Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #10078 > unrolled thread

OpenJFX 9 integration

Back to article view | Back to linux.debian.maint.java

Contents

  OpenJFX 9 integration Emmanuel Bourg <ebourg@apache.org> - 2017-10-13 00:40 +0200
    Re: OpenJFX 9 integration 殷啟聰 | Kai-Chung Yan <seamlikok@gmail.com> - 2017-10-17 17:20 +0200
      Re: OpenJFX 9 integration Emmanuel Bourg <ebourg@apache.org> - 2017-10-17 21:20 +0200
    Re: OpenJFX 9 integration Matthias Klose <doko@debian.org> - 2017-10-22 13:20 +0200
      Re: OpenJFX 9 integration 殷啟聰 | Kai-Chung Yan <seamlikok@gmail.com> - 2017-10-22 17:30 +0200
        Re: OpenJFX 9 integration Markus Koschany <apo@debian.org> - 2017-10-22 21:00 +0200
          Re: OpenJFX 9 integration Mykola Nikishov <mn@mn.com.ua> - 2017-10-22 23:00 +0200
            Re: OpenJFX 9 integration Markus Koschany <apo@debian.org> - 2017-10-22 23:10 +0200
      Re: OpenJFX 9 integration Emmanuel Bourg <ebourg@apache.org> - 2017-10-23 01:10 +0200
        Re: OpenJFX 9 integration 殷啟聰 | Kai-Chung Yan <seamlikok@gmail.com> - 2017-10-24 09:10 +0200
          Re: OpenJFX 9 integration Emmanuel Bourg <ebourg@apache.org> - 2017-10-24 12:20 +0200
        Re: OpenJFX 9 integration Sebastiaan Couwenberg <sebastic@xs4all.nl> - 2018-04-04 07:20 +0200
          Re: OpenJFX 9 integration Matthias Klose <doko@debian.org> - 2018-04-04 10:00 +0200
            Re: OpenJFX 9 integration Emmanuel Bourg <ebourg@apache.org> - 2018-04-04 10:30 +0200
              Re: OpenJFX 9 integration Bas Couwenberg <sebastic@xs4all.nl> - 2018-04-04 11:20 +0200
                Re: OpenJFX 9 integration tony mancill <tmancill@debian.org> - 2018-04-04 15:50 +0200
              Re: OpenJFX 9 integration Markus Koschany <apo@debian.org> - 2018-04-04 16:10 +0200
    Re: OpenJFX 9 integration David Goodenough <david.goodenough@linkchoose.co.uk> - 2017-10-24 07:40 +0200

#10078 — OpenJFX 9 integration

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.

What do you think?

Emmanuel Bourg

[1] https://anonscm.debian.org/cgit/pkg-java/openjfx9.git
[2]
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-IntegrationwithOpenJDK9

[toc] | [next] | [standalone]

#10093

[Multipart message — attachments visible in raw view] — view raw

Hello Emmanuel,

Thank you for your hard work on OpenJFX!

Although I like Plan C, it has more issues like:

  * Circular build-dependency between openjdk and openjfx (or there is already one?)
  * Strange versioning pattern of openjdk rebuilds. (9~b181-5+<openjfx-version> vs 9~b181-5+b1)

Looks like the extensibility of JRE itself has become a bit worse?

Emmanuel Bourg 於 2017年10月12日 19:13 寫道:
> 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.
>
> What do you think?
>
> Emmanuel Bourg
>
> [1] https://anonscm.debian.org/cgit/pkg-java/openjfx9.git
> [2]
> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-IntegrationwithOpenJDK9
>

[toc] | [prev] | [next] | [standalone]

#10094

Le 17/10/2017 à 17:18, 殷啟聰 | Kai-Chung Yan a écrit :

> Although I like Plan C, it has more issues like:
> 
>   * Circular build-dependency between openjdk and openjfx (or there is already one?)

True but I don't think this is really a problem. The OpenJFX integration
could be disabled in openjdk-9 when building the package for the first
time on an architecture.

>   * Strange versioning pattern of openjdk rebuilds. (9~b181-5+<openjfx-version> vs 9~b181-5+b1)

I think the openjdk-9 version will simply not include the openjfx
version. The version of openjfx could be documented with the Built-Using
field.

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#10105

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

[toc] | [prev] | [next] | [standalone]

#10106

[Multipart message — attachments visible in raw view] — view raw

(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
>

[toc] | [prev] | [next] | [standalone]

#10108

[Multipart message — attachments visible in raw view] — view raw

Am 22.10.2017 um 17:27 schrieb 殷啟聰 | Kai-Chung Yan:
> (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.

Indeed D is not really an option and would be the end for Netbeans,
pdfsam, mediathekview and a future Eclipse version. I wonder how other
distributions like Fedora will deal with this issue in the future.

Markus

[toc] | [prev] | [next] | [standalone]

#10109

Markus Koschany <apo@debian.org> writes:

> Indeed D is not really an option and would be the end for Netbeans,
> pdfsam, mediathekview and a future Eclipse version. I wonder how other
> distributions like Fedora will deal with this issue in the future.

Markus, could you elaborate on 'a future Eclipse version'? I'm not aware
of any work being done on moving Eclipse platform to require JavaFX.

-- 
Mykola
https://manandbytes.github.io/

[toc] | [prev] | [next] | [standalone]

#10110

[Multipart message — attachments visible in raw view] — view raw

Am 22.10.2017 um 21:32 schrieb Mykola Nikishov:
> Markus Koschany <apo@debian.org> writes:
> 
>> Indeed D is not really an option and would be the end for Netbeans,
>> pdfsam, mediathekview and a future Eclipse version. I wonder how other
>> distributions like Fedora will deal with this issue in the future.
> 
> Markus, could you elaborate on 'a future Eclipse version'? I'm not aware
> of any work being done on moving Eclipse platform to require JavaFX.

Oh, I was more thinking about developing JavaFX applications with
Eclipse and without OpenJFX we would lose this ability.

[toc] | [prev] | [next] | [standalone]

#10111

Le 22/10/2017 à 12:57, Matthias Klose a écrit :

> 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?

I don't know. At least they are aware that OpenJFX fails to build with a
raw OpenJDK not including OpenJFX and they seem willing to address that
issue.


> (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.

Ok let's do that. The name of the package is open to discussion, as well
as how the OpenJFX files will be distributed between the openjdk-9-*
packages.

For the name, since OpenJFX is now clearly becoming an extension of
OpenJDK I was thinking about naming the source package
"openjdk-9-openjfx" or "openjdk-9-jfx", and appending "-build" to the
binary package. What would be a good location for installing the build
directory?

Regarding the distribution of the files, the lib/modules file of
openjdk-9-jre-headless will now contain the JavaFX classes, but the
native libraries should go into openjdk-9-jre. javapackager and
ant-javafx.jar would go into openjdk-9-jdk-headless.

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#10113

[Multipart message — attachments visible in raw view] — view raw

Why not keep the source package name as "openjfx" and then name the binary package "openjdk-9-jfx"?

Emmanuel Bourg 於 2017年10月23日 07:00 寫道:
> Le 22/10/2017 à 12:57, Matthias Klose a écrit :
>
>> 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?
> I don't know. At least they are aware that OpenJFX fails to build with a
> raw OpenJDK not including OpenJFX and they seem willing to address that
> issue.
>
>
>> (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.
> Ok let's do that. The name of the package is open to discussion, as well
> as how the OpenJFX files will be distributed between the openjdk-9-*
> packages.
>
> For the name, since OpenJFX is now clearly becoming an extension of
> OpenJDK I was thinking about naming the source package
> "openjdk-9-openjfx" or "openjdk-9-jfx", and appending "-build" to the
> binary package. What would be a good location for installing the build
> directory?
>
> Regarding the distribution of the files, the lib/modules file of
> openjdk-9-jre-headless will now contain the JavaFX classes, but the
> native libraries should go into openjdk-9-jre. javapackager and
> ant-javafx.jar would go into openjdk-9-jdk-headless.
>
> Emmanuel Bourg
>

[toc] | [prev] | [next] | [standalone]

#10114

Le 24/10/2017 à 09:09, 殷啟聰 | Kai-Chung Yan a écrit :
> Why not keep the source package name as "openjfx" and then name the binary package "openjdk-9-jfx"?

src:openjfx can't be reused for OpenJFX 9, because I need it to backport
OpenJFX 8 updates for Stretch.

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#10389

On 10/23/2017 01:00 AM, Emmanuel Bourg wrote:
> Le 22/10/2017 à 12:57, Matthias Klose a écrit :
>> (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.
> 
> Ok let's do that. The name of the package is open to discussion, as well
> as how the OpenJFX files will be distributed between the openjdk-9-*
> packages.
> 
> For the name, since OpenJFX is now clearly becoming an extension of
> OpenJDK I was thinking about naming the source package
> "openjdk-9-openjfx" or "openjdk-9-jfx", and appending "-build" to the
> binary package. What would be a good location for installing the build
> directory?
> 
> Regarding the distribution of the files, the lib/modules file of
> openjdk-9-jre-headless will now contain the JavaFX classes, but the
> native libraries should go into openjdk-9-jre. javapackager and
> ant-javafx.jar would go into openjdk-9-jdk-headless.

Can progress be made with the above? Or is it blocked on lack of
feedback from Matthias?

A number of packages fail to build now that openjdk-9 is the default-jdk
and are forced to disable openjfx support to keep their packages in testing.

Kind Regards,

Bas

[toc] | [prev] | [next] | [standalone]

#10390

On 04.04.2018 07:10, Sebastiaan Couwenberg wrote:
> On 10/23/2017 01:00 AM, Emmanuel Bourg wrote:
>> Le 22/10/2017 à 12:57, Matthias Klose a écrit :
>>> (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.
>>
>> Ok let's do that. The name of the package is open to discussion, as well
>> as how the OpenJFX files will be distributed between the openjdk-9-*
>> packages.
>>
>> For the name, since OpenJFX is now clearly becoming an extension of
>> OpenJDK I was thinking about naming the source package
>> "openjdk-9-openjfx" or "openjdk-9-jfx", and appending "-build" to the
>> binary package. What would be a good location for installing the build
>> directory?
>>
>> Regarding the distribution of the files, the lib/modules file of
>> openjdk-9-jre-headless will now contain the JavaFX classes, but the
>> native libraries should go into openjdk-9-jre. javapackager and
>> ant-javafx.jar would go into openjdk-9-jdk-headless.
> 
> Can progress be made with the above? Or is it blocked on lack of
> feedback from Matthias?
> 
> A number of packages fail to build now that openjdk-9 is the default-jdk
> and are forced to disable openjfx support to keep their packages in testing.

I wouldn't spend any time on that. We are moving towards 11, and openjfx is
split out there. So yes, maybe packages have to drop openjfx support for some time.

Matthias

[toc] | [prev] | [next] | [standalone]

#10391

Le 04/04/2018 à 09:48, Matthias Klose a écrit :

> I wouldn't spend any time on that. We are moving towards 11, and openjfx is
> split out there. So yes, maybe packages have to drop openjfx support for some time.

+1, Oracle has announced last month [1] that JavaFX would be decoupled
from Java 11, so my integration plan with the OpenJDK package is moot.

I wonder if it's worth uploading a new openjfx-9 package now (FTP
masters would have to review a fairly big package that would be obsolete
on arrival) or waiting for the 11 release in September before moving on.

Emmanuel Bourg

[1]
https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates

[toc] | [prev] | [next] | [standalone]

#10392

On 2018-04-04 10:24, Emmanuel Bourg wrote:
> Le 04/04/2018 à 09:48, Matthias Klose a écrit :
> 
>> I wouldn't spend any time on that. We are moving towards 11, and 
>> openjfx is
>> split out there. So yes, maybe packages have to drop openjfx support 
>> for some time.
> 
> +1, Oracle has announced last month [1] that JavaFX would be decoupled
> from Java 11, so my integration plan with the OpenJDK package is moot.
> 
> I wonder if it's worth uploading a new openjfx-9 package now (FTP
> masters would have to review a fairly big package that would be 
> obsolete
> on arrival) or waiting for the 11 release in September before moving 
> on.

It's probably not worth it, although having at least 5 months until the 
openjfx RC bugs can be fixed (when the package doesn't work without it) 
is a bit long.

I'm personally fine with disabling openjfx in josm for the time being.

Kind Regards,

Bas

[toc] | [prev] | [next] | [standalone]

#10393

[Multipart message — attachments visible in raw view] — view raw

On Wed, Apr 04, 2018 at 11:15:59AM +0200, Bas Couwenberg wrote:
> On 2018-04-04 10:24, Emmanuel Bourg wrote:
> > Le 04/04/2018 à 09:48, Matthias Klose a écrit :
> > 
> > > I wouldn't spend any time on that. We are moving towards 11, and
> > > openjfx is
> > > split out there. So yes, maybe packages have to drop openjfx support
> > > for some time.
> > 
> > +1, Oracle has announced last month [1] that JavaFX would be decoupled
> > from Java 11, so my integration plan with the OpenJDK package is moot.
> > 
> > I wonder if it's worth uploading a new openjfx-9 package now (FTP
> > masters would have to review a fairly big package that would be obsolete
> > on arrival) or waiting for the 11 release in September before moving on.
> 
> It's probably not worth it, although having at least 5 months until the
> openjfx RC bugs can be fixed (when the package doesn't work without it) is a
> bit long.
> 
> I'm personally fine with disabling openjfx in josm for the time being.

On behalf of jabref 4.x and the new r-deps we have been working to get
into Debian, ouch!  Think we'll have to find some other way (PPAs or
something) to support JabRef users.

That said, I understand the decision.  My question is how much time do
we think we'll have between the acceptance of an openjfx package and the
release.  6 months?  A year?

Thanks,
tony

[toc] | [prev] | [next] | [standalone]

#10394

[Multipart message — attachments visible in raw view] — view raw

Am 04.04.2018 um 10:24 schrieb Emmanuel Bourg:
> Le 04/04/2018 à 09:48, Matthias Klose a écrit :
> 
>> I wouldn't spend any time on that. We are moving towards 11, and openjfx is
>> split out there. So yes, maybe packages have to drop openjfx support for some time.
> 
> +1, Oracle has announced last month [1] that JavaFX would be decoupled
> from Java 11, so my integration plan with the OpenJDK package is moot.
> 
> I wonder if it's worth uploading a new openjfx-9 package now (FTP
> masters would have to review a fairly big package that would be obsolete
> on arrival) or waiting for the 11 release in September before moving on.

Unfortunately disabling JavaFX is not an option for packages that
heavily rely on it, e.g. pdfsam or netbeans. As a workaround I could
force OpenJDK 8 for those packages to make them usable again provided
OpenJDK 8 will not be removed before Java 11 is ready.

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#10112

[Multipart message — attachments visible in raw view] — view raw

On Thursday, 12 October 2017 13:13:44 BST 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.
> 
> What do you think?
> 
> Emmanuel Bourg
> 
> [1] https://anonscm.debian.org/cgit/pkg-java/openjfx9.git
> [2]
> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJ
> FX-IntegrationwithOpenJDK9
I read on one of the Oracle lists that they were thinking that OpenJFX should 
be merged into OpenJDK 10.  

So maybe moving in the direction of merging the two is the better route.

David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.java

csiph-web