compiling 1.2 java to native bytecode

[Bryan Welch]

We need to find a product that will take java 1.2 source files (or compiled classes) and compile them down to native bytecode for pentium platforms. Could anyone recommend a product to do that?
thanks,
-Bryan
------------------
----
Bryan Welch
[e-mail]

[Jesper Ottosson]

try out towerj from ibm, i'm not 100% sure, but i think that's what it does

[Bryan Welch]

We spent some time last week working with Visual Cafe 4.0 trying to use it to build a Win32 standalone application from our java product. After much work to get it all to compile properly, we talked to a technician at Symmantic who told us the work could not benefit us. It turns out that the native Win32 application created is actually a jvm, our app, and a bunch of middleware tying it all together. At best, we'll get a minor decrease in performance.
Has anyone tried to do the same with JBuilder?
-Bryan

[Frank Hale]

Could somebody clear up why people would need to compile java applications down to an .exe? Whats wrong with just deploying the JRE with your app? Sure it adds another step to the deploying process but its not that bad. I've just never seen the need to making a java app into an exe. With the speed of JITs today there really isn't a need for it. Plus if there is then either you should write the critical code in a language that can produce native code and use JNI to connect with it or you should write the whole application in another language which will produce an binary native executable.
Sorry to rant!
Frank

[Ray Marsh]

Just an FYI. I know this does not pertain directly to your question, but here it is anyway.
We (my shop) installed a large 3rd party package that uses Java, called Jacada. Running the software was OK, speed wise, but when we recompiled the classes on the AS/400 the performance increased significantly.

[Amit Zzz Kulkarni]

Bryan,
You can evaluate Jove ,my friend used it at their place and it's highly recommended ,it even supports JDK 1.3 + Swing + AWT + JClass from KLGroup. Whereas TowerJ from IBM is for pure Server side Java.
http://www.instantiations.com/jove/product/thejovesystem.htm
I can't 'see' the entire thread at a time ? Am new to this site.
Anyway to answer a point raised in one of the follow up comments,there are certain situations where if your Application needs to run without stopping for months together the JVM goes kaput ,(even if you set the -mx & -ms option) it sometimes gives OutOfMemoryError.I have heard that Hotspot is chain lightning and one of our teams has tested it ,a Swing Applet which used to take 6 seconds to load does so inside of 2 seconds approx.
Bryan, I would say wait for 6 months or so and then take a look at JDK 1.3 ,by then they would have resolved and tuned it a bit further.
Pardon me ,if it is alright to say what is it that you are using it for then ,the others may offer more suggestions.
Regards
Amit

Originally posted by Bryan Welch:
We need to find a product that will take java 1.2 source files (or compiled classes) and compile them down to native bytecode for pentium platforms. Could anyone recommend a product to do that?
thanks,
-Bryan

[alex petrovich]

to Frank Hale
I think next reasons force to use exe files instead of java ones:
1. Form point of view of Company - better intellectual property protection (not so easy to decompile as Java class files).
2. Simpler distribution (no care about PC's current JVM)
Maybe somebody can add more reasons...

alex from http://www.erudite-center.com/java

[Samuel Wolfe]

If we're talking about compiling a finished product for distribution, I'd prefer distributing a more professional-looking .exe version to bytecode...

[Nathan Pruett]

How's an .exe more "professional-looking"??? If a product comes as a .bat file that launches the JRE with your classes, or as an .exe that is basically a crushed together JVM with your classes, how is this any different? The majority of the users aren't going to check how the program is launched, and the rest probably won't care (as long as the program works correctly). Also, by making an .exe version of your program you're ignoring anyone who doesn't have a Windows PC (or whatever platform you compile it for), and if a new (faster, better, whatever...) version of the JVM comes out, your users won't be able to get any better performance out of your .exe app...
The only reason I have ever thought of using native-code compilation (after I found out faster execution was a pipe-dream...) was for easier distribution of a program (i.e. just download, unzip, and run...), but then I realized that by doing so no Linux, Mac, or other users could use the program. Downloading the JRE isn't a big deal, and most computers come with it already installed now... and if you're distributing on CD what's the big deal with an extra 3 megs of disk space?
-Nate
[This message has been edited by Nathan Pruett (edited January 18, 2001).]

[Marius Holm]

Samuel,
Professional-looking to who? (Perhaps you would see clearer if you took off those sunglasses...) Good reasons for converting to .exe are welcome. Good reasons for letting it stay Java, I believe is not necessary...
Regards,
Marius

[This message has been edited by Marius Holm (edited January 18, 2001).]

[Samuel Wolfe]

Hey, hey, hey! Ease up on th' shootin' irons, pardners. I said -professional- looking, not more practical or portable. Yer talkin' to an old DOS dinosaur, an' we see things a bit different sometimes, y'heah?