>* 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
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
[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
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
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
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
>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
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 replyin
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.
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."
t;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
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) cont
it 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)
>
>
>
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
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
15 matches
Mail list logo