Java Compiler

(Moved from MachineCode, please ReFactor to establish context.)

There are also virtual CPUs, such as the JavaVirtualMachine. These could have been implemented in hardware, but happen to be implemented in software. In the future we may see JavaVirtualMachine's implemented in hardware---then we will have to distinguish between those that are JavaVirtualMachine's and those that are true JavaMachine?'s.

Since we have no commonly used native JavaMachine?, Java is typically not compiled to native MachineCode. Instead it is compiled to code for the virtual machine, that is is then interpreting the code or JIT-Compiling it, for instance. But native code generators for Java do exist. GCJ and ExcelsiorJet? are different examples of this.

According to Sun, Java is compiled to byte code -- the intermediate code (class files) that is interpreted by the Java machine, be it virtual or otherwise. Anything that compiles Java source directly into something native to a particular CPU (other than a JM) is not a Java compiler, as Microsoft and others came to find out.

Depends how you define 'Java' and 'Java compiler'. Anything which converts 'JavaLanguage' to _any_ other form is a Java compiler, as the term is commonly understood. Only something which converts 'JavaLanguage' to 'JVM language' is a Java compiler, as defined by Sun. It is sad that the legal system forces such a distinction of technical terms to be important for political reasons. --WilliamUnderwood

You betcha. The entire purpose for having this distinction is so that you don't have the Evil Empire and others hijacking Java for their own purposes. Remember, this is exactly what M$ was trying to do with their "extensions" and whatnot before Sun handed them their head. Having Java as bytecode in the Sun format is a large part of what makes Java so secure and testable -- you can always determine if a Java class file contains only valid Java bytecode. Being able to decompile it back to source is a secondary benefit.

Java "compilers" that convert Java source into something executed in the host machine's native environment (Windoze, Linux, VMS, OS/9, VxWorks, etc.) are not, by definition, "Java compilers." They are Java converters. This distinction is not simply a matter of semantics; it goes to the very heart of the Java Machine and its usefulness. A commercial example of a javaconverter, which is actually called "a native compiler" or a "AOT compiler" (AheadOfTimeCompiler? compare with JIT JustInTimeCompiler) is "Excelsior JET" (http://www.excelsior-usa.com).

For any other language, that would indeed be a compiler, and the issue of the usefulness of byte codes would be utterly secondary. It's not a "Java compiler" purely by decree of Sun Microsystems.

But you know, it is not at all clear to me that the Java community is at all consistent about sticking with the terminology you outline.

BTW, I think you don't mean to say "not simply a matter of semantics", since "semantics" is about meaning; I think you mean "not simply a matter of terminology".

: There is no way to force the distinction that Sun would have one make, without reducing the word 'Compiler' to nonsense terminology. If you restrict it to Java-as-C-like-language or Java-as-bytecode-language then it works; restricting to _exactly_ one input language and _exactly_ one output language reduces the term 'Java Compiler' to the name of a product (i.e., "The Prevayler", "Oracle", "Hyundai Accent", etc). I was under the impression that one couldn't copyright terms in an industry which already had a technical meaning in the industry; this is why there is such power in having your brand name become the household name of an item ('kleenix' vs 'tissue paper', 'xerox' vs 'photocopy'). But Sun isn't defending a new term that they invented for compilation. They're trying to take a neutral term by force.
: The distinction doesn't make any difference in the testability / security of the bytecode... you could always compare it to the standard, it simply wouldn't work with extensions. There are already such extensions, and they require specialized VM's (consider a java persistence engine which uses a special vm and compiler).
: I'm quite unconvinced that Sun isn't an EvilEmpire? all their own :) --WilliamUnderwood

Hmmm ...

GCJ is not a 'Java compiler^tm', but GCJ is a native compiler for JavaLanguage. The whole problem about terminology probably comes from the fact that SunMicrosystems has registered the term 'Java compiler^tm' as a trademark. That doesn't change the meaning or semantics of the words, but you cannot marketing GCJ as a 'Java compiler', you have to marketing it as a compiler, that happens to compile JavaLanguage into native MachineCode (or does it make AssemblyLanguage for gas?).

CategoryCompilers