Re: OpenJFX 9 integration
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
Reply to: