|
Replies:
15
-
Last Post:
Aug 18, 2006 2:46 PM
by: leouser
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
How does this effect run-time?
Posted:
Aug 15, 2006 8:53 AM
|
|
|
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?
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 15, 2006 11:24 AM
in response to: paulbristow
|
|
|
Paul:
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?
Thanks!
--Tom
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 15, 2006 3:46 PM
in response to: tmarble
|
|
|
Paul: I was on the call when Tom asked us. Specifically, what do you mean by "various flavors"?
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 16, 2006 12:50 AM
in response to: robogeek
|
|
|
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?
Paul
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 16, 2006 5:23 AM
in response to: paulbristow
|
|
|
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).
|
|
|
|
|
|
|
|
|
Doomsday forking.
Posted:
Aug 16, 2006 6:14 AM
in response to: jwenting
|
|
|
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?
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 16, 2006 1:10 PM
in response to: jwenting
|
|
|
> 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)?
Thanks,
Dmitri
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 16, 2006 1:20 PM
in response to: trembovetski
|
|
|
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.
leouser
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 16, 2006 3:44 PM
in response to: leouser
|
|
|
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.
[snip]
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 16, 2006 4:48 PM
in response to: robilad
|
|
|
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..
Thanks,
Dmitri
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 16, 2006 4:56 PM
in response to: trembovetski
|
|
|
'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.
leouser
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 17, 2006 11:04 PM
in response to: trembovetski
|
|
|
>
> 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.
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 18, 2006 10:05 AM
in response to: jwenting
|
|
|
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.
leouser
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 18, 2006 2:03 PM
in response to: jwenting
|
|
|
> 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.
Dmitri
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 18, 2006 2:46 PM
in response to: trembovetski
|
|
|
Hmm, you must be talking about having a set of compatibility tests for folks to use.
leouser
|
|
|
|
|
|
|
|
|
Re: How does this effect run-time?
Posted:
Aug 16, 2006 6:36 PM
in response to: paulbristow
|
|
|
Hi Paul,
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.
-Ray
|
|
|
|
|
java.net RSS
