wood burning stoves 2.0*
The moose likes Java in General and the fly likes Native Compiler for Java Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Native Compiler for Java" Watch "Native Compiler for Java" New topic
Author

Native Compiler for Java

Jason Stortz
Ranch Hand

Joined: Jan 11, 2001
Posts: 68
How many of you have used the various Native Compilers for Java and what did you think of them? I am considering doing a research paper on the topic as most of my class mates in college didn't even know they existed!
So, if any of you have some pointers or suggestions for me, or just want to voice your opinion lets hear it! How easy are they to use? Which is your favorite? Did you notice a difference in performance? Do you notice more of a difference with certain style apllications (Ex: Swing vs Console)?
I have been unable to try gcj just yet, anyone used that? What about some of the ones for windows that cost big money like BulletTrain or JOVE?
Thanks I look forward to hearing from you!
Jason
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

At first, Java native compilation sounds really cool... (I admit it... when I first heard about it I was excited about it too...) The only problem is by doing this, you are completly breaking the "Run Anywhere" precept Java was founded on...
Not to ruin the topic of your paper, but the big question is : What do you get by using native compilation? One of the main reasons to use Java is for it's platform independence, if you are going to throw that away by using native compilation, why not just code in C++?
Just my $0.02 (plus tax ),
-Nate


-Nate
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
Jason Stortz
Ranch Hand

Joined: Jan 11, 2001
Posts: 68
Nathan,
First off, thank you for your response! You have brought up some great points, and I understand what you're getting at. I intend to use those angles in my discussion as well.
Just to bounce some ideas off you, here are some responses. A decent amount of the assignments and research we (we being an independent study group at school) do is on a UNIX(Linux) based platform. We use Java because that is the main programming language taught at my school, and few of us know C++ THAT well. We can almost all code much faster and better with Java. Also, I've HEARD (emphasis on have not confirmed) that native compilers for Java can take advantage of some optimizations that are not possible when native compiling from C++. I suspect this is a true, but I suspect the reverse is true and it was not mentioned in the article I read which was promoting Java over C++. I am not sure though.
Now, on the cross platform issue, like I said before, we do most of our work on Linux, and really could care less about this...though we could still just take the class files and go over to say windows and run, it would just be slower, and back to normal. NOTED: You mentioned if we didn't care why not just code in C++? Answer: As stated before, we know Java a lot better. Whether this be a good or bad reason it is what it is.
That said, I look forward to your thoughts and others thoughts as well. We code mainly on one system, and in Java because we know it fairly well. That being the case, we're looking into any way we can enhance those efforts. Also, more than anything this is simply for my curiosity which is why I was glad to get your open minded responses about C++.
Thanks again for your time,
Jason
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

Jason,
I agree with you that Java is much easier to code in than C++, and if the majority of your coders know Java, then you are probably better off doing it in Java!
I am not sure about the claim that you heard that Java Native Code Compilers optimize better than C++ compilers... this really sounds untrue, because (as far as I know) all Java Native Code Compilers are really doing are one of two things...

  1. Parsing the Java code and creating C++ code, then running the C++ code through a C++ compiler. I know that the Gnu Java Native Code Compiler does this.

  2. Creating an EXE that is basically a conglomeration of a small JVM, your class files, and some code to launch it. Basically, the class files still exist as Java class files, they are just being used as resources of a small JVM embedded in an EXE file. Very small (if any) speed improvements... if there are any it is due entirely to the small JVM being used. I think that M$ J++ (Yuk! ) used this, and some other IDE native code compilers did this too. ( IBM VisualAge comes to mind, but I am not sure... )


  3. Some of the more expensive Native Code Compilers ( JOVE and BulletTrain, as you mentioned ) may do this differently, but I could not find any information on their websites on what they actually do under the hood to find out...
    What is the reason that you want to do native code compilation? Speed? I have heard that most of the native code compilations add little speed to execution ( They do add some though... depending on what you are doing... and what type of native code compiler you are using... ) Ease of distribution? Just use a JAR file and a script. Make the user download the JRE if they don't have it.
    I would assume that you are doing this for a speed increase since you mentioned that you don't really care about platform dependence. The type of compilation I mentioned first ( translation to C++ ) may add some speed, but it all really depends on what you are doing. Personally, I would try to optimize my Java code before planning on a speed increase from a native code compiler. As I mentioned before, I am not sure about how much JOVE or BulletTrain improve performance, but they seem to be a little pricey.
    Personally, if speed is your main concern I would use the JNI ( Java Native Interface ) to use Java to access natively compiled C++ ( even C++ derived from Java through native code compilers! ) before natively compiling all my Java code. Just use the native compilation to speed up the things that need to be sped up.
    The entire issue of Java Native Code Compilation is one of tradeoffs, and for most people the loss of platform independence is not worth the small increase in performance that is gained.
    This would actually be a really good topic for a paper, there are lots of different facets and issues that can arise from this one argument...
    Just my $0.02,
    -Nate
Jason Stortz
Ranch Hand

Joined: Jan 11, 2001
Posts: 68
Nathan,
Again, thank you for your indepth reply!

I am not sure about the claim that you heard that Java Native Code Compilers optimize better than C++ compilers... this really sounds untrue, because (as far as I know) all Java Native Code Compilers are really doing are one of two things...

I think I found this information on the website for JOVE, but as you stated later in your response JOVE and BulletTrain are far too expensive for us to try at this time to see if it is true and what not.
Your points on how java native compilers accomplish their job is something I'm reading more and more. I suspect you're correct for the majority of the ones I've seen so far.

What is the reason that you want to do native code compilation? Speed? I have heard that most of the native code compilations add little speed to execution.

Well, we haven't gotten to really try much of anything yet, though we're setting up gcj to try right now on Linux. So far, we've optimized the code we use as well as we know how from Java's perspective, and we've used the native methods as you suggested in your response to resolve areas we feel are bottlenecks and what not, but we have limited ability to do this as we aren't that good at C/C++. Though this method also kill the cross platform issues in the purest sense of the idea. Again however, we don't really care about that.
All in all, we are doing it mainly out of curiosity, just to see what it can do for us, more of a "proof of concept" than anything. Which of course, is especially why we cannot afford to get a professional item like JOVE or what not.
The entire issue of Java Native Code Compilation is one of tradeoffs, and for most people the loss of platform independence is not worth the small increase in performance that is gained.

This would actually be a really good topic for a paper, there are lots of different facets and issues that can arise from this one argument...

Hope so.
Well, again thanks Nate. Your insights are appreciated.
Best of Luck,
Jason
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
Well I am a bit confused (as usual). As far as I can tell we ALL use Native compilers. The jdk ships with a JIT compiler and it is turned ON by default. So unless you actually went in and turned the parameter off, when your class gets loaded it is also compiled to Native machine code (without benefit of C++ interference). That is part of the reason that JRE's are operating system specific.
Try reading this: http://developer.java.sun.com/developer/onlineTraining/Programming/JDCBook/perf2.html#jit

"JavaRanch, where the deer and the Certified play" - David O'Meara
Jason Stortz
Ranch Hand

Joined: Jan 11, 2001
Posts: 68
Cindy,
Thank you for your response, and for the reading you provided.
I see your point, though in my reading I've come across people that say JIT is not the same. It is close, but it is not the same. Now, do I agree? Not real sure to be honest.
For example, according to what I understand about JIT compilers once it loads a method lets say for the first time it is "hooked" to a native block for the rest of execution and would be just as good as natively compiled code. So that means the only time you'd really suffer is in that first phase of loading.
Again, this is more of "just do it 'cause we can" project than for a need for speed. Perhaps I should spend some more time looking into fully native compilations versus what the JIT offers us already? Yes, perhaps so.
So, thank you for your points, they've got my brain turning.
Sincerely,
Jason
Originally posted by Cindy Glass:
Well I am a bit confused (as usual). As far as I can tell we [b]ALL use Native compilers. The jdk ships with a JIT compiler and it is turned ON by default. So unless you actually went in and turned the parameter off, when your class gets loaded it is also compiled to Native machine code (without benefit of C++ interference). That is part of the reason that JRE's are operating system specific.
Try reading this: http://developer.java.sun.com/developer/onlineTraining/Programming/JDCBook/perf2.html #jit
[/B]


[This message has been edited by Jason Stortz (edited March 16, 2001).]
ryan burgdorfer
Ranch Hand

Joined: Jan 24, 2001
Posts: 219
Does anyone know of any Windows native compilers? That is, something that will compile my source into a Windows-specific machine language executable (.exe)? I realize of course that this would defeat the write-once, run-anywhere capability of Java, but what I really want is a free way to create windows-executables.
Any pointers in the right direction are much appreciated...
------------------
  • Ryan Burgdorfer
  • Java Acolyte in
  • Columbus, OH USA


<UL TYPE=SQUARE><I><LI>Ryan Burgdorfer<BR><LI>Java Acolyte</I></UL>
Jason Stortz
Ranch Hand

Joined: Jan 11, 2001
Posts: 68
Ryan, do some searches through the different boards, I know they talk about how to make an executable jar file for Windows.
I don't know how, but I know you can do it, some of the demo things that come with the jdk are jar files that you can click on and they start up.
Help this helps,
Jason
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

Ryan,
I know that some of the Windows IDEs come with some sort of .EXE builder... IBMs VisualAge comes to mind, also M$ J++ ( yeccch! ). However, I do not believe that JBuilder provides native compilation.
Of the two high-end Java native code compilers mentioned above, BulletTrain specifically says that it runs on Windows and produces a windows execuatble, but JOVE never mentions what type of system it runs on.
Windows is really behind in the development of native code compilers... I know of a friend with an iMac that was even able to find a free native code compiler... and Gnu provides GJC for Linux and other Unix derivatives... however, it seems that there is not a free native code compiler for the windows platform... all of them are either integrated into commercial IDEs ( and usually only the high-end, high-priced Enterprise editions of these! ) or in very expensive commercial products designed specifically for this... If I didn't know any better I would say that M$ was repressing any research into native code compilers for their platform.
HTH,
-Nate
P.S. - Note to all that read this... if I disappear and stop replying to JavaRanch posts, you know what has happened to me... it was Micro- *gahhhh* THUNK! (They got me...)
eric moon
Ranch Hand

Joined: Nov 26, 2000
Posts: 133
Where I work, we create windows .exe files of our swing app using jove. Aside from occaisional glitches (had to rewrite a mousewheel dll) the code runs fine from the .exe. And it doesn't violate the write once, run anywhere--we only write it once! BUT! It is not any faster, in fact it's a bit slower.... Why do we do it? Strange windows thin-client that can't run java (cytrix).
Anyway, jove has been working pretty well for us.
e


<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>"Those who cast the votes decide nothing. Those who count the<BR>votes decide<BR>everything." <BR> -Joseph Stalin<HR></BLOCKQUOTE>
Peter Tran
Bartender

Joined: Jan 02, 2001
Posts: 783
Jason,
From an academic perspective, your research will be interesting. But from an industry/business standpoint, the cross paltform issue is really important.

Now, on the cross platform issue, like I said before, we do most of our work on Linux, and really could care less about this...

I agree with Nathan when he said
The entire issue of Java Native Code Compilation is one of tradeoffs, and for most people the loss of platform independence is not worth the small increase in performance that is gained.

Where I work, we develop on NT 4.0/2000 and port everything over to various UNIX OS (e.g. HP-UX, SOLARIS, AIX, etc.) When I optimize code, using Native Compilers for JAVA isn't even on my list of things to try. It's just too painful to get things working on all the platforms.
-Peter
Pete Cassetta
Greenhorn

Joined: Feb 13, 2001
Posts: 23
Jason,
Thanks for the interesting discussion. I'd like to respond to this:
Originally posted by Jason Stortz:
Also, I've HEARD (emphasis on have not confirmed) that native compilers for Java can take advantage of some optimizations that are not possible when native compiling from C++. I suspect this is a true, but I suspect the reverse is true and it was not mentioned in the article I read which was promoting Java over C++.

When you look at the tradeoffs between Java and C++, you have to conclude that C++ generally makes you worry about a lot of lower-level stuff yourself. If you do this efficiently, you are almost always going to end up with a much faster executable using compiled C++ than compiled Java. Java's whole approach of freeing the programmer from worrying about the details of memory allocation and deallocation is a Godsend for productivity, but when I first started using Java I was appalled at how often I had to use "new". Not that I minded using it, just that I wasn't accustomed to allocating memory 5 times per statement. I admit, though, the garbage collection strategy of Java is addictive, and it really frees me up to focus on the big picture.
So I think a really good C++ programmer is going to end up with a faster program than a really good Java programmer, even if the Java code is run through a compiler. Less memory allocation and freeing is going on in C++, so the machine code will require fewer CPU cycles to accomplish the same thing. (Consider how many times you allocate Strings in a typical Java program vs. a C++ program, and you'll see where I'm coming from.)
However (and this is a big caveat), Java enables us to more easily focus on the big picture, and I'll bet that this often leads to more efficient high-level algorithms. So if your overall algorithm is better in Java, then your program may well run quicker in Java than in C++, regardless of whether you compile the Java code or not. This is the real beauty of Java. I only use C++ when platform independence is not important, and either execution speed or the environment I'm programming for demands C++. (For example, I still use C++ for consumer software that is going to be commercially distributed.) Java is fast enough for most other uses, including all my Web development and in-house projects.
Jason Stortz
Ranch Hand

Joined: Jan 11, 2001
Posts: 68
Eric, Peter & Pere,
Thank you for your replies. I was able to obtain a no-cost academic version of JOVE for testing and my report. I am still milling about trying to figure it out and get some good examples to run through it.
Without attempting to make this into a c/c++ vs Java bit I will say this though: I find many people follow along Pete's remarks. They can use Java to get done quickly, or to hash out a bigger picture, but for commercial release quality applications they still use C++ or the like for a sort of "best in class" speed if you will.
I haven't been able to run a difinitive test yet that would hold up under real scrutiny but according to Eric (thanks for the info Eric) the optimizations that JOVE does on the .class files produced by javac aren't going to help all that much, but it does produce an executable. So, the executable is nice, but it wasn't really what I was looking for.
Then again, that's why we do this sort of research. To see what comes of it! =)
I would also like to comment on Peter T's reply. While *THIS* project in particular is unconcerned with cross platform issues I believe it is the standard case as Peter has said that it is INDEED a big issue in the real working environment, and not a thought to be discarded lightly. I am merely trying to find out what advantages and disadvantages lie in wait for us by trying something new, however, I would strongly encourage consideration of what is to be lost through native compilations like cross platform issues.
Thank you all for your comments, you all have good points!
Sincerely,
Jason
Brian Schaefer
Greenhorn

Joined: Feb 20, 2001
Posts: 5
Here are 2 more considerations:
1/ Although initial development may be easier in some languages than others, MOST software cost (80% they say) is in the maintenance. (from the developers point of view, most of the aggravation in the maintenance too) So a language that is easy to maintain is a major consideration.
2/ Java is faster than C in many situations. Try measuring the performance of a method using HotSpot. It never seems to cease getting faster as you run it longer. The day will come when dynamic byte code interpreters can more pervasively beat native compilers. In the meantime, thank our lucky stars for a language that makes OOP facile and enjoyable, and is plenty fast enough. ( even if you don't use some common sense and recycle or create less garbage)
Roseanne Zhang
Ranch Hand

Joined: Nov 14, 2000
Posts: 1953
I can see how smart Jason is to bring up this rich discussion for his research paper.
Congratulations!!!
Roseanne
Jason Stortz
Ranch Hand

Joined: Jan 11, 2001
Posts: 68

* Brian Schaefer
Good points, thank you for your input! I think that the development issue is largely in agreement with you by far. It is easier to maintain Java code than C/C++ and even if you have to sacrifice some speed(not saying you always do), you get a lot back in return. Also, I will try and check into the HotSpot statements some and see if I can come up with any tests for that which I can pit against some of the other JIT type compilers and native compilation, etc. Simply seeing how a "set" of these works against each other will be interesting.
Roseanne: Thanks, and thanks to everyone that has given me ideas!

ryan burgdorfer
Ranch Hand

Joined: Jan 24, 2001
Posts: 219
Jason, Nathan & Eric -
Thanks for your replies. Now, assuming I find the time to really delve into this, I have some good starting points.
------------------
  • Ryan Burgdorfer
  • Java Acolyte in
  • Columbus, OH USA
Wirianto Djunaidi
Ranch Hand

Joined: Mar 20, 2001
Posts: 210

Jason,
You might want to check http://www.volano.com/benchmarks.html
They do benchmarks on many JVM on different platform.
Of course their benchmark is not fullfledge benchmarks
that test all/most of Java features.
Good luck
Jason Stortz
Ranch Hand

Joined: Jan 11, 2001
Posts: 68
Ryo,
Great, thanks! That will be some good reading!
Thanks again,
Jason
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Native Compiler for Java
 
Similar Threads
Declaring a native as final
NX: stand-alone mode using RMI
Who's using threads?
Inner Classes
How do I change default tomcat installation ??