Re: How Sun makes money from Java since it develops it and gives to everybody for free?

John T wrote:

[...] if Eclipse uses its own
compiler, which obviously it does, how can we be guaranteed that if a
program is written for JDK1.6 and Eclipse compiles it sucessfully that
it would run from the command line just using the proper CLASSPATH
variable with a java my_program command?

There is always a possibility of bugs, of course, but the chance of that
causing serious problems should be fairly slim. There are several reasons...

One is that what we call the Java "compiler" is actually a /translator/ -- it
converts from one high-level, OO, language (called "Java") to another, very
similar, high-level, OO, language (called "JVM bytecode"). Those two languages
are both pretty well specified, and the mapping between them is also fairly
well tied down by the specs, so there isn't that much room for interpretation.
And, since they are so /very/ similar, there isn't a lot of room for error
either. (BTW, when I say, "very similar" I mean more similar than C and Pascal
are to each other, for instance). The Java spec has become pretty complicated
over the years, but most of the bugs in javac or Eclipse seem to be (and have
been) in the type-checking parts (which are the most complicated), and errors
there don't usually have any effect at runtime. That's to say: the JDK
compiler and the Eclipse compiler might disagree on whether some code was legal
at all, but if they both were willing to compile it then they would probably
produce equivalent results.

Secondly, the Eclipse people have quite a lot of time to study upcoming Sun
releases and (presumably) plenty of opportunity to talk to the people at Sum.
And vice versa. So there should be a fair degree of agreement between the two
teams -- remember, they are not in competition with each other.

Lastly, since Eclipse uses Sun's (or whoever's) JVM as the runtime for the code
you create and test, it doesn't really matter very much if they differ. You
will, presumably, test your code on the kind(s) of JVM that your users will
have, or onto which you will deploy your webservers. So, provided the tests
work, you have a reasonable assurance of safety. Of course, if you expect to
be shipping your code to run on a variety of different JVMs then you should
expand your testing program -- but there's nothing new about that... You
aren't going to be shipping Java source to your customers (usually) so it
doesn't matter whether the bytecode you ship depends in some obscure way on the
compiler you use to generate it -- what matters is whether that bytecode will
run the same on the customers' JVMs as it does in your testing environment.

-- chris



.

Relevant Pages

  • Re: Java question
    ... Thats correct, however as I stated, you loose all the standard stuff that comes with a JVM and you loose the capability to have a runtime that behaves similar and can be tuned and parameterized similar to other platforms. ... Or when classes are used among multiple JVMs, in addition to the shared classloader cache having a shared JIT cache would likely have its benefits. ... Subject: Java question ... expect this to be the very same version of the compiler, ...
    (bit.listserv.ibm-main)
  • Re: A question related to type casting
    ... public int __specialised_get{ ... the code you posted might work fine for that very specific example (if you somehow convince Java to actually successfully break its own rules to generate code like that). ... The JVM is allowed to do all kinds of optimizations at run time that have nothing to do with what the compiler conceptually does, as long as in practice it gives results consistent with the specified program. ...
    (comp.lang.java.programmer)
  • Re: A Nice functional language
    ... on a client machine because it does not have the right JIT, ... ANY and ALL JVM. ... So if the Nice compiler is to support it on all ... and the interoperability with Java would suffer. ...
    (comp.lang.functional)
  • Re: HashMap get/put
    ... The Java compiler emits an invokevirtual opcode even for a final ... The JVM itself, of course, is free to optimize anything as it sees fit, ... How the JIT handles those semantics is ...
    (comp.lang.java.programmer)
  • Re: Java question
    ... at the will of the programmer instead of at the will of the JVM. ... recognize pre-compiled java class files. ... JIT compiled machine code version today? ... expect this to be the very same version of the compiler, ...
    (bit.listserv.ibm-main)