If you’ve been reading my blog for a while, you know I was really enthusiastic for Sun opening the JDK so that we could have Free Java. This should have solved both the Java trap and the Java crap (the false sense of portability among systems), and I was really looking forward for it.
When Sun finally made OpenJDK sources available, the Gentoo Java team was already on the field, and we were the first distribution packaging it, albeit in an experimental overlay that most users wouldn’t want to try. I also tried to do my best to improve the situation submitting buildsystem fixes to Sun itself to get it to build on my term, which means system libraries, --as-needed support and so on. The hospital set me back so I couldn’t continue my work to have something working, so at the end I gave up. Too bad.
After I came home I discovered that the IcedTea idea seemed to work fine, and the project was really getting something done, cool! But it wasn’t ready for prime time yet, so I decided to wait; I tried getting back on track last summer, but hospital set me back again, so I decided to not stick around too much, being out of the loop.
But since I stopped using Konqueror (with the rest of KDE) and moved to Firefox I’m missing Java functionality, since I’m on AMD64 and I don’t intend to use the 32-bit Firefox builds. So I decided to check out IcedTea6, based on OpenJDK 6 (that is, the codebase of the 1.6 series of Sun JDK, which should be much more stable). IcedTea6 actually got releases out, 1.2, 1.3, 1.3.1 now. Even though Andrew seems to be optimistic, this is not working just yet.
First problem: while OpenJDK only bootstrapped with Sun JDK 1.7 betas, IcedTea6 only bootstraps with IcedTea itself or another GNU classpath based compiler, like gcj or cacao. Okay so I merged gcj-jdk and used that one; IcedTea6 fails when I force --as-needed through compiler specs. Since the build system is quite too much of a mess for me I didn’t want to try fixing that just yet, I just wanted it to work, so I disabled that and restarted build. With gcj-jdk it fails to build because of a problem with source/target settings. Okay I can still use cacao.
The first problem with cacao is that gnu-classpath does not build with the nsplugin USE flag enabled since it does not recognise xulrunner-1.9, there is a bug open for that but no solution just yet. I disable that one and cacao builds, although IcedTea6 fails later on with internal compiler error. Yuppie!
And this is not just the end of the Odissey; I want to get Freemind to work on Yamato since I’ve tried it out and it really seems cool, but I can get it to work only on OS X for now, since to build some of its dependencies on Gentoo I need a 1.4 JDK, but on AMD64 there is no Sun JDK 1.4, no Blackdown, just Kaffe… and Kaffe 1.1.7 (the latest is 1.1.9), which is not considered anything useful or usable (and indeed it fails to build the dependency here).
I think the road is still very long, and very tricky. And I need to get a Java minion to help me finding what the heck of the problem it is!
I helped Andrew with the icedtea ebuilds during the summer but haven’t touched them recently. It worked okay for me except I sometimes stumbled across a completely unrelated race condition bug in GCJ that only affects SMP machines and results in internal compiler errors. That’s recently been fixed upstream. If you’ve not enabled GCJ before, it’s still a bit of a hassle though. I think the long-term plan may be to provide prebuilt icedtea packages (on the LiveCD?) that you can bootstrap from. As for that source/target problem, I bet it’s related to ant’s environment as the build is particularly sensitive about that. Hopefully Andrew can figure it out.
Additionally, if you find a good/easy way to get java working in ff on amd64, I am interested in hearing about it. I have tried myself and the process was not successful at the time.
I had the same problems like, last week or so…I only got IcedTea-1.2 to compile, never managed it for 1.3, though 1.2 is enough for Firefox, as I too only need Java for the browser basically. That gnu-classpath doesn’t build with nsplugin USE happened to me too, but you don’t need that, it’s the IcedTea nsplugin USE flag you want enabled to get the 64bit FF plugin, the one on gnu-classpath is not needed for that and tbh I have no clue what kind of plugin that one would precisely build.To get 1.2 to compile I too tried cacao or gcj, nothing worked, but it does compile using Sun’s JDK, you just have to edit the ebuild to not bail out if the system-vm isn’t gcj or cacao, but let it pass the same config parameters as if you’d be building using gcj!Still, I concour with your conclusion: cool idea et all, but really not there at all yet, the whole thing looks mighty shaky and probably correctly builds as it should only on full moons in years that are a power of 2. :PHope some of what I wrote can help you get a working FF plugin, chtekk.
Actually, I had the same problem with gcj-jdk having issues with source/target (it complained about generics in the code at some point).I ended up having to downgrade ant-core to a version from the java-overlay (some problem with resetting JAVA_HOME during the build that the default ant-core dislikes…)This only applies, at least in my experience, for icedtea6-1.2. 1.3.1 will build, but fails to build the pluginappletviewer binary, so the plugin doesn’t work.
John actually hit the nail on the head, mostly.Let me try to sum up what a day of discussion (yesterday) brought me to know:* Gentoo officially does not support JAVA_HOME, and does the most to make sure it’s ignored;* IcedTea6 build expects JAVA_HOME to be properly respected;* dev-java/ant-core-1.7.0-r3 in the java-overlay is “hacked” to respect JAVA_HOME (Andrew consider it “fixed”, Gentoo Java team “hacked”, your call what the right word is; to me it just means that it’s not the same as the Gentoo’s ant script);* the latest version in ~arch for ant-core is 1.7.1 which is *not* respecting JAVA_HOME.The result is that yes, Andrew’s blog post was overly optimistic since there is no way on a _current pure Gentoo system_ for IcedTea6 to build. Sorry Andrew that you think this is not true, but the fact that you need a modified ant for me means you have to fiddle with the system, and fiddling with the system is not the same as having the package building fine on a pure system by definition.I haven’t tried hacking ant and see what happens, but if John is right and even IcedTea6 will fail to build the nsplugin, I’m not sure if I do want to try that at all…
I’ve just emerged the latest version icedtea6-1.3.1-r1 and have a working java plugin using that. It’s not the first version of IcedTea I installed though. I did have some -9999 and 1.2+ versions before, right now it was an upgrade from 1.3.1. In the beginning I emerged gcj and have ant-core-1.7.1-r1 from the java-overlay installed.So in short: there’s some system fiddling / bug fixing required but you can get a working java plugin in 64bit Firefox.
I have been fighting these exact same problems for two weeks now… opening bugs, contacting with the java guys. I hope to find a way to get this working soon!
I think a lot of these problems stem from the fact that Gentoo has been living in a completely different world when it comes to the Java stack compared to the other main GNU/Linux distributions. On Debian, Ubuntu and Fedora, GCJ as the JDK was the standard. It’s now been supplanted by IcedTea in two Ubuntu releases and three Fedora releases. I’m hardly being optimistic when this is a piece of software that is being built on a daily basis by myself, the other IcedTea developers and people from these distributions. Gentoo may have embraced OpenJDK initially, but it has fell massively behind since.In these distros, Freedom is much more central than in Gentoo where the attitude seems to be much more ambivalent. Fedora doesn’t package non-Free stuff, Debian and Ubuntu relegate it to non-free/multiverse. The original OpenJDK drops from Sun don’t build with the Free stack so IcedTea was created to allow this. It doesn’t support proprietary packages like ‘sun-jdk’. This is intentional; no-one in the IcedTea team is interested in supporting building with a proprietary JDK AFAIK. Someone from Gentoo is welcome to take this on of course, but I’m hardly going to support something I don’t use myself in the ebuild. If you remove the parts of the ebuild which check you have a Free JDK, you’re on your own. Expecting us to be able to do anything with a HotSpot crash you get building IcedTea with a proprietary JDK is ludicrous; the only folks who can help you there work for Sun.Sermon over, I hope that’s established the context for you a little. The issues mentioned here should now be resolved. Plugin-wise, 1.2 packages gcjwebplugin, which is the same code as in GNU Classpath, but reworked to use Sun’s security and applet packages and with some more bugs fixed. I don’t recommend using nsplugin with GNU Classpath, and I’m going to suggest that the plugin dropped for 0.98. 1.3.1 packages a rewritten plugin which supports LiveConnect and should work with even more sites. The plugin is developed by the IcedTea team; Sun have not released the source code for their plugin and have no plans to.I wasn’t impressed with how the 1.3 release was handled for IcedTea or the state of the plugin in 1.3.1. Basically, 1.3 was unusable because the gcj bootstrap was broken due to missing files. This is why the ebuild was deleted as soon as 1.3.1 was available. A less major but still significant issue with the plugin, in that it still purports to support the old gcjwebplugin but this won’t build. Initial versions of the 1.3 and 1.3.1 ebuilds maintained the old plugin (under the belief that it worked and because it supported ff2). Once the issue was noted, the new plugin was used by default. It was always intended to move to the new plugin, but the bug made this move more necessary and immediate.Finally on the subject of Ant, the issue is that whether or not Gentoo wants to ‘support’ JAVA_HOME, Ant uses it. The problem with the Ant script provided by Gentoo which *differs* from that provided by other distros is that it ignores any JAVA_HOME environment set by the user and sets its own. This causes problems in the IcedTea build because it means another JDK on your system may be added into the mix. In some situations, it will work, in others not. I fixed it, but this remained only in the overlay as the Gentoo Java team basically did nothing with this bug for about six months. Finally a fix has been applied in the main tree which I still don’t believe is ideal but means that IcedTea can be built without running into some random JDK that the Ant build script decides to pick up (I think it bases it on java-config but don’t quote me on that, take a look yourself).In summary, most of the issues you run into are not issues with IcedTea persay but rather artefacts of how Gentoo has chosen to do things differently over the past few years. Hopefully when IcedTea finally goes into the main tree, Gentoo will be more in line with the norm. An icedtea6-bin ebuild is available in the overlay now to reduce some of the issues for those on x86 and x86_64. I hope in time Gentoo will make IcedTea the default and get it certified through the JCK.