1.6 was EOLed in Feb 2013, this tracker aims to deal with packages that do not support 1.7 yet; as it is time that we start to try to get rid of 1.6. http://www.oracle.com/technetwork/java/eol-135779.html Please do not respond to this bug; if you have a bug with a package that does not compile against 1.7, please file a new bug. Thank you in advance.
Created attachment 399314 [details] candidates.txt Pretty much all the JDKs/JREs listed in this file can go except SoyLatte 7 (v6 is obsolete). We have to get in touch with Gentoo Prefix since they maintain it and let them know about the removal.
I mentioned this in the recent IRC meeting, but the URL mentioned refers to Oracle's implementation of Java 6. OpenJDK 6, as used by IcedTea 1.x, is still being maintained at present and so there is no reason to remove that or the 1.6 virtual as yet.
Is there any great reason to keep it though once we get 7 stabilised?
I discussed the above question with gnu_andrew on IRC and we came to the conclusion that Gentoo doesn't really need Java 6 at all. As an upstream maintainer of icedtea, he will continue to privately work on an ebuild, primarily to test that it builds in a clean environment.
Hi Prefix team We are in the process of cleaning up 1.6 JDKs/JREs from the tree, and hence are listing potential candidates. Although we do not maitain dev-java/soy-latte-jdk-bin, we would like to know if you want to keep it the tree (dev-java/soylatte-jdk-bin/soylatte-jdk-bin-1.0.3.ebuild) or are OK if we go ahead and remove it. Bear in mind Oracle have EOL'd Java 6 in Feb 2013 so it would be about time to see it off.
This is not so much about wanting this or not. I noticed you already threw away the apple variants. This is about if you want any Java, on some systems you just have at best Java 1.5, or Java 6. These are older OSX-es, with PPC in particular. Maybe we can move it to some overlay so it remains available for those who have no other choice. Solaris same thing, IIRC.
It's just dawned on me that we cannot even remove 1.6 until we have 1.7 or better VMs for *all* the archs we have keywords for in *any* other Java packages. Seems obvious but no one has raised this point yet. Despite what grobian said above, the prefix targets are actually relatively well covered thanks to Oracle's JDK supporting MacOS (but not PPC) and Solaris. oracle-jdk-bin-1.7.0.76.ebuild has all these: KEYWORDS="amd64 x86 ~amd64-linux ~x86-linux ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris" icedtea-7.2.4.8.ebuild also has ia64 covered. The problem archs are plain arm, ppc, and ppc64. I have access to timberdoodle and my own ARM hardware so I guess I'll need to get icedtea-bin packages built for all these.
Although being available for ppc*-linux and x86*-linux as well, bug#499874 comment#2 tells about punting ibm-jdk-bin. But, AFAICS, as the only one for ppc-aix, what to do with that one?
(In reply to Michael Haubenwallner from comment #8) > But, AFAICS, as the only one for ppc-aix, what to do with that one? I've asked gnu_andrew about this but he has yet to respond. As best as I can tell, support was merged into icedtea some time ago so it may just work but you guys are going to have to help us out here. I've never used or even seen AIX in my life. Please try to build icedtea, either using gcj or failing that, with ibm-jdk-bin. If only the latter works then we'll have to see about creating an icedtea-bin package that you can use to bootstrap from in future. I've tried to find out more about OSX/PPC but information is sketchy and gnu_andrew didn't know. Soylatte is Java 7 but the release is very old so you really want to start using icedtea proper if you can. The only Apple hardware in this house is an iPod Mini so again, you're going to have to do some work here. Sorry if it sounds like I'm being difficult but these old VMs are a burden for us and a liability for you. We would test these platforms if we could but we can't. I have at least taken on Linux/PPC by getting access to timberdoodle even though this is a platform I only had a short run with a few years ago. So I've managed to build icedtea 7 on Linux/PPC. I had hoped the tests would pass but they're quite explosive. On closer inspection, the systemtap tests only support x86 and amd64 but there are plenty of other failures too. gnu_andrew tells me that they used to run the suite automatically but have neglected it lately. I am currently attempting a test run on my own amd64 system to see how that compares but I suspect it'll be a case of RESTRICT="test". I'm more concerned that the tests for dev-java/jna are failing on ppc while they pass on amd64. Investigating…
IBM & SAP's work [0] includes a PPC64 port for both GNU/Linux and AIX. I've never even used an AIX machine though, and I doubt anyone has built IcedTea on it. But, in theory, it should be supported. They merged their port into OpenJDK 8 upstream but we've also included the 7 version in IcedTea 2.x. OS X is supported by Oracle on x86_64. PPC is supported on Linux. So, in theory the combination should be possible. I also have access to Apple PPC hardware, but I don't know when I'd have time to look into this. I suspect there will be issues with the compiler and libraries being older than what Oracle build on. As to tests, I've never known all the jtreg tests to pass (I assume that's what you mean; running 'make check' in IcedTea) on the main platforms like x86_64. If you're using a different VM on a different arch, it's even more unlikely. I did add RESTRICT="test" originally but it was removed in the main tree. It should either be re-added, or you can try a midway option of configuring with --disable-jdk-tests which should turn off the most troublesome JDK ones, leaving the JVM and tools tests, which have tended to be more reliable. Again, improving tests is something that's on the TODO list, but resources are stretched, especially now there are four JDKs (6,7,8,9) being used. [0] http://openjdk.java.net/projects/ppc-aix-port/
After giving up on the icedtea tests, I tried to get better results from the jna tests. gnu_andrew suggested I rebuild icedtea with jamvm instead since this looks to be the future for Java on PPC. After wrestling with an unusual issue that I won't bore you with, the jna tests mostly pass, much better than they did with icedtea built against CACAO. Given that the tests are probably geared towards HotSpot and also given they don't entirely pass with ibm-jdk-bin either, I have at least a little confidence in this solution for PPC going forward. Hopefully a new icedtea release against jamvm 2.0.0 will yield even better results. In the meantime, I will see about preparing an icedtea-bin package so that we can continue culling off 1.6.
It has been brought to my attention that IBM's JDK is still very much maintained, all the way from 1.5 to 1.8 on x86, amd64, ppc, and ppc64 for Linux. I had wrongly assumed that it had died out like many of the other JDKs. That doesn't change my stance on removing 1.6, in fact it strengthens it, but I am in two minds about whether to keep ibm-jdk-bin at all. On the one hand, it's even more annoying than Oracle's in that you need to actually register to download it. I am prepared to make an exception for Oracle's given its popularity but shouldn't we be nudging people towards free software here? We're very lucky that the maintainer of icedtea is a Gentoo user. On the other hand, while I am prepared to create icedtea-bin releases for ppc and ppc64 on Linux, I cannot help with AIX. That would mean someone else would have to take up this task or end users would have to make do with bootstrapping from GCJ. I would like ppc team's input here so CC'ing them in.
(In reply to James Le Cuirot from comment #12) > On the other hand, while I am prepared to create icedtea-bin releases for > ppc and ppc64 on Linux, I cannot help with AIX. That would mean someone else > would have to take up this task or end users would have to make do with > bootstrapping from GCJ. As far as I am aware of, the number of ppc-aix users besides myself is near zero. And myself in particular doesn't care too much for a broken ~ppc-aix until I find time to fix it again. But when I fix ibm-jdk-bin, what I'd like to know is the agreed target for these fixes: Either gx86, or prefix-overlay with chance to move to gx86, or my company-overlay only.
Okay guys, it's taken a while but short of a stabilization or two, the road is now clear for the removal of Java 6. We'll hang on to icedtea-6 while the stragglers are sorted out but I intend to last-rite the others now. These are: dev-java/apple-jdk-bin dev-java/hp-jdk-bin dev-java/ibm-jdk-bin:1.6 dev-java/soylatte-jdk-bin (including the Java 7 version) I'm sorry if you're using one of these on some old platform but these are beyond ancient. As I said earlier, you really should be looking at icedtea now. We should have totally killed off Java 7 by now, let alone 6. I am now much happier about the situation for ppc and ppc64 on Linux. The CACAO builds are faring well since I applied my dynamic heap patch. ppc64 even supports HotSpot, which we haven't been able to use on timberdoodle for Java 7 due to some race condition but it does work fine for Java 8. If you want to try icedtea yourself then you need to start with gcc[gcj]. GCJ is going away sooner or later and icedtea will attempt to address this by allowing itself to be built without any Java prerequisites, possibly with the help of JamVM. This will certainly make things simpler but we're not there yet, I'm afraid. I am in dialog with haubi about the future of ibm-jdk-bin. It is still very much maintained upstream but there is practically no user interest, not least because of its registration wall. haubi wants it for ppc-aix so it may be keyworded for this alone in an overlay. We're still working out the details. gnu_andrew has expressed that he would like to keep icedtea-6 in java-overlay as he still intends to maintain it. I will therefore, if it's possible, unmask it in java-overlay to counteract the mask in the main tree. The virtuals will remain masked, however. I will wait till Sunday evening for any concerns to be raised but keeping these around simply isn't an option.
I dunno, I guess the only option is to let you remove it and leave people without.
It's finally gone! Yay!
