[robotic]

I'm in a CSC 101 class at my college, where we are studying java. In our textbook, it says that you can either compile java to bytecode (interpreted using the virtual machine) or compile all the way to machine code. How can I compile java to machine code in Project Builder? I've heard that most of the speed issues with Java are with the virtual machine, so would compiling the machine code make it as fast as objective C?

Thanks,
Robotic

[lgerbarg]

Originally posted by robotic:

I'm in a CSC 101 class at my college, where we are studying java. In our textbook, it says that you can either compile java to bytecode (interpreted using the virtual machine) or compile all the way to machine code. How can I compile java to machine code in Project Builder? I've heard that most of the speed issues with Java are with the virtual machine, so would compiling the machine code make it as fast as objective C?

Thanks,
Robotic

You can conceptually compile it all the way to machine code, but no compilers do. GCC 3.0 has done most of the work necessarfy for this, but it is not quite complete.

Louis

[absmiths]

Comiling to native code is not as big a boon as you might expect. I saw a survey once on this and the result was that the native code executed faster initially due to the requirements of the VM loader, but code executed in a Vm with HotSpot 1.3.0 installed actually executed faster. The reason is that the runtime compiler can make a lot more optimizations based on the runtime environment than a static compiler can.

Also note that you will be losing many of the HUGE benefits of the runtime environment, such as dynamic class loading (I have yet to see a native compiler that will let you bring in classes that were not available at compile time), RMI (for the same reasons as dynamic class loading), Object serialization, etc.

If you are trying to speed up a GUI program than I would expect 0%difference with native code. On the other hand, mathematical applications (neural-nets, monte-carlos, etc) could be helped but these are so fast as it is that the difference would probably be negligible.

One more thing, if you did statically compile your code, the linker would either have to link in the entire VM code *and* the compiled standard libraries (which would probably equal ~5MB at least), or you would be dynamically linked against this library.

One of the misconceptions is that Java is interpreted like a language like Perl is, which is not the case. Java is more accurately called an emulated language, since what is executed is not source code, but binaries compiled for a very specific machine, with a very well defined environment. (Which, BTW, is why Sun calls the 'interpreter' a 'Virtual Machine.')

The short story is - I wouldn't bother.

[This message has been edited by absmiths (edited 02-16-2001).]

[Dalgo]

Originally posted by absmiths:

Also note that you will be losing many of the HUGE benefits of the runtime environment, such as dynamic class loading (I have yet to see a native compiler that will let you bring in classes that were not available at compile time), RMI (for the same reasons as dynamic class loading), Object serialization, etc.

Cocoa with Objective C dynamically links it's classes. Why couldn't someone make a Java compiler that did the same thing? I doubt that it's a limitation of the language and more a limitation of the runtime environment. I mean, Objective C has some sort of runtime architecture that it set up with the system that allows it to link to stuff on the fly. When something runs under the Java VM it has it's own runtime environment right there.

Also, I'd tend to think that having the compiled code run slower than that which is running under the Virtual Machine is just a sign that you have a really crappy compiler or you compiled it with zero optimization. I mean, Objective C Cocoa runs faster than your Java Cocoa running under it's VM. I don't think that the languages are the limiting factor here; I think it's the fact that the Java isn't being run natively.

[absmiths]

//--
Cocoa with Objective C dynamically links it's classes. Why couldn't someone make a Java compiler that did the same thing?
//--

Java does dynamically link classes - that is what you loose when you use native compilation. In this sense, natively compiling Java classes is exactly the same as normal compilation of C++ classes - the classes disappear in the executable and you are left with a more procedural application.

//--
I mean, Objective C has some sort of runtime architecture that it set up with the system that allows it to link to stuff on the fly
//--

Java has a mechanism to do the same thing - System.loadLibrary(). But that can only load procedural libraries - not new object types. E.G., if you need to load 'plugins' from a directory, you can use Class.forName() or write a custom ClassLoader to pull Class objects from a server, or a directory, etc, and bring new object types into the system that hadn't been written when the application was compiled. Native code compilation cannot do that.

//--
Also, I'd tend to think that having the compiled code run slower than that which is running under the Virtual Machine is just a sign that you have a really crappy compiler or you compiled it with zero optimization. I mean, Objective C Cocoa runs faster than your Java Cocoa running under it's VM
//--

And C-code and assembler run significantly faster than Objective-C - what is your point? Did you have optimzation turned on? The compiler isn't the issue - there are specific requirements for the runtime environment which limit the compiler. For example, the smartest compiler in the world cannot inline a non-private method in a Java class. Why? Because that method might be overridden at any point in the future. On the other hand, compilation at runtime CAN inline a non-private method because it knows exactly who is calling the method - something a static compiler may not do. Part of the performance problem of Java on OS X is the VM itself - Apple has clearly not spent any time optimizing it (as of PB - I hear that they have come a long way since), whereas the Objective-C environment has certainly been optimized. I generally see 2X performance on equivalent systems running Windows 2k - a by-product of Sun's optimizations mostly.

//--
I don't think that the languages are the limiting factor here; I think it's the fact that the Java isn't being run natively
//--

Yet another inaccuracy. The problem is not the structure of the language or the syntax - the issue is the runtime versus compile-time environments. If it is still unclear, read "The Java Virtual Machine" from JavaSoft.

[theolein]

Java can be compiled to native code on one platform only: HP's chaiVM. It uses an ahead-of-time compiler. But as the man said, you lose the ability to dynamically load classes. Apart from that I really hope apple doesn't let java go to the dogs on OSX as they did on MacOS. There are, sadly, signs that apple isn't quite sure what to do with it's java strategy. There is a note over at the o'Reilly java network that apple will not be supporting Java 2EE. This would be sad because it would discourage potential enterprise dvelopers from moving over to OSX.

------------------
#ex-dotcom#