native libs in modules

Mon Apr 30 15:29:57 UTC 2018

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-request at openjdk.java.net> wrote:
>
>> Send openjfx-dev mailing list submissions to
>>          openjfx-dev at 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-request at openjdk.java.net
>>
>> You can reach the person managing the list at
>>          openjfx-dev-owner at 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 +0000
>> From: Johan Vos <johan.vos at gluonhq.com>
>> To: "openjfx-dev at openjdk.java.net List" <openjfx-dev at openjdk.java.net>
>> Subject: native libs in modules
>> Message-ID:
>>          <CABxFH2EBg3w6Nf3ER5pBW4uhvodiL1Ei_7yEXaxN33eEJ78Xkw at 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 <tbee at tbee.org>
>> To: openjfx-dev at openjdk.java.net
>> Subject: WaitForPaintPulse
>> Message-ID: <eadb4e62-e310-c0cb-da47-50649b6479cd at 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.race at oracle.com>
>> To: Johan Vos <johan.vos at gluonhq.com>
>> Cc: "openjfx-dev at openjdk.java.net List" <openjfx-dev at openjdk.java.net>
>> Subject: Re: native libs in modules
>> Message-ID: <5AE652EE.8080606 at 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 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
>>
>> End of openjfx-dev Digest, Vol 77, Issue 28
>> *******************************************
>>