Re: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API

[Kevin Rushforth]

Most things are working with either mode (JDK 10 with qualified exports 
or JDK 11 without), although I do get a few test failures.


There is a serious issue with leakage into the public API that needs to 
be addressed before worrying about the failures, but I'll list the test 
failures at the end.


SwingNode.java:

This public class is part of the API. You cannot make any of the 
following fields public as this would leak implementation into public API:


+    public int swingPrefWidth;
+    public int swingPrefHeight;
+    public int swingMaxWidth;
+    public int swingMaxHeight;
+    public int swingMinWidth;
+    public int swingMinHeight;

+    public final Object getLightweightFrame() { return lwFrame; }

+    public final ReentrantLock paintLock = new ReentrantLock();

+    public boolean grabbed; // lwframe initiated grab

+    public void setImageBuffer(...)

+   public void setImageBounds(...);

+    public void repaintDirtyRegion(...)

+    public void ungrabFocus(boolean postUngrabEvent)

If you need to access them from other packages, you can either use the 
accessor pattern (this might be easiest) or else refactor it further to 
move more of this down to the implementation. I note that even though 
SwingNodeInterop is abstract, it can still have non-abstract methods if 
that helps in your refactoring.



SwingFXUtils.java

Same problem as SwingNode, although to a lesser extent. The following 
must not be public:


+    public static void runOnFxThread(Runnable runnable)
+    public static void runOnEDT(final Runnable r)
+    public static void runOnEDTAndWait(Object nestedLoopKey, Runnable r)
+    public static void leaveFXNestedLoop(Object nestedLoopKey)


JFXPanel is fine.

-

* System tests failures on Linux:

test.robot.javafx.embed.swing.SwingNodeJDialogTest > testJDialogAbove FAILED
    java.lang.AssertionError: JDialog is not above JavaFX stage 
expected: but 
was:


test.robot.javafx.embed.swing.SwingNodeJDialogTest > 
testNodeRemovalAfterShow FAILED
    java.lang.AssertionError: JDialog is not above JavaFX stage 
expected: but 
was:


test.robot.javafx.embed.swing.SwingNodeJDialogTest > 
testStageCloseAfterShow FAILED
    java.lang.AssertionError: JDialog is not above JavaFX stage 
expected: but 
was:


test.javafx.embed.swing.SwingNodeMemoryLeakTest > 
testSwingNodeMemoryLeak FAILED

    java.lang.AssertionError: expected:<10> but was:<9>
    at org.junit.Assert.fail(Assert.java:91)
    at org.junit.Assert.failNotEquals(Assert.java:645)
    at org.junit.Assert.assertEquals(Assert.java:126)
    at org.junit.Assert.assertEquals(Assert.java:470)
    at org.junit.Assert.assertEquals(Assert.java:454)
    at 
test.javafx.embed.swing.SwingNodeMemoryLeakTest.testSwingNodeMemoryLeak(SwingNodeMemoryLeakTest.java:97)


Two of these, SwingNodeJDialogTest.testNodeRemovalAfterShow and 
SwingNodeJDialogTest.testStageCloseAfterShow, also fail on Mac


-- Kevin


On 7/5/2018 11:29 PM, Prasanta Sadhukhan wrote:


My Bad. Please find modified webrev restoring the filter

http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.4/

Regards
Prasanta
On 7/6/2018 6:47 AM, Kevin Rushforth wrote:

One quick comment:

This no longer compiles with OpenJDK10. It looks like the logic to 
optionally filter out jdk.unsupported.desktop from javafx.swing's 
module-info.java got lost between the .2 and .3 versions.


-- Kevin


On 7/4/2018 4:35 AM, Prasanta Sadhukhan wrote:

Hi All,

Please review an enhancement to support openjfx swing 
interoperability once the dependancy of internal jdk classes are 
removed.
JDK-8202199  
provided a new "jdk.unsupported.desktop" module in JDK 11 that 
exports public API that is intended to be used by the javafx.swing 
module
and unbundled OpenJFX is now made to depend on these APIs to support 
interoperation
between Swing and JavaFX components to replace previous use of 
internal APIs when it was part of Oracle JDK.


Bug: https://bugs.openjdk.java.net/browse/JDK-8195811
webrev: http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.3/

Regards
Prasanta

Re: JavaFX 11 snapshots in maven sonatype

[Michael Paus]

Hi Johan,
many thanks for the clarifications.
Please find some more comments inline:

Am 06.07.18 um 14:54 schrieb Johan Vos:

Hi Michael,

Thanks for testing this.

You can avoid downloading all platform jars by specifying the 
javafx.platform with maven:


mvn -Djavafx.platform=mac clean package exec:java
I can confirm that this works as you said if the property is specified 
on the command line

but I am wondering why this does not work if you
set javafx.platform inside the pom.xml as a property like this

    
        mac
        ...
    

or if you specify the classifier explicitly.

    mac

or if you specify the property in the Maven settings.xml file.

In all these three cases Maven still downloads everything.


There is a rationale behind this:
maven would be able to detect the OS and make sure only the platform 
jars related to that OS are downloaded.
But that won't work with gradle. So we have this base pom that, unless 
javafx.platform is specified, will depend on all platforms, which will 
cause gradle to download the correct platform (and the others as well).
Now, for SNAPSHOTs this doesn't work with gradle (see previous mail) 
but that is another issue. For releases, this works with gradle.


I'm very open to suggestions on how to change this.

As for architectures: I would suggest we follow the approach of the 
excellent nd4j project and append the arch if used (see 
https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j-native/1.0.0-SNAPSHOT/ -- 
it even includes linux-x86_64-avx512)
This looks good to me but shouldn't we then use this architecture 
extension right from the beginning in order to avoid future confusion?


For Eclipse: by setting the {javafx.platform} variable somewhere, it 
will be avoided to download the other platforms.
What would be the right place to do that? As pointed out above the right 
place seems to be very sensitive.

But your error message seems to suggest something else:
 Error: JavaFX runtime components are missing, and are required to  
run this application


That is an issue I brought up somewhere else: 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021977.html
The Java launcher will check if the main class extends 
javafx.application.Application and if that is the case, it will do a 
hard check on the availability of the javafx.graphics module in the 
modulepath. If it can't find that, it will bail with the message 
above. So that is happening.



I was able to temporarily fix this by introducing a separate launcher class.

    package org.projavafx.javafx3d.hello3d;
    public class ShapesLauncher {
        public static void main(String[] args) {
            Shapes.main(args);
        }
    }

But this is a terrible hack.
This doesn't happen when you launch via maven, as maven is launching 
the application inside its own Java process -- hence the main class is 
a maven class, not extending javafx.application.Application.


The solution to this is somehow tell maven or eclipse to use modules. 
With gradle, we have a relative easy way to do this:

run {
    doFirst {
        jvmArgs = [
            '--module-path', classpath.asPath,
            '--add-modules', 'javafx.controls'
        ]
    classpath = sourceSets.main.output
    }
}

I doubt that this will help to set up the class/module path correctly 
when you import an external project into Eclipse.
(unfortunately, we can't use gradle due to that snapshot/platform 
issue, but I tested it with a release extension instead of a snapshot 
extension and then it works).


I would assume maven allows for a similar approach. In general, this 
is an issue not specific to JavaFX: how can you tell maven to use the 
artifacts as modules (e.g. set the correct module-path and add the 
modules).
That is absolutely true and to my opinion we are not doing ourselves a 
favor if we force people into using modules if the most common build 
tools are still not able to fully handle the module system in a 
consistent and correct manner.
The only thing that is JavaFX specific is that the Java launcher will 
exit if ((the main class extends Application) AND (no modules used)).


See 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021983.html for 
the discussion about this. I'm not 100% what the best approach is 
here. It sounds a bit unfair that you can only NOT use classpath when 
your main class extends javafx.application.Application, but the best 
approach is probably a fix in a maven plugin so that it works with 
modules (might already be there?)
How long are we going to wait for this to happen? My impression is that 
there still is not enough pressure on the tool providers because the 
majority of people is still on Java 8 (or less) and are just ignoring 
the new module system.


- Johan


On Fri, Jul 6, 2018 at 12:51 PM Michael Paus > wrote:


Hi,
I tried the examples on my Mac with Maven and with a simple
 mvn clean package exec:java

Re: JavaFX 11 snapshots in maven sonatype

[Johan Vos]

Hi Michael,

Thanks for testing this.

You can avoid downloading all platform jars by specifying the
javafx.platform with maven:

mvn -Djavafx.platform=mac clean package exec:java

There is a rationale behind this:
maven would be able to detect the OS and make sure only the platform jars
related to that OS are downloaded.
But that won't work with gradle. So we have this base pom that, unless
javafx.platform is specified, will depend on all platforms, which will
cause gradle to download the correct platform (and the others as well).
Now, for SNAPSHOTs this doesn't work with gradle (see previous mail) but
that is another issue. For releases, this works with gradle.

I'm very open to suggestions on how to change this.

As for architectures: I would suggest we follow the approach of the
excellent nd4j project and append the arch if used (see
https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j-native/1.0.0-SNAPSHOT/
--
it even includes linux-x86_64-avx512)

For Eclipse: by setting the {javafx.platform} variable somewhere, it will
be avoided to download the other platforms.
But your error message seems to suggest something else:
 Error: JavaFX runtime components are missing, and are required to  run
this application

That is an issue I brought up somewhere else:
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021977.html
The Java launcher will check if the main class extends
javafx.application.Application and if that is the case, it will do a hard
check on the availability of the javafx.graphics module in the modulepath.
If it can't find that, it will bail with the message above. So that is
happening.

This doesn't happen when you launch via maven, as maven is launching the
application inside its own Java process -- hence the main class is a maven
class, not extending javafx.application.Application.

The solution to this is somehow tell maven or eclipse to use modules. With
gradle, we have a relative easy way to do this:
run {
doFirst {
jvmArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.controls'
]
classpath = sourceSets.main.output
}
}

(unfortunately, we can't use gradle due to that snapshot/platform issue,
but I tested it with a release extension instead of a snapshot extension
and then it works).

I would assume maven allows for a similar approach. In general, this is an
issue not specific to JavaFX: how can you tell maven to use the artifacts
as modules (e.g. set the correct module-path and add the modules). The only
thing that is JavaFX specific is that the Java launcher will exit if ((the
main class extends Application) AND (no modules used)).

See http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021983.html
for
the discussion about this. I'm not 100% what the best approach is here. It
sounds a bit unfair that you can only NOT use classpath when your main
class extends javafx.application.Application, but the best approach is
probably a fix in a maven plugin so that it works with modules (might
already be there?)

- Johan


On Fri, Jul 6, 2018 at 12:51 PM Michael Paus  wrote:

> Hi,
> I tried the examples on my Mac with Maven and with a simple
>  mvn clean package exec:java
> on the command line they all compiled and worked out of the box.
> Great work! I used OpenJDK 11ea20 for this.
>
> I have a few questions though:
>
> 1. I observed that maven downloaded all dependencies for all platforms
> (mac,win,linux)
> which does not seem to make much sense. Is this normal or could that be
> prevented somehow?
>
> 2. How would the platform concept be extended once we have to also
> distinguish between architectures?
> (Linux on x86 vs. Linux on ARM for the Raspi for example)
>
> 3. How is this setup supposed to be used in an IDE like Eclipse. I tried
> to import one of the example projects
> into Eclipse and Eclipse ended up creating maven dependencies for all
> platforms and not just the Mac.
> This has the consequence that you cannot start an example directly in
> Eclipse anymore because it then fails with:
>  Error: JavaFX runtime components are missing, and are required to
> run this application
> You can launch it via maven but I normally prefer to do it directly
> which is no problem with a normal maven project.
>
> Michael
>
> Am 05.07.18 um 11:03 schrieb Johan Vos:
> > A first batch of snapshots for the JavaFX 11 modules is now in the maven
> > sonatype snapshot repository (see
> > https://oss.sonatype.org/content/repositories/snapshots/org/openjfx/
> although
> > you probably don't want to work with these artifacts directly but use
> build
> > tools like maven or gradle to do that)
> >
> > This is work based on the not-yet-merged PR#83:
> > https://github.com/javafxports/openjdk-jfx/pull/83
> >
> > Basically, you need to specify which modules you need (transitive
> > dependency management will be handled by maven as the modules contain a
> > pom.xml with the same dependencies as the

Re: JavaFX 11 snapshots in maven sonatype

[Johan Vos]

That is a known issue indeed, but I think it should be fixed in Gradle. We
can't easily upload all platforms using the same snapshot version, unless
I'm missing something?

We ran into this before, when working with nd4j SNAPSHOT versions on
gradle. We "fixed" it by applying own plugin code, e.g.
https://github.com/javafxports/javafxmobile-plugin/blob/master/src/main/groovy/org/javafxports/jfxmobile/plugin/JFXMobileConvention.groovy#L61

It is very inconvenient, so if you know an easy way to get all snapshot
version to be equal, I would love to hear that. But still, if other
libraries don't follow that approach (e.g. nd4j) it still means gradle
can't be used (unless you apply the "snapshotlocal" fix as in the above
link).

I really hope this can be fixed, as I loved gradle (less typing), but this
issue is the reason I had to revert to maven.

- Johan

On Thu, Jul 5, 2018 at 10:43 PM MUELLER-SCHRAMM Gerd <
gerd.mueller-schr...@hexagon.com> wrote:

> Hi Johan,
>
> Gradle doesn't ignore the classifier but there is no Windows- and
> Linux-version for the latest snapshot "20180702.224902-3". Gradle always
> checks for the latest snapshot, adds the classifier and tries to download
> this. The classifier 'mac' works with gradle. So all platform versions of
> JFX need the same snapshot version.
>
> Best regards,
> Gerd
>
> Gerd Müller-Schramm
> Software Developer, GeoMedia Smart Client Kommunal
> T: +49 341 92 60 30 47 <+49%20341%2092603047>
> E: gerd.mueller-schr...@hexagon.com
>
> Hexagon Geospatial
> Wittenberger Straße 15B
> 04129 Leipzig, Germany
> hexagongeospatial.com
>
> -Original Message-
> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf
> Of Johan Vos
> Sent: Donnerstag, 5. Juli 2018 11:03
> To: openjfx-dev@openjdk.java.net List 
> Subject: JavaFX 11 snapshots in maven sonatype
>
> A first batch of snapshots for the JavaFX 11 modules is now in the maven
> sonatype snapshot repository (see
> https://oss.sonatype.org/content/repositories/snapshots/org/openjfx/
> although you probably don't want to work with these artifacts directly but
> use build tools like maven or gradle to do that)
>
> This is work based on the not-yet-merged PR#83:
> https://github.com/javafxports/openjdk-jfx/pull/83
>
> Basically, you need to specify which modules you need (transitive
> dependency management will be handled by maven as the modules contain a
> pom.xml with the same dependencies as the module-info.java), e.g.
>
>
> 
>   org.openjfx
>   javafx.controls
>   11.0.0-SNAPSHOT
> 
>
>
> I have a few samples that show how you can use those artifacts in your
> maven project:
> https://github.com/johanvos/javafx11samples (note that this is a temporary
> repository)
> the topics/javafx3d directory contains a number of standalone samples that
> can be executed via mvn clean install exec:java
>
> Note that some of the samples create a build.gradle as well, but I never
> managed to get gradle working with the combination of classifiers and
> SNAPSHOT versions (it's actually the reason why I went back from gradle to
> maven in other projects -- e.g. dl4j related).
>
> If someone else can somehow fix the build.gradle, that would be great of
> course.
>
> Before PR#83 is merged, it would be nice to have a few reports from people
> using the snapshots.
>
> - Johan
>
>

Re: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API

[Kevin Rushforth]

Thanks.

As a note to reviewers, if you want to test the new functionality, and 
be able to run JavaFX swing interop applications without adding 
qualified exports, you will need to use a recent OpenJDK 11 ea build as 
the boot JDK. If you use OpenJDK 10, it will work no better (and 
hopefully no worse) than before, meaning that you will still need the 
additional qualified exports.


-- Kevin

On 7/5/2018 11:29 PM, Prasanta Sadhukhan wrote:


My Bad. Please find modified webrev restoring the filter

http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.4/

Regards
Prasanta
On 7/6/2018 6:47 AM, Kevin Rushforth wrote:

One quick comment:

This no longer compiles with OpenJDK10. It looks like the logic to 
optionally filter out jdk.unsupported.desktop from javafx.swing's 
module-info.java got lost between the .2 and .3 versions.


-- Kevin


On 7/4/2018 4:35 AM, Prasanta Sadhukhan wrote:

Hi All,

Please review an enhancement to support openjfx swing 
interoperability once the dependancy of internal jdk classes are 
removed.
JDK-8202199  
provided a new "jdk.unsupported.desktop" module in JDK 11 that 
exports public API that is intended to be used by the javafx.swing 
module
and unbundled OpenJFX is now made to depend on these APIs to support 
interoperation
between Swing and JavaFX components to replace previous use of 
internal APIs when it was part of Oracle JDK.


Bug: https://bugs.openjdk.java.net/browse/JDK-8195811
webrev: http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.3/

Regards
Prasanta

Re: JavaFX 11 snapshots in maven sonatype

[Michael Paus]

Hi,
I tried the examples on my Mac with Maven and with a simple
    mvn clean package exec:java
on the command line they all compiled and worked out of the box.
Great work! I used OpenJDK 11ea20 for this.

I have a few questions though:

1. I observed that maven downloaded all dependencies for all platforms 
(mac,win,linux)
which does not seem to make much sense. Is this normal or could that be 
prevented somehow?


2. How would the platform concept be extended once we have to also 
distinguish between architectures?

(Linux on x86 vs. Linux on ARM for the Raspi for example)

3. How is this setup supposed to be used in an IDE like Eclipse. I tried 
to import one of the example projects
into Eclipse and Eclipse ended up creating maven dependencies for all 
platforms and not just the Mac.
This has the consequence that you cannot start an example directly in 
Eclipse anymore because it then fails with:
    Error: JavaFX runtime components are missing, and are required to 
run this application
You can launch it via maven but I normally prefer to do it directly 
which is no problem with a normal maven project.


Michael

Am 05.07.18 um 11:03 schrieb Johan Vos:

A first batch of snapshots for the JavaFX 11 modules is now in the maven
sonatype snapshot repository (see
https://oss.sonatype.org/content/repositories/snapshots/org/openjfx/ although
you probably don't want to work with these artifacts directly but use build
tools like maven or gradle to do that)

This is work based on the not-yet-merged PR#83:
https://github.com/javafxports/openjdk-jfx/pull/83

Basically, you need to specify which modules you need (transitive
dependency management will be handled by maven as the modules contain a
pom.xml with the same dependencies as the module-info.java), e.g.



   org.openjfx
   javafx.controls
   11.0.0-SNAPSHOT



I have a few samples that show how you can use those artifacts in your
maven project:
https://github.com/johanvos/javafx11samples (note that this is a temporary
repository)
the topics/javafx3d directory contains a number of standalone samples that
can be executed via
mvn clean install exec:java

Note that some of the samples create a build.gradle as well, but I never
managed to get gradle working with the combination of classifiers and
SNAPSHOT versions (it's actually the reason why I went back from gradle to
maven in other projects -- e.g. dl4j related).

If someone else can somehow fix the build.gradle, that would be great of
course.

Before PR#83 is merged, it would be nice to have a few reports from people
using the snapshots.

- Johan

Review Request JDK-8187100 [JavaFX] To make display Variation Selectors(SVS/IVS) on Win(VISTA-) and MacOS(10.6-)

[Nakajima Akira]

Hi All.

patch: https://github.com/javafxports/openjdk-jfx/pull/126


This is separated from
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/022005.html
 and modified to simple patch for Win(VISTA or later) and MacOS(10.6 or 
later).



I checked on Windows7 and Windows10.
But I could not check on VISTA and MacOSX because of no having these OS.

Especially, I take care about MacOS code version.
I have no idea that following code is correct or not.

MAC_10_6_OR_LATER = MAC && versionNumberGreaterThanOrEqualTo(10.6f);




Regards,
Akira Nakajima

--
Company: NTT Comware Corporation
Name: Akira Nakajima
E-Mail: nakajima.ak...@nttcom.co.jp
OLA : http://www.oracle.com/technetwork/community/oca-486395.html#n
--