Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 583368

Summary: dev-java/oracle-jre-bin and dev-java/oracle-jdk-bin slot 1.7 are still needed
Product: Gentoo Linux Reporter: Chicago <chicago>
Component: [OLD] JavaAssignee: Java team <java>
Status: RESOLVED WONTFIX    
Severity: normal CC: chicago
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Chicago 2016-05-18 03:31:34 UTC
It appears the v1.7 Oracle JRE and JDK have been removed from the tree.

    This seems to be quite aggressive tree trimming and impacts users negatively in multiple ways.

    Please restore the v1.7 slotted oracle-jre-bin and oracle-jdk-bin as they are still useful especially as browser plugins where an applet requires v1.7 even in 2016.

    At the absolute very least, there should have been GLEP 42 news giving either advanced notice or warning once it had been made obsolete and planned for removal.

    Without there even being a masked version available, users are left without an in-tree option.

    This is a rant and a courtesy gripe to suggest the Java package maintenance should remain as conservative as possible.  Enterprises leverage older JRE and JDK for *years* after their "expiration date".  Users have no control over this and need to still interact with them.  For those preferring the native runtime, the Oracle binaries are absolutely necessary.

Kind Regards,
-Chicago
Comment 1 James Le Cuirot gentoo-dev 2016-05-18 20:27:55 UTC
Yes, because providing a JVM with a mountain of vulnerabilities is doing our users a great service. You make it sound like we have removed Java 7 altogether.

You do know that Java was open sourced, right? Perhaps you do and that was what you meant by the "native runtime" but any such FUD has to stop. The 32-bit ARM port aside, what you get from Oracle is practically identical to what you get from OpenJDK/IcedTea. Perhaps you don't trust our icedtea-bin package even though I build it from source myself? So go build your own. Any issues? File a bug. It will get fixed. Red Hat pay for the continued maintenance of Java 7 (and 6) and Gentoo is very lucky to have the main guy behind that effort actively writing ebuilds for us. He's even copied in on all Gentoo Java bug reports, including this one. Want that kind of support from Oracle? You'll be lucky to get it even if you pay them.

On that note, you talk about enterprise. I use Java in commercial production and there's no way in hell I would use that version. We had a PCI DSS audit last week. If we'd had that version installed anywhere, it would have been a flat out fail. Companies that insist on Oracle would be paying them for the updates they are no longer freely providing. We are perfectly happy with the OpenJDK packages provided by RHEL and Debian so if we were stuck with Java 7 then we wouldn't even have to pay to remain secure.

A news item was not warranted. Java 8 is over two years old. Removing just one of the two possible Java 7 VMs is hardly news, especially when that VM hasn't been updated in a year. I actually wanted it dealt with quietly because I was frankly quite embarrassed that we hadn't removed it sooner, given how vulnerable it is. Even when I removed Java 6, a news item was not necessary because the package masks did the job. Practically everyone had stopped using it anyway and the only legitimate complaint I received was from some guy with an ancient printer and he conceded that was he going to get rid of it soon. Because there was no package mask in this case, it's not like I've even forced you to remove it! Go ahead and keep your system at risk if you really want to.

Now I will admit that I intend to drop Java 7 entirely by the end of the year. Despite these complaints of incompatibilities, practically nothing in the tree requires it at runtime and very little requires it at build time. We should be able to deal with the build time issues. Rest assured, you will get plenty of notice from the package mask and beyond that, you will still have the option of using the upstream-provided ebuilds in java-overlay, as is already the case for Java 6.

Why are we doing this? The Java team is very small and having so many JVMs to deal with greatly increases the maintenance burden. We cannot afford to be "conservative" and have been striving to trim the fat down to a more manageable size in order to stop the rot. If I were to walk away tomorrow (and I'm not even that heavily invested in Java) the sheer volume of what we have right now (never mind what we had a year ago) would almost certain scare any serious new contributors off. The lack of Java 7 would then be the least of your worries.
Comment 2 Chicago 2016-05-20 01:57:29 UTC
Hi James,

    Thanks for your thorough outline of the project's future goals and for describing how confidently our users should be able to rely upon the OpenJDK/IcedTea.

    I will accept your guidance and go with the herd on this one.

    Coincidentally, not more than 12 hours after filing this bug report, 90% of my use case for a Java 7 runtime has been negated as the upstream Enterprise application just switched to an HTML 5 implementation.

    Really, thanks for the rundown on how well Gentoo is actually supported with Java.

    Please accept my ignorance as a user in need of proper guidance.

Kind Regards,
-Chicago