begin quoting Rick Funderburg as of Tue, Aug 22, 2006 at 12:18:41PM -0700: > Stewart Stremler wrote: > >Java gets compiled (i.e., transformed) into bytecode, which is a > >binary intermediate format, which then gets interpreted; Sun's > >JIT takes the bytecode and further translates it into the local > >hardware's machine instructions. > > > >So yes, Java's interpreted, but then, so is the Linux kernel, > >when I run it on my PPC mac under VirtualPC. > > Java _can_ be interpreted, but with JIT, it is not interpreted; instead > it is compiled at runtime. I get the sense that you know the > distinction, but it did not come through clearly (at least to me) in the > paragraphs above.
Apologies for the lack of clarity. > With JIT, you take a performance hit while the > compilation takes place (when the code loads), but you do not incur any s/loads/is run/ At one of the early presentations, there was talk about only compiling code on the *second* invocation -- I don't know if this is what they finally went with. I should probably go read up on it one of these days. > performance penalties when running the code, as you would when using > interpreted Java. There are some penalty, still, but it mostly amortizes out. [If I write code with a lot of reflection (introspection), there's not a lot the JIT can do... but at least the code still runs.] > Also, Java can be compiled into native code with gcj[1], which produces > a compiled binary just like typical C or C++ compilers. Bleah. The ability to ship around .class/.jar files is one of the benefits of Java; compiling to native code is an optimization step that should only be invoked /after/ the profiler says there's nothing obvious to fix. :-) Does gcj handle reflection yet? I've not kept up with it -- but that would produce a binary quite a bit different than that produced with C or C++ compilers. > So, what this shows, as was stated before in this thread, is that the > language is a specification, and the runtime environment is typically an > implementation detail. The runtime is still specified. It's not merely an implementation detail. :) > I think that failing to make this distinction is > one of Sun's failures. Branding both the language and the platform as > Java has caused at least some confusion. For example, Jython (Python > compiled into Java bytecode) helps blur the line. What, "JVM" and "Java Language" wasn't enough of a distinction? How should they have done it? Call it the "Sun Independent Hardware Generalization"? Wait, no, we want a cute acronym. Um. L. A. T. T. E. -- E could be "environment". A could be "abstract". Um. Um. L could be "licensed"? T could be "tranlation", perhaps. Darn, I'm stuck. So much for acronym-driven design. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
