Re: native libs in modules

[Paul Ray Russell]

>* I'm thinking about this issue now because I quite like JavaFX and its
*>* future is clearly as a regular Java library, albeit a big one, distributed
*>* either via (not ideal) an SDK or (better) a set of regular libraries
*>* published to a Maven repository.
*>

+1 for this. (-1 for cross posting)

The OP is right IMO, hacky jars containing native payloads seem common.

Re: native libs in modules

[Johan Vos]

FYI, the native-libs-in-mods issue is being discussed on the panama-dev
list as well:
http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001543.html

- Johan

On Tue, May 1, 2018 at 6:01 PM Kevin Rushforth 
wrote:

>
>
> On 4/30/2018 8:58 AM, Michael Paus wrote:
> > 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?
>
> This is somewhat tangential to the issue of how to ship the native
> libraries and platform-specific classes for each platform. While it is
> true that the prism_es2 classes and native libraries are compiled on
> Windows platforms, they aren't part of the build artifacts, and aren't
> ever run or tested at all. So it wouldn't be as simple as shipping
> something that is currently not shipped. Doing so would require a bit of
> work, not to mention a bug tail since OpenGL drivers for Windows tend to
> be buggy (especially for Intel HD). As for WebGL, it would probably make
> more sense to use ANGLE to translate to D3D on Windows than try to rely
> on OpenGL being available everywhere.
>
> -- Kevin
>
> > Michael
>
>

Re: native libs in modules

[Kevin Rushforth]

[including Alan and Mandy]

This came up briefly in a thread sent to jigsaw-dev [1], but with no 
real conclusion. I agree that it would be good to get a recommendation 
from the Jigsaw team.


After thinking about it more, here are my preferences:

* From the developer's point of view, they shouldn't have to know or 
care that some of our modules have platform-specific native code and 
others do not. Ideally, all an app developer should need is to declare a 
dependency on the needed module(s). Something like this:


    'javafx:javafx.controls:11'
    'javafx:javafx.graphics:11'   (although controls will depend on 
graphics, so this should be optional)


* For maven, the pom file should take care of downloading the jar 
file(s) for the specific platform; not sure if that is possible for 
gradle dependencies, but it would be ideal.


* For each module, we can package up the natives in one of two ways:

A) create a separate jar file per platform with the native code and the 
modular jar both in the same jar file. something like:


javafx-graphics-win-x64.jar
javafx-graphics-linux-x64.jar
javafx-graphics-osx-x64.jar

B) create one platform-independent modular jar file with all classes for 
all platforms, and also a separate jar per platform just for the native 
libraries:


javafx-graphics.jar  (with classes for all platforms)
javafx-graphics-natives-win-x64.jar
javafx-graphics-natives-linux-x64.jar
javafx-graphics-natives-osx-x64.jar

For either option there will need to be code that unpacks the natives.

I prefer option A if feasible, as I think it simplifies the build, 
hopefully without unduly complicating anything else. If it isn't 
feasible, then option B might be a good fallback.


Comments?

-- Kevin

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-April/013762.html


On 5/1/2018 5:34 AM, Johan Vos wrote:

I'd love to hear a general recommendation from the jigsaw team as well.
Clearly, there are a number of solutions, and as a developer, I easily 
get confused if some frameworks do it with option A and others with 
option B.

So what is the preferred approach in general?

It seems (given the large size of the webkit native library) there is 
a growing consensus here for bundling native code inside 
platform-specific jars?


- Johan

On Tue, May 1, 2018 at 7:38 AM Phil Race > wrote:


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

[Johan Vos]

I'd love to hear a general recommendation from the jigsaw team as well.
Clearly, there are a number of solutions, and as a developer, I easily get
confused if some frameworks do it with option A and others with option B.
So what is the preferred approach in general?

It seems (given the large size of the webkit native library) there is a
growing consensus here for bundling native code inside platform-specific
jars?

- Johan

On Tue, May 1, 2018 at 7:38 AM Phil Race  wrote:

> 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

[Phil Race]

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

[Kevin Rushforth]

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

[Paul Ray Russell]

 >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

[Johan Vos]

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 <kevin.rushfo...@oracle.com>
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, <openjfx-dev-requ...@openjdk.java.net> 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 <johan@gluonhq.com>
> >> To: "openjfx-dev@openjdk.java.net List" <openjfx-dev@openjdk.java.net>
> >> Subject: native libs in modules
> >> Message-ID:
> >>  <CABxFH2EBg3w6Nf3ER5pBW4uhvodiL1Ei_7yEXaxN33eEJ78Xkw@mail.
> >> 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.

Re: native libs in modules

[Michael Paus]

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

[Glenn Holmer]

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

[Kevin Rushforth]

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, <openjfx-dev-requ...@openjdk.java.net> 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 <johan@gluonhq.com>
To: "openjfx-dev@openjdk.java.net List" <openjfx-dev@openjdk.java.net>
Subject: native libs in modules
Message-ID:
 <CABxFH2EBg3w6Nf3ER5pBW4uhvodiL1Ei_7yEXaxN33eEJ78Xkw@mail.
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 <t...@tbee.org>
To: openjfx-dev@openjdk.java.net
Subject: WaitForPaintPulse
Message-ID: <eadb4e62-e310-c0cb-da47-50649b647...@tbee.org>
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 <philip.r...@oracle.com>
To: Johan Vos <johan@gluonhq.com>
Cc: "openjfx-dev@openjdk.java.net List" <openjfx-dev@openjdk.java.net>
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.
de

Re: native libs in modules

[Michael Dever]

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

[Paul Ray Russell]

 >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, <openjfx-dev-requ...@openjdk.java.net> 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 <johan@gluonhq.com>
> To: "openjfx-dev@openjdk.java.net List" <openjfx-dev@openjdk.java.net>
> Subject: native libs in modules
> Message-ID:
> <CABxFH2EBg3w6Nf3ER5pBW4uhvodiL1Ei_7yEXaxN33eEJ78Xkw@mail.
> 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 <t...@tbee.org>
> To: openjfx-dev@openjdk.java.net
> Subject: WaitForPaintPulse
> Message-ID: <eadb4e62-e310-c0cb-da47-50649b647...@tbee.org>
> 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 <philip.r...@oracle.com>
> To: Johan Vos <johan@gluonhq.com>
> Cc: "openjfx-dev@openjdk.java.net List" <openjfx-dev@openjdk.java.net>
> 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.

Re: native libs in modules

[Philip Race]

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 packages acrosss modules which is 
what it

would probably mean.

-phil.


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