Re: Canonical Will Remove Java From Ubuntu
On 10:41 Thu 22 Dec , Paul Howarth wrote: On Thu, 22 Dec 2011 09:17:15 + Andrew Haley a...@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 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Canonical Will Remove Java From Ubuntu
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 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Canonical Will Remove Java From Ubuntu
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 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Canonical Will Remove Java From Ubuntu
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). -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?
On 13:12 Fri 04 Nov , Tom Lane wrote: I have been looking into replacing Fedora's obsolete version of libpng (1.2.x release series) with something more modern. The possible choices are the 1.4.x and 1.5.x release series. The 1.5.x series adds some more features that 1.4.x did not have, but it also poses significantly more migration problems. The reason is that 1.5.x no longer exposes the contents of the library's internal png_info struct. Direct access to fields of png_info has been deprecated for a long time, in favor of using accessor functions, but up through 1.4 you can get away with it. I did test rebuilds in mock of all rawhide packages that are reported to be dependent on libpng. Out of 964 packages with dependencies on libpng, we have: Packages that rebuilt successfully with 1.5 658 Packages that FTBFS for non-libpng reasons186 Packages that rebuilt with 1.4, but not 1.5 74 Packages that need help even with 1.4 46 (The non-libpng failures seem to mostly be due to the recent upgrade to glib 2.0. Some of those probably have libpng issues as well, but didn't get far enough in their builds to expose them.) About half of the need help anyway group may just need their BuildRequires to be rebuilt first --- it looked like they had no source-code dependency, but were just absorbing -lpng12 from library link flags reported by other packages. I built each package independently rather than trying to chain the builds, so this wasn't catered for. The vast majority of the 74 packages that would need extra work if we move to libpng 1.5 are trying to access the png_info struct directly, and so would need patches to use the accessor functions instead. This is work that should be done and upstreamed anyway, but if we move to 1.4 we would not have to do it Right Now. It looks like it would be a fairly large amount of work, too --- I count 1164 incomplete type failures in the build logs for those packages, and it's quite likely there are more in source files that the build runs didn't get to. On the other hand, if we move to 1.4 there will not be any pressing reason for these fixes to get made, and so I'm not sure that we'll be any better off when we try to move to 1.5 later. Another point is that we'd have to build these same 964 packages over again if we plan a two-stage upgrade. Any opinions on which way to jump? In either case, as per the discussion at http://lists.fedoraproject.org/pipermail/devel/2011-October/157712.html I plan to provide the 1.2.x libpng shared library (and only the library, not its devel support files) in a libpng-compat subpackage for the time being. So existing programs that depend on 1.2.x will continue to work, but it won't be possible to rebuild a package that has source-level dependencies on 1.2.x until those are fixed. I think this is enough to avoid needing a special build tag for staging the rebuilds. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel FYI, Gentoo already went to libpng 1.5 and so have patches floating around for a lot of stuff that breaks. A lot of the issues I found when rebuilding against 1.5 was the hardcoding in libtool files rather than any source code issues, which means they have to rebuilt in the right order (e.g. a high-level GNOME package doesn't build because one of its dependencies hasn't been rebuilt and it still has the old -lpng12 hardcoded). We already fixed IcedTea/OpenJDK to work with libpng 1.5 as a result of Gentoo's work, and those packages should already be in Fedora. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug in javac ?
On 16:48 Mon 31 Oct , Andrew Haley wrote: Am 31.10.2011 17:00, schrieb Deepak Bhole: It looks like a known bug in the 6 compiler related to interface inheritance and covariant return types. I think this is the commit that fixed it in 7: http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/4a3b9801f7a0 If you have code that resembles the above and would like to see the fix backported to 6, please feel free to open a bug. Thanks. Bug is open (#750301) This one should be submitted to the tools people @ Oracle rather than just patched into Icedtea, I think. Their input might avoid us breaking anything. It's worth a try, but they've been pretty unhelpful in the past. The OpenJDK6 toolset is a mess (being some fairly random point in the development of the 7 compiler) and their main contribution has being to break the TCK run. On that note, a good initial test for this would be to see if the patched version passes the TCK. Then post to compiler-dev and jdk6-dev. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: java-1.7.0-openjdk breaks java detection in LibreOffice?
On 19:58 Wed 26 Oct , Heiko Adams wrote: Am 26.10.2011 19:06, schrieb Jared K. Smith: On Wed, Oct 26, 2011 at 12:50 PM, Heiko Adams fedora-upda...@heiko-adams.de wrote: is it just me or is java-1.7.0-openjdk breaking LibreOffice java detection? Sounds like it might be related to bug 748585. That would explain why java-1.7.0 isn't found by LO but not why java-1.7.0 hides java-1.6.0. But on the other hand java-1.7.0 is just some kind of technical preview. No it isn't. 1.7 has been released and is final. http://blogs.oracle.com/javase/entry/java_7_has_released Regards, Heiko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Java 7 for Fedora 16
On 10:55 Fri 29 Jul , Deepak Bhole wrote: * Omair Majid oma...@redhat.com [2011-07-29 10:32]: On 07/25/2011 04:04 PM, Deepak Bhole wrote: * Bill Nottinghamnott...@redhat.com [2011-07-25 15:54]: Toshio Kuratomi (a.bad...@gmail.com) said: Robyn and I have talked about how the feature process could be adapted to allow for more late work to occur however none of that talk has turned into anything solid yet. One point that bears on this is that the Feature Owners must be willing to commit to doing all the work involved in coordination when they submit something late. In other words, if Java 7 update went in well before the feature deadline, the expectation would be that packagers whose packages depended on Java would need to adapt to Java 7. The expectation now that the Feature Freeze has passed is that the people pushing Java 7 into the repos would also need to seek out and fix all the packages that depend on them that are broken. Would we actually be shipping only 7, or both 6 and 7? This hasn't been debated yet, but I am very much in favour of having only 7 in Fedora 16. If the reason for asking was w.r.t re-builds, it is unlikely that most applications will need a rebuild -- only those using deprecated APIs (which would have been deprecated for years now) and private APIs would be affected. That would likely be a small subset. Have you seen the list of incompatibilities? http://www.oracle.com/technetwork/java/javase/compatibility-417013.html Thanks. I hadn't seen the full list, but I knew it'd fairly small given how much importance compatibility has been given in the past and for 7. Unfortunately it is not possible to gauge how much Fedora will be affected by that :/ My biggest concern would be for apps using sun.* APIs. As mentioned above though, it should be a small percentage. The old com.sun jpeg libraries would be the obvious ones to spring to mind. Whatever list Oracle has come up with doesn't really compare to real-world use and testing. I think we should offer both in F16. Cheers, Deepak -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 07:41 Thu 04 Nov , Ralf Corsepius wrote: snip... As a maintainer, abrt to me primarily means wading through wakes of hardly readable emails, mostly to scan them for useful information. I many cases I ended up with closing BZ, because these emails did not contain sufficient info. That said, as a maintainer, abrt to me only has introduced a higher noise/signal ratio in bugreports as before. This is the problem we have with java-1.6.0-openjdk, except it's magnified by the fact that the user could be running *ANYTHING* on the JVM. So if some native code in a Java application crashes the JVM, we get an abrt bug report for it. The information provided is pretty much always useless for diagnosing the issue. The attached crash report is pretty incomprehensible for the JVM. Including the hs_err_pid.log generated by the JVM would at least be a start in making it easier to see what the failure was. But the main problem is that there is pretty much no way of reproducing most of these crashes and the user often has no clue what happened. We're getting lots of these, on a daily basis, which means that proper bug reports (i.e. ones filed by users who actually took the time to file a bug report with some useful information) are getting swamped by these abrt reports and our valuable time is being wasted. Please turn these off for this package until such a time as the default abrt report is actually useful for some form of diagnosis, which means it at least has an hs_err file and mandatory reproducer information. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 17:54 Thu 04 Nov , Frank Murphy wrote: On 04/11/10 17:51, Dr Andrew John Hughes wrote: This is the problem we have with java-1.6.0-openjdk, except it's magnified by the fact that the user could be running *ANYTHING* on the JVM. So if some native code in a Java application crashes the JVM, we get an abrt bug report for it. snip Please turn these off for this package until such a time as the default abrt report is actually useful for some form of diagnosis, which means it at least has an hs_err file and mandatory reproducer information. Then step up and work with the abrt devs, tell them what you need. Don't shoot the messenger, help improve the message I just have. And not for the first time. -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 19:06 Thu 04 Nov , Jiri Moskovcak wrote: On 11/04/2010 06:56 PM, Dr Andrew John Hughes wrote: On 17:54 Thu 04 Nov , Frank Murphy wrote: On 04/11/10 17:51, Dr Andrew John Hughes wrote: This is the problem we have with java-1.6.0-openjdk, except it's magnified by the fact that the user could be running *ANYTHING* on the JVM. So if some native code in a Java application crashes the JVM, we get an abrt bug report for it. snip Please turn these off for this package until such a time as the default abrt report is actually useful for some form of diagnosis, which means it at least has an hs_err file and mandatory reproducer information. Then step up and work with the abrt devs, tell them what you need. Don't shoot the messenger, help improve the message I just have. And not for the first time. Speaking of JVM - I already tried to contact the JVM maintainers (http://lists.fedoraproject.org/pipermail/java-devel/2010-October/003957.html) I can blacklist jvm before we figure this out, but I'm afraid, that by silencing ABRT the whole JVM+ABRT problem will just go off the radar... Yes, this thread is what I was referring to. If you're happy with /var/log/openjdk as a location for error logs, I can look at adding this option upstream. But this would take time to appear in the java-1.6.0-openjdk packages and presumably for the abrt side to be worked out too. In the meantime, we should consider turning off ABRT for OpenJDK until fixes on both the abrt and OpenJDK side have trickled through to end users. Jirka -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Java3D?
On 12:53 Sun 17 Oct , Eric Smith wrote: Has anyone worked on packaging Java3D for Fedora? Or is there any reason that it wouldn't be acceptable for inclusion in Fedora? I haven't really looked into packaging Java3D yet, but I want to package ReplicatorG, which is used to control 3D printers such as the MakerBot and RepRap, and it depends on Java3D. If no one else is working on packaging it, I'm willing to give it a try. Thanks, Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel It at least now looks like the license is suitable for Fedora; GPLv2 + Classpath exception for the core, and BSD for vecmath and the utilities, along with the MIT license on some headers: https://j3d-core.dev.java.net/ -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
