Quote:
Originally Posted by Toutatis
Thank you,
I am using Oracle JDK 17 and JavaFX 17 to run pdfsam. Is it possible to use my JavaFX from OpenJDK17, or is a recompilation of JavaFX needed ?
|
Should just work, since it was spun off JavaFX is just a library now - a bunch of modular jars and some native (JNI) libraries. But I also checked and confirm it works on either for one of my bits of code. AS WELL IT SHOULD OF COURSE! Otherwise it couldn't really call itself 'Java' since the jars are created to run on a specification-conforming implementation of 'Java 17' and they both promote themselves as such. I suspect strongly gluon would be using the openjdk and not the oracle jdk for their builds to start with.
Given 17 is still the current openjdk I imagine the common components will be identical to the openjdk apart from branding and license texts. This seems to be confirmed looking at the classes in some of the modules - java.core has some telemetry(?) (package sun.usagetracker) and JarVerifier, java.desktop is identical apart from some awt branding images, java.net is identical.
Actually based on the comments at the head of a reddit discussion [1] (see in particular pron98's replies - an openjdk developer) they should be the same, it's basically just 'commercial' vs 'gpl' licensed OpenJDK, but they will necessarily diverge once openjdk moves onto 18 and the openjdk-17 branch no longer receive any gpl updates. There's been quite a lot of discussion and clarification about the 'new' release cycle on reddit and the openjdk mailing lists trying to convince people that the LTS distinction isn't meaningful for most Java users and developers, and that the 'major releases' are no different to the 'feature releases' previously (large changes within a major-version number). To summarise, each LTS is a specific licensed Oracle product (or some other vendor like RedHat) intended for large slow-moving corporate customers and is separate to the openjdk. The problem with the non-Oracle LTS's is that while they can borrow the name and backport security and other fixes from later OpenJDK development that will no longer be possible once deprecated components are removed or implementations changed to use new features (something which is happening much more aggressively now). And as Oracle does by far most of the work on the source tree that means security will eventually be impacted. There's been a lot of very good quality info on reddit and the mailing lists which i've been following for the last few years but it's all pretty hard to recover after the fact unless you get lucky with searches. Honestly the amount of patience the Oracle guys like pron98 display during some of the discussions[2] put most other public projects to shame (and certainly my own record when I did such a thing).
There's some other stuff that's happening in the java world that doesn't really match with the way java has been setup in slackware and similar systems in the past for better or worse - e.g. jlink is now the intended method used to build a bespoke java runtime environment for each application rather than using a system-installed JRE or JDK - although the openjdk can still be used as is anyway and it probably makes more sense to do this on slackware in particular since it comes with all the dev tools for lots of languages. So in reality it doesn't make much difference here. It's trivial to use jlink to create a custom JRE of whatever modules your application needs, a linux-amd64 one with javafx.controls (enough for most javafx) is ~57MB - contrast to the ~300B+150MB of openjdk + openjfx although these are about 2x bigger than an everything-and-the-kitchen-sink 'jre' because they contain the jmod files which are only used by jlink and not required at runtime (neat fact: you can cross-build for different platforms by just changing the jmod search path and specifying the target).
The inability to install multiple jdk's is idiosyncratic of slackware though, ubuntu lets you install multiple in parallel via their package managers, gentoo as well although it's support for openjdk is in a pretty sad state but as a source-based distribution it has it's own difficulties to deal with. Like i said in the other thread I just install the sdks into /usr/local - things like IDE's that let you choose which backend to use look there and a few other places already. And expect everything to be in one directory of that layout rather than splattered across the /usr file tree. Like the python 3.x question, perhaps slackware needs to make a decision on java,
just sticking to a specific openjdk Java "LTS" will actually be incorrect whatever the decision - but i suspect other GNU distributions will make the same mistake due to the overloading of the meaning of "LTS". It's less impactful than the python question though, in part because the language has an actual specification and compatibility is one of it's goals, although mostly because nothing in slackware uses it. Also note using jlink completely side-steps the question[3].
[1]
https://old.reddit.com/r/java/commen..._adoptopenjdk/
[2]
https://old.reddit.com/r/java/commen...tures/hguochg/ (e.g. alex0589 - lengthy discussion ending in 'i'm too young to be hired', lol).
[3] I don't necessarily think it's a great thing, and something about it rubs me the wrong way in the same way rust's static linking does - but this is just what 20+ years of 'progress' has done to software systems and crying about it wont change that fact.
