[arch-dev-public] Java on archlinux
As some people have noticed, I put a lot of effort in getting a free java runtime and SDK on archlinux, using GNU java, Eclipse-ecj and some other free tools, wrapped in java-gcj-compat. The downside of this whole project is that it's stuck at java 5.0, the runtime isn't certified (the eclipse compiler is) and there's no more effort put into this project by redhat. Since a while, there's an alternative to java-gcj-compat, called icedtea. This project is based on openjdk, with the difference that missing pieces of openjdk are filled in with parts from GNU classpath. One example is the webbrowser plugin, that has been missing from x86_64 since java's existence for this platform. The icedtea6 java environment passes sun's testsuite, making it a full blown GPL'ed java environment that is compatible with Sun's java. As it's developed by redhat, it also compiles fine with GCC 4.3, which we can't say about openjdk. I would propose to package icedtea/openjdk for archlinux and make it the prefered java environment. Packaging this java environment requires a java compiler, our current free java platform is able to build icedtea/openjdk from source. This means that only java tools and packages required to build icedtea/openjdk will get built with gcj/ecj/java-gcj-compat, others will get built with icedtea/openjdk. Making this switch means no official support for java-gcj-compat anymore. If something continues working with java-gcj-compat, it's nice, but if it doesn't, we don't consider it a bug. Please let me know what your thoughts are about this change.
On Sat, Jun 28, 2008 at 6:29 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
As some people have noticed, I put a lot of effort in getting a free java runtime and SDK on archlinux, using GNU java, Eclipse-ecj and some other free tools, wrapped in java-gcj-compat.
The downside of this whole project is that it's stuck at java 5.0, the runtime isn't certified (the eclipse compiler is) and there's no more effort put into this project by redhat.
Since a while, there's an alternative to java-gcj-compat, called icedtea. This project is based on openjdk, with the difference that missing pieces of openjdk are filled in with parts from GNU classpath. One example is the webbrowser plugin, that has been missing from x86_64 since java's existence for this platform. The icedtea6 java environment passes sun's testsuite, making it a full blown GPL'ed java environment that is compatible with Sun's java. As it's developed by redhat, it also compiles fine with GCC 4.3, which we can't say about openjdk.
I would propose to package icedtea/openjdk for archlinux and make it the prefered java environment. Packaging this java environment requires a java compiler, our current free java platform is able to build icedtea/openjdk from source. This means that only java tools and packages required to build icedtea/openjdk will get built with gcj/ecj/java-gcj-compat, others will get built with icedtea/openjdk. Can't we bootstrap compile it the first time?
Making this switch means no official support for java-gcj-compat anymore. If something continues working with java-gcj-compat, it's nice, but if it doesn't, we don't consider it a bug.
Please let me know what your thoughts are about this change.
On the whole, sounds like a good idea to me. I know Arch used to have the idea that we preferred one tool for the job, and as long as we make it clear that our Java environment will be icedtea, we are picking one tool we will actively keep on top of. -Dan
On Sat, 2008-06-28 at 18:34 -0500, Dan McGee wrote:
I would propose to package icedtea/openjdk for archlinux and make it the prefered java environment. Packaging this java environment requires a java compiler, our current free java platform is able to build icedtea/openjdk from source. This means that only java tools and packages required to build icedtea/openjdk will get built with gcj/ecj/java-gcj-compat, others will get built with icedtea/openjdk. Can't we bootstrap compile it the first time?
Yes, we can. But that will create a circular build-dependency on itself. We already have this problem with gcc-java/eclipse-ecj that (make)depend on eachother. The gcc-java/eclipse-ecj dependency loop is easy to solve, as we can upload an architecture-neutral jarfile to FTP and use that in the future. Building icedtea/openjdk actually only requires gcc-java, the eclipse-ecj.jar file and xalan-java. This is a minimal set of makedepends, we could eventually drop the rest of the java-gcj-compat environment (java-gcj-compat, gjdoc) if we want.
Please let me know what your thoughts are about this change.
+1 for anything that'll get me a working x86_64 java browser plugin that works well. Dale
Am Sun, 29 Jun 2008 01:29:11 +0200 schrieb Jan de Groot <jan@jgc.homeip.net>:
As some people have noticed, I put a lot of effort in getting a free java runtime and SDK on archlinux, using GNU java, Eclipse-ecj and some other free tools, wrapped in java-gcj-compat.
The downside of this whole project is that it's stuck at java 5.0, the runtime isn't certified (the eclipse compiler is) and there's no more effort put into this project by redhat.
Since a while, there's an alternative to java-gcj-compat, called icedtea. This project is based on openjdk, with the difference that missing pieces of openjdk are filled in with parts from GNU classpath. One example is the webbrowser plugin, that has been missing from x86_64 since java's existence for this platform. The icedtea6 java environment passes sun's testsuite, making it a full blown GPL'ed java environment that is compatible with Sun's java. As it's developed by redhat, it also compiles fine with GCC 4.3, which we can't say about openjdk.
I would propose to package icedtea/openjdk for archlinux and make it the prefered java environment. Packaging this java environment requires a java compiler, our current free java platform is able to build icedtea/openjdk from source. This means that only java tools and packages required to build icedtea/openjdk will get built with gcj/ecj/java-gcj-compat, others will get built with icedtea/openjdk. Making this switch means no official support for java-gcj-compat anymore. If something continues working with java-gcj-compat, it's nice, but if it doesn't, we don't consider it a bug.
Please let me know what your thoughts are about this change.
+1 from me. Most work seems to done already in the AUR packages. But then we should also drop providing SUN's jre/jdk in extra. Let's support only free software. Let's put SUN stuff back to AUR. That also solves probable license issues. -AndyRTR
On Sun, 2008-06-29 at 10:47 +0200, Andreas Radke wrote:
+1 from me. Most work seems to done already in the AUR packages.
But then we should also drop providing SUN's jre/jdk in extra. Let's support only free software. Let's put SUN stuff back to AUR. That also solves probable license issues.
Both JRE/JDKs are compatible with eachother. The licensing of Sun JRE/JDK is "free" also due to the distribution license they put on it. This means we can distribute it with our distribution for free. This means there's no licensing issue, so we're allowed to have it in the repositories, either extra or community. I don't know what the current maintainer thinks about keeping JDK/JRE, but if he insists on keeping it, we'll keep it. If he decides to drop it, we'll drop it and place it in community.
Jan de Groot wrote:
On Sun, 2008-06-29 at 10:47 +0200, Andreas Radke wrote:
+1 from me. Most work seems to done already in the AUR packages.
But then we should also drop providing SUN's jre/jdk in extra. Let's support only free software. Let's put SUN stuff back to AUR. That also solves probable license issues.
Both JRE/JDKs are compatible with eachother. The licensing of Sun JRE/JDK is "free" also due to the distribution license they put on it. This means we can distribute it with our distribution for free. This means there's no licensing issue, so we're allowed to have it in the repositories, either extra or community.
I don't know what the current maintainer thinks about keeping JDK/JRE, but if he insists on keeping it, we'll keep it. If he decides to drop it, we'll drop it and place it in community.
Hi. Didn't realize this discussion was going to get into Sun JDK/JRE. Since they are free, and still provide the best compatibility around, I don't see why we should drop them. Has anyone found circumstances in which the Sun JDK and JRE have been inadequate for their Java needs? I recognize that it's possible that one day OpenJDK will actually lead the pack, given the way the Java world is moving, but I don't think that day is yet, and generally prefer to be using the reference JVM wherever possible. - P
On Sun, Jun 29, 2008 at 8:44 AM, Paul Mattal <paul@mattal.com> wrote:
Jan de Groot wrote:
On Sun, 2008-06-29 at 10:47 +0200, Andreas Radke wrote:
+1 from me. Most work seems to done already in the AUR packages.
But then we should also drop providing SUN's jre/jdk in extra. Let's support only free software. Let's put SUN stuff back to AUR. That also solves probable license issues.
Both JRE/JDKs are compatible with eachother. The licensing of Sun JRE/JDK is "free" also due to the distribution license they put on it. This means we can distribute it with our distribution for free. This means there's no licensing issue, so we're allowed to have it in the repositories, either extra or community.
I don't know what the current maintainer thinks about keeping JDK/JRE, but if he insists on keeping it, we'll keep it. If he decides to drop it, we'll drop it and place it in community.
Hi.
Didn't realize this discussion was going to get into Sun JDK/JRE. Since they are free, and still provide the best compatibility around, I don't see why we should drop them.
Has anyone found circumstances in which the Sun JDK and JRE have been inadequate for their Java needs? I recognize that it's possible that one day OpenJDK will actually lead the pack, given the way the Java world is moving, but I don't think that day is yet, and generally prefer to be using the reference JVM wherever possible.
Whoa! I'm with Paul here. This was never meant to be the free software crusade. When we become Debian I will find myself a new distro. -Dan
On Sun, 2008-06-29 at 13:52 -0500, Dan McGee wrote:
Has anyone found circumstances in which the Sun JDK and JRE have been inadequate for their Java needs? I recognize that it's possible that one day OpenJDK will actually lead the pack, given the way the Java world is moving, but I don't think that day is yet, and generally prefer to be using the reference JVM wherever possible.
Whoa! I'm with Paul here. This was never meant to be the free software crusade. When we become Debian I will find myself a new distro.
The whole point of the "reference JDK" from sun is that it doesn't include a browser plugin for x86_64 and it has bugs that wouldn't have existed when it had been allowed to build from source. The libxcb issue that has been fixed in the binaries recently is one example of that. The reason why we're bringing up this potential removal isn't because of free software. As I said, it will only get removed when its maintainer decides to drop the package and no other maintainer wants to take over.
On Sun, Jun 29, 2008 at 01:52:37PM -0500, Dan McGee wrote:
On Sun, Jun 29, 2008 at 8:44 AM, Paul Mattal <paul@mattal.com> wrote:
Hi.
Didn't realize this discussion was going to get into Sun JDK/JRE. Since they are free, and still provide the best compatibility around, I don't see why we should drop them.
Has anyone found circumstances in which the Sun JDK and JRE have been inadequate for their Java needs? I recognize that it's possible that one day OpenJDK will actually lead the pack, given the way the Java world is moving, but I don't think that day is yet, and generally prefer to be using the reference JVM wherever possible.
Whoa! I'm with Paul here. This was never meant to be the free software crusade. When we become Debian I will find myself a new distro.
What Paul and Dan said. As a sidenote, I use Java for work and have a vested interest in keeping Sun's official implemenation in the repos. If no one else wants to maintain it, I will, because I have a reason to. -S
On Sun, Jun 29, 2008 at 2:20 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Sun, 2008-06-29 at 10:47 +0200, Andreas Radke wrote:
+1 from me. Most work seems to done already in the AUR packages.
But then we should also drop providing SUN's jre/jdk in extra. Let's support only free software. Let's put SUN stuff back to AUR. That also solves probable license issues.
Both JRE/JDKs are compatible with eachother. The licensing of Sun JRE/JDK is "free" also due to the distribution license they put on it. This means we can distribute it with our distribution for free. This means there's no licensing issue, so we're allowed to have it in the repositories, either extra or community.
I don't know what the current maintainer thinks about keeping JDK/JRE, but if he insists on keeping it, we'll keep it. If he decides to drop it, we'll drop it and place it in community.
I'll keep doing my poor job maintaining JDK/JRE but I still think it should probably be around. Jason
On Sun, 29 Jun 2008 01:29:11 +0200 Jan de Groot <jan@jgc.homeip.net> wrote:
Please let me know what your thoughts are about this change.
+1 from my side. It's sound good for me. Daniel
Am Sonntag, 29. Juni 2008 01:29:11 schrieb Jan de Groot:
Making this switch means no official support for java-gcj-compat anymore. If something continues working with java-gcj-compat, it's nice, but if it doesn't, we don't consider it a bug.
Please let me know what your thoughts are about this change.
A working OS Java would be really nice. gcj wasn't a real alternative. How difficult is it to package? Maybe we could test it a while; but in the end I wouldn't mind replacing jdk by openjdk if everything works fine. Pierre -- http://www.archlinux.de
On Sun, 2008-06-29 at 14:51 +0200, Pierre Schmitz wrote:
Am Sonntag, 29. Juni 2008 01:29:11 schrieb Jan de Groot:
Making this switch means no official support for java-gcj-compat anymore. If something continues working with java-gcj-compat, it's nice, but if it doesn't, we don't consider it a bug.
Please let me know what your thoughts are about this change.
A working OS Java would be really nice. gcj wasn't a real alternative. How difficult is it to package?
Maybe we could test it a while; but in the end I wouldn't mind replacing jdk by openjdk if everything works fine.
packaging isn't so difficult. It's nothing more than just downloading openjdk sources, icedtea6 sources, applying a patch so openjdk knows to find some important system binaries in /bin instead of /usr/bin (these are in AUR), then running configure and make from the icedtea6 sources and as final step, package up the resulting java sdk/jre directories in the same way we do for the current JDK/JRE packages. The AUR PKGBUILD contains a lot of patches and special steps to get this thing built, but I don't see the need to do it that way. I'ld like to keep this thing as vanilla as possible.
Jan de Groot schrieb:
Since a while, there's an alternative to java-gcj-compat, called icedtea. This project is based on openjdk, with the difference that missing pieces of openjdk are filled in with parts from GNU classpath. One example is the webbrowser plugin, that has been missing from x86_64 since java's existence for this platform. The icedtea6 java environment passes sun's testsuite, making it a full blown GPL'ed java environment that is compatible with Sun's java. As it's developed by redhat, it also compiles fine with GCC 4.3, which we can't say about openjdk.
I always wanted to try openjdk/icedtea, but was too confused by the different packages in AUR. The PKGBUILDs were difficult to read and seemed to do "too much".
I would propose to package icedtea/openjdk for archlinux and make it the prefered java environment. Packaging this java environment requires a java compiler, our current free java platform is able to build icedtea/openjdk from source.
A nice and clean package that gives me a fully compatible Java runtime and a browser plugin would be very good. +16 from me. As you said java-gcj-compat didn't work too well, at least with the browser plugin.
participants (10)
-
Andreas Radke
-
Dale Blount
-
Dan McGee
-
Daniel Isenmann
-
Jan de Groot
-
Jason Chu
-
Paul Mattal
-
Pierre Schmitz
-
Simo Leone
-
Thomas Bächler