This forum is designated JDK Open Source. How is the open sourcing of Java going to affect run-time or binary distribution of the various flavours of the Java Platform?
> How does making it easier for people to create and deploy incompatible JVMs reduce the number of incompatibillities?
This is not what I said.
We could reduce the incompatibilities, for example, by providing means for people to make sure their implementation is compatible.
Hmm, you must be talking about having a set of compatibility tests for folks to use.
> Anyway, hopefully we will be able to reduce these
> incompatibilities with Sun's implementaition being
> open sources..
How does making it easier for people to create and deploy incompatible JVMs reduce the number of incompatibillities?
In the past you had to create an entire runtime and compiler from scratch, soon all you have to do is change a few lines of code, pack it up, and ship it out.
I guess in theory it will make it easier to understand the behavior of the Reference implementation. Instead of testing something with code to understand it or writing someone an email to get a better idea you can read the code and figure out what the intent of an obscure method. Though as you point out there is a flip side to that as well, someone could read the intent and decide that it needs to be something else.
Interestingly enough when I converted a python project to jython, the author of the original project didn't consider the software to be a version of the original but an entirely different product. Oddly though I didn't perceive this to be the case.
> It will most likely result in an ugly multitude of mutually incompatible JVMs, each requiring classfiles compiled with their own compilers which may or may not be compatible at a language level.
How is this different from what we have now with major linux distributions shipping non-compatible "free" runtimes (and while they don't claim themselves as Java, they are the ones used by default when you type 'java' at the command prompt)?
I suppose a distinguisher from the situation you've outlined with:
'How is this different from what we have now with major linux distributions shipping non-compatible "free" runtimes (and while they don't claim themselves as Java, they are the ones used by default when you type 'java' at the command prompt)?'
would be that they may be called "Java", as in the product is. A command line invocation and a total product are different. If you were to go and look at what the 'java' was invoking you could make out that the product wasn't "Java". But if the product was called "Java" upon analysis the user could find themselves confused. Maybe they would ask a question such as "Why does my Java 6 compiled class file run ok on this Linux distro but over here on Solaris it crashes the VM because the byte-code verifier is vetoing the execution". yuck. I have no idea if this would ever happen.
That's correct. The code from Kaffe's CVS head returns
topic@amy:~/projects/build-kaffe$ /tmp/kaffe-classpath-zip/bin/java -version
java full version "kaffe-1.4.2"
kaffe VM "1.1.8-pre"
Copyright (c) 1996-2006 Kaffe.org project contributors (please see
the source code for a full list of contributors). All rights reserved.
Portions Copyright (c) 1996-2002 Transvirtual Technologies, Inc.
Yeah, but imagine a user who tries to run his java application after he updated his linux distribution by using "java" command he has in his path, and finds that his application no longer works!
I have a benefit of not having to imagine such users, I've seen bugs filed against us with GCJ's stacktraces =)
My point is, the user has some compatibility expectations about "java" app in his path. In this case they were broken. The user didn't care that "java -version" didn't say that it's JavaTM.
In this sense, I think, we already have an incompatible implementation.
Anyway, hopefully we will be able to reduce these incompatibilities with Sun's implementaition being open sources..
'I have a benefit of not having to imagine such users, I've seen bugs filed against us with GCJ's stacktraces =)'
though odd, I can believe it. Ive seen bugs posted for SWT in the database before and Ive been mystified as to why their there. I guess this goes to show that for some users Java is Sun, Sun is Java.
I think the answer to your question is yes, there will still be a distinction between the JDK and JRE. We don't have any plans to merge them all into one melting pot. :-)
This forum is all about open source for Sun's Java SE technologies since we'll be open sourcing the JDK and JRE in early calendar year 2007. Of course feel free to talk about non-Sun implementations as well -- we may not be able to answer all the questions, but others may be able to help.
As for the Java ME technologies, I assume they will remain separate as well. You'll be hearing more about open source Java ME in the next few months. Stay tuned.
I just asked a bunch of experts that question
and got a variety of different answers based on
how they interpreted what you mean....
Can you please clarify?
Paul: I was on the call when Tom asked us. Specifically, what do you mean by "various flavors"?
Currently, one has a differentiation between the JDK, as you download it from Sun, and the run-time platform (J2SE, J2ME etc). If you go to the java.sun.com web site you are given the choice of the JDK or the JRE to download, so my question initially refers to that JRE i.e. is this forum discussing the JRE as well?
By various platforms, I mean not just the PC version but the various J2ME + class library combinations.
Does that clarify?
It will most likely result in an ugly multitude of mutually incompatible JVMs, each requiring classfiles compiled with their own compilers which may or may not be compatible at a language level.
Think back to the bad old days of the 1980s, with software being written that had to be not just compiled on and tested on, but partially rewritten for, each of dozens of platforms.
Now multiply that by an order of magnitude and you have what Java may end up to be in a few years (at most) if Sun isn't extremely careful (and from what I read it seems like they're not seriously considering the consequences of their actions in this).
This just isn't going to be the case. While people could and probably will go and make some wacky J#GTK/QT$ version of the language it won't be Java. There has been no talk of freeing up the rights to the â€œJavaâ€ name. Anyone who is going to go threw the hassle of making a serious version is going to worry about compatibility. Anyone not making a serious version, well, why worry about that?
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.