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 +0000
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.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
*******************************************