(D) doesn't seem good to me, since lot of apps are using JavaFX (e.g. NetBeans and Bisq). These apps won't even launch using Debian's default JRE if OpenJFX isn't included, which would be quite annoying to some users. Matthias Klose 於 2017年10月22日 18:57 寫道: > On 12.10.2017 13:13, Emmanuel Bourg wrote: >> Hi all, >> >> I started working on OpenJFX 9 this week. The good news is that it >> builds fine in Debian now [1]. The bad news is that it's going to be >> significantly more challenging to integrate it with our OpenJDK package. >> >> With OpenJDK 8 the integration was just a matter of installing extra jar >> files and native libraries under /usr/lib/jvm/java-8-openjdk-amd64. With >> Java 9 and the modularization of the JDK it's another story: >> 1. The class files for the JRE and JavaFX are merged into a huge binary >> blob (lib/modules) using a custom format. >> 2. The javadocs are also merged into a unique src.zip archive. >> 3. The JDK contains new .jmod files for each module, and the ones for >> JavaFX are built by OpenJDK, not OpenJFX. >> 4. The JRE modules have to be patched to allow JavaFX classes to use >> internal JRE classes. >> >> According to the build instructions of OpenJFX [1] we have to build >> OpenJFX first and then build OpenJDK with an extra configuration >> parameter (--with-import-modules) pointing to the OpenJFX build directory. >> >> In this context it appears nearly impossible to package OpenJFX >> independently of OpenJDK. Here are the options I can see so far: >> >> A. Merge the openjfx package into openjdk. >> >> B. Keep the packages separate and attempt to overcome the issues (1) and >> (2) with postinst hooks or triggers merging the files, (3) by patching >> the OpenJFX build, and (4) by patching the module-info.java files in >> OpenJDK. >> >> C. Generate an intermediary package containing the build result of >> OpenJFX and used as a build dependency of OpenJDK. >> >> (A) is problematic because the openjdk package is already quite complex, >> and since openjdk is in the hands of the OpenJDK Team I won't be able to >> maintain OpenJFX there. (B) involves a lot of work, merging lib/modules >> is the biggest issue. (C) requires a rebuild of OpenJDK every time >> OpenJFX is updated, but is by far the easiest solution to implement. > (A) is also problematic, because it adds yet another build tool, which never > should have been invented: gradle. The OpenJDK package should be cross > buildable to (re-)bootstrap architectures. We can't rely anymore on gcj for the > bootstrap. Gradle is a mess when it comes to cross build support, hard coding > target architectures everywhere (at least that's when I looked at it two years > ago). So independent of any maintainership, I don't like option (A). > > (B) is something which should be addressed upstream independently. Currently > upstream's thinking seems to be to ship everything in one place without caring > how the result is built, and only then providing some ways to build a minimal > JRE for some specific application. That's not something distributions can use. > > Are you aware if upstream is aware of these issues, and if they intend to stop > using internal OpenJDK APIs? Any plans to get rid off the single file approach > for the database files? > > (C) looks like the best workaround for now. Looking at at least four security > releases per year, and maybe the double amount of package uploads, the OpenJDK > package has a higher upload frequency anyway. There is however a risk that an > OpenJDK (security) update won't build anymore with a prebuilt OpenJFX (not sure > if that is a real issue). In any case, the OpenJDK package should have a build > profile to build without OpenJFX support. > > (D) seems to be forgotten here: Don't build OpenJFX in the distro. That might > be an option if OpenJFX can't keep up with security updates. > > Matthias >
Attachment:
signature.asc
Description: OpenPGP digital signature