Java to Native - When?
John Young
Thanks
John Young
jyb...@ilnk.com
MW Ron
john...@usa.net (John Young) wrote:
> Is there any update on when the Java-to-native compilers are going to be
ready?
There is no date for a completion of the Java to Native compilers. There
has been very little interest in these tools. If you feel that this is a
misconception please feel free to write directly to me on this.
Ron
--
Battle of the Java development tools By Rex Baldazo
"When it comes time for final production, though,
I'll move over to CodeWarrior"
http://www.builder.com/Servers/RexTech/111698/?dd.cn
http://www.zdnet.com/pcweek/stories/news/0,4153,361176,00.html
CW Pro 4.0 C++ compiler 30% edge in Tak benchmark over VC++ 6.0
METROWERKS - Ron Liechty - MW...@metrowerks.com
Malcolm I. Ross
In article
<MWRon-20119...@dyn1-tnt2-28.kalamazoo.mi.ameritech.net>,
MW...@metrowerks.com (MW Ron) wrote:
>In article <johnyoung-ya023080...@news.ilnk.com>,
>john...@usa.net (John Young) wrote:
>
>> Is there any update on when the Java-to-native compilers are going to be
>ready?
>
>There is no date for a completion of the Java to Native compilers. There
>has been very little interest in these tools. If you feel that this is a
>misconception please feel free to write directly to me on this.
>
Have you ever asked the newsgroup if JNI is interesting, or is it just a
feeling? I am very interested, but was waiting for the next release to
begin really investigating. The alpha stuff was a pain to work with, so I
held my tongue and my breath, waiting for the next release. Is it really
fair to say that there has been "very little interest in these tools",
based upon a painful alpha-release of compiler technology ?
In the grand scheme of things, I think JNI will/does play an important
role. I think others will agree.....
-Malcolm Ross
Owner, Earth in Motion Technologies
Malcolm I. Ross
ei...@insync.net (Malcolm I. Ross) wrote:
>Ron -
>
>In article
><MWRon-20119...@dyn1-tnt2-28.kalamazoo.mi.ameritech.net>,
>MW...@metrowerks.com (MW Ron) wrote:
>
>>In article <johnyoung-ya023080...@news.ilnk.com>,
>>john...@usa.net (John Young) wrote:
>>
>>> Is there any update on when the Java-to-native compilers are going to be
>>ready?
>>
>>There is no date for a completion of the Java to Native compilers. There
>>has been very little interest in these tools. If you feel that this is a
>>misconception please feel free to write directly to me on this.
>>
>
>Have you ever asked the newsgroup if JNI is interesting, or is it just a
Sorry, that should have been Java to Native, not JNI.
>feeling? I am very interested, but was waiting for the next release to
>begin really investigating. The alpha stuff was a pain to work with, so I
>held my tongue and my breath, waiting for the next release. Is it really
>fair to say that there has been "very little interest in these tools",
>based upon a painful alpha-release of compiler technology ?
>
>In the grand scheme of things, I think JNI will/does play an important
Java to Native, not JNI.
Dave Fernandes
<MWRon-20119...@dyn1-tnt2-28.kalamazoo.mi.ameritech.net>,
MW...@metrowerks.com (MW Ron) wrote:
> There is no date for a completion of the Java to Native compilers. There
> has been very little interest in these tools. If you feel that this is a
> misconception please feel free to write directly to me on this.
I would be very interested in something that could compile a full blown
app or library and provide a native version of classes.zip. The problem
with the current compiler is that it doesn't support threads, awt, etc.
(At least last time I checked.) Given these restrictions, it was not
worth the effort to try using the technology.
Scott Ellsworth
>john...@usa.net (John Young) wrote:
>
>> Is there any update on when the Java-to-native compilers are going to be
>ready?
>
>has been very little interest in these tools. If you feel that this is a
>misconception please feel free to write directly to me on this.
I am interested, but the projects I write are all threaded Swing apps.
CodeWarrior is still my favorite Java environment, but I did not feel
the need to be a thrill seeker in this area until I felt the tools
were mature enough to support my apps. I hope this does not mean
I am going to wait forever.
An interesting side note - I write a lot of code for my working
persona in Borland C++. I will often use the last version of
CodeWarrior that the company bought as an IDE, and then I
go back to Borland to compile. I would love to ditch the Borland
compiler but we are using OWL, which means we are stuck
with Borland until we can afford a major rewrite.
Scott
Scott Ellsworth sc...@eviews.com
"When a great many people are unable to find work, unemployment
results" - Calvin Coolidge, (Stanley Walker, City Editor, p. 131 (1934))
"The barbarian is thwarted at the moat." - Scott Adams
Rik Jones
>
> In article
> <MWRon-20119...@dyn1-tnt2-28.kalamazoo.mi.ameritech.net>,
> MW...@metrowerks.com (MW Ron) wrote:
>
> > There is no date for a completion of the Java to Native compilers. There
> > has been very little interest in these tools. If you feel that this is a
> > misconception please feel free to write directly to me on this.
>
> app or library and provide a native version of classes.zip. The problem
> with the current compiler is that it doesn't support threads, awt, etc.
> (At least last time I checked.) Given these restrictions, it was not
> worth the effort to try using the technology.
I agree if the Java to Native could be flushed out I would be all over
using it.
I tried a few things with the Trill seaker version and just got
frustrated with the limitations. In addition to the AWT and Treads I
think JDBC is also important
Kees van Reeuwijk
>In article <johnyoung-ya023080...@news.ilnk.com>,
>john...@usa.net (John Young) wrote:
>
>> Is there any update on when the Java-to-native compilers are going to be
>ready?
>
>There is no date for a completion of the Java to Native compilers. There
>has been very little interest in these tools. If you feel that this is a
>misconception please feel free to write directly to me on this.
This is probably one of those chicken-and-egg situations.
For example, I am considering converting a Windows C++ program to Java
to make it more portable and use Java libraries, but for the moment Java
programs simply run too slow for this to be practical. The MW Java to
Native compiler looks a bit too experimental to bet so much conversion
porting time on.
I'm sure I'm not unique.
Greg Galanos
davef@NOSPAM_delete_this.dato.com (Dave Fernandes) wrote:
> In article
> <MWRon-20119...@dyn1-tnt2-28.kalamazoo.mi.ameritech.net>,
> MW...@metrowerks.com (MW Ron) wrote:
>
> > There is no date for a completion of the Java to Native compilers. There
> > has been very little interest in these tools. If you feel that this is a
> > misconception please feel free to write directly to me on this.
>
> I would be very interested in something that could compile a full blown
> app or library and provide a native version of classes.zip. The problem
> with the current compiler is that it doesn't support threads, awt, etc.
> (At least last time I checked.) Given these restrictions, it was not
> worth the effort to try using the technology.
I'm going to make some statements and take the heat so poor Ron doesn't
get blamed for technology decisions made elsewhere.
Even though, our investigations into Java to native proved quite
successful in terms of proving that:
1-Java source compiled to native code achieved the same performance
characteristics as C++, and
2-Java objects mapped to C++ objects allowed us to debug both from the same
debugger,
we have decided to not deploy this technology on the desktop for quite a
few reasons:
1-many customers stressed portability over performance
2-it remains unclear that a native binary is a 100% pure Jav
3-we could not overcome some real issues with respect to the reflection APIs
4-the new VMs' performance envelopes are getting much better and should increase
with new versions from Sun, Microsoft and Apple
5-the tradeoff for performance was size, the binaries were incredibly large
as most of the VM and all the classes had to be sucked into the final app
6-there remains outstanding issues in order to provide a common runtime that
is acceptable to the system vendors and to Sun
For all these reasons, we have decided to not introduce a product that
would only be half-pregnant. Metrowerks continues to develop and use Java
to native technology for specific use within the company, such as building
our Java compilers native (where awt and other APIs are not required).
Hopefully, one day, we can deploy this technology, but currently, we have
made the decision not to given the restrictions and limitations our
customers would have to live with.
-GregG
--
Founder, President and Chief Technology Officer
Metrowerks, Inc.
Allen Ethridge
Greg Galanos wrote:
> we have decided to not deploy this technology on the desktop for quite a
> few reasons:
> 5-the tradeoff for performance was size, the binaries were incredibly large
> as most of the VM and all the classes had to be sucked into the final app
Microsoft insists that application software is an integral part of its operating
system. Oracle announces that they will deliver a computer without an
operating system. And Metrowerks has to build compilers that place
operating system functionality (or maybe just a complete operating system)
into each application if they want to deliver a Java to Native compiler.
When did it all get so distorted?
> Hopefully, one day, we can deploy this technology, but currently, we have
> made the decision not to given the restrictions and limitations our
> customers would have to live with.
I guess there isn't much chance of adding Eiffel to the languages you
support, is there? I hear Eiffel even runs on real-time systems these days.
Just some whining from a programmer desperately wanting a good OO
language/compiler and a telecommunications dweeb who can't understand
why people who make computer systems don't understand concepts like
"modularity" and "standards".
Allen
Gerry Beggs
> > we have decided to not deploy this technology on the desktop for quite a
> > few reasons:
>
> > 5-the tradeoff for performance was size, the binaries were incredibly large
> > as most of the VM and all the classes had to be sucked into the final app
Couldn't this stuff be put into a shared library?
That way only application-specific code would have to go into the
application.
Or am I missing something?