On Sun, Dec 18, 2011 at 12:54 PM, Neal Becker ndbecker2@gmail.com wrote:
So? They are removing the non free Sun JDK ... which we never shipped.
drago01 wrote:
On Sun, Dec 18, 2011 at 12:54 PM, Neal Becker ndbecker2@gmail.com wrote:
So? They are removing the non free Sun JDK ... which we never shipped.
Sorry, I was confused - shouldn't post so early in the morning.
On Sun, Dec 18, 2011 at 11:54 AM, Neal Becker ndbecker2@gmail.com wrote:
Actually that's not entirely correct. They're removing the Sun Java closed source variant due to changes in licensing from Oracle preventing them from shipping security fixes. They also ship OpenJDK which is the open source release of the Java JDK as shipped in Fedora and that will continue to be available and its completely compatible with the Sun variant as its mostly based on the same code. I personally think its a good thing.
See their press release with the full details https://lwn.net/Articles/472466/
Also this is completely off topic for this list.
Peter
Peter Robinson wrote:
Actually that's not entirely correct. They're removing the Sun Java closed source variant due to changes in licensing from Oracle preventing them from shipping security fixes. They also ship OpenJDK which is the open source release of the Java JDK as shipped in Fedora and that will continue to be available and its completely compatible with the Sun variant as its mostly based on the same code. I personally think its a good thing.
See their press release with the full details https://lwn.net/Articles/472466/
What I don't understand is why they're replacing the packages with empty packages rather than just dragging in OpenJDK as an upgrade, which IMHO would be much less disruptive.
Kevin Kofler
On 12/20/2011 05:48 PM, Kevin Kofler wrote:
Peter Robinson wrote:
Actually that's not entirely correct. They're removing the Sun Java closed source variant due to changes in licensing from Oracle preventing them from shipping security fixes. They also ship OpenJDK which is the open source release of the Java JDK as shipped in Fedora and that will continue to be available and its completely compatible with the Sun variant as its mostly based on the same code. I personally think its a good thing.
See their press release with the full details https://lwn.net/Articles/472466/
What I don't understand is why they're replacing the packages with empty packages rather than just dragging in OpenJDK as an upgrade, which IMHO would be much less disruptive.
Probably because OpenJDK and SunJDK aren't really that compatible. I keep running into all kinds of software the will not run with the OpenJDK. This is one of the reasons why I'm not particularly fond of Java as a Platform. It was supposed to be "write once run anywhere" but that is not the case in practice. Luckily Oracle will deem OpenJDK the official JDK with the next major release so hopefully things will improve with that.
I guess the Ubuntu people decided that making users consciously replace the JDK is better then to silently replace it and get all kinds of bug reports about java software behaving in strange ways.
Regards, Dennis
On 20.12.2011 19:30, Dennis Jacobfeuerborn wrote:
Probably because OpenJDK and SunJDK aren't really that compatible.
I am afraid that most of these problems are caused by stupid developers who are using (against all advices they were given) com.sun.* classes (which I am said is the most common source of problems). There is no protection against stupid programmers, I am afraid.
While I am looking over the shoulder of my JBoss colleague sitting next to me, I don't see much problems (of course, bugs happen) with running even so large application as JBoss AS on OpenJDK.
Also, on the theme of stupid programmers, see https://bugzilla.redhat.com/show_bug.cgi?id=741821 (although I am not sure where the stupidity lies in this issue).
Matěj
On 18:09 Wed 21 Dec , Matej Cepl wrote:
On 20.12.2011 19:30, Dennis Jacobfeuerborn wrote:
Probably because OpenJDK and SunJDK aren't really that compatible.
I am afraid that most of these problems are caused by stupid developers who are using (against all advices they were given) com.sun.* classes (which I am said is the most common source of problems). There is no protection against stupid programmers, I am afraid.
I agree use of com.sun.* is annoying (and it now has an explicit warning with OpenJDK7's javac) but these classes do exist in OpenJDK.
While I am looking over the shoulder of my JBoss colleague sitting next to me, I don't see much problems (of course, bugs happen) with running even so large application as JBoss AS on OpenJDK.
Also, on the theme of stupid programmers, see https://bugzilla.redhat.com/show_bug.cgi?id=741821 (although I am not sure where the stupidity lies in this issue).
With whoever decided /etc/.java was a good idea... :-)
Matěj
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 12/21/2011 10:45 PM, Dr Andrew John Hughes wrote:
On 18:09 Wed 21 Dec , Matej Cepl wrote:
Also, on the theme of stupid programmers, see https://bugzilla.redhat.com/show_bug.cgi?id=741821 (although I am not sure where the stupidity lies in this issue).
With whoever decided /etc/.java was a good idea... :-)
/etc/.java could be a symlink to /etc/java
Rahul
Le Mer 21 décembre 2011 19:22, Rahul Sundaram a écrit :
On 12/21/2011 10:45 PM, Dr Andrew John Hughes wrote:
On 18:09 Wed 21 Dec , Matej Cepl wrote:
Also, on the theme of stupid programmers, see https://bugzilla.redhat.com/show_bug.cgi?id=741821 (although I am not sure where the stupidity lies in this issue).
With whoever decided /etc/.java was a good idea... :-)
/etc/.java could be a symlink to /etc/java
Assuming that works (some jvm was not symlink-proof in the past)
On 12/21/2011 05:09 PM, Matej Cepl wrote:
On 20.12.2011 19:30, Dennis Jacobfeuerborn wrote:
Probably because OpenJDK and SunJDK aren't really that compatible.
Well, hold on. Both the proprietary JDK and OpenJDK meet the specification, and we try very hard to be compatible with all the things that Java programmers assume. And we fix compatibility bugs if we can.
I am afraid that most of these problems are caused by stupid developers who are using (against all advices they were given) com.sun.* classes (which I am said is the most common source of problems). There is no protection against stupid programmers, I am afraid.
There really is very little difference between the com.sun.* classes in OpenJDK and the proprietary JDK, as far as I know. Of course, I haven't really checked, but... ;-)
Andrew.
On 21.12.2011 18:52, Andrew Haley wrote:
There really is very little difference between the com.sun.* classes in OpenJDK and the proprietary JDK, as far as I know. Of course, I haven't really checked, but... ;-)
So, what is the root cause of (infrequent, but persistent) alarms about incompatibility between OpenJDK and proprietary JDK?
Matěj
On 12/21/2011 10:45 PM, Matej Cepl wrote:
On 21.12.2011 18:52, Andrew Haley wrote:
There really is very little difference between the com.sun.* classes in OpenJDK and the proprietary JDK, as far as I know. Of course, I haven't really checked, but... ;-)
So, what is the root cause of (infrequent, but persistent) alarms about incompatibility between OpenJDK and proprietary JDK?
To know for certain I'd have to trawl all the bug reports, but they seem to boil down to web plugin incompatibilities and assuming a particular layout of the installation. With regard to the plugin, it's much more compatible now, but we still have occasional problems with proprietary applications that make incorrect assumptions. It's particularly difficult with banks that have applications we can't even try. Oh, and we do have bugs sometimes. ;-)
Andrew.
On Thu, 22 Dec 2011 09:17:15 +0000 Andrew Haley aph@redhat.com wrote:
On 12/21/2011 10:45 PM, Matej Cepl wrote:
On 21.12.2011 18:52, Andrew Haley wrote:
There really is very little difference between the com.sun.* classes in OpenJDK and the proprietary JDK, as far as I know. Of course, I haven't really checked, but... ;-)
So, what is the root cause of (infrequent, but persistent) alarms about incompatibility between OpenJDK and proprietary JDK?
To know for certain I'd have to trawl all the bug reports, but they seem to boil down to web plugin incompatibilities and assuming a particular layout of the installation. With regard to the plugin, it's much more compatible now, but we still have occasional problems with proprietary applications that make incorrect assumptions. It's particularly difficult with banks that have applications we can't even try. Oh, and we do have bugs sometimes. ;-)
At $WORKPLACE I use a Java app (via javaws) - EMC NetWorker Management Console - that won't work with OpenJDK (it pops up a username/password window as expected but doesn't then pop up the main app window once the username+password have been entered), whilst it does work with Sun/Oracle java 6 and 7. I would much rather use OpenJDK but I haven't a clue how to track down what the problem is, knowing next to nothing about java.
Paul.
On 22/12/11 10:41, Paul Howarth wrote:
At $WORKPLACE I use a Java app (via javaws) - EMC NetWorker Management Console - that won't work with OpenJDK (it pops up a username/password window as expected but doesn't then pop up the main app window once the username+password have been entered), whilst it does work with Sun/Oracle java 6 and 7. I would much rather use OpenJDK but I haven't a clue how to track down what the problem is, knowing next to nothing about java.
Paul.
You would need to see what classes are imported. They are probably specific to Oracle JDK. Usually the top lines in a *.java src.
In order to get the same functionality, someone would need to implement that in a "lets not get sued class"
On Thu, Dec 22, 2011 at 10:52:13AM +0000, Frank Murphy wrote:
On 22/12/11 10:41, Paul Howarth wrote:
At $WORKPLACE I use a Java app (via javaws) - EMC NetWorker Management Console - that won't work with OpenJDK (it pops up a username/password window as expected but doesn't then pop up the main app window once the username+password have been entered), whilst it does work with Sun/Oracle java 6 and 7. I would much rather use OpenJDK but I haven't a clue how to track down what the problem is, knowing next to nothing about java.
Paul.
You would need to see what classes are imported. They are probably specific to Oracle JDK. Usually the top lines in a *.java src.
Source is often not available. Is there a website or anything related to getting stuff working with OpenJDK? The software I use works fine with Oracle Java, but fails with http://fpaste.org/Ybkj/ on any OpenJDK.
On 10:41 Thu 22 Dec , Paul Howarth wrote:
On Thu, 22 Dec 2011 09:17:15 +0000 Andrew Haley aph@redhat.com wrote:
On 12/21/2011 10:45 PM, Matej Cepl wrote:
On 21.12.2011 18:52, Andrew Haley wrote:
There really is very little difference between the com.sun.* classes in OpenJDK and the proprietary JDK, as far as I know. Of course, I haven't really checked, but... ;-)
So, what is the root cause of (infrequent, but persistent) alarms about incompatibility between OpenJDK and proprietary JDK?
To know for certain I'd have to trawl all the bug reports, but they seem to boil down to web plugin incompatibilities and assuming a particular layout of the installation. With regard to the plugin, it's much more compatible now, but we still have occasional problems with proprietary applications that make incorrect assumptions. It's particularly difficult with banks that have applications we can't even try. Oh, and we do have bugs sometimes. ;-)
At $WORKPLACE I use a Java app (via javaws) - EMC NetWorker Management Console - that won't work with OpenJDK (it pops up a username/password window as expected but doesn't then pop up the main app window once the username+password have been entered), whilst it does work with Sun/Oracle java 6 and 7. I would much rather use OpenJDK but I haven't a clue how to track down what the problem is, knowing next to nothing about java.
While OpenJDK is mostly the same codebase as the proprietary Oracle JDK (and, in fact, is the reference JDK for 7), the plugin and javaws are not part of OpenJDK. Sun never released the source code for these and they aren't part of the compatibility test suite (TCK).
The packages in Fedora and other distros are thus an independent implementation developed primarily by developers at Red Hat in a project called IcedTea-Web:
http://icedtea.classpath.org/wiki/IcedTea-Web
Fixing incompatibilities between this and the proprietary implementation is a matter of finding issues and doing our best to fix them. In this, the help of users is of great importance and we'd appreciate bug reports at http://icedtea.classpath.org/bugzilla, with as many details as possible.
As Andrew Haley implies, there are some issues where we can't reproduce the fault. Your case would appear to be one of them, as we would not have a username and password to enter into the app. This is also true of many banking sites.
Paul.
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
* Paul Howarth paul@city-fan.org [2011-12-22 05:41]:
On Thu, 22 Dec 2011 09:17:15 +0000 Andrew Haley aph@redhat.com wrote:
On 12/21/2011 10:45 PM, Matej Cepl wrote:
On 21.12.2011 18:52, Andrew Haley wrote:
There really is very little difference between the com.sun.* classes in OpenJDK and the proprietary JDK, as far as I know. Of course, I haven't really checked, but... ;-)
So, what is the root cause of (infrequent, but persistent) alarms about incompatibility between OpenJDK and proprietary JDK?
To know for certain I'd have to trawl all the bug reports, but they seem to boil down to web plugin incompatibilities and assuming a particular layout of the installation. With regard to the plugin, it's much more compatible now, but we still have occasional problems with proprietary applications that make incorrect assumptions. It's particularly difficult with banks that have applications we can't even try. Oh, and we do have bugs sometimes. ;-)
At $WORKPLACE I use a Java app (via javaws) - EMC NetWorker Management Console - that won't work with OpenJDK (it pops up a username/password window as expected but doesn't then pop up the main app window once the username+password have been entered), whilst it does work with Sun/Oracle java 6 and 7. I would much rather use OpenJDK but I haven't a clue how to track down what the problem is, knowing next to nothing about java.
Hi Paul,
Is there a bug open for this?
Deepak
Paul.
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 12/22/2011 08:50 AM, Deepak Bhole wrote:
At $WORKPLACE I use a Java app (via javaws) - EMC NetWorker Management Console - that won't work with OpenJDK (it pops up a username/password window as expected but doesn't then pop up the main app window once the username+password have been entered), whilst it does work with Sun/Oracle java 6 and 7. I would much rather use OpenJDK but I haven't a clue how to track down what the problem is, knowing next to nothing about java.
When was the last time you tried, this sounds like the same problem we had and is fixed at https://bugzilla.redhat.com/show_bug.cgi?id=677772
"NoSuchAlgorithmException using SSL/TLS in javaws"
Our application did not work because when loggin in SSL was required
Hi Paul,
Is there a bug open for this?
Deepak
Paul.
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 12/22/2011 10:41 AM, Paul Howarth wrote:
At $WORKPLACE I use a Java app (via javaws) - EMC NetWorker Management Console - that won't work with OpenJDK (it pops up a username/password window as expected but doesn't then pop up the main app window once the username+password have been entered), whilst it does work with Sun/Oracle java 6 and 7. I would much rather use OpenJDK but I haven't a clue how to track down what the problem is, knowing next to nothing about java.
We will try to fix this if we can get enough information.
FWIW -- and you may be surprised by this -- javaws and the browser plugin aren't part of Java Platform, Standard Edition (Java SE) or of OpenJDK but are a different project (IcedTea-Web) altogether.
We have had very few compatibility issues with Java SE itself.
Andrew.
On 12/21/2011 06:52 PM, Andrew Haley wrote:
On 12/21/2011 05:09 PM, Matej Cepl wrote:
On 20.12.2011 19:30, Dennis Jacobfeuerborn wrote:
Probably because OpenJDK and SunJDK aren't really that compatible.
Well, hold on. Both the proprietary JDK and OpenJDK meet the specification, and we try very hard to be compatible with all the things that Java programmers assume. And we fix compatibility bugs if we can.
I wasn't saying that this was the fault of people involved in OpenJDK. The problem is that the applications rely on behavior that is part of the platform but not mentioned in the specifications. You cannot expect different implementations to behave the same way when it comes to things that weren't specified in the first place.
I am afraid that most of these problems are caused by stupid developers who are using (against all advices they were given) com.sun.* classes (which I am said is the most common source of problems). There is no protection against stupid programmers, I am afraid.
There really is very little difference between the com.sun.* classes in OpenJDK and the proprietary JDK, as far as I know. Of course, I haven't really checked, but... ;-)
The more important question is if Sun didn't want people to use the com.sun.* classes then why did they include them in the platform?
In my opinion the root cause for these incompatibilities is that the platform simply isn't defined well. If you want to make good on the claim "write once run anywhere" then you actually have to make an effort to come up with a robust core. Injecting vendor specific stuff in there is pretty much doing the opposite of that.
Regards, Dennis
On 14:12 Thu 22 Dec , Dennis Jacobfeuerborn wrote:
On 12/21/2011 06:52 PM, Andrew Haley wrote:
On 12/21/2011 05:09 PM, Matej Cepl wrote:
On 20.12.2011 19:30, Dennis Jacobfeuerborn wrote:
Probably because OpenJDK and SunJDK aren't really that compatible.
Well, hold on. Both the proprietary JDK and OpenJDK meet the specification, and we try very hard to be compatible with all the things that Java programmers assume. And we fix compatibility bugs if we can.
I wasn't saying that this was the fault of people involved in OpenJDK. The problem is that the applications rely on behavior that is part of the platform but not mentioned in the specifications. You cannot expect different implementations to behave the same way when it comes to things that weren't specified in the first place.
Yes, we know this from experience working on gcj/GNU Classpath. But OpenJDK and the proprietary Oracle JDK are (according to Sun/Oracle) ~96% the same code.
I am afraid that most of these problems are caused by stupid developers who are using (against all advices they were given) com.sun.* classes (which I am said is the most common source of problems). There is no protection against stupid programmers, I am afraid.
There really is very little difference between the com.sun.* classes in OpenJDK and the proprietary JDK, as far as I know. Of course, I haven't really checked, but... ;-)
The more important question is if Sun didn't want people to use the com.sun.* classes then why did they include them in the platform?
Assuming you mean 'platform' as in http://docs.oracle.com/javase/7/docs/api/ they didn't.
There *has* to be some classes that aren't part of the API to actually make things work (e.g. providing implementation of services provided by the API). You'll find just the same thing in the gnu.* namespace for GNU Classpath & gcj.
In my opinion the root cause for these incompatibilities is that the platform simply isn't defined well. If you want to make good on the claim "write once run anywhere" then you actually have to make an effort to come up with a robust core. Injecting vendor specific stuff in there is pretty much doing the opposite of that.
Seems pretty well defined to me.
Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, Dec 21, 2011 at 06:09:57PM +0100, Matej Cepl wrote:
On 20.12.2011 19:30, Dennis Jacobfeuerborn wrote:
Probably because OpenJDK and SunJDK aren't really that compatible.
I am afraid that most of these problems are caused by stupid developers who are using (against all advices they were given) com.sun.* classes (which I am said is the most common source of problems). There is no protection against stupid programmers, I am afraid.
It has *ALWAYS* been the case that you weren't supposed to use anything outside of java[x].* in application code, that it was implementation detail up in thar and subject to change without notice.
On 06:54 Sun 18 Dec , Neal Becker wrote:
http://lxer.com/module/newswire/ext_link.php?rid=159737
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Saw this on LWN. It's because of Oracle licensing changes and may actually mean more users of OpenJDK and IcedTea-Web instead of the proprietary solution (though in all likelihood, they'll just download it from java.sun.com instead).