From pankaj.b.bansal at oracle.com Tue Jul 3 07:55:40 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 3 Jul 2018 00:55:40 -0700 (PDT) Subject: [11] JDK-8191885 : [MacOS] JavaFX main window not resizable coming back from full screen mode in MacOS Message-ID: Hi Kevin, Murali & Ajit, Please review this fix, Webrev: http://cr.openjdk.java.net/~pbansal/8191885/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8191885 Regards, Pankaj From priyanka.mangal at oracle.com Tue Jul 3 08:44:42 2018 From: priyanka.mangal at oracle.com (Priyanka Mangal) Date: Tue, 3 Jul 2018 14:14:42 +0530 Subject: [11] Review request: 8201231 : java.lang.NullPointerException at WindowStage.setPlatformEnabled In-Reply-To: <222641c2-a2aa-d4fe-0665-8e6a7a6e5903@oracle.com> References: <222641c2-a2aa-d4fe-0665-8e6a7a6e5903@oracle.com> Message-ID: <4f1f5844-6620-3817-6447-4b07017450dd@oracle.com> Hi, Please review this fix : Webrev : http://cr.openjdk.java.net/~dkumar/primanga/8201231/webrev.00/ JBS : https://bugs.openjdk.java.net/browse/JDK-8201231 Thanks, Priyanka From bourges.laurent at gmail.com Tue Jul 3 09:13:30 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 3 Jul 2018 11:13:30 +0200 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> Message-ID: Kevin, Thanks for the review ! 2018-06-29 22:52 GMT+02:00 Kevin Rushforth : > I'm giving a +1 on the implementation changes. I scanned the webrev and > didn't see anything out of place. I compared the diffs of the FX Marlin > 0.9.2 with the Java2D 0.9.1 changeset, and there were a few more diffs than > I might have expoected, but nothing jumped out of me as a problem. Also, > I've tested it pretty well on all three platforms. > > The overall +1 is pending the fixes needed for the test: at least the > copyright header and shortening or disabling the test. > Here is the updated webrev fixing the test: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.1/ ClipShapeTest incremental diff: --- /tmp/meld-tmpyWO0FS +++ /home/bourgesl/libs/marlin/branches/marlin-fx-openjdk/src/test/java/test/manual/marlin/ClipShapeTest.java @@ -4,7 +4,9 @@ * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or @@ -219,12 +221,10 @@ // cubic min/max error: System.setProperty("prism.marlin.cubic_dec_d2", "1e-3"); - System.setProperty("prism.marlin.cubic_inc_d1", "1e-4"); // or disabled ~ 1e-6 + System.setProperty("prism.marlin.cubic_inc_d1", "1e-4"); // quad max error: System.setProperty("prism.marlin.quad_dec_d2", "5e-4"); - - System.setProperty("javafx.animation.fullspeed", "true"); // full speed } // Application class. An instance is created and initialized before running @@ -273,7 +273,7 @@ } private static void resetOptions() { - NUM_TESTS = 5000; + NUM_TESTS = Integer.getInteger("ClipShapeTest.numTests", 100); // shape settings: SHAPE_MODE = ShapeMode.NINE_LINE_POLYS; Changes: - fixed license (Classpath exception) - removed "javafx.animation.fullspeed" in the test setup - use 100 tests by default to shorten the test duration (but I kept the high timeout values if the following parameter is increased): I added the system property "ClipShapeTest.numTests" but it requires a build.gradle change to pass the parameter: + // Marlin ClipShapeTest+ systemProperty "ClipShapeTest.numTests", project.getProperty("ClipShapeTest.numTests")+ If it is not recommended to add such specific parameters into the build.gradle file, what do you recommend ? (manual edit ?) Best regards, Laurent > > On 6/29/2018 11:25 AM, Kevin Rushforth wrote: > >> One more thing about the test. All of the OpenJFX unit tests should have >> GPL v2 + Classpath Exception (this differs from the JDK). >> >> -- Kevin >> >> >> On 6/29/2018 10:23 AM, Kevin Rushforth wrote: >> >>> >>> I'll plan to review the code today if possible. This will need one more >>> reviewer, so maybe Phil can also review it, since he reviewed the Java2D >>> patch? >>> >>> As for my comments on the test: >>> >>> Finally I think this test should be manually run only if Marlin renderer >>>> is modified. >>>> How to do that ? use @Ignore or specific tags ? >>>> >>> >>> As a slight variation of this: How about running a small number (say, >>> 200 or 250) by default, but adding a flag to run more? Alternatively, you >>> could use a flag to enable it, but since you would need to do something >>> extra (provide a flag or modify the test) to run it, we might as well get >>> at least some testing all the time. Unless you really think there is no >>> value in doing this. >>> >>> I deliberately set all these Marlin clip (runtime + always subdivider) / >>>> curve quality settings (quads / cubics thresholds) to be sure of the >>>> concrete Marlin setup as quality thresholds are sensitive to such values. >>>> >>> >>> As a best practice, tests should generally be run using the same >>> settings as are used in production. Other than to verify how it behaves >>> when you change these settings, I don't see the value in testing the system >>> running in a mode that no application will ever see. I may be missing some >>> point here. >>> >>> -- Kevin >>> >>> >>> On 6/25/2018 9:01 AM, Laurent Bourg?s wrote: >>> >>>> Kevin, >>>> >>>> Here are my comments below: >>>> >>>> 2018-06-16 1:47 GMT+02:00 Kevin Rushforth >>> >: >>>> >>>> I tested this on all three platforms and the updated rasterizer >>>> looks good. >>>> >>>> I spot checked the code changes, but didn't get time to do a >>>> complete review yet. I was mostly looking for diffs between the >>>> Java2D version which was already reviewed, and this one. >>>> >>>> I do have a couple comments on the new ClipShapeTest (which looks >>>> like a nice accuracy test, btw). >>>> >>>> 1. The test runs for way too long (about 20x too long) to include >>>> in our normal test runs. By default the entire class file (all >>>> three tests) needs to take < 5 minutes and 2 minutes would be >>>> better. I measured the time on 4 machines that I have and found >>>> that if you cut the number of iterations down from 5000 to 250 it >>>> will be just about the right run time. Then you can set the >>>> timeout to 120 seconds (the slowest test on the slowest of my >>>> machines took about 48 seconds, so a 2 minute timeout should be >>>> plenty). >>>> >>>> >>>> I agree this test is very long but it is the only mean I found to test >>>> all possible stroke combinations and test enough shapes (5000) to detect >>>> bugs. >>>> I wondered if using mask directly (via ShapeUtils.getMaskData()) would >>>> become faster but it will never run below the 2 minutes threshold in total. >>>> >>>> Finally I think this test should be manually run only if Marlin >>>> renderer is modified. >>>> How to do that ? use @Ignore or specific tags ? >>>> >>>> >>>> 2. Can you explain the reason for setting the following? >>>> >>>> 206 // disable static clipping setting: >>>> 207 System.setProperty("prism.marlin.clip", "false"); >>>> 208 >>>> System.setProperty("prism.marlin.clip.runtime.enable", "true"); >>>> 209 >>>> 210 // enable subdivider: >>>> 211 System.setProperty("prism.marlin.clip.subdivider", >>>> "true"); >>>> 212 >>>> 213 // disable min length check: always subdivide curves >>>> at clip edges >>>> 214 System.setProperty("prism.marlin.clip.subdivider.minLength", >>>> "-1"); >>>> 215 >>>> 216 // If any curve, increase curve accuracy: >>>> 217 // curve length max error: >>>> 218 System.setProperty("prism.marlin.curve_len_err", "1e-4"); >>>> 219 >>>> 220 // cubic min/max error: >>>> 221 System.setProperty("prism.marlin.cubic_dec_d2", "1e-3"); >>>> 222 System.setProperty("prism.marlin.cubic_inc_d1", >>>> "1e-4"); // or disabled ~ 1e-6 >>>> 223 >>>> 224 // quad max error: >>>> 225 System.setProperty("prism.marlin.quad_dec_d2", "5e-4"); >>>> >>>> It seems better to test with the default parameters (i.e., it >>>> makes a better regression test that way). >>>> >>>> >>>> I deliberately set all these Marlin clip (runtime + always subdivider) >>>> / curve quality settings (quads / cubics thresholds) to be sure of the >>>> concrete Marlin setup as quality thresholds are sensitive to such values. >>>> >>>> The ClipShapeTest is dedicated to test the clipper (+ subdivider) part >>>> of the Marlin renderer. >>>> >>>> >>>> >>>> 3. Related to that, I think you should eliminate the following (I >>>> don't recommend running functional tests with this set), although >>>> since you don't do any animation, it probably doesn't matter. >>>> >>>> 227 System.setProperty("javafx.animation.fullspeed", >>>> "true"); // full speed >>>> >>>> >>>> I will remove it and see if the overall test is not slower. >>>> Is Platform.runLater() impacted by such setting (latency of FX thread >>>> -> Prism rendering thread ?) ? >>>> >>>> Laurent >>>> >>>> >>>> >>>> On 6/8/2018 7:28 AM, Laurent Bourg?s wrote: >>>> >>>> Hi, >>>> >>>> Please review this large patch to upgrade MarlinFX to 0.9.2 in >>>> OpenJFX11: >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8198885 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.0/ >>>> >>>> >>> > >>>> PR: https://github.com/javafxports/openjdk-jfx/pull/96 >>>> (CI OK) >>>> >>>> This patch is almost identical to Marlin(2D) patch, see: >>>> https://bugs.openjdk.java.net/browse/JDK-8198885 >>>> >>>> >>>> I added the ClipShapeTest (ported to jfx) that compares shape >>>> clipping (within threshold) and it works (within large >>>> timeouts): >>>> gradle -PFULL_TEST=true :system:test --tests >>>> test.com.sun.marlin.ClipShapeTest >>>> >>>> Regards, >>>> Laurent >>>> >>>> >>>> >>>> >>> >> > -- -- Laurent Bourg?s From kevin.rushforth at oracle.com Tue Jul 3 12:08:25 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 3 Jul 2018 05:08:25 -0700 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> Message-ID: <0c0969b1-d807-6d8a-1dd3-ddbf374a1e25@oracle.com> Hi Laurent, > I added the system property "ClipShapeTest.numTests" but it requires a build.gradle change to pass the parameter: Yes, something like this is what I had in mind. As long as we don't add too many of these, it is OK with me. Note that as coded, the build will fail if you don't define ClipShapeTest.numTests, so you will need to check for that. I note also that you used tabs in build.gradle (so please change them to spaces). I recommend the following logic: ? ?? ?? if (rootProject.hasProperty("ClipShapeTest.numTests")) { ??? ? ?? ?? systemProperty "ClipShapeTest.numTests", rootProject.getProperty("ClipShapeTest.numTests") ? ?? ?? } -- Kevin On 7/3/2018 2:13 AM, Laurent Bourg?s wrote: > Kevin, > > Thanks for the review ! > > 2018-06-29 22:52 GMT+02:00 Kevin Rushforth >: > > I'm giving a +1 on the implementation changes. I scanned the > webrev and didn't see anything out of place. I compared the diffs > of the FX Marlin 0.9.2 with the Java2D 0.9.1 changeset, and there > were a few more diffs than I might have expoected, but nothing > jumped out of me as a problem. Also, I've tested it pretty well on > all three platforms. > > The overall +1 is pending the fixes needed for the test: at least > the copyright header and shortening or disabling the test. > > > Here is the updated webrev fixing the test: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.1/ > > > ClipShapeTest incremental diff: > --- /tmp/meld-tmpyWO0FS > +++ > /home/bourgesl/libs/marlin/branches/marlin-fx-openjdk/src/test/java/test/manual/marlin/ClipShapeTest.java > @@ -4,7 +4,9 @@ > ? * > ? * This code is free software; you can redistribute it and/or modify it > ? * under the terms of the GNU General Public License version 2 only, as > - * published by the Free Software Foundation. > + * published by the Free Software Foundation. Oracle designates this > + * particular file as subject to the "Classpath" exception as provided > + * by Oracle in the LICENSE file that accompanied this code. > ? * > ? * This code is distributed in the hope that it will be useful, but > WITHOUT > ? * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > @@ -219,12 +221,10 @@ > > ???????? // cubic min/max error: > System.setProperty("prism.marlin.cubic_dec_d2", "1e-3"); > - System.setProperty("prism.marlin.cubic_inc_d1", "1e-4"); // or > disabled ~ 1e-6 > + System.setProperty("prism.marlin.cubic_inc_d1", "1e-4"); > > ???????? // quad max error: > System.setProperty("prism.marlin.quad_dec_d2", "5e-4"); > - > - System.setProperty("javafx.animation.fullspeed", "true"); // full speed > ???? } > > ???? // Application class. An instance is created and initialized > before running > @@ -273,7 +273,7 @@ > ???? } > > ???? private static void resetOptions() { > -??????? NUM_TESTS = 5000; > +??????? NUM_TESTS = Integer.getInteger("ClipShapeTest.numTests", 100); > > ???????? // shape settings: > ???????? SHAPE_MODE = ShapeMode.NINE_LINE_POLYS; > > Changes: > - fixed license (Classpath exception) > - removed "javafx.animation.fullspeed"in the test setup > - use 100 tests by default to shorten the test duration (but I kept > the high timeout values if the following parameter is increased): > > I added the system property "ClipShapeTest.numTests" but it requires a > build.gradle change to pass the parameter: > > + // Marlin ClipShapeTest > + systemProperty "ClipShapeTest.numTests", > project.getProperty("ClipShapeTest.numTests") > + > If it is not recommended to add such specific parameters into the > build.gradle file, what do you recommend ? (manual edit ?) > > Best regards, > Laurent > > > > > On 6/29/2018 11:25 AM, Kevin Rushforth wrote: > > One more thing about the test. All of the OpenJFX unit tests > should have GPL v2 + Classpath Exception (this differs from > the JDK). > > -- Kevin > > > On 6/29/2018 10:23 AM, Kevin Rushforth wrote: > > > I'll plan to review the code today if possible. This will > need one more reviewer, so maybe Phil can also review it, > since he reviewed the Java2D patch? > > As for my comments on the test: > > Finally I think this test should be manually run only > if Marlin renderer is modified. > How to do that ? use @Ignore or specific tags ? > > > As a slight variation of this: How about running a small > number (say, 200 or 250) by default, but adding a flag to > run more? Alternatively, you could use a flag to enable > it, but since you would need to do something extra > (provide a flag or modify the test) to run it, we might as > well get at least some testing all the time. Unless you > really think there is no value in doing this. > > I deliberately set all these Marlin clip (runtime + > always subdivider) / curve quality settings (quads / > cubics thresholds) to be sure of the concrete Marlin > setup as quality thresholds are sensitive to such values. > > > As a best practice, tests should generally be run using > the same settings as are used in production. Other than to > verify how it behaves when you change these settings, I > don't see the value in testing the system running in a > mode that no application will ever see. I may be missing > some point here. > > -- Kevin > > > On 6/25/2018 9:01 AM, Laurent Bourg?s wrote: > > Kevin, > > Here are my comments below: > > 2018-06-16 1:47 GMT+02:00 Kevin Rushforth > > >>: > > ??? I tested this on all three platforms and the > updated rasterizer > ??? looks good. > > ??? I spot checked the code changes, but didn't get > time to do a > ??? complete review yet. I was mostly looking for > diffs between the > ??? Java2D version which was already reviewed, and > this one. > > ??? I do have a couple comments on the new > ClipShapeTest (which looks > ??? like a nice accuracy test, btw). > > ??? 1. The test runs for way too long (about 20x too > long) to include > ??? in our normal test runs. By default the entire > class file (all > ??? three tests) needs to take < 5 minutes and 2 > minutes would be > ??? better. I measured the time on 4 machines that I > have and found > ??? that if you cut the number of iterations down from > 5000 to 250 it > ??? will be just about the right run time. Then you > can set the > ??? timeout to 120 seconds (the slowest test on the > slowest of my > ??? machines took about 48 seconds, so a 2 minute > timeout should be > ??? plenty). > > > I agree this test is very long but it is the only mean > I found to test all possible stroke combinations and > test enough shapes (5000) to detect bugs. > I wondered if using mask directly (via > ShapeUtils.getMaskData()) would become faster but it > will never run below the 2 minutes threshold in total. > > Finally I think this test should be manually run only > if Marlin renderer is modified. > How to do that ? use @Ignore or specific tags ? > > > ??? 2. Can you explain the reason for setting the > following? > > ??? ?206???????? // disable static clipping setting: > ??? ?207 System.setProperty("prism.marlin.clip", "false"); > ??? ?208 > ??? > System.setProperty("prism.marlin.clip.runtime.enable", > "true"); > ??? ?209 > ??? ?210???????? // enable subdivider: > ??? ?211 > System.setProperty("prism.marlin.clip.subdivider", > ??? "true"); > ??? ?212 > ??? ?213???????? // disable min length check: always > subdivide curves > ??? at clip edges > ??? ?214 > System.setProperty("prism.marlin.clip.subdivider.minLength", > ??? "-1"); > ??? ?215 > ??? ?216???????? // If any curve, increase curve accuracy: > ??? ?217???????? // curve length max error: > ??? ?218 > System.setProperty("prism.marlin.curve_len_err", "1e-4"); > ??? ?219 > ??? ?220???????? // cubic min/max error: > ??? ?221 > System.setProperty("prism.marlin.cubic_dec_d2", "1e-3"); > ??? ?222 System.setProperty("prism.marlin.cubic_inc_d1", > ??? "1e-4"); // or disabled ~ 1e-6 > ??? ?223 > ??? ?224???????? // quad max error: > ??? ?225 > System.setProperty("prism.marlin.quad_dec_d2", "5e-4"); > > ??? It seems better to test with the default > parameters (i.e., it > ??? makes a better regression test that way). > > > I deliberately set all these Marlin clip (runtime + > always subdivider) / curve quality settings (quads / > cubics thresholds) to be sure of the concrete Marlin > setup as quality thresholds are sensitive to such values. > > The ClipShapeTest is dedicated to test the clipper (+ > subdivider) part of the Marlin renderer. > > > > ??? 3. Related to that, I think you should eliminate > the following (I > ??? don't recommend running functional tests with this > set), although > ??? since you don't do any animation, it probably > doesn't matter. > > ??? ?227 System.setProperty("javafx.animation.fullspeed", > ??? "true"); // full speed > > > I will remove it and see if the overall test is not > slower. > Is Platform.runLater() impacted by such setting > (latency of FX thread -> Prism rendering thread ?) ? > > Laurent > > > > ??? On 6/8/2018 7:28 AM, Laurent Bourg?s wrote: > > ??????? Hi, > > ??????? Please review this large patch to upgrade > MarlinFX to 0.9.2 in > ??????? OpenJFX11: > ??????? JBS: > https://bugs.openjdk.java.net/browse/JDK-8198885 > > > > ??????? webrev: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.0/ > > > > > >> > ??????? PR: > https://github.com/javafxports/openjdk-jfx/pull/96 > > > > (CI OK) > > ??????? This patch is almost identical to Marlin(2D) > patch, see: > https://bugs.openjdk.java.net/browse/JDK-8198885 > > > > > ??????? I added the ClipShapeTest (ported to jfx) that > compares shape > ??????? clipping (within threshold) and it works > (within large timeouts): > ??????? gradle -PFULL_TEST=true :system:test --tests > ??????? test.com.sun.marlin.ClipShapeTest > > ??????? Regards, > ??????? Laurent > > > > > > > > > > -- > -- > Laurent Bourg?s From bourges.laurent at gmail.com Tue Jul 3 15:45:49 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 3 Jul 2018 17:45:49 +0200 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: <0c0969b1-d807-6d8a-1dd3-ddbf374a1e25@oracle.com> References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> <0c0969b1-d807-6d8a-1dd3-ddbf374a1e25@oracle.com> Message-ID: Kevin, > I added the system property "ClipShapeTest.numTests" but it requires a > build.gradle change to pass the parameter: > > Yes, something like this is what I had in mind. As long as we don't add > too many of these, it is OK with me. Note that as coded, the build will > fail if you don't define ClipShapeTest.numTests, so you will need to check > for that. I note also that you used tabs in build.gradle (so please change > them to spaces). I recommend the following logic: > > if (rootProject.hasProperty("ClipShapeTest.numTests")) { > systemProperty "ClipShapeTest.numTests", > rootProject.getProperty("ClipShapeTest.numTests") > } > I adopted your proposal and updated the webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/ PS: I am not really satisfied by adding such noise in build.gradle, but it can be improved later ... Laurent From kevin.rushforth at oracle.com Tue Jul 3 15:55:31 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 3 Jul 2018 08:55:31 -0700 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> <0c0969b1-d807-6d8a-1dd3-ddbf374a1e25@oracle.com> Message-ID: <0a9c73c3-60b3-4ac3-3058-05c9878ca2b6@oracle.com> > On 7/3/2018 8:45 AM, Laurent Bourg?s wrote: > Kevin, > > > I added the system property "ClipShapeTest.numTests" but it requires a > build.gradle change to pass the parameter: > > Yes, something like this is what I had in mind. As long as we > don't add too many of these, it is OK with me. Note that as coded, > the build will fail if you don't define ClipShapeTest.numTests, so > you will need to check for that. I note also that you used tabs in > build.gradle (so please change them to spaces). I recommend the > following logic: > > ? ?? ?? if (rootProject.hasProperty("ClipShapeTest.numTests")) { > ??? ? ?? ?? systemProperty "ClipShapeTest.numTests", > rootProject.getProperty("ClipShapeTest.numTests") > ? ?? ?? } > > > I adopted your proposal and updated the webrev: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/ > > > PS: I am not really satisfied by adding such noise in build.gradle, > but it can be improved later ... > > Laurent From kevin.rushforth at oracle.com Tue Jul 3 15:56:33 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 3 Jul 2018 08:56:33 -0700 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> <0c0969b1-d807-6d8a-1dd3-ddbf374a1e25@oracle.com> Message-ID: > PS: I am not really satisfied by adding such noise in build.gradle, > but it can be improved later ... Agreed. This can be a follow-on issue. I'll finish my review shortly. -- Kevin On 7/3/2018 8:45 AM, Laurent Bourg?s wrote: > Kevin, > > > I added the system property "ClipShapeTest.numTests" but it requires a > build.gradle change to pass the parameter: > > Yes, something like this is what I had in mind. As long as we > don't add too many of these, it is OK with me. Note that as coded, > the build will fail if you don't define ClipShapeTest.numTests, so > you will need to check for that. I note also that you used tabs in > build.gradle (so please change them to spaces). I recommend the > following logic: > > ? ?? ?? if (rootProject.hasProperty("ClipShapeTest.numTests")) { > ??? ? ?? ?? systemProperty "ClipShapeTest.numTests", > rootProject.getProperty("ClipShapeTest.numTests") > ? ?? ?? } > > > I adopted your proposal and updated the webrev: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/ > > > PS: I am not really satisfied by adding such noise in build.gradle, > but it can be improved later ... > > Laurent From kevin.rushforth at oracle.com Tue Jul 3 16:03:47 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 3 Jul 2018 09:03:47 -0700 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> <0c0969b1-d807-6d8a-1dd3-ddbf374a1e25@oracle.com> Message-ID: Looks good. +1 -- note that needs a second reviewer (doesn't need to be a capital-R Reviewer). -- Kevin On 7/3/2018 8:56 AM, Kevin Rushforth wrote: >> PS: I am not really satisfied by adding such noise in build.gradle, >> but it can be improved later ... > > Agreed. This can be a follow-on issue. I'll finish my review shortly. > > -- Kevin > > > On 7/3/2018 8:45 AM, Laurent Bourg?s wrote: >> Kevin, >> >> ??? > I added the system property "ClipShapeTest.numTests" but it >> requires a >> ??? build.gradle change to pass the parameter: >> >> ??? Yes, something like this is what I had in mind. As long as we >> ??? don't add too many of these, it is OK with me. Note that as coded, >> ??? the build will fail if you don't define ClipShapeTest.numTests, so >> ??? you will need to check for that. I note also that you used tabs in >> ??? build.gradle (so please change them to spaces). I recommend the >> ??? following logic: >> >> ??? ? ?? ?? if (rootProject.hasProperty("ClipShapeTest.numTests")) { >> ??? ??? ? ?? ?? systemProperty "ClipShapeTest.numTests", >> ??? rootProject.getProperty("ClipShapeTest.numTests") >> ??? ? ?? ?? } >> >> >> I adopted your proposal and updated the webrev: >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/ >> >> >> PS: I am not really satisfied by adding such noise in build.gradle, >> but it can be improved later ... >> >> Laurent > From kevin.rushforth at oracle.com Tue Jul 3 16:19:07 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 3 Jul 2018 09:19:07 -0700 Subject: [11] Review request: 8090763: FX Robot API Message-ID: <6031d8fe-285e-44ea-4882-cbc51b49dad8@oracle.com> Most of you should be aware of this already: The review for the public FX Robot API, contributed by Michael Ennen (and sponsored by me), has been proceeding on GitHub: https://bugs.openjdk.java.net/browse/JDK-8090763 https://github.com/javafxports/openjdk-jfx/pull/36 My review is now done, so as soon as we get one more review, I'll merge the PR on GitHub. This will also serve as the request to integrate this into the openjfx/jfx-dev master repo. -- Kevin From kevin.rushforth at oracle.com Tue Jul 3 21:59:19 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 3 Jul 2018 14:59:19 -0700 Subject: REMINDER: Milestone dates for OpenJFX 11 release In-Reply-To: References: Message-ID: <2cf8ac79-2baa-c989-4085-5f6ddceecc7e@oracle.com> As a reminder, the RDP1 date for openjfx11 is July 9, at 23:59 Pacific time. This is the deadline for features, although we will have a process for getting in some smaller enhancements after RDP1 with approval (similar to what the JDK does). -- Kevin On 6/12/2018 3:18 PM, Kevin Rushforth wrote: > We are getting close to the start of rampdown for JDK 11 [1]. Now that > FX is no longer bundled we don't need to follow exactly the same > schedule of milestones, although we do want to release this first > unbundled FX 11 release at the same time JDK 11 ships (or slightly > sooner). > > Here is the proposed rampdown schedule for FX 11. The main differences > between the JDK schedule and the FX schedule is that we don't need as > long a back end as a full JDK feature release > > 2018-07-09 : RDP1 (aka feature freeze) > 2018-08-06 : RDP2 > 2018-08-27 : freeze for GAC build > 2018-09-18 : GA > > I am proposing a shorter time after RDP2 than the JDK because I don't > think we need the long back end of a full JDK feature release (not as > many moving parts or stakeholders). > > I will send out the proposed ramp-down policies, but as a starting > point I imagine we want something similar to what the JDK uses with a > couple modifications: > > 1. Since this is our first unbundled release and there are likely to > be plenty of bugs that need fixing during RDP1, so I propose to > postpone forking the repo until RDP1. This means a 4 week downtime > where there is no place to push new features / enhancements unless > they are critical to openjfx 11 (in which case they will be an > exception). I think this is a reasonable trade-off for this release > > 2. I don't plan to propose any restrictions on P4 bugs before RDP2. > The focus should be on more serious bugs, and we likely won't fix many > P4s, but if a safe P4 bug fix is proposed, reviewed, and tested, then > I see no reason not to take it between RDP1 and RDP2. > > -- Kevin > > [1] http://openjdk.java.net/projects/jdk/11/ > From guy.abossolo.foh at scientificware.com Wed Jul 4 00:27:44 2018 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Wed, 04 Jul 2018 02:27:44 +0200 Subject: HTMLEditor don't create new line when Enter pressed. Message-ID: Hi, Did someone test HTMLEditor with OpenJFX 9 and 10 ? - HTMLEditor doesn't create a new line when one presses Enter. - It works with JavaFX 8u171 and 11-internal+0-2018-07-02-110935. - but not with JavaFX 9.0.4 and JavaFX 10.0.1. Best regards. From bourges.laurent at gmail.com Wed Jul 4 07:30:30 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 4 Jul 2018 09:30:30 +0200 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> <0c0969b1-d807-6d8a-1dd3-ddbf374a1e25@oracle.com> Message-ID: Thanks Kevin for your approval. Phil or Sergey, could you make another review ? I would like to push this large patch in jfx 11. Regards, Laurent Le mar. 3 juil. 2018 ? 18:03, Kevin Rushforth a ?crit : > Looks good. > > +1 -- note that needs a second reviewer (doesn't need to be a capital-R > Reviewer). > > -- Kevin > > > On 7/3/2018 8:56 AM, Kevin Rushforth wrote: > >> PS: I am not really satisfied by adding such noise in build.gradle, > >> but it can be improved later ... > > > > Agreed. This can be a follow-on issue. I'll finish my review shortly. > > > > -- Kevin > > > > > > On 7/3/2018 8:45 AM, Laurent Bourg?s wrote: > >> Kevin, > >> > >> > I added the system property "ClipShapeTest.numTests" but it > >> requires a > >> build.gradle change to pass the parameter: > >> > >> Yes, something like this is what I had in mind. As long as we > >> don't add too many of these, it is OK with me. Note that as coded, > >> the build will fail if you don't define ClipShapeTest.numTests, so > >> you will need to check for that. I note also that you used tabs in > >> build.gradle (so please change them to spaces). I recommend the > >> following logic: > >> > >> if (rootProject.hasProperty("ClipShapeTest.numTests")) { > >> systemProperty "ClipShapeTest.numTests", > >> rootProject.getProperty("ClipShapeTest.numTests") > >> } > >> > >> > >> I adopted your proposal and updated the webrev: > >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/ > >> > >> > >> PS: I am not really satisfied by adding such noise in build.gradle, > >> but it can be improved later ... > >> > >> Laurent > > > > From johan.vos at gluonhq.com Wed Jul 4 07:55:02 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 4 Jul 2018 09:55:02 +0200 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> <0c0969b1-d807-6d8a-1dd3-ddbf374a1e25@oracle.com> Message-ID: I looked at it, mainly at the differences between the Java2D patch and the JavaFX patch, and it looks ok to me. I'll try to test it on linux and/or mac later today and have a deeper look. - Johan On Tue, Jul 3, 2018 at 6:14 PM Kevin Rushforth wrote: > Looks good. > > +1 -- note that needs a second reviewer (doesn't need to be a capital-R > Reviewer). > > -- Kevin > > > On 7/3/2018 8:56 AM, Kevin Rushforth wrote: > >> PS: I am not really satisfied by adding such noise in build.gradle, > >> but it can be improved later ... > > > > Agreed. This can be a follow-on issue. I'll finish my review shortly. > > > > -- Kevin > > > > > > On 7/3/2018 8:45 AM, Laurent Bourg?s wrote: > >> Kevin, > >> > >> > I added the system property "ClipShapeTest.numTests" but it > >> requires a > >> build.gradle change to pass the parameter: > >> > >> Yes, something like this is what I had in mind. As long as we > >> don't add too many of these, it is OK with me. Note that as coded, > >> the build will fail if you don't define ClipShapeTest.numTests, so > >> you will need to check for that. I note also that you used tabs in > >> build.gradle (so please change them to spaces). I recommend the > >> following logic: > >> > >> if (rootProject.hasProperty("ClipShapeTest.numTests")) { > >> systemProperty "ClipShapeTest.numTests", > >> rootProject.getProperty("ClipShapeTest.numTests") > >> } > >> > >> > >> I adopted your proposal and updated the webrev: > >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/ > >> > >> > >> PS: I am not really satisfied by adding such noise in build.gradle, > >> but it can be improved later ... > >> > >> Laurent > > > > From prasanta.sadhukhan at oracle.com Wed Jul 4 11:35:39 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 4 Jul 2018 17:05:39 +0530 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API Message-ID: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> 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 From johan.vos at gluonhq.com Thu Jul 5 09:03:12 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 5 Jul 2018 11:03:12 +0200 Subject: JavaFX 11 snapshots in maven sonatype Message-ID: 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 From johan.vos at gluonhq.com Thu Jul 5 09:46:22 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 5 Jul 2018 11:46:22 +0200 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> <0c0969b1-d807-6d8a-1dd3-ddbf374a1e25@oracle.com> Message-ID: I had a slightly deeper look and had a few comments, but it's hard to check the math behind it and evaluating performance without doing real tests. However, I feel confident we can merge it. That will also allow eager developers to use it and provide feedback. - Johan On Wed, Jul 4, 2018 at 9:55 AM Johan Vos wrote: > I looked at it, mainly at the differences between the Java2D patch and the > JavaFX patch, and it looks ok to me. > I'll try to test it on linux and/or mac later today and have a deeper look. > > - Johan > > > On Tue, Jul 3, 2018 at 6:14 PM Kevin Rushforth > wrote: > >> Looks good. >> >> +1 -- note that needs a second reviewer (doesn't need to be a capital-R >> Reviewer). >> >> -- Kevin >> >> >> On 7/3/2018 8:56 AM, Kevin Rushforth wrote: >> >> PS: I am not really satisfied by adding such noise in build.gradle, >> >> but it can be improved later ... >> > >> > Agreed. This can be a follow-on issue. I'll finish my review shortly. >> > >> > -- Kevin >> > >> > >> > On 7/3/2018 8:45 AM, Laurent Bourg?s wrote: >> >> Kevin, >> >> >> >> > I added the system property "ClipShapeTest.numTests" but it >> >> requires a >> >> build.gradle change to pass the parameter: >> >> >> >> Yes, something like this is what I had in mind. As long as we >> >> don't add too many of these, it is OK with me. Note that as coded, >> >> the build will fail if you don't define ClipShapeTest.numTests, so >> >> you will need to check for that. I note also that you used tabs in >> >> build.gradle (so please change them to spaces). I recommend the >> >> following logic: >> >> >> >> if (rootProject.hasProperty("ClipShapeTest.numTests")) { >> >> systemProperty "ClipShapeTest.numTests", >> >> rootProject.getProperty("ClipShapeTest.numTests") >> >> } >> >> >> >> >> >> I adopted your proposal and updated the webrev: >> >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/ >> >> >> >> >> >> PS: I am not really satisfied by adding such noise in build.gradle, >> >> but it can be improved later ... >> >> >> >> Laurent >> > >> >> From bourges.laurent at gmail.com Thu Jul 5 13:07:03 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 5 Jul 2018 15:07:03 +0200 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> <0c0969b1-d807-6d8a-1dd3-ddbf374a1e25@oracle.com> Message-ID: Johan, I agree Marlin 0.9.2 provides new clipping algorithms (curve subdivision & clipping in the dasher stage) so it involves lots of maths and tricks ... I implemented the automated ClipShapeTest that compares rendering with clipping enabled vs disabled for all possible combinations: - stroked & dashed paths with all sort of joins / caps - filled paths with all filling rules (NZ /EO) with lines/quads/curves ... This intensive test proves new algorithms do not introduce visual regressions except that clipped stroked curves are slightly different due to the curve offsetting algorithm. Such problem has no exact solution and the approximated offsetted curve causes the minor visual differences along the stroked curve. Finally MarlinFX 0.9.2 is giving same clipping accuracy than Marlin 0.9.1 integrated in jdk11. Performance is mainly improved for huge dashed paths. Kevin & Johan, do you consider the last webrev is approved by 2 reviewers ? Laurent Le jeu. 5 juil. 2018 ? 11:46, Johan Vos a ?crit : > I had a slightly deeper look and had a few comments, but it's hard to > check the math behind it and evaluating performance without doing real > tests. > However, I feel confident we can merge it. That will also allow eager > developers to use it and provide feedback. > > - Johan > > On Wed, Jul 4, 2018 at 9:55 AM Johan Vos wrote: > >> I looked at it, mainly at the differences between the Java2D patch and >> the JavaFX patch, and it looks ok to me. >> I'll try to test it on linux and/or mac later today and have a deeper >> look. >> >> - Johan >> >> >> On Tue, Jul 3, 2018 at 6:14 PM Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> Looks good. >>> >>> +1 -- note that needs a second reviewer (doesn't need to be a capital-R >>> Reviewer). >>> >>> -- Kevin >>> >>> >>> On 7/3/2018 8:56 AM, Kevin Rushforth wrote: >>> >> PS: I am not really satisfied by adding such noise in build.gradle, >>> >> but it can be improved later ... >>> > >>> > Agreed. This can be a follow-on issue. I'll finish my review shortly. >>> > >>> > -- Kevin >>> > >>> > >>> > On 7/3/2018 8:45 AM, Laurent Bourg?s wrote: >>> >> Kevin, >>> >> >>> >> > I added the system property "ClipShapeTest.numTests" but it >>> >> requires a >>> >> build.gradle change to pass the parameter: >>> >> >>> >> Yes, something like this is what I had in mind. As long as we >>> >> don't add too many of these, it is OK with me. Note that as coded, >>> >> the build will fail if you don't define ClipShapeTest.numTests, so >>> >> you will need to check for that. I note also that you used tabs in >>> >> build.gradle (so please change them to spaces). I recommend the >>> >> following logic: >>> >> >>> >> if (rootProject.hasProperty("ClipShapeTest.numTests")) { >>> >> systemProperty "ClipShapeTest.numTests", >>> >> rootProject.getProperty("ClipShapeTest.numTests") >>> >> } >>> >> >>> >> >>> >> I adopted your proposal and updated the webrev: >>> >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/ >>> >> >>> >> >>> >> PS: I am not really satisfied by adding such noise in build.gradle, >>> >> but it can be improved later ... >>> >> >>> >> Laurent >>> > >>> >>> From kevin.rushforth at oracle.com Thu Jul 5 13:24:17 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 5 Jul 2018 06:24:17 -0700 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> <0c0969b1-d807-6d8a-1dd3-ddbf374a1e25@oracle.com> Message-ID: <9fc4ec39-79d3-8821-d149-62c59eaed13e@oracle.com> > Kevin & Johan, do you consider the last webrev is approved by 2 reviewers ? I took Johan's comment to be a "+1" from him. He can correct us if that wasn't his intent. -- Kevin On 7/5/2018 6:07 AM, Laurent Bourg?s wrote: > Johan, > I agree Marlin 0.9.2 provides new clipping algorithms (curve > subdivision & clipping in the dasher stage) so it involves lots of > maths and tricks ... > > I implemented the automated ClipShapeTest that compares rendering with > clipping enabled vs disabled for all possible combinations: > - stroked & dashed paths with all sort of joins / caps > - filled paths with all filling rules (NZ /EO) > with > ?lines/quads/curves ... > > This intensive test proves new algorithms do not introduce visual > regressions except that clipped stroked curves are slightly different > due to the curve offsetting algorithm. Such problem has no exact > solution and the approximated offsetted curve causes the minor visual > differences along the stroked curve. > > Finally MarlinFX 0.9.2 is giving same clipping accuracy than Marlin > 0.9.1 integrated in jdk11. > Performance is mainly improved for huge dashed paths. > > Kevin & Johan, do you consider the last webrev is approved by 2 > reviewers ? > > Laurent > > Le jeu. 5 juil. 2018 ? 11:46, Johan Vos > a ?crit?: > > I had a slightly deeper look and had a few comments, but it's hard > to check the math behind it and evaluating performance without > doing real tests. > However, I feel confident we can merge it. That will also allow > eager developers to use it and provide feedback. > > - Johan > > On Wed, Jul 4, 2018 at 9:55 AM Johan Vos > wrote: > > I looked at it, mainly at the differences between the Java2D > patch and the JavaFX patch, and it looks ok to me. > I'll try to test it on linux and/or mac later today and have a > deeper look. > > - Johan > > > On Tue, Jul 3, 2018 at 6:14 PM Kevin Rushforth > > wrote: > > Looks good. > > +1 -- note that needs a second reviewer (doesn't need to > be a capital-R > Reviewer). > > -- Kevin > > > On 7/3/2018 8:56 AM, Kevin Rushforth wrote: > >> PS: I am not really satisfied by adding such noise in > build.gradle, > >> but it can be improved later ... > > > > Agreed. This can be a follow-on issue. I'll finish my > review shortly. > > > > -- Kevin > > > > > > On 7/3/2018 8:45 AM, Laurent Bourg?s wrote: > >> Kevin, > >> > >> ??? > I added the system property > "ClipShapeTest.numTests" but it > >> requires a > >> ??? build.gradle change to pass the parameter: > >> > >> ??? Yes, something like this is what I had in mind. As > long as we > >> ??? don't add too many of these, it is OK with me. Note > that as coded, > >> ??? the build will fail if you don't define > ClipShapeTest.numTests, so > >> ??? you will need to check for that. I note also that > you used tabs in > >> ??? build.gradle (so please change them to spaces). I > recommend the > >> ??? following logic: > >> > >> ??? ? ?? ?? if > (rootProject.hasProperty("ClipShapeTest.numTests")) { > >> ??? ??? ? ?? ?? systemProperty "ClipShapeTest.numTests", > >> rootProject.getProperty("ClipShapeTest.numTests") > >> ??? ? ?? ?? } > >> > >> > >> I adopted your proposal and updated the webrev: > >> > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/ > > > >> > > >> > >> PS: I am not really satisfied by adding such noise in > build.gradle, > >> but it can be improved later ... > >> > >> Laurent > > > From johan.vos at gluonhq.com Thu Jul 5 13:27:43 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 5 Jul 2018 15:27:43 +0200 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: <9fc4ec39-79d3-8821-d149-62c59eaed13e@oracle.com> References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> <0c0969b1-d807-6d8a-1dd3-ddbf374a1e25@oracle.com> <9fc4ec39-79d3-8821-d149-62c59eaed13e@oracle.com> Message-ID: I confirm my comments can be summarized as a "+1" - Johan On Thu, Jul 5, 2018 at 3:24 PM Kevin Rushforth wrote: > > > Kevin & Johan, do you consider the last webrev is approved by 2 > reviewers ? > > I took Johan's comment to be a "+1" from him. He can correct us if that > wasn't his intent. > > > -- Kevin > > > > On 7/5/2018 6:07 AM, Laurent Bourg?s wrote: > > Johan, > I agree Marlin 0.9.2 provides new clipping algorithms (curve subdivision & > clipping in the dasher stage) so it involves lots of maths and tricks ... > > I implemented the automated ClipShapeTest that compares rendering with > clipping enabled vs disabled for all possible combinations: > - stroked & dashed paths with all sort of joins / caps > - filled paths with all filling rules (NZ /EO) > with > lines/quads/curves ... > > This intensive test proves new algorithms do not introduce visual > regressions except that clipped stroked curves are slightly different due > to the curve offsetting algorithm. Such problem has no exact solution and > the approximated offsetted curve causes the minor visual differences along > the stroked curve. > > Finally MarlinFX 0.9.2 is giving same clipping accuracy than Marlin 0.9.1 > integrated in jdk11. > Performance is mainly improved for huge dashed paths. > > Kevin & Johan, do you consider the last webrev is approved by 2 reviewers ? > > Laurent > > Le jeu. 5 juil. 2018 ? 11:46, Johan Vos a ?crit : > >> I had a slightly deeper look and had a few comments, but it's hard to >> check the math behind it and evaluating performance without doing real >> tests. >> However, I feel confident we can merge it. That will also allow eager >> developers to use it and provide feedback. >> >> - Johan >> >> On Wed, Jul 4, 2018 at 9:55 AM Johan Vos wrote: >> >>> I looked at it, mainly at the differences between the Java2D patch and >>> the JavaFX patch, and it looks ok to me. >>> I'll try to test it on linux and/or mac later today and have a deeper >>> look. >>> >>> - Johan >>> >>> >>> On Tue, Jul 3, 2018 at 6:14 PM Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> Looks good. >>>> >>>> +1 -- note that needs a second reviewer (doesn't need to be a capital-R >>>> Reviewer). >>>> >>>> -- Kevin >>>> >>>> >>>> On 7/3/2018 8:56 AM, Kevin Rushforth wrote: >>>> >> PS: I am not really satisfied by adding such noise in build.gradle, >>>> >> but it can be improved later ... >>>> > >>>> > Agreed. This can be a follow-on issue. I'll finish my review shortly. >>>> > >>>> > -- Kevin >>>> > >>>> > >>>> > On 7/3/2018 8:45 AM, Laurent Bourg?s wrote: >>>> >> Kevin, >>>> >> >>>> >> > I added the system property "ClipShapeTest.numTests" but it >>>> >> requires a >>>> >> build.gradle change to pass the parameter: >>>> >> >>>> >> Yes, something like this is what I had in mind. As long as we >>>> >> don't add too many of these, it is OK with me. Note that as >>>> coded, >>>> >> the build will fail if you don't define ClipShapeTest.numTests, >>>> so >>>> >> you will need to check for that. I note also that you used tabs >>>> in >>>> >> build.gradle (so please change them to spaces). I recommend the >>>> >> following logic: >>>> >> >>>> >> if (rootProject.hasProperty("ClipShapeTest.numTests")) { >>>> >> systemProperty "ClipShapeTest.numTests", >>>> >> rootProject.getProperty("ClipShapeTest.numTests") >>>> >> } >>>> >> >>>> >> >>>> >> I adopted your proposal and updated the webrev: >>>> >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/ >>>> >> >>>> >> >>>> >> PS: I am not really satisfied by adding such noise in build.gradle, >>>> >> but it can be improved later ... >>>> >> >>>> >> Laurent >>>> > >>>> >>>> > From gerd.mueller-schramm at hexagon.com Thu Jul 5 14:48:10 2018 From: gerd.mueller-schramm at hexagon.com (MUELLER-SCHRAMM Gerd) Date: Thu, 5 Jul 2018 14:48:10 +0000 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: 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? E:?gerd.mueller-schramm at hexagon.com Hexagon Geospatial Wittenberger Stra?e 15B 04129 Leipzig, Germany hexagongeospatial.com -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Johan Vos Sent: Donnerstag, 5. Juli 2018 11:03 To: openjfx-dev at 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 From bernhard.lutzmann at gmail.com Thu Jul 5 20:06:22 2018 From: bernhard.lutzmann at gmail.com (Bernhard Lutzmann) Date: Thu, 5 Jul 2018 22:06:22 +0200 Subject: GitHub review for JDK-8203345: Memory leak in VirtualFlow when screen reader is enabled Message-ID: Hi, please review the following pull request on GitHub: JBS: https://bugs.openjdk.java.net/browse/JDK-8203345 PR: https://github.com/javafxports/openjdk-jfx/pull/78 Thanks, Bernhard From kevin.rushforth at oracle.com Thu Jul 5 21:52:59 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 5 Jul 2018 14:52:59 -0700 Subject: GitHub review for JDK-8203345: Memory leak in VirtualFlow when screen reader is enabled In-Reply-To: References: Message-ID: Note that this has already been merged into the 'develop' branch on GitHub. Barring any objections, I'll push it to openjfx-dev tomorrow. On 7/5/2018 1:06 PM, Bernhard Lutzmann wrote: > Hi, > > please review the following pull request on GitHub: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8203345 > PR: https://github.com/javafxports/openjdk-jfx/pull/78 > > Thanks, > Bernhard From kevin.rushforth at oracle.com Fri Jul 6 01:17:18 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 5 Jul 2018 18:17:18 -0700 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API In-Reply-To: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> References: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> Message-ID: 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 From nakajima.akira at nttcom.co.jp Fri Jul 6 03:10:34 2018 From: nakajima.akira at nttcom.co.jp (Nakajima Akira) Date: Fri, 6 Jul 2018 12:10:34 +0900 Subject: Review Request Re: [PATCH] Fix bug to handle minus value glyph_id on Windows In-Reply-To: References: <019bd585-5a3b-8cdc-8f15-f890e32055c5@nttcom.co.jp> Message-ID: <8966cde8-bb77-7b01-cd04-c0fe88102a6d@nttcom.co.jp> Hi All. I created github account today and re-posted this patch to github. Please review the following fix: patch: https://github.com/javafxports/openjdk-jfx/pull/125 Regards, Akira Nakajima -------------------------------------- Company: NTT Comware Corporation Name: Akira Nakajima E-Mail: nakajima.akira at nttcom.co.jp OLA : http://www.oracle.com/technetwork/community/oca-486395.html#n -------------------------------------- On 2018/06/27 15:02, Nakajima Akira wrote: > This bug is happened on Windows. > > Sorry, I should use SHORTMASK instead of intMask. > I re-send patch. > Difference is name only. > intMask -> SHORTMASK > > > > diff --git > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > > --- > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > > +++ > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > > @@ -52,6 +52,7 @@ > private static D2D1_COLOR_F WHITE = new D2D1_COLOR_F(1f, 1f, 1f, 1f); > private static D2D1_MATRIX_3X2_F D2D2_MATRIX_IDENTITY = new > D2D1_MATRIX_3X2_F(1,0, 0,1, 0,0); > > + static final int SHORTMASK = 0x0000ffff; > > DWGlyph(DWFontStrike strike, int glyphCode, boolean drawShapes) { > this.strike = strike; > @@ -303,12 +304,12 @@ > > @Override > public int getGlyphCode() { > - return run.glyphIndices; > + return ((int)run.glyphIndices & SHORTMASK); > } > > @Override > public RectBounds getBBox() { > - return strike.getBBox(run.glyphIndices); > + return strike.getBBox((int)run.glyphIndices & SHORTMASK); > } > > @Override > @@ -321,7 +322,7 @@ > > @Override > public Shape getShape() { > - return strike.createGlyphOutline(run.glyphIndices); > + return strike.createGlyphOutline((int)run.glyphIndices & > SHORTMASK); > } > > @Override > diff --git > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > > --- > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > > +++ > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > > @@ -138,6 +138,7 @@ > int i, j; > int[] iglyphs = new int[glyphCount]; > int slotMask = slot << 24; > + final int SHORTMASK = 0x0000ffff; > boolean missingGlyph = false; > i = 0; j = rtl ? glyphCount - 1 : 0; > while (i < glyphCount) { > @@ -145,7 +146,7 @@ > missingGlyph = true; > if (composite) break; > } > - iglyphs[i] = glyphs[j] | slotMask; > + iglyphs[i] = ((int)glyphs[j] & SHORTMASK) | slotMask; > i++; > j+=step; > } > > > Thanks. > Akira Nakajima > > > On 2018/06/27 14:52, Nakajima Akira wrote: >> # This patch is separated from >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/022005.html >> >> >> Java issue error of ArrayIndexOutOfBoundsException by run following Test >> program on Windows. >> This bug is that Java handles big glyph_id as minus value. >> For Example, >> Inside JavaFX, glyph_id 49496(Uint16) is now handled as -16040(short). >> >> >> ScreenShots of before/after applying this patch. >> Windows10 x64 (openjfx11 and Oracle JDK 10.0.1) >> https://drive.google.com/drive/folders/1UHPfCbQF4X_SSvjqgNGGKfEm-8GiNP80 >> >> >> >> # NOTICE >> Now Windows API provide glyphIndices as UINT16. >> Exsample) >> https://msdn.microsoft.com/en-us/library/windows/desktop/dd316625%28v=vs.85%29.aspx >> >> >> >> But originally, Windows API should provide as UINT32. >> Because CMAP Format 8,12,13 have UINT32. >> https://docs.microsoft.com/en-us/typography/opentype/spec/cmap >> https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6cmap.html >> >> >> >> I have not reported to Microsoft, since I guess Microsoft knows this >> problem. >> >> CMap.java provide char (UINT16). >> Freetype2 provide UINT32. >> >> >> >> Thanks. >> Akira Nakajima >> >> >> [PATCH] >> javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >> >> javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >> >> >> >> ========================= >> PATCH >> ========================= >> diff --git >> a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >> >> b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >> >> >> --- >> a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >> >> >> +++ >> b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >> >> >> @@ -52,6 +52,7 @@ >> private static D2D1_COLOR_F WHITE = new D2D1_COLOR_F(1f, 1f, 1f, >> 1f); >> private static D2D1_MATRIX_3X2_F D2D2_MATRIX_IDENTITY = new >> D2D1_MATRIX_3X2_F(1,0, 0,1, 0,0); >> >> + static final int intMask = 0x0000ffff; >> >> DWGlyph(DWFontStrike strike, int glyphCode, boolean drawShapes) { >> this.strike = strike; >> @@ -303,12 +304,12 @@ >> >> @Override >> public int getGlyphCode() { >> - return run.glyphIndices; >> + return ((int)run.glyphIndices & intMask); >> } >> >> @Override >> public RectBounds getBBox() { >> - return strike.getBBox(run.glyphIndices); >> + return strike.getBBox((int)run.glyphIndices & intMask); >> } >> >> @Override >> @@ -321,7 +322,7 @@ >> >> @Override >> public Shape getShape() { >> - return strike.createGlyphOutline(run.glyphIndices); >> + return strike.createGlyphOutline((int)run.glyphIndices & >> intMask); >> } >> >> @Override >> diff --git >> a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >> >> b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >> >> >> --- >> a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >> >> >> +++ >> b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >> >> >> @@ -138,6 +138,7 @@ >> int i, j; >> int[] iglyphs = new int[glyphCount]; >> int slotMask = slot << 24; >> + final int intMask = 0x0000ffff; >> boolean missingGlyph = false; >> i = 0; j = rtl ? glyphCount - 1 : 0; >> while (i < glyphCount) { >> @@ -145,7 +146,7 @@ >> missingGlyph = true; >> if (composite) break; >> } >> - iglyphs[i] = glyphs[j] | slotMask; >> + iglyphs[i] = ((int)glyphs[j] & intMask) | slotMask; >> i++; >> j+=step; >> } >> >> >> >> ========================= >> Test for Win10 >> ========================= >> import javafx.application.Application; >> import static javafx.application.Application.launch; >> import javafx.scene.Group; >> import javafx.scene.Scene; >> import javafx.scene.paint.Color; >> import javafx.scene.text.Font; >> import javafx.scene.text.Text; >> import javafx.scene.text.TextFlow; >> import javafx.stage.Stage; >> >> public class TestHandlingBigGlyphID_Win10 extends Application { >> @Override >> public void start(Stage stage) throws Exception { >> final String fontName = "ARIALUNI.TTF"; // Arial Unicode MS >> // download from >> https://www.wfonts.com/download/data/2015/05/16/arial-unicode-ms/ARIALUNI.TTF >> >> >> // and place in $(user.home)/fonts/ >> // e.g. C:/Users/username/fonts/arialuni.ttf >> >> Font ourFont = >> Font.loadFont("file://"+System.getProperty("user.home")+"/fonts/"+fontName.toString(), >> >> 48); >> TextFlow textFlow = new TextFlow(); >> // Unicode(GlyphID) >> Text text = new Text("\uD7A3\u0E3F"); // U+D7A3(49496) + >> U+0E3F(1262) >> /* Inside JavaFX, 49496(Uint16) is handled as -16040(short). >> * By ScriptMapper.isComplexCharCode(), U+0E3F is handled as >> complex. >> * When in condition with minus glyphID value and complex >> * , JavaFX is forcibly terminated. >> * (java.lang.ArrayIndexOutOfBoundsException) >> */ >> >> text.setFill(Color.GREEN); >> text.setFont(ourFont); >> textFlow.getChildren().addAll(text); >> >> Group group = new Group(textFlow); >> Scene scene = new Scene(group, 100, 60, Color.WHITE); >> stage.setScene(scene); >> stage.show(); >> } >> } >> >> ========================= >> Test for Win7 and Win10 >> ========================= >> import javafx.application.Application; >> import static javafx.application.Application.launch; >> import javafx.scene.Group; >> import javafx.scene.Scene; >> import javafx.scene.paint.Color; >> import javafx.scene.text.Font; >> import javafx.scene.text.Text; >> import javafx.scene.text.TextFlow; >> import javafx.stage.Stage; >> >> public class TestHandlingBigGlyphID_Win7_and_Win10 extends Application { >> @Override >> public void start(Stage stage) throws Exception { >> final String family = "Arial Unicode MS"; // ARIALUNI.TTF >> // download from >> https://www.wfonts.com/download/data/2015/05/16/arial-unicode-ms/ARIALUNI.TTF >> >> >> // and You NEED install font. >> >> Font ourFont = Font.font(family, 48); >> TextFlow textFlow = new TextFlow(); >> // Unicode(GlyphID) >> Text text = new Text("\uD7A3\u0E3F"); // U+D7A3(49496) + >> U+0E3F(1262) >> /* Inside JavaFX, 49496(Uint16) is handled as -16040(short). >> * By ScriptMapper.isComplexCharCode(), U+0E3F is handled as >> complex. >> * When in condition with minus glyphID value and complex >> * , JavaFX is forcibly terminated. >> * (java.lang.ArrayIndexOutOfBoundsException) >> */ >> >> text.setFill(Color.GREEN); >> text.setFont(ourFont); >> textFlow.getChildren().addAll(text); >> >> Group group = new Group(textFlow); >> Scene scene = new Scene(group, 100, 60, Color.WHITE); >> stage.setScene(scene); >> stage.show(); >> } >> } >> >> >> -------------------------------------- >> Company: NTT Comware Corporation >> Name: Akira Nakajima >> E-Mail: nakajima.akira at nttcom.co.jp >> -------------------------------------- From prem.balakrishnan at oracle.com Fri Jul 6 04:16:45 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Thu, 5 Jul 2018 21:16:45 -0700 (PDT) Subject: [11] Review Request:JDK-8186187 Modify return type of public API StyleConverter.getEnumConverter() In-Reply-To: <8260c2ca-26fd-4a7f-ab4a-f3cb02926e8e@default> References: <8260c2ca-26fd-4a7f-ab4a-f3cb02926e8e@default> Message-ID: Hi Kevin, Ajit Please review the updated patch with test case: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/fx/8186187/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/fx/8186187/webrev.01/ Regards, Prem From: Prem Balakrishnan Sent: Monday, May 14, 2018 5:04 PM To: Kevin Rushforth ; Ajit Haribhau Ghaisas (ajit.ghaisas at oracle.com) ; openjfx-dev at openjdk.java.net List Subject: [11] Review Request:JDK-8186187 Modify return type of public API StyleConverter.getEnumConverter() Hi Kevin, Ajit Request you to review following fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8186187 Webrev: http://cr.openjdk.java.net/~pkbalakr/fx/8186187/webrev.00/ Regards, Prem From prasanta.sadhukhan at oracle.com Fri Jul 6 06:29:56 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 6 Jul 2018 11:59:56 +0530 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API In-Reply-To: References: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> Message-ID: <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> 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 > From nakajima.akira at nttcom.co.jp Fri Jul 6 06:59:24 2018 From: nakajima.akira at nttcom.co.jp (Nakajima Akira) Date: Fri, 6 Jul 2018 15:59:24 +0900 Subject: Review Request JDK-8187100 [JavaFX] To make display Variation Selectors(SVS/IVS) on Win(VISTA-) and MacOS(10.6-) In-Reply-To: References: Message-ID: <389c3fab-0b86-e1f0-d8c8-1d76e828024f@nttcom.co.jp> 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.akira at nttcom.co.jp OLA : http://www.oracle.com/technetwork/community/oca-486395.html#n -------------------------------------- From mp at jugs.org Fri Jul 6 10:40:54 2018 From: mp at jugs.org (Michael Paus) Date: Fri, 6 Jul 2018 12:40:54 +0200 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: 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 From kevin.rushforth at oracle.com Fri Jul 6 11:41:25 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 6 Jul 2018 04:41:25 -0700 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API In-Reply-To: <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> References: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> Message-ID: 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 >> > From johan.vos at gluonhq.com Fri Jul 6 12:33:30 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 6 Jul 2018 14:33:30 +0200 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: 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-schramm at 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-schramm at hexagon.com > > Hexagon Geospatial > Wittenberger Stra?e 15B > 04129 Leipzig, Germany > hexagongeospatial.com > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf > Of Johan Vos > Sent: Donnerstag, 5. Juli 2018 11:03 > To: openjfx-dev at 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 > > From johan.vos at gluonhq.com Fri Jul 6 12:54:20 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 6 Jul 2018 14:54:20 +0200 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: 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 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 > > > From mp at jugs.org Fri Jul 6 17:15:04 2018 From: mp at jugs.org (Michael Paus) Date: Fri, 6 Jul 2018 19:15:04 +0200 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: <62088fe1-a3ce-c819-032b-8655a36ff8bd@jugs.org> 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 > 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 > > From kevin.rushforth at oracle.com Fri Jul 6 23:00:22 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 6 Jul 2018 16:00:22 -0700 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API In-Reply-To: <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> References: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> Message-ID: <52f046f0-4621-596c-b84f-7602266c30d0@oracle.com> 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 >> > From johan.vos at gluonhq.com Sat Jul 7 09:28:34 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 7 Jul 2018 11:28:34 +0200 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: As another possible "solution" for this, we can avoid using SNAPSHOTS by using releases instead. This would also make sense in aligning the maven artifacts with the standalone Java SDK, by using the same build number (e.g. javafx.graphics:11.0.0-ea18). This will make it much easier for gradle projects. The drawbacks I see are mainly semantic. The sonatype release repository is for releases, and 11.0.0-ea18 is, well, an early-access release. But since it is tagged, it can easily be traced down to an exact state of the code repository, so I think it makes sense. - Johan On Fri, Jul 6, 2018 at 2:33 PM Johan Vos wrote: > 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-schramm at 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-schramm at hexagon.com >> >> Hexagon Geospatial >> Wittenberger Stra?e 15B >> 04129 Leipzig, Germany >> hexagongeospatial.com >> >> -----Original Message----- >> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >> Behalf Of Johan Vos >> Sent: Donnerstag, 5. Juli 2018 11:03 >> To: openjfx-dev at 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 >> >> From tbee at tbee.org Sun Jul 8 08:32:24 2018 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 8 Jul 2018 10:32:24 +0200 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: <6e51598e-5af8-3704-d478-1a648ed1973c@tbee.org> If you deploy it as a release, Sonatype won't allow overwriting, right? So its behavior is different from a snapshot and you can't overwrite it each night. Maybe frequently releasing EA builds is acceptable for Gradle, and Maven can still use snapshots? Or can Gradle be told to use a specific snapshot (20180702.224902-3), if the latest fails somehow? On 7-7-2018 11:28, Johan Vos wrote: > As another possible "solution" for this, we can avoid using SNAPSHOTS by > using releases instead. This would also make sense in aligning the maven > artifacts with the standalone Java SDK, by using the same build number > (e.g. javafx.graphics:11.0.0-ea18). > > This will make it much easier for gradle projects. > > The drawbacks I see are mainly semantic. The sonatype release repository is > for releases, and 11.0.0-ea18 is, well, an early-access release. But since > it is tagged, it can easily be traced down to an exact state of the code > repository, so I think it makes sense. > > - Johan > > On Fri, Jul 6, 2018 at 2:33 PM Johan Vos wrote: > >> 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-schramm at 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-schramm at hexagon.com >>> >>> Hexagon Geospatial >>> Wittenberger Stra?e 15B >>> 04129 Leipzig, Germany >>> hexagongeospatial.com >>> >>> -----Original Message----- >>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>> Behalf Of Johan Vos >>> Sent: Donnerstag, 5. Juli 2018 11:03 >>> To: openjfx-dev at 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 >>> >>> From ket1999 at gmail.com Sun Jul 8 09:06:28 2018 From: ket1999 at gmail.com (Kenzie Togami) Date: Sun, 8 Jul 2018 02:06:28 -0700 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: Hi Johan, > 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. I think that the varying snapshots versions probably occur because a separate publication is set up for each `compileTarget`: https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1564 I haven't used the Gradle maven-publish plugin yet but I think it could work if you instead iterate over each target where the artifacts are generated, which is the only place it's used anyways: compileTargets { t -> artifact project.tasks."moduleEmptyPublicationJar$t.capital" artifact project.tasks."modularPublicationJar$t.capital" { classifier "$t.name" } } On Fri, Jul 6, 2018 at 5:34 AM Johan Vos wrote: > 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-schramm at 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-schramm at hexagon.com > > > > Hexagon Geospatial > > Wittenberger Stra?e 15B > > 04129 Leipzig, Germany > > hexagongeospatial.com > > > > -----Original Message----- > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On > Behalf > > Of Johan Vos > > Sent: Donnerstag, 5. Juli 2018 11:03 > > To: openjfx-dev at 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 > > > > > -- ~Kenzie Togami From johan.vos at gluonhq.com Sun Jul 8 12:38:22 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 8 Jul 2018 14:38:22 +0200 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: I don't think that will help, as the artifacts for the different platforms are not created inside the same gradle process. We don't do cross-compiling, so for each compileTarget a different machine and a different build process is used. Hence, I think we have to deal with separate publications anyhow, right? - Johan On Sun, Jul 8, 2018 at 11:06 AM Kenzie Togami wrote: > Hi Johan, > > > 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. > > I think that the varying snapshots versions probably occur because a > separate publication is set up for each `compileTarget`: > https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1564 > I haven't used the Gradle maven-publish plugin yet but I think it could > work if you instead iterate over each target where the artifacts are > generated, which is the only place it's used anyways: > > compileTargets { t -> > artifact project.tasks."moduleEmptyPublicationJar$t.capital" > artifact project.tasks."modularPublicationJar$t.capital" { > classifier "$t.name" > } > } > > > On Fri, Jul 6, 2018 at 5:34 AM Johan Vos wrote: > >> 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-schramm at 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> <+49%20341%2092603047> > > >> > E: gerd.mueller-schramm at hexagon.com >> > >> > Hexagon Geospatial >> > Wittenberger Stra?e 15B >> >> >> > >> 04129 Leipzig, Germany >> >> > hexagongeospatial.com >> > >> > -----Original Message----- >> > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >> Behalf >> > Of Johan Vos >> > Sent: Donnerstag, 5. Juli 2018 11:03 >> > To: openjfx-dev at 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 >> > >> > >> > > > -- > ~Kenzie Togami > From swpalmer at gmail.com Sun Jul 8 17:03:59 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 8 Jul 2018 13:03:59 -0400 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: If separate Gradle processes produce the artifacts, there is probably a way to bring them together and (re-)publish them together in yet another project. Scott > On Jul 8, 2018, at 8:38 AM, Johan Vos wrote: > > I don't think that will help, as the artifacts for the different platforms > are not created inside the same gradle process. We don't do > cross-compiling, so for each compileTarget a different machine and a > different build process is used. > Hence, I think we have to deal with separate publications anyhow, right? > > - Johan > >> On Sun, Jul 8, 2018 at 11:06 AM Kenzie Togami wrote: >> >> Hi Johan, >> >>> 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. >> >> I think that the varying snapshots versions probably occur because a >> separate publication is set up for each `compileTarget`: >> https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1564 >> I haven't used the Gradle maven-publish plugin yet but I think it could >> work if you instead iterate over each target where the artifacts are >> generated, which is the only place it's used anyways: >> >> compileTargets { t -> >> artifact project.tasks."moduleEmptyPublicationJar$t.capital" >> artifact project.tasks."modularPublicationJar$t.capital" { >> classifier "$t.name" >> } >> } From sven.reimers at gmail.com Sun Jul 8 17:37:28 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 8 Jul 2018 19:37:28 +0200 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: Hi, I think I like the idea of just having something similiar like OpenJDK e.g. 11.0.0-ea18. Do we really need snapshots - i.e. continuous builds published to maven central? -Sven Scott Palmer schrieb am So., 8. Juli 2018, 19:04: > If separate Gradle processes produce the artifacts, there is probably a > way to bring them together and (re-)publish them together in yet another > project. > > Scott > > > On Jul 8, 2018, at 8:38 AM, Johan Vos wrote: > > > > I don't think that will help, as the artifacts for the different > platforms > > are not created inside the same gradle process. We don't do > > cross-compiling, so for each compileTarget a different machine and a > > different build process is used. > > Hence, I think we have to deal with separate publications anyhow, right? > > > > - Johan > > > >> On Sun, Jul 8, 2018 at 11:06 AM Kenzie Togami > wrote: > >> > >> Hi Johan, > >> > >>> 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. > >> > >> I think that the varying snapshots versions probably occur because a > >> separate publication is set up for each `compileTarget`: > >> > https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1564 > >> I haven't used the Gradle maven-publish plugin yet but I think it could > >> work if you instead iterate over each target where the artifacts are > >> generated, which is the only place it's used anyways: > >> > >> compileTargets { t -> > >> artifact project.tasks."moduleEmptyPublicationJar$t.capital" > >> artifact project.tasks."modularPublicationJar$t.capital" { > >> classifier "$t.name" > >> } > >> } > From johan.vos at gluonhq.com Sun Jul 8 19:28:49 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 8 Jul 2018 21:28:49 +0200 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: I agree. It's not only the pragmatic approach (no need for a work-around for the gradle snapshot/classifier combo issue), but it also makes it easier to track issues (e.g. "this issue appears with 11.0.0-ea18 but is gone with ea19) -> versioning in JBS/github. - Johan On Sun, Jul 8, 2018 at 7:37 PM Sven Reimers wrote: > Hi, > > I think I like the idea of just having something similiar like OpenJDK > e.g. 11.0.0-ea18. > Do we really need snapshots - i.e. continuous builds published to maven > central? > > -Sven > > Scott Palmer schrieb am So., 8. Juli 2018, 19:04: > >> If separate Gradle processes produce the artifacts, there is probably a >> way to bring them together and (re-)publish them together in yet another >> project. >> >> Scott >> >> > On Jul 8, 2018, at 8:38 AM, Johan Vos wrote: >> > >> > I don't think that will help, as the artifacts for the different >> platforms >> > are not created inside the same gradle process. We don't do >> > cross-compiling, so for each compileTarget a different machine and a >> > different build process is used. >> > Hence, I think we have to deal with separate publications anyhow, right? >> > >> > - Johan >> > >> >> On Sun, Jul 8, 2018 at 11:06 AM Kenzie Togami >> wrote: >> >> >> >> Hi Johan, >> >> >> >>> 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. >> >> >> >> I think that the varying snapshots versions probably occur because a >> >> separate publication is set up for each `compileTarget`: >> >> >> https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1564 >> >> I haven't used the Gradle maven-publish plugin yet but I think it could >> >> work if you instead iterate over each target where the artifacts are >> >> generated, which is the only place it's used anyways: >> >> >> >> compileTargets { t -> >> >> artifact project.tasks."moduleEmptyPublicationJar$t.capital" >> >> artifact project.tasks."modularPublicationJar$t.capital" { >> >> classifier "$t.name" >> >> } >> >> } >> > From matthieu at brouillard.fr Sun Jul 8 19:30:42 2018 From: matthieu at brouillard.fr (Matthieu BROUILLARD) Date: Sun, 8 Jul 2018 21:30:42 +0200 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: Hi, If you are really looking for some automated project versioning, you can also look at jgitver (1) which can compute project versions based on git commits, tags, branches, ... There is a maven core extension (2) and a gradle plugin (3) for it. -- Matthieu Brouillard 1: https://github.com/jgitver/jgitver 2: https://github.com/jgitver/jgitver-maven-plugin 3: https://github.com/jgitver/gradle-jgitver-plugin On Sun, Jul 8, 2018 at 7:57 PM Sven Reimers wrote: > Hi, > > I think I like the idea of just having something similiar like OpenJDK e.g. > 11.0.0-ea18. > Do we really need snapshots - i.e. continuous builds published to maven > central? > > -Sven > > Scott Palmer schrieb am So., 8. Juli 2018, 19:04: > > > If separate Gradle processes produce the artifacts, there is probably a > > way to bring them together and (re-)publish them together in yet another > > project. > > > > Scott > > > > > On Jul 8, 2018, at 8:38 AM, Johan Vos wrote: > > > > > > I don't think that will help, as the artifacts for the different > > platforms > > > are not created inside the same gradle process. We don't do > > > cross-compiling, so for each compileTarget a different machine and a > > > different build process is used. > > > Hence, I think we have to deal with separate publications anyhow, > right? > > > > > > - Johan > > > > > >> On Sun, Jul 8, 2018 at 11:06 AM Kenzie Togami > > wrote: > > >> > > >> Hi Johan, > > >> > > >>> 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. > > >> > > >> I think that the varying snapshots versions probably occur because a > > >> separate publication is set up for each `compileTarget`: > > >> > > > https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1564 > > >> I haven't used the Gradle maven-publish plugin yet but I think it > could > > >> work if you instead iterate over each target where the artifacts are > > >> generated, which is the only place it's used anyways: > > >> > > >> compileTargets { t -> > > >> artifact project.tasks."moduleEmptyPublicationJar$t.capital" > > >> artifact project.tasks."modularPublicationJar$t.capital" { > > >> classifier "$t.name" > > >> } > > >> } > > > From ket1999 at gmail.com Sun Jul 8 19:42:17 2018 From: ket1999 at gmail.com (Kenzie Togami) Date: Sun, 8 Jul 2018 12:42:17 -0700 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: >I don't think that will help, as the artifacts for the different platforms are not created inside the same gradle process. We don't do cross-compiling, so for each compileTarget a different machine and a different build process is used. >Hence, I think we have to deal with separate publications anyhow, right? Yes, that would be correct. Scott's suggestion could work (and is what I would suggest in this situation) but would require more moving parts for a full build, which may be too complicated. On Sun, Jul 8, 2018 at 5:38 AM Johan Vos wrote: > I don't think that will help, as the artifacts for the different platforms > are not created inside the same gradle process. We don't do > cross-compiling, so for each compileTarget a different machine and a > different build process is used. > Hence, I think we have to deal with separate publications anyhow, right? > > - Johan > > On Sun, Jul 8, 2018 at 11:06 AM Kenzie Togami wrote: > >> Hi Johan, >> >> > 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. >> >> I think that the varying snapshots versions probably occur because a >> separate publication is set up for each `compileTarget`: >> https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1564 >> I haven't used the Gradle maven-publish plugin yet but I think it could >> work if you instead iterate over each target where the artifacts are >> generated, which is the only place it's used anyways: >> >> compileTargets { t -> >> artifact project.tasks."moduleEmptyPublicationJar$t.capital" >> artifact project.tasks."modularPublicationJar$t.capital" { >> classifier "$t.name" >> } >> } >> >> >> On Fri, Jul 6, 2018 at 5:34 AM Johan Vos wrote: >> >>> 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-schramm at 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> <+49%20341%2092603047> >> >> >>> > E: gerd.mueller-schramm at hexagon.com >>> > >>> > Hexagon Geospatial >>> > Wittenberger Stra?e 15B >>> >>> >>> > >>> 04129 Leipzig, Germany >>> >>> > hexagongeospatial.com >>> > >>> > -----Original Message----- >>> > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>> Behalf >>> > Of Johan Vos >>> > Sent: Donnerstag, 5. Juli 2018 11:03 >>> > To: openjfx-dev at 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 >>> > >>> > >>> >> >> >> -- >> ~Kenzie Togami >> > -- ~Kenzie Togami From tbee at tbee.org Sun Jul 8 19:59:06 2018 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 8 Jul 2018 21:59:06 +0200 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: <9c4b48a4-1187-ab33-37d6-f3becf4fd193@tbee.org> JFXtras also uses versioning based on the associated Java version, which works quite well. It can change based on what will be picked here. Or not. :-) On 8-7-2018 21:28, Johan Vos wrote: > I agree. > It's not only the pragmatic approach (no need for a work-around for the > gradle snapshot/classifier combo issue), but it also makes it easier to > track issues (e.g. "this issue appears with 11.0.0-ea18 but is gone with > ea19) -> versioning in JBS/github. > > - Johan > > On Sun, Jul 8, 2018 at 7:37 PM Sven Reimers wrote: > >> Hi, >> >> I think I like the idea of just having something similiar like OpenJDK >> e.g. 11.0.0-ea18. >> Do we really need snapshots - i.e. continuous builds published to maven >> central? >> >> -Sven >> >> Scott Palmer schrieb am So., 8. Juli 2018, 19:04: >> >>> If separate Gradle processes produce the artifacts, there is probably a >>> way to bring them together and (re-)publish them together in yet another >>> project. >>> >>> Scott >>> >>>> On Jul 8, 2018, at 8:38 AM, Johan Vos wrote: >>>> >>>> I don't think that will help, as the artifacts for the different >>> platforms >>>> are not created inside the same gradle process. We don't do >>>> cross-compiling, so for each compileTarget a different machine and a >>>> different build process is used. >>>> Hence, I think we have to deal with separate publications anyhow, right? >>>> >>>> - Johan >>>> >>>>> On Sun, Jul 8, 2018 at 11:06 AM Kenzie Togami >>> wrote: >>>>> Hi Johan, >>>>> >>>>>> 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. >>>>> >>>>> I think that the varying snapshots versions probably occur because a >>>>> separate publication is set up for each `compileTarget`: >>>>> >>> https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1564 >>>>> I haven't used the Gradle maven-publish plugin yet but I think it could >>>>> work if you instead iterate over each target where the artifacts are >>>>> generated, which is the only place it's used anyways: >>>>> >>>>> compileTargets { t -> >>>>> artifact project.tasks."moduleEmptyPublicationJar$t.capital" >>>>> artifact project.tasks."modularPublicationJar$t.capital" { >>>>> classifier "$t.name" >>>>> } >>>>> } From steve.hruda at gmail.com Mon Jul 9 09:56:39 2018 From: steve.hruda at gmail.com (Steve Hruda) Date: Mon, 9 Jul 2018 11:56:39 +0200 Subject: Jlink - OpenJDK 11 Build 21 in combination with OpenJFX 11 Build 17 Message-ID: Hi, I downloaded the JMODs of OpenJFX 11 Build 17 and OpenJDK11 Build 21 and unpacked them in the same directory. So I have now a jdk11 and a javafx-jmods-11 directory at my unzip location. Now I want to create a custom runtime image which uses java.se and javafx.controls but I get an PluginException (Duplicate resources) I executed the following: jdk-11\bin\jlink.exe --module-path "jdk-11\jmods;javafx-jmods-11" --add-modules "java.se,javafx.controls" --output myRuntime --compress=2 --strip-debug I get a similar exception if I use only javafx.controls.... jdk-11\bin\jlink.exe --module-path "jdk-11\jmods;javafx-jmods-11" --add-modules javafx.controls --output myRuntime --compress=2 --strip-debug Any Ideas? Best Regards, Steve --- Error in case of --add-modules java.se,javafx.controls Error: jdk.tools.jlink.plugin.PluginException: Duplicate resources: {bin\api-ms-win-crt-string-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-heap-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-timezone-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-runtime-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-locale-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-conio-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-processenvironment-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-stdio-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-synch-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-interlocked-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-file-l2-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-namedpipe-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-time-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-libraryloader-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-debug-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-heap-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-console-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-private-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-environment-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-math-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-errorhandling-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-processthreads-l1-1-1.dll=[javafx.graphics, java.base], bin\ucrtbase.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-convert-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-sysinfo-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-file-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-localization-l1-2-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-process-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-profile-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-filesystem-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-multibyte-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-datetime-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-file-l1-2-0.dll=[javafx.graphics, java.base], bin\api-ms-win-crt-utility-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-handle-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-rtlsupport-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-memory-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-processthreads-l1-1-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-synch-l1-2-0.dll=[javafx.graphics, java.base], bin\api-ms-win-core-util-l1-1-0.dll=[javafx.graphics, java.base], bin\vcruntime140.dll=[javafx.graphics, java.base], bin\api-ms-win-core-string-l1-1-0.dll=[javafx.graphics, java.base], bin\msvcp140.dll=[javafx.graphics, java.base]} From prasanta.sadhukhan at oracle.com Mon Jul 9 11:12:48 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 9 Jul 2018 16:42:48 +0530 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API In-Reply-To: <52f046f0-4621-596c-b84f-7602266c30d0@oracle.com> References: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> <52f046f0-4621-596c-b84f-7602266c30d0@oracle.com> Message-ID: <04091299-44e3-ad9b-2210-f4b420c1dac7@oracle.com> Hi Kevin, Modified webrev to address the "public" leakage http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.5/ I am looking into the test failures. Regards Prasanta On 7/7/2018 4:30 AM, Kevin Rushforth wrote: > 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 >>> >> > From arunprasad.rajkumar at oracle.com Mon Jul 9 11:53:27 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Mon, 9 Jul 2018 17:23:27 +0530 Subject: [openjfx11] Review request for 8206899: DRT crashes randomly when running 'dom/html/level2/html/AppletsCollection.html' Message-ID: Hi, Please review the following fix, https://bugs.openjdk.java.net/browse/JDK-8206899 http://cr.openjdk.java.net/~arajkumar/8206899/webrev Root-cause: Problem is due to the following statement in `void PluginWidgetJava::updatePluginWidget()` jobject obj = platformWidget(); platformWidget method returns temporary JGObject as a value and it?s life time is restricted with in the same line. Proposed solution: Change the `obj` type to JLObject, so that it will hold the ref object as local variable in the function scope. JLObject obj = platformWidget(); Thanks, Arun From kevin.rushforth at oracle.com Mon Jul 9 15:07:04 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 9 Jul 2018 08:07:04 -0700 Subject: Jlink - OpenJDK 11 Build 21 in combination with OpenJFX 11 Build 17 In-Reply-To: References: Message-ID: Hi Steve, This is happening because the JDK has now switched to VS 2017 for its build, and is now delivering the Microsoft redistributable DLLs. JavaFX switched to using VS 2017 prior to JDK 10, so the javafx.graphics module also includes these DLLs. I will file a bug against JavaFX. I don't know if there is an option to jlink to have it ignore such duplicates, but if not, then you will need to wait until we fix it or use an earlier EA build of JDK 11 for testing. -- Kevin On 7/9/2018 2:56 AM, Steve Hruda wrote: > Hi, > I downloaded the JMODs of OpenJFX 11 Build 17 and OpenJDK11 Build 21 and > unpacked them in the same directory. > > So I have now a jdk11 and a javafx-jmods-11 directory at my unzip location. > Now I want to create a custom runtime image which uses java.se and > javafx.controls but I get an PluginException (Duplicate resources) > > I executed the following: > > jdk-11\bin\jlink.exe --module-path "jdk-11\jmods;javafx-jmods-11" > --add-modules "java.se,javafx.controls" --output myRuntime --compress=2 > --strip-debug > > I get a similar exception if I use only javafx.controls.... > > jdk-11\bin\jlink.exe --module-path "jdk-11\jmods;javafx-jmods-11" > --add-modules javafx.controls --output myRuntime --compress=2 > --strip-debug > > Any Ideas? > Best Regards, > Steve > > --- > > Error in case of --add-modules java.se,javafx.controls > Error: jdk.tools.jlink.plugin.PluginException: Duplicate resources: > {bin\api-ms-win-crt-string-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-heap-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-timezone-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-runtime-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-locale-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-conio-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-processenvironment-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-crt-stdio-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-synch-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-interlocked-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-file-l2-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-namedpipe-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-crt-time-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-libraryloader-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-debug-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-heap-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-console-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-crt-private-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-crt-environment-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-crt-math-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-errorhandling-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-processthreads-l1-1-1.dll=[javafx.graphics, > java.base], bin\ucrtbase.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-convert-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-sysinfo-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-file-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-localization-l1-2-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-process-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-profile-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-filesystem-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-multibyte-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-datetime-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-file-l1-2-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-utility-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-handle-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-rtlsupport-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-memory-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-processthreads-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-synch-l1-2-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-util-l1-1-0.dll=[javafx.graphics, java.base], > bin\vcruntime140.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-string-l1-1-0.dll=[javafx.graphics, java.base], > bin\msvcp140.dll=[javafx.graphics, java.base]} From sverre.moe at gmail.com Mon Jul 9 19:13:20 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Mon, 9 Jul 2018 21:13:20 +0200 Subject: JavaFX 11 snapshots in maven sonatype In-Reply-To: References: Message-ID: I thought I replied to the list, and not just you. Probably easier to use the module name as artifactId, but it seems odd though and stands out against all the rest of dependencies naming using a dash delimiter. Den tor. 5. jul. 2018, 19:02 skrev Johan Vos : > The name is the same name as the module (in module-info.java). > I'm very open to discuss this though, so if you want to start a > discussion, send it to the list? I personally have no real preference for > naming, but it's better to change the name now instead of next year :) > > - Johan > > On Thu, Jul 5, 2018 at 6:27 PM Sverre Moe wrote: > >> Great work. >> >> One oddity. Shouldn't artifactId be javafx-controls, instead of >> javafx.controls? >> Never seen any dependencies that used punctuation as delimiter in >> artifactId. >> >> /Sverre >> >> Den tor. 5. jul. 2018 kl. 11:04 skrev 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 >>> >> From kevin.rushforth at oracle.com Tue Jul 10 01:43:01 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 9 Jul 2018 18:43:01 -0700 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API In-Reply-To: <04091299-44e3-ad9b-2210-f4b420c1dac7@oracle.com> References: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> <52f046f0-4621-596c-b84f-7602266c30d0@oracle.com> <04091299-44e3-ad9b-2210-f4b420c1dac7@oracle.com> Message-ID: Hi Prasanta, The public API looks fine now. I sent you an offline note about one of the test failures (SwingNodeMemoryLeakTest). There are still whitespace problems that will cause a failure in 'gradle checkrepo' (and 'hg jcheck'). I'll do a more thorough review in the next day or so. -- Kevin On 7/9/2018 4:12 AM, Prasanta Sadhukhan wrote: > > Hi Kevin, > > Modified webrev to address the "public" leakage > http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.5/ > > I am looking into the test failures. > > Regards > Prasanta > On 7/7/2018 4:30 AM, Kevin Rushforth wrote: >> 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 >>>> >>> >> > From prasanta.sadhukhan at oracle.com Tue Jul 10 10:28:51 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 10 Jul 2018 15:58:51 +0530 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API In-Reply-To: References: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> <52f046f0-4621-596c-b84f-7602266c30d0@oracle.com> <04091299-44e3-ad9b-2210-f4b420c1dac7@oracle.com> Message-ID: <3b9d0c51-153e-e74a-2667-761bb5c877d9@oracle.com> Hi Kevin, Please find modified webrev with some more refactoring to move more common code to SwingNode and also this solves SwingNodeMemoryLeakTest failure http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.6/ Regards Prasanta On 7/10/2018 7:13 AM, Kevin Rushforth wrote: > Hi Prasanta, > > The public API looks fine now. I sent you an offline note about one of > the test failures (SwingNodeMemoryLeakTest). > > There are still whitespace problems that will cause a failure in > 'gradle checkrepo' (and 'hg jcheck'). > > I'll do a more thorough review in the next day or so. > > -- Kevin > > > On 7/9/2018 4:12 AM, Prasanta Sadhukhan wrote: >> >> Hi Kevin, >> >> Modified webrev to address the "public" leakage >> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.5/ >> >> I am looking into the test failures. >> >> Regards >> Prasanta >> On 7/7/2018 4:30 AM, Kevin Rushforth wrote: >>> 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 >>>>> >>>> >>> >> > From kevin.rushforth at oracle.com Tue Jul 10 11:47:24 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Jul 2018 04:47:24 -0700 Subject: OpenJFX 11 is in Rampdown Phase One (RDP1) Message-ID: <9a0763c7-a29c-bf61-1477-ad70894fe498@oracle.com> To: OpenJFX Developers As a reminder, OpenJFX 11 is now in Rampdown Phase One RDP1. [1] During RDP1, the only restriction is that any enhancements will need explicit approval to go in. Note that these restrictions apply to the jfx-dev/rt mainline (and by extension, the develop branch of the GitHub sandbox), since we have not yet forked a stabilization branch -- for this release that will happen at RDP2, which starts on Monday, Aug 6 (at 23:59 Pacific Daylight Time). We will use the same rules for RDP1 that the JDK uses [2], with three modifications: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 11 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx11-enhancement-request", "openjfx11-enhancement-yes", "openjfx11-enhancement-no" and "openjfx11-enhancement-nmi" as corresponding labels. 3. No explicit approval is needed to push P4 bugs during RDP1, as long as those bugs have otherwise met the usual code review criteria. Having said that, I do not expect reviewers or developers to spend much time on P4 bugs. We have 4 weeks until RDP2 and we would be better served fixing higher priority bugs. There are two "must fix" enhancements for this release that are in progress: JDK-8205919: create artifacts and functionality to upload them to Maven Central [3] JDK-8195811: Support FX Swing interop using public API [4] Other high-priority enhancements might be considered during RDP1, but the closer we get to the end of the release, the more careful we will be about including anything that introduces risk. Let me know if there are any questions. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-July/022083.html [2] http://openjdk.java.net/jeps/3 [3] https://bugs.openjdk.java.net/browse/JDK-8205919 [4] https://bugs.openjdk.java.net/browse/JDK-8195811 From lhochet at gmail.com Tue Jul 10 20:34:31 2018 From: lhochet at gmail.com (Ludovic HOCHET) Date: Tue, 10 Jul 2018 22:34:31 +0200 Subject: Jlink - OpenJDK 11 Build 21 in combination with OpenJFX 11 Build 17 In-Reply-To: References: Message-ID: Hello Steve, you can try adding --exclude-files glob:/javafx.graphics/lib/api-ms*.dll,glob:/javafx.graphics/lib/ucrtbase.dll,glob:/javafx.graphics/lib/vcruntime140.dll,glob:/javafx.graphics/lib/,glob:/javafx.graphics/lib/msvcp140.dll to your jlink command line. HTH, On 9 July 2018 at 11:56, Steve Hruda wrote: > Hi, > I downloaded the JMODs of OpenJFX 11 Build 17 and OpenJDK11 Build 21 and > unpacked them in the same directory. > > So I have now a jdk11 and a javafx-jmods-11 directory at my unzip location. > Now I want to create a custom runtime image which uses java.se and > javafx.controls but I get an PluginException (Duplicate resources) > > I executed the following: > > jdk-11\bin\jlink.exe --module-path "jdk-11\jmods;javafx-jmods-11" > --add-modules "java.se,javafx.controls" --output myRuntime --compress=2 > --strip-debug > > I get a similar exception if I use only javafx.controls.... > > jdk-11\bin\jlink.exe --module-path "jdk-11\jmods;javafx-jmods-11" > --add-modules javafx.controls --output myRuntime --compress=2 > --strip-debug > > Any Ideas? > Best Regards, > Steve > > --- > > Error in case of --add-modules java.se,javafx.controls > Error: jdk.tools.jlink.plugin.PluginException: Duplicate resources: > {bin\api-ms-win-crt-string-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-heap-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-timezone-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-runtime-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-locale-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-conio-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-processenvironment-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-crt-stdio-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-synch-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-interlocked-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-file-l2-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-namedpipe-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-crt-time-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-libraryloader-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-debug-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-heap-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-console-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-crt-private-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-crt-environment-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-crt-math-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-errorhandling-l1-1-0.dll=[javafx.graphics, > java.base], bin\api-ms-win-core-processthreads-l1-1-1.dll=[javafx.graphics, > java.base], bin\ucrtbase.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-convert-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-sysinfo-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-file-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-localization-l1-2-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-process-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-profile-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-filesystem-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-multibyte-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-datetime-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-file-l1-2-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-crt-utility-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-handle-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-rtlsupport-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-memory-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-processthreads-l1-1-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-synch-l1-2-0.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-util-l1-1-0.dll=[javafx.graphics, java.base], > bin\vcruntime140.dll=[javafx.graphics, java.base], > bin\api-ms-win-core-string-l1-1-0.dll=[javafx.graphics, java.base], > bin\msvcp140.dll=[javafx.graphics, java.base]} -- Ludovic ----------------------------------------- "Les formes qui differencient les etres importent peu si leur pensees s'unissent pour batir un univers..." Yoko Tsuno (in 'Les titans' by Roger Leloup) [The shapes that differenciate beings are not important if their thoughts unite to build a universe] From kevin.rushforth at oracle.com Tue Jul 10 23:35:24 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Jul 2018 16:35:24 -0700 Subject: Jlink - OpenJDK 11 Build 21 in combination with OpenJFX 11 Build 17 In-Reply-To: References: Message-ID: Yes, that will work around the problem.Thanks for posting it. Note that the 'glob:/javafx.graphics/lib/' term is unneeded. The following is sufficient: --exclude-files "glob:/javafx.graphics/lib/api-ms*.dll,glob:/javafx.graphics/lib/ucrtbase.dll,glob:/javafx.graphics/lib/vcruntime140.dll,glob:/javafx.graphics/lib/msvcp140.dll" I filed the following bug to track this for FX 11: https://bugs.openjdk.java.net/browse/JDK-8207015 -- Kevin On 7/10/2018 1:34 PM, Ludovic HOCHET wrote: > Hello Steve, > you can try adding --exclude-files > glob:/javafx.graphics/lib/api-ms*.dll,glob:/javafx.graphics/lib/ucrtbase.dll,glob:/javafx.graphics/lib/vcruntime140.dll,glob:/javafx.graphics/lib/,glob:/javafx.graphics/lib/msvcp140.dll > to your jlink command line. > > HTH, > > On 9 July 2018 at 11:56, Steve Hruda wrote: >> Hi, >> I downloaded the JMODs of OpenJFX 11 Build 17 and OpenJDK11 Build 21 and >> unpacked them in the same directory. >> >> So I have now a jdk11 and a javafx-jmods-11 directory at my unzip location. >> Now I want to create a custom runtime image which uses java.se and >> javafx.controls but I get an PluginException (Duplicate resources) >> >> I executed the following: >> >> jdk-11\bin\jlink.exe --module-path "jdk-11\jmods;javafx-jmods-11" >> --add-modules "java.se,javafx.controls" --output myRuntime --compress=2 >> --strip-debug >> >> I get a similar exception if I use only javafx.controls.... >> >> jdk-11\bin\jlink.exe --module-path "jdk-11\jmods;javafx-jmods-11" >> --add-modules javafx.controls --output myRuntime --compress=2 >> --strip-debug >> >> Any Ideas? >> Best Regards, >> Steve >> >> --- >> >> Error in case of --add-modules java.se,javafx.controls >> Error: jdk.tools.jlink.plugin.PluginException: Duplicate resources: >> {bin\api-ms-win-crt-string-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-crt-heap-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-timezone-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-crt-runtime-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-crt-locale-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-crt-conio-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-processenvironment-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-crt-stdio-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-core-synch-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-core-interlocked-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-core-file-l2-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-core-namedpipe-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-crt-time-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-core-libraryloader-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-core-debug-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-core-heap-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-core-console-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-crt-private-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-crt-environment-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-crt-math-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-core-errorhandling-l1-1-0.dll=[javafx.graphics, >> java.base], bin\api-ms-win-core-processthreads-l1-1-1.dll=[javafx.graphics, >> java.base], bin\ucrtbase.dll=[javafx.graphics, java.base], >> bin\api-ms-win-crt-convert-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-sysinfo-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-file-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-localization-l1-2-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-crt-process-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-profile-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-crt-filesystem-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-crt-multibyte-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-datetime-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-file-l1-2-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-crt-utility-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-handle-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-rtlsupport-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-memory-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-processthreads-l1-1-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-synch-l1-2-0.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-util-l1-1-0.dll=[javafx.graphics, java.base], >> bin\vcruntime140.dll=[javafx.graphics, java.base], >> bin\api-ms-win-core-string-l1-1-0.dll=[javafx.graphics, java.base], >> bin\msvcp140.dll=[javafx.graphics, java.base]} > > From kevin.rushforth at oracle.com Tue Jul 10 23:41:58 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Jul 2018 16:41:58 -0700 Subject: CFV: New OpenJFX Committer: Prem Balakrishnan Message-ID: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> I hereby nominate Prem Balakrishnan [1] to OpenJFX Committer. Prem is a member of JavaFX team at Oracle, who has contributed 10 changesets [2] to OpenJFX. Votes are due by July 24, 2018. Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. Thanks. -- Kevin [1] http://openjdk.java.net/census#pkbalakr [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28pkbalakr%29 [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer From kevin.rushforth at oracle.com Tue Jul 10 23:42:50 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Jul 2018 16:42:50 -0700 Subject: CFV: New OpenJFX Committer: Prem Balakrishnan In-Reply-To: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> References: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> Message-ID: <3be45015-2da0-0314-65df-fd5317c3bb5b@oracle.com> Vote: YES On 7/10/2018 4:41 PM, Kevin Rushforth wrote: > I hereby nominate Prem Balakrishnan [1] to OpenJFX Committer. > > Prem is a member of JavaFX team at Oracle, who has contributed 10 > changesets [2] to OpenJFX. > > Votes are due by July 24, 2018. > > Only current OpenJFX Committers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. Nomination to a > project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#pkbalakr > > [2] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28pkbalakr%29 > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From philip.race at oracle.com Wed Jul 11 00:16:09 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 10 Jul 2018 17:16:09 -0700 Subject: CFV: New OpenJFX Committer: Prem Balakrishnan In-Reply-To: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> References: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> Message-ID: <5B454C49.6070909@oracle.com> Vote: yes. -phil. From arunprasad.rajkumar at oracle.com Wed Jul 11 10:56:52 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 11 Jul 2018 16:26:52 +0530 Subject: CFV: New OpenJFX Committer: Prem Balakrishnan In-Reply-To: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> References: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> Message-ID: Vote: Yes > On 11-Jul-2018, at 5:11 AM, Kevin Rushforth wrote: > > I hereby nominate Prem Balakrishnan [1] to OpenJFX Committer. > > Prem is a member of JavaFX team at Oracle, who has contributed 10 changesets [2] to OpenJFX. > > Votes are due by July 24, 2018. > > Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#pkbalakr > > [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28pkbalakr%29 > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From johan.vos at gluonhq.com Wed Jul 11 11:45:09 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 11 Jul 2018 13:45:09 +0200 Subject: CFV: New OpenJFX Committer: Prem Balakrishnan In-Reply-To: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> References: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> Message-ID: Vote: Yes On Wed, Jul 11, 2018 at 1:52 AM Kevin Rushforth wrote: > I hereby nominate Prem Balakrishnan [1] to OpenJFX Committer. > > Prem is a member of JavaFX team at Oracle, who has contributed 10 > changesets [2] to OpenJFX. > > Votes are due by July 24, 2018. > > Only current OpenJFX Committers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#pkbalakr > > [2] > > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28pkbalakr%29 > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > > From prasanta.sadhukhan at oracle.com Wed Jul 11 15:48:55 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 11 Jul 2018 21:18:55 +0530 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API In-Reply-To: <3b9d0c51-153e-e74a-2667-761bb5c877d9@oracle.com> References: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> <52f046f0-4621-596c-b84f-7602266c30d0@oracle.com> <04091299-44e3-ad9b-2210-f4b420c1dac7@oracle.com> <3b9d0c51-153e-e74a-2667-761bb5c877d9@oracle.com> Message-ID: <81e09726-e23d-df1a-ee42-b32e173eb56d@oracle.com> Hi Kevin, Please find modified webrev fixing the other test failures by modifying the overrideNativeWindowHandle JNI method http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.7/ Regards Prasanta On 7/10/2018 3:58 PM, Prasanta Sadhukhan wrote: > > Hi Kevin, > > Please find modified webrev with some more refactoring to move more > common code to SwingNode > and also this solves SwingNodeMemoryLeakTest failure > http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.6/ > > Regards > Prasanta > On 7/10/2018 7:13 AM, Kevin Rushforth wrote: >> Hi Prasanta, >> >> The public API looks fine now. I sent you an offline note about one >> of the test failures (SwingNodeMemoryLeakTest). >> >> There are still whitespace problems that will cause a failure in >> 'gradle checkrepo' (and 'hg jcheck'). >> >> I'll do a more thorough review in the next day or so. >> >> -- Kevin >> >> >> On 7/9/2018 4:12 AM, Prasanta Sadhukhan wrote: >>> >>> Hi Kevin, >>> >>> Modified webrev to address the "public" leakage >>> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.5/ >>> >>> I am looking into the test failures. >>> >>> Regards >>> Prasanta >>> On 7/7/2018 4:30 AM, Kevin Rushforth wrote: >>>> 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 >>>>>> >>>>> >>>> >>> >> > From murali.billa at oracle.com Thu Jul 12 02:22:16 2018 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 11 Jul 2018 19:22:16 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Prem Balakrishnan In-Reply-To: References: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> Message-ID: Vote: YES > On 11-Jul-2018, at 5:11 AM, Kevin Rushforth wrote: > > I hereby nominate Prem Balakrishnan [1] to OpenJFX Committer. > > Prem is a member of JavaFX team at Oracle, who has contributed 10 changesets [2] to OpenJFX. > > Votes are due by July 24, 2018. > > Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#pkbalakr > > [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28pkbalakr%29 > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From tom.schindl at bestsolution.at Thu Jul 12 07:47:36 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 12 Jul 2018 09:47:36 +0200 Subject: Aw: Chance of Backporting Gtk3 Support to JavaFX 8 In-Reply-To: References: <57e7b661-9171-da25-613a-9de9d7b46f12@bestsolution.at> Message-ID: Hi, There's a now a defined EOL for SWT-Gtk2 announced [1]. The last SWT Release supporting Gtk2 is 2018-09! Starting with 2018-12 SWT there will be no more Gtk2 support! Tom [1]https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg15783.html On 06.06.18 11:12, Tom Schindl wrote: > Hi, > > Yes. FXCanvas from JavaFX8 won't work anymore once SWT-Gtk2 is gone. > > The discussion on this currently happens at [platform-dev] mailing list > - see https://dev.eclipse.org/mhonarc/lists/platform-dev/ - There's no > timeframe mentionned yet by the SWT-Team but sooner or later that will > happen. > > Tom > > On 06.06.18 11:03, Thorsten Fischer wrote: >> Hello Tom, >> ? >> does that mean that FXCanvas won't work with upcoming Eclipse versions >> and JavaFX8? >> ? >> Do you know in which timeframe/release that my occur? Is that issue >> discussed in the eclipse bugtracker somewhere? I couldn't find it by >> searching for "gtk4". >> ? >> Kind regards, >> Thorsten >> ? >> *Gesendet:*?Mittwoch, 06. Juni 2018 um 10:20 Uhr >> *Von:*?"Tom Schindl" >> *An:*?"openjfx-dev at openjdk.java.net Mailing" >> *Betreff:*?Chance of Backporting Gtk3 Support to JavaFX 8 >> Hi, >> >> Eclipse SWT developers are about to remove Gtk2-SWT port once they start >> developing towards support for Gtk4. >> >> This means there's no SWT-FX-Integration layer anymore for JavaFX8 >> because it is linked to Gtk2. >> >> I know JavaFX-8 is not the new and shining thing because everyone wants >> to use modules and Java 11 but there are many applications who can not >> easily to Java 9+. >> >> Is there any chance the Gtk3 changes from JavaFX-9 get backported to >> JavaFX-8? >> >> Tom From pankaj.b.bansal at oracle.com Thu Jul 12 07:51:15 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Thu, 12 Jul 2018 00:51:15 -0700 (PDT) Subject: [11] JDK-8204336 : Platform.exit() throws ISE when a nested event loop is active Message-ID: Hi Kevin, Murali, Please review this fix, Webrev: http://cr.openjdk.java.net/~pbansal/8204336/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8204336 Regards, Pankaj From rajath.kamath at oracle.com Thu Jul 12 08:06:39 2018 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Thu, 12 Jul 2018 01:06:39 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Prem Balakrishnan In-Reply-To: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> References: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> Message-ID: Vote: Yes -----Original Message----- From: Kevin Rushforth Sent: Wednesday, July 11, 2018 5:12 AM To: openjfx-dev at openjdk.java.net; Prem Balakrishnan Subject: CFV: New OpenJFX Committer: Prem Balakrishnan I hereby nominate Prem Balakrishnan [1] to OpenJFX Committer. Prem is a member of JavaFX team at Oracle, who has contributed 10 changesets [2] to OpenJFX. Votes are due by July 24, 2018. Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. Thanks. -- Kevin [1] http://openjdk.java.net/census#pkbalakr [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28pkbalakr%29 [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer From jonathan at jonathangiles.net Thu Jul 12 08:09:29 2018 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Thu, 12 Jul 2018 20:09:29 +1200 Subject: CFV: New OpenJFX Committer: Prem Balakrishnan In-Reply-To: References: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> Message-ID: Vote: yes -- Jonathan (Tapped on a touch device) On Wed, 11 Jul 2018, 10:57 PM Arunprasad Rajkumar, < arunprasad.rajkumar at oracle.com> wrote: > Vote: Yes > > > On 11-Jul-2018, at 5:11 AM, Kevin Rushforth > wrote: > > > > I hereby nominate Prem Balakrishnan [1] to OpenJFX Committer. > > > > Prem is a member of JavaFX team at Oracle, who has contributed 10 > changesets [2] to OpenJFX. > > > > Votes are due by July 24, 2018. > > > > Only current OpenJFX Committers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [5]. Nomination to a project > Committer is described in [6]. > > > > Thanks. > > > > -- Kevin > > > > [1] http://openjdk.java.net/census#pkbalakr > > > > [2] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28pkbalakr%29 > > > > [3] http://openjdk.java.net/census#openjfx > > > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > > > [5] http://openjdk.java.net/projects#project-committer > > > > From wowselim at gmail.com Thu Jul 12 11:02:42 2018 From: wowselim at gmail.com (Selim Dincer) Date: Thu, 12 Jul 2018 13:02:42 +0200 Subject: Determining which GraphicsPipeline is being used Message-ID: Hi, I was wondering if there is a way to find out which graphics pipeline is being used by javafx. Some of our users access our application via virtualized environments or use old GPUs that in some way don't support hardware rendering. The way we do it at the moment: com.sun.prism.GraphicsPipeline.getPipeline() ?Are there any plans to provide public API for this (maybe in form of an MXBean along with FPS stats and other metrics)? ?Selim From kevin.rushforth at oracle.com Thu Jul 12 12:53:44 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 Jul 2018 05:53:44 -0700 Subject: Aw: Chance of Backporting Gtk3 Support to JavaFX 8 In-Reply-To: References: <57e7b661-9171-da25-613a-9de9d7b46f12@bestsolution.at> Message-ID: <4dc5e5ef-af9e-8dc2-6a89-1f334aee88c6@oracle.com> Good to know about the time frame. Yes, we are looking at backporting GTK 3 support to JDK 8. -- Kevin On 7/12/2018 12:47 AM, Tom Schindl wrote: > Hi, > > There's a now a defined EOL for SWT-Gtk2 announced [1]. The last SWT > Release supporting Gtk2 is 2018-09! Starting with 2018-12 SWT there will > be no more Gtk2 support! > > Tom > > [1]https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg15783.html > > On 06.06.18 11:12, Tom Schindl wrote: >> Hi, >> >> Yes. FXCanvas from JavaFX8 won't work anymore once SWT-Gtk2 is gone. >> >> The discussion on this currently happens at [platform-dev] mailing list >> - see https://dev.eclipse.org/mhonarc/lists/platform-dev/ - There's no >> timeframe mentionned yet by the SWT-Team but sooner or later that will >> happen. >> >> Tom >> >> On 06.06.18 11:03, Thorsten Fischer wrote: >>> Hello Tom, >>> >>> does that mean that FXCanvas won't work with upcoming Eclipse versions >>> and JavaFX8? >>> >>> Do you know in which timeframe/release that my occur? Is that issue >>> discussed in the eclipse bugtracker somewhere? I couldn't find it by >>> searching for "gtk4". >>> >>> Kind regards, >>> Thorsten >>> >>> *Gesendet:*?Mittwoch, 06. Juni 2018 um 10:20 Uhr >>> *Von:*?"Tom Schindl" >>> *An:*?"openjfx-dev at openjdk.java.net Mailing" >>> *Betreff:*?Chance of Backporting Gtk3 Support to JavaFX 8 >>> Hi, >>> >>> Eclipse SWT developers are about to remove Gtk2-SWT port once they start >>> developing towards support for Gtk4. >>> >>> This means there's no SWT-FX-Integration layer anymore for JavaFX8 >>> because it is linked to Gtk2. >>> >>> I know JavaFX-8 is not the new and shining thing because everyone wants >>> to use modules and Java 11 but there are many applications who can not >>> easily to Java 9+. >>> >>> Is there any chance the Gtk3 changes from JavaFX-9 get backported to >>> JavaFX-8? >>> >>> Tom From kevin.rushforth at oracle.com Thu Jul 12 13:02:16 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 Jul 2018 06:02:16 -0700 Subject: Determining which GraphicsPipeline is being used In-Reply-To: References: Message-ID: <62622996-6376-1a6b-e83c-96f6450391b5@oracle.com> Checking the conditional feature SCENE_3D should give you what you need. It is true if and only if there is support for 3D features, which is the software pipelines lack. -- Kevin On 7/12/2018 4:02 AM, Selim Dincer wrote: > Hi, > > I was wondering if there is a way to find out which graphics pipeline is > being used by javafx. Some of our users access our application via > virtualized environments or use old GPUs that in some way don't support > hardware rendering. > The way we do it at the moment: > > com.sun.prism.GraphicsPipeline.getPipeline() > > ?Are there any plans to provide public API for this (maybe in form of an > MXBean along with FPS stats and other metrics)? > > > ?Selim From kevin.rushforth at oracle.com Thu Jul 12 23:59:02 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 Jul 2018 16:59:02 -0700 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API In-Reply-To: <81e09726-e23d-df1a-ee42-b32e173eb56d@oracle.com> References: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> <52f046f0-4621-596c-b84f-7602266c30d0@oracle.com> <04091299-44e3-ad9b-2210-f4b420c1dac7@oracle.com> <3b9d0c51-153e-e74a-2667-761bb5c877d9@oracle.com> <81e09726-e23d-df1a-ee42-b32e173eb56d@oracle.com> Message-ID: <81c576c1-7d2c-483b-fa83-f023e36a7999@oracle.com> Hi Prasanta, I confirm that the test failures are gone now. I need to do some final testing (e.g., a clean build using both JDK 11 and JDK 10 on all three platforms). I also want a second look at a couple of the implementation files, but overall it's close I think. Here are my review comments so far: General review comments: * White space problems ? - trailing whitespace and TABS, which must be fixed ? -? InteropFactoryO constructor missing a space: 'Exception{' * Several of the files have unused imports -- also can you please sort the imports? build.gradle: * MINOR: naming suggestion: > 2344???? task checkJDKUnsupportedModule(...) Maybe a more descrptive name for the task would be "copyModuleInfo"? javafx.swing/src/main/module-info/module-info.java: * Ordering of requires directives > 41???? requires static jdk.unsupported.desktop; Can you move this before the 'requires transitive' statements -- it should group with the previous block (the 'requires' statements) InteropFactory: * MINOR: maybe use a lambda for the following? ? 37???????? AccessController.doPrivileged(new PrivilegedAction() { ? 38???????????? public Object run() { ? 39???????????????? verbose = Boolean.valueOf( ? 40 System.getProperty("javafx.embed.swing.verbose")); ? 41???????????????? return null; ? 42???????????? } ? 43???????? }); JFXPanelInterop ? 38???? public abstract long setMask(); Would ?getMask? be a better name? (it?s a getter not a setter) FOLLOW-ON BUGS: * We should file a follow-on bug to remove the runtime qualified exports (e.g., from testrun.args) when running a JDK that HAS_UNSUPPORTED_DESKTOP; this isn't high priority -- Kevin On 7/11/2018 8:48 AM, Prasanta Sadhukhan wrote: > > Hi Kevin, > > Please find modified webrev fixing the other test failures by > modifying the overrideNativeWindowHandle JNI method > http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.7/ > > Regards > Prasanta > On 7/10/2018 3:58 PM, Prasanta Sadhukhan wrote: >> >> Hi Kevin, >> >> Please find modified webrev with some more refactoring to move more >> common code to SwingNode >> and also this solves SwingNodeMemoryLeakTest failure >> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.6/ >> >> Regards >> Prasanta >> On 7/10/2018 7:13 AM, Kevin Rushforth wrote: >>> Hi Prasanta, >>> >>> The public API looks fine now. I sent you an offline note about one >>> of the test failures (SwingNodeMemoryLeakTest). >>> >>> There are still whitespace problems that will cause a failure in >>> 'gradle checkrepo' (and 'hg jcheck'). >>> >>> I'll do a more thorough review in the next day or so. >>> >>> -- Kevin >>> >>> >>> On 7/9/2018 4:12 AM, Prasanta Sadhukhan wrote: >>>> >>>> Hi Kevin, >>>> >>>> Modified webrev to address the "public" leakage >>>> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.5/ >>>> >>>> I am looking into the test failures. >>>> >>>> Regards >>>> Prasanta >>>> On 7/7/2018 4:30 AM, Kevin Rushforth wrote: >>>>> 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> > From prasanta.sadhukhan at oracle.com Fri Jul 13 09:05:09 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 13 Jul 2018 14:35:09 +0530 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API In-Reply-To: <81c576c1-7d2c-483b-fa83-f023e36a7999@oracle.com> References: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> <52f046f0-4621-596c-b84f-7602266c30d0@oracle.com> <04091299-44e3-ad9b-2210-f4b420c1dac7@oracle.com> <3b9d0c51-153e-e74a-2667-761bb5c877d9@oracle.com> <81e09726-e23d-df1a-ee42-b32e173eb56d@oracle.com> <81c576c1-7d2c-483b-fa83-f023e36a7999@oracle.com> Message-ID: Hi Kevin,Ambarish, Please find modified webrev taking care of review comments. http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.8/ I had done "gradle checkrepo" followed by "checkWhiteSpace -F" to get rid of whitespace problem. Regards Prasanta On 7/13/2018 5:29 AM, Kevin Rushforth wrote: > Hi Prasanta, > > I confirm that the test failures are gone now. I need to do some final > testing (e.g., a clean build using both JDK 11 and JDK 10 on all three > platforms). I also want a second look at a couple of the > implementation files, but overall it's close I think. Here are my > review comments so far: > > General review comments: > > * White space problems > ? - trailing whitespace and TABS, which must be fixed > ? -? InteropFactoryO constructor missing a space: 'Exception{' > > * Several of the files have unused imports -- also can you please sort > the imports? > > > build.gradle: > > * MINOR: naming suggestion: > > > 2344???? task checkJDKUnsupportedModule(...) > > Maybe a more descrptive name for the task would be "copyModuleInfo"? > > > javafx.swing/src/main/module-info/module-info.java: > > * Ordering of requires directives > > > 41???? requires static jdk.unsupported.desktop; > > Can you move this before the 'requires transitive' statements -- it > should group with the previous block (the 'requires' statements) > > > InteropFactory: > > * MINOR: maybe use a lambda for the following? > > > ? 37???????? AccessController.doPrivileged(new > PrivilegedAction() { > ? 38???????????? public Object run() { > ? 39???????????????? verbose = Boolean.valueOf( > ? 40 System.getProperty("javafx.embed.swing.verbose")); > ? 41???????????????? return null; > ? 42???????????? } > ? 43???????? }); > > > JFXPanelInterop > > ? 38???? public abstract long setMask(); > > Would ?getMask? be a better name? (it?s a getter not a setter) > > > FOLLOW-ON BUGS: > > * We should file a follow-on bug to remove the runtime qualified > exports (e.g., from testrun.args) when running a JDK that > HAS_UNSUPPORTED_DESKTOP; this isn't high priority > > > -- Kevin > > > On 7/11/2018 8:48 AM, Prasanta Sadhukhan wrote: >> >> Hi Kevin, >> >> Please find modified webrev fixing the other test failures by >> modifying the overrideNativeWindowHandle JNI method >> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.7/ >> >> Regards >> Prasanta >> On 7/10/2018 3:58 PM, Prasanta Sadhukhan wrote: >>> >>> Hi Kevin, >>> >>> Please find modified webrev with some more refactoring to move more >>> common code to SwingNode >>> and also this solves SwingNodeMemoryLeakTest failure >>> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.6/ >>> >>> Regards >>> Prasanta >>> On 7/10/2018 7:13 AM, Kevin Rushforth wrote: >>>> Hi Prasanta, >>>> >>>> The public API looks fine now. I sent you an offline note about one >>>> of the test failures (SwingNodeMemoryLeakTest). >>>> >>>> There are still whitespace problems that will cause a failure in >>>> 'gradle checkrepo' (and 'hg jcheck'). >>>> >>>> I'll do a more thorough review in the next day or so. >>>> >>>> -- Kevin >>>> >>>> >>>> On 7/9/2018 4:12 AM, Prasanta Sadhukhan wrote: >>>>> >>>>> Hi Kevin, >>>>> >>>>> Modified webrev to address the "public" leakage >>>>> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.5/ >>>>> >>>>> I am looking into the test failures. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 7/7/2018 4:30 AM, Kevin Rushforth wrote: >>>>>> 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 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From johan.vos at gluonhq.com Fri Jul 13 10:40:25 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 13 Jul 2018 12:40:25 +0200 Subject: review request for 8205919: artifacts for maven central Message-ID: PR 83 (https://github.com/javafxports/openjdk-jfx/pull/83) is ready to be merged. The JBS issue is at https://bugs.openjdk.java.net/browse/JDK-8205919 webrev: http://cr.openjdk.java.net/~jvos/8205919/webrev.00/rt.patch The GitHub PR is approved by Kevin, if I get a +1 on the webrev I can do that semi-atomically. - Johan From kevin.rushforth at oracle.com Fri Jul 13 12:38:45 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 13 Jul 2018 05:38:45 -0700 Subject: review request for 8205919: artifacts for maven central In-Reply-To: References: Message-ID: <6309219f-4a5b-5991-4c28-3db1f75d7c72@oracle.com> +1 On 7/13/2018 3:40 AM, Johan Vos wrote: > PR 83 (https://github.com/javafxports/openjdk-jfx/pull/83) is ready to be > merged. > > The JBS issue is at https://bugs.openjdk.java.net/browse/JDK-8205919 > webrev: http://cr.openjdk.java.net/~jvos/8205919/webrev.00/rt.patch > > The GitHub PR is approved by Kevin, if I get a +1 on the webrev I can do > that semi-atomically. > > - Johan From steve.hruda at gmail.com Fri Jul 13 14:19:20 2018 From: steve.hruda at gmail.com (Steve Hruda) Date: Fri, 13 Jul 2018 16:19:20 +0200 Subject: JavaFX 11 maven snapshots - empty jars Message-ID: Hi, Johan asked me to move the empty jar discussion to the mailing list. As I mentioned at GitHub, we did some tests with the published SNAPSHOT's and we had to force an exclude of the empty jars at the dependecies. Otherwise e.g. Eclipse shows a warning that the module name is instable because of the "auto-generated" module name in case of the empty jars. Thanks at Joeri for explaining the reason. I understand now the reason for the empty jar. https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 I never tried it and I know that it doesn't fit to the familar handling of platform dependent jars... Have you thought about it to use the platform variable at the artifactId? Something like: javafx-controls-${javafx.platform} Best Regards, Steve From johan.vos at gluonhq.com Fri Jul 13 14:37:07 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 13 Jul 2018 16:37:07 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: Message-ID: Hi Steve, Yes, that has been considered, but I'm more than happy to re-open the discussion. The problem with javafx-controls-${javafx.platform} as the artifactId is that in that case, the gradle developer is in all cases required to add the platform suffix to the dependency, which makes it very hard to manage JavaFX projects via version control, as the dependency file will hard-code contain e.g. javafx-controls-linux, where other developers would use javafx-controls-windows - Johan On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda wrote: > Hi, > Johan asked me to move the empty jar discussion to the mailing list. > > As I mentioned at GitHub, we did some tests with the published SNAPSHOT's > and we had to force an exclude of the empty jars at the dependecies. > Otherwise e.g. Eclipse shows a warning that the module name is instable > because of the "auto-generated" module name in case of the empty jars. > > Thanks at Joeri for explaining the reason. I understand now the reason for > the empty jar. > https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 > > I never tried it and I know that it doesn't fit to the familar handling of > platform dependent jars... > > Have you thought about it to use the platform variable at the artifactId? > Something like: > javafx-controls-${javafx.platform} > > Best Regards, > Steve > From kevin.rushforth at oracle.com Fri Jul 13 14:59:47 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 13 Jul 2018 07:59:47 -0700 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: Message-ID: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Would it help Eclipse if instead of an empty jar, the jar contained just the module-info.class file? Or will that then cause problems because of two .jar files with the same module name? -- Kevin On 7/13/2018 7:37 AM, Johan Vos wrote: > Hi Steve, > > Yes, that has been considered, but I'm more than happy to re-open the > discussion. > > The problem with javafx-controls-${javafx.platform} as the artifactId is > that in that case, the gradle developer is in all cases required to add the > platform suffix to the dependency, which makes it very hard to manage > JavaFX projects via version control, as the dependency file will hard-code > contain e.g. javafx-controls-linux, where other developers would use > javafx-controls-windows > > - Johan > > > On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda wrote: > >> Hi, >> Johan asked me to move the empty jar discussion to the mailing list. >> >> As I mentioned at GitHub, we did some tests with the published SNAPSHOT's >> and we had to force an exclude of the empty jars at the dependecies. >> Otherwise e.g. Eclipse shows a warning that the module name is instable >> because of the "auto-generated" module name in case of the empty jars. >> >> Thanks at Joeri for explaining the reason. I understand now the reason for >> the empty jar. >> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 >> >> I never tried it and I know that it doesn't fit to the familar handling of >> platform dependent jars... >> >> Have you thought about it to use the platform variable at the artifactId? >> Something like: >> javafx-controls-${javafx.platform} >> >> Best Regards, >> Steve >> From johan at lodgon.com Fri Jul 13 15:25:12 2018 From: johan at lodgon.com (Johan Vos) Date: Fri, 13 Jul 2018 17:25:12 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: That's a good question. I think we might open the discussion to IDE's in general. Basically, there are 3 layers involved here: 1. the artifacts, stored in repositories (maven central or jcenter for example). 2. the build tools (maven and gradle): they have their own appoaches for downloading artifacts, solving transitive dependencies, dealing with platform classifiers, setting up classpath/modulepath for compiletime and runtime (optionally via plugins) 3. the IDE's. They typically work with both build tools, but can have their own mechanism as well. The combination leads to a large set of possible configurations. But since this is not really JavaFX specific, I wonder if the jigsaw mailinglist contains discussions about this, or whether that is left to the tool/IDE vendors? - Johan Op vr 13 jul. 2018 om 17:01 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > Would it help Eclipse if instead of an empty jar, the jar contained just > the module-info.class file? Or will that then cause problems because of > two .jar files with the same module name? > > -- Kevin > > > On 7/13/2018 7:37 AM, Johan Vos wrote: > > Hi Steve, > > > > Yes, that has been considered, but I'm more than happy to re-open the > > discussion. > > > > The problem with javafx-controls-${javafx.platform} as the artifactId is > > that in that case, the gradle developer is in all cases required to add > the > > platform suffix to the dependency, which makes it very hard to manage > > JavaFX projects via version control, as the dependency file will > hard-code > > contain e.g. javafx-controls-linux, where other developers would use > > javafx-controls-windows > > > > - Johan > > > > > > On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda > wrote: > > > >> Hi, > >> Johan asked me to move the empty jar discussion to the mailing list. > >> > >> As I mentioned at GitHub, we did some tests with the published > SNAPSHOT's > >> and we had to force an exclude of the empty jars at the dependecies. > >> Otherwise e.g. Eclipse shows a warning that the module name is instable > >> because of the "auto-generated" module name in case of the empty jars. > >> > >> Thanks at Joeri for explaining the reason. I understand now the reason > for > >> the empty jar. > >> > https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 > >> > >> I never tried it and I know that it doesn't fit to the familar handling > of > >> platform dependent jars... > >> > >> Have you thought about it to use the platform variable at the > artifactId? > >> Something like: > >> javafx-controls-${javafx.platform} > >> > >> Best Regards, > >> Steve > >> > > From steve.hruda at gmail.com Fri Jul 13 15:25:32 2018 From: steve.hruda at gmail.com (Steve Hruda) Date: Fri, 13 Jul 2018 17:25:32 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: Johan, hmm but is that not quite the same in case of the classifier? Because I also have to define a property or static value in case of the classifier. Kevin, The same name could b e a problem. "Module names, like package names, must not conflict. The recommended way to name a module is to use the reverse-domain-name pattern that has long been recommended for naming packages. " http://openjdk.java.net/projects/jigsaw/spec/sotms/#module-declarations But something like a "javafx.controls.dummy" could help. Is there a plan to split the really platform dependent stuff (natives) from the platform independent Code? Which would causein the end that the javafx.controls.jar would not be empty? Maybe in that case it makes sense that the empty jar uses the module name javafx.controls and the platform dependent uses e.g. javafx.controls.windows Regards, Steve Am Fr., 13. Juli 2018 um 17:00 Uhr schrieb Kevin Rushforth < kevin.rushforth at oracle.com>: > Would it help Eclipse if instead of an empty jar, the jar contained just > the module-info.class file? Or will that then cause problems because of > two .jar files with the same module name? > > -- Kevin > > > On 7/13/2018 7:37 AM, Johan Vos wrote: > > Hi Steve, > > > > Yes, that has been considered, but I'm more than happy to re-open the > > discussion. > > > > The problem with javafx-controls-${javafx.platform} as the artifactId is > > that in that case, the gradle developer is in all cases required to add > the > > platform suffix to the dependency, which makes it very hard to manage > > JavaFX projects via version control, as the dependency file will > hard-code > > contain e.g. javafx-controls-linux, where other developers would use > > javafx-controls-windows > > > > - Johan > > > > > > On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda > wrote: > > > >> Hi, > >> Johan asked me to move the empty jar discussion to the mailing list. > >> > >> As I mentioned at GitHub, we did some tests with the published > SNAPSHOT's > >> and we had to force an exclude of the empty jars at the dependecies. > >> Otherwise e.g. Eclipse shows a warning that the module name is instable > >> because of the "auto-generated" module name in case of the empty jars. > >> > >> Thanks at Joeri for explaining the reason. I understand now the reason > for > >> the empty jar. > >> > https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 > >> > >> I never tried it and I know that it doesn't fit to the familar handling > of > >> platform dependent jars... > >> > >> Have you thought about it to use the platform variable at the > artifactId? > >> Something like: > >> javafx-controls-${javafx.platform} > >> > >> Best Regards, > >> Steve > >> > > -- Mit freundlichen Gr??en Steve Hruda From johan at lodgon.com Fri Jul 13 15:33:23 2018 From: johan at lodgon.com (Johan Vos) Date: Fri, 13 Jul 2018 17:33:23 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: Hi Steve, Op vr 13 jul. 2018 om 17:27 schreef Steve Hruda : > Johan, > hmm but is that not quite the same in case of the classifier? Because I > also have to define a property or static value in case of the classifier. > > Not if you use maven, as the javafx.pom will check for a special variable $ os.name and based on that, it will set a classifier and only the jar for your platform will be considered. Hence, no need to supply a classifier. But for gradle, you have to add a classifier indeed. From kevin.rushforth at oracle.com Fri Jul 13 15:39:56 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 13 Jul 2018 08:39:56 -0700 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: > Is there a plan to split the really platform dependent stuff (natives) from the platform independent Code? Not any time soon. And that would cause it's own set of problems. In particular I would not be in favor of a solution that leaked new "module names" for what is (and should remain) an implementation detail. -- Kevin On 7/13/2018 8:25 AM, Steve Hruda wrote: > Johan, > hmm but is that not quite the same in case of the classifier? Because > I also have to define a property or static value in case of the > classifier. > > Kevin, > The same name could b e a problem. > "Module names, like package names, must not conflict. The recommended > way to name a module is to use the reverse-domain-name pattern that > has long been recommended for naming packages.?" > > http://openjdk.java.net/projects/jigsaw/spec/sotms/#module-declarations > > But something like a "javafx.controls.dummy" could help. > > Is there a plan to split the really platform dependent stuff (natives) > from the platform independent Code? > > Which would causein the end that the javafx.controls.jar would not be > empty? > > Maybe in that case it makes sense that the empty jar uses the module > name javafx.controls and the platform dependent uses e.g. > javafx.controls.windows > > Regards, > Steve > > > Am Fr., 13. Juli 2018 um 17:00?Uhr schrieb Kevin Rushforth > >: > > Would it help Eclipse if instead of an empty jar, the jar > contained just > the module-info.class file? Or will that then cause problems > because of > two .jar files with the same module name? > > -- Kevin > > > On 7/13/2018 7:37 AM, Johan Vos wrote: > > Hi Steve, > > > > Yes, that has been considered, but I'm more than happy to > re-open the > > discussion. > > > > The problem with javafx-controls-${javafx.platform} as the > artifactId is > > that in that case, the gradle developer is in all cases required > to add the > > platform suffix to the dependency, which makes it very hard to > manage > > JavaFX projects via version control, as the dependency file will > hard-code > > contain e.g. javafx-controls-linux, where other developers would use > > javafx-controls-windows > > > > - Johan > > > > > > On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda > > wrote: > > > >> Hi, > >> Johan asked me to move the empty jar discussion to the mailing > list. > >> > >> As I mentioned at GitHub, we did some tests with the published > SNAPSHOT's > >> and we had to force an exclude of the empty jars at the > dependecies. > >> Otherwise e.g. Eclipse shows a warning that the module name is > instable > >> because of the "auto-generated" module name in case of the > empty jars. > >> > >> Thanks at Joeri for explaining the reason. I understand now the > reason for > >> the empty jar. > >> > https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 > >> > >> I never tried it and I know that it doesn't fit to the familar > handling of > >> platform dependent jars... > >> > >> Have you thought about it to use the platform variable at the > artifactId? > >> Something like: > >> javafx-controls-${javafx.platform} > >> > >> Best Regards, > >> Steve > >> > > > > -- > Mit freundlichen Gr??en > Steve Hruda From kevin.rushforth at oracle.com Fri Jul 13 15:46:44 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 13 Jul 2018 08:46:44 -0700 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API In-Reply-To: References: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> <52f046f0-4621-596c-b84f-7602266c30d0@oracle.com> <04091299-44e3-ad9b-2210-f4b420c1dac7@oracle.com> <3b9d0c51-153e-e74a-2667-761bb5c877d9@oracle.com> <81e09726-e23d-df1a-ee42-b32e173eb56d@oracle.com> <81c576c1-7d2c-483b-fa83-f023e36a7999@oracle.com> Message-ID: <6bc732a5-15e6-c08a-9b9a-29cac85580c1@oracle.com> Hi Prasanta, > I had done "gradle checkrepo" followed by "checkWhiteSpace -F" to get rid of whitespace problem. It looks like you either didn't refresh your patch, or you subsequently introduced additional white space problems. Here is the output of applying your .8 patch and running 'gradle checkrepo' : > Task :checkrepo FAILED modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/FXDnD.java :tabs:trailingWhitespace: modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/FXDnDInterop.java :tabs:trailingWhitespace: modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/InteropFactory.java :tabs: modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/JFXPanelInterop.java :trailingWhitespace: modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/SwingNodeInterop.java :tabs:trailingWhitespace: Found 5 whitespace or executable issues To correct, use ?? bash tools/scripts/checkWhiteSpace -F -x I'll continue testing anyway, assuming that the only changes at this point will be white space changes or similar, which won't invalidate testing. -- Kevin On 7/13/2018 2:05 AM, Prasanta Sadhukhan wrote: > > Hi Kevin,Ambarish, > > Please find modified webrev taking care of review comments. > http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.8/ > I had done "gradle checkrepo" followed by "checkWhiteSpace -F" to get > rid of whitespace problem. > > Regards > Prasanta > On 7/13/2018 5:29 AM, Kevin Rushforth wrote: >> Hi Prasanta, >> >> I confirm that the test failures are gone now. I need to do some >> final testing (e.g., a clean build using both JDK 11 and JDK 10 on >> all three platforms). I also want a second look at a couple of the >> implementation files, but overall it's close I think. Here are my >> review comments so far: >> >> General review comments: >> >> * White space problems >> ? - trailing whitespace and TABS, which must be fixed >> ? -? InteropFactoryO constructor missing a space: 'Exception{' >> >> * Several of the files have unused imports -- also can you please >> sort the imports? >> >> >> build.gradle: >> >> * MINOR: naming suggestion: >> >> > 2344???? task checkJDKUnsupportedModule(...) >> >> Maybe a more descrptive name for the task would be "copyModuleInfo"? >> >> >> javafx.swing/src/main/module-info/module-info.java: >> >> * Ordering of requires directives >> >> > 41???? requires static jdk.unsupported.desktop; >> >> Can you move this before the 'requires transitive' statements -- it >> should group with the previous block (the 'requires' statements) >> >> >> InteropFactory: >> >> * MINOR: maybe use a lambda for the following? >> >> >> ? 37???????? AccessController.doPrivileged(new >> PrivilegedAction() { >> ? 38???????????? public Object run() { >> ? 39???????????????? verbose = Boolean.valueOf( >> ? 40 System.getProperty("javafx.embed.swing.verbose")); >> ? 41???????????????? return null; >> ? 42???????????? } >> ? 43???????? }); >> >> >> JFXPanelInterop >> >> ? 38???? public abstract long setMask(); >> >> Would ?getMask? be a better name? (it?s a getter not a setter) >> >> >> FOLLOW-ON BUGS: >> >> * We should file a follow-on bug to remove the runtime qualified >> exports (e.g., from testrun.args) when running a JDK that >> HAS_UNSUPPORTED_DESKTOP; this isn't high priority >> >> >> -- Kevin >> >> >> On 7/11/2018 8:48 AM, Prasanta Sadhukhan wrote: >>> >>> Hi Kevin, >>> >>> Please find modified webrev fixing the other test failures by >>> modifying the overrideNativeWindowHandle JNI method >>> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.7/ >>> >>> Regards >>> Prasanta >>> On 7/10/2018 3:58 PM, Prasanta Sadhukhan wrote: >>>> >>>> Hi Kevin, >>>> >>>> Please find modified webrev with some more refactoring to move more >>>> common code to SwingNode >>>> and also this solves SwingNodeMemoryLeakTest failure >>>> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.6/ >>>> >>>> Regards >>>> Prasanta >>>> On 7/10/2018 7:13 AM, Kevin Rushforth wrote: >>>>> Hi Prasanta, >>>>> >>>>> The public API looks fine now. I sent you an offline note about >>>>> one of the test failures (SwingNodeMemoryLeakTest). >>>>> >>>>> There are still whitespace problems that will cause a failure in >>>>> 'gradle checkrepo' (and 'hg jcheck'). >>>>> >>>>> I'll do a more thorough review in the next day or so. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 7/9/2018 4:12 AM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Hi Kevin, >>>>>> >>>>>> Modified webrev to address the "public" leakage >>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.5/ >>>>>> >>>>>> I am looking into the test failures. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 7/7/2018 4:30 AM, Kevin Rushforth wrote: >>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From steve.hruda at gmail.com Fri Jul 13 16:00:03 2018 From: steve.hruda at gmail.com (Steve Hruda) Date: Fri, 13 Jul 2018 18:00:03 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: Ok and the set of the property doesn't work in case of the artifactId? https://oss.sonatype.org/content/repositories/snapshots/org/openjfx/javafx/11.0.0-SNAPSHOT/javafx-11.0.0-20180629.175048-1.pom Am Fr., 13. Juli 2018 um 17:33 Uhr schrieb Johan Vos : > Hi Steve, > > Op vr 13 jul. 2018 om 17:27 schreef Steve Hruda : > >> Johan, >> hmm but is that not quite the same in case of the classifier? Because I >> also have to define a property or static value in case of the classifier. >> >> Not if you use maven, as the javafx.pom will check for a special variable > $os.name and based on that, it will set a classifier and only the jar for > your platform will be considered. Hence, no need to supply a classifier. > But for gradle, you have to add a classifier indeed. > -- Mit freundlichen Gr??en Steve Hruda From steve.hruda at gmail.com Fri Jul 13 16:36:47 2018 From: steve.hruda at gmail.com (Steve Hruda) Date: Fri, 13 Jul 2018 18:36:47 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: Okay, I understand. If the empty jar will be the final solution, then I think I will find a workaround at our Gradle's build to avoid loading of such empty jars. Am Fr., 13. Juli 2018 um 17:39 Uhr schrieb Kevin Rushforth < kevin.rushforth at oracle.com>: > > > Is there a plan to split the really platform dependent stuff (natives) > from the platform independent Code? > > Not any time soon. And that would cause it's own set of problems. > > In particular I would not be in favor of a solution that leaked new > "module names" for what is (and should remain) an implementation detail. > > -- Kevin > > > On 7/13/2018 8:25 AM, Steve Hruda wrote: > > Johan, > hmm but is that not quite the same in case of the classifier? Because I > also have to define a property or static value in case of the classifier. > > Kevin, > The same name could b e a problem. > "Module names, like package names, must not conflict. The recommended way > to name a module is to use the reverse-domain-name pattern that has long > been recommended for naming packages. " > > http://openjdk.java.net/projects/jigsaw/spec/sotms/#module-declarations > > But something like a "javafx.controls.dummy" could help. > > Is there a plan to split the really platform dependent stuff (natives) > from the platform independent Code? > > Which would causein the end that the javafx.controls.jar would not be > empty? > > Maybe in that case it makes sense that the empty jar uses the module name > javafx.controls and the platform dependent uses e.g. javafx.controls.windows > > Regards, > Steve > > > Am Fr., 13. Juli 2018 um 17:00 Uhr schrieb Kevin Rushforth < > kevin.rushforth at oracle.com>: > >> Would it help Eclipse if instead of an empty jar, the jar contained just >> the module-info.class file? Or will that then cause problems because of >> two .jar files with the same module name? >> >> -- Kevin >> >> >> On 7/13/2018 7:37 AM, Johan Vos wrote: >> > Hi Steve, >> > >> > Yes, that has been considered, but I'm more than happy to re-open the >> > discussion. >> > >> > The problem with javafx-controls-${javafx.platform} as the artifactId is >> > that in that case, the gradle developer is in all cases required to add >> the >> > platform suffix to the dependency, which makes it very hard to manage >> > JavaFX projects via version control, as the dependency file will >> hard-code >> > contain e.g. javafx-controls-linux, where other developers would use >> > javafx-controls-windows >> > >> > - Johan >> > >> > >> > On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda >> wrote: >> > >> >> Hi, >> >> Johan asked me to move the empty jar discussion to the mailing list. >> >> >> >> As I mentioned at GitHub, we did some tests with the published >> SNAPSHOT's >> >> and we had to force an exclude of the empty jars at the dependecies. >> >> Otherwise e.g. Eclipse shows a warning that the module name is instable >> >> because of the "auto-generated" module name in case of the empty jars. >> >> >> >> Thanks at Joeri for explaining the reason. I understand now the reason >> for >> >> the empty jar. >> >> >> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 >> >> >> >> I never tried it and I know that it doesn't fit to the familar >> handling of >> >> platform dependent jars... >> >> >> >> Have you thought about it to use the platform variable at the >> artifactId? >> >> Something like: >> >> javafx-controls-${javafx.platform} >> >> >> >> Best Regards, >> >> Steve >> >> >> >> > > -- > Mit freundlichen Gr??en > Steve Hruda > > > -- Mit freundlichen Gr??en Steve Hruda From johan.vos at gluonhq.com Sat Jul 14 08:32:25 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 14 Jul 2018 10:32:25 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: Hi Steve, I think we really want a solution that allows for as many use cases as possible. If the current proposal is not working with Eclipse, we need to fix it. I wonder if we want to create a javafx gradle plugin? We already have a jfxmobile plugin for gradle to deal with JavaFX on mobile, but in general, a JavaFX gradle plugin that facilitates development of JavaFX on any platform might be good. I'm not sure that is a solution for all cases, as you don't want to force people to work with gradle. Hence, a maven plugin might be worth considering as well. It is not a JavaFX specific issue though. We will see an increasing number of related issues, where artifacts contain (platform-dependent) native code. Previously, the Java SDK that you installed contained all platform-specific libraries you needed. Moving these to separate projects also moves the platform-specific libraries to the repositories, and require the build tools to take care of this. IMHO, this is something that needs to be discussed with a wider audience. I want to discuss this at the OpenJDK Workshop ( http://openjdk.java.net/workshop). - Johan On Fri, Jul 13, 2018 at 9:37 PM Steve Hruda wrote: > Okay, I understand. > > If the empty jar will be the final solution, then I think I will find a > workaround at our Gradle's build to avoid loading of such empty jars. > > > Am Fr., 13. Juli 2018 um 17:39 Uhr schrieb Kevin Rushforth < > kevin.rushforth at oracle.com>: > > > > > > Is there a plan to split the really platform dependent stuff (natives) > > from the platform independent Code? > > > > Not any time soon. And that would cause it's own set of problems. > > > > In particular I would not be in favor of a solution that leaked new > > "module names" for what is (and should remain) an implementation detail. > > > > -- Kevin > > > > > > On 7/13/2018 8:25 AM, Steve Hruda wrote: > > > > Johan, > > hmm but is that not quite the same in case of the classifier? Because I > > also have to define a property or static value in case of the classifier. > > > > Kevin, > > The same name could b e a problem. > > "Module names, like package names, must not conflict. The recommended way > > to name a module is to use the reverse-domain-name pattern that has long > > been recommended for naming packages. " > > > > http://openjdk.java.net/projects/jigsaw/spec/sotms/#module-declarations > > > > But something like a "javafx.controls.dummy" could help. > > > > Is there a plan to split the really platform dependent stuff (natives) > > from the platform independent Code? > > > > Which would causein the end that the javafx.controls.jar would not be > > empty? > > > > Maybe in that case it makes sense that the empty jar uses the module name > > javafx.controls and the platform dependent uses e.g. > javafx.controls.windows > > > > Regards, > > Steve > > > > > > Am Fr., 13. Juli 2018 um 17:00 Uhr schrieb Kevin Rushforth < > > kevin.rushforth at oracle.com>: > > > >> Would it help Eclipse if instead of an empty jar, the jar contained just > >> the module-info.class file? Or will that then cause problems because of > >> two .jar files with the same module name? > >> > >> -- Kevin > >> > >> > >> On 7/13/2018 7:37 AM, Johan Vos wrote: > >> > Hi Steve, > >> > > >> > Yes, that has been considered, but I'm more than happy to re-open the > >> > discussion. > >> > > >> > The problem with javafx-controls-${javafx.platform} as the artifactId > is > >> > that in that case, the gradle developer is in all cases required to > add > >> the > >> > platform suffix to the dependency, which makes it very hard to manage > >> > JavaFX projects via version control, as the dependency file will > >> hard-code > >> > contain e.g. javafx-controls-linux, where other developers would use > >> > javafx-controls-windows > >> > > >> > - Johan > >> > > >> > > >> > On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda > >> wrote: > >> > > >> >> Hi, > >> >> Johan asked me to move the empty jar discussion to the mailing list. > >> >> > >> >> As I mentioned at GitHub, we did some tests with the published > >> SNAPSHOT's > >> >> and we had to force an exclude of the empty jars at the dependecies. > >> >> Otherwise e.g. Eclipse shows a warning that the module name is > instable > >> >> because of the "auto-generated" module name in case of the empty > jars. > >> >> > >> >> Thanks at Joeri for explaining the reason. I understand now the > reason > >> for > >> >> the empty jar. > >> >> > >> > https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 > >> >> > >> >> I never tried it and I know that it doesn't fit to the familar > >> handling of > >> >> platform dependent jars... > >> >> > >> >> Have you thought about it to use the platform variable at the > >> artifactId? > >> >> Something like: > >> >> javafx-controls-${javafx.platform} > >> >> > >> >> Best Regards, > >> >> Steve > >> >> > >> > >> > > > > -- > > Mit freundlichen Gr??en > > Steve Hruda > > > > > > > > -- > Mit freundlichen Gr??en > Steve Hruda > From steve.hruda at gmail.com Sat Jul 14 10:16:02 2018 From: steve.hruda at gmail.com (Steve Hruda) Date: Sat, 14 Jul 2018 12:16:02 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: Hi Johan, a discussion with a wider audience ist a very good Idea. Maybe some core developers of Gradle join the discussion and assist OpenJFX. Pleased dont missunderstand me, it's not my intention to push a solution which works only fit one case. >From my current understandig, it's not a dedicated Eclipse issue. It's more an issue which affects somebody if he adds both jars (empty & platform dependent) to the module path. So in the end, It's ok for me that my mentioned workaround will not considered if doesn't work in both cases. To ensure that we all talk about the same, I describe it a little bit more in detail: 1. OpenJFX's gradle build - Add the platform (windows,linux, mac) to the artifactId e.g javafx-controls-windows and don't use the classifier - publish the platform dependent jar's to the repository without using any variables at the POMs. Which means that the current manipulation of the POM would no longer necessary. 2. javafx.pom still defines properties which makes the maven handling more comfortable 3. in case of your hello3d example: https://github.com/johanvos/javafx11samples/blob/master/topics/javafx3d/hello3d - pom.xml: Remove the property at the classifier and define javafx-controls-${javafx.platform} - build.gradle: define "org.openjfx:javafx-controls-${javafx.platform} :11.0.0-SNAPSHOT" instead So in the end the maven user has still the possibility to define javafx.pom as a parent which sets the necessary javafx.platform. In addition and if it works, POM-only artifacts for maven builds can be defined (javafx-controls, javafx-graphics). These POM's can still use the Javafx.pom as a parent and Joeri's case 2 should work for maven. https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 Regarding the current solution: Does the hello3d pom.xml work if 1. the parent javafx.pom will be removed so that the reference to the javafx.pom exists only at the 2. the dependency will be changed to javafx.controls without the classifier? Best Regards, Steve Johan Vos schrieb am Sa., 14. Juli 2018, 10:32: > Hi Steve, > > I think we really want a solution that allows for as many use cases as > possible. If the current proposal is not working with Eclipse, we need to > fix it. I wonder if we want to create a javafx gradle plugin? We already > have a jfxmobile plugin for gradle to deal with JavaFX on mobile, but in > general, a JavaFX gradle plugin that facilitates development of JavaFX on > any platform might be good. > > I'm not sure that is a solution for all cases, as you don't want to force > people to work with gradle. Hence, a maven plugin might be worth > considering as well. > > It is not a JavaFX specific issue though. We will see an increasing number > of related issues, where artifacts contain (platform-dependent) native > code. Previously, the Java SDK that you installed contained all > platform-specific libraries you needed. Moving these to separate projects > also moves the platform-specific libraries to the repositories, and require > the build tools to take care of this. > IMHO, this is something that needs to be discussed with a wider audience. > I want to discuss this at the OpenJDK Workshop ( > http://openjdk.java.net/workshop). > > - Johan > > On Fri, Jul 13, 2018 at 9:37 PM Steve Hruda wrote: > >> Okay, I understand. >> >> If the empty jar will be the final solution, then I think I will find a >> workaround at our Gradle's build to avoid loading of such empty jars. >> >> >> Am Fr., 13. Juli 2018 um 17:39 Uhr schrieb Kevin Rushforth < >> kevin.rushforth at oracle.com>: >> >> > >> > > Is there a plan to split the really platform dependent stuff (natives) >> > from the platform independent Code? >> > >> > Not any time soon. And that would cause it's own set of problems. >> > >> > In particular I would not be in favor of a solution that leaked new >> > "module names" for what is (and should remain) an implementation detail. >> > >> > -- Kevin >> > >> > >> > On 7/13/2018 8:25 AM, Steve Hruda wrote: >> > >> > Johan, >> > hmm but is that not quite the same in case of the classifier? Because I >> > also have to define a property or static value in case of the >> classifier. >> > >> > Kevin, >> > The same name could b e a problem. >> > "Module names, like package names, must not conflict. The recommended >> way >> > to name a module is to use the reverse-domain-name pattern that has long >> > been recommended for naming packages. " >> > >> > http://openjdk.java.net/projects/jigsaw/spec/sotms/#module-declarations >> > >> > But something like a "javafx.controls.dummy" could help. >> > >> > Is there a plan to split the really platform dependent stuff (natives) >> > from the platform independent Code? >> > >> > Which would causein the end that the javafx.controls.jar would not be >> > empty? >> > >> > Maybe in that case it makes sense that the empty jar uses the module >> name >> > javafx.controls and the platform dependent uses e.g. >> javafx.controls.windows >> > >> > Regards, >> > Steve >> > >> > >> > Am Fr., 13. Juli 2018 um 17:00 Uhr schrieb Kevin Rushforth < >> > kevin.rushforth at oracle.com>: >> > >> >> Would it help Eclipse if instead of an empty jar, the jar contained >> just >> >> the module-info.class file? Or will that then cause problems because of >> >> two .jar files with the same module name? >> >> >> >> -- Kevin >> >> >> >> >> >> On 7/13/2018 7:37 AM, Johan Vos wrote: >> >> > Hi Steve, >> >> > >> >> > Yes, that has been considered, but I'm more than happy to re-open the >> >> > discussion. >> >> > >> >> > The problem with javafx-controls-${javafx.platform} as the >> artifactId is >> >> > that in that case, the gradle developer is in all cases required to >> add >> >> the >> >> > platform suffix to the dependency, which makes it very hard to manage >> >> > JavaFX projects via version control, as the dependency file will >> >> hard-code >> >> > contain e.g. javafx-controls-linux, where other developers would use >> >> > javafx-controls-windows >> >> > >> >> > - Johan >> >> > >> >> > >> >> > On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda >> >> wrote: >> >> > >> >> >> Hi, >> >> >> Johan asked me to move the empty jar discussion to the mailing list. >> >> >> >> >> >> As I mentioned at GitHub, we did some tests with the published >> >> SNAPSHOT's >> >> >> and we had to force an exclude of the empty jars at the dependecies. >> >> >> Otherwise e.g. Eclipse shows a warning that the module name is >> instable >> >> >> because of the "auto-generated" module name in case of the empty >> jars. >> >> >> >> >> >> Thanks at Joeri for explaining the reason. I understand now the >> reason >> >> for >> >> >> the empty jar. >> >> >> >> >> >> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 >> >> >> >> >> >> I never tried it and I know that it doesn't fit to the familar >> >> handling of >> >> >> platform dependent jars... >> >> >> >> >> >> Have you thought about it to use the platform variable at the >> >> artifactId? >> >> >> Something like: >> >> >> javafx-controls-${javafx.platform} >> >> >> >> >> >> Best Regards, >> >> >> Steve >> >> >> >> >> >> >> >> > >> > -- >> > Mit freundlichen Gr??en >> > Steve Hruda >> > >> > >> > >> >> -- >> Mit freundlichen Gr??en >> Steve Hruda >> > From prasanta.sadhukhan at oracle.com Mon Jul 16 05:01:13 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 16 Jul 2018 10:31:13 +0530 Subject: [11] RFR: Enhancement: JDK-8195811:Support FX Swing interop using public API In-Reply-To: <6bc732a5-15e6-c08a-9b9a-29cac85580c1@oracle.com> References: <5f0e5430-6417-8256-370d-c1e3c65d32fe@oracle.com> <03236b8a-cd5d-df97-48d1-9b64027b6ac1@oracle.com> <52f046f0-4621-596c-b84f-7602266c30d0@oracle.com> <04091299-44e3-ad9b-2210-f4b420c1dac7@oracle.com> <3b9d0c51-153e-e74a-2667-761bb5c877d9@oracle.com> <81e09726-e23d-df1a-ee42-b32e173eb56d@oracle.com> <81c576c1-7d2c-483b-fa83-f023e36a7999@oracle.com> <6bc732a5-15e6-c08a-9b9a-29cac85580c1@oracle.com> Message-ID: <2b6eb6db-37ca-9375-0248-84ff28aa9e91@oracle.com> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.9/ with sorting and whitespace fixed, hopefully. Regards Prasanta On 7/13/2018 9:16 PM, Kevin Rushforth wrote: > Hi Prasanta, > > > I had done "gradle checkrepo" followed by "checkWhiteSpace -F" to > get rid of whitespace problem. > > It looks like you either didn't refresh your patch, or you > subsequently introduced additional white space problems. Here is the > output of applying your .8 patch and running 'gradle checkrepo' : > > > Task :checkrepo FAILED > modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/FXDnD.java > :tabs:trailingWhitespace: > modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/FXDnDInterop.java > :tabs:trailingWhitespace: > modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/InteropFactory.java > :tabs: > modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/JFXPanelInterop.java > :trailingWhitespace: > modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/SwingNodeInterop.java > :tabs:trailingWhitespace: > > Found 5 whitespace or executable issues > > To correct, use > ?? bash tools/scripts/checkWhiteSpace -F -x > > I'll continue testing anyway, assuming that the only changes at this > point will be white space changes or similar, which won't invalidate > testing. > > -- Kevin > > > On 7/13/2018 2:05 AM, Prasanta Sadhukhan wrote: >> >> Hi Kevin,Ambarish, >> >> Please find modified webrev taking care of review comments. >> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.8/ >> I had done "gradle checkrepo" followed by "checkWhiteSpace -F" to get >> rid of whitespace problem. >> >> Regards >> Prasanta >> On 7/13/2018 5:29 AM, Kevin Rushforth wrote: >>> Hi Prasanta, >>> >>> I confirm that the test failures are gone now. I need to do some >>> final testing (e.g., a clean build using both JDK 11 and JDK 10 on >>> all three platforms). I also want a second look at a couple of the >>> implementation files, but overall it's close I think. Here are my >>> review comments so far: >>> >>> General review comments: >>> >>> * White space problems >>> ? - trailing whitespace and TABS, which must be fixed >>> ? -? InteropFactoryO constructor missing a space: 'Exception{' >>> >>> * Several of the files have unused imports -- also can you please >>> sort the imports? >>> >>> >>> build.gradle: >>> >>> * MINOR: naming suggestion: >>> >>> > 2344???? task checkJDKUnsupportedModule(...) >>> >>> Maybe a more descrptive name for the task would be "copyModuleInfo"? >>> >>> >>> javafx.swing/src/main/module-info/module-info.java: >>> >>> * Ordering of requires directives >>> >>> > 41???? requires static jdk.unsupported.desktop; >>> >>> Can you move this before the 'requires transitive' statements -- it >>> should group with the previous block (the 'requires' statements) >>> >>> >>> InteropFactory: >>> >>> * MINOR: maybe use a lambda for the following? >>> >>> >>> ? 37???????? AccessController.doPrivileged(new >>> PrivilegedAction() { >>> ? 38???????????? public Object run() { >>> ? 39???????????????? verbose = Boolean.valueOf( >>> ? 40 System.getProperty("javafx.embed.swing.verbose")); >>> ? 41???????????????? return null; >>> ? 42???????????? } >>> ? 43???????? }); >>> >>> >>> JFXPanelInterop >>> >>> ? 38???? public abstract long setMask(); >>> >>> Would ?getMask? be a better name? (it?s a getter not a setter) >>> >>> >>> FOLLOW-ON BUGS: >>> >>> * We should file a follow-on bug to remove the runtime qualified >>> exports (e.g., from testrun.args) when running a JDK that >>> HAS_UNSUPPORTED_DESKTOP; this isn't high priority >>> >>> >>> -- Kevin >>> >>> >>> On 7/11/2018 8:48 AM, Prasanta Sadhukhan wrote: >>>> >>>> Hi Kevin, >>>> >>>> Please find modified webrev fixing the other test failures by >>>> modifying the overrideNativeWindowHandle JNI method >>>> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.7/ >>>> >>>> Regards >>>> Prasanta >>>> On 7/10/2018 3:58 PM, Prasanta Sadhukhan wrote: >>>>> >>>>> Hi Kevin, >>>>> >>>>> Please find modified webrev with some more refactoring to move >>>>> more common code to SwingNode >>>>> and also this solves SwingNodeMemoryLeakTest failure >>>>> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.6/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 7/10/2018 7:13 AM, Kevin Rushforth wrote: >>>>>> Hi Prasanta, >>>>>> >>>>>> The public API looks fine now. I sent you an offline note about >>>>>> one of the test failures (SwingNodeMemoryLeakTest). >>>>>> >>>>>> There are still whitespace problems that will cause a failure in >>>>>> 'gradle checkrepo' (and 'hg jcheck'). >>>>>> >>>>>> I'll do a more thorough review in the next day or so. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 7/9/2018 4:12 AM, Prasanta Sadhukhan wrote: >>>>>>> >>>>>>> Hi Kevin, >>>>>>> >>>>>>> Modified webrev to address the "public" leakage >>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.5/ >>>>>>> >>>>>>> I am looking into the test failures. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 7/7/2018 4:30 AM, Kevin Rushforth wrote: >>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From arunprasad.rajkumar at oracle.com Tue Jul 17 06:55:20 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 17 Jul 2018 12:25:20 +0530 Subject: [openjfx11] Review request for 8206995: Remove unused WebKit files Message-ID: Hi, Please review the fix for following bug, Bug: https://bugs.openjdk.java.net/browse/JDK-8206995 Patch: https://bugs.openjdk.java.net/secure/attachment/77667/rt.patch Thanks, Arun From arunprasad.rajkumar at oracle.com Tue Jul 17 16:15:12 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 17 Jul 2018 21:45:12 +0530 Subject: [openjfx11] [RFC] 8147476: Rendering issues with MathML token elements Message-ID: <8A4C5509-2927-4027-8873-89D2D79EA0D9@oracle.com> Hi, The following bug has been already reviewed and merged to OpenJFX GitHub mirror repo[1][2]. https://bugs.openjdk.java.net/browse/JDK-8147476 Soon it will be pushed to jfx-dev[3] and 8u-dev[4] repos as well. Please let me know if you have any concerns. [1] https://github.com/javafxports/openjdk-jfx [2] https://github.com/javafxports/openjdk-jfx/pull/117/ [3] http://hg.openjdk.java.net/openjfx/jfx-dev/rt [4] http://hg.openjdk.java.net/openjfx/8u-dev/rt Thanks, Arun From kevin.rushforth at oracle.com Tue Jul 17 17:52:33 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Jul 2018 10:52:33 -0700 Subject: Changes for July 2018 CPU release synced into FX 8u-dev, 10u-dev, jfx-dev Message-ID: <68ea55af-7bbe-b19a-3d62-f65ef5f7fd67@oracle.com> FYI, I have synced the OpenJFX changes from the just-released July 2018 CPU/PSU release (8u181, 10.0.2) into 8u-dev, 10u-dev, and jfx-dev. -- Kevin From ericeden at amazon.com Tue Jul 17 17:57:41 2018 From: ericeden at amazon.com (Edens, Eric) Date: Tue, 17 Jul 2018 17:57:41 +0000 Subject: Changes for July 2018 CPU release synced into FX 8u-dev, 10u-dev, jfx-dev Message-ID: <1531850261752.53902@amazon.com> Quick check on the tags. For JFX 8u181, the latest tag shows a build number of b12, but for JDK 8u181 the latest tag shows a build number is b13. Should the build numbers be the same? http://hg.openjdk.java.net/openjfx/8u/rt/tags http://hg.openjdk.java.net/jdk8u/jdk8u/tags? From kevin.rushforth at oracle.com Tue Jul 17 18:29:09 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Jul 2018 11:29:09 -0700 Subject: Changes for July 2018 CPU release synced into FX 8u-dev, 10u-dev, jfx-dev In-Reply-To: <1531850261752.53902@amazon.com> References: <1531850261752.53902@amazon.com> Message-ID: There was a somewhat late-ish respin of JDK 8u181 for a problem that was unrelated to and did not affect JavaFX, so JDK 8u181-b13 used the FX bits from build 12. Thanks for checking, though. -- Kevin On 7/17/2018 10:57 AM, Edens, Eric wrote: > Quick check on the tags. For JFX 8u181, the latest tag shows a build number of b12, but for JDK 8u181 the latest tag shows a build number is b13. Should the build numbers be the same? > > > http://hg.openjdk.java.net/openjfx/8u/rt/tags > > http://hg.openjdk.java.net/jdk8u/jdk8u/tags? From mark at soderquist.net Tue Jul 17 20:07:43 2018 From: mark at soderquist.net (Mark Soderquist) Date: Tue, 17 Jul 2018 14:07:43 -0600 Subject: JavaFX 11 maven snapshots - empty jars Message-ID: I've been forging ahead in my JavaFX work trying to get things figured out with OpenJDK 11 and OpenJFX. It's an exciting challenge. I've read the other two threads regarding the Maven snapshot artifacts and there are probably more questions than answers at this point. Since Johan mentioned the OpenJDK workshop I wanted to ask about the intended tooling around modules, specifically since OpenJFX just got thrust into that space starting with OpenJDK 11. Maven only handles JARs as far as I can tell. Support for proper modules, JMODs, is limited at this point. I'm not sure if Maven would know how to use a JMOD if it were put in a repository. I haven't tried. Even if we manage to get the current artifacts working we still have to be able to get through jlink and javapackager to create a deployable application. My hope for the workshop is that some guidance will come from those who understand how java modules are intended to work so we can apply that guidance to OpenJFX. It would apply to all those who have to make platform specific modules. - Mark From tom.schindl at bestsolution.at Wed Jul 18 13:02:23 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 18 Jul 2018 15:02:23 +0200 Subject: Trying to find what fixed a TextFlow bug between 8 and 9 Message-ID: <185d5407-0d11-4a33-76e6-cd6b5ca7079b@bestsolution.at> Hi, I'm trying to find the change that was made so that the following snippet renders the text no matter if TextFlow wraps the line or not in the same way (which is broken in FX8) > package fxbugs; > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.layout.VBox; > import javafx.scene.text.Text; > import javafx.scene.text.TextFlow; > import javafx.stage.Stage; > > public class TextRenderBug extends Application { > > @Override > public void start(Stage primaryStage) throws Exception { > VBox box = new VBox(); > > Text t1 = new Text("1234"); > Text t2 = new Text(" - A. Ackermann Bla Bla Bla"); > TextFlow t = new TextFlow(t1,t2); > box.getChildren().add(t); > > Scene s = new Scene(box, 800, 600); > primaryStage.setScene(s); > primaryStage.show(); > } > > public static void main(String[] args) { > launch(args); > } > } I've looked through the changes of com.sun.javafx.text but nothing really looked like it might have fixed the issue. Tom From philip.race at oracle.com Wed Jul 18 17:04:08 2018 From: philip.race at oracle.com (Philip Race) Date: Wed, 18 Jul 2018 10:04:08 -0700 Subject: Trying to find what fixed a TextFlow bug between 8 and 9 In-Reply-To: <185d5407-0d11-4a33-76e6-cd6b5ca7079b@bestsolution.at> References: <185d5407-0d11-4a33-76e6-cd6b5ca7079b@bestsolution.at> Message-ID: <5B4F7308.7080404@oracle.com> Do you see the bug as platform independent ? I just ran your test on 8u121 on Mac and am not sure what the problem is that you are seeing. It behaves as well as JDK 10 does. If its platform specific maybe you need to look at the platform-specific code -phil. On 7/18/18, 6:02 AM, Tom Schindl wrote: > Hi, > > I'm trying to find the change that was made so that the following > snippet renders the text no matter if TextFlow wraps the line or not in > the same way (which is broken in FX8) > >> package fxbugs; >> >> import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.layout.VBox; >> import javafx.scene.text.Text; >> import javafx.scene.text.TextFlow; >> import javafx.stage.Stage; >> >> public class TextRenderBug extends Application { >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> VBox box = new VBox(); >> >> Text t1 = new Text("1234"); >> Text t2 = new Text(" - A. Ackermann Bla Bla Bla"); >> TextFlow t = new TextFlow(t1,t2); >> box.getChildren().add(t); >> >> Scene s = new Scene(box, 800, 600); >> primaryStage.setScene(s); >> primaryStage.show(); >> } >> >> public static void main(String[] args) { >> launch(args); >> } >> } > I've looked through the changes of com.sun.javafx.text but nothing > really looked like it might have fixed the issue. > > Tom From tom.schindl at bestsolution.at Wed Jul 18 18:04:33 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 18 Jul 2018 20:04:33 +0200 Subject: Trying to find what fixed a TextFlow bug between 8 and 9 In-Reply-To: <5B4F7308.7080404@oracle.com> References: <185d5407-0d11-4a33-76e6-cd6b5ca7079b@bestsolution.at> <5B4F7308.7080404@oracle.com> Message-ID: Hi, I'm on OS-X and running that code repositions the glyphs once it starts wrapping the 2nd Text-Node. See this screencast: https://youtu.be/W-N0fSTeYtg Tom On 18.07.18 19:04, Philip Race wrote: > Do you see the bug as platform independent ? > I just ran your test on 8u121 on Mac and am not sure what the problem is > that you are seeing. It behaves as well as JDK 10 does. > If its platform specific maybe you need to look at the platform-specific > code > > -phil. > > On 7/18/18, 6:02 AM, Tom Schindl wrote: >> Hi, >> >> I'm trying to find the change that was made so that the following >> snippet renders the text no matter if TextFlow wraps the line or not in >> the same way (which is broken in FX8) >> >>> package fxbugs; >>> >>> import javafx.application.Application; >>> import javafx.scene.Scene; >>> import javafx.scene.layout.VBox; >>> import javafx.scene.text.Text; >>> import javafx.scene.text.TextFlow; >>> import javafx.stage.Stage; >>> >>> public class TextRenderBug extends Application { >>> >>> ???? @Override >>> ???? public void start(Stage primaryStage) throws Exception { >>> ???????? VBox box = new VBox(); >>> >>> ???????? Text t1 = new Text("1234"); >>> ???????? Text t2 = new Text(" - A. Ackermann Bla Bla Bla"); >>> ???????? TextFlow t = new TextFlow(t1,t2); >>> ???????? box.getChildren().add(t); >>> >>> ???????? Scene s = new Scene(box, 800, 600); >>> ???????? primaryStage.setScene(s); >>> ???????? primaryStage.show(); >>> ???? } >>> >>> ???? public static void main(String[] args) { >>> ???????? launch(args); >>> ???? } >>> } >> I've looked through the changes of com.sun.javafx.text but nothing >> really looked like it might have fixed the issue. >> >> Tom From philip.race at oracle.com Wed Jul 18 22:38:54 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 18 Jul 2018 15:38:54 -0700 Subject: Trying to find what fixed a TextFlow bug between 8 and 9 In-Reply-To: References: <185d5407-0d11-4a33-76e6-cd6b5ca7079b@bestsolution.at> <5B4F7308.7080404@oracle.com> Message-ID: <6cc424cd-a6f8-0341-7ca6-020a88fa75bc@oracle.com> OK. I see it on Mac, but I don't see it on Windows, and on Mac it goes away if I use -Dprism.order=sw So perhaps you need to be looking for a fix in the ES2 pipeline code ? -phil. On 07/18/2018 11:04 AM, Tom Schindl wrote: > Hi, > > I'm on OS-X and running that code repositions the glyphs once it starts > wrapping the 2nd Text-Node. > > See this screencast: https://youtu.be/W-N0fSTeYtg > > Tom > > On 18.07.18 19:04, Philip Race wrote: >> Do you see the bug as platform independent ? >> I just ran your test on 8u121 on Mac and am not sure what the problem is >> that you are seeing. It behaves as well as JDK 10 does. >> If its platform specific maybe you need to look at the platform-specific >> code >> >> -phil. >> >> On 7/18/18, 6:02 AM, Tom Schindl wrote: >>> Hi, >>> >>> I'm trying to find the change that was made so that the following >>> snippet renders the text no matter if TextFlow wraps the line or not in >>> the same way (which is broken in FX8) >>> >>>> package fxbugs; >>>> >>>> import javafx.application.Application; >>>> import javafx.scene.Scene; >>>> import javafx.scene.layout.VBox; >>>> import javafx.scene.text.Text; >>>> import javafx.scene.text.TextFlow; >>>> import javafx.stage.Stage; >>>> >>>> public class TextRenderBug extends Application { >>>> >>>> @Override >>>> public void start(Stage primaryStage) throws Exception { >>>> VBox box = new VBox(); >>>> >>>> Text t1 = new Text("1234"); >>>> Text t2 = new Text(" - A. Ackermann Bla Bla Bla"); >>>> TextFlow t = new TextFlow(t1,t2); >>>> box.getChildren().add(t); >>>> >>>> Scene s = new Scene(box, 800, 600); >>>> primaryStage.setScene(s); >>>> primaryStage.show(); >>>> } >>>> >>>> public static void main(String[] args) { >>>> launch(args); >>>> } >>>> } >>> I've looked through the changes of com.sun.javafx.text but nothing >>> really looked like it might have fixed the issue. >>> >>> Tom From tom.schindl at bestsolution.at Thu Jul 19 07:53:25 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 19 Jul 2018 09:53:25 +0200 Subject: Trying to find what fixed a TextFlow bug between 8 and 9 In-Reply-To: <6cc424cd-a6f8-0341-7ca6-020a88fa75bc@oracle.com> References: <185d5407-0d11-4a33-76e6-cd6b5ca7079b@bestsolution.at> <5B4F7308.7080404@oracle.com> <6cc424cd-a6f8-0341-7ca6-020a88fa75bc@oracle.com> Message-ID: <7448488c-88a8-b059-fed9-53c181bea593@bestsolution.at> Hi, You are absolutely right! Running in the software pipline yields the correct results on java8 as well. In general although the fonts produced by the SW-pipeline look different to the ones from the es2 one (they look thinner). I'll dig further - this is a blocking issue for one of our applications as it makes the whole UI look slugish and none professional and moving to Java9 is currently out-of-scope. Tom On 19.07.18 00:38, Phil Race wrote: > OK. I see it on Mac, but I don't see it on Windows, and on Mac it goes away > if I use -Dprism.order=sw > > So perhaps you need to be looking for a fix in the ES2 pipeline code ? > > -phil. > > On 07/18/2018 11:04 AM, Tom Schindl wrote: >> Hi, >> >> I'm on OS-X and running that code repositions the glyphs once it starts >> wrapping the 2nd Text-Node. >> >> See this screencast: https://youtu.be/W-N0fSTeYtg >> >> Tom >> >> On 18.07.18 19:04, Philip Race wrote: >>> Do you see the bug as platform independent ? >>> I just ran your test on 8u121 on Mac and am not sure what the problem is >>> that you are seeing. It behaves as well as JDK 10 does. >>> If its platform specific maybe you need to look at the platform-specific >>> code >>> >>> -phil. >>> >>> On 7/18/18, 6:02 AM, Tom Schindl wrote: >>>> Hi, >>>> >>>> I'm trying to find the change that was made so that the following >>>> snippet renders the text no matter if TextFlow wraps the line or not in >>>> the same way (which is broken in FX8) >>>> >>>>> package fxbugs; >>>>> >>>>> import javafx.application.Application; >>>>> import javafx.scene.Scene; >>>>> import javafx.scene.layout.VBox; >>>>> import javafx.scene.text.Text; >>>>> import javafx.scene.text.TextFlow; >>>>> import javafx.stage.Stage; >>>>> >>>>> public class TextRenderBug extends Application { >>>>> >>>>> ????? @Override >>>>> ????? public void start(Stage primaryStage) throws Exception { >>>>> ????????? VBox box = new VBox(); >>>>> >>>>> ????????? Text t1 = new Text("1234"); >>>>> ????????? Text t2 = new Text(" - A. Ackermann Bla Bla Bla"); >>>>> ????????? TextFlow t = new TextFlow(t1,t2); >>>>> ????????? box.getChildren().add(t); >>>>> >>>>> ????????? Scene s = new Scene(box, 800, 600); >>>>> ????????? primaryStage.setScene(s); >>>>> ????????? primaryStage.show(); >>>>> ????? } >>>>> >>>>> ????? public static void main(String[] args) { >>>>> ????????? launch(args); >>>>> ????? } >>>>> } >>>> I've looked through the changes of com.sun.javafx.text but nothing >>>> really looked like it might have fixed the issue. >>>> >>>> Tom > From prasanta.sadhukhan at oracle.com Thu Jul 19 09:14:19 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 19 Jul 2018 14:44:19 +0530 Subject: [11] RFR JDK-8201291:Clicking a JFXPanel having setFocusable(false) causes its processMouseEvent method to loop forever Message-ID: Hi All, Please review a fix for JFXPanel focusability issue Bug: https://bugs.openjdk.java.net/browse/JDK-8201291 webrev: http://cr.openjdk.java.net/~psadhukhan/fx/8201291/webrev.0/ Regards Prasanta From prasanta.sadhukhan at oracle.com Fri Jul 20 05:21:45 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 20 Jul 2018 10:51:45 +0530 Subject: [11] RFR JDK-8207923: Disable failing Swing interop tests in SandboxAppTest Message-ID: Hi Kevin, All Please review the disabling of the 2 failing tests in SandboxAppTest. --- a/tests/system/src/test/java/test/sandbox/SandboxAppTest.java Mon Jul 16 14:30:19 2018 +0530 +++ b/tests/system/src/test/java/test/sandbox/SandboxAppTest.java Fri Jul 20 10:49:46 2018 +0530 @@ -29,6 +29,7 @@ ?import java.util.ArrayList; ?import junit.framework.AssertionFailedError; ?import org.junit.Test; +import org.junit.Ignore; ?import static org.junit.Assert.*; ?import static org.junit.Assume.*; @@ -109,11 +110,13 @@ ???????? runSandboxedApp("FXNonApp"); ???? } +??? @Ignore("JDK-8202451") ???? @Test (timeout = 15000) ???? public void testJFXPanelApp() throws Exception { ???????? runSandboxedApp("JFXPanelApp"); ???? } +??? @Ignore("JDK-8202451") ???? @Test (timeout = 15000) ???? public void testJFXPanelImplicitExitApp() throws Exception { ???????? runSandboxedApp("JFXPanelImplicitExitApp", 0); Regards Prasanta From kevin.rushforth at oracle.com Fri Jul 20 11:57:58 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Jul 2018 04:57:58 -0700 Subject: [11] RFR JDK-8207923: Disable failing Swing interop tests in SandboxAppTest In-Reply-To: References: Message-ID: +1 On 7/19/2018 10:21 PM, Prasanta Sadhukhan wrote: > Hi Kevin, All > > Please review the disabling of the 2 failing tests in SandboxAppTest. > > --- a/tests/system/src/test/java/test/sandbox/SandboxAppTest.java Mon > Jul 16 14:30:19 2018 +0530 > +++ b/tests/system/src/test/java/test/sandbox/SandboxAppTest.java Fri > Jul 20 10:49:46 2018 +0530 > @@ -29,6 +29,7 @@ > ?import java.util.ArrayList; > ?import junit.framework.AssertionFailedError; > ?import org.junit.Test; > +import org.junit.Ignore; > > ?import static org.junit.Assert.*; > ?import static org.junit.Assume.*; > @@ -109,11 +110,13 @@ > ???????? runSandboxedApp("FXNonApp"); > ???? } > > +??? @Ignore("JDK-8202451") > ???? @Test (timeout = 15000) > ???? public void testJFXPanelApp() throws Exception { > ???????? runSandboxedApp("JFXPanelApp"); > ???? } > > +??? @Ignore("JDK-8202451") > ???? @Test (timeout = 15000) > ???? public void testJFXPanelImplicitExitApp() throws Exception { > ???????? runSandboxedApp("JFXPanelImplicitExitApp", 0); > > Regards > Prasanta From stijn.vranckx1 at telenet.be Fri Jul 20 19:59:33 2018 From: stijn.vranckx1 at telenet.be (stijn.vranckx1 at telenet.be) Date: Fri, 20 Jul 2018 21:59:33 +0200 (CEST) Subject: openjdk doesn't find my javafx modules Message-ID: <1597079487.455989197.1532116773619.JavaMail.zimbra@telenet.be> Hi, I have downloaded both: - openjdk-11-ea+23_windows-x64_bin - openjfx-11-ea+19_windows-x64_bin-sdk And unzipped them C:\Program Files\Java\jdk-11 and C:\Program Files\Java\jdk-11\javafx-sdk-11 However when I run my javafx application with --module-path "C:\Program Files\Java\jdk-11\javafx-sdk-11\"--add-modules javafx.graphics,javafx.fxml parameters. I get the error: Error occurred during initialization of boot layer java.lang.module.FindException: Module javafx.graphics not found I looked for a solution, but can't find any. Which makes it hard to verify if JDK-8193313 : MediaPlayer Leaking Native Memory still occurs in my application. Best regards, Stijn From johan at lodgon.com Fri Jul 20 20:07:13 2018 From: johan at lodgon.com (Johan Vos) Date: Fri, 20 Jul 2018 22:07:13 +0200 Subject: openjdk doesn't find my javafx modules In-Reply-To: <1597079487.455989197.1532116773619.JavaMail.zimbra@telenet.be> References: <1597079487.455989197.1532116773619.JavaMail.zimbra@telenet.be> Message-ID: Hi, You need to add `lib` to the module path (hence ...\javafx-sdk-11\lib) We just published a very small howto at http://docs.gluonhq.com/javafx11/#install-javafx - Johan Op vr 20 jul. 2018 om 22:01 schreef : > Hi, > > I have downloaded both: > > - openjdk-11-ea+23_windows-x64_bin > - openjfx-11-ea+19_windows-x64_bin-sdk > > And unzipped them C:\Program Files\Java\jdk-11 and C:\Program > Files\Java\jdk-11\javafx-sdk-11 > > However when I run my javafx application with > > --module-path "C:\Program Files\Java\jdk-11\javafx-sdk-11\"--add-modules > javafx.graphics,javafx.fxml > > parameters. > > I get the error: > > Error occurred during initialization of boot layer > java.lang.module.FindException: Module javafx.graphics not found > > I looked for a solution, but can't find any. > > Which makes it hard to verify if JDK-8193313 : MediaPlayer Leaking Native > Memory still occurs in my application. > > > Best regards, > Stijn > > > From kevin.rushforth at oracle.com Fri Jul 20 21:02:29 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Jul 2018 14:02:29 -0700 Subject: [11] Review request: 8207015: jlink javafx.graphics on Windows fails: PluginException: Duplicate resources Message-ID: <27f634e5-becb-380f-686d-374ce6b69ca0@oracle.com> Please review the following PR on GItHub. Once approved there, I will merge it to develop and then push it to the jfx-dev HG repo. https://bugs.openjdk.java.net/browse/JDK-8207015 https://github.com/javafxports/openjdk-jfx/pull/136 -- Kevin From mike.ennen at gmail.com Fri Jul 20 21:08:16 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 20 Jul 2018 14:08:16 -0700 Subject: Review-Request for JDK-8207372 Message-ID: Hi, I'd like to request a review for the fix of JDK-8207372. The change is at https://github.com/javafxports/openjdk-jfx/pull/134 Thanks. -- Michael Ennen From org.openjdk at io7m.com Sat Jul 21 14:55:15 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Sat, 21 Jul 2018 15:55:15 +0100 Subject: Simple Maven example fails with unusual error Message-ID: <20180721155515.7d471cad@almond.int.arc7.info> Hello! I've finally gotten around to trying out the artifacts that are currently on Maven Central. I put together a trivial example that does nothing but start up OpenJFX: https://github.com/io7m/javafx-example-20180721 It works, but only if I take the somewhat bizarre step of excluding the non-platform-specific artifacts from the build. Note the elements in the Maven dependencies. The error I get if I don't do this: java.lang.module.FindException: Unable to derive module descriptor for /home/rm/var/maven/org/openjfx/javafx-graphics/11-ea+19/javafx-graphics-11-ea+19.jar Caused by: java.lang.IllegalArgumentException: javafx.graphics.11.ea.19: Invalid module name: '11' is not a Java identifier Is this a known issue? -- Mark Raynsford | http://www.io7m.com From org.openjdk at io7m.com Sat Jul 21 15:07:45 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Sat, 21 Jul 2018 16:07:45 +0100 Subject: Simple Maven example fails with unusual error In-Reply-To: <20180721155515.7d471cad@almond.int.arc7.info> References: <20180721155515.7d471cad@almond.int.arc7.info> Message-ID: <20180721160745.61862755@almond.int.arc7.info> On 2018-07-21T15:55:15 +0100 Mark Raynsford wrote: > > Is this a known issue? Forgot to mention: $ java -version openjdk version "10.0.1" 2018-04-17 OpenJDK Runtime Environment (build 10.0.1+10) OpenJDK 64-Bit Server VM (build 10.0.1+10, mixed mode) $ uname -a Linux almond.int.arc7.info 4.17.5-1-ARCH #1 SMP PREEMPT Sun Jul 8 17:27:31 UTC 2018 x86_64 GNU/Linux $ mvn --version Apache Maven 3.5.2 (NON-CANONICAL_2017-10-25T13:09:52+03:00_root; 2017-10-25T11:09:52+01:00) Maven home: /opt/maven Java version: 10.0.1, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-10-openjdk Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "4.17.5-1-arch", arch: "amd64", family: "unix" -- Mark Raynsford | http://www.io7m.com From matthew.james.elliot at gmail.com Sun Jul 22 13:35:02 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Sun, 22 Jul 2018 15:35:02 +0200 Subject: TableViews Shift+Click multi-selection issues Message-ID: Hi all, I hope this is an easy question but I haven't been able to find an answer in the internet. I have a TreeTable with multi-selection enabled and I am listing to the selectedItems() property. When I shift+click with the mouse to select more than 1 row I always first get notified there are 0 elements due to a clearSelection call inside the implementation and then notified of the selected elements. (2 calls) It would seem TreeTable should support this operation atomically (code is there) but that the way the mouse click bubbles through the table implementation it does so without triggering the isAtomic() option and therefore multiple notifications are triggered against selectedItems(). For me this is problematic as the clear has a meaning in the application, e.g. unselect and I want to happen in some cases but definitely not in this case. Click unselect vs Shift + Click to multi-select. Conversely control clicking is fine as it will simply add to the selection. Is this a bug in the implementation of selection or a misunderstanding on my end? In any case, is there an obvious way to work around this whereby in the shift select case I can make this operation appear atomic even if the control will not? Thanks in advance, Matt From paulrussell70 at gmail.com Sun Jul 22 17:17:49 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Sun, 22 Jul 2018 18:17:49 +0100 Subject: Simple Maven example fails with unusual error In-Reply-To: References: Message-ID: Hi Mark, Are you using the v. latest version maven compiler in your POM? Best, Paul On Sun, 22 Jul 2018 at 13:00, 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. Simple Maven example fails with unusual error (Mark Raynsford) > 2. Re: Simple Maven example fails with unusual error (Mark Raynsford) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 21 Jul 2018 15:55:15 +0100 > From: Mark Raynsford > To: openjfx-dev at openjdk.java.net > Subject: Simple Maven example fails with unusual error > Message-ID: <20180721155515.7d471cad at almond.int.arc7.info> > Content-Type: text/plain; charset=US-ASCII > > Hello! > > I've finally gotten around to trying out the artifacts that are > currently on Maven Central. > > I put together a trivial example that does nothing but start up > OpenJFX: > > https://github.com/io7m/javafx-example-20180721 > > It works, but only if I take the somewhat bizarre step of excluding the > non-platform-specific artifacts from the build. Note the > elements in the Maven dependencies. > > The error I get if I don't do this: > > java.lang.module.FindException: Unable to derive module descriptor > for > /home/rm/var/maven/org/openjfx/javafx-graphics/11-ea+19/javafx-graphics-11-ea+19.jar > Caused by: java.lang.IllegalArgumentException: > javafx.graphics.11.ea.19: Invalid module name: '11' is not a Java > identifier > > Is this a known issue? > > -- > Mark Raynsford | http://www.io7m.com > > > > ------------------------------ > > Message: 2 > Date: Sat, 21 Jul 2018 16:07:45 +0100 > From: Mark Raynsford > To: openjfx-dev at openjdk.java.net > Subject: Re: Simple Maven example fails with unusual error > Message-ID: <20180721160745.61862755 at almond.int.arc7.info> > Content-Type: text/plain; charset=US-ASCII > > On 2018-07-21T15:55:15 +0100 > Mark Raynsford wrote: > > > > Is this a known issue? > > Forgot to mention: > > $ java -version > openjdk version "10.0.1" 2018-04-17 > OpenJDK Runtime Environment (build 10.0.1+10) > OpenJDK 64-Bit Server VM (build 10.0.1+10, mixed mode) > > $ uname -a > Linux almond.int.arc7.info 4.17.5-1-ARCH #1 SMP PREEMPT Sun Jul 8 > 17:27:31 UTC 2018 x86_64 GNU/Linux > > $ mvn --version > Apache Maven 3.5.2 (NON-CANONICAL_2017-10-25T13:09:52+03:00_root; > 2017-10-25T11:09:52+01:00) Maven home: /opt/maven > Java version: 10.0.1, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-10-openjdk > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux", version: "4.17.5-1-arch", arch: "amd64", family: > "unix" > > > -- > Mark Raynsford | http://www.io7m.com > > > > End of openjfx-dev Digest, Vol 80, Issue 32 > ******************************************* > From paulrussell70 at gmail.com Sun Jul 22 17:29:52 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Sun, 22 Jul 2018 18:29:52 +0100 Subject: openjfx-dev Digest, Vol 80, Issue 32 In-Reply-To: References: Message-ID: Hi Mark, OK ignore that. I clicked through and looked at your POM. Best, Paul On Sun, 22 Jul 2018 at 13:00, 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. Simple Maven example fails with unusual error (Mark Raynsford) > 2. Re: Simple Maven example fails with unusual error (Mark Raynsford) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 21 Jul 2018 15:55:15 +0100 > From: Mark Raynsford > To: openjfx-dev at openjdk.java.net > Subject: Simple Maven example fails with unusual error > Message-ID: <20180721155515.7d471cad at almond.int.arc7.info> > Content-Type: text/plain; charset=US-ASCII > > Hello! > > I've finally gotten around to trying out the artifacts that are > currently on Maven Central. > > I put together a trivial example that does nothing but start up > OpenJFX: > > https://github.com/io7m/javafx-example-20180721 > > It works, but only if I take the somewhat bizarre step of excluding the > non-platform-specific artifacts from the build. Note the > elements in the Maven dependencies. > > The error I get if I don't do this: > > java.lang.module.FindException: Unable to derive module descriptor > for > /home/rm/var/maven/org/openjfx/javafx-graphics/11-ea+19/javafx-graphics-11-ea+19.jar > Caused by: java.lang.IllegalArgumentException: > javafx.graphics.11.ea.19: Invalid module name: '11' is not a Java > identifier > > Is this a known issue? > > -- > Mark Raynsford | http://www.io7m.com > > > > ------------------------------ > > Message: 2 > Date: Sat, 21 Jul 2018 16:07:45 +0100 > From: Mark Raynsford > To: openjfx-dev at openjdk.java.net > Subject: Re: Simple Maven example fails with unusual error > Message-ID: <20180721160745.61862755 at almond.int.arc7.info> > Content-Type: text/plain; charset=US-ASCII > > On 2018-07-21T15:55:15 +0100 > Mark Raynsford wrote: > > > > Is this a known issue? > > Forgot to mention: > > $ java -version > openjdk version "10.0.1" 2018-04-17 > OpenJDK Runtime Environment (build 10.0.1+10) > OpenJDK 64-Bit Server VM (build 10.0.1+10, mixed mode) > > $ uname -a > Linux almond.int.arc7.info 4.17.5-1-ARCH #1 SMP PREEMPT Sun Jul 8 > 17:27:31 UTC 2018 x86_64 GNU/Linux > > $ mvn --version > Apache Maven 3.5.2 (NON-CANONICAL_2017-10-25T13:09:52+03:00_root; > 2017-10-25T11:09:52+01:00) Maven home: /opt/maven > Java version: 10.0.1, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-10-openjdk > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux", version: "4.17.5-1-arch", arch: "amd64", family: > "unix" > > > -- > Mark Raynsford | http://www.io7m.com > > > > End of openjfx-dev Digest, Vol 80, Issue 32 > ******************************************* > From org.openjdk at io7m.com Sun Jul 22 21:07:06 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Sun, 22 Jul 2018 22:07:06 +0100 Subject: Simple Maven example fails with unusual error In-Reply-To: References: Message-ID: <20180722220706.5c4d5338@almond.int.arc7.info> On 2018-07-22T18:17:49 +0100 Paul Ray Russell wrote: > Hi Mark, > > Are you using the v. latest version maven compiler in your POM? Hello! Yes, I'm using the maven-compiler-plugin 3.7.0. -- Mark Raynsford | http://www.io7m.com From johan.vos at gluonhq.com Mon Jul 23 07:42:56 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 23 Jul 2018 09:42:56 +0200 Subject: Simple Maven example fails with unusual error In-Reply-To: <20180722220706.5c4d5338@almond.int.arc7.info> References: <20180722220706.5c4d5338@almond.int.arc7.info> Message-ID: Hi Mark, Paul, I can't reproduce the issue, as I'm running into these warnings that are turned into errors, apparantly: [WARNING] Rule 4: org.apache.maven.plugins.enforcer.RequireProperty failed with message: Property "io7m.api.previousVersion" evaluates to "". This does not match the regular expression "[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9]+)?" On Sun, Jul 22, 2018 at 11:18 PM Mark Raynsford wrote: > On 2018-07-22T18:17:49 +0100 > Paul Ray Russell wrote: > > > Hi Mark, > > > > Are you using the v. latest version maven compiler in your POM? > > Hello! > > Yes, I'm using the maven-compiler-plugin 3.7.0. > > -- > Mark Raynsford | http://www.io7m.com > > From org.openjdk at io7m.com Mon Jul 23 08:09:04 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 23 Jul 2018 09:09:04 +0100 Subject: Simple Maven example fails with unusual error In-Reply-To: References: <20180722220706.5c4d5338@almond.int.arc7.info> Message-ID: <20180723090904.65f728b0@almond.int.arc7.info> On 2018-07-23T09:42:56 +0200 Johan Vos wrote: > Hi Mark, Paul, > > I can't reproduce the issue, as I'm running into these warnings that are > turned into errors, apparantly: > > [WARNING] Rule 4: org.apache.maven.plugins.enforcer.RequireProperty failed > with message: > Property "io7m.api.previousVersion" evaluates to "". This does not match > the regular expression "[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9]+)?" Sorry, my fault. I'd inadvertently set the POM's parent to the parent POM I usually use. I've removed it. However, I'm now getting an apparently more serious error: $ mvn -e clean package [INFO] Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building com.io7m.javafx0 0.0.1 [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ com.io7m.javafx0 --- [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ com.io7m.javafx0 --- [WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent! [INFO] skip non existing resourceDirectory /home/rm/git/com.github/io7m/javafx-bug-20180721/src/main/resources [INFO] [INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @ com.io7m.javafx0 --- [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.070 s [INFO] Finished at: 2018-07-23T09:06:34+01:00 [INFO] Final Memory: 9M/37M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project com.io7m.javafx0: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile failed.: IllegalArgumentException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project com.io7m.javafx0: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290) at org.apache.maven.cli.MavenCli.main (MavenCli.java:194) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:564) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:145) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290) at org.apache.maven.cli.MavenCli.main (MavenCli.java:194) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:564) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) Caused by: java.lang.IllegalArgumentException at org.objectweb.asm.ClassReader. (Unknown Source) at org.objectweb.asm.ClassReader. (Unknown Source) at org.objectweb.asm.ClassReader. (Unknown Source) at org.codehaus.plexus.languages.java.jpms.AsmModuleInfoParser.parse (AsmModuleInfoParser.java:80) at org.codehaus.plexus.languages.java.jpms.AsmModuleInfoParser.getModuleDescriptor (AsmModuleInfoParser.java:65) at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths (LocationManager.java:113) at org.apache.maven.plugin.compiler.CompilerMojo.preparePaths (CompilerMojo.java:219) at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:762) at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:168) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:134) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290) at org.apache.maven.cli.MavenCli.main (MavenCli.java:194) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:564) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) [ERROR] [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException The last time I saw an exception like this related to org.objectweb.asm.ClassReader, it was due to incompatible bytecode (when Java 9 was released, most tools weren't yet compatible with Java 9 bytecode). -- Mark Raynsford | http://www.io7m.com From org.openjdk at io7m.com Mon Jul 23 10:03:08 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 23 Jul 2018 11:03:08 +0100 Subject: Simple Maven example fails with unusual error In-Reply-To: References: <20180722220706.5c4d5338@almond.int.arc7.info> <20180723090904.65f728b0@almond.int.arc7.info> Message-ID: <20180723110308.352fbbbb@almond.int.arc7.info> On 2018-07-23T10:49:29 +0100 Paul Ray Russell wrote: > Mark, > > I do find the following: > https://github.com/eclipse/jetty.project/issues/2397 - and I notice in your > POM you're using an annotation processor path. Removed that. Same error, unfortunately. I feel like we may be looking at two separate issues here. One appears to be that the non-platform-specific artifacts are named such that the JVM attempts to derive an automatic module name from them and can't due to the structure of the version number. The other issue appears to be some sort of compiler bug. There's a new release of the compiler plugin due out soon that I hope might fix the latter, but I think the former is going to require a version number format change - it's not possible to get around the fact that Maven is going to name the jar files a certain way on disk, and that the JVM doesn't like what it names them. -- Mark Raynsford | http://www.io7m.com From johan.vos at gluonhq.com Mon Jul 23 15:22:34 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 23 Jul 2018 17:22:34 +0200 Subject: Simple Maven example fails with unusual error In-Reply-To: <20180723110308.352fbbbb@almond.int.arc7.info> References: <20180722220706.5c4d5338@almond.int.arc7.info> <20180723090904.65f728b0@almond.int.arc7.info> <20180723110308.352fbbbb@almond.int.arc7.info> Message-ID: Hi Mark, So it seems these issues are not OpenJFX specific, and more projects will run into this? I'm a bit worried about the grey zone between OpenJDK and Maven/Gradle... @Kevin are you aware of someone from the jigsaw team who is working in this zone? Alan Bateman? - Johan On Mon, Jul 23, 2018 at 2:33 PM Mark Raynsford wrote: > On 2018-07-23T10:49:29 +0100 > Paul Ray Russell wrote: > > > Mark, > > > > I do find the following: > > https://github.com/eclipse/jetty.project/issues/2397 - and I notice in > your > > POM you're using an annotation processor path. > > Removed that. Same error, unfortunately. > > I feel like we may be looking at two separate issues here. One appears > to be that the non-platform-specific artifacts are named such that the > JVM attempts to derive an automatic module name from them and can't due > to the structure of the version number. The other issue appears to be > some sort of compiler bug. > > There's a new release of the compiler plugin due out soon that I hope > might fix the latter, but I think the former is going to require a > version number format change - it's not possible to get around the fact > that Maven is going to name the jar files a certain way on disk, and > that the JVM doesn't like what it names them. > > -- > Mark Raynsford | http://www.io7m.com > > From kevin.rushforth at oracle.com Mon Jul 23 15:35:47 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Jul 2018 08:35:47 -0700 Subject: Simple Maven example fails with unusual error In-Reply-To: References: <20180722220706.5c4d5338@almond.int.arc7.info> <20180723090904.65f728b0@almond.int.arc7.info> <20180723110308.352fbbbb@almond.int.arc7.info> Message-ID: Alan Bateman is probably the best person to ask about this, although I don't know how much he has looked into what maven is doing w.r.t. modules. The problem here seems to be that the dummy jar doesn't have a module-info.class, and so will become an automatic module with a name chosen based on the name of the jar. -- Kevin On 7/23/2018 8:22 AM, Johan Vos wrote: > Hi Mark, > > So it seems these issues are not OpenJFX specific, and more projects will > run into this? > I'm a bit worried about the grey zone between OpenJDK and Maven/Gradle... > @Kevin are you aware of someone from the jigsaw team who is working in this > zone? Alan Bateman? > > - Johan > > On Mon, Jul 23, 2018 at 2:33 PM Mark Raynsford wrote: > >> On 2018-07-23T10:49:29 +0100 >> Paul Ray Russell wrote: >> >>> Mark, >>> >>> I do find the following: >>> https://github.com/eclipse/jetty.project/issues/2397 - and I notice in >> your >>> POM you're using an annotation processor path. >> Removed that. Same error, unfortunately. >> >> I feel like we may be looking at two separate issues here. One appears >> to be that the non-platform-specific artifacts are named such that the >> JVM attempts to derive an automatic module name from them and can't due >> to the structure of the version number. The other issue appears to be >> some sort of compiler bug. >> >> There's a new release of the compiler plugin due out soon that I hope >> might fix the latter, but I think the former is going to require a >> version number format change - it's not possible to get around the fact >> that Maven is going to name the jar files a certain way on disk, and >> that the JVM doesn't like what it names them. >> >> -- >> Mark Raynsford | http://www.io7m.com >> >> From org.openjdk at io7m.com Mon Jul 23 15:36:15 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 23 Jul 2018 16:36:15 +0100 Subject: Simple Maven example fails with unusual error In-Reply-To: References: <20180722220706.5c4d5338@almond.int.arc7.info> <20180723090904.65f728b0@almond.int.arc7.info> <20180723110308.352fbbbb@almond.int.arc7.info> Message-ID: <20180723163615.74a28056@almond.int.arc7.info> On 2018-07-23T17:22:34 +0200 Johan Vos wrote: > Hi Mark, > > So it seems these issues are not OpenJFX specific, and more projects will > run into this? > I'm a bit worried about the grey zone between OpenJDK and Maven/Gradle... > @Kevin are you aware of someone from the jigsaw team who is working in this > zone? Alan Bateman? Depends on which of the two errors you're referring to. The one regarding the version number is not strictly OpenJFX specific, it's just that OpenJFX happened to pick a version number format that the JVM doesn't like. The issue relating to the compiler raising an IllegalArgumentException... I have no idea who's fault that is. I've been working with a lot of modular projects for over a year and only saw anything similar to this error when working with old versions of the compiler plugin (and those were fixed). Those issues were strictly down to an embedded version of ASM (pre 6.1) that didn't support the newer bytecode format. None of the ~70 or so modular projects I currently compile have this problem (both projects that are themselves modular, and have dependencies on the module path). I'm a little mystified as to why it's shown up today at all, given that it didn't when I initially posted to the list. I can reproduce the issue on Travis CI: https://travis-ci.org/io7m/javafx-example-20180721/builds/407068017 ... so it doesn't appear to be my environment that's broken (or at least it's not *just* mine!) -- Mark Raynsford | http://www.io7m.com From tom.schindl at bestsolution.at Mon Jul 23 19:37:53 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 23 Jul 2018 21:37:53 +0200 Subject: Review-Request for JDK-8207794 Message-ID: Hi, I'd like to request a review for JDK-8207794 [1] available as a PR [2] on the Github-Mirror. Thanks Tom [1]https://bugs.openjdk.java.net/browse/JDK-8207794 [2]https://github.com/javafxports/openjdk-jfx/pull/139 From mike.ennen at gmail.com Mon Jul 23 21:25:43 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 23 Jul 2018 14:25:43 -0700 Subject: Review-Request for JDK-8207370 Message-ID: Hi, I'd like to request a review for JDK-8207370 available as a PR on Github: https://github.com/javafxports/openjdk-jfx/pull/135 Thanks. -- Michael Ennen From mike.ennen at gmail.com Mon Jul 23 21:26:18 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 23 Jul 2018 14:26:18 -0700 Subject: Review-Request for JDK-8207377 Message-ID: Hi, I'd like to request a review for JDK-8207377 available as a PR on Github: https://github.com/javafxports/openjdk-jfx/pull/140 Thanks. -- Michael Ennen From arunprasad.rajkumar at oracle.com Tue Jul 24 08:28:50 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 24 Jul 2018 13:58:50 +0530 Subject: [openjfx11][RFR] 8208114: Drag and drop of text contents and URL links functionalities are broken in Webview Message-ID: <3AA90064-788D-4B3A-B87A-9D369FE5F83C@oracle.com> Hi, Please review the following fix, JBS: https://bugs.openjdk.java.net/browse/JDK-8208114 Root cause: It is a regression of JDK-8199474. DataTransfer mode should be set to readonly before calling DataTransfer::types, otherwise it will return empty mime type list while doing DnD. Solution: Move the temporary mode changing code before DataTransfer::types call. Webrev: http://cr.openjdk.java.net/~arajkumar/8208114/webrev Thanks, Arun From arunprasad.rajkumar at oracle.com Tue Jul 24 11:20:59 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 24 Jul 2018 16:50:59 +0530 Subject: [openjfx11][RFR] 8196968: One time crash on exit in JNIEnv_::CallObjectMethod Message-ID: <0332E1DC-94B5-44E2-B015-C843D3E5ACAD@oracle.com> Hi, Please review the following fix, JBS: https://bugs.openjdk.java.net/browse/JDK-8196968 webrev: http://cr.openjdk.java.net/~arajkumar/8196968/webrev Root cause: From the crash log, I could see that WebCore image decoder is trying to call the Java method(through JNI) after detaching from main thread. This leads to null JNIEnv pointer, which causes the crash. Proposed Solution: Add a null check before accessing the JNIEnv pointer. (Note: I couldn?t reproduce the crash in my dev machine) Thanks, Arun From fastegal at swingempire.de Tue Jul 24 11:44:00 2018 From: fastegal at swingempire.de (fastegal at swingempire.de) Date: Tue, 24 Jul 2018 13:44:00 +0200 Subject: Openjfx ea: error on trying to access private fields Message-ID: <20180724134400.Horde.y5nn-mlyXFems4j6Pj_c0g4@webmail.df.eu> below is a small app that comes up with a button: on click it wants to access a private field (obviouly via reflection) in the button class. Due to relaxed permission constraints, that works in all java versions 9/10 without additional configuration and also with openjdk for non-fx classes. With the combination of openjdk10 + openjfx-ea (both downloaded from their respective download pages at java.net) it throws an error at runtime on clicking: Exception in thread "JavaFX Application Thread" java.lang.reflect.InaccessibleObjectException: Unable to make field private javafx.beans.property.BooleanProperty javafx.scene.control.Button.defaultButton accessible: module javafx.controls does not "opens javafx.scene.control" to unnamed module @b65246 Happens both from the command line (thanks Johan for the concise example, easy to understand even for a command line hater like myself :) as from inside eclipse Any idea what's wrong? public class MinimalAccessFieldFX10Open extends Application { private Parent getContent() { Button button = new Button("something to click on"); button.setOnAction(e -> { // okay Object def = invokeGetFieldValue(Button.class, button, "defaultButton"); LOG.info("getting the private field: " + def); }); BorderPane pane = new BorderPane(button); return pane; } @Override public void start(Stage primaryStage) throws Exception { primaryStage.setScene(new Scene(getContent(), 600, 400)); primaryStage.show(); } public static Object invokeGetFieldValue(Class declaringClass, Object target, String name) { try { Field field = declaringClass.getDeclaredField(name); field.setAccessible(true); return field.get(target); } catch (NoSuchFieldException | SecurityException | IllegalArgumentException | IllegalAccessException e) { e.printStackTrace(); } return null; } public static void main(String[] args) { launch(args); } @SuppressWarnings("unused") private static final Logger LOG = Logger .getLogger(MinimalAccessFieldFX10Open.class.getName()); } From kevin.rushforth at oracle.com Tue Jul 24 11:44:55 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Jul 2018 04:44:55 -0700 Subject: Review Request Re: [PATCH] Fix bug to handle minus value glyph_id on Windows In-Reply-To: <8966cde8-bb77-7b01-cd04-c0fe88102a6d@nttcom.co.jp> References: <019bd585-5a3b-8cdc-8f15-f890e32055c5@nttcom.co.jp> <8966cde8-bb77-7b01-cd04-c0fe88102a6d@nttcom.co.jp> Message-ID: As an FYI, this is filed in JBS as: https://bugs.openjdk.java.net/browse/JDK-8207839 and is now being reviewed. -- Kevin On 7/5/2018 8:10 PM, Nakajima Akira wrote: > Hi All. > > I created github account today > ?and re-posted this patch to github. > Please review the following fix: > > patch: https://github.com/javafxports/openjdk-jfx/pull/125 > > Regards, > Akira Nakajima > > -------------------------------------- > Company: NTT Comware Corporation > Name: Akira Nakajima > E-Mail: nakajima.akira at nttcom.co.jp > OLA : http://www.oracle.com/technetwork/community/oca-486395.html#n > -------------------------------------- > > On 2018/06/27 15:02, Nakajima Akira wrote: >> This bug is happened on Windows. >> >> Sorry, I should use SHORTMASK instead of intMask. >> I re-send patch. >> Difference is name only. >> intMask -> SHORTMASK >> >> >> >> diff --git >> a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >> >> b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >> >> >> --- >> a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >> >> >> +++ >> b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >> >> >> @@ -52,6 +52,7 @@ >> ???? private static D2D1_COLOR_F WHITE = new D2D1_COLOR_F(1f, 1f, 1f, >> 1f); >> ???? private static D2D1_MATRIX_3X2_F D2D2_MATRIX_IDENTITY = new >> D2D1_MATRIX_3X2_F(1,0, 0,1, 0,0); >> >> +??? static final int SHORTMASK = 0x0000ffff; >> >> ???? DWGlyph(DWFontStrike strike, int glyphCode, boolean drawShapes) { >> ???????? this.strike = strike; >> @@ -303,12 +304,12 @@ >> >> ???? @Override >> ???? public int getGlyphCode() { >> -??????? return run.glyphIndices; >> +??????? return ((int)run.glyphIndices & SHORTMASK); >> ???? } >> >> ???? @Override >> ???? public RectBounds getBBox() { >> -??????? return strike.getBBox(run.glyphIndices); >> +??????? return strike.getBBox((int)run.glyphIndices & SHORTMASK); >> ???? } >> >> ???? @Override >> @@ -321,7 +322,7 @@ >> >> ???? @Override >> ???? public Shape getShape() { >> -??????? return strike.createGlyphOutline(run.glyphIndices); >> +??????? return strike.createGlyphOutline((int)run.glyphIndices & >> SHORTMASK); >> ???? } >> >> ???? @Override >> diff --git >> a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >> >> b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >> >> >> --- >> a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >> >> >> +++ >> b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >> >> >> @@ -138,6 +138,7 @@ >> ???????? int i, j; >> ???????? int[] iglyphs = new int[glyphCount]; >> ???????? int slotMask = slot << 24; >> +??????? final int SHORTMASK = 0x0000ffff; >> ???????? boolean missingGlyph = false; >> ???????? i = 0; j = rtl ? glyphCount - 1 : 0; >> ???????? while (i < glyphCount) { >> @@ -145,7 +146,7 @@ >> ???????????????? missingGlyph = true; >> ???????????????? if (composite) break; >> ???????????? } >> -??????????? iglyphs[i] = glyphs[j] | slotMask; >> +??????????? iglyphs[i] = ((int)glyphs[j] & SHORTMASK) | slotMask; >> ???????????? i++; >> ???????????? j+=step; >> ???????? } >> >> >> Thanks. >> Akira Nakajima >> >> >> On 2018/06/27 14:52, Nakajima Akira wrote: >>> # This patch is separated from >>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/022005.html >>> >>> >>> >>> Java issue error of ArrayIndexOutOfBoundsException by run following >>> Test >>> program on Windows. >>> This bug is that Java handles big glyph_id as minus value. >>> For Example, >>> Inside JavaFX, glyph_id 49496(Uint16) is now handled as -16040(short). >>> >>> >>> ScreenShots of before/after applying this patch. >>> Windows10 x64 (openjfx11 and Oracle JDK 10.0.1) >>> https://drive.google.com/drive/folders/1UHPfCbQF4X_SSvjqgNGGKfEm-8GiNP80 >>> >>> >>> >>> >>> # NOTICE >>> Now Windows API provide glyphIndices as UINT16. >>> Exsample) >>> https://msdn.microsoft.com/en-us/library/windows/desktop/dd316625%28v=vs.85%29.aspx >>> >>> >>> >>> >>> But originally, Windows API should provide as UINT32. >>> Because CMAP Format 8,12,13 have UINT32. >>> https://docs.microsoft.com/en-us/typography/opentype/spec/cmap >>> https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6cmap.html >>> >>> >>> >>> >>> I have not reported to Microsoft, since I guess Microsoft knows this >>> problem. >>> >>> CMap.java provide char (UINT16). >>> Freetype2 provide UINT32. >>> >>> >>> >>> Thanks. >>> Akira Nakajima >>> >>> >>> [PATCH] >>> javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >>> >>> >>> javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >>> >>> >>> >>> >>> ========================= >>> PATCH >>> ========================= >>> diff --git >>> a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >>> >>> >>> b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >>> >>> >>> >>> --- >>> a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >>> >>> >>> >>> +++ >>> b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java >>> >>> >>> >>> @@ -52,6 +52,7 @@ >>> ???? private static D2D1_COLOR_F WHITE = new D2D1_COLOR_F(1f, 1f, 1f, >>> 1f); >>> ???? private static D2D1_MATRIX_3X2_F D2D2_MATRIX_IDENTITY = new >>> D2D1_MATRIX_3X2_F(1,0, 0,1, 0,0); >>> >>> +??? static final int intMask = 0x0000ffff; >>> >>> ???? DWGlyph(DWFontStrike strike, int glyphCode, boolean drawShapes) { >>> ???????? this.strike = strike; >>> @@ -303,12 +304,12 @@ >>> >>> ???? @Override >>> ???? public int getGlyphCode() { >>> -??????? return run.glyphIndices; >>> +??????? return ((int)run.glyphIndices & intMask); >>> ???? } >>> >>> ???? @Override >>> ???? public RectBounds getBBox() { >>> -??????? return strike.getBBox(run.glyphIndices); >>> +??????? return strike.getBBox((int)run.glyphIndices & intMask); >>> ???? } >>> >>> ???? @Override >>> @@ -321,7 +322,7 @@ >>> >>> ???? @Override >>> ???? public Shape getShape() { >>> -??????? return strike.createGlyphOutline(run.glyphIndices); >>> +??????? return strike.createGlyphOutline((int)run.glyphIndices & >>> intMask); >>> ???? } >>> >>> ???? @Override >>> diff --git >>> a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >>> >>> >>> b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >>> >>> >>> >>> --- >>> a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >>> >>> >>> >>> +++ >>> b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java >>> >>> >>> >>> @@ -138,6 +138,7 @@ >>> ???????? int i, j; >>> ???????? int[] iglyphs = new int[glyphCount]; >>> ???????? int slotMask = slot << 24; >>> +??????? final int intMask = 0x0000ffff; >>> ???????? boolean missingGlyph = false; >>> ???????? i = 0; j = rtl ? glyphCount - 1 : 0; >>> ???????? while (i < glyphCount) { >>> @@ -145,7 +146,7 @@ >>> ???????????????? missingGlyph = true; >>> ???????????????? if (composite) break; >>> ???????????? } >>> -??????????? iglyphs[i] = glyphs[j] | slotMask; >>> +??????????? iglyphs[i] = ((int)glyphs[j] & intMask) | slotMask; >>> ???????????? i++; >>> ???????????? j+=step; >>> ???????? } >>> >>> >>> >>> ========================= >>> Test for Win10 >>> ========================= >>> import javafx.application.Application; >>> import static javafx.application.Application.launch; >>> import javafx.scene.Group; >>> import javafx.scene.Scene; >>> import javafx.scene.paint.Color; >>> import javafx.scene.text.Font; >>> import javafx.scene.text.Text; >>> import javafx.scene.text.TextFlow; >>> import javafx.stage.Stage; >>> >>> public class TestHandlingBigGlyphID_Win10 extends Application { >>> ??? @Override >>> ??? public void start(Stage stage) throws Exception { >>> ??????? final String fontName = "ARIALUNI.TTF"; // Arial Unicode MS >>> ??????? // download from >>> https://www.wfonts.com/download/data/2015/05/16/arial-unicode-ms/ARIALUNI.TTF >>> >>> >>> >>> ??????? //? and place in $(user.home)/fonts/ >>> ??????? //??? e.g. C:/Users/username/fonts/arialuni.ttf >>> >>> ??????? Font ourFont = >>> Font.loadFont("file://"+System.getProperty("user.home")+"/fonts/"+fontName.toString(), >>> >>> >>> 48); >>> ??????? TextFlow textFlow = new TextFlow(); >>> ??????????????????????????????????????????????? // Unicode(GlyphID) >>> ??????? Text text = new Text("\uD7A3\u0E3F");??? // U+D7A3(49496) + >>> U+0E3F(1262) >>> ??????? /* Inside JavaFX, 49496(Uint16) is handled as -16040(short). >>> ???????? * By ScriptMapper.isComplexCharCode(), U+0E3F is handled as >>> complex. >>> ???????? * When in condition with minus glyphID value and complex >>> ???????? * , JavaFX is forcibly terminated. >>> ???????? *???? (java.lang.ArrayIndexOutOfBoundsException) >>> ???????? */ >>> >>> ??????? text.setFill(Color.GREEN); >>> ??????? text.setFont(ourFont); >>> ??????? textFlow.getChildren().addAll(text); >>> >>> ??????? Group group = new Group(textFlow); >>> ??????? Scene scene = new Scene(group, 100, 60, Color.WHITE); >>> ??????? stage.setScene(scene); >>> ??????? stage.show(); >>> ??? } >>> } >>> >>> ========================= >>> Test for Win7 and Win10 >>> ========================= >>> import javafx.application.Application; >>> import static javafx.application.Application.launch; >>> import javafx.scene.Group; >>> import javafx.scene.Scene; >>> import javafx.scene.paint.Color; >>> import javafx.scene.text.Font; >>> import javafx.scene.text.Text; >>> import javafx.scene.text.TextFlow; >>> import javafx.stage.Stage; >>> >>> public class TestHandlingBigGlyphID_Win7_and_Win10 extends >>> Application { >>> ??? @Override >>> ??? public void start(Stage stage) throws Exception { >>> ??????? final String family = "Arial Unicode MS"; // ARIALUNI.TTF >>> ??????? // download from >>> https://www.wfonts.com/download/data/2015/05/16/arial-unicode-ms/ARIALUNI.TTF >>> >>> >>> >>> ??????? //? and You NEED install font. >>> >>> ??????? Font ourFont = Font.font(family, 48); >>> ??????? TextFlow textFlow = new TextFlow(); >>> ??????????????????????????????????????????????? // Unicode(GlyphID) >>> ??????? Text text = new Text("\uD7A3\u0E3F");??? // U+D7A3(49496) + >>> U+0E3F(1262) >>> ??????? /* Inside JavaFX, 49496(Uint16) is handled as -16040(short). >>> ???????? * By ScriptMapper.isComplexCharCode(), U+0E3F is handled as >>> complex. >>> ???????? * When in condition with minus glyphID value and complex >>> ???????? * , JavaFX is forcibly terminated. >>> ???????? *???? (java.lang.ArrayIndexOutOfBoundsException) >>> ???????? */ >>> >>> ??????? text.setFill(Color.GREEN); >>> ??????? text.setFont(ourFont); >>> ??????? textFlow.getChildren().addAll(text); >>> >>> ??????? Group group = new Group(textFlow); >>> ??????? Scene scene = new Scene(group, 100, 60, Color.WHITE); >>> ??????? stage.setScene(scene); >>> ??????? stage.show(); >>> ??? } >>> } >>> >>> >>> -------------------------------------- >>> Company: NTT Comware Corporation >>> Name: Akira Nakajima >>> E-Mail: nakajima.akira at nttcom.co.jp >>> -------------------------------------- From kevin.rushforth at oracle.com Tue Jul 24 11:47:52 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Jul 2018 04:47:52 -0700 Subject: Review Request JDK-8187100 [JavaFX] To make display Variation Selectors(SVS/IVS) on Win(VISTA-) and MacOS(10.6-) In-Reply-To: <389c3fab-0b86-e1f0-d8c8-1d76e828024f@nttcom.co.jp> References: <389c3fab-0b86-e1f0-d8c8-1d76e828024f@nttcom.co.jp> Message-ID: <02a6836a-6d53-8fc4-9e96-dfd96cb5ef72@oracle.com> This is being tracked here: https://bugs.openjdk.java.net/browse/JDK-8207932 As an RFE, this can be considered for openjfx12. -- Kevin On 7/5/2018 11:59 PM, Nakajima Akira wrote: > 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.akira at nttcom.co.jp > OLA : http://www.oracle.com/technetwork/community/oca-486395.html#n > -------------------------------------- From johan.vos at gluonhq.com Tue Jul 24 12:42:08 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 24 Jul 2018 14:42:08 +0200 Subject: Review-Request for JDK-8207370 In-Reply-To: References: Message-ID: Hi Michael, Excuse me for the simple question, but how to you enable those tests (as in: what options do you provide to gradle)? Fix looks trivial to me, but want to double check. - Johan On Mon, Jul 23, 2018 at 11:36 PM Michael Ennen wrote: > Hi, > > I'd like to request a review for JDK-8207370 available > as a PR on Github: > > https://github.com/javafxports/openjdk-jfx/pull/135 > > Thanks. > > -- > Michael Ennen > From kevin.rushforth at oracle.com Tue Jul 24 12:18:47 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Jul 2018 05:18:47 -0700 Subject: Openjfx ea: error on trying to access private fields In-Reply-To: <20180724134400.Horde.y5nn-mlyXFems4j6Pj_c0g4@webmail.df.eu> References: <20180724134400.Horde.y5nn-mlyXFems4j6Pj_c0g4@webmail.df.eu> Message-ID: Hi, The relaxed permissions, which are allowed given the default '--illegal-access=permit' mode, only apply to modules that are linked into the Java runtime. Modules that are loaded on the module-path are subject to strict access controls. I see three possible solutions for you: 1. Run your application with 'java --add-opens javafx.controls/javafx.scene.control=ALL-UNNAMED' 2. jlink the javafx modules into a custom JRE (at which point the javafx modules are part of the java runtime) 3. Find a solution that doesn't rely on accessing internal implementation details of javafx.controls. I note that the default for --illegal-access is likely to change to "deny" in the not-too-distant future -- possibly as early as JDK 12, so it is only a matter of time before this will affect platform classes (at which time option #2 stops being available without adding '--illegal-access=permit'). Long-term you should explore #3, since accessing internal fields or methods is fragile and might stop working at any point. -- Kevin On 7/24/2018 4:44 AM, fastegal at swingempire.de wrote: > > below is a small app that comes up with a button: on click it wants > to access a private field (obviouly via reflection) in the button class. > Due to relaxed permission constraints, that works in all java versions > 9/10 > without additional configuration and also with openjdk for non-fx > classes. > > With the combination of openjdk10 + openjfx-ea (both downloaded from > their > respective download pages at java.net) it throws an error at runtime > on clicking: > > Exception in thread "JavaFX Application Thread" > java.lang.reflect.InaccessibleObjectException: > Unable to make field private javafx.beans.property.BooleanProperty > javafx.scene.control.Button.defaultButton accessible: > module javafx.controls does not "opens javafx.scene.control" to > unnamed module @b65246 > > Happens both from the command line (thanks Johan for the concise example, > easy to understand even for a command line hater like myself :) as > from inside eclipse > > Any idea what's wrong? > > > public class MinimalAccessFieldFX10Open extends Application { > > ??? private Parent getContent() { > ??????? Button button = new Button("something to click on"); > > ??????? button.setOnAction(e -> { > ??????????? // okay > ??????????? Object def = invokeGetFieldValue(Button.class, button, > "defaultButton"); > ??????????? LOG.info("getting the private field: " + def); > ??????? }); > ??????? BorderPane pane = new BorderPane(button); > ??????? return pane; > ??? } > > ??? @Override > ??? public void start(Stage primaryStage) throws Exception { > ??????? primaryStage.setScene(new Scene(getContent(), 600, 400)); > ??????? primaryStage.show(); > ??? } > > ??? public static Object invokeGetFieldValue(Class declaringClass, > ??????????? Object target, String name) { > ??????? try { > ??????????? Field field = declaringClass.getDeclaredField(name); > ??????????? field.setAccessible(true); > ??????????? return field.get(target); > ??????? } catch (NoSuchFieldException | SecurityException > ??????????????? | IllegalArgumentException | IllegalAccessException e) { > ??????????? e.printStackTrace(); > ??????? } > ??????? return null; > ??? } > > ??? public static void main(String[] args) { > ??????? launch(args); > ??? } > > ??? @SuppressWarnings("unused") > ??? private static final Logger LOG = Logger > .getLogger(MinimalAccessFieldFX10Open.class.getName()); > } > From fastegal at swingempire.de Tue Jul 24 13:04:12 2018 From: fastegal at swingempire.de (fastegal at swingempire.de) Date: Tue, 24 Jul 2018 15:04:12 +0200 Subject: Openjfx ea: error on trying to access private fields In-Reply-To: References: <20180724134400.Horde.y5nn-mlyXFems4j6Pj_c0g4@webmail.df.eu> Message-ID: <20180724150412.Horde.rCE9oh5cFaiheavDw1KnUA1@webmail.df.eu> Hi Kevin, thanks for your quick answer. > > The relaxed permissions, which are allowed given the default > '--illegal-access=permit' mode, only apply to modules that are > linked into the Java runtime. Modules that are loaded on the > module-path are subject to strict access controls. > ahh ... wasn't aware of that, probably should have read the modul specs more closely ;) > I see three possible solutions for you: > > 1. Run your application with 'java --add-opens > javafx.controls/javafx.scene.control=ALL-UNNAMED' will try, might help now that I know what the base problem is > 2. jlink the javafx modules into a custom JRE (at which point the > javafx modules are part of the java runtime) that's a good intermediate, thanks > 3. Find a solution that doesn't rely on accessing internal > implementation details of javafx.controls. > hehe .. you mean without c&p of large portions of the overly closed internals > I note that the default for --illegal-access is likely to change to > "deny" in the not-too-distant future -- possibly as early as JDK 12, > so it is only a matter of time before this will affect platform > classes (at which time option #2 stops being available without > adding '--illegal-access=permit'). > > Long-term you should explore #3, since accessing internal fields or > methods is fragile and might stop working at any point. > thanks again for the info (12 is next spring, so indeed not that far away), but then the oldish versions will still be around for a while. CU, Jeanette From kevin.rushforth at oracle.com Tue Jul 24 14:16:39 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Jul 2018 07:16:39 -0700 Subject: Review-Request for JDK-8207370 In-Reply-To: References: Message-ID: The following should work: ??? gradle -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true :systemTests:test You can limit it to just the Monocle tests as follows: ??? gradle -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true :systemTests:test --tests 'test.robot.com.sun.glass.ui.monocle.*' -- Kevin On 7/24/2018 5:42 AM, Johan Vos wrote: > Hi Michael, > > Excuse me for the simple question, but how to you enable those tests (as > in: what options do you provide to gradle)? > Fix looks trivial to me, but want to double check. > > - Johan > > On Mon, Jul 23, 2018 at 11:36 PM Michael Ennen wrote: > >> Hi, >> >> I'd like to request a review for JDK-8207370 available >> as a PR on Github: >> >> https://github.com/javafxports/openjdk-jfx/pull/135 >> >> Thanks. >> >> -- >> Michael Ennen >> From johan at lodgon.com Tue Jul 24 15:54:09 2018 From: johan at lodgon.com (Johan Vos) Date: Tue, 24 Jul 2018 17:54:09 +0200 Subject: Review-Request for JDK-8207370 In-Reply-To: References: Message-ID: Using the proposed patch, there is only 1 failure instead of 12. I suggest to create a separate issue for that 1 failure, as the patch indeed fixes the assertEquals issue. Op di 24 jul. 2018 om 16:18 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > The following should work: > > gradle -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true > :systemTests:test > > You can limit it to just the Monocle tests as follows: > > gradle -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true > :systemTests:test --tests 'test.robot.com.sun.glass.ui.monocle.*' > > -- Kevin > > On 7/24/2018 5:42 AM, Johan Vos wrote: > > Hi Michael, > > > > Excuse me for the simple question, but how to you enable those tests (as > > in: what options do you provide to gradle)? > > Fix looks trivial to me, but want to double check. > > > > - Johan > > > > On Mon, Jul 23, 2018 at 11:36 PM Michael Ennen > wrote: > > > >> Hi, > >> > >> I'd like to request a review for JDK-8207370 available > >> as a PR on Github: > >> > >> https://github.com/javafxports/openjdk-jfx/pull/135 > >> > >> Thanks. > >> > >> -- > >> Michael Ennen > >> > > From kevin.rushforth at oracle.com Tue Jul 24 16:00:35 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Jul 2018 09:00:35 -0700 Subject: Review-Request for JDK-8207370 In-Reply-To: References: Message-ID: <6c9d95da-f560-ff07-dfa6-0902e7dabfe4@oracle.com> Thanks for checking. On my system, I get 0 failures after the fix. Regarding the 1 failure you see: the tests are known to be unstable, which is why they are skipped by default. This test instability is covered by JDK-8196607 [1]. Does this explain the failure you are seeing? -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8196607 On 7/24/2018 8:54 AM, Johan Vos wrote: > Using the proposed patch, there is only 1 failure instead of 12. > I suggest to create a separate issue for that 1 failure, as the patch > indeed fixes the assertEquals issue. > > Op di 24 jul. 2018 om 16:18 schreef Kevin Rushforth > >: > > The following should work: > > ???? gradle -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true > :systemTests:test > > You can limit it to just the Monocle tests as follows: > > ???? gradle -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true > :systemTests:test --tests 'test.robot.com.sun.glass.ui.monocle.*' > > -- Kevin > > On 7/24/2018 5:42 AM, Johan Vos wrote: > > Hi Michael, > > > > Excuse me for the simple question, but how to you enable those > tests (as > > in: what options do you provide to gradle)? > > Fix looks trivial to me, but want to double check. > > > > - Johan > > > > On Mon, Jul 23, 2018 at 11:36 PM Michael Ennen > > wrote: > > > >> Hi, > >> > >> I'd like to request a review for JDK-8207370 available > >> as a PR on Github: > >> > >> https://github.com/javafxports/openjdk-jfx/pull/135 > >> > >> Thanks. > >> > >> -- > >> Michael Ennen > >> > From johan at lodgon.com Tue Jul 24 16:14:02 2018 From: johan at lodgon.com (Johan Vos) Date: Tue, 24 Jul 2018 18:14:02 +0200 Subject: Review-Request for JDK-8207370 In-Reply-To: <6c9d95da-f560-ff07-dfa6-0902e7dabfe4@oracle.com> References: <6c9d95da-f560-ff07-dfa6-0902e7dabfe4@oracle.com> Message-ID: Running the tests again got 0 failures. The previous failure was: test.robot.com.sun.glass.ui.monocle.RotateTest > testRotateLeftByFewSmallSteps[1] FAILED com.sun.glass.ui.monocle.TestLogShim$TestLogAssertion: Timed out after 3000ms waiting for 'TouchPoint: PRESSED 640, 40' at javafx.graphics/com.sun.glass.ui.monocle.TestLogShim.waitForLog(TestLogShim.java:211) at javafx.graphics/com.sun.glass.ui.monocle.TestLogShim.waitForLogContaining(TestLogShim.java:237) at javafx.graphics/com.sun.glass.ui.monocle.TestLogShim.waitForLogContaining(TestLogShim.java:246) at test.robot.com.sun.glass.ui.monocle.RotateTest.Rotate(RotateTest.java:121) at test.robot.com.sun.glass.ui.monocle.RotateTest.Rotate(RotateTest.java:226) at test.robot.com.sun.glass.ui.monocle.RotateTest.testRotateLeftByFewSmallSteps(RotateTest.java:287) I ran that test a number of times, but it never failed. Might look again later, as we are still using monocle on Android. - Johan Op di 24 jul. 2018 om 18:00 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > Thanks for checking. On my system, I get 0 failures after the fix. > > Regarding the 1 failure you see: the tests are known to be unstable, which > is why they are skipped by default. This test instability is covered by > JDK-8196607 [1]. Does this explain the failure you are seeing? > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8196607 > > > > On 7/24/2018 8:54 AM, Johan Vos wrote: > > Using the proposed patch, there is only 1 failure instead of 12. > I suggest to create a separate issue for that 1 failure, as the patch > indeed fixes the assertEquals issue. > > Op di 24 jul. 2018 om 16:18 schreef Kevin Rushforth < > kevin.rushforth at oracle.com>: > >> The following should work: >> >> gradle -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true >> :systemTests:test >> >> You can limit it to just the Monocle tests as follows: >> >> gradle -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true >> :systemTests:test --tests 'test.robot.com.sun.glass.ui.monocle.*' >> >> -- Kevin >> >> On 7/24/2018 5:42 AM, Johan Vos wrote: >> > Hi Michael, >> > >> > Excuse me for the simple question, but how to you enable those tests (as >> > in: what options do you provide to gradle)? >> > Fix looks trivial to me, but want to double check. >> > >> > - Johan >> > >> > On Mon, Jul 23, 2018 at 11:36 PM Michael Ennen >> wrote: >> > >> >> Hi, >> >> >> >> I'd like to request a review for JDK-8207370 available >> >> as a PR on Github: >> >> >> >> https://github.com/javafxports/openjdk-jfx/pull/135 >> >> >> >> Thanks. >> >> >> >> -- >> >> Michael Ennen >> >> >> >> > From kevin.rushforth at oracle.com Tue Jul 24 16:42:20 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Jul 2018 09:42:20 -0700 Subject: Review-Request for JDK-8207370 In-Reply-To: References: <6c9d95da-f560-ff07-dfa6-0902e7dabfe4@oracle.com> Message-ID: <9d8fe178-85fe-d8d8-65e3-adf911e48a9f@oracle.com> Sounds good. FWIW, I think the problem is likely in the tests themselves. I will note that on my Mac system they pass quite reliably for me (I run them weekly on my local Mac, which is how I discovered the assertEquals bug). -- Kevin On 7/24/2018 9:14 AM, Johan Vos wrote: > Running the tests again got 0 failures. > The previous failure was: > test.robot.com.sun.glass.ui.monocle.RotateTest > > testRotateLeftByFewSmallSteps[1] FAILED > com.sun.glass.ui.monocle.TestLogShim$TestLogAssertion: Timed out after > 3000ms waiting for 'TouchPoint: PRESSED 640, 40' > ? ? ? ? at > javafx.graphics/com.sun.glass.ui.monocle.TestLogShim.waitForLog(TestLogShim.java:211) > ? ? ? ? at > javafx.graphics/com.sun.glass.ui.monocle.TestLogShim.waitForLogContaining(TestLogShim.java:237) > ? ? ? ? at > javafx.graphics/com.sun.glass.ui.monocle.TestLogShim.waitForLogContaining(TestLogShim.java:246) > ? ? ? ? at > test.robot.com.sun.glass.ui.monocle.RotateTest.Rotate(RotateTest.java:121) > ? ? ? ? at > test.robot.com.sun.glass.ui.monocle.RotateTest.Rotate(RotateTest.java:226) > ? ? ? ? at > test.robot.com.sun.glass.ui.monocle.RotateTest.testRotateLeftByFewSmallSteps(RotateTest.java:287) > > > I ran that test a number of times, but it never failed. Might look > again later, as we are still using monocle on Android. > > - Johan > > Op di 24 jul. 2018 om 18:00 schreef Kevin Rushforth > >: > > Thanks for checking. On my system, I get 0 failures after the fix. > > Regarding the 1 failure you see: the tests are known to be > unstable, which is why they are skipped by default. This test > instability is covered by JDK-8196607 [1]. Does this explain the > failure you are seeing? > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8196607 > > > > On 7/24/2018 8:54 AM, Johan Vos wrote: >> Using the proposed patch, there is only 1 failure instead of 12. >> I suggest to create a separate issue for that 1 failure, as the >> patch indeed fixes the assertEquals issue. >> >> Op di 24 jul. 2018 om 16:18 schreef Kevin Rushforth >> >: >> >> The following should work: >> >> ???? gradle -PFULL_TEST=true -PUSE_ROBOT=true >> -PUNSTABLE_TEST=true >> :systemTests:test >> >> You can limit it to just the Monocle tests as follows: >> >> ???? gradle -PFULL_TEST=true -PUSE_ROBOT=true >> -PUNSTABLE_TEST=true >> :systemTests:test --tests 'test.robot.com.sun.glass.ui.monocle.*' >> >> -- Kevin >> >> On 7/24/2018 5:42 AM, Johan Vos wrote: >> > Hi Michael, >> > >> > Excuse me for the simple question, but how to you enable >> those tests (as >> > in: what options do you provide to gradle)? >> > Fix looks trivial to me, but want to double check. >> > >> > - Johan >> > >> > On Mon, Jul 23, 2018 at 11:36 PM Michael Ennen >> > wrote: >> > >> >> Hi, >> >> >> >> I'd like to request a review for JDK-8207370 available >> >> as a PR on Github: >> >> >> >> https://github.com/javafxports/openjdk-jfx/pull/135 >> >> >> >> Thanks. >> >> >> >> -- >> >> Michael Ennen >> >> >> > From nakajima.akira at nttcom.co.jp Tue Jul 24 23:52:33 2018 From: nakajima.akira at nttcom.co.jp (Nakajima Akira) Date: Wed, 25 Jul 2018 08:52:33 +0900 Subject: Review-Request for JDK-8208076 (display INVISIBLE_GLYPH_ID as square box on Windows) Message-ID: <2605fa1d-7161-0584-c20b-a809a46ec78b@nttcom.co.jp> Hi. I'd like to request a review for JDK-8208076 [1] available as a PR [2] on the Github-Mirror. Thanks Akira Nakajima [1]https://bugs.openjdk.java.net/browse/JDK-8208076 [2]https://github.com/javafxports/openjdk-jfx/pull/137 -------------------------------------- Company: NTT Comware Corporation Name: Akira Nakajima E-Mail: nakajima.akira at nttcom.co.jp OCA : http://www.oracle.com/technetwork/community/oca-486395.html#n -------------------------------------- From kevin.rushforth at oracle.com Wed Jul 25 11:55:54 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Jul 2018 04:55:54 -0700 Subject: Result: New OpenJFX Committer: Prem Balakrishnan In-Reply-To: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> References: <6f734c02-fb89-6908-e679-0fdbc2f58349@oracle.com> Message-ID: <58e8077c-ad57-ad05-4d45-05b1f3479e04@oracle.com> Voting for Prem Balakrishnan [1] to OpenJFX Committer [2] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] http://openjdk.java.net/census#pkbalakr [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-July/022127.html From steve.hruda at gmail.com Thu Jul 26 08:33:10 2018 From: steve.hruda at gmail.com (Steve Hruda) Date: Thu, 26 Jul 2018 10:33:10 +0200 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage Message-ID: Hi, I created a custom runtime image (windows x64) for my JavaFX application and used the OpenJFX 11-ea+19 maven artifacts. I get the following exception if I try to execute my application: Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) at javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) at javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) at javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) at javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) at java.base/java.lang.Thread.run(Thread.java:844) Exception in thread "main" java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) Caused by: java.lang.RuntimeException: No toolkit found at javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) at javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) at javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) at javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) ... 5 more -Djavafx.verbose=true shows that JavaFX isn't able to load the native libs from the javafx-graphics jar. I debugged the NativeLibLoader and loadLibraryFromResource and installLibraryFromResource will be executed which is ok. But the *reallib *value for all dll's is wrong because of the empty *libSuffix*. e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is */api-ms-win-core-console-l1-1-0* and not */api-ms-win-core-console-l1-1-0.dll* Is it intentional that *libPrefix *& *libSuffix *will not be set in case of the jrt protocol ? https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 Best Regards, Steve From johan.vos at gluonhq.com Thu Jul 26 09:46:05 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 26 Jul 2018 11:46:05 +0200 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage In-Reply-To: References: Message-ID: Hi Steve, That looks like a bug. The libPrefix and libSuffix are indeed not set in cases where usingModules is true, which is only the case when the jrt protocol is used. It seems to me the prefix/suffix should always be computed. It doesn't look right that they are computed inside the loadLibraryFullPath. But it looks even worse that the "reallib" is calculated based on statements that might not be reached, where it could have used System.mapLibraryName() I'll create an issue and a PR to fix this. Thanks for reporting, - Johan On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda wrote: > Hi, > I created a custom runtime image (windows x64) for my JavaFX application > and used the OpenJFX 11-ea+19 maven artifacts. > > I get the following exception if I try to execute my application: > > Graphics Device initialization failed for : d3d, sw > Error initializing QuantumRenderer: no suitable pipeline found > java.lang.RuntimeException: java.lang.RuntimeException: Error initializing > QuantumRenderer: no suitable pipeline found > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) > at > > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) > at > > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) > at > > javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) > at > > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) > at > > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at > > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) > Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: > no suitable pipeline found > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) > at java.base/java.lang.Thread.run(Thread.java:844) > Exception in thread "main" java.lang.reflect.InvocationTargetException > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at > > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) > Caused by: java.lang.RuntimeException: No toolkit found > at > javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) > at > > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) > at > > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) > at > > javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) > at > > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) > at > > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) > ... 5 more > > > -Djavafx.verbose=true shows that JavaFX isn't able to load the native libs > from the javafx-graphics jar. > > > I debugged the NativeLibLoader and loadLibraryFromResource and > installLibraryFromResource will be executed which is ok. But the > *reallib *value for > all dll's is wrong because of the empty *libSuffix*. > > e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is > */api-ms-win-core-console-l1-1-0* and not > */api-ms-win-core-console-l1-1-0.dll* > > Is it intentional that *libPrefix *& *libSuffix *will not be set in case of > the jrt protocol ? > > > https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 > > > > > https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 > > > > > Best Regards, > Steve > From johan.vos at gluonhq.com Thu Jul 26 10:09:49 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 26 Jul 2018 12:09:49 +0200 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage In-Reply-To: References: Message-ID: tracked in https://github.com/javafxports/openjdk-jfx/issues/142. Tested on linux, not yet on mac/windows On Thu, Jul 26, 2018 at 11:46 AM Johan Vos wrote: > Hi Steve, > > That looks like a bug. The libPrefix and libSuffix are indeed not set in > cases where usingModules is true, which is only the case when the jrt > protocol is used. > It seems to me the prefix/suffix should always be computed. It doesn't > look right that they are computed inside the loadLibraryFullPath. But it > looks even worse that the "reallib" is calculated based on statements that > might not be reached, where it could have used System.mapLibraryName() > > I'll create an issue and a PR to fix this. > > Thanks for reporting, > > - Johan > > > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda > wrote: > >> Hi, >> I created a custom runtime image (windows x64) for my JavaFX application >> and used the OpenJFX 11-ea+19 maven artifacts. >> >> I get the following exception if I try to execute my application: >> >> Graphics Device initialization failed for : d3d, sw >> Error initializing QuantumRenderer: no suitable pipeline found >> java.lang.RuntimeException: java.lang.RuntimeException: Error initializing >> QuantumRenderer: no suitable pipeline found >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) >> at >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) >> at >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >> at >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >> at >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >> at >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >> at >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at >> >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >> Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: >> no suitable pipeline found >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) >> at java.base/java.lang.Thread.run(Thread.java:844) >> Exception in thread "main" java.lang.reflect.InvocationTargetException >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at >> >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >> Caused by: java.lang.RuntimeException: No toolkit found >> at >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) >> at >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >> at >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >> at >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >> at >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >> at >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> ... 5 more >> >> >> -Djavafx.verbose=true shows that JavaFX isn't able to load the native libs >> from the javafx-graphics jar. >> >> >> I debugged the NativeLibLoader and loadLibraryFromResource and >> installLibraryFromResource will be executed which is ok. But the >> *reallib *value for >> all dll's is wrong because of the empty *libSuffix*. >> >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is >> */api-ms-win-core-console-l1-1-0* and not >> */api-ms-win-core-console-l1-1-0.dll* >> >> Is it intentional that *libPrefix *& *libSuffix *will not be set in case >> of >> the jrt protocol ? >> >> >> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 >> >> >> >> >> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 >> >> >> >> >> Best Regards, >> Steve >> > From steve.hruda at gmail.com Thu Jul 26 10:54:17 2018 From: steve.hruda at gmail.com (Steve Hruda) Date: Thu, 26 Jul 2018 12:54:17 +0200 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage In-Reply-To: References: Message-ID: Cool, thanks for the fast response! Am Do., 26. Juli 2018 um 12:10 Uhr schrieb Johan Vos : > tracked in https://github.com/javafxports/openjdk-jfx/issues/142. > Tested on linux, not yet on mac/windows > > On Thu, Jul 26, 2018 at 11:46 AM Johan Vos wrote: > >> Hi Steve, >> >> That looks like a bug. The libPrefix and libSuffix are indeed not set in >> cases where usingModules is true, which is only the case when the jrt >> protocol is used. >> It seems to me the prefix/suffix should always be computed. It doesn't >> look right that they are computed inside the loadLibraryFullPath. But it >> looks even worse that the "reallib" is calculated based on statements that >> might not be reached, where it could have used System.mapLibraryName() >> >> I'll create an issue and a PR to fix this. >> >> Thanks for reporting, >> >> - Johan >> >> >> On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda >> wrote: >> >>> Hi, >>> I created a custom runtime image (windows x64) for my JavaFX application >>> and used the OpenJFX 11-ea+19 maven artifacts. >>> >>> I get the following exception if I try to execute my application: >>> >>> Graphics Device initialization failed for : d3d, sw >>> Error initializing QuantumRenderer: no suitable pipeline found >>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>> initializing >>> QuantumRenderer: no suitable pipeline found >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) >>> at >>> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) >>> at >>> >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >>> at >>> >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >>> at >>> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >>> at >>> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >>> at >>> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >>> at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> at >>> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at >>> >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >>> at >>> >>> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >>> Caused by: java.lang.RuntimeException: Error initializing >>> QuantumRenderer: >>> no suitable pipeline found >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) >>> at >>> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) >>> at java.base/java.lang.Thread.run(Thread.java:844) >>> Exception in thread "main" java.lang.reflect.InvocationTargetException >>> at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> at >>> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at >>> >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >>> at >>> >>> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >>> Caused by: java.lang.RuntimeException: No toolkit found >>> at >>> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) >>> at >>> >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >>> at >>> >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >>> at >>> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >>> at >>> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >>> at >>> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >>> ... 5 more >>> >>> >>> -Djavafx.verbose=true shows that JavaFX isn't able to load the native >>> libs >>> from the javafx-graphics jar. >>> >>> >>> I debugged the NativeLibLoader and loadLibraryFromResource and >>> installLibraryFromResource will be executed which is ok. But the >>> *reallib *value for >>> all dll's is wrong because of the empty *libSuffix*. >>> >>> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is >>> */api-ms-win-core-console-l1-1-0* and not >>> */api-ms-win-core-console-l1-1-0.dll* >>> >>> Is it intentional that *libPrefix *& *libSuffix *will not be set in case >>> of >>> the jrt protocol ? >>> >>> >>> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 >>> >>> >>> >>> >>> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 >>> >>> >>> >>> >>> Best Regards, >>> Steve >>> >> -- Mit freundlichen Gr??en Steve Hruda From kevin.rushforth at oracle.com Thu Jul 26 12:42:08 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 Jul 2018 05:42:08 -0700 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage In-Reply-To: References: Message-ID: Hi Steve, Seems it will be an easy bug for Johan to fix, but I'm curious about how you created your custom image. The jmods are more suitable for that approach, since their purpose is to be used with jlink to create a custom image, in which case the native libraries will be linked into the image. Maybe I'm missing some use case, though. -- Kevin On 7/26/2018 2:46 AM, Johan Vos wrote: > Hi Steve, > > That looks like a bug. The libPrefix and libSuffix are indeed not set in > cases where usingModules is true, which is only the case when the jrt > protocol is used. > It seems to me the prefix/suffix should always be computed. It doesn't look > right that they are computed inside the loadLibraryFullPath. But it looks > even worse that the "reallib" is calculated based on statements that might > not be reached, where it could have used System.mapLibraryName() > > I'll create an issue and a PR to fix this. > > Thanks for reporting, > > - Johan > > > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda wrote: > >> Hi, >> I created a custom runtime image (windows x64) for my JavaFX application >> and used the OpenJFX 11-ea+19 maven artifacts. >> >> I get the following exception if I try to execute my application: >> >> Graphics Device initialization failed for : d3d, sw >> Error initializing QuantumRenderer: no suitable pipeline found >> java.lang.RuntimeException: java.lang.RuntimeException: Error initializing >> QuantumRenderer: no suitable pipeline found >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) >> at >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) >> at >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >> at >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >> at >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >> at >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >> at >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at >> >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >> Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: >> no suitable pipeline found >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) >> at >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) >> at java.base/java.lang.Thread.run(Thread.java:844) >> Exception in thread "main" java.lang.reflect.InvocationTargetException >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at >> >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >> Caused by: java.lang.RuntimeException: No toolkit found >> at >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) >> at >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >> at >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >> at >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >> at >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >> at >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> ... 5 more >> >> >> -Djavafx.verbose=true shows that JavaFX isn't able to load the native libs >> from the javafx-graphics jar. >> >> >> I debugged the NativeLibLoader and loadLibraryFromResource and >> installLibraryFromResource will be executed which is ok. But the >> *reallib *value for >> all dll's is wrong because of the empty *libSuffix*. >> >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is >> */api-ms-win-core-console-l1-1-0* and not >> */api-ms-win-core-console-l1-1-0.dll* >> >> Is it intentional that *libPrefix *& *libSuffix *will not be set in case of >> the jrt protocol ? >> >> >> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 >> >> >> >> >> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 >> >> >> >> >> Best Regards, >> Steve >> From steve.hruda at gmail.com Fri Jul 27 13:43:59 2018 From: steve.hruda at gmail.com (Steve Hruda) Date: Fri, 27 Jul 2018 15:43:59 +0200 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage In-Reply-To: References: Message-ID: Hi Kevin, at the moment it's not really a use-case. I didn't used the jmods because I test if the maven artifacts could easier our life in case of maintaining different product versions. I love the easy distribution of the maven artifacts across different machines (developers & build servers). But so far I'm not sure if I the maven artifacts bring me a real benefit compared to the jmod's. Off-Topic: I don't know if this discussion already comes up but I didn't found any related answers. Is there a self-defined goal about the compability of versions OpenJFX and the OracleJDK LTS versions? E.g. OpenJFX will be compatible to OracleJDK 11 until the next LTS version of Oracle will be released Best Regards, Steve Kevin Rushforth schrieb am Do., 26. Juli 2018, 14:42: > Hi Steve, > > Seems it will be an easy bug for Johan to fix, but I'm curious about how > you created your custom image. The jmods are more suitable for that > approach, since their purpose is to be used with jlink to create a > custom image, in which case the native libraries will be linked into the > image. Maybe I'm missing some use case, though. > > -- Kevin > > > On 7/26/2018 2:46 AM, Johan Vos wrote: > > Hi Steve, > > > > That looks like a bug. The libPrefix and libSuffix are indeed not set in > > cases where usingModules is true, which is only the case when the jrt > > protocol is used. > > It seems to me the prefix/suffix should always be computed. It doesn't > look > > right that they are computed inside the loadLibraryFullPath. But it looks > > even worse that the "reallib" is calculated based on statements that > might > > not be reached, where it could have used System.mapLibraryName() > > > > I'll create an issue and a PR to fix this. > > > > Thanks for reporting, > > > > - Johan > > > > > > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda > wrote: > > > >> Hi, > >> I created a custom runtime image (windows x64) for my JavaFX application > >> and used the OpenJFX 11-ea+19 maven artifacts. > >> > >> I get the following exception if I try to execute my application: > >> > >> Graphics Device initialization failed for : d3d, sw > >> Error initializing QuantumRenderer: no suitable pipeline found > >> java.lang.RuntimeException: java.lang.RuntimeException: Error > initializing > >> QuantumRenderer: no suitable pipeline found > >> at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) > >> at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) > >> at > >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) > >> at > >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >> at > >> > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >> at > >> > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) > >> at > >> > >> > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) > >> Caused by: java.lang.RuntimeException: Error initializing > QuantumRenderer: > >> no suitable pipeline found > >> at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) > >> at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) > >> at java.base/java.lang.Thread.run(Thread.java:844) > >> Exception in thread "main" java.lang.reflect.InvocationTargetException > >> at > >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >> at > >> > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >> at > >> > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) > >> at > >> > >> > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) > >> Caused by: java.lang.RuntimeException: No toolkit found > >> at > >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) > >> ... 5 more > >> > >> > >> -Djavafx.verbose=true shows that JavaFX isn't able to load the native > libs > >> from the javafx-graphics jar. > >> > >> > >> I debugged the NativeLibLoader and loadLibraryFromResource and > >> installLibraryFromResource will be executed which is ok. But the > >> *reallib *value for > >> all dll's is wrong because of the empty *libSuffix*. > >> > >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is > >> */api-ms-win-core-console-l1-1-0* and not > >> */api-ms-win-core-console-l1-1-0.dll* > >> > >> Is it intentional that *libPrefix *& *libSuffix *will not be set in > case of > >> the jrt protocol ? > >> > >> > >> > https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 > >> > >> > >> > >> > >> > https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 > >> > >> > >> > >> > >> Best Regards, > >> Steve > >> > > Kevin Rushforth schrieb am Do., 26. Juli 2018, 14:42: > Hi Steve, > > Seems it will be an easy bug for Johan to fix, but I'm curious about how > you created your custom image. The jmods are more suitable for that > approach, since their purpose is to be used with jlink to create a > custom image, in which case the native libraries will be linked into the > image. Maybe I'm missing some use case, though. > > -- Kevin > > > On 7/26/2018 2:46 AM, Johan Vos wrote: > > Hi Steve, > > > > That looks like a bug. The libPrefix and libSuffix are indeed not set in > > cases where usingModules is true, which is only the case when the jrt > > protocol is used. > > It seems to me the prefix/suffix should always be computed. It doesn't > look > > right that they are computed inside the loadLibraryFullPath. But it looks > > even worse that the "reallib" is calculated based on statements that > might > > not be reached, where it could have used System.mapLibraryName() > > > > I'll create an issue and a PR to fix this. > > > > Thanks for reporting, > > > > - Johan > > > > > > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda > wrote: > > > >> Hi, > >> I created a custom runtime image (windows x64) for my JavaFX application > >> and used the OpenJFX 11-ea+19 maven artifacts. > >> > >> I get the following exception if I try to execute my application: > >> > >> Graphics Device initialization failed for : d3d, sw > >> Error initializing QuantumRenderer: no suitable pipeline found > >> java.lang.RuntimeException: java.lang.RuntimeException: Error > initializing > >> QuantumRenderer: no suitable pipeline found > >> at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) > >> at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) > >> at > >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) > >> at > >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >> at > >> > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >> at > >> > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) > >> at > >> > >> > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) > >> Caused by: java.lang.RuntimeException: Error initializing > QuantumRenderer: > >> no suitable pipeline found > >> at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) > >> at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) > >> at java.base/java.lang.Thread.run(Thread.java:844) > >> Exception in thread "main" java.lang.reflect.InvocationTargetException > >> at > >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >> at > >> > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >> at > >> > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) > >> at > >> > >> > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) > >> Caused by: java.lang.RuntimeException: No toolkit found > >> at > >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) > >> at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) > >> ... 5 more > >> > >> > >> -Djavafx.verbose=true shows that JavaFX isn't able to load the native > libs > >> from the javafx-graphics jar. > >> > >> > >> I debugged the NativeLibLoader and loadLibraryFromResource and > >> installLibraryFromResource will be executed which is ok. But the > >> *reallib *value for > >> all dll's is wrong because of the empty *libSuffix*. > >> > >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is > >> */api-ms-win-core-console-l1-1-0* and not > >> */api-ms-win-core-console-l1-1-0.dll* > >> > >> Is it intentional that *libPrefix *& *libSuffix *will not be set in > case of > >> the jrt protocol ? > >> > >> > >> > https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 > >> > >> > >> > >> > >> > https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 > >> > >> > >> > >> > >> Best Regards, > >> Steve > >> > > From kevin.rushforth at oracle.com Fri Jul 27 14:12:25 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 Jul 2018 07:12:25 -0700 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage In-Reply-To: References: Message-ID: Hi Steve, > I don't know if this discussion already comes up but I didn't found > any related answers. > Is there a self-defined goal about the compability of versions OpenJFX > and the OracleJDK LTS versions? > E.g. OpenJFX will be compatible to OracleJDK 11 until the next LTS > version of Oracle will be released That's an excellent question. While I might expect OpenJFX 12 to stop running on JDK 10 at some point (JDK 10 is EOLed by JDK 11, and dropping support for it would allow us to get rid of the old swing interop implementation and build logic), having it run on JDK 11 is a requirement: At a minimum we will need to run on the latest released version at any point, since we are no longer bundled. Beyond that, it's up for discussion among the OpenJFX community: I can see value in allowing, say, OpenJFX 13 or 14 to continue to run with JDK 11 LTS, but there is also a cost to doing so, both in terms of testing and also in either avoiding new JDK features or using reflection or other techniques to optionally use them. What do others think? -- Kevin On 7/27/2018 6:43 AM, Steve Hruda wrote: > Hi Kevin, > at the moment it's not really a use-case. I didn't used the jmods > because I test if the maven artifacts could easier our life in case of > maintaining different product versions. > I love the easy distribution of the maven artifacts across different > machines (developers & build servers). > > But so far I'm?not sure if I the maven artifacts bring me a real > benefit compared to the jmod's. > > Off-Topic: > I don't know if this discussion already comes up but I didn't found > any related answers. > Is there a self-defined goal about the compability of versions OpenJFX > and the OracleJDK LTS versions? > E.g. OpenJFX will be compatible to OracleJDK 11 until the next LTS > version of Oracle will be released > > Best Regards, > Steve > Kevin Rushforth > schrieb am Do., 26. Juli 2018, 14:42: > > Hi Steve, > > Seems it will be an easy bug for Johan to fix, but I'm curious > about how > you created your custom image. The jmods are more suitable for that > approach, since their purpose is to be used with jlink to create a > custom image, in which case the native libraries will be linked > into the > image. Maybe I'm missing some use case, though. > > -- Kevin > > > On 7/26/2018 2:46 AM, Johan Vos wrote: > > Hi Steve, > > > > That looks like a bug. The libPrefix and libSuffix are indeed > not set in > > cases where usingModules is true, which is only the case when > the jrt > > protocol is used. > > It seems to me the prefix/suffix should always be computed. It > doesn't look > > right that they are computed inside the loadLibraryFullPath. But > it looks > > even worse that the "reallib" is calculated based on statements > that might > > not be reached, where it could have used System.mapLibraryName() > > > > I'll create an issue and a PR to fix this. > > > > Thanks for reporting, > > > > - Johan > > > > > > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda > > wrote: > > > >> Hi, > >> I created a custom runtime image (windows x64) for my JavaFX > application > >> and used the OpenJFX 11-ea+19 maven artifacts. > >> > >> I get the following exception if I try to execute my application: > >> > >> Graphics Device initialization failed for : d3d, sw > >> Error initializing QuantumRenderer: no suitable pipeline found > >> java.lang.RuntimeException: java.lang.RuntimeException: Error > initializing > >> QuantumRenderer: no suitable pipeline found > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) > >>? ? ? ? ? at > >> > javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) > >>? ? ? ? ? at > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >>? ? ? ? ? at > >> > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >>? ? ? ? ? at > >> > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >>? ? ? ? ? at > java.base/java.lang.reflect.Method.invoke(Method.java:564) > >>? ? ? ? ? at > >> > >> > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) > >> Caused by: java.lang.RuntimeException: Error initializing > QuantumRenderer: > >> no suitable pipeline found > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) > >>? ? ? ? ? at java.base/java.lang.Thread.run(Thread.java:844) > >> Exception in thread "main" > java.lang.reflect.InvocationTargetException > >>? ? ? ? ? at > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >>? ? ? ? ? at > >> > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >>? ? ? ? ? at > >> > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >>? ? ? ? ? at > java.base/java.lang.reflect.Method.invoke(Method.java:564) > >>? ? ? ? ? at > >> > >> > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) > >> Caused by: java.lang.RuntimeException: No toolkit found > >>? ? ? ? ? at > >> > javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) > >>? ? ? ? ? ... 5 more > >> > >> > >> -Djavafx.verbose=true shows that JavaFX isn't able to load the > native libs > >> from the javafx-graphics jar. > >> > >> > >> I debugged the NativeLibLoader and loadLibraryFromResource and > >> installLibraryFromResource will be executed which is ok. But the > >> *reallib *value for > >> all dll's is wrong because of the empty *libSuffix*. > >> > >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is > >> */api-ms-win-core-console-l1-1-0* and not > >> */api-ms-win-core-console-l1-1-0.dll* > >> > >> Is it intentional that *libPrefix *& *libSuffix *will not be > set in case of > >> the jrt protocol ? > >> > >> > >> > https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 > >> > >> > >> > >> > >> > https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 > >> > >> > >> > >> > >> Best Regards, > >> Steve > >> > > > Kevin Rushforth > schrieb am Do., 26. Juli 2018, 14:42: > > Hi Steve, > > Seems it will be an easy bug for Johan to fix, but I'm curious > about how > you created your custom image. The jmods are more suitable for that > approach, since their purpose is to be used with jlink to create a > custom image, in which case the native libraries will be linked > into the > image. Maybe I'm missing some use case, though. > > -- Kevin > > > On 7/26/2018 2:46 AM, Johan Vos wrote: > > Hi Steve, > > > > That looks like a bug. The libPrefix and libSuffix are indeed > not set in > > cases where usingModules is true, which is only the case when > the jrt > > protocol is used. > > It seems to me the prefix/suffix should always be computed. It > doesn't look > > right that they are computed inside the loadLibraryFullPath. But > it looks > > even worse that the "reallib" is calculated based on statements > that might > > not be reached, where it could have used System.mapLibraryName() > > > > I'll create an issue and a PR to fix this. > > > > Thanks for reporting, > > > > - Johan > > > > > > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda > > wrote: > > > >> Hi, > >> I created a custom runtime image (windows x64) for my JavaFX > application > >> and used the OpenJFX 11-ea+19 maven artifacts. > >> > >> I get the following exception if I try to execute my application: > >> > >> Graphics Device initialization failed for :? d3d, sw > >> Error initializing QuantumRenderer: no suitable pipeline found > >> java.lang.RuntimeException: java.lang.RuntimeException: Error > initializing > >> QuantumRenderer: no suitable pipeline found > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) > >>? ? ? ? ? at > >> > javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) > >>? ? ? ? ? at > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >>? ? ? ? ? at > >> > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >>? ? ? ? ? at > >> > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >>? ? ? ? ? at > java.base/java.lang.reflect.Method.invoke(Method.java:564) > >>? ? ? ? ? at > >> > >> > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) > >> Caused by: java.lang.RuntimeException: Error initializing > QuantumRenderer: > >> no suitable pipeline found > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) > >>? ? ? ? ? at java.base/java.lang.Thread.run(Thread.java:844) > >> Exception in thread "main" > java.lang.reflect.InvocationTargetException > >>? ? ? ? ? at > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >>? ? ? ? ? at > >> > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >>? ? ? ? ? at > >> > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >>? ? ? ? ? at > java.base/java.lang.reflect.Method.invoke(Method.java:564) > >>? ? ? ? ? at > >> > >> > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) > >> Caused by: java.lang.RuntimeException: No toolkit found > >>? ? ? ? ? at > >> > javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) > >>? ? ? ? ? at > >> > >> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) > >>? ? ? ? ? ... 5 more > >> > >> > >> -Djavafx.verbose=true shows that JavaFX isn't able to load the > native libs > >> from the javafx-graphics jar. > >> > >> > >> I debugged the NativeLibLoader and loadLibraryFromResource and > >> installLibraryFromResource will be executed which is ok. But the > >> *reallib *value for > >> all dll's is wrong because of the empty *libSuffix*. > >> > >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is > >> */api-ms-win-core-console-l1-1-0* and not > >> */api-ms-win-core-console-l1-1-0.dll* > >> > >> Is it intentional that *libPrefix *& *libSuffix *will not be > set in case of > >> the jrt protocol ? > >> > >> > >> > https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 > >> > >> > >> > >> > >> > https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 > >> > >> > >> > >> > >> Best Regards, > >> Steve > >> > From johan.vos at gluonhq.com Fri Jul 27 14:35:46 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 27 Jul 2018 16:35:46 +0200 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage In-Reply-To: References: Message-ID: I think we have to distinguish between the technical work done by OpenJFX and the distributions/support offered by companies; similar to the technical work in OpenJDK and the distributions/support offered by Oracle and others. The technical work done here should imo be able to use all functionality offered by the latest released JDK (11/12/...) I don't think there is a good reason on why the head-development of OpenJFX can not use the latest JDK release. If developers/companies want to switch to the latest and greatest OpenJFX release, they can also upgrade to the latest released OpenJDK. And if there are company rules preventing this, well, that is a reason to consider commercial support. I don't like to use my commercial hat in this list, but this is why we have JavaFX Enterprise support with Gluon: https://gluonhq.com/commercial-support-for-javafx/ Also, not that it is relevant on this list, but the revenues from commercial enterprise support allow us to spend resources on working on OpenJFX. - Johan On Fri, Jul 27, 2018 at 4:12 PM Kevin Rushforth wrote: > Hi Steve, > > > I don't know if this discussion already comes up but I didn't found any > related answers. > Is there a self-defined goal about the compability of versions OpenJFX and > the OracleJDK LTS versions? > E.g. OpenJFX will be compatible to OracleJDK 11 until the next LTS version > of Oracle will be released > > > That's an excellent question. While I might expect OpenJFX 12 to stop > running on JDK 10 at some point (JDK 10 is EOLed by JDK 11, and dropping > support for it would allow us to get rid of the old swing interop > implementation and build logic), having it run on JDK 11 is a requirement: > At a minimum we will need to run on the latest released version at any > point, since we are no longer bundled. Beyond that, it's up for discussion > among the OpenJFX community: I can see value in allowing, say, OpenJFX 13 > or 14 to continue to run with JDK 11 LTS, but there is also a cost to doing > so, both in terms of testing and also in either avoiding new JDK features > or using reflection or other techniques to optionally use them. > > What do others think? > > > -- Kevin > > > > On 7/27/2018 6:43 AM, Steve Hruda wrote: > > Hi Kevin, > at the moment it's not really a use-case. I didn't used the jmods because > I test if the maven artifacts could easier our life in case of maintaining > different product versions. > I love the easy distribution of the maven artifacts across different > machines (developers & build servers). > > But so far I'm not sure if I the maven artifacts bring me a real benefit > compared to the jmod's. > > Off-Topic: > I don't know if this discussion already comes up but I didn't found any > related answers. > Is there a self-defined goal about the compability of versions OpenJFX and > the OracleJDK LTS versions? > E.g. OpenJFX will be compatible to OracleJDK 11 until the next LTS version > of Oracle will be released > > Best Regards, > Steve > Kevin Rushforth schrieb am Do., 26. Juli > 2018, 14:42: > >> Hi Steve, >> >> Seems it will be an easy bug for Johan to fix, but I'm curious about how >> you created your custom image. The jmods are more suitable for that >> approach, since their purpose is to be used with jlink to create a >> custom image, in which case the native libraries will be linked into the >> image. Maybe I'm missing some use case, though. >> >> -- Kevin >> >> >> On 7/26/2018 2:46 AM, Johan Vos wrote: >> > Hi Steve, >> > >> > That looks like a bug. The libPrefix and libSuffix are indeed not set in >> > cases where usingModules is true, which is only the case when the jrt >> > protocol is used. >> > It seems to me the prefix/suffix should always be computed. It doesn't >> look >> > right that they are computed inside the loadLibraryFullPath. But it >> looks >> > even worse that the "reallib" is calculated based on statements that >> might >> > not be reached, where it could have used System.mapLibraryName() >> > >> > I'll create an issue and a PR to fix this. >> > >> > Thanks for reporting, >> > >> > - Johan >> > >> > >> > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda >> wrote: >> > >> >> Hi, >> >> I created a custom runtime image (windows x64) for my JavaFX >> application >> >> and used the OpenJFX 11-ea+19 maven artifacts. >> >> >> >> I get the following exception if I try to execute my application: >> >> >> >> Graphics Device initialization failed for : d3d, sw >> >> Error initializing QuantumRenderer: no suitable pipeline found >> >> java.lang.RuntimeException: java.lang.RuntimeException: Error >> initializing >> >> QuantumRenderer: no suitable pipeline found >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) >> >> at >> >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> >> at >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> >> Method) >> >> at >> >> >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >> at >> >> >> >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> >> at >> >> >> >> >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >> >> Caused by: java.lang.RuntimeException: Error initializing >> QuantumRenderer: >> >> no suitable pipeline found >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) >> >> at java.base/java.lang.Thread.run(Thread.java:844) >> >> Exception in thread "main" java.lang.reflect.InvocationTargetException >> >> at >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> >> Method) >> >> at >> >> >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >> at >> >> >> >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> >> at >> >> >> >> >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >> >> Caused by: java.lang.RuntimeException: No toolkit found >> >> at >> >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> >> ... 5 more >> >> >> >> >> >> -Djavafx.verbose=true shows that JavaFX isn't able to load the native >> libs >> >> from the javafx-graphics jar. >> >> >> >> >> >> I debugged the NativeLibLoader and loadLibraryFromResource and >> >> installLibraryFromResource will be executed which is ok. But the >> >> *reallib *value for >> >> all dll's is wrong because of the empty *libSuffix*. >> >> >> >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is >> >> */api-ms-win-core-console-l1-1-0* and not >> >> */api-ms-win-core-console-l1-1-0.dll* >> >> >> >> Is it intentional that *libPrefix *& *libSuffix *will not be set in >> case of >> >> the jrt protocol ? >> >> >> >> >> >> >> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 >> >> >> >> >> >> >> >> >> >> >> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 >> >> >> >> >> >> >> >> >> >> Best Regards, >> >> Steve >> >> >> >> > Kevin Rushforth schrieb am Do., 26. Juli > 2018, 14:42: > >> Hi Steve, >> >> Seems it will be an easy bug for Johan to fix, but I'm curious about how >> you created your custom image. The jmods are more suitable for that >> approach, since their purpose is to be used with jlink to create a >> custom image, in which case the native libraries will be linked into the >> image. Maybe I'm missing some use case, though. >> >> -- Kevin >> >> >> On 7/26/2018 2:46 AM, Johan Vos wrote: >> > Hi Steve, >> > >> > That looks like a bug. The libPrefix and libSuffix are indeed not set in >> > cases where usingModules is true, which is only the case when the jrt >> > protocol is used. >> > It seems to me the prefix/suffix should always be computed. It doesn't >> look >> > right that they are computed inside the loadLibraryFullPath. But it >> looks >> > even worse that the "reallib" is calculated based on statements that >> might >> > not be reached, where it could have used System.mapLibraryName() >> > >> > I'll create an issue and a PR to fix this. >> > >> > Thanks for reporting, >> > >> > - Johan >> > >> > >> > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda >> wrote: >> > >> >> Hi, >> >> I created a custom runtime image (windows x64) for my JavaFX >> application >> >> and used the OpenJFX 11-ea+19 maven artifacts. >> >> >> >> I get the following exception if I try to execute my application: >> >> >> >> Graphics Device initialization failed for : d3d, sw >> >> Error initializing QuantumRenderer: no suitable pipeline found >> >> java.lang.RuntimeException: java.lang.RuntimeException: Error >> initializing >> >> QuantumRenderer: no suitable pipeline found >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) >> >> at >> >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> >> at >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> >> Method) >> >> at >> >> >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >> at >> >> >> >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> >> at >> >> >> >> >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >> >> Caused by: java.lang.RuntimeException: Error initializing >> QuantumRenderer: >> >> no suitable pipeline found >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) >> >> at java.base/java.lang.Thread.run(Thread.java:844) >> >> Exception in thread "main" java.lang.reflect.InvocationTargetException >> >> at >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> >> Method) >> >> at >> >> >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >> at >> >> >> >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> >> at >> >> >> >> >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >> >> Caused by: java.lang.RuntimeException: No toolkit found >> >> at >> >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >> >> at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> >> ... 5 more >> >> >> >> >> >> -Djavafx.verbose=true shows that JavaFX isn't able to load the native >> libs >> >> from the javafx-graphics jar. >> >> >> >> >> >> I debugged the NativeLibLoader and loadLibraryFromResource and >> >> installLibraryFromResource will be executed which is ok. But the >> >> *reallib *value for >> >> all dll's is wrong because of the empty *libSuffix*. >> >> >> >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is >> >> */api-ms-win-core-console-l1-1-0* and not >> >> */api-ms-win-core-console-l1-1-0.dll* >> >> >> >> Is it intentional that *libPrefix *& *libSuffix *will not be set in >> case of >> >> the jrt protocol ? >> >> >> >> >> >> >> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 >> >> >> >> >> >> >> >> >> >> >> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 >> >> >> >> >> >> >> >> >> >> Best Regards, >> >> Steve >> >> >> >> > From kevin.rushforth at oracle.com Fri Jul 27 14:49:03 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 Jul 2018 07:49:03 -0700 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage In-Reply-To: References: Message-ID: Those are all excellent points. This suggests we might want to adopt a general policy of "the current OpenJFX dev works with the latest released OpenJDK plus the current OpenJDK under development" is the better way to go. Otherwise it will be several years before OpenJFX can adopt, say, a new JDK 12 or JDK 13 feature. I note that this matches the model and spirit of the OpenJDK development. If you want to get the latest and greatest features, use the latest feature release. If you want stability, use a supported LTS release. Makes sense to me. -- Kevin On 7/27/2018 7:35 AM, Johan Vos wrote: > I think we have to distinguish between the technical work done by > OpenJFX and the distributions/support offered by companies; similar to > the technical work in OpenJDK and the distributions/support offered by > Oracle and others. > > The technical work done here should imo be able to use all > functionality offered by the latest released JDK (11/12/...) > > I don't think there is a good reason on why the head-development of > OpenJFX can not use the latest JDK release. If developers/companies > want to switch to the latest and greatest OpenJFX release, they can > also upgrade to the latest released OpenJDK. > > And if there are company rules preventing this, well, that is a reason > to consider commercial support. > I don't like to use my commercial hat in this list, but this is why we > have JavaFX Enterprise support with Gluon: > https://gluonhq.com/commercial-support-for-javafx/ > Also, not that it is relevant on this list, but the revenues from > commercial enterprise support allow us to spend resources on working > on OpenJFX. > > - Johan > > On Fri, Jul 27, 2018 at 4:12 PM Kevin Rushforth > > wrote: > > Hi Steve, > > >> I don't know if this discussion already comes up but I didn't >> found any related answers. >> Is there a self-defined goal about the compability of versions >> OpenJFX and the OracleJDK LTS versions? >> E.g. OpenJFX will be compatible to OracleJDK 11 until the next >> LTS version of Oracle will be released > > That's an excellent question. While I might expect OpenJFX 12 to > stop running on JDK 10 at some point (JDK 10 is EOLed by JDK 11, > and dropping support for it would allow us to get rid of the old > swing interop implementation and build logic), having it run on > JDK 11 is a requirement: At a minimum we will need to run on the > latest released version at any point, since we are no longer > bundled. Beyond that, it's up for discussion among the OpenJFX > community: I can see value in allowing, say, OpenJFX 13 or 14 to > continue to run with JDK 11 LTS, but there is also a cost to doing > so, both in terms of testing and also in either avoiding new JDK > features or using reflection or other techniques to optionally use > them. > > What do others think? > > > -- Kevin > > > > On 7/27/2018 6:43 AM, Steve Hruda wrote: >> Hi Kevin, >> at the moment it's not really a use-case. I didn't used the jmods >> because I test if the maven artifacts could easier our life in >> case of maintaining different product versions. >> I love the easy distribution of the maven artifacts across >> different machines (developers & build servers). >> >> But so far I'm?not sure if I the maven artifacts bring me a real >> benefit compared to the jmod's. >> >> Off-Topic: >> I don't know if this discussion already comes up but I didn't >> found any related answers. >> Is there a self-defined goal about the compability of versions >> OpenJFX and the OracleJDK LTS versions? >> E.g. OpenJFX will be compatible to OracleJDK 11 until the next >> LTS version of Oracle will be released >> >> Best Regards, >> Steve >> Kevin Rushforth > > schrieb am Do., 26. Juli >> 2018, 14:42: >> >> Hi Steve, >> >> Seems it will be an easy bug for Johan to fix, but I'm >> curious about how >> you created your custom image. The jmods are more suitable >> for that >> approach, since their purpose is to be used with jlink to >> create a >> custom image, in which case the native libraries will be >> linked into the >> image. Maybe I'm missing some use case, though. >> >> -- Kevin >> >> >> On 7/26/2018 2:46 AM, Johan Vos wrote: >> > Hi Steve, >> > >> > That looks like a bug. The libPrefix and libSuffix are >> indeed not set in >> > cases where usingModules is true, which is only the case >> when the jrt >> > protocol is used. >> > It seems to me the prefix/suffix should always be computed. >> It doesn't look >> > right that they are computed inside the >> loadLibraryFullPath. But it looks >> > even worse that the "reallib" is calculated based on >> statements that might >> > not be reached, where it could have used >> System.mapLibraryName() >> > >> > I'll create an issue and a PR to fix this. >> > >> > Thanks for reporting, >> > >> > - Johan >> > >> > >> > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda >> > wrote: >> > >> >> Hi, >> >> I created a custom runtime image (windows x64) for my >> JavaFX application >> >> and used the OpenJFX 11-ea+19 maven artifacts. >> >> >> >> I get the following exception if I try to execute my >> application: >> >> >> >> Graphics Device initialization failed for :? d3d, sw >> >> Error initializing QuantumRenderer: no suitable pipeline found >> >> java.lang.RuntimeException: java.lang.RuntimeException: >> Error initializing >> >> QuantumRenderer: no suitable pipeline found >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) >> >>? ? ? ? ? at >> >> >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> >>? ? ? ? ? at >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> >> Method) >> >>? ? ? ? ? at >> >> >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >>? ? ? ? ? at >> >> >> >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >>? ? ? ? ? at >> java.base/java.lang.reflect.Method.invoke(Method.java:564) >> >>? ? ? ? ? at >> >> >> >> >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >> >> Caused by: java.lang.RuntimeException: Error initializing >> QuantumRenderer: >> >> no suitable pipeline found >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) >> >>? ? ? ? ? at java.base/java.lang.Thread.run(Thread.java:844) >> >> Exception in thread "main" >> java.lang.reflect.InvocationTargetException >> >>? ? ? ? ? at >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> >> Method) >> >>? ? ? ? ? at >> >> >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >>? ? ? ? ? at >> >> >> >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >>? ? ? ? ? at >> java.base/java.lang.reflect.Method.invoke(Method.java:564) >> >>? ? ? ? ? at >> >> >> >> >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >> >> Caused by: java.lang.RuntimeException: No toolkit found >> >>? ? ? ? ? at >> >> >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> >>? ? ? ? ? ... 5 more >> >> >> >> >> >> -Djavafx.verbose=true shows that JavaFX isn't able to load >> the native libs >> >> from the javafx-graphics jar. >> >> >> >> >> >> I debugged the NativeLibLoader and loadLibraryFromResource and >> >> installLibraryFromResource will be executed which is ok. >> But the >> >> *reallib *value for >> >> all dll's is wrong because of the empty *libSuffix*. >> >> >> >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is >> >> */api-ms-win-core-console-l1-1-0* and not >> >> */api-ms-win-core-console-l1-1-0.dll* >> >> >> >> Is it intentional that *libPrefix *& *libSuffix *will not >> be set in case of >> >> the jrt protocol ? >> >> >> >> >> >> >> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 >> >> >> >> >> >> >> >> >> >> >> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 >> >> >> >> >> >> >> >> >> >> Best Regards, >> >> Steve >> >> >> >> >> Kevin Rushforth > > schrieb am Do., 26. Juli >> 2018, 14:42: >> >> Hi Steve, >> >> Seems it will be an easy bug for Johan to fix, but I'm >> curious about how >> you created your custom image. The jmods are more suitable >> for that >> approach, since their purpose is to be used with jlink to >> create a >> custom image, in which case the native libraries will be >> linked into the >> image. Maybe I'm missing some use case, though. >> >> -- Kevin >> >> >> On 7/26/2018 2:46 AM, Johan Vos wrote: >> > Hi Steve, >> > >> > That looks like a bug. The libPrefix and libSuffix are >> indeed not set in >> > cases where usingModules is true, which is only the case >> when the jrt >> > protocol is used. >> > It seems to me the prefix/suffix should always be computed. >> It doesn't look >> > right that they are computed inside the >> loadLibraryFullPath. But it looks >> > even worse that the "reallib" is calculated based on >> statements that might >> > not be reached, where it could have used >> System.mapLibraryName() >> > >> > I'll create an issue and a PR to fix this. >> > >> > Thanks for reporting, >> > >> > - Johan >> > >> > >> > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda >> > wrote: >> > >> >> Hi, >> >> I created a custom runtime image (windows x64) for my >> JavaFX application >> >> and used the OpenJFX 11-ea+19 maven artifacts. >> >> >> >> I get the following exception if I try to execute my >> application: >> >> >> >> Graphics Device initialization failed for :? d3d, sw >> >> Error initializing QuantumRenderer: no suitable pipeline found >> >> java.lang.RuntimeException: java.lang.RuntimeException: >> Error initializing >> >> QuantumRenderer: no suitable pipeline found >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) >> >>? ? ? ? ? at >> >> >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> >>? ? ? ? ? at >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> >> Method) >> >>? ? ? ? ? at >> >> >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >>? ? ? ? ? at >> >> >> >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >>? ? ? ? ? at >> java.base/java.lang.reflect.Method.invoke(Method.java:564) >> >>? ? ? ? ? at >> >> >> >> >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >> >> Caused by: java.lang.RuntimeException: Error initializing >> QuantumRenderer: >> >> no suitable pipeline found >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) >> >>? ? ? ? ? at java.base/java.lang.Thread.run(Thread.java:844) >> >> Exception in thread "main" >> java.lang.reflect.InvocationTargetException >> >>? ? ? ? ? at >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> >> Method) >> >>? ? ? ? ? at >> >> >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >>? ? ? ? ? at >> >> >> >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >>? ? ? ? ? at >> java.base/java.lang.reflect.Method.invoke(Method.java:564) >> >>? ? ? ? ? at >> >> >> >> >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >> >> Caused by: java.lang.RuntimeException: No toolkit found >> >>? ? ? ? ? at >> >> >> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >> >>? ? ? ? ? at >> >> >> >> >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> >>? ? ? ? ? ... 5 more >> >> >> >> >> >> -Djavafx.verbose=true shows that JavaFX isn't able to load >> the native libs >> >> from the javafx-graphics jar. >> >> >> >> >> >> I debugged the NativeLibLoader and loadLibraryFromResource and >> >> installLibraryFromResource will be executed which is ok. >> But the >> >> *reallib *value for >> >> all dll's is wrong because of the empty *libSuffix*. >> >> >> >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is >> >> */api-ms-win-core-console-l1-1-0* and not >> >> */api-ms-win-core-console-l1-1-0.dll* >> >> >> >> Is it intentional that *libPrefix *& *libSuffix *will not >> be set in case of >> >> the jrt protocol ? >> >> >> >> >> >> >> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 >> >> >> >> >> >> >> >> >> >> >> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 >> >> >> >> >> >> >> >> >> >> Best Regards, >> >> Steve >> >> >> > From swpalmer at gmail.com Fri Jul 27 15:07:00 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 27 Jul 2018 11:07:00 -0400 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage In-Reply-To: References: Message-ID: > On Jul 27, 2018, at 10:49 AM, Kevin Rushforth wrote: > > Those are all excellent points. This suggests we might want to adopt a general policy of "the current OpenJFX dev works with the latest released OpenJDK plus the current OpenJDK under development" is the better way to go. Otherwise it will be several years before OpenJFX can adopt, say, a new JDK 12 or JDK 13 feature. > > I note that this matches the model and spirit of the OpenJDK development. If you want to get the latest and greatest features, use the latest feature release. If you want stability, use a supported LTS release. Makes sense to me. Which can be much easier said than done. I generally like to live near the bleeding edge? I *want to switch*, but we are still stuck on Java 8 (like I suspect most companies are) because of the very significant development effort to move to Java 9 or beyond. Java 9 module's access controls were one thing, Java 11?s removal of some modules and development tools further broke the world. Not to mention that good module support in the tool chain is still not available. We are waiting for the dust to settle, we need to wait for many dependencies and tools to catch up and become Java 11 compatible, then we have to try to migrate our own code and hope that all the dependency upgrades didn?t break things. Basically we won?t even be able to start to migrate our code beyond Java 8 until next year (when Java 8 LTS ends). I?ve already spent days trying to get code to build with Java 11 (unsuccessfully). It?s the first time in the history of Java that I haven?t been able to upgrade the JRE with trivial effort. Usually the only thing holding me back was waiting for Proguard to support the new class version. (And I could at least develop and test without obfuscation until it was ready.) I am hoping that once we make the leap from Java 8 to Java 11, that further updates will be less painful. If so, then I could agree that the latest OpenJFX can use the latest released JRE. Unless you want to maintain a LTS release of OpenJFX in addition to the ?current? version? Scott > > -- Kevin > > > On 7/27/2018 7:35 AM, Johan Vos wrote: >> I think we have to distinguish between the technical work done by OpenJFX and the distributions/support offered by companies; similar to the technical work in OpenJDK and the distributions/support offered by Oracle and others. >> >> The technical work done here should imo be able to use all functionality offered by the latest released JDK (11/12/...) >> >> I don't think there is a good reason on why the head-development of OpenJFX can not use the latest JDK release. If developers/companies want to switch to the latest and greatest OpenJFX release, they can also upgrade to the latest released OpenJDK. >> >> And if there are company rules preventing this, well, that is a reason to consider commercial support. >> I don't like to use my commercial hat in this list, but this is why we have JavaFX Enterprise support with Gluon: https://gluonhq.com/commercial-support-for-javafx/ >> Also, not that it is relevant on this list, but the revenues from commercial enterprise support allow us to spend resources on working on OpenJFX. >> >> - Johan >> >> On Fri, Jul 27, 2018 at 4:12 PM Kevin Rushforth >> wrote: >> >> Hi Steve, >> >> >>> I don't know if this discussion already comes up but I didn't >>> found any related answers. >>> Is there a self-defined goal about the compability of versions >>> OpenJFX and the OracleJDK LTS versions? >>> E.g. OpenJFX will be compatible to OracleJDK 11 until the next >>> LTS version of Oracle will be released >> >> That's an excellent question. While I might expect OpenJFX 12 to >> stop running on JDK 10 at some point (JDK 10 is EOLed by JDK 11, >> and dropping support for it would allow us to get rid of the old >> swing interop implementation and build logic), having it run on >> JDK 11 is a requirement: At a minimum we will need to run on the >> latest released version at any point, since we are no longer >> bundled. Beyond that, it's up for discussion among the OpenJFX >> community: I can see value in allowing, say, OpenJFX 13 or 14 to >> continue to run with JDK 11 LTS, but there is also a cost to doing >> so, both in terms of testing and also in either avoiding new JDK >> features or using reflection or other techniques to optionally use >> them. >> >> What do others think? >> >> >> -- Kevin >> >> >> >> On 7/27/2018 6:43 AM, Steve Hruda wrote: >>> Hi Kevin, >>> at the moment it's not really a use-case. I didn't used the jmods >>> because I test if the maven artifacts could easier our life in >>> case of maintaining different product versions. >>> I love the easy distribution of the maven artifacts across >>> different machines (developers & build servers). >>> >>> But so far I'm not sure if I the maven artifacts bring me a real >>> benefit compared to the jmod's. >>> >>> Off-Topic: >>> I don't know if this discussion already comes up but I didn't >>> found any related answers. >>> Is there a self-defined goal about the compability of versions >>> OpenJFX and the OracleJDK LTS versions? >>> E.g. OpenJFX will be compatible to OracleJDK 11 until the next >>> LTS version of Oracle will be released >>> >>> Best Regards, >>> Steve >>> Kevin Rushforth >>> >> schrieb am Do., 26. Juli >>> 2018, 14:42: >>> >>> Hi Steve, >>> >>> Seems it will be an easy bug for Johan to fix, but I'm >>> curious about how >>> you created your custom image. The jmods are more suitable >>> for that >>> approach, since their purpose is to be used with jlink to >>> create a >>> custom image, in which case the native libraries will be >>> linked into the >>> image. Maybe I'm missing some use case, though. >>> >>> -- Kevin >>> >>> >>> On 7/26/2018 2:46 AM, Johan Vos wrote: >>> > Hi Steve, >>> > >>> > That looks like a bug. The libPrefix and libSuffix are >>> indeed not set in >>> > cases where usingModules is true, which is only the case >>> when the jrt >>> > protocol is used. >>> > It seems to me the prefix/suffix should always be computed. >>> It doesn't look >>> > right that they are computed inside the >>> loadLibraryFullPath. But it looks >>> > even worse that the "reallib" is calculated based on >>> statements that might >>> > not be reached, where it could have used >>> System.mapLibraryName() >>> > >>> > I'll create an issue and a PR to fix this. >>> > >>> > Thanks for reporting, >>> > >>> > - Johan >>> > >>> > >>> > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda >>> >> wrote: >>> > >>> >> Hi, >>> >> I created a custom runtime image (windows x64) for my >>> JavaFX application >>> >> and used the OpenJFX 11-ea+19 maven artifacts. >>> >> >>> >> I get the following exception if I try to execute my >>> application: >>> >> >>> >> Graphics Device initialization failed for : d3d, sw >>> >> Error initializing QuantumRenderer: no suitable pipeline found >>> >> java.lang.RuntimeException: java.lang.RuntimeException: >>> Error initializing >>> >> QuantumRenderer: no suitable pipeline found >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) >>> >> at >>> >> >>> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >>> >> at >>> >> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> >> Method) >>> >> at >>> >> >>> >> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> >> at >>> >> >>> >> >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >> at >>> java.base/java.lang.reflect.Method.invoke(Method.java:564) >>> >> at >>> >> >>> >> >>> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >>> >> Caused by: java.lang.RuntimeException: Error initializing >>> QuantumRenderer: >>> >> no suitable pipeline found >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) >>> >> at java.base/java.lang.Thread.run(Thread.java:844) >>> >> Exception in thread "main" >>> java.lang.reflect.InvocationTargetException >>> >> at >>> >> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> >> Method) >>> >> at >>> >> >>> >> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> >> at >>> >> >>> >> >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >> at >>> java.base/java.lang.reflect.Method.invoke(Method.java:564) >>> >> at >>> >> >>> >> >>> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >>> >> Caused by: java.lang.RuntimeException: No toolkit found >>> >> at >>> >> >>> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >>> >> ... 5 more >>> >> >>> >> >>> >> -Djavafx.verbose=true shows that JavaFX isn't able to load >>> the native libs >>> >> from the javafx-graphics jar. >>> >> >>> >> >>> >> I debugged the NativeLibLoader and loadLibraryFromResource and >>> >> installLibraryFromResource will be executed which is ok. >>> But the >>> >> *reallib *value for >>> >> all dll's is wrong because of the empty *libSuffix*. >>> >> >>> >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is >>> >> */api-ms-win-core-console-l1-1-0* and not >>> >> */api-ms-win-core-console-l1-1-0.dll* >>> >> >>> >> Is it intentional that *libPrefix *& *libSuffix *will not >>> be set in case of >>> >> the jrt protocol ? >>> >> >>> >> >>> >> >>> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 >>> >> >>> >> >>> >> >>> >> >>> >> >>> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 >>> >> >>> >> >>> >> >>> >> >>> >> Best Regards, >>> >> Steve >>> >> >>> >>> >>> Kevin Rushforth >>> >> schrieb am Do., 26. Juli >>> 2018, 14:42: >>> >>> Hi Steve, >>> >>> Seems it will be an easy bug for Johan to fix, but I'm >>> curious about how >>> you created your custom image. The jmods are more suitable >>> for that >>> approach, since their purpose is to be used with jlink to >>> create a >>> custom image, in which case the native libraries will be >>> linked into the >>> image. Maybe I'm missing some use case, though. >>> >>> -- Kevin >>> >>> >>> On 7/26/2018 2:46 AM, Johan Vos wrote: >>> > Hi Steve, >>> > >>> > That looks like a bug. The libPrefix and libSuffix are >>> indeed not set in >>> > cases where usingModules is true, which is only the case >>> when the jrt >>> > protocol is used. >>> > It seems to me the prefix/suffix should always be computed. >>> It doesn't look >>> > right that they are computed inside the >>> loadLibraryFullPath. But it looks >>> > even worse that the "reallib" is calculated based on >>> statements that might >>> > not be reached, where it could have used >>> System.mapLibraryName() >>> > >>> > I'll create an issue and a PR to fix this. >>> > >>> > Thanks for reporting, >>> > >>> > - Johan >>> > >>> > >>> > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda >>> >> wrote: >>> > >>> >> Hi, >>> >> I created a custom runtime image (windows x64) for my >>> JavaFX application >>> >> and used the OpenJFX 11-ea+19 maven artifacts. >>> >> >>> >> I get the following exception if I try to execute my >>> application: >>> >> >>> >> Graphics Device initialization failed for : d3d, sw >>> >> Error initializing QuantumRenderer: no suitable pipeline found >>> >> java.lang.RuntimeException: java.lang.RuntimeException: >>> Error initializing >>> >> QuantumRenderer: no suitable pipeline found >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) >>> >> at >>> >> >>> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >>> >> at >>> >> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> >> Method) >>> >> at >>> >> >>> >> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> >> at >>> >> >>> >> >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >> at >>> java.base/java.lang.reflect.Method.invoke(Method.java:564) >>> >> at >>> >> >>> >> >>> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >>> >> Caused by: java.lang.RuntimeException: Error initializing >>> QuantumRenderer: >>> >> no suitable pipeline found >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) >>> >> at java.base/java.lang.Thread.run(Thread.java:844) >>> >> Exception in thread "main" >>> java.lang.reflect.InvocationTargetException >>> >> at >>> >> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> >> Method) >>> >> at >>> >> >>> >> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> >> at >>> >> >>> >> >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >> at >>> java.base/java.lang.reflect.Method.invoke(Method.java:564) >>> >> at >>> >> >>> >> >>> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >>> >> Caused by: java.lang.RuntimeException: No toolkit found >>> >> at >>> >> >>> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >>> >> at >>> >> >>> >> >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >>> >> ... 5 more >>> >> >>> >> >>> >> -Djavafx.verbose=true shows that JavaFX isn't able to load >>> the native libs >>> >> from the javafx-graphics jar. >>> >> >>> >> >>> >> I debugged the NativeLibLoader and loadLibraryFromResource and >>> >> installLibraryFromResource will be executed which is ok. >>> But the >>> >> *reallib *value for >>> >> all dll's is wrong because of the empty *libSuffix*. >>> >> >>> >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is >>> >> */api-ms-win-core-console-l1-1-0* and not >>> >> */api-ms-win-core-console-l1-1-0.dll* >>> >> >>> >> Is it intentional that *libPrefix *& *libSuffix *will not >>> be set in case of >>> >> the jrt protocol ? >>> >> >>> >> >>> >> >>> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 >>> >> >>> >> >>> >> >>> >> >>> >> >>> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 >>> >> >>> >> >>> >> >>> >> >>> >> Best Regards, >>> >> Steve >>> >> From kevin.rushforth at oracle.com Fri Jul 27 15:38:25 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 Jul 2018 08:38:25 -0700 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage In-Reply-To: References: Message-ID: <0d078003-0969-9864-acc7-220fb655e535@oracle.com> > Unless you want to maintain a LTS release of OpenJFX in addition to > the ?current? version? I think that's what Johan was talking about with Gluon's "JavaFX Enterprise support". -- Kevin On 7/27/2018 8:07 AM, Scott Palmer wrote: > >> On Jul 27, 2018, at 10:49 AM, Kevin Rushforth >> > wrote: >> >> Those are all excellent points. This suggests we might want to adopt >> a general policy of "the current OpenJFX dev works with the latest >> released OpenJDK plus the current OpenJDK under development" is the >> better way to go. Otherwise it will be several years before OpenJFX >> can adopt, say, a new JDK 12 or JDK 13 feature. >> >> I note that this matches the model and spirit of the OpenJDK >> development. If you want to get the latest and greatest features, use >> the latest feature release. If you want stability, use a supported >> LTS release. Makes sense to me. > > > Which can be much easier said than done. ?I generally like to live > near the bleeding edge? I *want to switch*, but we are still stuck on > Java 8 (like I suspect most companies are) because of the very > significant development effort to move to Java 9 or beyond. ?Java 9 > module's access controls were one thing, Java 11?s removal of some > modules and development tools further broke the world. ?Not to mention > that good module support in the tool chain is still not available. We > are waiting for the dust to settle, we need to wait for many > dependencies and tools to catch up and become Java 11 compatible, then > we have to try to migrate our own code and hope that all the > dependency upgrades didn?t break things. ?Basically we won?t even be > able to start to migrate our code beyond Java 8 until next year (when > Java 8 LTS ends). > > I?ve already spent days trying to get code to build with Java 11 > (unsuccessfully). It?s the first time in the history of Java that I > haven?t been able to upgrade the JRE with trivial effort. ?Usually the > only thing holding me back was waiting for Proguard to support the new > class version. (And I could at least develop and test without > obfuscation until it was ready.) > > I am hoping that once we make the leap from Java 8 to Java 11, that > further updates will be less painful. ?If so, then I could agree that > the latest OpenJFX can use the latest released JRE. > > Unless you want to maintain a LTS release of OpenJFX in addition to > the ?current? version? > > Scott > > >> >> -- Kevin >> >> >> On 7/27/2018 7:35 AM, Johan Vos wrote: >>> I think we have to distinguish between the technical work done by >>> OpenJFX and the distributions/support offered by companies; similar >>> to the technical work in OpenJDK and the distributions/support >>> offered by Oracle and others. >>> >>> The technical work done here should imo be able to use all >>> functionality offered by the latest released JDK (11/12/...) >>> >>> I don't think there is a good reason on why the head-development of >>> OpenJFX can not use the latest JDK release. If developers/companies >>> want to switch to the latest and greatest OpenJFX release, they can >>> also upgrade to the latest released OpenJDK. >>> >>> And if there are company rules preventing this, well, that is a >>> reason to consider commercial support. >>> I don't like to use my commercial hat in this list, but this is why >>> we have JavaFX Enterprise support with Gluon: >>> https://gluonhq.com/commercial-support-for-javafx/ >>> Also, not that it is relevant on this list, but the revenues from >>> commercial enterprise support allow us to spend resources on working >>> on OpenJFX. >>> >>> - Johan >>> >>> On Fri, Jul 27, 2018 at 4:12 PM Kevin Rushforth >>> >> > >>> wrote: >>> >>> ???Hi Steve, >>> >>> >>>> ???I don't know if this discussion already comes up but I didn't >>>> ???found any related answers. >>>> ???Is there a self-defined goal about the compability of versions >>>> ???OpenJFX and the OracleJDK LTS versions? >>>> ???E.g. OpenJFX will be compatible to OracleJDK 11 until the next >>>> ???LTS version of Oracle will be released >>> >>> ???That's an excellent question. While I might expect OpenJFX 12 to >>> ???stop running on JDK 10 at some point (JDK 10 is EOLed by JDK 11, >>> ???and dropping support for it would allow us to get rid of the old >>> ???swing interop implementation and build logic), having it run on >>> ???JDK 11 is a requirement: At a minimum we will need to run on the >>> ???latest released version at any point, since we are no longer >>> ???bundled. Beyond that, it's up for discussion among the OpenJFX >>> ???community: I can see value in allowing, say, OpenJFX 13 or 14 to >>> ???continue to run with JDK 11 LTS, but there is also a cost to doing >>> ???so, both in terms of testing and also in either avoiding new JDK >>> ???features or using reflection or other techniques to optionally use >>> ???them. >>> >>> ???What do others think? >>> >>> >>> ???-- Kevin >>> >>> >>> >>> ???On 7/27/2018 6:43 AM, Steve Hruda wrote: >>>> ???Hi Kevin, >>>> ???at the moment it's not really a use-case. I didn't used the jmods >>>> ???because I test if the maven artifacts could easier our life in >>>> ???case of maintaining different product versions. >>>> ???I love the easy distribution of the maven artifacts across >>>> ???different machines (developers & build servers). >>>> >>>> ???But so far I'm?not sure if I the maven artifacts bring me a real >>>> ???benefit compared to the jmod's. >>>> >>>> ???Off-Topic: >>>> ???I don't know if this discussion already comes up but I didn't >>>> ???found any related answers. >>>> ???Is there a self-defined goal about the compability of versions >>>> ???OpenJFX and the OracleJDK LTS versions? >>>> ???E.g. OpenJFX will be compatible to OracleJDK 11 until the next >>>> ???LTS version of Oracle will be released >>>> >>>> ???Best Regards, >>>> ???Steve >>>> ???Kevin Rushforth >>> >>>> ???> schrieb am Do., 26. Juli >>>> ???2018, 14:42: >>>> >>>> ???????Hi Steve, >>>> >>>> ???????Seems it will be an easy bug for Johan to fix, but I'm >>>> ???????curious about how >>>> ???????you created your custom image. The jmods are more suitable >>>> ???????for that >>>> ???????approach, since their purpose is to be used with jlink to >>>> ???????create a >>>> ???????custom image, in which case the native libraries will be >>>> ???????linked into the >>>> ???????image. Maybe I'm missing some use case, though. >>>> >>>> ???????-- Kevin >>>> >>>> >>>> ???????On 7/26/2018 2:46 AM, Johan Vos wrote: >>>> ???????> Hi Steve, >>>> ???????> >>>> ???????> That looks like a bug. The libPrefix and libSuffix are >>>> ???????indeed not set in >>>> ???????> cases where usingModules is true, which is only the case >>>> ???????when the jrt >>>> ???????> protocol is used. >>>> ???????> It seems to me the prefix/suffix should always be computed. >>>> ???????It doesn't look >>>> ???????> right that they are computed inside the >>>> ???????loadLibraryFullPath. But it looks >>>> ???????> even worse that the "reallib" is calculated based on >>>> ???????statements that might >>>> ???????> not be reached, where it could have used >>>> ???????System.mapLibraryName() >>>> ???????> >>>> ???????> I'll create an issue and a PR to fix this. >>>> ???????> >>>> ???????> Thanks for reporting, >>>> ???????> >>>> ???????> - Johan >>>> ???????> >>>> ???????> >>>> ???????> On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda >>>> ???????>>> > wrote: >>>> ???????> >>>> ???????>> Hi, >>>> ???????>> I created a custom runtime image (windows x64) for my >>>> ???????JavaFX application >>>> ???????>> and used the OpenJFX 11-ea+19 maven artifacts. >>>> ???????>> >>>> ???????>> I get the following exception if I try to execute my >>>> ???????application: >>>> ???????>> >>>> ???????>> Graphics Device initialization failed for :? d3d, sw >>>> ???????>> Error initializing QuantumRenderer: no suitable pipeline >>>> found >>>> ???????>> java.lang.RuntimeException: java.lang.RuntimeException: >>>> ???????Error initializing >>>> ???????>> QuantumRenderer: no suitable pipeline found >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> ???????>> Method) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> ???????>>? ? ? ? ? at >>>> ???????java.base/java.lang.reflect.Method.invoke(Method.java:564) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >>>> ???????>> Caused by: java.lang.RuntimeException: Error initializing >>>> ???????QuantumRenderer: >>>> ???????>> no suitable pipeline found >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) >>>> ???????>>? ? ? ? ? at java.base/java.lang.Thread.run(Thread.java:844) >>>> ???????>> Exception in thread "main" >>>> ???????java.lang.reflect.InvocationTargetException >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> ???????>> Method) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> ???????>>? ? ? ? ? at >>>> ???????java.base/java.lang.reflect.Method.invoke(Method.java:564) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >>>> ???????>> Caused by: java.lang.RuntimeException: No toolkit found >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >>>> ???????>>? ? ? ? ? ... 5 more >>>> ???????>> >>>> ???????>> >>>> ???????>> -Djavafx.verbose=true shows that JavaFX isn't able to load >>>> ???????the native libs >>>> ???????>> from the javafx-graphics jar. >>>> ???????>> >>>> ???????>> >>>> ???????>> I debugged the NativeLibLoader and >>>> loadLibraryFromResource and >>>> ???????>> installLibraryFromResource will be executed which is ok. >>>> ???????But the >>>> ???????>> *reallib *value for >>>> ???????>> all dll's is wrong because of the empty *libSuffix*. >>>> ???????>> >>>> ???????>> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is >>>> ???????>> */api-ms-win-core-console-l1-1-0* and not >>>> ???????>> */api-ms-win-core-console-l1-1-0.dll* >>>> ???????>> >>>> ???????>> Is it intentional that *libPrefix *& *libSuffix *will not >>>> ???????be set in case of >>>> ???????>> the jrt protocol ? >>>> ???????>> >>>> ???????>> >>>> ???????>> >>>> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 >>>> ???????>> >>>> ???????>> >>>> ???????>> >>>> ???????>> >>>> ???????>> >>>> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 >>>> ???????>> >>>> ???????>> >>>> ???????>> >>>> ???????>> >>>> ???????>> Best Regards, >>>> ???????>> Steve >>>> ???????>> >>>> >>>> >>>> ???Kevin Rushforth >>> >>>> ???> schrieb am Do., 26. Juli >>>> ???2018, 14:42: >>>> >>>> ???????Hi Steve, >>>> >>>> ???????Seems it will be an easy bug for Johan to fix, but I'm >>>> ???????curious about how >>>> ???????you created your custom image. The jmods are more suitable >>>> ???????for that >>>> ???????approach, since their purpose is to be used with jlink to >>>> ???????create a >>>> ???????custom image, in which case the native libraries will be >>>> ???????linked into the >>>> ???????image. Maybe I'm missing some use case, though. >>>> >>>> ???????-- Kevin >>>> >>>> >>>> ???????On 7/26/2018 2:46 AM, Johan Vos wrote: >>>> ???????> Hi Steve, >>>> ???????> >>>> ???????> That looks like a bug. The libPrefix and libSuffix are >>>> ???????indeed not set in >>>> ???????> cases where usingModules is true, which is only the case >>>> ???????when the jrt >>>> ???????> protocol is used. >>>> ???????> It seems to me the prefix/suffix should always be computed. >>>> ???????It doesn't look >>>> ???????> right that they are computed inside the >>>> ???????loadLibraryFullPath. But it looks >>>> ???????> even worse that the "reallib" is calculated based on >>>> ???????statements that might >>>> ???????> not be reached, where it could have used >>>> ???????System.mapLibraryName() >>>> ???????> >>>> ???????> I'll create an issue and a PR to fix this. >>>> ???????> >>>> ???????> Thanks for reporting, >>>> ???????> >>>> ???????> - Johan >>>> ???????> >>>> ???????> >>>> ???????> On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda >>>> ???????>>> > wrote: >>>> ???????> >>>> ???????>> Hi, >>>> ???????>> I created a custom runtime image (windows x64) for my >>>> ???????JavaFX application >>>> ???????>> and used the OpenJFX 11-ea+19 maven artifacts. >>>> ???????>> >>>> ???????>> I get the following exception if I try to execute my >>>> ???????application: >>>> ???????>> >>>> ???????>> Graphics Device initialization failed for :? d3d, sw >>>> ???????>> Error initializing QuantumRenderer: no suitable pipeline >>>> found >>>> ???????>> java.lang.RuntimeException: java.lang.RuntimeException: >>>> ???????Error initializing >>>> ???????>> QuantumRenderer: no suitable pipeline found >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> ???????>> Method) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> ???????>>? ? ? ? ? at >>>> ???????java.base/java.lang.reflect.Method.invoke(Method.java:564) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >>>> ???????>> Caused by: java.lang.RuntimeException: Error initializing >>>> ???????QuantumRenderer: >>>> ???????>> no suitable pipeline found >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) >>>> ???????>>? ? ? ? ? at java.base/java.lang.Thread.run(Thread.java:844) >>>> ???????>> Exception in thread "main" >>>> ???????java.lang.reflect.InvocationTargetException >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> ???????>> Method) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> ???????>>? ? ? ? ? at >>>> ???????java.base/java.lang.reflect.Method.invoke(Method.java:564) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941) >>>> ???????>> Caused by: java.lang.RuntimeException: No toolkit found >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> ???????javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409) >>>> ???????>>? ? ? ? ? at >>>> ???????>> >>>> ???????>> >>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >>>> ???????>>? ? ? ? ? ... 5 more >>>> ???????>> >>>> ???????>> >>>> ???????>> -Djavafx.verbose=true shows that JavaFX isn't able to load >>>> ???????the native libs >>>> ???????>> from the javafx-graphics jar. >>>> ???????>> >>>> ???????>> >>>> ???????>> I debugged the NativeLibLoader and >>>> loadLibraryFromResource and >>>> ???????>> installLibraryFromResource will be executed which is ok. >>>> ???????But the >>>> ???????>> *reallib *value for >>>> ???????>> all dll's is wrong because of the empty *libSuffix*. >>>> ???????>> >>>> ???????>> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is >>>> ???????>> */api-ms-win-core-console-l1-1-0* and not >>>> ???????>> */api-ms-win-core-console-l1-1-0.dll* >>>> ???????>> >>>> ???????>> Is it intentional that *libPrefix *& *libSuffix *will not >>>> ???????be set in case of >>>> ???????>> the jrt protocol ? >>>> ???????>> >>>> ???????>> >>>> ???????>> >>>> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308 >>>> ???????>> >>>> ???????>> >>>> ???????>> >>>> ???????>> >>>> ???????>> >>>> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338 >>>> ???????>> >>>> ???????>> >>>> ???????>> >>>> ???????>> >>>> ???????>> Best Regards, >>>> ???????>> Steve >>>> ???????>> > From amnojeeuw at gmail.com Fri Jul 27 20:18:49 2018 From: amnojeeuw at gmail.com (AmnoJeeuw) Date: Fri, 27 Jul 2018 16:18:49 -0400 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage In-Reply-To: References: Message-ID: Yes I agree with Kevin From amnojeeuw at gmail.com Fri Jul 27 20:19:41 2018 From: amnojeeuw at gmail.com (AmnoJeeuw) Date: Fri, 27 Jul 2018 16:19:41 -0400 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage In-Reply-To: References: Message-ID: Sorry, I ment Johan :-[ On 2018-07-27 10:35 AM, Johan Vos wrote: >>> at >>> >>> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) >>> at >>> >>> From pedro.duquevieira at gmail.com Sat Jul 28 12:55:02 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sat, 28 Jul 2018 13:55:02 +0100 Subject: NativeLibLoader - installLibraryFromResource - RuntimeImage Message-ID: Hi, I agree with Scott Palmer. I think this is a rather complex issue with no easy answer. Right now, most people are still on java 8, if we follow the path of only supporting the latest issues we might end up with a library that no one uses, if no one uses than also less people will contribute with PRs, less third party libraries will exist, less tooling support, and so on.. Or maybe, like Scott says things will clear up after java 11 and migrating will become easier? And also more people will adopt the latest version? Would be useful to know at any given time how much people are on each java version so we could make this decision. Maybe will be best to decide on a case by case situation, that is, on each openjfx version depending on the rate of adoption of each java version? -- Pedro Duque Vieira From nlisker at gmail.com Sun Jul 29 22:34:53 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 30 Jul 2018 01:34:53 +0300 Subject: Review Request: JDK-8204653: Fix mistakes in FX API docs Message-ID: Hi Kevin, Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8204653 http://cr.openjdk.java.net/~nlisker/8204653/webrev.00/ I did not include a fix for https://github.com/javafxports/openjdk-jfx/issues/122, which is pending. From ambarish.rapte at oracle.com Mon Jul 30 19:51:37 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 30 Jul 2018 12:51:37 -0700 (PDT) Subject: [openjfx11] RFR : JDK-8197985 : Pressing Shift + DOWN in ListView causes Exception to be thrown Message-ID: Hi Kevin & Jeanette, Please review this fix: JBS: https://bugs.openjdk.java.net/browse/JDK-8197985 Webrev: http://cr.openjdk.java.net/~arapte/fx/8197985/webrev.00/ Regards, Ambarish From tom.schindl at bestsolution.at Tue Jul 31 07:46:49 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 31 Jul 2018 09:46:49 +0200 Subject: JavaFX SWT and Swing-Interopt Message-ID: <4d3db403-e1b0-4fd3-46be-8ff1f380ed9c@bestsolution.at> Hi, In one of our customers application we have major problems when embedding JavaFX into SWT (but from my tests the situation is equal for Swing). In the end all windows (most commonly popup-windows) are affected because they don't have a parent-window assigned and so they can be hidden by the window embedding them - if the window opened is Modal like eg the one from ColorPicker the JavaFX UI is also blocked. To see what I mean just use this snippet below and do the following: * Bring up the DropDown-List * Bring up the custom color dialog * Click somewhere in the JFrame You notice the following: * JavaFX Window is moved behind Swing-Window * JavaFX UI is blocked > package test; > > import javax.swing.JFrame; > > import javafx.application.Platform; > import javafx.embed.swing.JFXPanel; > import javafx.geometry.Pos; > import javafx.scene.Scene; > import javafx.scene.control.ColorPicker; > import javafx.scene.layout.BorderPane; > > public class TestSwingInterop extends JFrame { > > public TestSwingInterop() { > setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > final JFXPanel fxPanel = new JFXPanel(); > add(fxPanel); > > Platform.runLater(new Runnable() { > @Override > public void run() { > initFX(fxPanel); > } > }); > } > > private static void initFX(JFXPanel fxPanel) { > // This method is invoked on JavaFX thread > Scene scene = createScene(); > fxPanel.setScene(scene); > } > > private static Scene createScene() { > ColorPicker picker = new ColorPicker(); > BorderPane.setAlignment(picker, Pos.TOP_LEFT); > BorderPane p = new BorderPane(picker); > > return new Scene(p); > } > > public static void main(String[] args) { > TestSwingInterop s = new TestSwingInterop(); > s.setBounds(100, 100, 1000, 800); > s.setVisible(true); > } > } I've tested this on Java8 and Java9 but didn't had a chance to run it on the latest master. The problem is that the newly created JavaFX windows don't have the Native-Window as their parent but the EmbeddedStage (who is not bound to a native-window handle). It looks like EmbeddedStage has already been prepared (see getRawHandle() : long) to support something like that in future but com.sun.glass.ui.Window and its subclasses have never been extend to create a window based on a pure long-pointer. The only exception and the reason I guess the strategy would work was used for Applets. Before diving deeper into this I wanted to get a feedback from people who know things better: Does the strategy of passing along the window pointer (eg from SWT, don't know about Swing yet) to Glass and using it as the parent pointer sound like a proper idea? Tom -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From prasanta.sadhukhan at oracle.com Tue Jul 31 09:21:48 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 31 Jul 2018 14:51:48 +0530 Subject: JavaFX SWT and Swing-Interopt In-Reply-To: <4d3db403-e1b0-4fd3-46be-8ff1f380ed9c@bestsolution.at> References: <4d3db403-e1b0-4fd3-46be-8ff1f380ed9c@bestsolution.at> Message-ID: <517d3afe-4385-a86b-0d5d-157843ca93c6@oracle.com> Hi Tom, I am not able to see the problem in latest workspace. I believe this issue is already fixed by JDK-8185634. Regards Prasanta On 7/31/2018 1:16 PM, Tom Schindl wrote: > Hi, > > In one of our customers application we have major problems when > embedding JavaFX into SWT (but from my tests the situation is equal for > Swing). > > In the end all windows (most commonly popup-windows) are affected > because they don't have a parent-window assigned and so they can be > hidden by the window embedding them - if the window opened is Modal like > eg the one from ColorPicker the JavaFX UI is also blocked. > > To see what I mean just use this snippet below and do the following: > * Bring up the DropDown-List > * Bring up the custom color dialog > * Click somewhere in the JFrame > > You notice the following: > * JavaFX Window is moved behind Swing-Window > * JavaFX UI is blocked > >> package test; >> >> import javax.swing.JFrame; >> >> import javafx.application.Platform; >> import javafx.embed.swing.JFXPanel; >> import javafx.geometry.Pos; >> import javafx.scene.Scene; >> import javafx.scene.control.ColorPicker; >> import javafx.scene.layout.BorderPane; >> >> public class TestSwingInterop extends JFrame { >> >> public TestSwingInterop() { >> setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> final JFXPanel fxPanel = new JFXPanel(); >> add(fxPanel); >> >> Platform.runLater(new Runnable() { >> @Override >> public void run() { >> initFX(fxPanel); >> } >> }); >> } >> >> private static void initFX(JFXPanel fxPanel) { >> // This method is invoked on JavaFX thread >> Scene scene = createScene(); >> fxPanel.setScene(scene); >> } >> >> private static Scene createScene() { >> ColorPicker picker = new ColorPicker(); >> BorderPane.setAlignment(picker, Pos.TOP_LEFT); >> BorderPane p = new BorderPane(picker); >> >> return new Scene(p); >> } >> >> public static void main(String[] args) { >> TestSwingInterop s = new TestSwingInterop(); >> s.setBounds(100, 100, 1000, 800); >> s.setVisible(true); >> } >> } > > I've tested this on Java8 and Java9 but didn't had a chance to run it on > the latest master. > > The problem is that the newly created JavaFX windows don't have the > Native-Window as their parent but the EmbeddedStage (who is not bound to > a native-window handle). It looks like EmbeddedStage has already been > prepared (see getRawHandle() : long) to support something like that in > future but com.sun.glass.ui.Window and its subclasses have never been > extend to create a window based on a pure long-pointer. > > The only exception and the reason I guess the strategy would work was > used for Applets. > > Before diving deeper into this I wanted to get a feedback from people > who know things better: Does the strategy of passing along the window > pointer (eg from SWT, don't know about Swing yet) to Glass and using it > as the parent pointer sound like a proper idea? > > Tom > From tom.schindl at bestsolution.at Tue Jul 31 11:08:46 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 31 Jul 2018 13:08:46 +0200 Subject: JavaFX SWT and Swing-Interopt In-Reply-To: <517d3afe-4385-a86b-0d5d-157843ca93c6@oracle.com> References: <4d3db403-e1b0-4fd3-46be-8ff1f380ed9c@bestsolution.at> <517d3afe-4385-a86b-0d5d-157843ca93c6@oracle.com> Message-ID: <708aacd6-a449-426a-af3a-69efeba47f6b@bestsolution.at> Hi, I give it a try but from the bug description and discussion I would have assumed it deals with the opposite problems (Opening a Swing-Dialog from an JavaFX-Application who uses Swing-Node). I also studied the code to see if how you make a JavaFX-Stage having a different owner but I could only find changes to AWT deal with this. Anyways I'll try to get it the latest master running. The issue states that it is fixed in 8u182 but only 8u181 is available and there are no EA-Builds of Java8 available anymore (Looks like Oracle does not want people to test fixes for upcoming 8-update anymore) Tom On 31.07.18 11:21, Prasanta Sadhukhan wrote: > Hi Tom, > > I am not able to see the problem in latest workspace. I believe this > issue is already fixed by JDK-8185634. > > Regards > Prasanta > On 7/31/2018 1:16 PM, Tom Schindl wrote: >> Hi, >> >> In one of our customers application we have major problems when >> embedding JavaFX into SWT (but from my tests the situation is equal for >> Swing). >> >> In the end all windows (most commonly popup-windows) are affected >> because they don't have a parent-window assigned and so they can be >> hidden by the window embedding them - if the window opened is Modal like >> eg the one from ColorPicker the JavaFX UI is also blocked. >> >> To see what I mean just use this snippet below and do the following: >> * Bring up the DropDown-List >> * Bring up the custom color dialog >> * Click somewhere in the JFrame >> >> You notice the following: >> * JavaFX Window is moved behind Swing-Window >> * JavaFX UI is blocked >> >>> package test; >>> >>> import javax.swing.JFrame; >>> >>> import javafx.application.Platform; >>> import javafx.embed.swing.JFXPanel; >>> import javafx.geometry.Pos; >>> import javafx.scene.Scene; >>> import javafx.scene.control.ColorPicker; >>> import javafx.scene.layout.BorderPane; >>> >>> public class TestSwingInterop extends JFrame { >>> ???? >>> ????public TestSwingInterop() { >>> ??????? setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>> ??????? final JFXPanel fxPanel = new JFXPanel(); >>> ???????? add(fxPanel); >>> ???????? ???????? Platform.runLater(new Runnable() { >>> ???????????? @Override >>> ???????????? public void run() { >>> ???????????????? initFX(fxPanel); >>> ???????????? } >>> ???????? }); >>> ????} >>> ???? >>> ????private static void initFX(JFXPanel fxPanel) { >>> ???????? // This method is invoked on JavaFX thread >>> ???????? Scene scene = createScene(); >>> ???????? fxPanel.setScene(scene); >>> ???? } >>> ???? >>> ????private static Scene createScene() { >>> ??????? ColorPicker picker = new ColorPicker(); >>> ??????? BorderPane.setAlignment(picker, Pos.TOP_LEFT); >>> ??????? BorderPane p = new BorderPane(picker); >>> ??????? >>> ??????? return new Scene(p); >>> ????} >>> >>> ????public static void main(String[] args) { >>> ??????? TestSwingInterop s = new TestSwingInterop(); >>> ??????? s.setBounds(100, 100, 1000, 800); >>> ??????? s.setVisible(true); >>> ????} >>> } >> >> I've tested this on Java8 and Java9 but didn't had a chance to run it on >> the latest master. >> >> The problem is that the newly created JavaFX windows don't have the >> Native-Window as their parent but the EmbeddedStage (who is not bound to >> a native-window handle). It looks like EmbeddedStage has already been >> prepared (see getRawHandle() : long) to support something like that in >> future but com.sun.glass.ui.Window and its subclasses have never been >> extend to create a window based on a pure long-pointer. >> >> The only exception and the reason I guess the strategy would work was >> used for Applets. >> >> Before diving deeper into this I wanted to get a feedback from people >> who know things better: Does the strategy of passing along the window >> pointer (eg from SWT, don't know about Swing yet) to Glass and using it >> as the parent pointer sound like a proper idea? >> >> Tom >> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From kevin.rushforth at oracle.com Tue Jul 31 11:44:01 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 31 Jul 2018 04:44:01 -0700 Subject: JavaFX SWT and Swing-Interopt In-Reply-To: <708aacd6-a449-426a-af3a-69efeba47f6b@bestsolution.at> References: <4d3db403-e1b0-4fd3-46be-8ff1f380ed9c@bestsolution.at> <517d3afe-4385-a86b-0d5d-157843ca93c6@oracle.com> <708aacd6-a449-426a-af3a-69efeba47f6b@bestsolution.at> Message-ID: > ...there are no EA-Builds of Java8 available anymore (Looks like Oracle does not want people to test fixes for upcoming 8-update anymore) EA builds of JDK 8u192 were supposed to be published last week, but there was a glitch. I hope it will be fixed soon. Having said that, I see that the issue Prasanta mentioned was fixed in JDK 8u172, but I don't know whether your issue is the same. What platform(s) do you see this bug on? -- Kevin On 7/31/2018 4:08 AM, Tom Schindl wrote: > Hi, > > I give it a try but from the bug description and discussion I would have > assumed it deals with the opposite problems (Opening a Swing-Dialog from > an JavaFX-Application who uses Swing-Node). > > I also studied the code to see if how you make a JavaFX-Stage having a > different owner but I could only find changes to AWT deal with this. > > Anyways I'll try to get it the latest master running. The issue states > that it is fixed in 8u182 but only 8u181 is available and there are no > EA-Builds of Java8 available anymore (Looks like Oracle does not want > people to test fixes for upcoming 8-update anymore) > > Tom > > On 31.07.18 11:21, Prasanta Sadhukhan wrote: >> Hi Tom, >> >> I am not able to see the problem in latest workspace. I believe this >> issue is already fixed by JDK-8185634. >> >> Regards >> Prasanta >> On 7/31/2018 1:16 PM, Tom Schindl wrote: >>> Hi, >>> >>> In one of our customers application we have major problems when >>> embedding JavaFX into SWT (but from my tests the situation is equal for >>> Swing). >>> >>> In the end all windows (most commonly popup-windows) are affected >>> because they don't have a parent-window assigned and so they can be >>> hidden by the window embedding them - if the window opened is Modal like >>> eg the one from ColorPicker the JavaFX UI is also blocked. >>> >>> To see what I mean just use this snippet below and do the following: >>> * Bring up the DropDown-List >>> * Bring up the custom color dialog >>> * Click somewhere in the JFrame >>> >>> You notice the following: >>> * JavaFX Window is moved behind Swing-Window >>> * JavaFX UI is blocked >>> >>>> package test; >>>> >>>> import javax.swing.JFrame; >>>> >>>> import javafx.application.Platform; >>>> import javafx.embed.swing.JFXPanel; >>>> import javafx.geometry.Pos; >>>> import javafx.scene.Scene; >>>> import javafx.scene.control.ColorPicker; >>>> import javafx.scene.layout.BorderPane; >>>> >>>> public class TestSwingInterop extends JFrame { >>>> >>>> ????public TestSwingInterop() { >>>> ??????? setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>> ??????? final JFXPanel fxPanel = new JFXPanel(); >>>> ???????? add(fxPanel); >>>> ???????? ???????? Platform.runLater(new Runnable() { >>>> ???????????? @Override >>>> ???????????? public void run() { >>>> ???????????????? initFX(fxPanel); >>>> ???????????? } >>>> ???????? }); >>>> ????} >>>> >>>> ????private static void initFX(JFXPanel fxPanel) { >>>> ???????? // This method is invoked on JavaFX thread >>>> ???????? Scene scene = createScene(); >>>> ???????? fxPanel.setScene(scene); >>>> ???? } >>>> >>>> ????private static Scene createScene() { >>>> ??????? ColorPicker picker = new ColorPicker(); >>>> ??????? BorderPane.setAlignment(picker, Pos.TOP_LEFT); >>>> ??????? BorderPane p = new BorderPane(picker); >>>> >>>> ??????? return new Scene(p); >>>> ????} >>>> >>>> ????public static void main(String[] args) { >>>> ??????? TestSwingInterop s = new TestSwingInterop(); >>>> ??????? s.setBounds(100, 100, 1000, 800); >>>> ??????? s.setVisible(true); >>>> ????} >>>> } >>> I've tested this on Java8 and Java9 but didn't had a chance to run it on >>> the latest master. >>> >>> The problem is that the newly created JavaFX windows don't have the >>> Native-Window as their parent but the EmbeddedStage (who is not bound to >>> a native-window handle). It looks like EmbeddedStage has already been >>> prepared (see getRawHandle() : long) to support something like that in >>> future but com.sun.glass.ui.Window and its subclasses have never been >>> extend to create a window based on a pure long-pointer. >>> >>> The only exception and the reason I guess the strategy would work was >>> used for Applets. >>> >>> Before diving deeper into this I wanted to get a feedback from people >>> who know things better: Does the strategy of passing along the window >>> pointer (eg from SWT, don't know about Swing yet) to Glass and using it >>> as the parent pointer sound like a proper idea? >>> >>> Tom >>> From mp at jugs.org Tue Jul 31 11:45:49 2018 From: mp at jugs.org (Michael Paus) Date: Tue, 31 Jul 2018 13:45:49 +0200 Subject: JavaFX SWT and Swing-Interopt In-Reply-To: <708aacd6-a449-426a-af3a-69efeba47f6b@bestsolution.at> References: <4d3db403-e1b0-4fd3-46be-8ff1f380ed9c@bestsolution.at> <517d3afe-4385-a86b-0d5d-157843ca93c6@oracle.com> <708aacd6-a449-426a-af3a-69efeba47f6b@bestsolution.at> Message-ID: <20d831dc-047d-6163-cbbc-240c3ee6d12a@jugs.org> Hi Tom I gave it a try with the latest OpenJDK12ea and OpenJFX11ea and I still see the same baviour which you described. Michael Am 31.07.18 um 13:08 schrieb Tom Schindl: > Hi, > > I give it a try but from the bug description and discussion I would have > assumed it deals with the opposite problems (Opening a Swing-Dialog from > an JavaFX-Application who uses Swing-Node). > > I also studied the code to see if how you make a JavaFX-Stage having a > different owner but I could only find changes to AWT deal with this. > > Anyways I'll try to get it the latest master running. The issue states > that it is fixed in 8u182 but only 8u181 is available and there are no > EA-Builds of Java8 available anymore (Looks like Oracle does not want > people to test fixes for upcoming 8-update anymore) > > Tom > > On 31.07.18 11:21, Prasanta Sadhukhan wrote: >> Hi Tom, >> >> I am not able to see the problem in latest workspace. I believe this >> issue is already fixed by JDK-8185634. >> >> Regards >> Prasanta >> On 7/31/2018 1:16 PM, Tom Schindl wrote: >>> Hi, >>> >>> In one of our customers application we have major problems when >>> embedding JavaFX into SWT (but from my tests the situation is equal for >>> Swing). >>> >>> In the end all windows (most commonly popup-windows) are affected >>> because they don't have a parent-window assigned and so they can be >>> hidden by the window embedding them - if the window opened is Modal like >>> eg the one from ColorPicker the JavaFX UI is also blocked. >>> >>> To see what I mean just use this snippet below and do the following: >>> * Bring up the DropDown-List >>> * Bring up the custom color dialog >>> * Click somewhere in the JFrame >>> >>> You notice the following: >>> * JavaFX Window is moved behind Swing-Window >>> * JavaFX UI is blocked >>> >>>> package test; >>>> >>>> import javax.swing.JFrame; >>>> >>>> import javafx.application.Platform; >>>> import javafx.embed.swing.JFXPanel; >>>> import javafx.geometry.Pos; >>>> import javafx.scene.Scene; >>>> import javafx.scene.control.ColorPicker; >>>> import javafx.scene.layout.BorderPane; >>>> >>>> public class TestSwingInterop extends JFrame { >>>> >>>> ????public TestSwingInterop() { >>>> ??????? setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>> ??????? final JFXPanel fxPanel = new JFXPanel(); >>>> ???????? add(fxPanel); >>>> ???????? ???????? Platform.runLater(new Runnable() { >>>> ???????????? @Override >>>> ???????????? public void run() { >>>> ???????????????? initFX(fxPanel); >>>> ???????????? } >>>> ???????? }); >>>> ????} >>>> >>>> ????private static void initFX(JFXPanel fxPanel) { >>>> ???????? // This method is invoked on JavaFX thread >>>> ???????? Scene scene = createScene(); >>>> ???????? fxPanel.setScene(scene); >>>> ???? } >>>> >>>> ????private static Scene createScene() { >>>> ??????? ColorPicker picker = new ColorPicker(); >>>> ??????? BorderPane.setAlignment(picker, Pos.TOP_LEFT); >>>> ??????? BorderPane p = new BorderPane(picker); >>>> >>>> ??????? return new Scene(p); >>>> ????} >>>> >>>> ????public static void main(String[] args) { >>>> ??????? TestSwingInterop s = new TestSwingInterop(); >>>> ??????? s.setBounds(100, 100, 1000, 800); >>>> ??????? s.setVisible(true); >>>> ????} >>>> } >>> I've tested this on Java8 and Java9 but didn't had a chance to run it on >>> the latest master. >>> >>> The problem is that the newly created JavaFX windows don't have the >>> Native-Window as their parent but the EmbeddedStage (who is not bound to >>> a native-window handle). It looks like EmbeddedStage has already been >>> prepared (see getRawHandle() : long) to support something like that in >>> future but com.sun.glass.ui.Window and its subclasses have never been >>> extend to create a window based on a pure long-pointer. >>> >>> The only exception and the reason I guess the strategy would work was >>> used for Applets. >>> >>> Before diving deeper into this I wanted to get a feedback from people >>> who know things better: Does the strategy of passing along the window >>> pointer (eg from SWT, don't know about Swing yet) to Glass and using it >>> as the parent pointer sound like a proper idea? >>> >>> Tom >>> From kevin.rushforth at oracle.com Tue Jul 31 12:19:30 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 31 Jul 2018 05:19:30 -0700 Subject: JavaFX SWT and Swing-Interopt In-Reply-To: <20d831dc-047d-6163-cbbc-240c3ee6d12a@jugs.org> References: <4d3db403-e1b0-4fd3-46be-8ff1f380ed9c@bestsolution.at> <517d3afe-4385-a86b-0d5d-157843ca93c6@oracle.com> <708aacd6-a449-426a-af3a-69efeba47f6b@bestsolution.at> <20d831dc-047d-6163-cbbc-240c3ee6d12a@jugs.org> Message-ID: I ran the test program on Windows 7 using JDK-11+24 plus my local build of openjfx 11, and I can't reproduce the problem. I suspect that Prasanta is correct in that this was fixed for FX/Swing interop by JDK-8185634 (on the FX side) and JDK-8187803 (on the AWT side). I don't know why you and Tom are still seeing this bug. What platform are you testing on? Note that this won't help SWT interop, though. A similar fix might be needed there (once we understand why the Swing interop test program isn't working for some of you). -- Kevin On 7/31/2018 4:45 AM, Michael Paus wrote: > Hi Tom > I gave it a try with the latest OpenJDK12ea and OpenJFX11ea and I still > see the same baviour which you described. > Michael > > Am 31.07.18 um 13:08 schrieb Tom Schindl: >> Hi, >> >> I give it a try but from the bug description and discussion I would have >> assumed it deals with the opposite problems (Opening a Swing-Dialog from >> an JavaFX-Application who uses Swing-Node). >> >> I also studied the code to see if how you make a JavaFX-Stage having a >> different owner but I could only find changes to AWT deal with this. >> >> Anyways I'll try to get it the latest master running. The issue states >> that it is fixed in 8u182 but only 8u181 is available and there are no >> EA-Builds of Java8 available anymore (Looks like Oracle does not want >> people to test fixes for upcoming 8-update anymore) >> >> Tom >> >> On 31.07.18 11:21, Prasanta Sadhukhan wrote: >>> Hi Tom, >>> >>> I am not able to see the problem in latest workspace. I believe this >>> issue is already fixed by JDK-8185634. >>> >>> Regards >>> Prasanta >>> On 7/31/2018 1:16 PM, Tom Schindl wrote: >>>> Hi, >>>> >>>> In one of our customers application we have major problems when >>>> embedding JavaFX into SWT (but from my tests the situation is equal >>>> for >>>> Swing). >>>> >>>> In the end all windows (most commonly popup-windows) are affected >>>> because they don't have a parent-window assigned and so they can be >>>> hidden by the window embedding them - if the window opened is Modal >>>> like >>>> eg the one from ColorPicker the JavaFX UI is also blocked. >>>> >>>> To see what I mean just use this snippet below and do the following: >>>> * Bring up the DropDown-List >>>> * Bring up the custom color dialog >>>> * Click somewhere in the JFrame >>>> >>>> You notice the following: >>>> * JavaFX Window is moved behind Swing-Window >>>> * JavaFX UI is blocked >>>> >>>>> package test; >>>>> >>>>> import javax.swing.JFrame; >>>>> >>>>> import javafx.application.Platform; >>>>> import javafx.embed.swing.JFXPanel; >>>>> import javafx.geometry.Pos; >>>>> import javafx.scene.Scene; >>>>> import javafx.scene.control.ColorPicker; >>>>> import javafx.scene.layout.BorderPane; >>>>> >>>>> public class TestSwingInterop extends JFrame { >>>>> ???? ?????public TestSwingInterop() { >>>>> ???????? setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>>> ???????? final JFXPanel fxPanel = new JFXPanel(); >>>>> ????????? add(fxPanel); >>>>> ????????? ???????? Platform.runLater(new Runnable() { >>>>> ????????????? @Override >>>>> ????????????? public void run() { >>>>> ????????????????? initFX(fxPanel); >>>>> ????????????? } >>>>> ????????? }); >>>>> ?????} >>>>> ???? ?????private static void initFX(JFXPanel fxPanel) { >>>>> ????????? // This method is invoked on JavaFX thread >>>>> ????????? Scene scene = createScene(); >>>>> ????????? fxPanel.setScene(scene); >>>>> ????? } >>>>> ???? ?????private static Scene createScene() { >>>>> ???????? ColorPicker picker = new ColorPicker(); >>>>> ???????? BorderPane.setAlignment(picker, Pos.TOP_LEFT); >>>>> ???????? BorderPane p = new BorderPane(picker); >>>>> ??????? ???????? return new Scene(p); >>>>> ?????} >>>>> >>>>> ?????public static void main(String[] args) { >>>>> ???????? TestSwingInterop s = new TestSwingInterop(); >>>>> ???????? s.setBounds(100, 100, 1000, 800); >>>>> ???????? s.setVisible(true); >>>>> ?????} >>>>> } >>>> I've tested this on Java8 and Java9 but didn't had a chance to run >>>> it on >>>> the latest master. >>>> >>>> The problem is that the newly created JavaFX windows don't have the >>>> Native-Window as their parent but the EmbeddedStage (who is not >>>> bound to >>>> a native-window handle). It looks like EmbeddedStage has already been >>>> prepared (see getRawHandle() : long) to support something like that in >>>> future but com.sun.glass.ui.Window and its subclasses have never been >>>> extend to create a window based on a pure long-pointer. >>>> >>>> The only exception and the reason I guess the strategy would work was >>>> used for Applets. >>>> >>>> Before diving deeper into this I wanted to get a feedback from people >>>> who know things better: Does the strategy of passing along the window >>>> pointer (eg from SWT, don't know about Swing yet) to Glass and >>>> using it >>>> as the parent pointer sound like a proper idea? >>>> >>>> Tom >>>> > From mp at jugs.org Tue Jul 31 12:34:46 2018 From: mp at jugs.org (Michael Paus) Date: Tue, 31 Jul 2018 14:34:46 +0200 Subject: JavaFX SWT and Swing-Interopt In-Reply-To: References: <4d3db403-e1b0-4fd3-46be-8ff1f380ed9c@bestsolution.at> <517d3afe-4385-a86b-0d5d-157843ca93c6@oracle.com> <708aacd6-a449-426a-af3a-69efeba47f6b@bestsolution.at> <20d831dc-047d-6163-cbbc-240c3ee6d12a@jugs.org> Message-ID: <34309715-d571-68f8-e182-7a671e32c6d1@jugs.org> I did the test on a Mac. MacOS High Sierra OpenJDK12ea4 OpenJFX11ea20 (SDK) I just ran the code and repeated the steps given by Tom. * Bring up the DropDown-List * Bring up the custom color dialog * Click somewhere in the JFrame Michael Am 31.07.18 um 14:19 schrieb Kevin Rushforth: > I ran the test program on Windows 7 using JDK-11+24 plus my local > build of openjfx 11, and I can't reproduce the problem. I suspect that > Prasanta is correct in that this was fixed for FX/Swing interop by > JDK-8185634 (on the FX side) and JDK-8187803 (on the AWT side). I > don't know why you and Tom are still seeing this bug. What platform > are you testing on? > > Note that this won't help SWT interop, though. A similar fix might be > needed there (once we understand why the Swing interop test program > isn't working for some of you). > > -- Kevin > > On 7/31/2018 4:45 AM, Michael Paus wrote: >> Hi Tom >> I gave it a try with the latest OpenJDK12ea and OpenJFX11ea and I still >> see the same baviour which you described. >> Michael >> >> Am 31.07.18 um 13:08 schrieb Tom Schindl: >>> Hi, >>> >>> I give it a try but from the bug description and discussion I would >>> have >>> assumed it deals with the opposite problems (Opening a Swing-Dialog >>> from >>> an JavaFX-Application who uses Swing-Node). >>> >>> I also studied the code to see if how you make a JavaFX-Stage having a >>> different owner but I could only find changes to AWT deal with this. >>> >>> Anyways I'll try to get it the latest master running. The issue states >>> that it is fixed in 8u182 but only 8u181 is available and there are no >>> EA-Builds of Java8 available anymore (Looks like Oracle does not want >>> people to test fixes for upcoming 8-update anymore) >>> >>> Tom >>> >>> On 31.07.18 11:21, Prasanta Sadhukhan wrote: >>>> Hi Tom, >>>> >>>> I am not able to see the problem in latest workspace. I believe this >>>> issue is already fixed by JDK-8185634. >>>> >>>> Regards >>>> Prasanta >>>> On 7/31/2018 1:16 PM, Tom Schindl wrote: >>>>> Hi, >>>>> >>>>> In one of our customers application we have major problems when >>>>> embedding JavaFX into SWT (but from my tests the situation is >>>>> equal for >>>>> Swing). >>>>> >>>>> In the end all windows (most commonly popup-windows) are affected >>>>> because they don't have a parent-window assigned and so they can be >>>>> hidden by the window embedding them - if the window opened is >>>>> Modal like >>>>> eg the one from ColorPicker the JavaFX UI is also blocked. >>>>> >>>>> To see what I mean just use this snippet below and do the following: >>>>> * Bring up the DropDown-List >>>>> * Bring up the custom color dialog >>>>> * Click somewhere in the JFrame >>>>> >>>>> You notice the following: >>>>> * JavaFX Window is moved behind Swing-Window >>>>> * JavaFX UI is blocked >>>>> >>>>>> package test; >>>>>> >>>>>> import javax.swing.JFrame; >>>>>> >>>>>> import javafx.application.Platform; >>>>>> import javafx.embed.swing.JFXPanel; >>>>>> import javafx.geometry.Pos; >>>>>> import javafx.scene.Scene; >>>>>> import javafx.scene.control.ColorPicker; >>>>>> import javafx.scene.layout.BorderPane; >>>>>> >>>>>> public class TestSwingInterop extends JFrame { >>>>>> ???? ?????public TestSwingInterop() { >>>>>> ???????? setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>>>> ???????? final JFXPanel fxPanel = new JFXPanel(); >>>>>> ????????? add(fxPanel); >>>>>> ????????? ???????? Platform.runLater(new Runnable() { >>>>>> ????????????? @Override >>>>>> ????????????? public void run() { >>>>>> ????????????????? initFX(fxPanel); >>>>>> ????????????? } >>>>>> ????????? }); >>>>>> ?????} >>>>>> ???? ?????private static void initFX(JFXPanel fxPanel) { >>>>>> ????????? // This method is invoked on JavaFX thread >>>>>> ????????? Scene scene = createScene(); >>>>>> ????????? fxPanel.setScene(scene); >>>>>> ????? } >>>>>> ???? ?????private static Scene createScene() { >>>>>> ???????? ColorPicker picker = new ColorPicker(); >>>>>> ???????? BorderPane.setAlignment(picker, Pos.TOP_LEFT); >>>>>> ???????? BorderPane p = new BorderPane(picker); >>>>>> ??????? ???????? return new Scene(p); >>>>>> ?????} >>>>>> >>>>>> ?????public static void main(String[] args) { >>>>>> ???????? TestSwingInterop s = new TestSwingInterop(); >>>>>> ???????? s.setBounds(100, 100, 1000, 800); >>>>>> ???????? s.setVisible(true); >>>>>> ?????} >>>>>> } >>>>> I've tested this on Java8 and Java9 but didn't had a chance to run >>>>> it on >>>>> the latest master. >>>>> >>>>> The problem is that the newly created JavaFX windows don't have the >>>>> Native-Window as their parent but the EmbeddedStage (who is not >>>>> bound to >>>>> a native-window handle). It looks like EmbeddedStage has already been >>>>> prepared (see getRawHandle() : long) to support something like >>>>> that in >>>>> future but com.sun.glass.ui.Window and its subclasses have never been >>>>> extend to create a window based on a pure long-pointer. >>>>> >>>>> The only exception and the reason I guess the strategy would work was >>>>> used for Applets. >>>>> >>>>> Before diving deeper into this I wanted to get a feedback from people >>>>> who know things better: Does the strategy of passing along the window >>>>> pointer (eg from SWT, don't know about Swing yet) to Glass and >>>>> using it >>>>> as the parent pointer sound like a proper idea? >>>>> >>>>> Tom >>>>> >> > From tom.schindl at bestsolution.at Tue Jul 31 12:51:26 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 31 Jul 2018 14:51:26 +0200 Subject: JavaFX SWT and Swing-Interopt In-Reply-To: <34309715-d571-68f8-e182-7a671e32c6d1@jugs.org> References: <4d3db403-e1b0-4fd3-46be-8ff1f380ed9c@bestsolution.at> <517d3afe-4385-a86b-0d5d-157843ca93c6@oracle.com> <708aacd6-a449-426a-af3a-69efeba47f6b@bestsolution.at> <20d831dc-047d-6163-cbbc-240c3ee6d12a@jugs.org> <34309715-d571-68f8-e182-7a671e32c6d1@jugs.org> Message-ID: <7324829f-3804-cb75-0d12-8dda70c75884@bestsolution.at> Hi, I'm on Mac as well and just gave 8u181 a spin and see the same problem (beside others eg the DropDown popup does not move with window). Just to make sure: It is curcial to not only bring up the DropDown-List but also open the Dialog-Window with the color-spectrum, ... . Tom On 31.07.18 14:34, Michael Paus wrote: > I did the test on a Mac. > > MacOS High Sierra > OpenJDK12ea4 > OpenJFX11ea20 (SDK) > > I just ran the code and repeated the steps given by Tom. > * Bring up the DropDown-List > * Bring up the custom color dialog > * Click somewhere in the JFrame > > Michael > > Am 31.07.18 um 14:19 schrieb Kevin Rushforth: >> I ran the test program on Windows 7 using JDK-11+24 plus my local >> build of openjfx 11, and I can't reproduce the problem. I suspect that >> Prasanta is correct in that this was fixed for FX/Swing interop by >> JDK-8185634 (on the FX side) and JDK-8187803 (on the AWT side). I >> don't know why you and Tom are still seeing this bug. What platform >> are you testing on? >> >> Note that this won't help SWT interop, though. A similar fix might be >> needed there (once we understand why the Swing interop test program >> isn't working for some of you). >> >> -- Kevin >> >> On 7/31/2018 4:45 AM, Michael Paus wrote: >>> Hi Tom >>> I gave it a try with the latest OpenJDK12ea and OpenJFX11ea and I still >>> see the same baviour which you described. >>> Michael >>> >>> Am 31.07.18 um 13:08 schrieb Tom Schindl: >>>> Hi, >>>> >>>> I give it a try but from the bug description and discussion I would >>>> have >>>> assumed it deals with the opposite problems (Opening a Swing-Dialog >>>> from >>>> an JavaFX-Application who uses Swing-Node). >>>> >>>> I also studied the code to see if how you make a JavaFX-Stage having a >>>> different owner but I could only find changes to AWT deal with this. >>>> >>>> Anyways I'll try to get it the latest master running. The issue states >>>> that it is fixed in 8u182 but only 8u181 is available and there are no >>>> EA-Builds of Java8 available anymore (Looks like Oracle does not want >>>> people to test fixes for upcoming 8-update anymore) >>>> >>>> Tom >>>> >>>> On 31.07.18 11:21, Prasanta Sadhukhan wrote: >>>>> Hi Tom, >>>>> >>>>> I am not able to see the problem in latest workspace. I believe this >>>>> issue is already fixed by JDK-8185634. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 7/31/2018 1:16 PM, Tom Schindl wrote: >>>>>> Hi, >>>>>> >>>>>> In one of our customers application we have major problems when >>>>>> embedding JavaFX into SWT (but from my tests the situation is >>>>>> equal for >>>>>> Swing). >>>>>> >>>>>> In the end all windows (most commonly popup-windows) are affected >>>>>> because they don't have a parent-window assigned and so they can be >>>>>> hidden by the window embedding them - if the window opened is >>>>>> Modal like >>>>>> eg the one from ColorPicker the JavaFX UI is also blocked. >>>>>> >>>>>> To see what I mean just use this snippet below and do the following: >>>>>> * Bring up the DropDown-List >>>>>> * Bring up the custom color dialog >>>>>> * Click somewhere in the JFrame >>>>>> >>>>>> You notice the following: >>>>>> * JavaFX Window is moved behind Swing-Window >>>>>> * JavaFX UI is blocked >>>>>> >>>>>>> package test; >>>>>>> >>>>>>> import javax.swing.JFrame; >>>>>>> >>>>>>> import javafx.application.Platform; >>>>>>> import javafx.embed.swing.JFXPanel; >>>>>>> import javafx.geometry.Pos; >>>>>>> import javafx.scene.Scene; >>>>>>> import javafx.scene.control.ColorPicker; >>>>>>> import javafx.scene.layout.BorderPane; >>>>>>> >>>>>>> public class TestSwingInterop extends JFrame { >>>>>>> ???? ?????public TestSwingInterop() { >>>>>>> ???????? setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>>>>> ???????? final JFXPanel fxPanel = new JFXPanel(); >>>>>>> ????????? add(fxPanel); >>>>>>> ????????? ???????? Platform.runLater(new Runnable() { >>>>>>> ????????????? @Override >>>>>>> ????????????? public void run() { >>>>>>> ????????????????? initFX(fxPanel); >>>>>>> ????????????? } >>>>>>> ????????? }); >>>>>>> ?????} >>>>>>> ???? ?????private static void initFX(JFXPanel fxPanel) { >>>>>>> ????????? // This method is invoked on JavaFX thread >>>>>>> ????????? Scene scene = createScene(); >>>>>>> ????????? fxPanel.setScene(scene); >>>>>>> ????? } >>>>>>> ???? ?????private static Scene createScene() { >>>>>>> ???????? ColorPicker picker = new ColorPicker(); >>>>>>> ???????? BorderPane.setAlignment(picker, Pos.TOP_LEFT); >>>>>>> ???????? BorderPane p = new BorderPane(picker); >>>>>>> ??????? ???????? return new Scene(p); >>>>>>> ?????} >>>>>>> >>>>>>> ?????public static void main(String[] args) { >>>>>>> ???????? TestSwingInterop s = new TestSwingInterop(); >>>>>>> ???????? s.setBounds(100, 100, 1000, 800); >>>>>>> ???????? s.setVisible(true); >>>>>>> ?????} >>>>>>> } >>>>>> I've tested this on Java8 and Java9 but didn't had a chance to run >>>>>> it on >>>>>> the latest master. >>>>>> >>>>>> The problem is that the newly created JavaFX windows don't have the >>>>>> Native-Window as their parent but the EmbeddedStage (who is not >>>>>> bound to >>>>>> a native-window handle). It looks like EmbeddedStage has already been >>>>>> prepared (see getRawHandle() : long) to support something like >>>>>> that in >>>>>> future but com.sun.glass.ui.Window and its subclasses have never been >>>>>> extend to create a window based on a pure long-pointer. >>>>>> >>>>>> The only exception and the reason I guess the strategy would work was >>>>>> used for Applets. >>>>>> >>>>>> Before diving deeper into this I wanted to get a feedback from people >>>>>> who know things better: Does the strategy of passing along the window >>>>>> pointer (eg from SWT, don't know about Swing yet) to Glass and >>>>>> using it >>>>>> as the parent pointer sound like a proper idea? >>>>>> >>>>>> Tom >>>>>> >>> >> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From kevin.rushforth at oracle.com Tue Jul 31 12:57:34 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 31 Jul 2018 05:57:34 -0700 Subject: JavaFX SWT and Swing-Interopt In-Reply-To: <7324829f-3804-cb75-0d12-8dda70c75884@bestsolution.at> References: <4d3db403-e1b0-4fd3-46be-8ff1f380ed9c@bestsolution.at> <517d3afe-4385-a86b-0d5d-157843ca93c6@oracle.com> <708aacd6-a449-426a-af3a-69efeba47f6b@bestsolution.at> <20d831dc-047d-6163-cbbc-240c3ee6d12a@jugs.org> <34309715-d571-68f8-e182-7a671e32c6d1@jugs.org> <7324829f-3804-cb75-0d12-8dda70c75884@bestsolution.at> Message-ID: <069566e6-7003-a2ab-2d92-4825030d3892@oracle.com> OK, I can reproduce it on Mac using JDK 11-ea and the latest jfx-dev. Can you file a bug? -- Kevin On 7/31/2018 5:51 AM, Tom Schindl wrote: > Hi, > > I'm on Mac as well and just gave 8u181 a spin and see the same problem > (beside others eg the DropDown popup does not move with window). > > Just to make sure: It is curcial to not only bring up the DropDown-List > but also open the Dialog-Window with the color-spectrum, ... . > > Tom > > On 31.07.18 14:34, Michael Paus wrote: >> I did the test on a Mac. >> >> MacOS High Sierra >> OpenJDK12ea4 >> OpenJFX11ea20 (SDK) >> >> I just ran the code and repeated the steps given by Tom. >> * Bring up the DropDown-List >> * Bring up the custom color dialog >> * Click somewhere in the JFrame >> >> Michael >> >> Am 31.07.18 um 14:19 schrieb Kevin Rushforth: >>> I ran the test program on Windows 7 using JDK-11+24 plus my local >>> build of openjfx 11, and I can't reproduce the problem. I suspect that >>> Prasanta is correct in that this was fixed for FX/Swing interop by >>> JDK-8185634 (on the FX side) and JDK-8187803 (on the AWT side). I >>> don't know why you and Tom are still seeing this bug. What platform >>> are you testing on? >>> >>> Note that this won't help SWT interop, though. A similar fix might be >>> needed there (once we understand why the Swing interop test program >>> isn't working for some of you). >>> >>> -- Kevin >>> >>> On 7/31/2018 4:45 AM, Michael Paus wrote: >>>> Hi Tom >>>> I gave it a try with the latest OpenJDK12ea and OpenJFX11ea and I still >>>> see the same baviour which you described. >>>> Michael >>>> >>>> Am 31.07.18 um 13:08 schrieb Tom Schindl: >>>>> Hi, >>>>> >>>>> I give it a try but from the bug description and discussion I would >>>>> have >>>>> assumed it deals with the opposite problems (Opening a Swing-Dialog >>>>> from >>>>> an JavaFX-Application who uses Swing-Node). >>>>> >>>>> I also studied the code to see if how you make a JavaFX-Stage having a >>>>> different owner but I could only find changes to AWT deal with this. >>>>> >>>>> Anyways I'll try to get it the latest master running. The issue states >>>>> that it is fixed in 8u182 but only 8u181 is available and there are no >>>>> EA-Builds of Java8 available anymore (Looks like Oracle does not want >>>>> people to test fixes for upcoming 8-update anymore) >>>>> >>>>> Tom >>>>> >>>>> On 31.07.18 11:21, Prasanta Sadhukhan wrote: >>>>>> Hi Tom, >>>>>> >>>>>> I am not able to see the problem in latest workspace. I believe this >>>>>> issue is already fixed by JDK-8185634. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 7/31/2018 1:16 PM, Tom Schindl wrote: >>>>>>> Hi, >>>>>>> >>>>>>> In one of our customers application we have major problems when >>>>>>> embedding JavaFX into SWT (but from my tests the situation is >>>>>>> equal for >>>>>>> Swing). >>>>>>> >>>>>>> In the end all windows (most commonly popup-windows) are affected >>>>>>> because they don't have a parent-window assigned and so they can be >>>>>>> hidden by the window embedding them - if the window opened is >>>>>>> Modal like >>>>>>> eg the one from ColorPicker the JavaFX UI is also blocked. >>>>>>> >>>>>>> To see what I mean just use this snippet below and do the following: >>>>>>> * Bring up the DropDown-List >>>>>>> * Bring up the custom color dialog >>>>>>> * Click somewhere in the JFrame >>>>>>> >>>>>>> You notice the following: >>>>>>> * JavaFX Window is moved behind Swing-Window >>>>>>> * JavaFX UI is blocked >>>>>>> >>>>>>>> package test; >>>>>>>> >>>>>>>> import javax.swing.JFrame; >>>>>>>> >>>>>>>> import javafx.application.Platform; >>>>>>>> import javafx.embed.swing.JFXPanel; >>>>>>>> import javafx.geometry.Pos; >>>>>>>> import javafx.scene.Scene; >>>>>>>> import javafx.scene.control.ColorPicker; >>>>>>>> import javafx.scene.layout.BorderPane; >>>>>>>> >>>>>>>> public class TestSwingInterop extends JFrame { >>>>>>>> ???? ?????public TestSwingInterop() { >>>>>>>> ???????? setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>>>>>> ???????? final JFXPanel fxPanel = new JFXPanel(); >>>>>>>> ????????? add(fxPanel); >>>>>>>> ????????? ???????? Platform.runLater(new Runnable() { >>>>>>>> ????????????? @Override >>>>>>>> ????????????? public void run() { >>>>>>>> ????????????????? initFX(fxPanel); >>>>>>>> ????????????? } >>>>>>>> ????????? }); >>>>>>>> ?????} >>>>>>>> ???? ?????private static void initFX(JFXPanel fxPanel) { >>>>>>>> ????????? // This method is invoked on JavaFX thread >>>>>>>> ????????? Scene scene = createScene(); >>>>>>>> ????????? fxPanel.setScene(scene); >>>>>>>> ????? } >>>>>>>> ???? ?????private static Scene createScene() { >>>>>>>> ???????? ColorPicker picker = new ColorPicker(); >>>>>>>> ???????? BorderPane.setAlignment(picker, Pos.TOP_LEFT); >>>>>>>> ???????? BorderPane p = new BorderPane(picker); >>>>>>>> ??????? ???????? return new Scene(p); >>>>>>>> ?????} >>>>>>>> >>>>>>>> ?????public static void main(String[] args) { >>>>>>>> ???????? TestSwingInterop s = new TestSwingInterop(); >>>>>>>> ???????? s.setBounds(100, 100, 1000, 800); >>>>>>>> ???????? s.setVisible(true); >>>>>>>> ?????} >>>>>>>> } >>>>>>> I've tested this on Java8 and Java9 but didn't had a chance to run >>>>>>> it on >>>>>>> the latest master. >>>>>>> >>>>>>> The problem is that the newly created JavaFX windows don't have the >>>>>>> Native-Window as their parent but the EmbeddedStage (who is not >>>>>>> bound to >>>>>>> a native-window handle). It looks like EmbeddedStage has already been >>>>>>> prepared (see getRawHandle() : long) to support something like >>>>>>> that in >>>>>>> future but com.sun.glass.ui.Window and its subclasses have never been >>>>>>> extend to create a window based on a pure long-pointer. >>>>>>> >>>>>>> The only exception and the reason I guess the strategy would work was >>>>>>> used for Applets. >>>>>>> >>>>>>> Before diving deeper into this I wanted to get a feedback from people >>>>>>> who know things better: Does the strategy of passing along the window >>>>>>> pointer (eg from SWT, don't know about Swing yet) to Glass and >>>>>>> using it >>>>>>> as the parent pointer sound like a proper idea? >>>>>>> >>>>>>> Tom >>>>>>> From tom.schindl at bestsolution.at Tue Jul 31 13:16:33 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 31 Jul 2018 15:16:33 +0200 Subject: JavaFX SWT and Swing-Interopt In-Reply-To: <069566e6-7003-a2ab-2d92-4825030d3892@oracle.com> References: <4d3db403-e1b0-4fd3-46be-8ff1f380ed9c@bestsolution.at> <517d3afe-4385-a86b-0d5d-157843ca93c6@oracle.com> <708aacd6-a449-426a-af3a-69efeba47f6b@bestsolution.at> <20d831dc-047d-6163-cbbc-240c3ee6d12a@jugs.org> <34309715-d571-68f8-e182-7a671e32c6d1@jugs.org> <7324829f-3804-cb75-0d12-8dda70c75884@bestsolution.at> <069566e6-7003-a2ab-2d92-4825030d3892@oracle.com> Message-ID: hi, yes and I can confirm that the date-picker issue is not that dramatic on Windows. If I modify my test case just a bit by opening my own stage with a parent-stage the z-order at least can also get messed up on windows. package test; import javax.swing.JFrame; import javafx.application.Platform; import javafx.embed.swing.JFXPanel; import javafx.geometry.Pos; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ColorPicker; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; public class TestSwingInterop extends JFrame { public TestSwingInterop() { setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); final JFXPanel fxPanel = new JFXPanel(); add(fxPanel); Platform.runLater(new Runnable() { @Override public void run() { initFX(fxPanel); } }); } static void initFX(JFXPanel fxPanel) { // This method is invoked on JavaFX thread Scene scene = createScene(); fxPanel.setScene(scene); } static Scene createScene() { ColorPicker picker = new ColorPicker(); BorderPane.setAlignment(picker, Pos.TOP_LEFT); BorderPane p = new BorderPane(picker); Button button = new Button("Extra Stage"); button.setOnAction( evt -> { Stage s = new Stage(); s.setScene(new Scene(new BorderPane(new Button("Hello World")), 300, 300)); s.initOwner(button.getScene().getWindow()); s.show(); }); p.setBottom(button); return new Scene(p); } public static void main(String[] args) { TestSwingInterop s = new TestSwingInterop(); s.setBounds(100, 100, 1000, 800); s.setVisible(true); } } package test; import javafx.application.Application; import javafx.stage.Stage; public class TestPlainFX extends Application { @Override public void start(Stage primaryStage) throws Exception { primaryStage.setScene(TestSwingInterop.createScene()); primaryStage.show(); } public static void main(String[] args) { launch(args); } } If you run an click the "Extra - Stage" Button you'll notice that the main Swing window can get infront of it child (this is a similar problem than the Picker). The same does not work if you are in pure FX. Tom Am 2018-07-31 14:57, schrieb Kevin Rushforth: > OK, I can reproduce it on Mac using JDK 11-ea and the latest jfx-dev. > Can you file a bug? > > -- Kevin > > > On 7/31/2018 5:51 AM, Tom Schindl wrote: >> Hi, >> >> I'm on Mac as well and just gave 8u181 a spin and see the same problem >> (beside others eg the DropDown popup does not move with window). >> >> Just to make sure: It is curcial to not only bring up the >> DropDown-List >> but also open the Dialog-Window with the color-spectrum, ... . >> >> Tom >> >> On 31.07.18 14:34, Michael Paus wrote: >>> I did the test on a Mac. >>> >>> MacOS High Sierra >>> OpenJDK12ea4 >>> OpenJFX11ea20 (SDK) >>> >>> I just ran the code and repeated the steps given by Tom. >>> * Bring up the DropDown-List >>> * Bring up the custom color dialog >>> * Click somewhere in the JFrame >>> >>> Michael >>> >>> Am 31.07.18 um 14:19 schrieb Kevin Rushforth: >>>> I ran the test program on Windows 7 using JDK-11+24 plus my local >>>> build of openjfx 11, and I can't reproduce the problem. I suspect >>>> that >>>> Prasanta is correct in that this was fixed for FX/Swing interop by >>>> JDK-8185634 (on the FX side) and JDK-8187803 (on the AWT side). I >>>> don't know why you and Tom are still seeing this bug. What platform >>>> are you testing on? >>>> >>>> Note that this won't help SWT interop, though. A similar fix might >>>> be >>>> needed there (once we understand why the Swing interop test program >>>> isn't working for some of you). >>>> >>>> -- Kevin >>>> >>>> On 7/31/2018 4:45 AM, Michael Paus wrote: >>>>> Hi Tom >>>>> I gave it a try with the latest OpenJDK12ea and OpenJFX11ea and I >>>>> still >>>>> see the same baviour which you described. >>>>> Michael >>>>> >>>>> Am 31.07.18 um 13:08 schrieb Tom Schindl: >>>>>> Hi, >>>>>> >>>>>> I give it a try but from the bug description and discussion I >>>>>> would >>>>>> have >>>>>> assumed it deals with the opposite problems (Opening a >>>>>> Swing-Dialog >>>>>> from >>>>>> an JavaFX-Application who uses Swing-Node). >>>>>> >>>>>> I also studied the code to see if how you make a JavaFX-Stage >>>>>> having a >>>>>> different owner but I could only find changes to AWT deal with >>>>>> this. >>>>>> >>>>>> Anyways I'll try to get it the latest master running. The issue >>>>>> states >>>>>> that it is fixed in 8u182 but only 8u181 is available and there >>>>>> are no >>>>>> EA-Builds of Java8 available anymore (Looks like Oracle does not >>>>>> want >>>>>> people to test fixes for upcoming 8-update anymore) >>>>>> >>>>>> Tom >>>>>> >>>>>> On 31.07.18 11:21, Prasanta Sadhukhan wrote: >>>>>>> Hi Tom, >>>>>>> >>>>>>> I am not able to see the problem in latest workspace. I believe >>>>>>> this >>>>>>> issue is already fixed by JDK-8185634. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 7/31/2018 1:16 PM, Tom Schindl wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> In one of our customers application we have major problems when >>>>>>>> embedding JavaFX into SWT (but from my tests the situation is >>>>>>>> equal for >>>>>>>> Swing). >>>>>>>> >>>>>>>> In the end all windows (most commonly popup-windows) are >>>>>>>> affected >>>>>>>> because they don't have a parent-window assigned and so they can >>>>>>>> be >>>>>>>> hidden by the window embedding them - if the window opened is >>>>>>>> Modal like >>>>>>>> eg the one from ColorPicker the JavaFX UI is also blocked. >>>>>>>> >>>>>>>> To see what I mean just use this snippet below and do the >>>>>>>> following: >>>>>>>> * Bring up the DropDown-List >>>>>>>> * Bring up the custom color dialog >>>>>>>> * Click somewhere in the JFrame >>>>>>>> >>>>>>>> You notice the following: >>>>>>>> * JavaFX Window is moved behind Swing-Window >>>>>>>> * JavaFX UI is blocked >>>>>>>> >>>>>>>>> package test; >>>>>>>>> >>>>>>>>> import javax.swing.JFrame; >>>>>>>>> >>>>>>>>> import javafx.application.Platform; >>>>>>>>> import javafx.embed.swing.JFXPanel; >>>>>>>>> import javafx.geometry.Pos; >>>>>>>>> import javafx.scene.Scene; >>>>>>>>> import javafx.scene.control.ColorPicker; >>>>>>>>> import javafx.scene.layout.BorderPane; >>>>>>>>> >>>>>>>>> public class TestSwingInterop extends JFrame { >>>>>>>>> ???? ?????public TestSwingInterop() { >>>>>>>>> ???????? setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>>>>>>> ???????? final JFXPanel fxPanel = new JFXPanel(); >>>>>>>>> ????????? add(fxPanel); >>>>>>>>> ????????? ???????? Platform.runLater(new Runnable() { >>>>>>>>> ????????????? @Override >>>>>>>>> ????????????? public void run() { >>>>>>>>> ????????????????? initFX(fxPanel); >>>>>>>>> ????????????? } >>>>>>>>> ????????? }); >>>>>>>>> ?????} >>>>>>>>> ???? ?????private static void initFX(JFXPanel fxPanel) { >>>>>>>>> ????????? // This method is invoked on JavaFX thread >>>>>>>>> ????????? Scene scene = createScene(); >>>>>>>>> ????????? fxPanel.setScene(scene); >>>>>>>>> ????? } >>>>>>>>> ???? ?????private static Scene createScene() { >>>>>>>>> ???????? ColorPicker picker = new ColorPicker(); >>>>>>>>> ???????? BorderPane.setAlignment(picker, Pos.TOP_LEFT); >>>>>>>>> ???????? BorderPane p = new BorderPane(picker); >>>>>>>>> ??????? ???????? return new Scene(p); >>>>>>>>> ?????} >>>>>>>>> >>>>>>>>> ?????public static void main(String[] args) { >>>>>>>>> ???????? TestSwingInterop s = new TestSwingInterop(); >>>>>>>>> ???????? s.setBounds(100, 100, 1000, 800); >>>>>>>>> ???????? s.setVisible(true); >>>>>>>>> ?????} >>>>>>>>> } >>>>>>>> I've tested this on Java8 and Java9 but didn't had a chance to >>>>>>>> run >>>>>>>> it on >>>>>>>> the latest master. >>>>>>>> >>>>>>>> The problem is that the newly created JavaFX windows don't have >>>>>>>> the >>>>>>>> Native-Window as their parent but the EmbeddedStage (who is not >>>>>>>> bound to >>>>>>>> a native-window handle). It looks like EmbeddedStage has already >>>>>>>> been >>>>>>>> prepared (see getRawHandle() : long) to support something like >>>>>>>> that in >>>>>>>> future but com.sun.glass.ui.Window and its subclasses have never >>>>>>>> been >>>>>>>> extend to create a window based on a pure long-pointer. >>>>>>>> >>>>>>>> The only exception and the reason I guess the strategy would >>>>>>>> work was >>>>>>>> used for Applets. >>>>>>>> >>>>>>>> Before diving deeper into this I wanted to get a feedback from >>>>>>>> people >>>>>>>> who know things better: Does the strategy of passing along the >>>>>>>> window >>>>>>>> pointer (eg from SWT, don't know about Swing yet) to Glass and >>>>>>>> using it >>>>>>>> as the parent pointer sound like a proper idea? >>>>>>>> >>>>>>>> Tom >>>>>>>> From tom.schindl at bestsolution.at Tue Jul 31 20:14:12 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 31 Jul 2018 22:14:12 +0200 Subject: JavaFX SWT and Swing-Interopt In-Reply-To: References: <4d3db403-e1b0-4fd3-46be-8ff1f380ed9c@bestsolution.at> <517d3afe-4385-a86b-0d5d-157843ca93c6@oracle.com> <708aacd6-a449-426a-af3a-69efeba47f6b@bestsolution.at> <20d831dc-047d-6163-cbbc-240c3ee6d12a@jugs.org> <34309715-d571-68f8-e182-7a671e32c6d1@jugs.org> <7324829f-3804-cb75-0d12-8dda70c75884@bestsolution.at> <069566e6-7003-a2ab-2d92-4825030d3892@oracle.com> Message-ID: <90e9dc13-42d4-1b06-fd7e-8af9b20a78f6@bestsolution.at> Hi, I could not resist giving my idea a try and passing the native-pointer from SWT completely through JavaFX and using it as a parent on Windows created by FX. Although my C/Objective-C knowledge is next to useless it works and now Popup-Windows (eg created by a DropDown are a Native-Child of their SWT-NSWindow which means they move if you move the window, they don't hide behind their parent, ...) - they just work as they do in a native JavaFX application! I'll create an issue and we can move the discussion there. Tom On 31.07.18 15:16, Tom Schindl wrote: > hi, > > yes and I can confirm that the date-picker issue is not that dramatic on > Windows. If I modify my test case just a bit by opening my own stage > with a parent-stage the z-order at least can also get messed up on windows. > > package test; > > import javax.swing.JFrame; > > import javafx.application.Platform; > import javafx.embed.swing.JFXPanel; > import javafx.geometry.Pos; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ColorPicker; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class TestSwingInterop extends JFrame { > > ??? public TestSwingInterop() { > ??????? setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > ??????? final JFXPanel fxPanel = new JFXPanel(); > ??????? add(fxPanel); > > ??????? Platform.runLater(new Runnable() { > ??????????? @Override > ??????????? public void run() { > ??????????????? initFX(fxPanel); > ??????????? } > ??????? }); > ??? } > > ??? static void initFX(JFXPanel fxPanel) { > ??????? // This method is invoked on JavaFX thread > ??????? Scene scene = createScene(); > ??????? fxPanel.setScene(scene); > ??? } > > ??? static Scene createScene() { > ??????? ColorPicker picker = new ColorPicker(); > ??????? BorderPane.setAlignment(picker, Pos.TOP_LEFT); > ??????? BorderPane p = new BorderPane(picker); > ??????? Button button = new Button("Extra Stage"); > ??????? button.setOnAction( evt -> { > ??????????? Stage s = new Stage(); > ??????????? s.setScene(new Scene(new BorderPane(new Button("Hello > World")), 300, 300)); > ??????????? s.initOwner(button.getScene().getWindow()); > ??????????? s.show(); > ??????? }); > ??????? p.setBottom(button); > > ??????? return new Scene(p); > ??? } > > ??? public static void main(String[] args) { > ??????? TestSwingInterop s = new TestSwingInterop(); > ??????? s.setBounds(100, 100, 1000, 800); > ??????? s.setVisible(true); > ??? } > } > > package test; > > import javafx.application.Application; > import javafx.stage.Stage; > > public class TestPlainFX extends Application { > > ????@Override > ????public void start(Stage primaryStage) throws Exception { > ??????? primaryStage.setScene(TestSwingInterop.createScene()); > ??????? primaryStage.show(); > ????} > > ????public static void main(String[] args) { > ??????? launch(args); > ????} > } > > If you run an click the "Extra - Stage" Button you'll notice that the > main Swing window can get infront of it child (this is a similar problem > than the Picker). The same does not work if you are in pure FX. > > Tom > Am 2018-07-31 14:57, schrieb Kevin Rushforth: >> OK, I can reproduce it on Mac using JDK 11-ea and the latest jfx-dev. >> Can you file a bug? >> >> -- Kevin >> >> >> On 7/31/2018 5:51 AM, Tom Schindl wrote: >>> Hi, >>> >>> I'm on Mac as well and just gave 8u181 a spin and see the same problem >>> (beside others eg the DropDown popup does not move with window). >>> >>> Just to make sure: It is curcial to not only bring up the DropDown-List >>> but also open the Dialog-Window with the color-spectrum, ... . >>> >>> Tom >>> >>> On 31.07.18 14:34, Michael Paus wrote: >>>> I did the test on a Mac. >>>> >>>> MacOS High Sierra >>>> OpenJDK12ea4 >>>> OpenJFX11ea20 (SDK) >>>> >>>> I just ran the code and repeated the steps given by Tom. >>>> * Bring up the DropDown-List >>>> * Bring up the custom color dialog >>>> * Click somewhere in the JFrame >>>> >>>> Michael >>>> >>>> Am 31.07.18 um 14:19 schrieb Kevin Rushforth: >>>>> I ran the test program on Windows 7 using JDK-11+24 plus my local >>>>> build of openjfx 11, and I can't reproduce the problem. I suspect that >>>>> Prasanta is correct in that this was fixed for FX/Swing interop by >>>>> JDK-8185634 (on the FX side) and JDK-8187803 (on the AWT side). I >>>>> don't know why you and Tom are still seeing this bug. What platform >>>>> are you testing on? >>>>> >>>>> Note that this won't help SWT interop, though. A similar fix might be >>>>> needed there (once we understand why the Swing interop test program >>>>> isn't working for some of you). >>>>> >>>>> -- Kevin >>>>> >>>>> On 7/31/2018 4:45 AM, Michael Paus wrote: >>>>>> Hi Tom >>>>>> I gave it a try with the latest OpenJDK12ea and OpenJFX11ea and I >>>>>> still >>>>>> see the same baviour which you described. >>>>>> Michael >>>>>> >>>>>> Am 31.07.18 um 13:08 schrieb Tom Schindl: >>>>>>> Hi, >>>>>>> >>>>>>> I give it a try but from the bug description and discussion I would >>>>>>> have >>>>>>> assumed it deals with the opposite problems (Opening a Swing-Dialog >>>>>>> from >>>>>>> an JavaFX-Application who uses Swing-Node). >>>>>>> >>>>>>> I also studied the code to see if how you make a JavaFX-Stage >>>>>>> having a >>>>>>> different owner but I could only find changes to AWT deal with this. >>>>>>> >>>>>>> Anyways I'll try to get it the latest master running. The issue >>>>>>> states >>>>>>> that it is fixed in 8u182 but only 8u181 is available and there >>>>>>> are no >>>>>>> EA-Builds of Java8 available anymore (Looks like Oracle does not >>>>>>> want >>>>>>> people to test fixes for upcoming 8-update anymore) >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> On 31.07.18 11:21, Prasanta Sadhukhan wrote: >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> I am not able to see the problem in latest workspace. I believe >>>>>>>> this >>>>>>>> issue is already fixed by JDK-8185634. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 7/31/2018 1:16 PM, Tom Schindl wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> In one of our customers application we have major problems when >>>>>>>>> embedding JavaFX into SWT (but from my tests the situation is >>>>>>>>> equal for >>>>>>>>> Swing). >>>>>>>>> >>>>>>>>> In the end all windows (most commonly popup-windows) are affected >>>>>>>>> because they don't have a parent-window assigned and so they >>>>>>>>> can be >>>>>>>>> hidden by the window embedding them - if the window opened is >>>>>>>>> Modal like >>>>>>>>> eg the one from ColorPicker the JavaFX UI is also blocked. >>>>>>>>> >>>>>>>>> To see what I mean just use this snippet below and do the >>>>>>>>> following: >>>>>>>>> * Bring up the DropDown-List >>>>>>>>> * Bring up the custom color dialog >>>>>>>>> * Click somewhere in the JFrame >>>>>>>>> >>>>>>>>> You notice the following: >>>>>>>>> * JavaFX Window is moved behind Swing-Window >>>>>>>>> * JavaFX UI is blocked >>>>>>>>> >>>>>>>>>> package test; >>>>>>>>>> >>>>>>>>>> import javax.swing.JFrame; >>>>>>>>>> >>>>>>>>>> import javafx.application.Platform; >>>>>>>>>> import javafx.embed.swing.JFXPanel; >>>>>>>>>> import javafx.geometry.Pos; >>>>>>>>>> import javafx.scene.Scene; >>>>>>>>>> import javafx.scene.control.ColorPicker; >>>>>>>>>> import javafx.scene.layout.BorderPane; >>>>>>>>>> >>>>>>>>>> public class TestSwingInterop extends JFrame { >>>>>>>>>> ????? ?????public TestSwingInterop() { >>>>>>>>>> ????????? setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>>>>>>>> ????????? final JFXPanel fxPanel = new JFXPanel(); >>>>>>>>>> ?????????? add(fxPanel); >>>>>>>>>> ?????????? ???????? Platform.runLater(new Runnable() { >>>>>>>>>> ?????????????? @Override >>>>>>>>>> ?????????????? public void run() { >>>>>>>>>> ?????????????????? initFX(fxPanel); >>>>>>>>>> ?????????????? } >>>>>>>>>> ?????????? }); >>>>>>>>>> ??????} >>>>>>>>>> ????? ?????private static void initFX(JFXPanel fxPanel) { >>>>>>>>>> ?????????? // This method is invoked on JavaFX thread >>>>>>>>>> ?????????? Scene scene = createScene(); >>>>>>>>>> ?????????? fxPanel.setScene(scene); >>>>>>>>>> ?????? } >>>>>>>>>> ????? ?????private static Scene createScene() { >>>>>>>>>> ????????? ColorPicker picker = new ColorPicker(); >>>>>>>>>> ????????? BorderPane.setAlignment(picker, Pos.TOP_LEFT); >>>>>>>>>> ????????? BorderPane p = new BorderPane(picker); >>>>>>>>>> ???????? ???????? return new Scene(p); >>>>>>>>>> ??????} >>>>>>>>>> >>>>>>>>>> ??????public static void main(String[] args) { >>>>>>>>>> ????????? TestSwingInterop s = new TestSwingInterop(); >>>>>>>>>> ????????? s.setBounds(100, 100, 1000, 800); >>>>>>>>>> ????????? s.setVisible(true); >>>>>>>>>> ??????} >>>>>>>>>> } >>>>>>>>> I've tested this on Java8 and Java9 but didn't had a chance to run >>>>>>>>> it on >>>>>>>>> the latest master. >>>>>>>>> >>>>>>>>> The problem is that the newly created JavaFX windows don't have >>>>>>>>> the >>>>>>>>> Native-Window as their parent but the EmbeddedStage (who is not >>>>>>>>> bound to >>>>>>>>> a native-window handle). It looks like EmbeddedStage has >>>>>>>>> already been >>>>>>>>> prepared (see getRawHandle() : long) to support something like >>>>>>>>> that in >>>>>>>>> future but com.sun.glass.ui.Window and its subclasses have >>>>>>>>> never been >>>>>>>>> extend to create a window based on a pure long-pointer. >>>>>>>>> >>>>>>>>> The only exception and the reason I guess the strategy would >>>>>>>>> work was >>>>>>>>> used for Applets. >>>>>>>>> >>>>>>>>> Before diving deeper into this I wanted to get a feedback from >>>>>>>>> people >>>>>>>>> who know things better: Does the strategy of passing along the >>>>>>>>> window >>>>>>>>> pointer (eg from SWT, don't know about Swing yet) to Glass and >>>>>>>>> using it >>>>>>>>> as the parent pointer sound like a proper idea? >>>>>>>>> >>>>>>>>> Tom >>>>>>>>> -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck