Re: native libs in modules
You are describing the situation today and making it into a contract. You need to be sure that it is policed and enforceable. Meaning there need to be tests to ensure it stays that way and that it is not an unreasonable constraint on changes in the platform. Also what if anything do the jigsaw team recommend ? -Phil. > On Apr 30, 2018, at 4:07 PM, Kevin Rushforth > wrote: > > The native libraries are quite large -- especially jfxwebkit -- and it does > seem better to have per-platform jar files, at least for the native > libraries. The following modules could be platform-independent since they > have no natives: > > javafx.base > javafx.controls > javafx.fxml > javafx.swing > > We would just need to test that the set of modular jar files for each > platform are the same, and then pick one (Linux?) to use for generating the > platform-independent jar files. > > The following modules have native libraries: > > javafx.graphics (*) > javafx.media (*) > javafx.web > > (*) - also has some differences in the set of class files that are included > depending on the platform > > So per-platform versions of the above would be needed to accommodate the > different native libraries. > > If it would help, the .class files could be always included for all > platforms, but there would be some additional effort to make this work. Also, > it might be just as easy to have the class files and the natives in one > downloaded jar file per platform, since at least the natives need to be > platform-independent. I'm far from a maven expert, though, so I don't really > know for sure which path is easier. > > -- Kevin > > >> On 4/30/2018 9:44 AM, Paul Ray Russell wrote: >> >I'm not sure I understand the question about platform-specific jar files, >> >> Last time I worked on native specifics (which was to package up RXTX dlls >> for different OSs / in 64/32 bit) The easiest solution for pure Maven >> builds seemed to be, to package DLLs inside a jar. We then used a profile >> to control which DLL's were grabbed in different cases. And surely for this >> specific case, it would be better to split the native specifics into >> separate jars per OS to avoid a huge cross-OS download? >
Re: native libs in modules
The native libraries are quite large -- especially jfxwebkit -- and it does seem better to have per-platform jar files, at least for the native libraries. The following modules could be platform-independent since they have no natives: javafx.base javafx.controls javafx.fxml javafx.swing We would just need to test that the set of modular jar files for each platform are the same, and then pick one (Linux?) to use for generating the platform-independent jar files. The following modules have native libraries: javafx.graphics (*) javafx.media (*) javafx.web (*) - also has some differences in the set of class files that are included depending on the platform So per-platform versions of the above would be needed to accommodate the different native libraries. If it would help, the .class files could be always included for all platforms, but there would be some additional effort to make this work. Also, it might be just as easy to have the class files and the natives in one downloaded jar file per platform, since at least the natives need to be platform-independent. I'm far from a maven expert, though, so I don't really know for sure which path is easier. -- Kevin On 4/30/2018 9:44 AM, Paul Ray Russell wrote: >I'm not sure I understand the question about platform-specific jar files, Last time I worked on native specifics (which was to package up RXTX dlls for different OSs / in 64/32 bit) The easiest solution for pure Maven builds seemed to be, to package DLLs inside a jar. We then used a profile to control which DLL's were grabbed in different cases. And surely for this specific case, it would be better to split the native specifics into separate jars per OS to avoid a huge cross-OS download?
[8u] Review request: 8201619: [TESTBUG] Bad HG merge causes some web tests to be skipped by mistake
Murali, Please review this simple test-only fix to correct a bad merge: https://bugs.openjdk.java.net/browse/JDK-8201619 http://cr.openjdk.java.net/~kcr/8201619/webrev/ This only affects 8u-dev, since the merge in questions was done when merging changes from 8u171 into 8u172. -- Kevin
Re: native libs in modules
>I'm not sure I understand the question about platform-specific jar files, Last time I worked on native specifics (which was to package up RXTX dlls for different OSs / in 64/32 bit) The easiest solution for pure Maven builds seemed to be, to package DLLs inside a jar. We then used a profile to control which DLL's were grabbed in different cases. And surely for this specific case, it would be better to split the native specifics into separate jars per OS to avoid a huge cross-OS download?
Re: native libs in modules
We currently already have classes in distributions that are not relevant to that specific distribution. The com.sun.javafx.iio.ios.IosImageLoader is part of the Linux distribution, for example (it is directly referenced from the ImageLoader although it could be invoked via Reflection). But it is even more complicated than that. We have * java code for a specific platform (mac/linux/win/others) * native code for a specific platform (mac/linux/win/others) * java and native code for specific configurations (e.g. prism pipelines) The latter is sometimes related to platforms (e.g. D3D on windows only) and sometimes not. This allows for a very granular configuration, where only the relevant code is downloaded (e.g. prism-es2 for linux). In many cases though, an umbrella artefact is created that contains enough information for maven and gradle to download the correct dependencies then. I'm not sure I understand the question about platform-specific jar files, but typically this is done using classifiers, e.g. javafx javafx.graphics 11.0.0 linux-x86 or with gradle: compile 'javafx:javafx.graphics:11.0.0:linux-x86' The specified module can contain the native code + platform-specific java class files (in a platform-specific package in order not to have 2 modules with the same package) - Johan On Mon, Apr 30, 2018 at 5:40 PM Kevin Rushforth wrote: > Either way I suspect the native libs will need to be packaged in a jar > file. > > As Phil mentions, there are per-platform .class files as well as > per-platform native libraries. One thing to note is that unlike the JDK > build, all class files for Windows, Linux, and Mac are set up to be > built (but not shipped) on all three platforms, so it might be possible > to create a jar file that would be the same on all three platforms. I > don't know how feasible it would be or whether that the right direction > to take or not. > > This will need some more thought and discussion. How does SWT handle it? > In our build.gradle file we refer to the actual platform-specific jar > files (which is really just a zip file with another .jar that has the > class files, plus the native libraries), so I don't know how an > application using Maven would refer to SWT. > > -- Kevin > > > On 4/30/2018 8:07 AM, Paul Ray Russell wrote: > > >If you use gradle or maven, the same should be achieved using e.g. > >> dependencies { > >> compile 'javafx:javafx.controls:11.0.0' > >> } > > So does this mean there a plan to offer this as pure Maven build - or > will > > it require Gradle? If pure Maven, are the native libs going to be > packaged > > inside a JAR file? > > > > Best, > > Paul > > > > > > On 30 April 2018 at 13:00, wrote: > > > >> Send openjfx-dev mailing list submissions to > >> openjfx-dev@openjdk.java.net > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > >> or, via email, send a message with subject or body 'help' to > >> openjfx-dev-requ...@openjdk.java.net > >> > >> You can reach the person managing the list at > >> openjfx-dev-ow...@openjdk.java.net > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of openjfx-dev digest..." > >> > >> > >> Today's Topics: > >> > >> 1. native libs in modules (Johan Vos) > >> 2. WaitForPaintPulse (Tom Eugelink) > >> 3. Re: native libs in modules (Philip Race) > >> > >> > >> -- > >> > >> Message: 1 > >> Date: Sun, 29 Apr 2018 17:05:51 + > >> From: Johan Vos > >> To: "openjfx-dev@openjdk.java.net List" > >> Subject: native libs in modules > >> Message-ID: > >> >> gmail.com> > >> Content-Type: text/plain; charset="UTF-8" > >> > >> Now that the OpenJFX SDK that works with Java 11 is about to be > released in > >> EA, we should think about releasing the modules. > >> > >> In case you download the OpenJFX SDK, running an app goes like > >> java --module-path $OPENJFXSDK/lib --add-modules javafx.controls > your.app > >> > >> If you use gradle or maven, the same should be achieved using e.g. > >> dependencies { > >> compile 'javafx:javafx.controls:11.0.0' > >> } > >> > >> (ignore the naming and versioning for now) > >> > >> This will download the javafx controls module and its dependencies from > >> e.g. maven central. The javafx controls module info declares a requires > >> entry for javafx.base and javafx.graphics so those will be downloaded. > >> > >> The question is how the native libs should be downloaded. It is > possible to > >> bundle the native libs with the modules, but there are a number of > options > >> for dealing with platform-specific libraries: > >> > >> 1. javafx.graphics contains all native libraries for all platforms. > >> 2. a generic javafx.graphics module containing java code only, plus N > >> platform-specific modules (or jar) containi
Re: native libs in modules
Am 30.04.18 um 17:29 schrieb Kevin Rushforth: One thing to note is that unlike the JDK build, all class files for Windows, Linux, and Mac are set up to be built (but not shipped) on all three platforms, so it might be possible to create a jar file that would be the same on all three platforms. I don't know how feasible it would be or whether that the right direction to take or not. If possible, I would like to see a change in this policy to not ship certain fragments of the build. Especially I would like to have the possibility to use a JavaFX based on OpenGL on Windows too. This would make Java truly cross-platform and might offer a lot of possibilities for better integration of external graphics tools like for example tools based on JOGL. It might also offer the possibility to support WebGL in the WebView in the future so that this gap can be closed too. Am I just dreaming? What do others think? Michael
Re: native libs in modules
On 04/30/2018 10:12 AM, Michael Dever wrote: > What IDE are you all using. > Clearly, it can't be Netbeans. > That's still stuck on Java 8. http://netbeans.apache.org/download/index.html -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe."
Re: native libs in modules
Either way I suspect the native libs will need to be packaged in a jar file. As Phil mentions, there are per-platform .class files as well as per-platform native libraries. One thing to note is that unlike the JDK build, all class files for Windows, Linux, and Mac are set up to be built (but not shipped) on all three platforms, so it might be possible to create a jar file that would be the same on all three platforms. I don't know how feasible it would be or whether that the right direction to take or not. This will need some more thought and discussion. How does SWT handle it? In our build.gradle file we refer to the actual platform-specific jar files (which is really just a zip file with another .jar that has the class files, plus the native libraries), so I don't know how an application using Maven would refer to SWT. -- Kevin On 4/30/2018 8:07 AM, Paul Ray Russell wrote: >If you use gradle or maven, the same should be achieved using e.g. dependencies { compile 'javafx:javafx.controls:11.0.0' } So does this mean there a plan to offer this as pure Maven build - or will it require Gradle? If pure Maven, are the native libs going to be packaged inside a JAR file? Best, Paul On 30 April 2018 at 13:00, wrote: Send openjfx-dev mailing list submissions to openjfx-dev@openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev or, via email, send a message with subject or body 'help' to openjfx-dev-requ...@openjdk.java.net You can reach the person managing the list at openjfx-dev-ow...@openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of openjfx-dev digest..." Today's Topics: 1. native libs in modules (Johan Vos) 2. WaitForPaintPulse (Tom Eugelink) 3. Re: native libs in modules (Philip Race) -- Message: 1 Date: Sun, 29 Apr 2018 17:05:51 + From: Johan Vos To: "openjfx-dev@openjdk.java.net List" Subject: native libs in modules Message-ID: Content-Type: text/plain; charset="UTF-8" Now that the OpenJFX SDK that works with Java 11 is about to be released in EA, we should think about releasing the modules. In case you download the OpenJFX SDK, running an app goes like java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app If you use gradle or maven, the same should be achieved using e.g. dependencies { compile 'javafx:javafx.controls:11.0.0' } (ignore the naming and versioning for now) This will download the javafx controls module and its dependencies from e.g. maven central. The javafx controls module info declares a requires entry for javafx.base and javafx.graphics so those will be downloaded. The question is how the native libs should be downloaded. It is possible to bundle the native libs with the modules, but there are a number of options for dealing with platform-specific libraries: 1. javafx.graphics contains all native libraries for all platforms. 2. a generic javafx.graphics module containing java code only, plus N platform-specific modules (or jar) containing the native code. An example of how this is used is ND4J: https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j- native/1.0.0-SNAPSHOT/ To make it more complex, there are a number of options for e.g. prims leading to a number of native libs. Do we want to include all relevant options for all platforms? - Johan -- Message: 2 Date: Sun, 29 Apr 2018 20:25:02 +0200 From: Tom Eugelink To: openjfx-dev@openjdk.java.net Subject: WaitForPaintPulse Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed Is there a way in J9+ to wait for a paint pulse? I'm having problems getting my unit tests stable. Tom -- Message: 3 Date: Sun, 29 Apr 2018 16:19:10 -0700 From: Philip Race To: Johan Vos Cc: "openjfx-dev@openjdk.java.net List" Subject: Re: native libs in modules Message-ID: <5ae652ee.8080...@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed On 4/29/18, 10:05 AM, Johan Vos wrote: Now that the OpenJFX SDK that works with Java 11 is about to be released in EA, we should think about releasing the modules. In case you download the OpenJFX SDK, running an app goes like java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app If you use gradle or maven, the same should be achieved using e.g. dependencies { compile 'javafx:javafx.controls:11.0.0' } (ignore the naming and versioning for now) This will download the javafx controls module and its dependencies from e.g. maven central. The javafx controls module info declares a requires entry for javafx.base and javafx.graphics so those will be downloaded. The question is how the native libs should be downloaded. It is possible to bundle the native l
Re: native libs in modules
What IDE are you all using. Clearly, it can't be Netbeans. That's still stuck on Java 8. On Apr 29, 2018, at 1:05 PM, Johan Vos wrote: Now that the OpenJFX SDK that works with Java 11 is about to be released in EA, we should think about releasing the modules. In case you download the OpenJFX SDK, running an app goes like java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app If you use gradle or maven, the same should be achieved using e.g. dependencies { compile 'javafx:javafx.controls:11.0.0' } (ignore the naming and versioning for now) This will download the javafx controls module and its dependencies from e.g. maven central. The javafx controls module info declares a requires entry for javafx.base and javafx.graphics so those will be downloaded. The question is how the native libs should be downloaded. It is possible to bundle the native libs with the modules, but there are a number of options for dealing with platform-specific libraries: 1. javafx.graphics contains all native libraries for all platforms. 2. a generic javafx.graphics module containing java code only, plus N platform-specific modules (or jar) containing the native code. An example of how this is used is ND4J: https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j-native/1.0.0-SNAPSHOT/ To make it more complex, there are a number of options for e.g. prims leading to a number of native libs. Do we want to include all relevant options for all platforms? - Johan
Re: native libs in modules
>If you use gradle or maven, the same should be achieved using e.g. >dependencies { >compile 'javafx:javafx.controls:11.0.0' >} So does this mean there a plan to offer this as pure Maven build - or will it require Gradle? If pure Maven, are the native libs going to be packaged inside a JAR file? Best, Paul On 30 April 2018 at 13:00, wrote: > Send openjfx-dev mailing list submissions to > openjfx-dev@openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-requ...@openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-ow...@openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > >1. native libs in modules (Johan Vos) >2. WaitForPaintPulse (Tom Eugelink) >3. Re: native libs in modules (Philip Race) > > > -- > > Message: 1 > Date: Sun, 29 Apr 2018 17:05:51 + > From: Johan Vos > To: "openjfx-dev@openjdk.java.net List" > Subject: native libs in modules > Message-ID: > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Now that the OpenJFX SDK that works with Java 11 is about to be released in > EA, we should think about releasing the modules. > > In case you download the OpenJFX SDK, running an app goes like > java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app > > If you use gradle or maven, the same should be achieved using e.g. > dependencies { > compile 'javafx:javafx.controls:11.0.0' > } > > (ignore the naming and versioning for now) > > This will download the javafx controls module and its dependencies from > e.g. maven central. The javafx controls module info declares a requires > entry for javafx.base and javafx.graphics so those will be downloaded. > > The question is how the native libs should be downloaded. It is possible to > bundle the native libs with the modules, but there are a number of options > for dealing with platform-specific libraries: > > 1. javafx.graphics contains all native libraries for all platforms. > 2. a generic javafx.graphics module containing java code only, plus N > platform-specific modules (or jar) containing the native code. An example > of how this is used is ND4J: > https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j- > native/1.0.0-SNAPSHOT/ > > To make it more complex, there are a number of options for e.g. prims > leading to a number of native libs. Do we want to include all relevant > options for all platforms? > > - Johan > > > -- > > Message: 2 > Date: Sun, 29 Apr 2018 20:25:02 +0200 > From: Tom Eugelink > To: openjfx-dev@openjdk.java.net > Subject: WaitForPaintPulse > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > Is there a way in J9+ to wait for a paint pulse? I'm having problems > getting my unit tests stable. > > Tom > > > > > -- > > Message: 3 > Date: Sun, 29 Apr 2018 16:19:10 -0700 > From: Philip Race > To: Johan Vos > Cc: "openjfx-dev@openjdk.java.net List" > Subject: Re: native libs in modules > Message-ID: <5ae652ee.8080...@oracle.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > On 4/29/18, 10:05 AM, Johan Vos wrote: > > Now that the OpenJFX SDK that works with Java 11 is about to be released > in > > EA, we should think about releasing the modules. > > > > In case you download the OpenJFX SDK, running an app goes like > > java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app > > > > If you use gradle or maven, the same should be achieved using e.g. > > dependencies { > > compile 'javafx:javafx.controls:11.0.0' > > } > > > > (ignore the naming and versioning for now) > > > > This will download the javafx controls module and its dependencies from > > e.g. maven central. The javafx controls module info declares a requires > > entry for javafx.base and javafx.graphics so those will be downloaded. > > > > The question is how the native libs should be downloaded. It is possible > to > > bundle the native libs with the modules, but there are a number of > options > > for dealing with platform-specific libraries: > > > > 1. javafx.graphics contains all native libraries for all platforms. > > 2. a generic javafx.graphics module containing java code only, plus N > > platform-specific modules (or jar) containing the native code. An example > > of how this is used is ND4J: > > https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j- > native/1.0.0-SNAPSHOT/ > > The java code is platform-specific too .. so I don't see how #1 would > work and > #2 would seem to require some large amount of work and I don't think will > work either because you can't split