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 t
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 wo
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
>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 c
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 e
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."
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 n
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
>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 fi
10 matches
Mail list logo
