Emerge update forcing dev-java/oracle-jdk-bin

[wltjr]

Users have influence and clout, do they not? Rather than chalking this off to a rant, users could act and ensure such never happens again. Learn from the past, take action, and ensure it never occurs again.

If you do not learn from the past, it will repeat itself... Which has happened... I hope it does not happen again... However being only 2, and with the amount of work, that was to great for more than 2 in the past.... I very much fear burnout and the past will repeat itself...

If I wanted publicity, I would take it to -project and make considerably more noise... Like I did in the past.... Forums are the last place to comment on something you want being noticed or publicized...

Once again, I pushed for oracle-jdk-1.8 stabilization, etc. Thus I am part of this problem, and providing back story. Does not shock me in the least, most careless about the past, despite its direct relevance on the present state of things. Assuming that the future will be better than the past, not realizing that it can happen again....

The team used to have 7+ members, including myself, before icedtea/openjdk was even in tree. The team had a hard time keeping things up to date. With just 2, the odds are stacked against them. If they do not get some help, more Java devs, then they might burn out and the past will repeat....

[wltjr]

Here is my point in all this.... There is more to the discussion but showing the most important stuff... This is today, the PRESENT, not the past...

2015-04-22.log:18:55 <+wltjr> gnu_andrew: either way need to get latest versions of icedtea/openjdk stable, and punt the older stuff
2015-04-22.log:18:55 <+gnu_andrew> wltjr: heh the plugin won't even work with Chrome, I'm surprised it survives at all
2015-04-22.log:18:55 <+gnu_andrew> wltjr: I agree, but what can I do?
2015-04-22.log:18:55 <+wltjr> gnu_andrew: nada like me
2015-04-22.log:18:55 <+gnu_andrew> I provide versions earlier than most distros, the day the update goes out
2015-04-22.log:18:55 <+wltjr> gnu_andrew: your already doing all you can
2015-04-22.log:18:55 <+gnu_andrew> then Gentoo doesn't use them...
2015-04-22.log:18:56 <+gnu_andrew> you could have had 2.5.5 and 1.13.7 in before most other distros

Gentoo gets icedtea/openjdk stuff before other distros, but the lack of manpower results in them not making it to tree etc... This would not be an issue if gnu_andrew was a developer... Or others... Proxy maintaining is not a good option. Things can get out of sync, and could be updates available in an overlay that are not in tree, as has been the case for icedtea/openjdk for years...

This is the making of comrel, I have tried to get them to get gnu_andrew on board... Really not sure what it will take. Maybe users revolting, making a bunch of noise something. If the masses object, the minority will have to give in and make changes. Changes than will be good for Gentoo in the long run. Some are necessary for its survival....

[gnu_andrew]

I don't want to get embroiled in a political discussion either. The main reason I'm not yet a Gentoo developer is available time, the same thing that has also slowed down the release of IcedTea 3.0.0. If someone has a way of making the days 48 hours long, then that would be most helpful However, it would be a nice surprise if the fact I've worked on this ebuild for about eight years was taken into account as evidence that giving me commit access wouldn't lead to the complete destruction of Gentoo.

I understand the dislike of Oracle's proprietary JDK; I've worked on FOSS Java for 11 years, first on GNU Classpath and now IcedTea/OpenJDK. However, in this time, I've also met quite a few people who feel the opposite; they don't care about the license so much, they just want to download the latest and best supported binary. Gentoo has to cater for both groups of users, so stabilising jdk-1.8 is sensible and ensures that at least one version is available on Gentoo. This is especially important for these users, as Oracle won't be releasing any further public updates for 7, making the current ones obsolete when the next security update rolls around in July.

For FOSS Java users, I presume you already have the Oracle license blocked on your systems, so it's just a case of blocking virtual/jdk-1.8 for now (see the guide https://forums.gentoo.org/viewtopic-t-1015568.html). Alternatively, if you're willing to be a bit more experimental, we could use help testing icedtea:8. There's a live ebuild available in java overlay already. I'll make sure that's up to date and add a virtual/jdk-1.8 there to override the one in the main tree. Beware that it may still be buggy right now, but report any issues at http://icedtea.classpath.org/bugzilla and we'll try and make sure they get fixed before release. This is the best way to get us to a stable FOSS jdk-1.8.

[l_bratch]

Many thanks to Chewi, monsieurp and gnu_andrew! The recent update was mildly irritating, but the issue being discussed here in the open is appreciated.

I'll give icedtea:8 a test, too.

Edit:
And wltjr!

[Chiitoo]

[wltjr]

From source icedtea/openjdk ebuilds will always have deps like cups, X, and others. They are necessary to build/compile the jdk/jre, but are not needed at runtime. If you do not want those libraries you are better off staying with icedtea-bin. There will likely NEVER be a solution or option to build a jdk/jre from source without such deps like cups, X, etc. Otherwise you have to omit major parts of the jdk/jre, like all javax.print and wrt to X all java.swing and java.awt. You simply cannot leave out such and build a jdk/jre. The build system does not allow for such, and even if it did you would end up with a jdk/jre missing stuff that others have, the standard offerings of any jdk/jre.

People wanting less deps on from source IcedTea/OpenJDK simply do not understand Java. More than likely the ONLY option will be icedtea-bin. Just like oracle-jdk/jre, its already been built/compiled against necessary deps. If you do not use those parts of Java then the deps do not need to be installed. But that is very different when you are building and compiling IcedTea/OpenJDK.

I am trying to get Chewi and/or monsieurp (who is away now for 2 weeks) to get the latest versions of IcedTea from the Java Overlay to tree. Then we can stabilize 6 and 7, hopefully close some open bugs. Then build newer/updated icedtea-bin packages jdk/jre. I would have this done myself already, but I am stuck on the outside. IcedTea in tree, be it from source, and usually more so the -bin versions tend to be behind compared to whats in the Java Overlay. That delay will likely continue for some time, unfortunately.

But again when building from source, either deal with the deps on your system at build/compile time, you can remove them after if you want, just don't use those portions of the jdk/jre. Or just stick with the -bin versions, prebuilt that will not require the deps at runtime, unless you set the use flags and/or use those parts of the jdk/jre.

Likely need to make a wiki page on all this, as it will likely come up time and time again, and forum is not the best place to mention this stuff...

[Chiitoo]

Thanks for the input, wltjr!

As far as I understand, even the binary packages will require cups if X is enabled.

Granted, I need to re-evaluate my needs with regards to Java in general. It's just that I don't like things pulling in other things that which I don't need or use at all, and something like printing seems (to me) something that should not be so integral to web-browsers for example, and I certainly don't understand Java. I do understand, however, that it's not always so simple to cut them off after they've been tied to each other.
_________________
Kindest of regardses.

[wltjr]

I am not a fan of non-essential things being installed either. Why I tend to prefer bin vs from source version. I mostly run Oracle JDK as I use Java in production for things like Tomcat, web applications, etc. Also some graphical desktop applications, where PDFs are generated and at times printed. Though I do not use the Java printing API really.

If I go to use IcedTea/OpenJDK from source in the future, I will likely build it on a different system, or in a chroot. Then install the resulting binary I made. I think it still might try to pull in the compile time deps not sure. Worse case I can uninstall that after but it would likely be sucked back in up update etc.

I do not want X, cups, or other stuff on servers that will never use nor need that stuff. Many packages get pulled in that do not exist right now and I very much dislike that. However due to how Java is, I am not sure that will ever change.

The core of Java has to change, so if it was built say without X, cups, etc. If you go to use graphical, or printing aspects of code it would throw some exception. I think now the JVM would crash if it was compiled against stuff, trying to use that, but it was removed from the system. Its very different from other languages.

Part of the benefit of Java or a JRE/JDK is that most everything you need is there already. Want to do graphics, printing, or just regular java stuff, its all there. It increases even more with JEE, Enterprise Java. It has even more things included. Its not modular by design and I am not sure it ever will be. That changes the nature of Java, and what JRE/JDK provides. You would need different variants.

However other distros are offering like headless packages. There might be some headless builds or a Headless JRE/JDK offering in the future. Some what like how there was a Micro Edition of Java, and an Enterprise Edition. There might be some slimmed down server versions that do not have requirements on X, cups, etc but do not have those aspects of Java presenting for use either.

That said with regard to nsplugin, the web browser portions of Java. That will clearly require X, and printing will likely come as part of that. Printing is part of browsers, and Java really has no idea if someone will try to print from say a Java Applet, etc. So that dependency will likely always exist.

I have to double check but I think Oracle JDK/JRE has less deps than even IcedTea/OpenJDK binary package, not a binary you built yourself. They might be the same. Which brings me to my next point.

Keep in mind something VERY important. Oracle JDK/JRE literally is OpenJDK. Its not some other set of sources. The difference between Oracle JDK/JRE and IcedTea/OpenJDK, is ONLY in how it is built, and that Oracle is releasing the result under their license terms. The only difference with IcedTea/OpenJDK is the code was built using open source tools, but the end result is basically the same. Its using the same codebase. There is not separate Java sources for Oracle JDK/JRE and OpenJDK, its the same, its just a difference in building, packaging, and release.

Thus many do not want to accept license terms from Oracle, or use pre-built binaries. But it really is the same code at the end of the day. The rest is just semantics.

I do not think that applies to IBM JDK/JRE. While they are part of OpenJDK now and have their own OpenJDK builds. Historically IBM JDK/JRE was IBMs implementation of the Java spec. So that is a different codebase. But Oracle JDK/JRE literally is OpenJDK, just built for you and released/licensed by Oracle. Likely built using their JDK/JRE so compiled against a non open source base. That is the real gripe and benefit to IcedTea building OpenJDK. Its a version of Java built entirely from open source tools, not relying on a pre-built binary from a third party you must accept a license to download.

So its a semantic difference, and I can see license being a hangup for some organizations legally. But for individuals its just a preference, and might be creating more of a headache trying to avoid some semantics.

[wltjr]

[gnu_andrew]

[gnu_andrew]

Note that an updated jdk-1.8.0 which depends on icedtea:8 is now in the java overlay, together with the icedtea-3.0.0_pre03.ebuild which currently fulfils the requirement. With the overlay enabled, you shouldn't need to install the proprietary Oracle JDK.

[flagrant2]

A very small $0.02 from a recent debian convert: Openjdk 8 had been out for over a year before they released their current stable release and it still didn't make it in. It only recently made it from unstable to testing. So the situation in debian, a giant distro with lots of developer hours, is pretty similar. I can't comment on the political situation described here, but the java situation doesn't seem to me to be a reason to jump ship to another distro given the similar state of debian.

It really sounds like the devs around here have the users' interests at heart in spite of the internal dysfunction, so kudos for that and thanks for your efforts.

[wltjr]