Possibility to add Java/JVM as additional target platform for Eiffel

[galuszkiewicz]

Hi all,

Looking at the high portability of Eiffel runtime, I was thinking
about theoretical possibility to add another target (could be quite
valuable for Eiffel's popularity) - Java JVM. If everything in Eiffel
is translated to high portable C code, translating that C code to Java
source (and then compiling by standard java compiler) should not be
very complex task. There are even automated C to Java transformers
which already exist.

I know about SmartEiffel and its compilation to Java byte-code, but
firstly - I'm thinking about translating Eiffel-C to Java (as a
source), an another kind of finalization step - this should be much
easier to do and more flexible than direct Eiffel compilation to
another (for Eiffel) target platform-code, and secondly - SmartEiffel
decided to go its own way and not follow the ISE standard, and, it is
much less developed (in sense of whole environment/system) than ISE
Eiffel.

Of course, Eiffel applications can be ported to almost any platform in
the world (much more than Java), but the reason why I started thinking
about this was a possibility to integrate and use Eiffel in enterprise
servers/systems under Unix, like J2EE/EJB application servers.

Has anybody in ISE already maybe thought about providing this feature?
I'm pretty sure that yes, so what were the conclusions?
I'm very interested in opinions about such opportunity, possible
problems and your thoughts.

Piotr




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[vrhj2000]

I think that(Eiffel-c-JavaByteCode)could be fantastic.
There is a project called JEiffel(JEiffel - An Eiffel to Java
compiler.), you can see here
(http://se.inf.ethz.ch/projects/benno_baumgartner/), but the source
code, is not available :(.

Slds
JV


--- In eiffel_software@..., "galuszkiewicz" <pkg@...> wrote:

>
> Hi all,
>
> Looking at the high portability of Eiffel runtime, I was thinking
> about theoretical possibility to add another target (could be quite
> valuable for Eiffel's popularity) - Java JVM. If everything in Eiffel
> is translated to high portable C code, translating that C code to Java
> source (and then compiling by standard java compiler) should not be
> very complex task. There are even automated C to Java transformers
> which already exist.
>
> I know about SmartEiffel and its compilation to Java byte-code, but
> firstly - I'm thinking about translating Eiffel-C to Java (as a
> source), an another kind of finalization step - this should be much
> easier to do and more flexible than direct Eiffel compilation to
> another (for Eiffel) target platform-code, and secondly - SmartEiffel
> decided to go its own way and not follow the ISE standard, and, it is
> much less developed (in sense of whole environment/system) than ISE
> Eiffel.
>
> Of course, Eiffel applications can be ported to almost any platform in
> the world (much more than Java), but the reason why I started thinking
> about this was a possibility to integrate and use Eiffel in enterprise
> servers/systems under Unix, like J2EE/EJB application servers.
>
> Has anybody in ISE already maybe thought about providing this feature?
> I'm pretty sure that yes, so what were the conclusions?
> I'm very interested in opinions about such opportunity, possible
> problems and your thoughts.
>
> Piotr
>

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Emmanuel Stapf [ES]]

> There is a project called JEiffel(JEiffel - An Eiffel to Java
> compiler.), you can see here
> (http://se.inf.ethz.ch/projects/benno_baumgartner/), but the
> source code, is not available :(.

The source code of the project is indeed missing. But not everything is
lost. You can still download the experimental compiler from the above
website. The report contains the strategies used to map the Eiffel multiple
inheritance onto the JVM (which is the most difficult part in this). This
project was based on some code that is still in our compiler source tree for
showing the feasibility of such code generation. It was using at the time of
a simplified version of Eiffel (remember Eiffel#!).

If you are interested in this, feel free to contact us on the developer
mailing list of EiffelStudio
(http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel).

Regards,
Manu



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[galuszkiewicz]

Hi !

I have found that project (a master thesis), and read the docs, but it
is definitely not finished and nobody seems to continue his great work...
Anyway that guy was doing it on "binary" level (like .NET target)
which is more complex - I think (but of course gives better
integration grade). I thought about translating C source as it is
already "decoupled" from all object-level complexity, so translation
to Java should be easy - here Java is more complex, so it can easy
take all constructs and program flow from C (the only thing which can
make troubles is the basic runtime staff with an interface to the real
OS/platform). Of course this way doesn't allow good object and code
integration - it would be just a possibility to call some high level
functions from other "real" Java code to do their job and return the
results back to the caller, but with the advantage of staying in JVM
(so not as comprehensive as .NET integration).

But ! Some other idea just came up to my mind - because all that
complex work is already done for .NET MSIL and this is quite similar
to Java byte-code, maybe just some conversion MSIL-->J.bytecode can
satisfy this feature??? What do you think?

Piotr

--- In eiffel_software@..., "Emmanuel Stapf [ES]"
<manus@...> wrote:
> The source code of the project is indeed missing. But not everything is
> lost. You can still download the experimental compiler from the above
> website. The report contains the strategies used to map the Eiffel
multiple
> inheritance onto the JVM (which is the most difficult part in this).
This
> project was based on some code that is still in our compiler source
tree for
> showing the feasibility of such code generation. It was using at the
time of
> a simplified version of Eiffel (remember Eiffel#!).
>
> If you are interested in this, feel free to contact us on the developer
> mailing list of EiffelStudio
> (http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel).
>
> Regards,
> Manu
>




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Emmanuel Stapf [ES]]

> But ! Some other idea just came up to my mind - because all
> that complex work is already done for .NET MSIL and this is
> quite similar to Java byte-code, maybe just some conversion
> MSIL-->J.bytecode can satisfy this feature??? What do you think?

Back in 1996, there was an Australian project that did a java source code
generator starting from the Eiffel byte code that we generated, but it did
not really work. I do not recall exactly the reason, but what I now know
using our experience generating .NET and also having helped Benno doing his
java byte code generation is that generating java byte code is the way to
go. In both .NET and java byte code the complex part is not the code
generation itself, it is only two major things:
- dynamic binding
- object model representation

For both .NET and java byte code, we have been able to do this but so far
only .NET is really supported until someone devotes more time on the java
byte code backend.

Hope this helps,
Manu



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[donthb]

Instead of making Java a target would it be possible to use a multiple
inheritance aware JVM to replace the byte code interpreter (i.e.
replace Eiffel byte code with an extended Java byte code)?  With what
was done to handle .Net is multiple inheritance necessary for such a
JVM to be usable as a replacement within EiffelStudio? Is the .Net CLR
being used in EiffelStudio in a similar way?








------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Emmanuel Stapf [ES]]

> Instead of making Java a target would it be possible to use a
> multiple inheritance aware JVM to replace the byte code
> interpreter (i.e.
> replace Eiffel byte code with an extended Java byte code)?  

That would be possible but does such a JVM exist?

> With what was done to handle .Net is multiple inheritance
> necessary for such a JVM to be usable as a replacement within
> EiffelStudio? Is the .Net CLR being used in EiffelStudio in a
> similar way?

Currently the .NET CLR is used only when you decide to target .NET,
otherwise we still use our own byte code interpreter for executing the small
changes that are made while developing. That way we have a mixture of
machine code (compiled from our C generated code) and byte code that makes
the end result reasonably fast for a development version, and faster than
what the .NET CLR can provide.

Manu


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[donthb]

Where in the development process is the CLR used when targeting .Net?
Does it replace the byte code interpreter in the scenario you described?

I was thinking of an extended JVM for support of multiple inheritance
not a JVM that can intermingle byte code and machine code execution.
 But, again, is supporting multiple inheritance necessary in the
Eiffel byte code?  JVMs that extend the Java byte code to directly
support multiple inheritance have been done in academia.

As far as the intermingling of "codes" couldn't that kind of
capability be an adaptation of the the sources that supports debugging
of byte code in the JVM? Similar to an exception when the CPU
encounters a bad instruction?





------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[donthb]

Where in the development process is the CLR used when targeting .Net?
Does it replace the byte code interpreter in the scenario you described?

Research projects at the university level have experimented with JVMes
that have been extended to support byte code that incorporate multiple
inheritance. This is what I was thinking. But, again, is supporting
multiple inheritance necessary in the Eiffel byte code?

As far as the intermingling of "codes" couldn't that kind of
capability be an adaptation of the the sources that supports debugging
of byte code in the JVM? Similar to an exception when the CPU
encounters a bad instruction? This way working from outside in.
Instead of using JNI and working from the inside out?




------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Emmanuel Stapf [ES]]

> Where in the development process is the CLR used when targeting .Net?

It depends what you mean by development process? The CLR is used at
execution time.

> Does it replace the byte code interpreter in the scenario you
> described?

When targetting .NET, it certainly replaces our byte code interpreter.
 
> Research projects at the university level have experimented
> with JVMes that have been extended to support byte code that
> incorporate multiple inheritance. This is what I was
> thinking. But, again, is supporting multiple inheritance
> necessary in the Eiffel byte code?

The reason to have a byte code that supports multiple inheritance is to make
code verifiable as in most byte code I've seen you can simulate easily what
we do in our C code generation.
 
> As far as the intermingling of "codes" couldn't that kind of
> capability be an adaptation of the the sources that supports
> debugging of byte code in the JVM? Similar to an exception
> when the CPU encounters a bad instruction? This way working
> from outside in.
> Instead of using JNI and working from the inside out?

If our universe was byte code based, then the similar approaches as the one
you mentioned could be used. But the reason for mixing codes is because our
universe is C code based and to avoid expensive C compilation and linking we
created the byte code to interpret the minor modifications one made during
development. This is the metaphore of the melting ice, see
http://tinyurl.com/68ut9e.

Regards,
Manu


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[donthb]

> The reason to have a byte code that supports multiple inheritance is
> to make code verifiable as in most byte code I've seen you can
> simulate easily what we do in our C code generation.

So, would replacing the Eiffel byte code with Java byte code be
possible?  This way the freezing of code would be removed for Java,
but remain for C and .Net. How much more overhead would this be as
compared to Melting Ice now, since Eiffel Studio would be using a JVM
instead of the interpreter in this case?

Are all the features of Eiffel Studio available when targeting .Net?
If Melting Ice is available for .Net targets what happens when code is
frozen?  Is managed code created directly without source generated? If
source is generated what language is used?









------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Peter Gummer-2]

donthb wrote:
>
> Are all the features of Eiffel Studio available when targeting .Net?
> If Melting Ice is available for .Net targets what happens when code is
> frozen?  Is managed code created directly without source generated?

Eiffel compiles directly to .NET IL. Freezing is very, very quick in .NET,
because there is very little C code to compile.

(But I'm just a user; I'm sure one of the EiffelStudio developers will give
you a more definitive answer.)

- Peter Gummer



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Emmanuel Stapf [ES]]

> So, would replacing the Eiffel byte code with Java byte code
> be possible?  This way the freezing of code would be removed
> for Java, but remain for C and .Net. How much more overhead
> would this be as compared to Melting Ice now, since Eiffel
> Studio would be using a JVM instead of the interpreter in this case?

Using the Java byte code would be possible, but the C compilation would
still be required since some Eiffel libraries do need to interface with C
code. The overhead would be similar, possibly slightly faster since our byte
code is only interpreted and one could hope that the java one would be
faster.
 
> Are all the features of Eiffel Studio available when targeting .Net?

Yes.

> If Melting Ice is available for .Net targets what happens
> when code is frozen?  Is managed code created directly
> without source generated? If source is generated what
> language is used?

Yes, we do incremental compilation under .NET however this is not as fine
grained as it is with our Eiffel byte code. And we generate managed code
directly.

Regards,
Manu


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[donthb]

> Using the Java byte code would be possible, but the C compilation would
> still be required since some Eiffel libraries do need to interface
> with C code.

What changes to the library implementation were made for .Net in order
to avoid the C code dependencies in the libraries? I would guess that
JVMes should be able to support the same?

I guess the idea of using Java byte-code will not necessarily make
supporting JVMs easier in EiffelStudio?  The first platform I wish to
target only supports a specific JVM and it would be great to be able
to use a JVM of choice when doing development.

The possibility of having a single code base for native code, JVM and
.Net is very enticing whether or not the system dependent code are in
libraries. Even so, I would think this would take a long time to
implement.

Thanks for all the attention to my questions.







------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[donthb]

> Using the Java byte code would be possible, but the C compilation would
> still be required since some Eiffel libraries do need to interface
> with C code.

So, is Eiffel byte code used when targeting .Net until code is frozen,
when managed code is generated?  How do the Eiffel libraries support
.Net? How much .Net is required to use the CLR? Perhaps this method
could be used to support JVMes.

How would switching to JVMes impact support for .Net and the
generation of managed code (and C code) and would differences in
garbage collection in the runtime environments be problematic?

I thought replacing Eiffel byte code with Java byte code could make
the support of JVMs easier while also adding capabilities to Eiffel
Studio.  One such capability would allow the choice of JVM (such as
simulaters using embedded JVMes) when picking a target platform and
another would be execution and debugging of Java byte codes from
within the IDE without needing to freeze JVM targeted code.



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Emmanuel Stapf [ES]]

> So, is Eiffel byte code used when targeting .Net until code
> is frozen, when managed code is generated?  How do the Eiffel
> libraries support .Net? How much .Net is required to use the
> CLR? Perhaps this method could be used to support JVMes.

When targetting .NET, we only generate .NET CLI code. For existing Eiffel
code, this is transparent.
 
> How would switching to JVMes impact support for .Net and the
> generation of managed code (and C code) and would differences
> in garbage collection in the runtime environments be problematic?

If we target a JVM then it is like supporting a new platform and nothing
more. Once someone has done the work, one can compare the various platforms
(classic, .NET and JVM) and compare their various speed of execution.
 
> I thought replacing Eiffel byte code with Java byte code
> could make the support of JVMs easier while also adding
> capabilities to Eiffel Studio.  One such capability would
> allow the choice of JVM (such as simulaters using embedded
> JVMes) when picking a target platform and another would be
> execution and debugging of Java byte codes from within the
> IDE without needing to freeze JVM targeted code.

I'm not sure to understand what you mean nor what you would like to achieve.
Could you expand a bit?

Regards,
Manu


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.