From kevin.rushforth at oracle.com Wed Aug 1 18:50:21 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 1 Aug 2018 11:50:21 -0700 Subject: REMINDER: FX Rampdown Phase 2 coming on Monday (Aug 6) Message-ID: As a reminder, OpenJFX 11 will hit Rampdown Phase 2 (RDP2) at 23:59 Pacific Time on Monday, Aug 6, 2018 [1]. After that, we will fork an openjfx 11 stabilization repo; the mainline jfx-dev/rt repo, along with the 'develop' and 'master' branches of the javafxports/openjdk-jfx GitHub repo, will then be available for openjfx 12 development. During RDP2, the focus will be on stabilizing the release. We will have a process very similar to the JDK's process [2] for fixing bugs in openjfx 11 during RDP2: P1-P2 bugs can be fixed with approval; bugs in docs, tests, and demos of any priority can be fixed during RDP2 without explicit approval (other than the usual code review). We will periodically sync changes from 11 --> jfx-dev for the duration of the release, so any changes that are approved to go into 11, can go straight into 11-dev and then will be synced into jfx-dev without the developer needing to push explicitly in both places (the same model that the JDK uses). -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/022004.html [2] http://openjdk.java.net/jeps/3 From tom.schindl at bestsolution.at Wed Aug 1 20:00:49 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 1 Aug 2018 22:00:49 +0200 Subject: JavaFX SWT and Swing-Interopt In-Reply-To: <90e9dc13-42d4-1b06-fd7e-8af9b20a78f6@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> <069566e6-7003-a2ab-2d92-4825030d3892@oracle.com> <90e9dc13-42d4-1b06-fd7e-8af9b20a78f6@bestsolution.at> Message-ID: <8ec5cf4d-b28f-67dd-e2db-8001482974c2@bestsolution.at> I logged https://bugs.openjdk.java.net/browse/JDK-8208649 Tom On 31.07.18 22:14, Tom Schindl wrote: > 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 From tom.schindl at bestsolution.at Wed Aug 1 20:28:08 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 1 Aug 2018 22:28:08 +0200 Subject: JavaFX SWT and Swing-Interopt In-Reply-To: <8ec5cf4d-b28f-67dd-e2db-8001482974c2@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> <069566e6-7003-a2ab-2d92-4825030d3892@oracle.com> <90e9dc13-42d4-1b06-fd7e-8af9b20a78f6@bestsolution.at> <8ec5cf4d-b28f-67dd-e2db-8001482974c2@bestsolution.at> Message-ID: <57de4660-e25a-3535-4d82-1a81aeb2391a@bestsolution.at> Hi, I pushed my hacked together PoC to https://github.com/javafxports/openjdk-jfx/pull/145. Tom On 01.08.18 22:00, Tom Schindl wrote: > I logged https://bugs.openjdk.java.net/browse/JDK-8208649 > > Tom > > On 31.07.18 22:14, Tom Schindl wrote: >> 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 From kevin.rushforth at oracle.com Thu Aug 2 11:49:23 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 2 Aug 2018 04:49:23 -0700 Subject: [11] Review request: 8208610: Incorrect check for calling class in FXMLLoader::getDefaultClassLoader Message-ID: Please review the following: https://bugs.openjdk.java.net/browse/JDK-8208610 http://cr.openjdk.java.net/~kcr/8208610/webrev/ Evaluation is in JBS. -- Kevin From dev at marcelkliemannel.com Thu Aug 2 12:38:06 2018 From: dev at marcelkliemannel.com (dev at marcelkliemannel.com) Date: Thu, 02 Aug 2018 14:38:06 +0200 Subject: Update of JavaFX 11 snapshots in maven sonatype Message-ID: <1a1e1952c4baeaa939e176b625f77159@marcelkliemannel.com> We are currently in the migration process to Java 11 and are testing the OpenJFX snapshots from [1] intensively on all platforms. And everything works so far. The snapshots are now one month old. Since then, there have been some bug fixes (e. g. usage of JDK internal API [2]). Is there a way to update them again? And is there a plan for how to proceed with the snapshots up to the GA? - Marcel [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-July/022088.html [2] https://bugs.openjdk.java.net/browse/JDK-8195798 From arunprasad.rajkumar at oracle.com Thu Aug 2 13:06:21 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Thu, 2 Aug 2018 18:36:21 +0530 Subject: [RFR] JDK-8208622: [WebView] IllegalStateException when invoking print API with html form controls Message-ID: <1AD578E5-96AD-4D20-A72B-1F88F6030522@oracle.com> Hi, Please review the fix for following bug, https://bugs.openjdk.java.net/browse/JDK-8208622 Root cause: `RenderThemeJava` instance is associated with form controls rendering in `WebPage::prePaint` and disassociated in `WebPage::postPaint`. However, when printing is invoked, `WebPage.print` directly invokes `WebPage::paint` without invoking `WebPage::prePaint`, which causes the exception because there is no valid `RenderThemeJava` instance is available to render form controls. Proposed solution: Associate java `RenderTheme` instance with `PlatformContextJava` and make use of it while rendering FormControls. This solution also eliminates global state. Webrev: http://cr.openjdk.java.net/~arajkumar/8208622/webrev Regards, Arun From nlisker at gmail.com Fri Aug 3 07:58:44 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 3 Aug 2018 10:58:44 +0300 Subject: Code conventions formalization Message-ID: Hi all, As we're getting closer to 12 and the GitHub repo is gaining traction, I think we should start formalizing in writing the exact code conventions we want to use to decrease future mess. The wiki has some rules [1], but there are areas which are still fuzzy. The check tools could also use an update. Just a few specific points: * Line length limit vary greatly even withing the same class. * Number of empty lines before and after closing bracer `}` of classes (and inner classes) varies. * Annotations sometimes appear on the same line and sometimes above what they are annotating. * I recommend we enforce using @Override wherever applicable, it can only help. * Usage of 'var' (should probably link to the style guide by Stuart Marks). After we decide on what we care about and in what way, we should supply a formatter for each IDE (either in the repo or another source) so that contributors can easily plug it in and get everything right. - Nir [1] https://wiki.openjdk.java.net/display/OpenJFX/Code+Style+Rules From tom.schindl at bestsolution.at Fri Aug 3 18:44:04 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 3 Aug 2018 20:44:04 +0200 Subject: Skia Pipeline Message-ID: Hi, Has anyone ever explored if it would be possible to implement a 2d-Graphics-Pipeline using Skia? 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 nakajima.akira at nttcom.co.jp Mon Aug 6 02:36:11 2018 From: nakajima.akira at nttcom.co.jp (Nakajima Akira) Date: Mon, 6 Aug 2018 11:36:11 +0900 Subject: Review Request JDK-8207932 : Wrong rendering of variation sequences Message-ID: <40a4bf28-91ed-08e1-c77d-8aa94db622d7@nttcom.co.jp> Hi, I'd like to request a review for JDK-8207932. [1] https://bugs.openjdk.java.net/browse/JDK-8207932 [2] https://github.com/javafxports/openjdk-jfx/pull/126 Includes 2 patches (1) rendering variation sequences (for Win,MAC only) 55d85b5 https://github.com/javafxports/openjdk-jfx/pull/126/commits/55d85b5175296346266ebb78adbb038807a28f3f (2) rendering variation sequences (Linux) 805207a https://github.com/javafxports/openjdk-jfx/commit/805207ad71dac2759b6a100c05ee6446b82dba9c Thanks Akira Nakajima -------------------------------------- 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 tom.schindl at bestsolution.at Mon Aug 6 18:39:05 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 6 Aug 2018 20:39:05 +0200 Subject: Skia Pipeline In-Reply-To: References: Message-ID: <956822c8-585e-8b63-a197-df7beaa039d9@bestsolution.at> Hi, right and because I'm not really interested in Java 3d (my take on that is if you need 3d that you'd better use the native techs OpenGL/Vulkan/Metal/DirectX and integrate them into the FX) I'm not really worried that 3d is not available in such a render-pipeline. The first step although would be to write a JNI-Bindings for Skia and/or using JavaCPP - I guess Panama is too far away to help us ;-) I guess I'll start digging deeper in the next weeks. Tom On 06.08.18 10:12, Matthias H?nel wrote: > Hi Tom, > > actually, I analyzed this in the past and it seems to be possible. > We would benefit from the ANGLE implementation underneath. > > regards > Matthias > > Matthias H?nel > haenel at onexip.com > > onexip GmbH > Am Waldschloesschen 2 | D-01099?Dresden | Germany > > http://www.ultramixer.com > http://www.onexip.com > > >> Am 03.08.2018 um 20:44 schrieb Tom Schindl >> >: >> >> Hi, >> >> Has anyone ever explored if it would be possible to implement a >> 2d-Graphics-Pipeline using Skia? >> >> Tom >> >> -- >> Tom Schindl, CTO >> BestSolution.at EDV Systemhaus GmbH >> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From mp at jugs.org Mon Aug 6 21:15:30 2018 From: mp at jugs.org (Michael Paus) Date: Mon, 6 Aug 2018 23:15:30 +0200 Subject: Skia Pipeline In-Reply-To: <956822c8-585e-8b63-a197-df7beaa039d9@bestsolution.at> References: <956822c8-585e-8b63-a197-df7beaa039d9@bestsolution.at> Message-ID: Hi, what do you want to achieve with Skia? The rendering technique used by Skia seems to be very similar to what JavaFX does. My impression is that JavaFX has been very much influenced by it. I'd first do some tests to see whether the performance is really better or whatever your critera are. Keep us updated. Michael Am 06.08.18 um 20:39 schrieb Tom Schindl: > Hi, > > right and because I'm not really interested in Java 3d (my take on that > is if you need 3d that you'd better use the native techs > OpenGL/Vulkan/Metal/DirectX and integrate them into the FX) I'm not > really worried that 3d is not available in such a render-pipeline. > > The first step although would be to write a JNI-Bindings for Skia and/or > using JavaCPP - I guess Panama is too far away to help us ;-) I guess > I'll start digging deeper in the next weeks. > > Tom > > On 06.08.18 10:12, Matthias H?nel wrote: >> Hi Tom, >> >> actually, I analyzed this in the past and it seems to be possible. >> We would benefit from the ANGLE implementation underneath. >> >> regards >> Matthias >> >> Matthias H?nel >> haenel at onexip.com >> >> onexip GmbH >> Am Waldschloesschen 2 | D-01099?Dresden | Germany >> >> http://www.ultramixer.com >> http://www.onexip.com >> >> >>> Am 03.08.2018 um 20:44 schrieb Tom Schindl >>> >: >>> >>> Hi, >>> >>> Has anyone ever explored if it would be possible to implement a >>> 2d-Graphics-Pipeline using Skia? >>> >>> 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 nakajima.akira at nttcom.co.jp Mon Aug 6 23:17:31 2018 From: nakajima.akira at nttcom.co.jp (Nakajima Akira) Date: Tue, 7 Aug 2018 08:17:31 +0900 Subject: [javafxports/openjdk-jfx] JDK-8207932 : Wrong rendering of variation sequences (#126) In-Reply-To: References: Message-ID: Hi Kevin, Sorry. I pushed to different branch, since I don't know whether it is OK to mix two different patches (for Win/Mac and for Linux). Now I pushed patch(for Linux) to this branch. Would this be right? (1) rendering variation sequences (for Win,MAC only) 55d85b5 https://github.com/javafxports/openjdk-jfx/pull/126/commits/55d85b5175296346266ebb78adbb038807a28f3f (2) rendering variation sequences (for Linux) ea68aa7 https://github.com/javafxports/openjdk-jfx/pull/126/commits/ea68aa71d94e370e739556df0afeea105b1d07cb Thanks Akira Nakajima On 2018/08/06 21:48, Kevin Rushforth wrote: > I pushed patch for Linux. > rendering variation sequences (Linux) > 805207a > > > The above commit is not referenced by this PR. It looks like you pushed > it to a different branch than the one which this PR references. We > cannot review it in its current state. From nlisker at gmail.com Tue Aug 7 01:12:50 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 7 Aug 2018 04:12:50 +0300 Subject: Swing module's module-info file Message-ID: Hi, I didn't follow all the latest changes to the Swing module, but I notice now its module-info.java file is not in the same place where other modules have theirs: It's under javafx.swing\src\main\module-info instead of javafx.\src\main\java. Is there a reason for this? - Nir From prasanta.sadhukhan at oracle.com Tue Aug 7 04:51:01 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 7 Aug 2018 10:21:01 +0530 Subject: Swing module's module-info file In-Reply-To: References: Message-ID: This is because if fx is compiled with a jdk version which does not have jdk.unsupported.desktop module then having module-info.java in its original place would cause compilation error as module-info.java contains requires static jdk.unsupported.desktop; So, the idea was to copy the file into a directory which is not on the module-source-path. Then build.gradle copy it from there to gensrc directory optionally filtering the above line ?task copyModuleInfo(type: Copy, description: "copy module-info file to gensrc") { ??????? from "src/main/module-info/module-info.java" ??????? into "$buildDir/gensrc/java/" ??????? filter { line-> ??????????? !HAS_UNSUPPORTED_DESKTOP && line.contains('jdk.unsupported.desktop') ? null : line ??????? } ??? } Regards Prasanta On 8/7/2018 6:42 AM, Nir Lisker wrote: > Hi, > > I didn't follow all the latest changes to the Swing module, but I notice > now its module-info.java file is not in the same place where other modules > have theirs: > > It's under javafx.swing\src\main\module-info instead of > javafx.\src\main\java. > > Is there a reason for this? > > - Nir From lenborje at gmail.com Tue Aug 7 09:28:16 2018 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Tue, 7 Aug 2018 11:28:16 +0200 Subject: Fate of jdk.packager and jdk.packager.services? Message-ID: <938A17F1-B35B-4AA3-9635-8AB67EFF8FA9@gmail.com> I'm migrating to JDK 11 and OpenJFX 11, and would like to continue using the packager and the associated packager service (i.e. the UserJvmOptions). AFAIK, those are gone from the available binary builds, but still there in the code. Is there a way to use them without resorting to build openjfx myself? If not, is there some alternative to the UserJvmOptions? (I'm currently working around my problems by building both openjfx and the JDK, and bundling openjfx with the JDK, just like in the good old days...) Best regards, /Lennart B?rjeson From kevin.rushforth at oracle.com Tue Aug 7 11:15:35 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Aug 2018 04:15:35 -0700 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: <938A17F1-B35B-4AA3-9635-8AB67EFF8FA9@gmail.com> References: <938A17F1-B35B-4AA3-9635-8AB67EFF8FA9@gmail.com> Message-ID: We are proposing a JEP to add a new 'jpackager' tool [1] as a replacement for javapackager. The discussion is on core-libs-dev [2] [3] [4]. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054296.html [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054565.html On 8/7/2018 2:28 AM, Lennart B?rjeson wrote: > I'm migrating to JDK 11 and OpenJFX 11, and would like to continue using the packager and the associated packager service (i.e. the UserJvmOptions). > > AFAIK, those are gone from the available binary builds, but still there in the code. Is there a way to use them without resorting to build openjfx myself? If not, is there some alternative to the UserJvmOptions? > > > (I'm currently working around my problems by building both openjfx and the JDK, and bundling openjfx with the JDK, just like in the good old days...) > > Best regards, > > /Lennart B?rjeson > > From nlisker at gmail.com Tue Aug 7 11:45:32 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 7 Aug 2018 14:45:32 +0300 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: <938A17F1-B35B-4AA3-9635-8AB67EFF8FA9@gmail.com> References: <938A17F1-B35B-4AA3-9635-8AB67EFF8FA9@gmail.com> Message-ID: Hi Lennart, You should be able to use the packager from JDK 10, see https://bugs.openjdk.java.net/browse/JDK-8203379. There is a draft for a replacement, see https://bugs.openjdk.java.net/browse/JDK-8200758. - Nir On Tue, Aug 7, 2018 at 12:28 PM, Lennart B?rjeson wrote: > I'm migrating to JDK 11 and OpenJFX 11, and would like to continue using > the packager and the associated packager service (i.e. the UserJvmOptions). > > AFAIK, those are gone from the available binary builds, but still there in > the code. Is there a way to use them without resorting to build openjfx > myself? If not, is there some alternative to the UserJvmOptions? > > > (I'm currently working around my problems by building both openjfx and the > JDK, and bundling openjfx with the JDK, just like in the good old days...) > > Best regards, > > /Lennart B?rjeson > > > From nlisker at gmail.com Tue Aug 7 12:02:39 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 7 Aug 2018 15:02:39 +0300 Subject: Swing module's module-info file In-Reply-To: References: Message-ID: Thanks for the info. I'm working on updating the Eclipse files and this is causing problems for javafx.swing. When will the minimum version be bumped to 11? On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan < prasanta.sadhukhan at oracle.com> wrote: > This is because if fx is compiled with a jdk version which does not have > jdk.unsupported.desktop module then having module-info.java in its original > place would cause compilation error as module-info.java contains > > requires static jdk.unsupported.desktop; > > So, the idea was to copy the file into a directory which is not on the > module-source-path. Then build.gradle copy it from there to gensrc > directory optionally filtering the above line > task copyModuleInfo(type: Copy, description: "copy module-info file to > gensrc") { > from "src/main/module-info/module-info.java" > into "$buildDir/gensrc/java/" > filter { line-> > !HAS_UNSUPPORTED_DESKTOP && line.contains('jdk.unsupported.desktop') > ? null : line > } > } > > Regards > Prasanta > > On 8/7/2018 6:42 AM, Nir Lisker wrote: > >> Hi, >> >> I didn't follow all the latest changes to the Swing module, but I notice >> now its module-info.java file is not in the same place where other modules >> have theirs: >> >> It's under javafx.swing\src\main\module-info instead of >> javafx.\src\main\java. >> >> Is there a reason for this? >> >> - Nir >> > > From lenborje at gmail.com Tue Aug 7 12:03:22 2018 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Tue, 7 Aug 2018 14:03:22 +0200 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: References: <938A17F1-B35B-4AA3-9635-8AB67EFF8FA9@gmail.com> Message-ID: <613E292A-76CB-4EEB-9673-558AC5C621E7@gmail.com> Well, while I can surely use the packager from JDK 10 and bundle my application with 11, I'd still miss out on the packager service, i.e. the application would not be able to use the UserJvmOptions. It seems to me the packager service has been completely forgotten? JDK-8200758 does not mention it at all. /Lennart > 7 aug. 2018 kl. 13:45 skrev Nir Lisker : > > Hi Lennart, > > You should be able to use the packager from JDK 10, see https://bugs.openjdk.java.net/browse/JDK-8203379 . > > There is a draft for a replacement, see https://bugs.openjdk.java.net/browse/JDK-8200758 . > > - Nir > > On Tue, Aug 7, 2018 at 12:28 PM, Lennart B?rjeson > wrote: > I'm migrating to JDK 11 and OpenJFX 11, and would like to continue using the packager and the associated packager service (i.e. the UserJvmOptions). > > AFAIK, those are gone from the available binary builds, but still there in the code. Is there a way to use them without resorting to build openjfx myself? If not, is there some alternative to the UserJvmOptions? > > > (I'm currently working around my problems by building both openjfx and the JDK, and bundling openjfx with the JDK, just like in the good old days...) > > Best regards, > > /Lennart B?rjeson > > > From tom.schindl at bestsolution.at Tue Aug 7 12:11:41 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 7 Aug 2018 14:11:41 +0200 Subject: Swing module's module-info file In-Reply-To: References: Message-ID: <55d7742c-e691-01eb-2aae-1a54dec64fd3@bestsolution.at> Well I simply added the folder to my class-folders and things then work perfectly fine inside Eclipse Tom On 07.08.18 14:02, Nir Lisker wrote: > Thanks for the info. I'm working on updating the Eclipse files and this is > causing problems for javafx.swing. When will the minimum version be bumped > to 11? > > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan < > prasanta.sadhukhan at oracle.com> wrote: > >> This is because if fx is compiled with a jdk version which does not have >> jdk.unsupported.desktop module then having module-info.java in its original >> place would cause compilation error as module-info.java contains >> >> requires static jdk.unsupported.desktop; >> >> So, the idea was to copy the file into a directory which is not on the >> module-source-path. Then build.gradle copy it from there to gensrc >> directory optionally filtering the above line >> task copyModuleInfo(type: Copy, description: "copy module-info file to >> gensrc") { >> from "src/main/module-info/module-info.java" >> into "$buildDir/gensrc/java/" >> filter { line-> >> !HAS_UNSUPPORTED_DESKTOP && line.contains('jdk.unsupported.desktop') >> ? null : line >> } >> } >> >> Regards >> Prasanta >> >> On 8/7/2018 6:42 AM, Nir Lisker wrote: >> >>> Hi, >>> >>> I didn't follow all the latest changes to the Swing module, but I notice >>> now its module-info.java file is not in the same place where other modules >>> have theirs: >>> >>> It's under javafx.swing\src\main\module-info instead of >>> javafx.\src\main\java. >>> >>> Is there a reason for this? >>> >>> - Nir >>> >> >> -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From tom.schindl at bestsolution.at Tue Aug 7 12:22:10 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 7 Aug 2018 14:22:10 +0200 Subject: OpenJFX 11 in OSGi In-Reply-To: <7929fcef-7d97-6874-a098-fdbba79a59d0@bestsolution.at> References: <2ddccab0-0d42-fe94-7a23-1b78f1a6cd9b@bestsolution.at> <4f7584b3-5a00-437c-3e52-3c3ca7a8eb52@oracle.com> <7929fcef-7d97-6874-a098-fdbba79a59d0@bestsolution.at> Message-ID: <6abff12b-fdde-0989-f602-eaed839d0208@bestsolution.at> Hi, For those not following my blog [1]. We've managed to successfully run OpenJFX-11 modules inside Equinox using the same approach we've already supplied for FXCanvas. We "simply" spin up a new Module-Layer containing the JavaFX-bits. Tom [1]https://tomsondev.bestsolution.at/2018/08/04/supporting-openjfx-11-from-jdk11-onwards-in-efxclipse/ On 03.05.18 14:39, Tom Schindl wrote: > Hi, > > On 03.05.18 14:05, Kevin Rushforth wrote: >> >> >> On 5/3/2018 4:54 AM, Tom Schindl wrote: >>> Hi, >>> >>> Following up on the native-libs-in-modules I wonder how we deal with >>> OSGi-Applications like Eclipse RCP. >>> >>> Do OpenJFX-Binaries run only on the module-path or can they run on the >>> classpath as well. If they can run on the classpath, can they maybe >>> loaded as OSGi-Bundles (if they contain the necessary OSGi-Meta-Data). >> >> Only on the module path. I think it would be a step backwards to rework >> them so they could also run on the classpath. >> > > Ok - that's what I somehow feared would be the case. I filed > https://github.com/eclipse/efxclipse-rt/issues/217 but anyone who needs > OpenFX running in OSGi is requested to chime in and maybe provide help > to get this sorted out. > > 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 Aug 7 12:49:44 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Aug 2018 05:49:44 -0700 Subject: OpenJFX 11 in OSGi In-Reply-To: <6abff12b-fdde-0989-f602-eaed839d0208@bestsolution.at> References: <2ddccab0-0d42-fe94-7a23-1b78f1a6cd9b@bestsolution.at> <4f7584b3-5a00-437c-3e52-3c3ca7a8eb52@oracle.com> <7929fcef-7d97-6874-a098-fdbba79a59d0@bestsolution.at> <6abff12b-fdde-0989-f602-eaed839d0208@bestsolution.at> Message-ID: <92648075-5419-b61c-d076-294eecf3cade@oracle.com> Nice! -- Kevin On 8/7/2018 5:22 AM, Tom Schindl wrote: > Hi, > > For those not following my blog [1]. We've managed to successfully run > OpenJFX-11 modules inside Equinox using the same approach we've already > supplied for FXCanvas. We "simply" spin up a new Module-Layer containing > the JavaFX-bits. > > Tom > > [1]https://tomsondev.bestsolution.at/2018/08/04/supporting-openjfx-11-from-jdk11-onwards-in-efxclipse/ > > On 03.05.18 14:39, Tom Schindl wrote: >> Hi, >> >> On 03.05.18 14:05, Kevin Rushforth wrote: >>> >>> On 5/3/2018 4:54 AM, Tom Schindl wrote: >>>> Hi, >>>> >>>> Following up on the native-libs-in-modules I wonder how we deal with >>>> OSGi-Applications like Eclipse RCP. >>>> >>>> Do OpenJFX-Binaries run only on the module-path or can they run on the >>>> classpath as well. If they can run on the classpath, can they maybe >>>> loaded as OSGi-Bundles (if they contain the necessary OSGi-Meta-Data). >>> Only on the module path. I think it would be a step backwards to rework >>> them so they could also run on the classpath. >>> >> Ok - that's what I somehow feared would be the case. I filed >> https://github.com/eclipse/efxclipse-rt/issues/217 but anyone who needs >> OpenFX running in OSGi is requested to chime in and maybe provide help >> to get this sorted out. >> >> Tom >> From kevin.rushforth at oracle.com Tue Aug 7 12:53:19 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Aug 2018 05:53:19 -0700 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: <613E292A-76CB-4EEB-9673-558AC5C621E7@gmail.com> References: <938A17F1-B35B-4AA3-9635-8AB67EFF8FA9@gmail.com> <613E292A-76CB-4EEB-9673-558AC5C621E7@gmail.com> Message-ID: Can you subscribe to core-libs-dev and reply to the JEP discussion indicating how you use UserJvmOptions? We hadn't planned on providing the jdk.packager.services module (at least not in the initial version), but would be interested to know how useful it was. Having said that, the module is still there in the prototype in the jdk sandbox. -- Kevin On 8/7/2018 5:03 AM, Lennart B?rjeson wrote: > Well, while I can surely use the packager from JDK 10 and bundle my application with 11, I'd still miss out on the packager service, i.e. the application would not be able to use the UserJvmOptions. > > It seems to me the packager service has been completely forgotten? JDK-8200758 does not mention it at all. > > /Lennart > >> 7 aug. 2018 kl. 13:45 skrev Nir Lisker : >> >> Hi Lennart, >> >> You should be able to use the packager from JDK 10, see https://bugs.openjdk.java.net/browse/JDK-8203379 . >> >> There is a draft for a replacement, see https://bugs.openjdk.java.net/browse/JDK-8200758 . >> >> - Nir >> >> On Tue, Aug 7, 2018 at 12:28 PM, Lennart B?rjeson > wrote: >> I'm migrating to JDK 11 and OpenJFX 11, and would like to continue using the packager and the associated packager service (i.e. the UserJvmOptions). >> >> AFAIK, those are gone from the available binary builds, but still there in the code. Is there a way to use them without resorting to build openjfx myself? If not, is there some alternative to the UserJvmOptions? >> >> >> (I'm currently working around my problems by building both openjfx and the JDK, and bundling openjfx with the JDK, just like in the good old days...) >> >> Best regards, >> >> /Lennart B?rjeson >> >> >> From org.openjdk at io7m.com Tue Aug 7 13:02:34 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Tue, 7 Aug 2018 14:02:34 +0100 Subject: OpenJFX 11 in OSGi In-Reply-To: <6abff12b-fdde-0989-f602-eaed839d0208@bestsolution.at> References: <2ddccab0-0d42-fe94-7a23-1b78f1a6cd9b@bestsolution.at> <4f7584b3-5a00-437c-3e52-3c3ca7a8eb52@oracle.com> <7929fcef-7d97-6874-a098-fdbba79a59d0@bestsolution.at> <6abff12b-fdde-0989-f602-eaed839d0208@bestsolution.at> Message-ID: <20180807140234.4501a8f1@almond.int.arc7.info> On 2018-08-07T14:22:10 +0200 Tom Schindl wrote: > Hi, > > For those not following my blog [1]. We've managed to successfully run > OpenJFX-11 modules inside Equinox using the same approach we've already > supplied for FXCanvas. We "simply" spin up a new Module-Layer containing > the JavaFX-bits. > Nice work. I kept an eye on the GitHub ticket you (I think it was you, apologies if it wasn't!) filed a while back to track this. I never did find a decent solution, so I'm glad you came up with something. Is this applicable to Felix? It seems like it might use Equinox-specific facilities. -- Mark Raynsford | http://www.io7m.com From tom.schindl at bestsolution.at Tue Aug 7 13:27:33 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 7 Aug 2018 15:27:33 +0200 Subject: OpenJFX 11 in OSGi In-Reply-To: <20180807140234.4501a8f1@almond.int.arc7.info> References: <2ddccab0-0d42-fe94-7a23-1b78f1a6cd9b@bestsolution.at> <4f7584b3-5a00-437c-3e52-3c3ca7a8eb52@oracle.com> <7929fcef-7d97-6874-a098-fdbba79a59d0@bestsolution.at> <6abff12b-fdde-0989-f602-eaed839d0208@bestsolution.at> <20180807140234.4501a8f1@almond.int.arc7.info> Message-ID: Hi, No this is an Equinox only solution! I'm not sure Felix does provide a way to hook into the classloading system and catch problems. The approach of dynamically spinning up a layer although should work in general. I'm not sure about the Classloader-Delegation in Felix but if you write a custom Felix-Application launcher you and make Felix use the correct Layer-Classloader you are good to go ;-) IIRC the OSGi-People are working on a general solution to run Java-Modules inside OSGi but I haven't digged up the current state. Tom On 07.08.18 15:02, Mark Raynsford wrote: > On 2018-08-07T14:22:10 +0200 > Tom Schindl wrote: > >> Hi, >> >> For those not following my blog [1]. We've managed to successfully run >> OpenJFX-11 modules inside Equinox using the same approach we've already >> supplied for FXCanvas. We "simply" spin up a new Module-Layer containing >> the JavaFX-bits. >> > > Nice work. I kept an eye on the GitHub ticket you (I think it was you, > apologies if it wasn't!) filed a while back to track this. I never did > find a decent solution, so I'm glad you came up with something. > > Is this applicable to Felix? It seems like it might use > Equinox-specific facilities. > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From sverre.moe at gmail.com Tue Aug 7 13:44:39 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Tue, 7 Aug 2018 15:44:39 +0200 Subject: OpenJFX status update In-Reply-To: <29eb13dd-6d51-3596-0be6-ee4456761040@oracle.com> References: <27c67144-7b3d-311d-2479-f8a73d851dd5@oracle.com> <8762a0df-cde9-1e01-3000-7faa463fd2df@gmail.com> <29eb13dd-6d51-3596-0be6-ee4456761040@oracle.com> Message-ID: > > The javapackager tool and associated jdk.packager and > jdk.packager.services modules have been removed from the JDK along with > JavaFX. They are not part of the standalone JavaFX builds. > > -- Kevin > > What options are there if one relies on the javapackager to create native runtime images and native package installers? We cannot then upgrade to Java 11 since it has been removed. Neither can we use jlink instead since our application is not yet modularized. Though jlink does not create the There is a draft for a new jpackager tool, but when it will be ready seems to be undetermined. http://openjdk.java.net/jeps/8200758 Have anyone tried to build the javapackager code with OpenJDK 11 and create a javapackager executable file? It could be used as a standalone tool until the new jpackager is ready. /Sverre From kevin.rushforth at oracle.com Tue Aug 7 14:10:08 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Aug 2018 07:10:08 -0700 Subject: OpenJFX status update In-Reply-To: References: <27c67144-7b3d-311d-2479-f8a73d851dd5@oracle.com> <8762a0df-cde9-1e01-3000-7faa463fd2df@gmail.com> <29eb13dd-6d51-3596-0be6-ee4456761040@oracle.com> Message-ID: <9563e7ff-3374-d025-0d50-4d5da056d454@oracle.com> > Have anyone tried to build the javapackager code with OpenJDK 11 and create > a javapackager executable file? It could be used as a standalone tool until > the new jpackager is ready. This shouldn't be too hard to do, presuming that you can't use the javapackager from JDK 10. You will need to add the qualified exports on the command line when you run it. -- Kevin On 8/7/2018 6:44 AM, Sverre Moe wrote: >> The javapackager tool and associated jdk.packager and >> jdk.packager.services modules have been removed from the JDK along with >> JavaFX. They are not part of the standalone JavaFX builds. >> >> -- Kevin >> >> What options are there if one relies on the javapackager to create native > runtime images and native package installers? > > We cannot then upgrade to Java 11 since it has been removed. > Neither can we use jlink instead since our application is not yet > modularized. Though jlink does not create the > > There is a draft for a new jpackager tool, but when it will be ready seems > to be undetermined. > http://openjdk.java.net/jeps/8200758 > > Have anyone tried to build the javapackager code with OpenJDK 11 and create > a javapackager executable file? It could be used as a standalone tool until > the new jpackager is ready. > > /Sverre From kevin.rushforth at oracle.com Tue Aug 7 14:49:00 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Aug 2018 07:49:00 -0700 Subject: [11] Review request: 8201563: Update copyright header for files modified in 2018 Message-ID: Please review the following to update the date in the copyright header (JDK-8201563) and also fix a garbled copyright header (JDK-8202357). https://bugs.openjdk.java.net/browse/JDK-8201563 https://bugs.openjdk.java.net/browse/JDK-8202357 http://cr.openjdk.java.net/~kcr/8201563/webrev/ -- Kevin From johns at msli.com Tue Aug 7 16:16:47 2018 From: johns at msli.com (johns at msli.com) Date: Tue, 7 Aug 2018 09:16:47 -0700 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: <613E292A-76CB-4EEB-9673-558AC5C621E7@gmail.com> References: <938A17F1-B35B-4AA3-9635-8AB67EFF8FA9@gmail.com> <613E292A-76CB-4EEB-9673-558AC5C621E7@gmail.com> Message-ID: <141a4082-5728-2f11-45e1-6385eea535bb@msli.com> The motivation for a new packager states a need for a a packager, but not why the javapackager can't continue. With all the work that went into javapackager, why can't it simple be released for continued development outside Oracle, if they don't want to maintain it. The javapackager has worked well for a few years, so why reinvent a packager with fewer features, rather than expand features, and clear bugs? On 08/07/2018 05:03 AM, Lennart B?rjeson wrote: > Well, while I can surely use the packager from JDK 10 and bundle my application with 11, I'd still miss out on the packager service, i.e. the application would not be able to use the UserJvmOptions. > > It seems to me the packager service has been completely forgotten? JDK-8200758 does not mention it at all. > > /Lennart > >> 7 aug. 2018 kl. 13:45 skrev Nir Lisker : >> >> Hi Lennart, >> >> You should be able to use the packager from JDK 10, see https://bugs.openjdk.java.net/browse/JDK-8203379 . >> >> There is a draft for a replacement, see https://bugs.openjdk.java.net/browse/JDK-8200758 . >> >> - Nir >> >> On Tue, Aug 7, 2018 at 12:28 PM, Lennart B?rjeson > wrote: >> I'm migrating to JDK 11 and OpenJFX 11, and would like to continue using the packager and the associated packager service (i.e. the UserJvmOptions). >> >> AFAIK, those are gone from the available binary builds, but still there in the code. Is there a way to use them without resorting to build openjfx myself? If not, is there some alternative to the UserJvmOptions? >> >> >> (I'm currently working around my problems by building both openjfx and the JDK, and bundling openjfx with the JDK, just like in the good old days...) >> >> Best regards, >> >> /Lennart B?rjeson >> >> >> From nlisker at gmail.com Tue Aug 7 16:34:48 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 7 Aug 2018 19:34:48 +0300 Subject: Swing module's module-info file In-Reply-To: <55d7742c-e691-01eb-2aae-1a54dec64fd3@bestsolution.at> References: <55d7742c-e691-01eb-2aae-1a54dec64fd3@bestsolution.at> Message-ID: So you rebuilt the JDK with the new jdk.unsupported.desktop module? On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl wrote: > Well I simply added the folder to my class-folders and things then work > perfectly fine inside Eclipse > > Tom > > On 07.08.18 14:02, Nir Lisker wrote: > > Thanks for the info. I'm working on updating the Eclipse files and this > is > > causing problems for javafx.swing. When will the minimum version be > bumped > > to 11? > > > > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan < > > prasanta.sadhukhan at oracle.com> wrote: > > > >> This is because if fx is compiled with a jdk version which does not have > >> jdk.unsupported.desktop module then having module-info.java in its > original > >> place would cause compilation error as module-info.java contains > >> > >> requires static jdk.unsupported.desktop; > >> > >> So, the idea was to copy the file into a directory which is not on the > >> module-source-path. Then build.gradle copy it from there to gensrc > >> directory optionally filtering the above line > >> task copyModuleInfo(type: Copy, description: "copy module-info file to > >> gensrc") { > >> from "src/main/module-info/module-info.java" > >> into "$buildDir/gensrc/java/" > >> filter { line-> > >> !HAS_UNSUPPORTED_DESKTOP && line.contains('jdk. > unsupported.desktop') > >> ? null : line > >> } > >> } > >> > >> Regards > >> Prasanta > >> > >> On 8/7/2018 6:42 AM, Nir Lisker wrote: > >> > >>> Hi, > >>> > >>> I didn't follow all the latest changes to the Swing module, but I > notice > >>> now its module-info.java file is not in the same place where other > modules > >>> have theirs: > >>> > >>> It's under javafx.swing\src\main\module-info instead of > >>> javafx.\src\main\java. > >>> > >>> Is there a reason for this? > >>> > >>> - Nir > >>> > >> > >> > > -- > 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 Aug 7 16:49:59 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Aug 2018 09:49:59 -0700 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: <141a4082-5728-2f11-45e1-6385eea535bb@msli.com> References: <938A17F1-B35B-4AA3-9635-8AB67EFF8FA9@gmail.com> <613E292A-76CB-4EEB-9673-558AC5C621E7@gmail.com> <141a4082-5728-2f11-45e1-6385eea535bb@msli.com> Message-ID: <56f07481-3c94-9931-c419-636cb42d7e84@oracle.com> Someone could certainly do that. We think there is enough interest in having a standard tool that it is worth spending effort on a replacement tool that will be part of standard JDK builds, including OpenJDK builds that have never had javapackager. In the mean time, if a standalone build of javapackager works for you, then that's great. -- Kevin On 8/7/2018 9:16 AM, johns at msli.com wrote: > The motivation for a new packager states a need for a a packager, but > not why the javapackager can't continue. > > With all the work that went into javapackager, why can't it simple be > released for continued development outside Oracle, if they don't want to > maintain it. > > The javapackager has worked well for a few years, so why reinvent a > packager with fewer features, rather than expand features, and clear bugs? > > On 08/07/2018 05:03 AM, Lennart B?rjeson wrote: >> Well, while I can surely use the packager from JDK 10 and bundle my application with 11, I'd still miss out on the packager service, i.e. the application would not be able to use the UserJvmOptions. >> >> It seems to me the packager service has been completely forgotten? JDK-8200758 does not mention it at all. >> >> /Lennart >> >>> 7 aug. 2018 kl. 13:45 skrev Nir Lisker : >>> >>> Hi Lennart, >>> >>> You should be able to use the packager from JDK 10, see https://bugs.openjdk.java.net/browse/JDK-8203379 . >>> >>> There is a draft for a replacement, see https://bugs.openjdk.java.net/browse/JDK-8200758 . >>> >>> - Nir >>> >>> On Tue, Aug 7, 2018 at 12:28 PM, Lennart B?rjeson > wrote: >>> I'm migrating to JDK 11 and OpenJFX 11, and would like to continue using the packager and the associated packager service (i.e. the UserJvmOptions). >>> >>> AFAIK, those are gone from the available binary builds, but still there in the code. Is there a way to use them without resorting to build openjfx myself? If not, is there some alternative to the UserJvmOptions? >>> >>> >>> (I'm currently working around my problems by building both openjfx and the JDK, and bundling openjfx with the JDK, just like in the good old days...) >>> >>> Best regards, >>> >>> /Lennart B?rjeson >>> >>> >>> From mp at jugs.org Tue Aug 7 17:02:06 2018 From: mp at jugs.org (Michael Paus) Date: Tue, 7 Aug 2018 19:02:06 +0200 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: <56f07481-3c94-9931-c419-636cb42d7e84@oracle.com> References: <938A17F1-B35B-4AA3-9635-8AB67EFF8FA9@gmail.com> <613E292A-76CB-4EEB-9673-558AC5C621E7@gmail.com> <141a4082-5728-2f11-45e1-6385eea535bb@msli.com> <56f07481-3c94-9931-c419-636cb42d7e84@oracle.com> Message-ID: <4c6d4320-4e5e-8741-3a71-659f66c7f059@jugs.org> I don't know whether the following statement is still valid, but if it is, then it may not be worth the effort to resurrect the old javapackager if at least an EA build of the new one is so close. On 6/27/2018 3:30 PM, Kevin Rushforth wrote: >/We're aiming to get this into JDK 12 early enough so that an EA build />/would be available around the time JDK 11 ships. That will allow you />/to take a jlinked image with JDK 11 and package it up using (the EA) />/jpackager./ Michael Am 07.08.18 um 18:49 schrieb Kevin Rushforth: > Someone could certainly do that. > > We think there is enough interest in having a standard tool that it is > worth spending effort on a replacement tool that will be part of > standard JDK builds, including OpenJDK builds that have never had > javapackager. In the mean time, if a standalone build of javapackager > works for you, then that's great. > > -- Kevin > > > On 8/7/2018 9:16 AM, johns at msli.com wrote: >> The motivation for a new packager states a need for a a packager, but >> not why the javapackager can't continue. >> >> With all the work that went into javapackager, why can't it simple be >> released for continued development outside Oracle, if they don't want to >> maintain it. >> >> The javapackager has worked well for a few years, so why reinvent a >> packager with fewer features, rather than expand features, and clear >> bugs? >> >> On 08/07/2018 05:03 AM, Lennart B?rjeson wrote: >>> Well, while I can surely use the packager from JDK 10 and bundle my >>> application with 11, I'd still miss out on the packager service, >>> i.e. the application would not be able to use the UserJvmOptions. >>> >>> It seems to me the packager service has been completely forgotten? >>> JDK-8200758 does not mention it at all. >>> >>> /Lennart >>> >>>> 7 aug. 2018 kl. 13:45 skrev Nir Lisker : >>>> >>>> Hi Lennart, >>>> >>>> You should be able to use the packager from JDK 10, see >>>> https://bugs.openjdk.java.net/browse/JDK-8203379 >>>> . >>>> >>>> There is a draft for a replacement, see >>>> https://bugs.openjdk.java.net/browse/JDK-8200758 >>>> . >>>> >>>> - Nir >>>> >>>> On Tue, Aug 7, 2018 at 12:28 PM, Lennart B?rjeson >>>> > wrote: >>>> I'm migrating to JDK 11 and OpenJFX 11, and would like to continue >>>> using the packager and the associated packager service (i.e. the >>>> UserJvmOptions). >>>> >>>> AFAIK, those are gone from the available binary builds, but still >>>> there in the code. Is there a way to use them without resorting to >>>> build openjfx myself? If not, is there some alternative to the >>>> UserJvmOptions? >>>> >>>> >>>> (I'm currently working around my problems by building both openjfx >>>> and the JDK, and bundling openjfx with the JDK, just like in the >>>> good old days...) >>>> >>>> Best regards, >>>> >>>> /Lennart B?rjeson >>>> >>>> >>>> > From tom.schindl at bestsolution.at Tue Aug 7 17:04:37 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 7 Aug 2018 19:04:37 +0200 Subject: Swing module's module-info file In-Reply-To: References: <55d7742c-e691-01eb-2aae-1a54dec64fd3@bestsolution.at> Message-ID: <3e9d1bf4-ddb5-c980-bf39-3c185dc77ad7@bestsolution.at> Hi Nir, I'm using OpenJDK-11 in my eclipse for development so I have that module included. Tom On 07.08.18 18:34, Nir Lisker wrote: > So you rebuilt the JDK with the new jdk.unsupported.desktop module? > > On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl > wrote: > > Well I simply added the folder to my class-folders and things then work > perfectly fine inside Eclipse > > Tom > > On 07.08.18 14:02, Nir Lisker wrote: > > Thanks for the info. I'm working on updating the Eclipse files and > this is > > causing problems for javafx.swing. When will the minimum version > be bumped > > to 11? > > > > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan < > > prasanta.sadhukhan at oracle.com > > wrote: > > > >> This is because if fx is compiled with a jdk version which does > not have > >> jdk.unsupported.desktop module then having module-info.java in > its original > >> place would cause compilation error as module-info.java contains > >> > >> requires static jdk.unsupported.desktop; > >> > >> So, the idea was to copy the file into a directory which is not > on the > >> module-source-path. Then build.gradle copy it from there to gensrc > >> directory optionally filtering the above line > >>? task copyModuleInfo(type: Copy, description: "copy module-info > file to > >> gensrc") { > >>? ? ? ? ?from "src/main/module-info/module-info.java" > >>? ? ? ? ?into "$buildDir/gensrc/java/" > >>? ? ? ? ?filter { line-> > >>? ? ? ? ? ? ?!HAS_UNSUPPORTED_DESKTOP && > line.contains('jdk.unsupported.desktop') > >> ? null : line > >>? ? ? ? ?} > >>? ? ?} > >> > >> Regards > >> Prasanta > >> > >> On 8/7/2018 6:42 AM, Nir Lisker wrote: > >> > >>> Hi, > >>> > >>> I didn't follow all the latest changes to the Swing module, but > I notice > >>> now its module-info.java file is not in the same place where > other modules > >>> have theirs: > >>> > >>> It's under javafx.swing\src\main\module-info instead of > >>> javafx.\src\main\java. > >>> > >>> Is there a reason for this? > >>> > >>> - Nir > >>> > >> > >> > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From nlisker at gmail.com Tue Aug 7 17:36:43 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 7 Aug 2018 20:36:43 +0300 Subject: Swing module's module-info file In-Reply-To: <3e9d1bf4-ddb5-c980-bf39-3c185dc77ad7@bestsolution.at> References: <55d7742c-e691-01eb-2aae-1a54dec64fd3@bestsolution.at> <3e9d1bf4-ddb5-c980-bf39-3c185dc77ad7@bestsolution.at> Message-ID: And both newimlp and oldimpl packages compile for you? On Tue, Aug 7, 2018 at 8:04 PM, Tom Schindl wrote: > Hi Nir, > > I'm using OpenJDK-11 in my eclipse for development so I have that module > included. > > Tom > > On 07.08.18 18:34, Nir Lisker wrote: > > So you rebuilt the JDK with the new jdk.unsupported.desktop module? > > > > On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl > > wrote: > > > > Well I simply added the folder to my class-folders and things then > work > > perfectly fine inside Eclipse > > > > Tom > > > > On 07.08.18 14:02, Nir Lisker wrote: > > > Thanks for the info. I'm working on updating the Eclipse files and > > this is > > > causing problems for javafx.swing. When will the minimum version > > be bumped > > > to 11? > > > > > > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan < > > > prasanta.sadhukhan at oracle.com > > > wrote: > > > > > >> This is because if fx is compiled with a jdk version which does > > not have > > >> jdk.unsupported.desktop module then having module-info.java in > > its original > > >> place would cause compilation error as module-info.java contains > > >> > > >> requires static jdk.unsupported.desktop; > > >> > > >> So, the idea was to copy the file into a directory which is not > > on the > > >> module-source-path. Then build.gradle copy it from there to gensrc > > >> directory optionally filtering the above line > > >> task copyModuleInfo(type: Copy, description: "copy module-info > > file to > > >> gensrc") { > > >> from "src/main/module-info/module-info.java" > > >> into "$buildDir/gensrc/java/" > > >> filter { line-> > > >> !HAS_UNSUPPORTED_DESKTOP && > > line.contains('jdk.unsupported.desktop') > > >> ? null : line > > >> } > > >> } > > >> > > >> Regards > > >> Prasanta > > >> > > >> On 8/7/2018 6:42 AM, Nir Lisker wrote: > > >> > > >>> Hi, > > >>> > > >>> I didn't follow all the latest changes to the Swing module, but > > I notice > > >>> now its module-info.java file is not in the same place where > > other modules > > >>> have theirs: > > >>> > > >>> It's under javafx.swing\src\main\module-info instead of > > >>> javafx.\src\main\java. > > >>> > > >>> Is there a reason for this? > > >>> > > >>> - Nir > > >>> > > >> > > >> > > > > -- > > Tom Schindl, CTO > > BestSolution.at EDV Systemhaus GmbH > > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > > > > > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > From tom.schindl at bestsolution.at Tue Aug 7 17:51:17 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 7 Aug 2018 19:51:17 +0200 Subject: Swing module's module-info file In-Reply-To: References: <55d7742c-e691-01eb-2aae-1a54dec64fd3@bestsolution.at> <3e9d1bf4-ddb5-c980-bf39-3c185dc77ad7@bestsolution.at> Message-ID: <5cdbbe13-68e6-d26e-7186-11d2039d3cd9@bestsolution.at> Yes they do! Tom On 07.08.18 19:36, Nir Lisker wrote: > And both newimlp and oldimpl packages compile for you? > > On Tue, Aug 7, 2018 at 8:04 PM, Tom Schindl > wrote: > > Hi Nir, > > I'm using OpenJDK-11 in my eclipse for development so I have that module > included. > > Tom > > On 07.08.18 18:34, Nir Lisker wrote: > > So you rebuilt the JDK with the new jdk.unsupported.desktop module? > > > > On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl > > >> > wrote: > > > >? ? ?Well I simply added the folder to my class-folders and things then work > >? ? ?perfectly fine inside Eclipse > > > >? ? ?Tom > > > >? ? ?On 07.08.18 14:02, Nir Lisker wrote: > >? ? ?> Thanks for the info. I'm working on updating the Eclipse files and > >? ? ?this is > >? ? ?> causing problems for javafx.swing. When will the minimum version > >? ? ?be bumped > >? ? ?> to 11? > >? ? ?> > >? ? ?> On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan < > >? ? ?> prasanta.sadhukhan at oracle.com > >? ? ? >> wrote: > >? ? ?> > >? ? ?>> This is because if fx is compiled with a jdk version which does > >? ? ?not have > >? ? ?>> jdk.unsupported.desktop module then having module-info.java in > >? ? ?its original > >? ? ?>> place would cause compilation error as module-info.java > contains > >? ? ?>> > >? ? ?>> requires static jdk.unsupported.desktop; > >? ? ?>> > >? ? ?>> So, the idea was to copy the file into a directory which is not > >? ? ?on the > >? ? ?>> module-source-path. Then build.gradle copy it from there to > gensrc > >? ? ?>> directory optionally filtering the above line > >? ? ?>>? task copyModuleInfo(type: Copy, description: "copy module-info > >? ? ?file to > >? ? ?>> gensrc") { > >? ? ?>>? ? ? ? ?from "src/main/module-info/module-info.java" > >? ? ?>>? ? ? ? ?into "$buildDir/gensrc/java/" > >? ? ?>>? ? ? ? ?filter { line-> > >? ? ?>>? ? ? ? ? ? ?!HAS_UNSUPPORTED_DESKTOP && > >? ? ?line.contains('jdk.unsupported.desktop') > >? ? ?>> ? null : line > >? ? ?>>? ? ? ? ?} > >? ? ?>>? ? ?} > >? ? ?>> > >? ? ?>> Regards > >? ? ?>> Prasanta > >? ? ?>> > >? ? ?>> On 8/7/2018 6:42 AM, Nir Lisker wrote: > >? ? ?>> > >? ? ?>>> Hi, > >? ? ?>>> > >? ? ?>>> I didn't follow all the latest changes to the Swing > module, but > >? ? ?I notice > >? ? ?>>> now its module-info.java file is not in the same place where > >? ? ?other modules > >? ? ?>>> have theirs: > >? ? ?>>> > >? ? ?>>> It's under javafx.swing\src\main\module-info instead of > >? ? ?>>> javafx.\src\main\java. > >? ? ?>>> > >? ? ?>>> Is there a reason for this? > >? ? ?>>> > >? ? ?>>> - Nir > >? ? ?>>> > >? ? ?>> > >? ? ?>> > > > >? ? ?-- > >? ? ?Tom Schindl, CTO > >? ? ?BestSolution.at EDV Systemhaus GmbH > >? ? ?Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > >? ? ?Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > > > > > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > > -- 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 Aug 7 17:53:15 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Aug 2018 10:53:15 -0700 Subject: Swing module's module-info file In-Reply-To: References: <55d7742c-e691-01eb-2aae-1a54dec64fd3@bestsolution.at> <3e9d1bf4-ddb5-c980-bf39-3c185dc77ad7@bestsolution.at> Message-ID: There is no reason they won't both compile with JDK 11. In this case, the implementation is selected at runtime. When compiling with JDK 10, the 'newimpl' package is excluded. -- Kevin On 8/7/2018 10:36 AM, Nir Lisker wrote: > And both newimlp and oldimpl packages compile for you? > > On Tue, Aug 7, 2018 at 8:04 PM, Tom Schindl > wrote: > >> Hi Nir, >> >> I'm using OpenJDK-11 in my eclipse for development so I have that module >> included. >> >> Tom >> >> On 07.08.18 18:34, Nir Lisker wrote: >>> So you rebuilt the JDK with the new jdk.unsupported.desktop module? >>> >>> On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl >> > wrote: >>> >>> Well I simply added the folder to my class-folders and things then >> work >>> perfectly fine inside Eclipse >>> >>> Tom >>> >>> On 07.08.18 14:02, Nir Lisker wrote: >>> > Thanks for the info. I'm working on updating the Eclipse files and >>> this is >>> > causing problems for javafx.swing. When will the minimum version >>> be bumped >>> > to 11? >>> > >>> > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan < >>> > prasanta.sadhukhan at oracle.com >>> > wrote: >>> > >>> >> This is because if fx is compiled with a jdk version which does >>> not have >>> >> jdk.unsupported.desktop module then having module-info.java in >>> its original >>> >> place would cause compilation error as module-info.java contains >>> >> >>> >> requires static jdk.unsupported.desktop; >>> >> >>> >> So, the idea was to copy the file into a directory which is not >>> on the >>> >> module-source-path. Then build.gradle copy it from there to gensrc >>> >> directory optionally filtering the above line >>> >> task copyModuleInfo(type: Copy, description: "copy module-info >>> file to >>> >> gensrc") { >>> >> from "src/main/module-info/module-info.java" >>> >> into "$buildDir/gensrc/java/" >>> >> filter { line-> >>> >> !HAS_UNSUPPORTED_DESKTOP && >>> line.contains('jdk.unsupported.desktop') >>> >> ? null : line >>> >> } >>> >> } >>> >> >>> >> Regards >>> >> Prasanta >>> >> >>> >> On 8/7/2018 6:42 AM, Nir Lisker wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> I didn't follow all the latest changes to the Swing module, but >>> I notice >>> >>> now its module-info.java file is not in the same place where >>> other modules >>> >>> have theirs: >>> >>> >>> >>> It's under javafx.swing\src\main\module-info instead of >>> >>> javafx.\src\main\java. >>> >>> >>> >>> Is there a reason for this? >>> >>> >>> >>> - Nir >>> >>> >>> >> >>> >> >>> >>> -- >>> Tom Schindl, CTO >>> BestSolution.at EDV Systemhaus GmbH >>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck >>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck >>> >>> >> -- >> Tom Schindl, CTO >> BestSolution.at EDV Systemhaus GmbH >> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck >> From tom.schindl at bestsolution.at Tue Aug 7 17:54:33 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 7 Aug 2018 19:54:33 +0200 Subject: Swing module's module-info file In-Reply-To: <5cdbbe13-68e6-d26e-7186-11d2039d3cd9@bestsolution.at> References: <55d7742c-e691-01eb-2aae-1a54dec64fd3@bestsolution.at> <3e9d1bf4-ddb5-c980-bf39-3c185dc77ad7@bestsolution.at> <5cdbbe13-68e6-d26e-7186-11d2039d3cd9@bestsolution.at> Message-ID: Oh but naturally my .classpath-File is modified Tom On 07.08.18 19:51, Tom Schindl wrote: > Yes they do! > > Tom > > On 07.08.18 19:36, Nir Lisker wrote: >> And both newimlp and oldimpl packages compile for you? >> >> On Tue, Aug 7, 2018 at 8:04 PM, Tom Schindl > > wrote: >> >> Hi Nir, >> >> I'm using OpenJDK-11 in my eclipse for development so I have that module >> included. >> >> Tom >> >> On 07.08.18 18:34, Nir Lisker wrote: >> > So you rebuilt the JDK with the new jdk.unsupported.desktop module? >> > >> > On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl >> > >> >> wrote: >> > >> >? ? ?Well I simply added the folder to my class-folders and things then work >> >? ? ?perfectly fine inside Eclipse >> > >> >? ? ?Tom >> > >> >? ? ?On 07.08.18 14:02, Nir Lisker wrote: >> >? ? ?> Thanks for the info. I'm working on updating the Eclipse files and >> >? ? ?this is >> >? ? ?> causing problems for javafx.swing. When will the minimum version >> >? ? ?be bumped >> >? ? ?> to 11? >> >? ? ?> >> >? ? ?> On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan < >> >? ? ?> prasanta.sadhukhan at oracle.com >> >? ? ?> >> wrote: >> >? ? ?> >> >? ? ?>> This is because if fx is compiled with a jdk version which does >> >? ? ?not have >> >? ? ?>> jdk.unsupported.desktop module then having module-info.java in >> >? ? ?its original >> >? ? ?>> place would cause compilation error as module-info.java >> contains >> >? ? ?>> >> >? ? ?>> requires static jdk.unsupported.desktop; >> >? ? ?>> >> >? ? ?>> So, the idea was to copy the file into a directory which is not >> >? ? ?on the >> >? ? ?>> module-source-path. Then build.gradle copy it from there to >> gensrc >> >? ? ?>> directory optionally filtering the above line >> >? ? ?>>? task copyModuleInfo(type: Copy, description: "copy module-info >> >? ? ?file to >> >? ? ?>> gensrc") { >> >? ? ?>>? ? ? ? ?from "src/main/module-info/module-info.java" >> >? ? ?>>? ? ? ? ?into "$buildDir/gensrc/java/" >> >? ? ?>>? ? ? ? ?filter { line-> >> >? ? ?>>? ? ? ? ? ? ?!HAS_UNSUPPORTED_DESKTOP && >> >? ? ?line.contains('jdk.unsupported.desktop') >> >? ? ?>> ? null : line >> >? ? ?>>? ? ? ? ?} >> >? ? ?>>? ? ?} >> >? ? ?>> >> >? ? ?>> Regards >> >? ? ?>> Prasanta >> >? ? ?>> >> >? ? ?>> On 8/7/2018 6:42 AM, Nir Lisker wrote: >> >? ? ?>> >> >? ? ?>>> Hi, >> >? ? ?>>> >> >? ? ?>>> I didn't follow all the latest changes to the Swing >> module, but >> >? ? ?I notice >> >? ? ?>>> now its module-info.java file is not in the same place where >> >? ? ?other modules >> >? ? ?>>> have theirs: >> >? ? ?>>> >> >? ? ?>>> It's under javafx.swing\src\main\module-info instead of >> >? ? ?>>> javafx.\src\main\java. >> >? ? ?>>> >> >? ? ?>>> Is there a reason for this? >> >? ? ?>>> >> >? ? ?>>> - Nir >> >? ? ?>>> >> >? ? ?>> >> >? ? ?>> >> > >> >? ? ?-- >> >? ? ?Tom Schindl, CTO >> >? ? ?BestSolution.at EDV Systemhaus GmbH >> >? ? ?Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck >> >? ? ?Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck >> > >> > >> >> -- >> Tom Schindl, CTO >> BestSolution.at EDV Systemhaus GmbH >> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck >> >> > -- 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 Aug 7 17:54:43 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Aug 2018 10:54:43 -0700 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: <4c6d4320-4e5e-8741-3a71-659f66c7f059@jugs.org> References: <938A17F1-B35B-4AA3-9635-8AB67EFF8FA9@gmail.com> <613E292A-76CB-4EEB-9673-558AC5C621E7@gmail.com> <141a4082-5728-2f11-45e1-6385eea535bb@msli.com> <56f07481-3c94-9931-c419-636cb42d7e84@oracle.com> <4c6d4320-4e5e-8741-3a71-659f66c7f059@jugs.org> Message-ID: We're still aiming for that, although it might be a bit after JDK 11 ships. -- Kevin On 8/7/2018 10:02 AM, Michael Paus wrote: > I don't know whether the following statement is still valid, but if it > is, > then it may not be worth the effort to resurrect the old javapackager > if at least an EA build of the new one is so close. > > On 6/27/2018 3:30 PM, Kevin Rushforth wrote: >> /We're aiming to get this into JDK 12 early enough so that an EA >> build />/would be available around the time JDK 11 ships. That will >> allow you />/to take a jlinked image with JDK 11 and package it up >> using (the EA) />/jpackager./ > > Michael > > Am 07.08.18 um 18:49 schrieb Kevin Rushforth: >> Someone could certainly do that. >> >> We think there is enough interest in having a standard tool that it >> is worth spending effort on a replacement tool that will be part of >> standard JDK builds, including OpenJDK builds that have never had >> javapackager. In the mean time, if a standalone build of javapackager >> works for you, then that's great. >> >> -- Kevin >> >> >> On 8/7/2018 9:16 AM, johns at msli.com wrote: >>> The motivation for a new packager states a need for a a packager, but >>> not why the javapackager can't continue. >>> >>> With all the work that went into javapackager, why can't it simple be >>> released for continued development outside Oracle, if they don't >>> want to >>> maintain it. >>> >>> The javapackager has worked well for a few years, so why reinvent a >>> packager with fewer features, rather than expand features, and clear >>> bugs? >>> >>> On 08/07/2018 05:03 AM, Lennart B?rjeson wrote: >>>> Well, while I can surely use the packager from JDK 10 and bundle my >>>> application with 11, I'd still miss out on the packager service, >>>> i.e. the application would not be able to use the UserJvmOptions. >>>> >>>> It seems to me the packager service has been completely forgotten? >>>> JDK-8200758 does not mention it at all. >>>> >>>> /Lennart >>>> >>>>> 7 aug. 2018 kl. 13:45 skrev Nir Lisker : >>>>> >>>>> Hi Lennart, >>>>> >>>>> You should be able to use the packager from JDK 10, see >>>>> https://bugs.openjdk.java.net/browse/JDK-8203379 >>>>> . >>>>> >>>>> There is a draft for a replacement, see >>>>> https://bugs.openjdk.java.net/browse/JDK-8200758 >>>>> . >>>>> >>>>> - Nir >>>>> >>>>> On Tue, Aug 7, 2018 at 12:28 PM, Lennart B?rjeson >>>>> > wrote: >>>>> I'm migrating to JDK 11 and OpenJFX 11, and would like to continue >>>>> using the packager and the associated packager service (i.e. the >>>>> UserJvmOptions). >>>>> >>>>> AFAIK, those are gone from the available binary builds, but still >>>>> there in the code. Is there a way to use them without resorting to >>>>> build openjfx myself? If not, is there some alternative to the >>>>> UserJvmOptions? >>>>> >>>>> >>>>> (I'm currently working around my problems by building both openjfx >>>>> and the JDK, and bundling openjfx with the JDK, just like in the >>>>> good old days...) >>>>> >>>>> Best regards, >>>>> >>>>> /Lennart B?rjeson >>>>> >>>>> >>>>> >> > From lenborje at gmail.com Tue Aug 7 20:23:18 2018 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Tue, 7 Aug 2018 22:23:18 +0200 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: References: <938A17F1-B35B-4AA3-9635-8AB67EFF8FA9@gmail.com> <613E292A-76CB-4EEB-9673-558AC5C621E7@gmail.com> <141a4082-5728-2f11-45e1-6385eea535bb@msli.com> <56f07481-3c94-9931-c419-636cb42d7e84@oracle.com> <4c6d4320-4e5e-8741-3a71-659f66c7f059@jugs.org> Message-ID: ...and please don?t forget the packager services! Perhaps it could be made available as a maven module? /Lennart B?rjeson Electrogramma ab iPhono meo missum est > 7 aug. 2018 kl. 19:54 skrev Kevin Rushforth : > > We're still aiming for that, although it might be a bit after JDK 11 ships. > > -- Kevin > > >> On 8/7/2018 10:02 AM, Michael Paus wrote: >> I don't know whether the following statement is still valid, but if it is, >> then it may not be worth the effort to resurrect the old javapackager >> if at least an EA build of the new one is so close. >> >>> On 6/27/2018 3:30 PM, Kevin Rushforth wrote: >>> /We're aiming to get this into JDK 12 early enough so that an EA build />/would be available around the time JDK 11 ships. That will allow you />/to take a jlinked image with JDK 11 and package it up using (the EA) />/jpackager./ >> >> Michael >> >>> Am 07.08.18 um 18:49 schrieb Kevin Rushforth: >>> Someone could certainly do that. >>> >>> We think there is enough interest in having a standard tool that it is worth spending effort on a replacement tool that will be part of standard JDK builds, including OpenJDK builds that have never had javapackager. In the mean time, if a standalone build of javapackager works for you, then that's great. >>> >>> -- Kevin >>> >>> >>>> On 8/7/2018 9:16 AM, johns at msli.com wrote: >>>> The motivation for a new packager states a need for a a packager, but >>>> not why the javapackager can't continue. >>>> >>>> With all the work that went into javapackager, why can't it simple be >>>> released for continued development outside Oracle, if they don't want to >>>> maintain it. >>>> >>>> The javapackager has worked well for a few years, so why reinvent a >>>> packager with fewer features, rather than expand features, and clear bugs? >>>> >>>>> On 08/07/2018 05:03 AM, Lennart B?rjeson wrote: >>>>> Well, while I can surely use the packager from JDK 10 and bundle my application with 11, I'd still miss out on the packager service, i.e. the application would not be able to use the UserJvmOptions. >>>>> >>>>> It seems to me the packager service has been completely forgotten? JDK-8200758 does not mention it at all. >>>>> >>>>> /Lennart >>>>> >>>>>> 7 aug. 2018 kl. 13:45 skrev Nir Lisker : >>>>>> >>>>>> Hi Lennart, >>>>>> >>>>>> You should be able to use the packager from JDK 10, see https://bugs.openjdk.java.net/browse/JDK-8203379 . >>>>>> >>>>>> There is a draft for a replacement, see https://bugs.openjdk.java.net/browse/JDK-8200758 . >>>>>> >>>>>> - Nir >>>>>> >>>>>> On Tue, Aug 7, 2018 at 12:28 PM, Lennart B?rjeson > wrote: >>>>>> I'm migrating to JDK 11 and OpenJFX 11, and would like to continue using the packager and the associated packager service (i.e. the UserJvmOptions). >>>>>> >>>>>> AFAIK, those are gone from the available binary builds, but still there in the code. Is there a way to use them without resorting to build openjfx myself? If not, is there some alternative to the UserJvmOptions? >>>>>> >>>>>> >>>>>> (I'm currently working around my problems by building both openjfx and the JDK, and bundling openjfx with the JDK, just like in the good old days...) >>>>>> >>>>>> Best regards, >>>>>> >>>>>> /Lennart B?rjeson >>>>>> >>>>>> >>>>>> >>> >> > From kevin.rushforth at oracle.com Tue Aug 7 22:31:20 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Aug 2018 15:31:20 -0700 Subject: OpenJFX 11 is in Rampdown Phase Two (RDP2) Message-ID: <7d757b86-d73f-a101-6080-eb74fc1494b0@oracle.com> To: OpenJFX Developers As a reminder, OpenJFX 11 is now in Rampdown Phase Two RDP2. [1] During RDP2, all bug fixes, except for docs and test fixes, and all enhancements will need explicit approval to go in. Note that these restrictions apply to the soon-to-be-created openjfx/11-dev/rt repo [2]. Starting now, the jfx-dev/rt mainline -- and by extension, the develop branch of the GitHub sandbox -- is open for openjfx12 fixes. We will use the same rules for RDP2 that the JDK uses [3], 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-fix-request", "openjfx11-fix-yes", "openjfx11-fix-no" and "openjfx11-fix-nmi", "openjfx11-enhancement-request", "openjfx11-enhancement-yes", "openjfx11-enhancement-no" and "openjfx11-enhancement-nmi" as corresponding labels. 3. Some important P3 bugs might be considered during RDP2, as long as those bugs have otherwise met the usual code review criteria. Having said that, most P3 bugs should be moved to openjfx12 at this point. I do not expect many P3 bugs to be approved. If a fix is approved to push to 11-dev (with the appropriate approval label added by a lead), then you need not also push it to jfx-dev -- we will auto-sync from 11-dev --> jfx-dev for the duration of the openjfx11 release. Now that we are in RDP2, the goal should be to stabilize what is there, with priority on fixing bugs that are new in openjfx11. We need to be extremely careful 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-August/022233.html [2] http://hg.openjdk.java.net/openjfx/11-dev/rt? (not yet created as of this writing) [3] http://openjdk.java.net/jeps/3 From kevin.rushforth at oracle.com Tue Aug 7 22:42:35 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Aug 2018 15:42:35 -0700 Subject: [12] Review request: 8209040: Change JavaFX release version to 12 Message-ID: <603ac0a3-f833-0c44-0d2a-16d20902be1b@oracle.com> Please review the following to bump the feature version (aka major version) of openjfx to 12: https://bugs.openjdk.java.net/browse/JDK-8209040 http://cr.openjdk.java.net/~kcr/8209040/webrev/ As a note, I will wait to push this until the repo is tagged with 11+22 (the RDP2 build). I will then add a 12+0 tag, following by the changeset for this fix to bump the version to 12. -- Kevin From nlisker at gmail.com Tue Aug 7 23:27:47 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 8 Aug 2018 02:27:47 +0300 Subject: Swing module's module-info file In-Reply-To: References: <55d7742c-e691-01eb-2aae-1a54dec64fd3@bestsolution.at> <3e9d1bf4-ddb5-c980-bf39-3c185dc77ad7@bestsolution.at> <5cdbbe13-68e6-d26e-7186-11d2039d3cd9@bestsolution.at> Message-ID: Ah, yes, I was trying to see what modifications each project needs so I didn't have it modified. Can you share your Swing .classpath? Eclipse gives me a NPE during the build task, I think something broke. On Tue, Aug 7, 2018 at 8:54 PM, Tom Schindl wrote: > Oh but naturally my .classpath-File is modified > > Tom > > On 07.08.18 19:51, Tom Schindl wrote: > > Yes they do! > > > > Tom > > > > On 07.08.18 19:36, Nir Lisker wrote: > >> And both newimlp and oldimpl packages compile for you? > >> > >> On Tue, Aug 7, 2018 at 8:04 PM, Tom Schindl < > tom.schindl at bestsolution.at > >> > wrote: > >> > >> Hi Nir, > >> > >> I'm using OpenJDK-11 in my eclipse for development so I have that > module > >> included. > >> > >> Tom > >> > >> On 07.08.18 18:34, Nir Lisker wrote: > >> > So you rebuilt the JDK with the new jdk.unsupported.desktop > module? > >> > > >> > On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl < > tom.schindl at bestsolution.at > >> > bestsolution.at>>> > >> wrote: > >> > > >> > Well I simply added the folder to my class-folders and things > then work > >> > perfectly fine inside Eclipse > >> > > >> > Tom > >> > > >> > On 07.08.18 14:02, Nir Lisker wrote: > >> > > Thanks for the info. I'm working on updating the Eclipse > files and > >> > this is > >> > > causing problems for javafx.swing. When will the minimum > version > >> > be bumped > >> > > to 11? > >> > > > >> > > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan < > >> > > prasanta.sadhukhan at oracle.com oracle.com> > >> > >> >> wrote: > >> > > > >> > >> This is because if fx is compiled with a jdk version which > does > >> > not have > >> > >> jdk.unsupported.desktop module then having > module-info.java in > >> > its original > >> > >> place would cause compilation error as module-info.java > >> contains > >> > >> > >> > >> requires static jdk.unsupported.desktop; > >> > >> > >> > >> So, the idea was to copy the file into a directory which > is not > >> > on the > >> > >> module-source-path. Then build.gradle copy it from there to > >> gensrc > >> > >> directory optionally filtering the above line > >> > >> task copyModuleInfo(type: Copy, description: "copy > module-info > >> > file to > >> > >> gensrc") { > >> > >> from "src/main/module-info/module-info.java" > >> > >> into "$buildDir/gensrc/java/" > >> > >> filter { line-> > >> > >> !HAS_UNSUPPORTED_DESKTOP && > >> > line.contains('jdk.unsupported.desktop') > >> > >> ? null : line > >> > >> } > >> > >> } > >> > >> > >> > >> Regards > >> > >> Prasanta > >> > >> > >> > >> On 8/7/2018 6:42 AM, Nir Lisker wrote: > >> > >> > >> > >>> Hi, > >> > >>> > >> > >>> I didn't follow all the latest changes to the Swing > >> module, but > >> > I notice > >> > >>> now its module-info.java file is not in the same place > where > >> > other modules > >> > >>> have theirs: > >> > >>> > >> > >>> It's under javafx.swing\src\main\module-info instead of > >> > >>> javafx.\src\main\java. > >> > >>> > >> > >>> Is there a reason for this? > >> > >>> > >> > >>> - Nir > >> > >>> > >> > >> > >> > >> > >> > > >> > -- > >> > Tom Schindl, CTO > >> > BestSolution.at EDV Systemhaus GmbH > >> > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > >> > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > >> > > >> > > >> > >> -- > >> Tom Schindl, CTO > >> BestSolution.at EDV Systemhaus GmbH > >> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > >> > >> > > > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > From tom.schindl at bestsolution.at Wed Aug 8 06:55:17 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 8 Aug 2018 08:55:17 +0200 Subject: Swing module's module-info file In-Reply-To: References: <55d7742c-e691-01eb-2aae-1a54dec64fd3@bestsolution.at> <3e9d1bf4-ddb5-c980-bf39-3c185dc77ad7@bestsolution.at> <5cdbbe13-68e6-d26e-7186-11d2039d3cd9@bestsolution.at> Message-ID: <2a8118e2-fe92-3464-a7b7-7d7bf5f50e03@bestsolution.at> Hi Nir, I currently use the attached stash to make Eclipse compile all modules. Unfortunately I have to modify the following java-Files to get away without any compile errors: * Dialog => Added a method getDialog() instead of directly accessing the field * javafx.fxml => Add a static require for controls * javafx.web => Add a static require for java.management * MarlinUtils => Small JavaDoc fix because one can not access sun.security.... Issues 1 - 3 are Eclipse issues. The error in Dialog is known by the Eclipse people. I'm not sure with the Read-Edges we'd have to add to get around the module-info.java changes, IMHO the UI in Eclipse in this area is completely senseless (or I'm too dumb to understand it) Issue 4: Is something one could discuss if the Marlin maintainers would be ok to change? Tom On 08.08.18 01:27, Nir Lisker wrote: > Ah, yes, I was trying to see what modifications each project needs so I > didn't have it modified. > > Can you share your Swing .classpath? Eclipse gives me a NPE during the > build task, I think something broke. > > On Tue, Aug 7, 2018 at 8:54 PM, Tom Schindl > wrote: > > Oh but naturally my .classpath-File is modified > > Tom > > On 07.08.18 19:51, Tom Schindl wrote: > > Yes they do! > > > > Tom > > > > On 07.08.18 19:36, Nir Lisker wrote: > >> And both newimlp and oldimpl packages compile for you? > >> > >> On Tue, Aug 7, 2018 at 8:04 PM, Tom Schindl > > >> >> wrote: > >> > >>? ? ?Hi Nir, > >> > >>? ? ?I'm using OpenJDK-11 in my eclipse for development so I have > that module > >>? ? ?included. > >> > >>? ? ?Tom > >> > >>? ? ?On 07.08.18 18:34, Nir Lisker wrote: > >>? ? ?> So you rebuilt the JDK with the new jdk.unsupported.desktop > module? > >>? ? ?> > >>? ? ?> On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl > > > > >>? ? ?> > >>> > >>? ? ?wrote: > >>? ? ?> > >>? ? ?>? ? ?Well I simply added the folder to my class-folders and > things then work > >>? ? ?>? ? ?perfectly fine inside Eclipse > >>? ? ?> > >>? ? ?>? ? ?Tom > >>? ? ?> > >>? ? ?>? ? ?On 07.08.18 14:02, Nir Lisker wrote: > >>? ? ?>? ? ?> Thanks for the info. I'm working on updating the > Eclipse files and > >>? ? ?>? ? ?this is > >>? ? ?>? ? ?> causing problems for javafx.swing. When will the > minimum version > >>? ? ?>? ? ?be bumped > >>? ? ?>? ? ?> to 11? > >>? ? ?>? ? ?> > >>? ? ?>? ? ?> On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan < > >>? ? ?>? ? ?> prasanta.sadhukhan at oracle.com > > > > >>? ? ?>? ? ? > >>? ? ? >>> wrote: > >>? ? ?>? ? ?> > >>? ? ?>? ? ?>> This is because if fx is compiled with a jdk version > which does > >>? ? ?>? ? ?not have > >>? ? ?>? ? ?>> jdk.unsupported.desktop module then having > module-info.java in > >>? ? ?>? ? ?its original > >>? ? ?>? ? ?>> place would cause compilation error as module-info.java > >>? ? ?contains > >>? ? ?>? ? ?>> > >>? ? ?>? ? ?>> requires static jdk.unsupported.desktop; > >>? ? ?>? ? ?>> > >>? ? ?>? ? ?>> So, the idea was to copy the file into a directory > which is not > >>? ? ?>? ? ?on the > >>? ? ?>? ? ?>> module-source-path. Then build.gradle copy it from > there to > >>? ? ?gensrc > >>? ? ?>? ? ?>> directory optionally filtering the above line > >>? ? ?>? ? ?>>? task copyModuleInfo(type: Copy, description: "copy > module-info > >>? ? ?>? ? ?file to > >>? ? ?>? ? ?>> gensrc") { > >>? ? ?>? ? ?>>? ? ? ? ?from "src/main/module-info/module-info.java" > >>? ? ?>? ? ?>>? ? ? ? ?into "$buildDir/gensrc/java/" > >>? ? ?>? ? ?>>? ? ? ? ?filter { line-> > >>? ? ?>? ? ?>>? ? ? ? ? ? ?!HAS_UNSUPPORTED_DESKTOP && > >>? ? ?>? ? ?line.contains('jdk.unsupported.desktop') > >>? ? ?>? ? ?>> ? null : line > >>? ? ?>? ? ?>>? ? ? ? ?} > >>? ? ?>? ? ?>>? ? ?} > >>? ? ?>? ? ?>> > >>? ? ?>? ? ?>> Regards > >>? ? ?>? ? ?>> Prasanta > >>? ? ?>? ? ?>> > >>? ? ?>? ? ?>> On 8/7/2018 6:42 AM, Nir Lisker wrote: > >>? ? ?>? ? ?>> > >>? ? ?>? ? ?>>> Hi, > >>? ? ?>? ? ?>>> > >>? ? ?>? ? ?>>> I didn't follow all the latest changes to the Swing > >>? ? ?module, but > >>? ? ?>? ? ?I notice > >>? ? ?>? ? ?>>> now its module-info.java file is not in the same > place where > >>? ? ?>? ? ?other modules > >>? ? ?>? ? ?>>> have theirs: > >>? ? ?>? ? ?>>> > >>? ? ?>? ? ?>>> It's under javafx.swing\src\main\module-info instead of > >>? ? ?>? ? ?>>> javafx.\src\main\java. > >>? ? ?>? ? ?>>> > >>? ? ?>? ? ?>>> Is there a reason for this? > >>? ? ?>? ? ?>>> > >>? ? ?>? ? ?>>> - Nir > >>? ? ?>? ? ?>>> > >>? ? ?>? ? ?>> > >>? ? ?>? ? ?>> > >>? ? ?> > >>? ? ?>? ? ?-- > >>? ? ?>? ? ?Tom Schindl, CTO > >>? ? ?>? ? ?BestSolution.at EDV Systemhaus GmbH > >>? ? ?>? ? ?Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > >>? ? ?>? ? ?Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > >>? ? ?> > >>? ? ?> > >> > >>? ? ?-- > >>? ? ?Tom Schindl, CTO > >>? ? ?BestSolution.at EDV Systemhaus GmbH > >>? ? ?Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > >>? ? ?Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > >> > >> > > > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck -------------- next part -------------- diff --git a/.classpath b/.classpath index a4ebd5168d..67fed0187f 100644 --- a/.classpath +++ b/.classpath @@ -1,11 +1,10 @@ + - - - - - - - - - + + + + + + + diff --git a/.gitignore b/.gitignore index 899af1ffed..0874424342 100644 --- a/.gitignore +++ b/.gitignore @@ -14,3 +14,5 @@ webrev/ webrev.zip gradle.properties apps/samples/Ensemble8/lib/ +**/bin +**/testbin diff --git a/buildSrc/.classpath b/buildSrc/.classpath index d5a88e9dd6..61b3967dd3 100644 --- a/buildSrc/.classpath +++ b/buildSrc/.classpath @@ -1,14 +1,14 @@ - - - - - - - - - - - + + + + + + + + + + + diff --git a/modules/javafx.base/.classpath b/modules/javafx.base/.classpath index f93c7fa21b..beafbb5d8c 100644 --- a/modules/javafx.base/.classpath +++ b/modules/javafx.base/.classpath @@ -21,7 +21,6 @@ - diff --git a/modules/javafx.controls/.classpath b/modules/javafx.controls/.classpath index ac8be57636..a0e058a781 100644 --- a/modules/javafx.controls/.classpath +++ b/modules/javafx.controls/.classpath @@ -1,6 +1,7 @@ + @@ -38,8 +39,6 @@ - - diff --git a/modules/javafx.controls/src/main/java/javafx/scene/control/Dialog.java b/modules/javafx.controls/src/main/java/javafx/scene/control/Dialog.java index ed1348353d..d5dd38277f 100644 --- a/modules/javafx.controls/src/main/java/javafx/scene/control/Dialog.java +++ b/modules/javafx.controls/src/main/java/javafx/scene/control/Dialog.java @@ -269,6 +269,9 @@ public class Dialog implements EventTarget { initModality(Modality.APPLICATION_MODAL); } + FXDialog getDialog() { + return this.dialog; + } /************************************************************************** @@ -517,7 +520,7 @@ public class Dialog implements EventTarget { final boolean isExpanded = content == null ? false : content.isVisible(); setResizable(isExpanded); - Dialog.this.dialog.sizeToScene(); + Dialog.this.getDialog().sizeToScene(); }; final InvalidationListener headerListener = o -> { diff --git a/modules/javafx.fxml/src/main/java/module-info.java b/modules/javafx.fxml/src/main/java/module-info.java index 955bfe5d9c..f01d7c1827 100644 --- a/modules/javafx.fxml/src/main/java/module-info.java +++ b/modules/javafx.fxml/src/main/java/module-info.java @@ -35,6 +35,7 @@ module javafx.fxml { requires javafx.graphics; requires transitive javafx.base; + requires static javafx.controls; exports javafx.fxml; } diff --git a/modules/javafx.graphics/.classpath b/modules/javafx.graphics/.classpath index 122a75941e..84041561fe 100644 --- a/modules/javafx.graphics/.classpath +++ b/modules/javafx.graphics/.classpath @@ -1,6 +1,8 @@ + + @@ -37,8 +39,6 @@ - - diff --git a/modules/javafx.graphics/src/main/java/com/sun/marlin/MarlinUtils.java b/modules/javafx.graphics/src/main/java/com/sun/marlin/MarlinUtils.java index 55c775a06f..428c799178 100644 --- a/modules/javafx.graphics/src/main/java/com/sun/marlin/MarlinUtils.java +++ b/modules/javafx.graphics/src/main/java/com/sun/marlin/MarlinUtils.java @@ -64,7 +64,7 @@ public final class MarlinUtils { /** * Returns a root thread group. - * Should be called with {@link sun.security.util.SecurityConstants#MODIFY_THREADGROUP_PERMISSION} + * Should be called with sun.security.util.SecurityConstants#MODIFY_THREADGROUP_PERMISSION * * @return a root {@code ThreadGroup} */ diff --git a/modules/javafx.swing/.classpath b/modules/javafx.swing/.classpath index a195a541a3..640dcd6e8f 100644 --- a/modules/javafx.swing/.classpath +++ b/modules/javafx.swing/.classpath @@ -13,26 +13,24 @@ - - - - - + - + - + - + + + diff --git a/modules/javafx.swt/.classpath b/modules/javafx.swt/.classpath index 66917eb8a0..7e72e4709f 100644 --- a/modules/javafx.swt/.classpath +++ b/modules/javafx.swt/.classpath @@ -11,14 +11,20 @@ - - - + + + + + + + + + diff --git a/modules/javafx.web/.classpath b/modules/javafx.web/.classpath index 7d718e7812..287d1f0785 100644 --- a/modules/javafx.web/.classpath +++ b/modules/javafx.web/.classpath @@ -59,8 +59,6 @@ - - diff --git a/modules/javafx.web/src/main/java/module-info.java b/modules/javafx.web/src/main/java/module-info.java index 061972b6e5..9f43173083 100644 --- a/modules/javafx.web/src/main/java/module-info.java +++ b/modules/javafx.web/src/main/java/module-info.java @@ -40,6 +40,7 @@ module javafx.web { requires transitive javafx.base; requires transitive javafx.controls; requires transitive javafx.graphics; + requires static java.management; exports javafx.scene.web; From tom.schindl at bestsolution.at Wed Aug 8 07:10:48 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 8 Aug 2018 09:10:48 +0200 Subject: Swing module's module-info file In-Reply-To: <2a8118e2-fe92-3464-a7b7-7d7bf5f50e03@bestsolution.at> References: <55d7742c-e691-01eb-2aae-1a54dec64fd3@bestsolution.at> <3e9d1bf4-ddb5-c980-bf39-3c185dc77ad7@bestsolution.at> <5cdbbe13-68e6-d26e-7186-11d2039d3cd9@bestsolution.at> <2a8118e2-fe92-3464-a7b7-7d7bf5f50e03@bestsolution.at> Message-ID: Hi, On 08.08.18 08:55, Tom Schindl wrote: > Hi Nir, > > I currently use the attached stash to make Eclipse compile all modules. > > Unfortunately I have to modify the following java-Files to get away > without any compile errors: > * Dialog => Added a method getDialog() instead of directly accessing the > field > * javafx.fxml => Add a static require for controls > * javafx.web => Add a static require for java.management Looking once more I think read-edges are completely missing in Eclipse for projects. I can patch other projects to get a read-edge but not the project itself! In the end what we want is to patch eg the javafx.fxml-module to have a read-edge for javafx.control. I don't see how this can be done with the current Eclipse setup! My work around today is to add static-require and I don't see a way around that. 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 nlisker at gmail.com Wed Aug 8 13:19:49 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 8 Aug 2018 16:19:49 +0300 Subject: Swing module's module-info file In-Reply-To: References: <55d7742c-e691-01eb-2aae-1a54dec64fd3@bestsolution.at> <3e9d1bf4-ddb5-c980-bf39-3c185dc77ad7@bestsolution.at> <5cdbbe13-68e6-d26e-7186-11d2039d3cd9@bestsolution.at> <2a8118e2-fe92-3464-a7b7-7d7bf5f50e03@bestsolution.at> Message-ID: Yes, but since this thread was about the Swing module's module-info I'll start another thread with the link to the JBS issue I created a few days ago about Eclipse. On Wed, Aug 8, 2018 at 10:10 AM, Tom Schindl wrote: > Hi, > > On 08.08.18 08:55, Tom Schindl wrote: > > Hi Nir, > > > > I currently use the attached stash to make Eclipse compile all modules. > > > > Unfortunately I have to modify the following java-Files to get away > > without any compile errors: > > * Dialog => Added a method getDialog() instead of directly accessing the > > field > > * javafx.fxml => Add a static require for controls > > * javafx.web => Add a static require for java.management > > Looking once more I think read-edges are completely missing in Eclipse > for projects. I can patch other projects to get a read-edge but not the > project itself! > > In the end what we want is to patch eg the javafx.fxml-module to have a > read-edge for javafx.control. I don't see how this can be done with the > current Eclipse setup! > > My work around today is to add static-require and I don't see a way > around that. > > 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 nlisker at gmail.com Wed Aug 8 14:07:51 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 8 Aug 2018 17:07:51 +0300 Subject: JDK-8209015: Update Eclipse project files Message-ID: Hi, After the removal of some dependencies on JDK modules the Eclipse classpath files should be updated to allow developers to work on Eclipse without needing to do tricky configuration themselves. Iv'e submitted a JBS issue [1] to track the progress. There were discussion about removing IDE-specific files in the JBS [2] and on GitHub (see links in JBS issue). It seems that the idea was dropped and I propose to close this issue. A discussion on this issue can be found on the mailing list [3]. On to the technical discussion: Iv'e put up a gist with my classpath files [4], but Swing still gives me problems with an NPE during the build. On 08.08.18 08:55, Tom Schindl wrote: > > Hi Nir, > > > > I currently use the attached stash to make Eclipse compile all modules. > > > > Unfortunately I have to modify the following java-Files to get away > > without any compile errors: > > * Dialog => Added a method getDialog() instead of directly accessing the > > field > We have to wait for the fix [5], there's no workaround. > > * javafx.fxml => Add a static require for controls > > * javafx.web => Add a static require for java.management > > Looking once more I think read-edges are completely missing in Eclipse > for projects. I can patch other projects to get a read-edge but not the > project itself! > > In the end what we want is to patch eg the javafx.fxml-module to have a > read-edge for javafx.control. I don't see how this can be done with the > current Eclipse setup! > > My work around today is to add static-require and I don't see a way > around that. > It's possible to do it in the classpath file as Iv'e shown in [6], but I don't know if JUnit will work. I seem to have general JUnit problems. Can you try with my files and unmodified module-info.java files and see which projects can run JUnit? They should all compile. The bulk of the work for modular support is tracked under [7] and they want input from users, so try to help them. There's also a UI specific issue for modular projects [8]. - Nir [1] https://bugs.openjdk.java.net/browse/JDK-8209015 [2] https://bugs.openjdk.java.net/browse/JDK-8198795 [3] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021740.html [4] https://gist.github.com/nlisker/fd2d42f6467c069cf8c4cc054ba0ea40 [5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=536330 [6] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526963 [7] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526831 [8] https://bugs.eclipse.org/bugs/show_bug.cgi?id=536330 From kevin.rushforth at oracle.com Wed Aug 8 17:25:38 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 8 Aug 2018 10:25:38 -0700 Subject: OpenJFX 11 is in Rampdown Phase Two (RDP2) In-Reply-To: <7d757b86-d73f-a101-6080-eb74fc1494b0@oracle.com> References: <7d757b86-d73f-a101-6080-eb74fc1494b0@oracle.com> Message-ID: <60e6a992-c551-bbd8-6a97-bc54bdc086f0@oracle.com> One more item of interest to developers who use the javafxports/openjdk-jfx GitHub sandbox repo [1] : I just pushed a new 'jfx-11' branch to GitHub. The 'jfx-11' branch will track changesets pushed to the HG openjfx/11-dev/rt repo in the same manner that the 'master' branch tracks changesets pushed to the HG openjfx/jfx-dev/rt repo. Developers should consider this branch "read-only" and not make any pull requests against it (other than experimental "WIP" PRs for test purposes). All PRs should continue to be done against the develop branch. Let Johan or I know if you have any questions. -- Kevin [1] https://github.com/javafxports/openjdk-jfx On 8/7/2018 3:31 PM, Kevin Rushforth wrote: > To: OpenJFX Developers > > As a reminder, OpenJFX 11 is now in Rampdown Phase Two RDP2. [1] > > During RDP2, all bug fixes, except for docs and test fixes, and all > enhancements will need explicit approval to go in. Note that these > restrictions apply to the soon-to-be-created openjfx/11-dev/rt repo [2]. > > Starting now, the jfx-dev/rt mainline -- and by extension, the develop > branch of the GitHub sandbox -- is open for openjfx12 fixes. > > We will use the same rules for RDP2 that the JDK uses [3], 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-fix-request", > "openjfx11-fix-yes", "openjfx11-fix-no" and "openjfx11-fix-nmi", > "openjfx11-enhancement-request", "openjfx11-enhancement-yes", > "openjfx11-enhancement-no" and "openjfx11-enhancement-nmi" as > corresponding labels. > > 3. Some important P3 bugs might be considered during RDP2, as long as > those bugs have otherwise met the usual code review criteria. Having > said that, most P3 bugs should be moved to openjfx12 at this point. I > do not expect many P3 bugs to be approved. > > If a fix is approved to push to 11-dev (with the appropriate approval > label added by a lead), then you need not also push it to jfx-dev -- > we will auto-sync from 11-dev --> jfx-dev for the duration of the > openjfx11 release. > > Now that we are in RDP2, the goal should be to stabilize what is > there, with priority on fixing bugs that are new in openjfx11. We need > to be extremely careful 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-August/022233.html > > [2] http://hg.openjdk.java.net/openjfx/11-dev/rt? (not yet created as > of this writing) > > [3] http://openjdk.java.net/jeps/3 > From temp325 at live.fr Thu Aug 9 07:54:27 2018 From: temp325 at live.fr (cyril fischer) Date: Thu, 9 Aug 2018 07:54:27 +0000 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: References: Message-ID: I am following openjfx11 carefully, if I understand there won't be a packager tool ? And the answer to this is to use the packager from the jdk10. If I also understand the end of support of jdk10 start with the release of jdk11. So how long will the not supported jdk10 packager will stay compatible ? What will happen if it become incompatible ? (it happen quite recently [1] ) So what is the TL;DR ? How will I package my application (with javaFX) to release a standalone. exe app (with jre bundled) with jdk11? [1] https://bugs.openjdk.java.net/browse/JDK-8191176 My first mail on this mailing list !!! ?? From mike.ennen at gmail.com Thu Aug 9 08:02:10 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Thu, 9 Aug 2018 01:02:10 -0700 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: References: Message-ID: See this message from Kevin Rushforth about a javapackager replacement: We are proposing a JEP to add a new 'jpackager' tool [1] as a > replacement for javapackager. The discussion is on core-libs-dev [2] [3] > [4]. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8200758 > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html > [3] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054296.html > [4] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054565.html > On Thu, Aug 9, 2018 at 12:54 AM cyril fischer wrote: > > I am following openjfx11 carefully, if I understand there won't be a > packager tool ? And the answer to this is to use the packager from the > jdk10. If I also understand the end of support of jdk10 start with the > release of jdk11. > > So how long will the not supported jdk10 packager will stay compatible ? > What will happen if it become incompatible ? (it happen quite recently [1] ) > > > So what is the TL;DR ? > > How will I package my application (with javaFX) to release a standalone. > exe app (with jre bundled) with jdk11? > > > [1] https://bugs.openjdk.java.net/browse/JDK-8191176 > > My first mail on this mailing list !!! ?? > -- Michael Ennen From temp325 at live.fr Thu Aug 9 09:42:15 2018 From: temp325 at live.fr (Cyril F) Date: Thu, 9 Aug 2018 09:42:15 +0000 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: References: , Message-ID: I am sure the new jpackager tool will be a good substitute. But won't come before jdk12... In fact we are in the current situation : We have a javaFX8 app distributed as a .exe with a bundled JRE. We are mirating to javaFX11. My fear is that there will be a gap between javafx11 (october) and the new jpackager (not before jdk12) where no official and supported tool will be provided. In this situation (I am sure we are not alone) what should we do ? Wait for the new jpackager ? or start using openjfx11 with no real certainty ? use an other tool ? Cyril From mp at jugs.org Thu Aug 9 10:19:35 2018 From: mp at jugs.org (Michael Paus) Date: Thu, 9 Aug 2018 12:19:35 +0200 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: References: Message-ID: 1. What forces you to make the switch from 8 to 11 at the same day when jdk11 comes out? 2. The plan is that when jdk11 comes out there will already be an EA version of jdk12 available which ??? already contains a version of the new packager which will also work with jdk11 then. ??? As long as this plan holds, there will be no gap. Am 09.08.18 um 11:42 schrieb Cyril F: > I am sure the new jpackager tool will be a good substitute. But won't come before jdk12... > > In fact we are in the current situation : > We have a javaFX8 app distributed as a .exe with a bundled JRE. > We are mirating to javaFX11. > > My fear is that there will be a gap between javafx11 (october) and the new jpackager (not before jdk12) where no official and supported tool will be provided. > > In this situation (I am sure we are not alone) what should we do ? Wait for the new jpackager ? or start using openjfx11 with no real certainty ? use an other tool ? > > Cyril From johan.vos at gluonhq.com Thu Aug 9 13:00:02 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 9 Aug 2018 15:00:02 +0200 Subject: Fate of jdk.packager and jdk.packager.services? In-Reply-To: References: Message-ID: We (Gluon) are looking into creating a JavaFX 11 version of the packager. - Johan On Thu, Aug 9, 2018 at 1:42 PM Cyril F wrote: > I am sure the new jpackager tool will be a good substitute. But won't come > before jdk12... > > In fact we are in the current situation : > We have a javaFX8 app distributed as a .exe with a bundled JRE. > We are mirating to javaFX11. > > My fear is that there will be a gap between javafx11 (october) and the new > jpackager (not before jdk12) where no official and supported tool will be > provided. > > In this situation (I am sure we are not alone) what should we do ? Wait > for the new jpackager ? or start using openjfx11 with no real certainty ? > use an other tool ? > > Cyril > From steve.hruda at gmail.com Thu Aug 9 13:32:42 2018 From: steve.hruda at gmail.com (Steve Hruda) Date: Thu, 9 Aug 2018 15:32:42 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: Johan, another temporary fix could be the META-INF attribute "Automatic-Module-Name". E.g. set it at the empty jar to javafx.controls.workaround https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#main-attributes Regards, Steve Am Sa., 14. Juli 2018 um 12:16 Uhr schrieb Steve Hruda < steve.hruda at gmail.com>: > 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 >>> >> -- Mit freundlichen Gr??en Steve Hruda From johan.vos at gluonhq.com Thu Aug 9 13:33:38 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 9 Aug 2018 15:33:38 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: Right, that's a good idea. Thanks. On Thu, Aug 9, 2018 at 3:32 PM Steve Hruda wrote: > Johan, > another temporary fix could be the META-INF attribute > "Automatic-Module-Name". E.g. set it at the empty jar to > javafx.controls.workaround > https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#main-attributes > > Regards, > Steve > > Am Sa., 14. Juli 2018 um 12:16 Uhr schrieb Steve Hruda < > steve.hruda at gmail.com>: > >> 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 >>>> >>> > > -- > Mit freundlichen Gr??en > Steve Hruda > From kevin.rushforth at oracle.com Fri Aug 10 12:38:46 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 10 Aug 2018 05:38:46 -0700 Subject: [11] Review request: 8209358: Broken links in API docs for css page, fxml page, and all image files Message-ID: <4479c0b3-a872-5ea4-8bdd-3e9a0ae574f4@oracle.com> Please review the following simple fix to copy the javadoc resources into the correct place when using JDK 11 (or later) as a boot JDK: https://bugs.openjdk.java.net/browse/JDK-8209358 http://cr.openjdk.java.net/~kcr/8209358/webrev/ -- Kevin From arunprasad.rajkumar at oracle.com Mon Aug 13 13:01:52 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Mon, 13 Aug 2018 18:31:52 +0530 Subject: [RFR] 8209049: Cherry pick GTK WebKit 2.20.4 changes Message-ID: <09941ABC-94CE-408A-8845-00348187DA9E@oracle.com> Hi Kevin/Murali, Please review the fix the following bug, https://bugs.openjdk.java.net/browse/JDK-8209049 I didn?t generate webrev because patch contains changes from GTK WebKit 2.20.4 branch[1]. [1] https://trac.webkit.org/log/webkit/releases/WebKitGTK/webkit-2.20 Thanks, Arun From arunprasad.rajkumar at oracle.com Mon Aug 13 16:01:15 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Mon, 13 Aug 2018 21:31:15 +0530 Subject: [RFR] 8209191: [macOS] Distorted complex text rendering Message-ID: <2AF387C1-3AD0-4701-A69B-A7B1A6940812@oracle.com> Hi Kevin,Phil, Please review the fix for following bug, https://bugs.openjdk.java.net/browse/JDK-8209191 Root cause: JDK-8198354 takes care of NULL return from CTRunGetGlyphsPtr, the similar treatment has to be given for CTRunGetPositionsPtr[1] as well. (CTRunGetStringIndicesPtr already got that treatment). Webrev: http://cr.openjdk.java.net/~arajkumar/8209191/webrev.01 [1] https://developer.apple.com/documentation/coretext/1510044-ctrungetpositionsptr?language=objc Thanks, Arun From mnachev.nscenter.eu at gmail.com Tue Aug 14 14:12:39 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Tue, 14 Aug 2018 17:12:39 +0300 Subject: JavaFX (FXML) to HTML5+CSS+JavaScript Message-ID: Hi, I'm not sure, this is the right place for this question, and yet I want to ask, is there any active project or a working product that converts JavaFX (FXML) to HTML5+CSS+ JavaScript - statically or dynamically? Thank you in advance. Regards, Miro. From kevin.rushforth at oracle.com Tue Aug 14 20:36:38 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 Aug 2018 13:36:38 -0700 Subject: [11] Review request: 8209507: Incorrect copyright header for some Ensemble samples Message-ID: <6c1c4de9-1264-ca20-a10b-cd6f6027fe94@oracle.com> Phil, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8209507 http://cr.openjdk.java.net/~kcr/8209507/webrev/ This fixes a bug in the copyright header of two source files in the Ensemble sample. -- Kevin From nlisker at gmail.com Wed Aug 15 05:43:28 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 15 Aug 2018 08:43:28 +0300 Subject: Review Request: JDK-8209015: Update Eclipse project files Message-ID: Hi, Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8209015 http://cr.openjdk.java.net/~nlisker/8209015/webrev.00/ Thanks, Nir From pedro.duquevieira at gmail.com Wed Aug 15 14:15:18 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 15 Aug 2018 15:15:18 +0100 Subject: JavaFX (FXML) to HTML5+CSS+JavaScript Message-ID: Hi, Check out jpro (https://www.jpro.one/) AFAIK it converts the whole javafx app to a web version (html, javascript) not just the FXML. Cheers, -- Pedro Duque Vieira - https://www.pixelduke.com From la.tinca at gmail.com Wed Aug 15 14:40:16 2018 From: la.tinca at gmail.com (=?UTF-8?Q?Zsolt_K=C3=BAti?=) Date: Wed, 15 Aug 2018 16:40:16 +0200 Subject: JavaFX (FXML) to HTML5+CSS+JavaScript In-Reply-To: References: Message-ID: Hello, This coversation adds some bits of info: https://www.reddit.com/r/JavaFX/comments/5aqdrk/jproio_is_bringing_javafx_back_to_browser/ Bye On Wed, Aug 15, 2018 at 4:15 PM Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > Hi, > > Check out jpro (https://www.jpro.one/) > > AFAIK it converts the whole javafx app to a web version (html, javascript) > not just the FXML. > > Cheers, > > > -- > Pedro Duque Vieira - https://www.pixelduke.com > From mnachev.nscenter.eu at gmail.com Wed Aug 15 15:16:53 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Wed, 15 Aug 2018 18:16:53 +0300 Subject: JavaFX (FXML) to HTML5+CSS+JavaScript Message-ID: Thank you :) On Wed, Aug 15, 2018 at 5:15 PM, Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > Hi, > > Check out jpro (https://www.jpro.one/) > > AFAIK it converts the whole javafx app to a web version (html, javascript) > not just the FXML. > > Cheers, > > > -- > Pedro Duque Vieira - https://www.pixelduke.com > From lenborje at gmail.com Thu Aug 16 09:26:26 2018 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Thu, 16 Aug 2018 11:26:26 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: FWIW, I've fixed the Gradle builds in the current javafx11samples and sent you a pull request. I know these samples are only temporary, but I believe I'm not the only gradle user who's been frustrated by not having any working example to try out. My fix still uses the 11.0.0-SNAPSHOT builds and sets the classifier in the dependencies using Gradle's OPeratingSystem class. Best regards, /Lennart From arunprasad.rajkumar at oracle.com Thu Aug 16 18:46:37 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Fri, 17 Aug 2018 00:16:37 +0530 Subject: [RFR] JDK-8209457] [WebView : Canvas.toDataURL with image/jpeg MIME type fails Message-ID: <234DA1BF-3B47-47BD-B7FC-9F9C658B6EB5@oracle.com> Hi Kevin, Murali, Please review the fix for following bug, https://bugs.openjdk.java.net/browse/JDK-8209457 Root cause: BufferedImage is created with ARGB color model while converting from PrismImage to JPEG. JPEG doesn't supports alpha channel, which leads to error while encoding to JPEG image. Proposed fix: HTMl applications passes the destination image mime type, make use of it and hardwire the color model as RGB when the mime type is 'image/jpeg'. webrev: http://cr.openjdk.java.net/~arajkumar/8209457/webrev/ Thanks, Arun From kevin.rushforth at oracle.com Fri Aug 17 21:04:01 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 17 Aug 2018 14:04:01 -0700 Subject: [12] Review request: 8203379: Remove javapackager sources from OpenJFX repo Message-ID: Please review the following to remove the javapackager sources and build logic from the openjfx repo: https://bugs.openjdk.java.net/browse/JDK-8203379 http://cr.openjdk.java.net/~kcr/8203379/webrev.00/ See JBS for more information. -- Kevin From pnem at cmail.cz Sun Aug 19 14:00:37 2018 From: pnem at cmail.cz (Petr Nemecek) Date: Sun, 19 Aug 2018 16:00:37 +0200 Subject: JavaFX Deployment Message-ID: <003101d437c5$01f02f70$05d08e50$@cmail.cz> Hi all, I'm a nebiew to JavaFX, currently rewriting our industrial Flex app into JavaFX. So far so good (I like it!), it is just not clear to me, how to deploy the app once the Java Web Start is gone and JavaFX will not be bundled in Java itself. Questions: 1) Is there something similar to Java Web Start available? 1) If I would like to distribute the app just as a single jar, will I have to make two different builds, one without JavaFX for Java 10- users and one with embedded JavaFX for Java 11+ users? Many thanks, Petr From johan.vos at gluonhq.com Mon Aug 20 09:49:16 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 20 Aug 2018 11:49:16 +0200 Subject: JavaFX Deployment In-Reply-To: <003101d437c5$01f02f70$05d08e50$@cmail.cz> References: <003101d437c5$01f02f70$05d08e50$@cmail.cz> Message-ID: Hi Petr, Your questions are actually related. The recommended way for distributing JavaFX apps is by bundling them with the required libraries, modules and VM into an executable. That way, you determine whether your application works with Java 8, 9, 10, 11 or beyond. You simply bundle the required components of the JRE with your app, so that users don't need to have the correct version of Java installed. - Johan On Sun, Aug 19, 2018 at 4:11 PM Petr Nemecek wrote: > Hi all, > > I'm a nebiew to JavaFX, currently rewriting our industrial Flex app into > JavaFX. So far so good (I like it!), it is just not clear to me, how to > deploy the app once the Java Web Start is gone and JavaFX will not be > bundled in Java itself. > > Questions: > 1) Is there something similar to Java Web Start available? > 1) If I would like to distribute the app just as a single jar, will I have > to make two different builds, one without JavaFX for Java 10- users and one > with embedded JavaFX for Java 11+ users? > > Many thanks, > Petr > > From pnem at cmail.cz Mon Aug 20 10:37:07 2018 From: pnem at cmail.cz (Petr Nemecek) Date: Mon, 20 Aug 2018 12:37:07 +0200 Subject: JavaFX Deployment In-Reply-To: References: <003101d437c5$01f02f70$05d08e50$@cmail.cz> Message-ID: <006001d43871$be920ed0$3bb62c70$@cmail.cz> Hi Johan, that makes sense, thanks for feedback. If I would prefer to distribute just a single jar, in order not to force users to install stuff etc., and if it will contain latest JavaFX, will it work under older Java version, which contain older version of JavaFX? Thanks, Petr From: Johan Vos Sent: Monday, August 20, 2018 11:49 AM To: Petr Nemecek Cc: openjfx-dev at openjdk.java.net Subject: Re: JavaFX Deployment Hi Petr, Your questions are actually related. The recommended way for distributing JavaFX apps is by bundling them with the required libraries, modules and VM into an executable. That way, you determine whether your application works with Java 8, 9, 10, 11 or beyond. You simply bundle the required components of the JRE with your app, so that users don't need to have the correct version of Java installed. - Johan On Sun, Aug 19, 2018 at 4:11 PM Petr Nemecek > wrote: Hi all, I'm a nebiew to JavaFX, currently rewriting our industrial Flex app into JavaFX. So far so good (I like it!), it is just not clear to me, how to deploy the app once the Java Web Start is gone and JavaFX will not be bundled in Java itself. Questions: 1) Is there something similar to Java Web Start available? 1) If I would like to distribute the app just as a single jar, will I have to make two different builds, one without JavaFX for Java 10- users and one with embedded JavaFX for Java 11+ users? Many thanks, Petr From shlomo.belleli at gmail.com Mon Aug 20 15:12:53 2018 From: shlomo.belleli at gmail.com (Shlomo Belleli) Date: Mon, 20 Aug 2018 18:12:53 +0300 Subject: JavaFX Deployment In-Reply-To: References: <003101d437c5$01f02f70$05d08e50$@cmail.cz> Message-ID: Hi Petr This issue is a real problem for anyone that needs to deploy JavaFX and don't have the Webstart any more I am working on this issue for my own applications, and even talked with Johan about this, a few months ago there some issues here that you need to take into your consideration who are your users - inside (workplace) or outside (web), the answer can change the solution can your customer have the patience to download a store like application and install? how you will handle updates and hotfixes (new install? what will be the size?) a single jar can be a problem if you need fast updates in the future what the size of your application is your app ready for Jigsaw (modules... from JRE 9) what is the size of the JRE (after modeling with jlink ) your app needs, a bundled application with the JRE can be a big file XXX MB (modules can help here) which version of the JRE your app needs proxy/antivirus while downloading ??? don't forget them where you will publish your app and how customers/users will reach this location how you are going to deploy your app from classes to jars/modules... (launch4j? inno? ant? others?) depends on resources and or folders and such in the app folder how your app will distinguish a user with lower version and suggest a new version (new update) if you need help, I am here to share with you my experience in this subject Shlomo ??????? ??? ??, 20 ????? 2018 ?-12:50 ??? ?Johan Vos?? :? > Hi Petr, > > Your questions are actually related. The recommended way for distributing > JavaFX apps is by bundling them with the required libraries, modules and VM > into an executable. That way, you determine whether your application works > with Java 8, 9, 10, 11 or beyond. You simply bundle the required components > of the JRE with your app, so that users don't need to have the correct > version of Java installed. > > - Johan > > On Sun, Aug 19, 2018 at 4:11 PM Petr Nemecek wrote: > > > Hi all, > > > > I'm a nebiew to JavaFX, currently rewriting our industrial Flex app into > > JavaFX. So far so good (I like it!), it is just not clear to me, how to > > deploy the app once the Java Web Start is gone and JavaFX will not be > > bundled in Java itself. > > > > Questions: > > 1) Is there something similar to Java Web Start available? > > 1) If I would like to distribute the app just as a single jar, will I > have > > to make two different builds, one without JavaFX for Java 10- users and > one > > with embedded JavaFX for Java 11+ users? > > > > Many thanks, > > Petr > > > > > -- Shlomo belleli 972-50-7200510 shlomo.belleli at gmail.com From arunprasad.rajkumar at oracle.com Mon Aug 20 17:30:18 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Mon, 20 Aug 2018 23:00:18 +0530 Subject: [RFR] 8207159:Update ICU to version 62.1 Message-ID: Hi, Please review the fix for JDK-8207159. Changeset: 1. Build system related changes(done by us): http://cr.openjdk.java.net/~arajkumar/8207159/webrev 2. Complete changeset({62.1 icu + build system} changes): http://cr.openjdk.java.net/~arajkumar/8207159/webrev/icu.core.changeset.gz #1 contains build system related changes which need to be reviewed. Following are the major build system changes WRT to previous ICU, a. Simplified CMake scripts, `icu/CMakeLists.txt` is now responsible to build icuuc, icu18n, icudata libraries. b. Removed icudata building shell script and simplified the data build process using data_as_asm.cpp, it converts the given icudt*.dat file into static library. It is written specifically for JavaFX(not from ICU). c. icudt*.zip is moved from `icu/sources/data/in/icudt*.zip` to `icu/java/data/icudt*.zip`.(Currently we zip the icudt*.dat file, but I don't see a reason to compress because mercurial itself compresses the files when storing) #2 contains the actual changeset file in compressed format, follow the below steps to apply $ cd rt $ wget http://cr.openjdk.java.net/~arajkumar/8207159/webrev/icu.core.changeset.gz -O - | gunzip | hg import - ?no-commit Thanks, Arun From pedro.duquevieira at gmail.com Mon Aug 20 21:40:29 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 20 Aug 2018 22:40:29 +0100 Subject: JavaFX Deployment Message-ID: Hi Petr, I agree with Johan, best way to distribute a JavaFX app is to bundle Java with your app. Also, not everyone as Java installed. So if you distribute just the jars so that people don't have to install anything, they might have to end up having to install Java anyway. Cheers, -- Pedro Duque Vieira - https://www.pixelduke.com From kevin.rushforth at oracle.com Mon Aug 20 22:02:08 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Aug 2018 15:02:08 -0700 Subject: JavaFX Deployment In-Reply-To: References: Message-ID: <6d0acd48-7341-1493-0a89-9e29fcc38365@oracle.com> I agree with this advice, too. The easiest way is to take the javafx jmods and use 'jlink' to produce the JDK you need. If your application is modularized, you can jlink your app into the java runtime image and only pull in the modules you need. If you have more advanced needs, I note that we are looking to add a 'jpackager' tool as a replacement for the javapackager (which was delivered along with javafx in JDK 10). You can follow the discussion on core-libs-dev [1]. -- Kevin [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054565.html On 8/20/2018 2:40 PM, Pedro Duque Vieira wrote: > Hi Petr, > > I agree with Johan, best way to distribute a JavaFX app is to bundle Java > with your app. Also, not everyone as Java installed. So if you distribute > just the jars so that people don't have to install anything, they might > have to end up having to install Java anyway. > > Cheers, > From mike.ennen at gmail.com Tue Aug 21 00:59:35 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 20 Aug 2018 17:59:35 -0700 Subject: Review-Request for JDK-8209765 Message-ID: Hi, I'd like to request a review for JDK-8209765 available as a PR on Github: https://github.com/javafxports/openjdk-jfx/pull/153 Thanks. -- Michael Ennen From mike.ennen at gmail.com Tue Aug 21 01:00:38 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 20 Aug 2018 18:00:38 -0700 Subject: Review-Request for JDK-8209764 Message-ID: Hi, I'd like to request a review for JDK-8209764 available as a PR on Github: https://github.com/javafxports/openjdk-jfx/pull/155 Thanks. -- Michael Ennen From ank.cpp at gmail.com Tue Aug 21 20:44:32 2018 From: ank.cpp at gmail.com (ankit srivastav) Date: Wed, 22 Aug 2018 02:14:32 +0530 Subject: INFO: JFX Issue Message-ID: Team, I would like to work on below issue, let me know if anyone else is working on the same. https://bugs.openjdk.java.net/browse/JDK-8207772 --Ankit From kevin.rushforth at oracle.com Tue Aug 21 21:37:02 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 21 Aug 2018 14:37:02 -0700 Subject: INFO: JFX Issue In-Reply-To: References: Message-ID: <0ddc425f-4e4c-23b5-dd2d-b4fd20eeb1ba@oracle.com> Hi Ankit, This one is actively under development by Murali; it was just targeted to openjfx12 today. If you have any comments on this enhancement that might be helpful, you can add them to JBS or share them on the list. Thanks. -- Kevin On 8/21/2018 1:44 PM, ankit srivastav wrote: > Team, > > I would like to work on below issue, let me know if anyone else is working > on the same. > > https://bugs.openjdk.java.net/browse/JDK-8207772 > > > --Ankit From nlisker at gmail.com Tue Aug 21 21:40:33 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 22 Aug 2018 00:40:33 +0300 Subject: INFO: JFX Issue In-Reply-To: <0ddc425f-4e4c-23b5-dd2d-b4fd20eeb1ba@oracle.com> References: <0ddc425f-4e4c-23b5-dd2d-b4fd20eeb1ba@oracle.com> Message-ID: Hi, Shouldn't it be marked as In Progress in this case? - Nir On Wed, Aug 22, 2018 at 12:37 AM Kevin Rushforth wrote: > Hi Ankit, > > This one is actively under development by Murali; it was just targeted > to openjfx12 today. If you have any comments on this enhancement that > might be helpful, you can add them to JBS or share them on the list. > > Thanks. > > -- Kevin > > > On 8/21/2018 1:44 PM, ankit srivastav wrote: > > Team, > > > > I would like to work on below issue, let me know if anyone else is > working > > on the same. > > > > https://bugs.openjdk.java.net/browse/JDK-8207772 > > > > > > --Ankit > > From kevin.rushforth at oracle.com Tue Aug 21 21:56:30 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 21 Aug 2018 14:56:30 -0700 Subject: INFO: JFX Issue In-Reply-To: References: <0ddc425f-4e4c-23b5-dd2d-b4fd20eeb1ba@oracle.com> Message-ID: <39fffc02-a380-04bc-da65-6b11402abb68@oracle.com> Yes, that's generally a good idea. In this case, it was just targeted to openjfx12 earlier today, so the status hasn't been updated.. -- Kevin On 8/21/2018 2:40 PM, Nir Lisker wrote: > Hi, > > Shouldn't it be marked as In Progress in this case? > > - Nir > > On Wed, Aug 22, 2018 at 12:37 AM Kevin Rushforth > > wrote: > > Hi Ankit, > > This one is actively under development by Murali; it was just > targeted > to openjfx12 today. If you have any comments on this enhancement that > might be helpful, you can add them to JBS or share them on the list. > > Thanks. > > -- Kevin > > > On 8/21/2018 1:44 PM, ankit srivastav wrote: > > Team, > > > > I would like to work on below issue, let me know if anyone else > is working > > on the same. > > > > https://bugs.openjdk.java.net/browse/JDK-8207772 > > > > > > --Ankit > From kevin.rushforth at oracle.com Tue Aug 21 22:00:45 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 21 Aug 2018 15:00:45 -0700 Subject: INFO: JFX Issue In-Reply-To: <39fffc02-a380-04bc-da65-6b11402abb68@oracle.com> References: <0ddc425f-4e4c-23b5-dd2d-b4fd20eeb1ba@oracle.com> <39fffc02-a380-04bc-da65-6b11402abb68@oracle.com> Message-ID: <1e197ba2-4a56-6477-2f47-31e61f5345eb@oracle.com> I should add, that it's always fine to ask the question. In many cases bugs targeted for the current dev release (openjfx12 in this case) are often planned to be worked on soon even if they aren't in progress at the moment, but this isn't always the case, so please do ask if there is a bug you want to work on. Thanks. -- Kevin On 8/21/2018 2:56 PM, Kevin Rushforth wrote: > Yes, that's generally a good idea. In this case, it was just targeted > to openjfx12 earlier today, so the status hasn't been updated.. > > -- Kevin > > > On 8/21/2018 2:40 PM, Nir Lisker wrote: >> Hi, >> >> Shouldn't it be marked as In Progress in this case? >> >> - Nir >> >> On Wed, Aug 22, 2018 at 12:37 AM Kevin Rushforth >> > wrote: >> >> ??? Hi Ankit, >> >> ??? This one is actively under development by Murali; it was just >> ??? targeted >> ??? to openjfx12 today. If you have any comments on this enhancement >> that >> ??? might be helpful, you can add them to JBS or share them on the list. >> >> ??? Thanks. >> >> ??? -- Kevin >> >> >> ??? On 8/21/2018 1:44 PM, ankit srivastav wrote: >> ??? > Team, >> ??? > >> ??? > I would like to work on below issue, let me know if anyone else >> ??? is working >> ??? > on the same. >> ??? > >> ??? > https://bugs.openjdk.java.net/browse/JDK-8207772 >> ??? > >> ??? > >> ??? > --Ankit >> > From johan.vos at gluonhq.com Wed Aug 22 12:11:32 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 22 Aug 2018 14:11:32 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: I spent some more time on this. Adding the Automatic-Module-Name seems the easiest fix to me. I created a PR at https://github.com/javafxports/openjdk-jfx/pull/162 for this. Having the platform-name hardcoded in the artifact Id would require upfront magic in build.gradle or pom.xml to prevent the need to put a platform hardcoded in the build.gradle or pom.xml. Removing the empty jars never gives a result that works fine for both maven and gradle, see https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 In the end, the real fix for this should be in maven/gradle. We currently need to specify dependencies in both the module-info.java as well as in the pom.xml. That doesn't sound right. I would assume that the gradle Java plugin should check if a dependency contains a module-info.class, and if so, parse it and process it. - Johan On Thu, Aug 16, 2018 at 11:26 AM Lennart B?rjeson wrote: > FWIW, I've fixed the Gradle builds in the current javafx11samples and sent > you a pull request. > > I know these samples are only temporary, but I believe I'm not the only > gradle user who's been frustrated by not having any working example to try > out. > > My fix still uses the 11.0.0-SNAPSHOT builds and sets the classifier in > the dependencies using Gradle's OPeratingSystem class. > > > > Best regards, > > /Lennart > > > From lenborje at gmail.com Wed Aug 22 13:03:21 2018 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Wed, 22 Aug 2018 15:03:21 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: Sound reasonable, thank you. In the meantime (waiting for the next version of the maven artefacts) I've updated my PR (https://github.com/johanvos/javafx11samples/pull/1 ) for your javafx11samples with a build.gradle work-around to filter out the empty javafx-jars. This makes your samples run with Java 11, gradle 4.9 and openjdx 11-ea+19. /Lennart > 22 aug. 2018 kl. 14:11 skrev Johan Vos : > > I spent some more time on this. > Adding the Automatic-Module-Name seems the easiest fix to me. I created a PR at https://github.com/javafxports/openjdk-jfx/pull/162 for this. > > Having the platform-name hardcoded in the artifact Id would require upfront magic in build.gradle or pom.xml to prevent the need to put a platform hardcoded in the build.gradle or pom.xml. > Removing the empty jars never gives a result that works fine for both maven and gradle, see https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 > > In the end, the real fix for this should be in maven/gradle. We currently need to specify dependencies in both the module-info.java as well as in the pom.xml. That doesn't sound right. I would assume that the gradle Java plugin should check if a dependency contains a module-info.class, and if so, parse it and process it. > > - Johan > > > > On Thu, Aug 16, 2018 at 11:26 AM Lennart B?rjeson > wrote: > FWIW, I've fixed the Gradle builds in the current javafx11samples and sent you a pull request. > > I know these samples are only temporary, but I believe I'm not the only gradle user who's been frustrated by not having any working example to try out. > > My fix still uses the 11.0.0-SNAPSHOT builds and sets the classifier in the dependencies using Gradle's OPeratingSystem class. > > > > Best regards, > > /Lennart > > From johan.vos at gluonhq.com Wed Aug 22 14:13:49 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 22 Aug 2018 16:13:49 +0200 Subject: webrev for 8209836: Automatic-Module-Name for empty jars Message-ID: Please review http://cr.openjdk.java.net/~jvos/8209836/webrev.00/ Thanks, - Johan From michab66 at gmail.com Wed Aug 22 18:47:09 2018 From: michab66 at gmail.com (Michael Binz) Date: Wed, 22 Aug 2018 20:47:09 +0200 Subject: JI-9056801 : Scene: Allow to add a stylesheet using a typed URL, not a stringified URL Message-ID: Hi all, I opened a proposal for an extension of the javafx.scene.Scene API to allow to add a stylesheet using a typed java.net.URL. Currently the Scene class offers a list of stylesheet URLs in their stringified representation accessible by Scene.getStylesheets(). The problem is that in some cases an URL instance encapsulates internal state that gets lost in the conversion into its external form and back into an URL instance, namely information on an URL handler. This ultimately results in a failure (IOException file not found) when the Screen class tries to load a stylesheet though code that loads the file contents using URL#openStream() on the original URL instance can read the file contents successfully. In my case the problem showed up when creating an executable jar file containing my JavaFX application (using OneJar). The application startup in this case installs a customized Classloader that implements special logic for accessing the jars contained classes, This works transparently for classes and resources, but the URLs returned by Class#getResource( name ) do not survive the conversion to string and back because of the described reason. There is a workaround that caches the resource in a temporary file and passes this file's URL to the Scene's list of stylesheets, but this poses other problems. As a remark, other APIs in JavaFX use the same pattern of expecting stringified URLs like the Image() constructor and have the same problem, but offer alternative constructors accepting a stream which allows to solve the problem nicely. Please discuss and decide if the proposal can be added as a change request for JavaFX. Best wishes, Michael. From priyanka.mangal at oracle.com Thu Aug 23 05:45:00 2018 From: priyanka.mangal at oracle.com (Priyanka Mangal) Date: Thu, 23 Aug 2018 11:15:00 +0530 Subject: [12] Review request: 8209791 : OpenJFX build fails in PrismPrint.c due to missing JNICALL In-Reply-To: <9917355f-a025-a58c-f5b3-5ecbf6ce7879@oracle.com> References: <9917355f-a025-a58c-f5b3-5ecbf6ce7879@oracle.com> Message-ID: Hi, Please review this fix : Webrev : http://cr.openjdk.java.net/~dkumar/primanga/8209791/webrev.00/ JBS : https://bugs.openjdk.java.net/browse/JDK-8209791 Thanks, Priyanka From lenborje at gmail.com Thu Aug 23 09:27:50 2018 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Thu, 23 Aug 2018 11:27:50 +0200 Subject: ArrayIndexOutOfBoundsException with openjfx 11-ea+23, run from gradle Message-ID: <190E496A-30DD-42AE-B287-79C457129BB0@gmail.com> After upgrading to the latest maven artefacts (11-ea+23) from the previous (11-ea+19), I get the following error when I try to run the javafx11sample hello3d from gradle: > Task :run RenderJob.run: internal exception java.lang.ArrayIndexOutOfBoundsException: 0 at java.base/java.util.Arrays$ArrayList.get(Arrays.java:4351) at java.base/java.util.Collections$UnmodifiableList.get(Collections.java:1306) at javafx.graphics/com.sun.glass.ui.Screen.getMainScreen(Screen.java:61) at javafx.graphics/com.sun.prism.sw.SWPipeline.getDefaultResourceFactory(SWPipeline.java:82) at javafx.graphics/com.sun.prism.GraphicsPipeline.getDefaultResourceFactory(GraphicsPipeline.java:120) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.lambda$createResourceFactory$2(QuantumRenderer.java:161) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.base/java.lang.Thread.run(Thread.java:831) All context can be found at https://github.com/johanvos/javafx11samples/pull/1 . The program runs fine when launched via maven or directly from the command line, so there must be some peculiarity concerning how gradle launches a program, but I can't figure out what. Note that I can run from gradle when I use the 11-ea+19 snapshots, so something must have changed in 11-ea+23 which causes this error. I'd really appreciate any help or insights with this. I get the same error when upgrading my real application, not just these samples, to 11-ea+23. This is on a Mac, BTW. From kevin.rushforth at oracle.com Thu Aug 23 12:40:41 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 23 Aug 2018 05:40:41 -0700 Subject: ArrayIndexOutOfBoundsException with openjfx 11-ea+23, run from gradle In-Reply-To: <190E496A-30DD-42AE-B287-79C457129BB0@gmail.com> References: <190E496A-30DD-42AE-B287-79C457129BB0@gmail.com> Message-ID: <2095916b-d524-e300-03a8-15d3376c0991@oracle.com> > at javafx.graphics/com.sun.prism.sw.SWPipeline.getDefaultResourceFactory(SWPipeline.java:82) This suggests that there may be some problems loading the native libs. Can you try running with '-Djavafx.verbose=true' ? Johan might have other suggestions. -- Kevin On 8/23/2018 2:27 AM, Lennart B?rjeson wrote: > After upgrading to the latest maven artefacts (11-ea+23) from the previous (11-ea+19), I get the following error when I try to run the javafx11sample hello3d from gradle: > >> Task :run > RenderJob.run: internal exception > java.lang.ArrayIndexOutOfBoundsException: 0 > at java.base/java.util.Arrays$ArrayList.get(Arrays.java:4351) > at java.base/java.util.Collections$UnmodifiableList.get(Collections.java:1306) > at javafx.graphics/com.sun.glass.ui.Screen.getMainScreen(Screen.java:61) > at javafx.graphics/com.sun.prism.sw.SWPipeline.getDefaultResourceFactory(SWPipeline.java:82) > at javafx.graphics/com.sun.prism.GraphicsPipeline.getDefaultResourceFactory(GraphicsPipeline.java:120) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.lambda$createResourceFactory$2(QuantumRenderer.java:161) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) > at java.base/java.lang.Thread.run(Thread.java:831) > > > All context can be found at https://github.com/johanvos/javafx11samples/pull/1 . > > The program runs fine when launched via maven or directly from the command line, so there must be some peculiarity concerning how gradle launches a program, but I can't figure out what. > > Note that I can run from gradle when I use the 11-ea+19 snapshots, so something must have changed in 11-ea+23 which causes this error. > > I'd really appreciate any help or insights with this. I get the same error when upgrading my real application, not just these samples, to 11-ea+23. > > This is on a Mac, BTW. > From johan at lodgon.com Thu Aug 23 13:09:32 2018 From: johan at lodgon.com (Johan Vos) Date: Thu, 23 Aug 2018 15:09:32 +0200 Subject: ArrayIndexOutOfBoundsException with openjfx 11-ea+23, run from gradle In-Reply-To: <2095916b-d524-e300-03a8-15d3376c0991@oracle.com> References: <190E496A-30DD-42AE-B287-79C457129BB0@gmail.com> <2095916b-d524-e300-03a8-15d3376c0991@oracle.com> Message-ID: The fact that you fallback to SW indicate ES2 failed to initialize indeed. I checked and merged your PR, and it runs locally fine for me on mac. As Kevin said, can you add javafx.verbose to true, as well as -Dprism.verbose=true ? Thanks for testing, these quirks are the ones we have to fix now :) - Johan Op do 23 aug. 2018 om 14:43 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > > > at > javafx.graphics/com.sun.prism.sw.SWPipeline.getDefaultResourceFactory(SWPipeline.java:82) > > This suggests that there may be some problems loading the native libs. > Can you try running with '-Djavafx.verbose=true' ? Johan might have > other suggestions. > > -- Kevin > > > On 8/23/2018 2:27 AM, Lennart B?rjeson wrote: > > After upgrading to the latest maven artefacts (11-ea+23) from the > previous (11-ea+19), I get the following error when I try to run the > javafx11sample hello3d from gradle: > > > >> Task :run > > RenderJob.run: internal exception > > java.lang.ArrayIndexOutOfBoundsException: 0 > > at java.base/java.util.Arrays$ArrayList.get(Arrays.java:4351) > > at > java.base/java.util.Collections$UnmodifiableList.get(Collections.java:1306) > > at > javafx.graphics/com.sun.glass.ui.Screen.getMainScreen(Screen.java:61) > > at > javafx.graphics/com.sun.prism.sw.SWPipeline.getDefaultResourceFactory(SWPipeline.java:82) > > at > javafx.graphics/com.sun.prism.GraphicsPipeline.getDefaultResourceFactory(GraphicsPipeline.java:120) > > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.lambda$createResourceFactory$2(QuantumRenderer.java:161) > > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > > at > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > > at > javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) > > at java.base/java.lang.Thread.run(Thread.java:831) > > > > > > All context can be found at > https://github.com/johanvos/javafx11samples/pull/1 < > https://github.com/johanvos/javafx11samples/pull/1> . > > > > The program runs fine when launched via maven or directly from the > command line, so there must be some peculiarity concerning how gradle > launches a program, but I can't figure out what. > > > > Note that I can run from gradle when I use the 11-ea+19 snapshots, so > something must have changed in 11-ea+23 which causes this error. > > > > I'd really appreciate any help or insights with this. I get the same > error when upgrading my real application, not just these samples, to > 11-ea+23. > > > > This is on a Mac, BTW. > > > > From lenborje at gmail.com Thu Aug 23 13:36:20 2018 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Thu, 23 Aug 2018 15:36:20 +0200 Subject: ArrayIndexOutOfBoundsException with openjfx 11-ea+23, run from gradle In-Reply-To: References: <190E496A-30DD-42AE-B287-79C457129BB0@gmail.com> <2095916b-d524-e300-03a8-15d3376c0991@oracle.com> Message-ID: <63842D24-3C2A-42E9-A172-4C032172E9B6@gmail.com> I stopped my gradle demons (I had one for each JDK I'm testing) and after restart, everything works with either Java 10 or 11, and both openjfx 11-ea+19 and 11-ea+23 works now. My "real" application I'm porting to java11+openjfx also runs OK. (Oh well, just another gradle oddity then.) So, now you can update your samples to 11-ea+23 with confidence! Thanks for the help. Best regards, /Lennart > 23 aug. 2018 kl. 15:09 skrev Johan Vos : > > The fact that you fallback to SW indicate ES2 failed to initialize indeed. > I checked and merged your PR, and it runs locally fine for me on mac. > > As Kevin said, can you add javafx.verbose to true, as well as -Dprism.verbose=true ? > > Thanks for testing, these quirks are the ones we have to fix now :) > > - Johan > > Op do 23 aug. 2018 om 14:43 schreef Kevin Rushforth >: > > > at javafx.graphics/com.sun.prism.sw.SWPipeline.getDefaultResourceFactory(SWPipeline.java:82) > > This suggests that there may be some problems loading the native libs. > Can you try running with '-Djavafx.verbose=true' ? Johan might have > other suggestions. > > -- Kevin > > > On 8/23/2018 2:27 AM, Lennart B?rjeson wrote: > > After upgrading to the latest maven artefacts (11-ea+23) from the previous (11-ea+19), I get the following error when I try to run the javafx11sample hello3d from gradle: > > > >> Task :run > > RenderJob.run: internal exception > > java.lang.ArrayIndexOutOfBoundsException: 0 > > at java.base/java.util.Arrays$ArrayList.get(Arrays.java:4351) > > at java.base/java.util.Collections$UnmodifiableList.get(Collections.java:1306) > > at javafx.graphics/com.sun.glass.ui.Screen.getMainScreen(Screen.java:61) > > at javafx.graphics/com.sun.prism.sw.SWPipeline.getDefaultResourceFactory(SWPipeline.java:82) > > at javafx.graphics/com.sun.prism.GraphicsPipeline.getDefaultResourceFactory(GraphicsPipeline.java:120) > > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.lambda$createResourceFactory$2(QuantumRenderer.java:161) > > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > > at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > > at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) > > at java.base/java.lang.Thread.run(Thread.java:831) > > > > > > All context can be found at https://github.com/johanvos/javafx11samples/pull/1 > . > > > > The program runs fine when launched via maven or directly from the command line, so there must be some peculiarity concerning how gradle launches a program, but I can't figure out what. > > > > Note that I can run from gradle when I use the 11-ea+19 snapshots, so something must have changed in 11-ea+23 which causes this error. > > > > I'd really appreciate any help or insights with this. I get the same error when upgrading my real application, not just these samples, to 11-ea+23. > > > > This is on a Mac, BTW. > > > From mnachev.nscenter.eu at gmail.com Thu Aug 23 14:34:30 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Thu, 23 Aug 2018 17:34:30 +0300 Subject: Calculate preferred size and set as minimum Message-ID: Hi, Is there any standard way to calculate the preferred size for Scene, Node/Pane and Stage/Window? I want once a form/pane is visualized, it cannot be minimized to a certain size. Since I did not find such a built-in opportunity, at the moment I am doing the following: Scene scene = new Scene(gridPane); primaryStage.setScene(scene); primaryStage.sizeToScene(); primaryStage.show(); primaryStage.setMinWidth(primaryStage.getWidth() + 1); primaryStage.setMinHeight(primaryStage.getHeight() + 1); primaryStage.setWidth(640); primaryStage.setHeight(480); primaryStage.show(); The first call to primaryStage.show() (in orange) I do to calculate the minimum panel size (Scene/GridPane), then set that size as minimum on primaryStage, and finally set the size I want and visualize the panel again. The unpleasant side effect is, that the panel is no longer at the center of the screen. Any ideas? Regards, Miro. From kevin.rushforth at oracle.com Thu Aug 23 15:21:47 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 23 Aug 2018 08:21:47 -0700 Subject: OpenJFX 11 is in Rampdown Phase Two (RDP2) In-Reply-To: <7d757b86-d73f-a101-6080-eb74fc1494b0@oracle.com> References: <7d757b86-d73f-a101-6080-eb74fc1494b0@oracle.com> Message-ID: We are nearing the end of RDP2 for OpenJFX 11. As a reminder, the deadline for getting fixes in prior to the GA Candidate (Release Candidate) build is this coming Monday, August 27 at 11:59 pm Pacific. After that point, only stopper issues will be considered for inclusion in 11. -- Kevin On 8/7/2018 3:31 PM, Kevin Rushforth wrote: > To: OpenJFX Developers > > As a reminder, OpenJFX 11 is now in Rampdown Phase Two RDP2. [1] > > During RDP2, all bug fixes, except for docs and test fixes, and all > enhancements will need explicit approval to go in. Note that these > restrictions apply to the soon-to-be-created openjfx/11-dev/rt repo [2]. > > Starting now, the jfx-dev/rt mainline -- and by extension, the develop > branch of the GitHub sandbox -- is open for openjfx12 fixes. > > We will use the same rules for RDP2 that the JDK uses [3], 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-fix-request", > "openjfx11-fix-yes", "openjfx11-fix-no" and "openjfx11-fix-nmi", > "openjfx11-enhancement-request", "openjfx11-enhancement-yes", > "openjfx11-enhancement-no" and "openjfx11-enhancement-nmi" as > corresponding labels. > > 3. Some important P3 bugs might be considered during RDP2, as long as > those bugs have otherwise met the usual code review criteria. Having > said that, most P3 bugs should be moved to openjfx12 at this point. I > do not expect many P3 bugs to be approved. > > If a fix is approved to push to 11-dev (with the appropriate approval > label added by a lead), then you need not also push it to jfx-dev -- > we will auto-sync from 11-dev --> jfx-dev for the duration of the > openjfx11 release. > > Now that we are in RDP2, the goal should be to stabilize what is > there, with priority on fixing bugs that are new in openjfx11. We need > to be extremely careful 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-August/022233.html > > [2] http://hg.openjdk.java.net/openjfx/11-dev/rt? (not yet created as > of this writing) > > [3] http://openjdk.java.net/jeps/3 > From kevin.rushforth at oracle.com Thu Aug 23 15:40:15 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 23 Aug 2018 08:40:15 -0700 Subject: ArrayIndexOutOfBoundsException with openjfx 11-ea+23, run from gradle In-Reply-To: <63842D24-3C2A-42E9-A172-4C032172E9B6@gmail.com> References: <190E496A-30DD-42AE-B287-79C457129BB0@gmail.com> <2095916b-d524-e300-03a8-15d3376c0991@oracle.com> <63842D24-3C2A-42E9-A172-4C032172E9B6@gmail.com> Message-ID: <6c28a5c2-2f92-c95b-f77b-40a62d4b2535@oracle.com> Maybe you hit Gradle #3468 [1], which I discovered as reported in JDK-8193288 [2]? -- Kevin [1]? https://github.com/gradle/gradle/issues/3468 [2] https://bugs.openjdk.java.net/browse/JDK-8193288 On 8/23/2018 6:36 AM, Lennart B?rjeson wrote: > I stopped my gradle demons (I had one for each JDK I'm testing) and > after restart, everything works with either Java 10 or 11, and both > openjfx 11-ea+19 and 11-ea+23 works now. > > My "real" application I'm porting to java11+openjfx also runs OK. > > (Oh well, just another gradle oddity then.) > > So, now you can update your samples to 11-ea+23 with confidence! > > Thanks for the help. > > > Best regards, > > /Lennart > >> 23 aug. 2018 kl. 15:09 skrev Johan Vos > >: >> >> The fact that you fallback to SW indicate ES2 failed to initialize >> indeed. >> I checked and merged your PR, and it runs locally fine for me on mac. >> >> As Kevin said, can you add javafx.verbose to true, as well as >> -Dprism.verbose=true ? >> >> Thanks for testing, these quirks are the ones we have to fix now :) >> >> - Johan >> >> Op do 23 aug. 2018 om 14:43 schreef Kevin Rushforth >> >: >> >> >> >? ? ? ? ? at >> javafx.graphics/com.sun.prism.sw.SWPipeline.getDefaultResourceFactory(SWPipeline.java:82) >> >> This suggests that there may be some problems loading the native >> libs. >> Can you try running with '-Djavafx.verbose=true' ? Johan might have >> other suggestions. >> >> -- Kevin >> >> >> On 8/23/2018 2:27 AM, Lennart B?rjeson wrote: >> > After upgrading to the latest maven artefacts (11-ea+23) from >> the previous (11-ea+19), I get the following error when I try to >> run the javafx11sample hello3d from gradle: >> > >> >> Task :run >> > RenderJob.run: internal exception >> > java.lang.ArrayIndexOutOfBoundsException: 0 >> >? ? ? ? ? at >> java.base/java.util.Arrays$ArrayList.get(Arrays.java:4351) >> >? ? ? ? ? at >> java.base/java.util.Collections$UnmodifiableList.get(Collections.java:1306) >> >? ? ? ? ? at >> javafx.graphics/com.sun.glass.ui.Screen.getMainScreen(Screen.java:61) >> >? ? ? ? ? at >> javafx.graphics/com.sun.prism.sw.SWPipeline.getDefaultResourceFactory(SWPipeline.java:82) >> >? ? ? ? ? at >> javafx.graphics/com.sun.prism.GraphicsPipeline.getDefaultResourceFactory(GraphicsPipeline.java:120) >> >? ? ? ? ? at >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.lambda$createResourceFactory$2(QuantumRenderer.java:161) >> >? ? ? ? ? at >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> >? ? ? ? ? at >> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> >? ? ? ? ? at >> javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> >? ? ? ? ? at >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> >? ? ? ? ? at >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> >? ? ? ? ? at >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >> >? ? ? ? ? at java.base/java.lang.Thread.run(Thread.java:831) >> > >> > >> > All context can be found at >> https://github.com/johanvos/javafx11samples/pull/1 >> . >> > >> > The program runs fine when launched via maven or directly from >> the command line, so there must be some peculiarity concerning >> how gradle launches a program, but I can't figure out what. >> > >> > Note that I can run from gradle when I use the 11-ea+19 >> snapshots, so something must have changed in 11-ea+23 which >> causes this error. >> > >> > I'd really appreciate any help or insights with this. I get the >> same error when upgrading my real application, not just these >> samples, to 11-ea+23. >> > >> > This is on a Mac, BTW. >> > >> > From mnachev.nscenter.eu at gmail.com Thu Aug 23 17:16:30 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Thu, 23 Aug 2018 20:16:30 +0300 Subject: Calculate preferred size and set as minimum In-Reply-To: References: Message-ID: For Button this works. For GridPane doesn't works: gridPane.applyCss(); gridPane.layout(); double width = gridPane.getWidth(); double height = gridPane.getHeight(); System.out.println("width=" + width + ", height=" + height); --- exec-maven-plugin:1.5.0:exec (default-cli) --- width=0.0, height=0.0 On Thu, Aug 23, 2018 at 6:56 PM Shakir Gusaroff wrote: > . In javafx 8 you can find the width and height of the node before the > Stage has been shown. Use applyCss() and layout(). > > > > > > > @Override > > public void start(Stage stage) throws Exception { > > > > Group root = new Group(); > > Scene scene = new Scene(root); > > > > Button button = new Button("Hello World"); > > root.getChildren().add(button); > > > > root.applyCss(); > > root.layout(); > > > > double width = button.getWidth(); > > double height = button.getHeight(); > > > > System.out.println(width + ", " + height); > > > > stage.setScene(scene); > > stage.show(); > > } > > > On Thu, Aug 23, 2018 at 10:35 AM Miroslav Nachev < > mnachev.nscenter.eu at gmail.com> wrote: > >> Hi, >> >> Is there any standard way to calculate the preferred size for Scene, >> Node/Pane and Stage/Window? >> I want once a form/pane is visualized, it cannot be minimized to a certain >> size. Since I did not find such a built-in opportunity, at the moment I am >> doing the following: >> >> Scene scene = new Scene(gridPane); >> primaryStage.setScene(scene); >> primaryStage.sizeToScene(); >> >> primaryStage.show(); >> primaryStage.setMinWidth(primaryStage.getWidth() + 1); >> primaryStage.setMinHeight(primaryStage.getHeight() + 1); >> primaryStage.setWidth(640); >> primaryStage.setHeight(480); >> primaryStage.show(); >> >> The first call to primaryStage.show() (in orange) I do to calculate the >> minimum panel size (Scene/GridPane), then set that size as minimum on >> primaryStage, and finally set the size I want and visualize the panel >> again. >> >> The unpleasant side effect is, that the panel is no longer at the center >> of >> the screen. >> >> Any ideas? >> >> >> Regards, >> Miro. >> > From mnachev.nscenter.eu at gmail.com Thu Aug 23 17:34:08 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Thu, 23 Aug 2018 20:34:08 +0300 Subject: Calculate preferred size and set as minimum In-Reply-To: References: Message-ID: The GridPane is not empty: gridPane.add(sceneTitleHBox, 0, 0, 2, 1); Label usernameLabel = new Label("Username:"); gridPane.add(usernameLabel, 0, 1); TextField usernameText = new TextField(); gridPane.add(usernameText, 1, 1); Label passwordLabel = new Label("Password:"); gridPane.add(passwordLabel, 0, 2); PasswordField passwordField = new PasswordField(); gridPane.add(passwordField, 1, 2); gridPane.add(buttonLoginHBox, 0, 4, 2, 1); gridPane.add(buttonLoginActionMessage, 1, 6); On Thu, Aug 23, 2018 at 8:22 PM David Grieve wrote: > If your GridPane is empty, it won't have any height or width unless you > set min. > > > On 8/23/18 1:16 PM, Miroslav Nachev wrote: > > For Button this works. For GridPane doesn't works: > > gridPane.applyCss(); > > gridPane.layout(); > > double width = gridPane.getWidth(); > > double height = gridPane.getHeight(); > > System.out.println("width=" + width + ", height=" + height); > > --- exec-maven-plugin:1.5.0:exec (default-cli) --- > > width=0.0, height=0.0 > > > > > > On Thu, Aug 23, 2018 at 6:56 PM Shakir Gusaroff < > shakir.gusaroff at gmail.com> > > wrote: > > > >> . In javafx 8 you can find the width and height of the node before the > >> Stage has been shown. Use applyCss() and layout(). > >> > >> > >> > >> > >> > >> > >> @Override > >> > >> public void start(Stage stage) throws Exception { > >> > >> > >> > >> Group root = new Group(); > >> > >> Scene scene = new Scene(root); > >> > >> > >> > >> Button button = new Button("Hello World"); > >> > >> root.getChildren().add(button); > >> > >> > >> > >> root.applyCss(); > >> > >> root.layout(); > >> > >> > >> > >> double width = button.getWidth(); > >> > >> double height = button.getHeight(); > >> > >> > >> > >> System.out.println(width + ", " + height); > >> > >> > >> > >> stage.setScene(scene); > >> > >> stage.show(); > >> > >> } > >> > >> > >> On Thu, Aug 23, 2018 at 10:35 AM Miroslav Nachev < > >> mnachev.nscenter.eu at gmail.com> wrote: > >> > >>> Hi, > >>> > >>> Is there any standard way to calculate the preferred size for Scene, > >>> Node/Pane and Stage/Window? > >>> I want once a form/pane is visualized, it cannot be minimized to a > certain > >>> size. Since I did not find such a built-in opportunity, at the moment > I am > >>> doing the following: > >>> > >>> Scene scene = new Scene(gridPane); > >>> primaryStage.setScene(scene); > >>> primaryStage.sizeToScene(); > >>> > >>> primaryStage.show(); > >>> primaryStage.setMinWidth(primaryStage.getWidth() + 1); > >>> primaryStage.setMinHeight(primaryStage.getHeight() + 1); > >>> primaryStage.setWidth(640); > >>> primaryStage.setHeight(480); > >>> primaryStage.show(); > >>> > >>> The first call to primaryStage.show() (in orange) I do to calculate the > >>> minimum panel size (Scene/GridPane), then set that size as minimum on > >>> primaryStage, and finally set the size I want and visualize the panel > >>> again. > >>> > >>> The unpleasant side effect is, that the panel is no longer at the > center > >>> of > >>> the screen. > >>> > >>> Any ideas? > >>> > >>> > >>> Regards, > >>> Miro. > >>> > > From kevin.rushforth at oracle.com Thu Aug 23 17:47:04 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 23 Aug 2018 10:47:04 -0700 Subject: Calculate preferred size and set as minimum In-Reply-To: References: Message-ID: In general, this is fragile and should not be relied upon (not to mention it is internal API that is not available in the latest release and is subject to change in 8u). One possibility using public API is to use Scene::snapshot, but even that isn't guaranteed to work in all cases if the Scene has never been shown. -- Kevin On 8/23/2018 10:34 AM, Miroslav Nachev wrote: > The GridPane is not empty: > gridPane.add(sceneTitleHBox, 0, 0, 2, 1); > Label usernameLabel = new Label("Username:"); > gridPane.add(usernameLabel, 0, 1); > > TextField usernameText = new TextField(); > gridPane.add(usernameText, 1, 1); > > Label passwordLabel = new Label("Password:"); > gridPane.add(passwordLabel, 0, 2); > > PasswordField passwordField = new PasswordField(); > gridPane.add(passwordField, 1, 2); > gridPane.add(buttonLoginHBox, 0, 4, 2, 1); > gridPane.add(buttonLoginActionMessage, 1, 6); > > > > On Thu, Aug 23, 2018 at 8:22 PM David Grieve > wrote: > >> If your GridPane is empty, it won't have any height or width unless you >> set min. >> >> >> On 8/23/18 1:16 PM, Miroslav Nachev wrote: >>> For Button this works. For GridPane doesn't works: >>> gridPane.applyCss(); >>> gridPane.layout(); >>> double width = gridPane.getWidth(); >>> double height = gridPane.getHeight(); >>> System.out.println("width=" + width + ", height=" + height); >>> --- exec-maven-plugin:1.5.0:exec (default-cli) --- >>> width=0.0, height=0.0 >>> >>> >>> On Thu, Aug 23, 2018 at 6:56 PM Shakir Gusaroff < >> shakir.gusaroff at gmail.com> >>> wrote: >>> >>>> . In javafx 8 you can find the width and height of the node before the >>>> Stage has been shown. Use applyCss() and layout(). >>>> >>>> >>>> >>>> >>>> >>>> >>>> @Override >>>> >>>> public void start(Stage stage) throws Exception { >>>> >>>> >>>> >>>> Group root = new Group(); >>>> >>>> Scene scene = new Scene(root); >>>> >>>> >>>> >>>> Button button = new Button("Hello World"); >>>> >>>> root.getChildren().add(button); >>>> >>>> >>>> >>>> root.applyCss(); >>>> >>>> root.layout(); >>>> >>>> >>>> >>>> double width = button.getWidth(); >>>> >>>> double height = button.getHeight(); >>>> >>>> >>>> >>>> System.out.println(width + ", " + height); >>>> >>>> >>>> >>>> stage.setScene(scene); >>>> >>>> stage.show(); >>>> >>>> } >>>> >>>> >>>> On Thu, Aug 23, 2018 at 10:35 AM Miroslav Nachev < >>>> mnachev.nscenter.eu at gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> Is there any standard way to calculate the preferred size for Scene, >>>>> Node/Pane and Stage/Window? >>>>> I want once a form/pane is visualized, it cannot be minimized to a >> certain >>>>> size. Since I did not find such a built-in opportunity, at the moment >> I am >>>>> doing the following: >>>>> >>>>> Scene scene = new Scene(gridPane); >>>>> primaryStage.setScene(scene); >>>>> primaryStage.sizeToScene(); >>>>> >>>>> primaryStage.show(); >>>>> primaryStage.setMinWidth(primaryStage.getWidth() + 1); >>>>> primaryStage.setMinHeight(primaryStage.getHeight() + 1); >>>>> primaryStage.setWidth(640); >>>>> primaryStage.setHeight(480); >>>>> primaryStage.show(); >>>>> >>>>> The first call to primaryStage.show() (in orange) I do to calculate the >>>>> minimum panel size (Scene/GridPane), then set that size as minimum on >>>>> primaryStage, and finally set the size I want and visualize the panel >>>>> again. >>>>> >>>>> The unpleasant side effect is, that the panel is no longer at the >> center >>>>> of >>>>> the screen. >>>>> >>>>> Any ideas? >>>>> >>>>> >>>>> Regards, >>>>> Miro. >>>>> >> From nlisker at gmail.com Thu Aug 23 19:31:50 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 23 Aug 2018 22:31:50 +0300 Subject: JDK-8208761: Update constant collections to use the new immutable collections Message-ID: Hi All, Iv'e been working on updating OpenJFX to use the Java 9 immutable collections [1]. If you know of any additional location which can be updated, please add a comment or reply here. New code should be mindful of these collections' existence (contributors and reviewers alike) so that we don't need to continuously iterate over the platform to update it. [1] https://bugs.openjdk.java.net/browse/JDK-8208761 Thanks, Nir From mnachev.nscenter.eu at gmail.com Fri Aug 24 06:34:46 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Fri, 24 Aug 2018 09:34:46 +0300 Subject: Calculate preferred size and set as minimum In-Reply-To: References: Message-ID: Yes, it works. Thank you Kevin. The used JDK is: java version "10.0.2" 2018-07-17 Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13) Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) Here is the code: Scene scene = new Scene(gridPane); scene.snapshot(null); double width = gridPane.getWidth(); double height = gridPane.getHeight(); System.out.println("width=" + width + ", height=" + height); if(width > 0 && height > 0) { primaryStage.setMinWidth(width + 1); primaryStage.setMinHeight(height + 1); } primaryStage.setScene(scene); primaryStage.setWidth(640); primaryStage.setHeight(480); primaryStage.show(); On Thu, Aug 23, 2018 at 8:47 PM Kevin Rushforth wrote: > In general, this is fragile and should not be relied upon (not to > mention it is internal API that is not available in the latest release > and is subject to change in 8u). > > One possibility using public API is to use Scene::snapshot, but even > that isn't guaranteed to work in all cases if the Scene has never been > shown. > > -- Kevin > > > On 8/23/2018 10:34 AM, Miroslav Nachev wrote: > > The GridPane is not empty: > > gridPane.add(sceneTitleHBox, 0, 0, 2, 1); > > Label usernameLabel = new Label("Username:"); > > gridPane.add(usernameLabel, 0, 1); > > > > TextField usernameText = new TextField(); > > gridPane.add(usernameText, 1, 1); > > > > Label passwordLabel = new Label("Password:"); > > gridPane.add(passwordLabel, 0, 2); > > > > PasswordField passwordField = new PasswordField(); > > gridPane.add(passwordField, 1, 2); > > gridPane.add(buttonLoginHBox, 0, 4, 2, 1); > > gridPane.add(buttonLoginActionMessage, 1, 6); > > > > > > > > On Thu, Aug 23, 2018 at 8:22 PM David Grieve > > wrote: > > > >> If your GridPane is empty, it won't have any height or width unless you > >> set min. > >> > >> > >> On 8/23/18 1:16 PM, Miroslav Nachev wrote: > >>> For Button this works. For GridPane doesn't works: > >>> gridPane.applyCss(); > >>> gridPane.layout(); > >>> double width = gridPane.getWidth(); > >>> double height = gridPane.getHeight(); > >>> System.out.println("width=" + width + ", height=" + height); > >>> --- exec-maven-plugin:1.5.0:exec (default-cli) --- > >>> width=0.0, height=0.0 > >>> > >>> > >>> On Thu, Aug 23, 2018 at 6:56 PM Shakir Gusaroff < > >> shakir.gusaroff at gmail.com> > >>> wrote: > >>> > >>>> . In javafx 8 you can find the width and height of the node before the > >>>> Stage has been shown. Use applyCss() and layout(). > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> @Override > >>>> > >>>> public void start(Stage stage) throws Exception { > >>>> > >>>> > >>>> > >>>> Group root = new Group(); > >>>> > >>>> Scene scene = new Scene(root); > >>>> > >>>> > >>>> > >>>> Button button = new Button("Hello World"); > >>>> > >>>> root.getChildren().add(button); > >>>> > >>>> > >>>> > >>>> root.applyCss(); > >>>> > >>>> root.layout(); > >>>> > >>>> > >>>> > >>>> double width = button.getWidth(); > >>>> > >>>> double height = button.getHeight(); > >>>> > >>>> > >>>> > >>>> System.out.println(width + ", " + height); > >>>> > >>>> > >>>> > >>>> stage.setScene(scene); > >>>> > >>>> stage.show(); > >>>> > >>>> } > >>>> > >>>> > >>>> On Thu, Aug 23, 2018 at 10:35 AM Miroslav Nachev < > >>>> mnachev.nscenter.eu at gmail.com> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> Is there any standard way to calculate the preferred size for Scene, > >>>>> Node/Pane and Stage/Window? > >>>>> I want once a form/pane is visualized, it cannot be minimized to a > >> certain > >>>>> size. Since I did not find such a built-in opportunity, at the moment > >> I am > >>>>> doing the following: > >>>>> > >>>>> Scene scene = new Scene(gridPane); > >>>>> primaryStage.setScene(scene); > >>>>> primaryStage.sizeToScene(); > >>>>> > >>>>> primaryStage.show(); > >>>>> primaryStage.setMinWidth(primaryStage.getWidth() + 1); > >>>>> primaryStage.setMinHeight(primaryStage.getHeight() + 1); > >>>>> primaryStage.setWidth(640); > >>>>> primaryStage.setHeight(480); > >>>>> primaryStage.show(); > >>>>> > >>>>> The first call to primaryStage.show() (in orange) I do to calculate > the > >>>>> minimum panel size (Scene/GridPane), then set that size as minimum on > >>>>> primaryStage, and finally set the size I want and visualize the panel > >>>>> again. > >>>>> > >>>>> The unpleasant side effect is, that the panel is no longer at the > >> center > >>>>> of > >>>>> the screen. > >>>>> > >>>>> Any ideas? > >>>>> > >>>>> > >>>>> Regards, > >>>>> Miro. > >>>>> > >> > > From mnachev.nscenter.eu at gmail.com Fri Aug 24 06:57:28 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Fri, 24 Aug 2018 09:57:28 +0300 Subject: How to access com.sun.webkit.network.CookieManager at JDK 10? Message-ID: Hi, I have apps that work well on JDK8, but on JDK10 I do not have access to some classes, for example, com.sun.webkit.network.CookieManager. This class is the only one, that is up to date (RFC 6265) and is part of Java. The java.net.CookieManager class is obsolete: RFC 2965. The Cookie solution in Apache HttpComponents is very complicated, difficult to use, and is mostly not compatible with JDK and JavaFX. In fact, I use JavaFX CookieManager in the following 3 scenarios: - When using WebEngine (JavaFX 8). - JavaFX Desktop App to store frequently used words in text and other fields (TextField, etc.). - To store session parameters in JavaFX Desktop Clients that uses REST WS or Web Sockets to connect to the Web Server (App Server). Is there any way to enable access to com.sun.webkit.network.CookieManager at JDK 10? Regards, Miro. From johan.vos at gluonhq.com Fri Aug 24 07:11:55 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 24 Aug 2018 09:11:55 +0200 Subject: Travis failures in jfx-11 branch Message-ID: I noticed Travis fails a number of times on branches. For example: https://travis-ci.org/javafxports/openjdk-jfx/builds/419599353 This is the exact commit that worked fine in the development branch. >From the logs, it seems that the failures occur when all the packages have to be installed: Setting up libudev1:amd64 (204-5ubuntu20.28) ... Setting up udev (204-5ubuntu20.28) ... runlevel:/var/run/utmp: No such file or directory invoke-rc.d: initscript udev, action "restart" failed. On successful builds, this apt-get install command is not executed. - Johan From lenborje at gmail.com Fri Aug 24 08:16:02 2018 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Fri, 24 Aug 2018 10:16:02 +0200 Subject: ArrayIndexOutOfBoundsException with openjfx 11-ea+23, run from gradle In-Reply-To: <6c28a5c2-2f92-c95b-f77b-40a62d4b2535@oracle.com> References: <190E496A-30DD-42AE-B287-79C457129BB0@gmail.com> <2095916b-d524-e300-03a8-15d3376c0991@oracle.com> <63842D24-3C2A-42E9-A172-4C032172E9B6@gmail.com> <6c28a5c2-2f92-c95b-f77b-40a62d4b2535@oracle.com> Message-ID: Most probable! Your ref [1] states fix for that is Gradle #6170, which was resolved and merged after 4.9 was release. I'll test again when 4.10 is out. /Lennart > 23 aug. 2018 kl. 17:40 skrev Kevin Rushforth : > > Maybe you hit Gradle #3468 [1], which I discovered as reported in JDK-8193288 [2]? > > -- Kevin > > [1] https://github.com/gradle/gradle/issues/3468 > [2] https://bugs.openjdk.java.net/browse/JDK-8193288 > > > On 8/23/2018 6:36 AM, Lennart B?rjeson wrote: >> I stopped my gradle demons (I had one for each JDK I'm testing) and after restart, everything works with either Java 10 or 11, and both openjfx 11-ea+19 and 11-ea+23 works now. >> >> My "real" application I'm porting to java11+openjfx also runs OK. >> >> (Oh well, just another gradle oddity then.) >> >> So, now you can update your samples to 11-ea+23 with confidence! >> >> Thanks for the help. >> >> >> Best regards, >> >> /Lennart >> >>> 23 aug. 2018 kl. 15:09 skrev Johan Vos >: >>> >>> The fact that you fallback to SW indicate ES2 failed to initialize indeed. >>> I checked and merged your PR, and it runs locally fine for me on mac. >>> >>> As Kevin said, can you add javafx.verbose to true, as well as -Dprism.verbose=true ? >>> >>> Thanks for testing, these quirks are the ones we have to fix now :) >>> >>> - Johan >>> >>> Op do 23 aug. 2018 om 14:43 schreef Kevin Rushforth >: >>> >>> > at javafx.graphics/com.sun.prism.sw.SWPipeline.getDefaultResourceFactory(SWPipeline.java:82) >>> >>> This suggests that there may be some problems loading the native libs. >>> Can you try running with '-Djavafx.verbose=true' ? Johan might have >>> other suggestions. >>> >>> -- Kevin >>> >>> >>> On 8/23/2018 2:27 AM, Lennart B?rjeson wrote: >>> > After upgrading to the latest maven artefacts (11-ea+23) from the previous (11-ea+19), I get the following error when I try to run the javafx11sample hello3d from gradle: >>> > >>> >> Task :run >>> > RenderJob.run: internal exception >>> > java.lang.ArrayIndexOutOfBoundsException: 0 >>> > at java.base/java.util.Arrays$ArrayList.get(Arrays.java:4351) >>> > at java.base/java.util.Collections$UnmodifiableList.get(Collections.java:1306) >>> > at javafx.graphics/com.sun.glass.ui.Screen.getMainScreen(Screen.java:61) >>> > at javafx.graphics/com.sun.prism.sw.SWPipeline.getDefaultResourceFactory(SWPipeline.java:82) >>> > at javafx.graphics/com.sun.prism.GraphicsPipeline.getDefaultResourceFactory(GraphicsPipeline.java:120) >>> > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.lambda$createResourceFactory$2(QuantumRenderer.java:161) >>> > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>> > at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>> > at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>> > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>> > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>> > at java.base/java.lang.Thread.run(Thread.java:831) >>> > >>> > >>> > All context can be found at https://github.com/johanvos/javafx11samples/pull/1 > . >>> > >>> > The program runs fine when launched via maven or directly from the command line, so there must be some peculiarity concerning how gradle launches a program, but I can't figure out what. >>> > >>> > Note that I can run from gradle when I use the 11-ea+19 snapshots, so something must have changed in 11-ea+23 which causes this error. >>> > >>> > I'd really appreciate any help or insights with this. I get the same error when upgrading my real application, not just these samples, to 11-ea+23. >>> > >>> > This is on a Mac, BTW. >>> > >>> >> > From arunprasad.rajkumar at oracle.com Fri Aug 24 09:04:36 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Fri, 24 Aug 2018 14:34:36 +0530 Subject: How to access com.sun.webkit.network.CookieManager at JDK 10? In-Reply-To: References: Message-ID: <1326B9D9-F0F7-40DA-8B15-FEAAB51D275E@oracle.com> Hello Miro, CookieManager is a module private class, which is not exposed to outside. I could think of two options, 1. com.sun.webkit.network.CookieManager is a type of java.net.CookieHandler, that means after instantiating WebEngine, you can call CookieHandler.getDefault() to get the instance of CookieManager. new WebEngine(); CookieHandler cookieHandler = CookieHandler.getDefault(); // This will be an instance of com.sun.webkit.network.CookieManager 2. Export the module private implementation using "--add-exports=javafx.web/com.sun.webkit.network=ALL-UNNAMED? Thanks, Arun > On 24-Aug-2018, at 12:27 PM, Miroslav Nachev wrote: > > Hi, > > I have apps that work well on JDK8, but on JDK10 I do not have access to > some classes, for example, com.sun.webkit.network.CookieManager. This class > is the only one, that is up to date (RFC 6265) and is part of Java. The > java.net.CookieManager class is obsolete: RFC 2965. The Cookie solution in > Apache HttpComponents is very complicated, difficult to use, and is mostly > not compatible with JDK and JavaFX. > In fact, I use JavaFX CookieManager in the following 3 scenarios: > > - When using WebEngine (JavaFX 8). > - JavaFX Desktop App to store frequently used words in text and other > fields (TextField, etc.). > - To store session parameters in JavaFX Desktop Clients that uses REST > WS or Web Sockets to connect to the Web Server (App Server). > > Is there any way to enable access to com.sun.webkit.network.CookieManager > at JDK 10? > > > Regards, > Miro. From mnachev.nscenter.eu at gmail.com Fri Aug 24 09:37:52 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Fri, 24 Aug 2018 12:37:52 +0300 Subject: How to access com.sun.webkit.network.CookieManager at JDK 10? In-Reply-To: <1326B9D9-F0F7-40DA-8B15-FEAAB51D275E@oracle.com> References: <1326B9D9-F0F7-40DA-8B15-FEAAB51D275E@oracle.com> Message-ID: Hi Arun, Thank you. I'm already using the first option, but then I need to access other methods and classes that are not available. Can I use the 2nd option with declaration in the source code, or the only possible option is to pass as parameter when starting the application? Miro. On Fri, Aug 24, 2018 at 12:04 PM Arunprasad Rajkumar < arunprasad.rajkumar at oracle.com> wrote: > Hello Miro, > > CookieManager is a module private class, which is not exposed to outside. > > I could think of two options, > > 1. com.sun.webkit.network.CookieManager is a type of > java.net.CookieHandler, that means after instantiating WebEngine, you can > call CookieHandler.getDefault() to get the instance of CookieManager. > new WebEngine(); > CookieHandler cookieHandler = CookieHandler.getDefault(); // This > will be an instance of com.sun.webkit.network.CookieManager > > 2. Export the module private implementation using > "--add-exports=javafx.web/com.sun.webkit.network=ALL-UNNAMED? > > Thanks, > Arun > > > On 24-Aug-2018, at 12:27 PM, Miroslav Nachev < > mnachev.nscenter.eu at gmail.com> wrote: > > > > Hi, > > > > I have apps that work well on JDK8, but on JDK10 I do not have access to > > some classes, for example, com.sun.webkit.network.CookieManager. This > class > > is the only one, that is up to date (RFC 6265) and is part of Java. The > > java.net.CookieManager class is obsolete: RFC 2965. The Cookie solution > in > > Apache HttpComponents is very complicated, difficult to use, and is > mostly > > not compatible with JDK and JavaFX. > > In fact, I use JavaFX CookieManager in the following 3 scenarios: > > > > - When using WebEngine (JavaFX 8). > > - JavaFX Desktop App to store frequently used words in text and other > > fields (TextField, etc.). > > - To store session parameters in JavaFX Desktop Clients that uses REST > > WS or Web Sockets to connect to the Web Server (App Server). > > > > Is there any way to enable access to com.sun.webkit.network.CookieManager > > at JDK 10? > > > > > > Regards, > > Miro. > > From kevin.rushforth at oracle.com Fri Aug 24 11:32:43 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 24 Aug 2018 04:32:43 -0700 Subject: Travis failures in jfx-11 branch In-Reply-To: References: Message-ID: I think I've seen this failure in the develop branch as well. -- Kevin On 8/24/2018 12:11 AM, Johan Vos wrote: > I noticed Travis fails a number of times on branches. > For example: https://travis-ci.org/javafxports/openjdk-jfx/builds/419599353 > This is the exact commit that worked fine in the development branch. > > From the logs, it seems that the failures occur when all the packages have > to be installed: > > > Setting up libudev1:amd64 (204-5ubuntu20.28) ... > Setting up udev (204-5ubuntu20.28) ... > runlevel:/var/run/utmp: No such file or directory > invoke-rc.d: initscript udev, action "restart" failed. > > > On successful builds, this apt-get install command is not executed. > > - Johan From nlisker at gmail.com Fri Aug 24 13:02:29 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 24 Aug 2018 16:02:29 +0300 Subject: How to access com.sun.webkit.network.CookieManager at JDK 10? In-Reply-To: References: <1326B9D9-F0F7-40DA-8B15-FEAAB51D275E@oracle.com> Message-ID: Hi Miro, Can I use the 2nd option with declaration in the source code, or the only > possible option is to pass as parameter when starting the application? > If your app is not a module then you don't have a module-info.java in your source code to declare the dependency. What you can do is export a package during runtime with the addExports method [1]. [1] https://docs.oracle.com/javase/10/docs/api/java/lang/Module.html#addExports(java.lang.String,java.lang.Module) On Fri, Aug 24, 2018 at 12:38 PM Miroslav Nachev < mnachev.nscenter.eu at gmail.com> wrote: > Hi Arun, > > Thank you. I'm already using the first option, but then I need to access > other methods and classes that are not available. > Can I use the 2nd option with declaration in the source code, or the only > possible option is to pass as parameter when starting the application? > > > Miro. > > On Fri, Aug 24, 2018 at 12:04 PM Arunprasad Rajkumar < > arunprasad.rajkumar at oracle.com> wrote: > > > Hello Miro, > > > > CookieManager is a module private class, which is not exposed to outside. > > > > I could think of two options, > > > > 1. com.sun.webkit.network.CookieManager is a type of > > java.net.CookieHandler, that means after instantiating WebEngine, you can > > call CookieHandler.getDefault() to get the instance of CookieManager. > > new WebEngine(); > > CookieHandler cookieHandler = CookieHandler.getDefault(); // This > > will be an instance of com.sun.webkit.network.CookieManager > > > > 2. Export the module private implementation using > > "--add-exports=javafx.web/com.sun.webkit.network=ALL-UNNAMED? > > > > Thanks, > > Arun > > > > > On 24-Aug-2018, at 12:27 PM, Miroslav Nachev < > > mnachev.nscenter.eu at gmail.com> wrote: > > > > > > Hi, > > > > > > I have apps that work well on JDK8, but on JDK10 I do not have access > to > > > some classes, for example, com.sun.webkit.network.CookieManager. This > > class > > > is the only one, that is up to date (RFC 6265) and is part of Java. The > > > java.net.CookieManager class is obsolete: RFC 2965. The Cookie solution > > in > > > Apache HttpComponents is very complicated, difficult to use, and is > > mostly > > > not compatible with JDK and JavaFX. > > > In fact, I use JavaFX CookieManager in the following 3 scenarios: > > > > > > - When using WebEngine (JavaFX 8). > > > - JavaFX Desktop App to store frequently used words in text and other > > > fields (TextField, etc.). > > > - To store session parameters in JavaFX Desktop Clients that uses > REST > > > WS or Web Sockets to connect to the Web Server (App Server). > > > > > > Is there any way to enable access to > com.sun.webkit.network.CookieManager > > > at JDK 10? > > > > > > > > > Regards, > > > Miro. > > > > > From mnachev.nscenter.eu at gmail.com Fri Aug 24 13:43:07 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Fri, 24 Aug 2018 16:43:07 +0300 Subject: How to access com.sun.webkit.network.CookieManager at JDK 10? In-Reply-To: References: <1326B9D9-F0F7-40DA-8B15-FEAAB51D275E@oracle.com> Message-ID: Now I adopted the application to be module, adding this: module my.app.Test { requires controlsfx; requires javafx.base; requires javafx.controls; } What is the next step? On Fri, Aug 24, 2018 at 4:02 PM Nir Lisker wrote: > Hi Miro, > > Can I use the 2nd option with declaration in the source code, or the only >> possible option is to pass as parameter when starting the application? >> > > If your app is not a module then you don't have a module-info.java in your > source code to declare the dependency. What you can do is export a package > during runtime with the addExports method [1]. > > [1] > https://docs.oracle.com/javase/10/docs/api/java/lang/Module.html#addExports(java.lang.String,java.lang.Module) > > On Fri, Aug 24, 2018 at 12:38 PM Miroslav Nachev < > mnachev.nscenter.eu at gmail.com> wrote: > >> Hi Arun, >> >> Thank you. I'm already using the first option, but then I need to access >> other methods and classes that are not available. >> Can I use the 2nd option with declaration in the source code, or the only >> possible option is to pass as parameter when starting the application? >> >> >> Miro. >> >> On Fri, Aug 24, 2018 at 12:04 PM Arunprasad Rajkumar < >> arunprasad.rajkumar at oracle.com> wrote: >> >> > Hello Miro, >> > >> > CookieManager is a module private class, which is not exposed to >> outside. >> > >> > I could think of two options, >> > >> > 1. com.sun.webkit.network.CookieManager is a type of >> > java.net.CookieHandler, that means after instantiating WebEngine, you >> can >> > call CookieHandler.getDefault() to get the instance of CookieManager. >> > new WebEngine(); >> > CookieHandler cookieHandler = CookieHandler.getDefault(); // >> This >> > will be an instance of com.sun.webkit.network.CookieManager >> > >> > 2. Export the module private implementation using >> > "--add-exports=javafx.web/com.sun.webkit.network=ALL-UNNAMED? >> > >> > Thanks, >> > Arun >> > >> > > On 24-Aug-2018, at 12:27 PM, Miroslav Nachev < >> > mnachev.nscenter.eu at gmail.com> wrote: >> > > >> > > Hi, >> > > >> > > I have apps that work well on JDK8, but on JDK10 I do not have access >> to >> > > some classes, for example, com.sun.webkit.network.CookieManager. This >> > class >> > > is the only one, that is up to date (RFC 6265) and is part of Java. >> The >> > > java.net.CookieManager class is obsolete: RFC 2965. The Cookie >> solution >> > in >> > > Apache HttpComponents is very complicated, difficult to use, and is >> > mostly >> > > not compatible with JDK and JavaFX. >> > > In fact, I use JavaFX CookieManager in the following 3 scenarios: >> > > >> > > - When using WebEngine (JavaFX 8). >> > > - JavaFX Desktop App to store frequently used words in text and >> other >> > > fields (TextField, etc.). >> > > - To store session parameters in JavaFX Desktop Clients that uses >> REST >> > > WS or Web Sockets to connect to the Web Server (App Server). >> > > >> > > Is there any way to enable access to >> com.sun.webkit.network.CookieManager >> > > at JDK 10? >> > > >> > > >> > > Regards, >> > > Miro. >> > >> > >> > From nlisker at gmail.com Fri Aug 24 14:11:20 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 24 Aug 2018 17:11:20 +0300 Subject: How to access com.sun.webkit.network.CookieManager at JDK 10? In-Reply-To: References: <1326B9D9-F0F7-40DA-8B15-FEAAB51D275E@oracle.com> Message-ID: Sorry, my reply was not phrased well. Whether you declare a module-info.java or not, you still have to add-exports either via command line or during runtime. What I meant with not needing to declare a dependency in module-info.java is that you don't need a 'requires' (or add-reads) because the unnamed module reads everything be default. So, in your case you need a command line "--add-exports javafx.web/com.sun.webkit.network=my.app.Test" (or the equivalent runtime code) and "requires javafx.web" in the module-info.java. The latter is what's not needed if you don't declare a module. - Nir On Fri, Aug 24, 2018 at 4:43 PM Miroslav Nachev < mnachev.nscenter.eu at gmail.com> wrote: > Now I adopted the application to be module, adding this: > module my.app.Test { > requires controlsfx; > requires javafx.base; > requires javafx.controls; > } > > What is the next step? > > > On Fri, Aug 24, 2018 at 4:02 PM Nir Lisker wrote: > >> Hi Miro, >> >> Can I use the 2nd option with declaration in the source code, or the only >>> possible option is to pass as parameter when starting the application? >>> >> >> If your app is not a module then you don't have a module-info.java in >> your source code to declare the dependency. What you can do is export a >> package during runtime with the addExports method [1]. >> >> [1] >> https://docs.oracle.com/javase/10/docs/api/java/lang/Module.html#addExports(java.lang.String,java.lang.Module) >> >> On Fri, Aug 24, 2018 at 12:38 PM Miroslav Nachev < >> mnachev.nscenter.eu at gmail.com> wrote: >> >>> Hi Arun, >>> >>> Thank you. I'm already using the first option, but then I need to access >>> other methods and classes that are not available. >>> Can I use the 2nd option with declaration in the source code, or the only >>> possible option is to pass as parameter when starting the application? >>> >>> >>> Miro. >>> >>> On Fri, Aug 24, 2018 at 12:04 PM Arunprasad Rajkumar < >>> arunprasad.rajkumar at oracle.com> wrote: >>> >>> > Hello Miro, >>> > >>> > CookieManager is a module private class, which is not exposed to >>> outside. >>> > >>> > I could think of two options, >>> > >>> > 1. com.sun.webkit.network.CookieManager is a type of >>> > java.net.CookieHandler, that means after instantiating WebEngine, you >>> can >>> > call CookieHandler.getDefault() to get the instance of CookieManager. >>> > new WebEngine(); >>> > CookieHandler cookieHandler = CookieHandler.getDefault(); // >>> This >>> > will be an instance of com.sun.webkit.network.CookieManager >>> > >>> > 2. Export the module private implementation using >>> > "--add-exports=javafx.web/com.sun.webkit.network=ALL-UNNAMED? >>> > >>> > Thanks, >>> > Arun >>> > >>> > > On 24-Aug-2018, at 12:27 PM, Miroslav Nachev < >>> > mnachev.nscenter.eu at gmail.com> wrote: >>> > > >>> > > Hi, >>> > > >>> > > I have apps that work well on JDK8, but on JDK10 I do not have >>> access to >>> > > some classes, for example, com.sun.webkit.network.CookieManager. This >>> > class >>> > > is the only one, that is up to date (RFC 6265) and is part of Java. >>> The >>> > > java.net.CookieManager class is obsolete: RFC 2965. The Cookie >>> solution >>> > in >>> > > Apache HttpComponents is very complicated, difficult to use, and is >>> > mostly >>> > > not compatible with JDK and JavaFX. >>> > > In fact, I use JavaFX CookieManager in the following 3 scenarios: >>> > > >>> > > - When using WebEngine (JavaFX 8). >>> > > - JavaFX Desktop App to store frequently used words in text and >>> other >>> > > fields (TextField, etc.). >>> > > - To store session parameters in JavaFX Desktop Clients that uses >>> REST >>> > > WS or Web Sockets to connect to the Web Server (App Server). >>> > > >>> > > Is there any way to enable access to >>> com.sun.webkit.network.CookieManager >>> > > at JDK 10? >>> > > >>> > > >>> > > Regards, >>> > > Miro. >>> > >>> > >>> >> From kevin.rushforth at oracle.com Fri Aug 24 14:18:34 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 24 Aug 2018 07:18:34 -0700 Subject: How to access com.sun.webkit.network.CookieManager at JDK 10? In-Reply-To: References: <1326B9D9-F0F7-40DA-8B15-FEAAB51D275E@oracle.com> Message-ID: <99c38254-b096-0a9b-a0f4-e628f42794a1@oracle.com> You probably already know this, but using internal interfaces is fragile and can change or break at any time and without notice. -- Kevin On 8/24/2018 7:11 AM, Nir Lisker wrote: > Sorry, my reply was not phrased well. Whether you declare a > module-info.java or not, you still have to add-exports either via command > line or during runtime. What I meant with not needing to declare a > dependency in module-info.java is that you don't need a 'requires' (or > add-reads) because the unnamed module reads everything be default. > > So, in your case you need a command line "--add-exports > javafx.web/com.sun.webkit.network=my.app.Test" (or the equivalent runtime > code) and "requires javafx.web" in the module-info.java. The latter is > what's not needed if you don't declare a module. > > - Nir > > On Fri, Aug 24, 2018 at 4:43 PM Miroslav Nachev < > mnachev.nscenter.eu at gmail.com> wrote: > >> Now I adopted the application to be module, adding this: >> module my.app.Test { >> requires controlsfx; >> requires javafx.base; >> requires javafx.controls; >> } >> >> What is the next step? >> >> >> On Fri, Aug 24, 2018 at 4:02 PM Nir Lisker wrote: >> >>> Hi Miro, >>> >>> Can I use the 2nd option with declaration in the source code, or the only >>>> possible option is to pass as parameter when starting the application? >>>> >>> If your app is not a module then you don't have a module-info.java in >>> your source code to declare the dependency. What you can do is export a >>> package during runtime with the addExports method [1]. >>> >>> [1] >>> https://docs.oracle.com/javase/10/docs/api/java/lang/Module.html#addExports(java.lang.String,java.lang.Module) >>> >>> On Fri, Aug 24, 2018 at 12:38 PM Miroslav Nachev < >>> mnachev.nscenter.eu at gmail.com> wrote: >>> >>>> Hi Arun, >>>> >>>> Thank you. I'm already using the first option, but then I need to access >>>> other methods and classes that are not available. >>>> Can I use the 2nd option with declaration in the source code, or the only >>>> possible option is to pass as parameter when starting the application? >>>> >>>> >>>> Miro. >>>> >>>> On Fri, Aug 24, 2018 at 12:04 PM Arunprasad Rajkumar < >>>> arunprasad.rajkumar at oracle.com> wrote: >>>> >>>>> Hello Miro, >>>>> >>>>> CookieManager is a module private class, which is not exposed to >>>> outside. >>>>> I could think of two options, >>>>> >>>>> 1. com.sun.webkit.network.CookieManager is a type of >>>>> java.net.CookieHandler, that means after instantiating WebEngine, you >>>> can >>>>> call CookieHandler.getDefault() to get the instance of CookieManager. >>>>> new WebEngine(); >>>>> CookieHandler cookieHandler = CookieHandler.getDefault(); // >>>> This >>>>> will be an instance of com.sun.webkit.network.CookieManager >>>>> >>>>> 2. Export the module private implementation using >>>>> "--add-exports=javafx.web/com.sun.webkit.network=ALL-UNNAMED? >>>>> >>>>> Thanks, >>>>> Arun >>>>> >>>>>> On 24-Aug-2018, at 12:27 PM, Miroslav Nachev < >>>>> mnachev.nscenter.eu at gmail.com> wrote: >>>>>> Hi, >>>>>> >>>>>> I have apps that work well on JDK8, but on JDK10 I do not have >>>> access to >>>>>> some classes, for example, com.sun.webkit.network.CookieManager. This >>>>> class >>>>>> is the only one, that is up to date (RFC 6265) and is part of Java. >>>> The >>>>>> java.net.CookieManager class is obsolete: RFC 2965. The Cookie >>>> solution >>>>> in >>>>>> Apache HttpComponents is very complicated, difficult to use, and is >>>>> mostly >>>>>> not compatible with JDK and JavaFX. >>>>>> In fact, I use JavaFX CookieManager in the following 3 scenarios: >>>>>> >>>>>> - When using WebEngine (JavaFX 8). >>>>>> - JavaFX Desktop App to store frequently used words in text and >>>> other >>>>>> fields (TextField, etc.). >>>>>> - To store session parameters in JavaFX Desktop Clients that uses >>>> REST >>>>>> WS or Web Sockets to connect to the Web Server (App Server). >>>>>> >>>>>> Is there any way to enable access to >>>> com.sun.webkit.network.CookieManager >>>>>> at JDK 10? >>>>>> >>>>>> >>>>>> Regards, >>>>>> Miro. >>>>> From wowselim at gmail.com Fri Aug 24 14:44:02 2018 From: wowselim at gmail.com (Selim Dincer) Date: Fri, 24 Aug 2018 16:44:02 +0200 Subject: RFR: 8207328: API docs for javafx.css.Stylesheet are inaccurate / wrong Message-ID: Hey, Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8207328 Pull request: https://github.com/javafxports/openjdk-jfx/pull/147 Thanks, Selim From mnachev.nscenter.eu at gmail.com Fri Aug 24 20:58:45 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Fri, 24 Aug 2018 23:58:45 +0300 Subject: Formatting and Validating Message-ID: Hi, Is there any intention of adding formatting and validating of data in JavaFX? Are there any active projects or libraries for that? For example integer, decimal, currency, custom, etc.? Local data representation, which is typical for each country. It will be good if Formatting and Validating is in real-time during typing. Regards, Miro. From sam.carlberg at gmail.com Fri Aug 24 21:23:20 2018 From: sam.carlberg at gmail.com (Sam Carlberg) Date: Fri, 24 Aug 2018 17:23:20 -0400 Subject: Why are there only platform-specific Maven artifacts? Message-ID: As I see it, providing only platform-specific artifacts makes it difficult or impossible for third-party JavaFX libraries or frameworks to depend on the JavaFX API and pass it along to consumers. Libraries don't care about the platform-specific code - that's up the final application to determine - but are forced to arbitrarily choose one of the Windows, Mac, or Linux JARs anyway. I suppose they could use a compileOnly configuration, but that forces all downstream consumers to re-declare the JavaFX dependencies (and keep track of the dependencies of the library, too!) IMO it makes more sense to publish the general API classes into a classifier-less JAR (which are now the "empty JARs") and place the platform-specific classes and binaries in platform-specific artifacts with a different name. For example, JavaFX could have a "javafx-graphics" artifact for the platform-agnostic classes, and a `java-graphics-platform" for platform-specific code, with classifiers to specify the platform. This does run into the "empty JAR" issue again, but it'd be limited in scope to only the final application. -- Sam Carlberg From david.grieve at oracle.com Fri Aug 24 21:24:29 2018 From: david.grieve at oracle.com (David Grieve) Date: Fri, 24 Aug 2018 17:24:29 -0400 Subject: Formatting and Validating In-Reply-To: References: Message-ID: <9cf15139-72ff-6e66-8312-452e56ffce43@oracle.com> You can set a javafx.scene.control.TextFormatter on any TextInputControl On 8/24/18 4:58 PM, Miroslav Nachev wrote: > Hi, > > Is there any intention of adding formatting and validating of data in > JavaFX? Are there any active projects or libraries for that? > > For example integer, decimal, currency, custom, etc.? Local data > representation, which is typical for each country. > > It will be good if Formatting and Validating is in real-time during typing. > > > Regards, > Miro. From hjohn at xs4all.nl Fri Aug 24 22:07:39 2018 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 25 Aug 2018 00:07:39 +0200 Subject: Build fails at graphics:linkWinFont Message-ID: <62366d5a-6920-c16b-8a81-ece7c78072fe@xs4all.nl> Hi, I'm trying to get openjfx build on Windows, but I've run into an issue I haven't been able to resolve. Any tips I can try? --John > Task :graphics:linkWinFont FAILED Creating library P:\Dev\git\openjdk-jfx\modules\javafx.graphics\build\libs\font\win\javafx_font.lib and object P:\Dev\git\openjdk-jfx\modules\javafx.graphics\build\libs\font\win\javafx_font.exp fontpath.obj : error LNK2019: unresolved external symbol __imp_EnumFontFamiliesExW referenced in function DifferentFamily fontpath.obj : error LNK2019: unresolved external symbol __imp_GetDeviceCaps referenced in function Java_com_sun_javafx_font_PrismFontFactory_getSystemFontSizeNative C:/Program Files (x86)/Windows Kits/10/lib/10.0.16299.0/um/x86\gdi32.lib : warning LNK4272: library machine type 'X86' conflicts with target machine type 'x64' P:\Dev\git\openjdk-jfx\modules\javafx.graphics\build\libs\font\win\javafx_font.dll : fatal error LNK1120: 2 unresolved externals FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':graphics:linkWinFont'. > Process 'command 'C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.10.25017/bin/HostX64/x64/link.exe'' finished with non-zero exit value 1120 From kevin.rushforth at oracle.com Fri Aug 24 22:24:17 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 24 Aug 2018 15:24:17 -0700 Subject: Build fails at graphics:linkWinFont In-Reply-To: <62366d5a-6920-c16b-8a81-ece7c78072fe@xs4all.nl> References: <62366d5a-6920-c16b-8a81-ece7c78072fe@xs4all.nl> Message-ID: > C:/Program Files (x86)/Windows > Kits/10/lib/10.0.16299.0/um/x86\gdi32.lib : warning LNK4272: library > machine type 'X86' conflicts with target machine type 'x64' This looks like a problem where the tools are confused about 32-bit versus 64-bit. It might be something missing from your Visual Studio installation, but it's hard to say without more information. Take a look at build/windows_tools.properties and see if anything looks odd. One thing you could try is to 'rm -rf build', then run 'gradle clean' then try the build again. -- Kevin On 8/24/2018 3:07 PM, John Hendrikx wrote: > Hi, > > I'm trying to get openjfx build on Windows, but I've run into an issue > I haven't been able to resolve. > > Any tips I can try? > > --John > > > > Task :graphics:linkWinFont FAILED > ?? Creating library > P:\Dev\git\openjdk-jfx\modules\javafx.graphics\build\libs\font\win\javafx_font.lib > and object > P:\Dev\git\openjdk-jfx\modules\javafx.graphics\build\libs\font\win\javafx_font.exp > fontpath.obj : error LNK2019: unresolved external symbol > __imp_EnumFontFamiliesExW referenced in function DifferentFamily > fontpath.obj : error LNK2019: unresolved external symbol > __imp_GetDeviceCaps referenced in function > Java_com_sun_javafx_font_PrismFontFactory_getSystemFontSizeNative > C:/Program Files (x86)/Windows > Kits/10/lib/10.0.16299.0/um/x86\gdi32.lib : warning LNK4272: library > machine type 'X86' conflicts with target machine type 'x64' > P:\Dev\git\openjdk-jfx\modules\javafx.graphics\build\libs\font\win\javafx_font.dll > : fatal error LNK1120: 2 unresolved externals > > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':graphics:linkWinFont'. > > Process 'command 'C:/Program Files (x86)/Microsoft Visual > Studio/2017/Enterprise/VC/Tools/MSVC/14.10.25017/bin/HostX64/x64/link.exe'' > finished with non-zero exit value 1120 > From arunprasad.rajkumar at oracle.com Sat Aug 25 06:55:41 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Sat, 25 Aug 2018 12:25:41 +0530 Subject: [RFR] [openjfx12] 8148129: Implement Accelerated composition for WebView Message-ID: Hi, Please review the patch for following enhancement, it is targeted for openjfx12. https://bugs.openjdk.java.net/browse/JDK-8148129 Changes are available as gihub PR, refer the following link, https://github.com/javafxports/openjdk-jfx/pull/51 Unified diff is available in the following link, https://github.com/javafxports/openjdk-jfx/pull/51.diff Thanks, Arun From johan.vos at gluonhq.com Sat Aug 25 07:27:04 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 25 Aug 2018 09:27:04 +0200 Subject: building webkit Message-ID: We currently don't build WebKit with Appveyor/Travis, as the combined build time would be too long. I'm wondering though if it would be possible to have separate build jobs for webkit? Typically, when building a JavaFX SDK, the webkit part is where things go wrong (if they go wrong), and have that somehow automated would be very helpful. - Johan From hjohn at xs4all.nl Sat Aug 25 07:47:55 2018 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 25 Aug 2018 09:47:55 +0200 Subject: Build fails at graphics:linkWinFont In-Reply-To: References: <62366d5a-6920-c16b-8a81-ece7c78072fe@xs4all.nl> Message-ID: <0dc4440c-96c9-e3f8-7a7a-3e713d840dd0@xs4all.nl> There should have been a gdi32.lib in the x64 folder as well, but there wasn't. Downloading a Windows SDK (10.0.16299) and installing it solved this. --John On 25/08/2018 00:24, Kevin Rushforth wrote: > >> C:/Program Files (x86)/Windows >> Kits/10/lib/10.0.16299.0/um/x86\gdi32.lib : warning LNK4272: library >> machine type 'X86' conflicts with target machine type 'x64' > > This looks like a problem where the tools are confused about 32-bit > versus 64-bit. It might be something missing from your Visual Studio > installation, but it's hard to say without more information. Take a look > at build/windows_tools.properties and see if anything looks odd. One > thing you could try is to 'rm -rf build', then run 'gradle clean' then > try the build again. > > -- Kevin > > > On 8/24/2018 3:07 PM, John Hendrikx wrote: >> Hi, >> >> I'm trying to get openjfx build on Windows, but I've run into an issue >> I haven't been able to resolve. >> >> Any tips I can try? >> >> --John >> >> >> > Task :graphics:linkWinFont FAILED >> Creating library >> P:\Dev\git\openjdk-jfx\modules\javafx.graphics\build\libs\font\win\javafx_font.lib >> and object >> P:\Dev\git\openjdk-jfx\modules\javafx.graphics\build\libs\font\win\javafx_font.exp >> >> fontpath.obj : error LNK2019: unresolved external symbol >> __imp_EnumFontFamiliesExW referenced in function DifferentFamily >> fontpath.obj : error LNK2019: unresolved external symbol >> __imp_GetDeviceCaps referenced in function >> Java_com_sun_javafx_font_PrismFontFactory_getSystemFontSizeNative >> C:/Program Files (x86)/Windows >> Kits/10/lib/10.0.16299.0/um/x86\gdi32.lib : warning LNK4272: library >> machine type 'X86' conflicts with target machine type 'x64' >> P:\Dev\git\openjdk-jfx\modules\javafx.graphics\build\libs\font\win\javafx_font.dll >> : fatal error LNK1120: 2 unresolved externals >> >> FAILURE: Build failed with an exception. >> >> * What went wrong: >> Execution failed for task ':graphics:linkWinFont'. >> > Process 'command 'C:/Program Files (x86)/Microsoft Visual >> Studio/2017/Enterprise/VC/Tools/MSVC/14.10.25017/bin/HostX64/x64/link.exe'' >> finished with non-zero exit value 1120 >> > From kevin.rushforth at oracle.com Sat Aug 25 13:00:04 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 25 Aug 2018 06:00:04 -0700 (PDT) Subject: building webkit In-Reply-To: References: Message-ID: Yes, this should be possible to do. Even without build changes, we could build just the SDK + WebKit (and maybe media, too, or maybe a separate job for that). The problem is that even building just WebKit takes longer than Travis / Appveyor will allow. See PR #121 [1]. Arun can comment further. Irrespective of the above, as long as a compatible SDK (meaning an SDK built from the current tip of jfx-dev/rt) is available for download, the build can point to it, and will use the jfxwebkit and media natives from that build. So if we had a nightly build available, most developers could use that (it wouldn't help anyone making native changes to WebKit, but would be fine for most developers who don't). -- Kevin [1] https://github.com/javafxports/openjdk-jfx/pull/121 On 8/25/2018 12:27 AM, Johan Vos wrote: > We currently don't build WebKit with Appveyor/Travis, as the combined build > time would be too long. > > I'm wondering though if it would be possible to have separate build jobs > for webkit? Typically, when building a JavaFX SDK, the webkit part is where > things go wrong (if they go wrong), and have that somehow automated would > be very helpful. > > - Johan From kevin.rushforth at oracle.com Sat Aug 25 13:01:48 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 25 Aug 2018 06:01:48 -0700 Subject: Build fails at graphics:linkWinFont In-Reply-To: <0dc4440c-96c9-e3f8-7a7a-3e713d840dd0@xs4all.nl> References: <62366d5a-6920-c16b-8a81-ece7c78072fe@xs4all.nl> <0dc4440c-96c9-e3f8-7a7a-3e713d840dd0@xs4all.nl> Message-ID: Good to know. -- Kevin On 8/25/2018 12:47 AM, John Hendrikx wrote: > There should have been a gdi32.lib in the x64 folder as well, but > there wasn't.? Downloading a Windows SDK (10.0.16299) and installing > it solved this. > > --John > > On 25/08/2018 00:24, Kevin Rushforth wrote: >> >>> C:/Program Files (x86)/Windows >>> Kits/10/lib/10.0.16299.0/um/x86\gdi32.lib : warning LNK4272: library >>> machine type 'X86' conflicts with target machine type 'x64' >> >> This looks like a problem where the tools are confused about 32-bit >> versus 64-bit. It might be something missing from your Visual Studio >> installation, but it's hard to say without more information. Take a look >> at build/windows_tools.properties and see if anything looks odd. One >> thing you could try is to 'rm -rf build', then run 'gradle clean' then >> try the build again. >> >> -- Kevin >> >> >> On 8/24/2018 3:07 PM, John Hendrikx wrote: >>> Hi, >>> >>> I'm trying to get openjfx build on Windows, but I've run into an issue >>> I haven't been able to resolve. >>> >>> Any tips I can try? >>> >>> --John >>> >>> >>> > Task :graphics:linkWinFont FAILED >>> ?? Creating library >>> P:\Dev\git\openjdk-jfx\modules\javafx.graphics\build\libs\font\win\javafx_font.lib >>> >>> and object >>> P:\Dev\git\openjdk-jfx\modules\javafx.graphics\build\libs\font\win\javafx_font.exp >>> >>> >>> fontpath.obj : error LNK2019: unresolved external symbol >>> __imp_EnumFontFamiliesExW referenced in function DifferentFamily >>> fontpath.obj : error LNK2019: unresolved external symbol >>> __imp_GetDeviceCaps referenced in function >>> Java_com_sun_javafx_font_PrismFontFactory_getSystemFontSizeNative >>> C:/Program Files (x86)/Windows >>> Kits/10/lib/10.0.16299.0/um/x86\gdi32.lib : warning LNK4272: library >>> machine type 'X86' conflicts with target machine type 'x64' >>> P:\Dev\git\openjdk-jfx\modules\javafx.graphics\build\libs\font\win\javafx_font.dll >>> >>> : fatal error LNK1120: 2 unresolved externals >>> >>> FAILURE: Build failed with an exception. >>> >>> * What went wrong: >>> Execution failed for task ':graphics:linkWinFont'. >>> > Process 'command 'C:/Program Files (x86)/Microsoft Visual >>> Studio/2017/Enterprise/VC/Tools/MSVC/14.10.25017/bin/HostX64/x64/link.exe'' >>> >>> finished with non-zero exit value 1120 >>> >> From tom.schindl at bestsolution.at Sat Aug 25 13:04:45 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 25 Aug 2018 15:04:45 +0200 Subject: building webkit In-Reply-To: References: Message-ID: <62be0ee0-7609-0086-8f20-1d239584c85f@bestsolution.at> Hi, How does AdoptJDK solve problems of long build times? Can we not adopt their build chain/infrastructure? Tom On 25.08.18 15:00, Kevin Rushforth wrote: > Yes, this should be possible to do. Even without build changes, we could > build just the SDK + WebKit (and maybe media, too, or maybe a separate > job for that). The problem is that even building just WebKit takes > longer than Travis / Appveyor will allow. See PR #121 [1]. Arun can > comment further. > > Irrespective of the above, as long as a compatible SDK (meaning an SDK > built from the current tip of jfx-dev/rt) is available for download, the > build can point to it, and will use the jfxwebkit and media natives from > that build. So if we had a nightly build available, most developers > could use that (it wouldn't help anyone making native changes to WebKit, > but would be fine for most developers who don't). > > -- Kevin > > [1] https://github.com/javafxports/openjdk-jfx/pull/121 > > > On 8/25/2018 12:27 AM, Johan Vos wrote: >> We currently don't build WebKit with Appveyor/Travis, as the combined >> build >> time would be too long. >> >> I'm wondering though if it would be possible to have separate build jobs >> for webkit? Typically, when building a JavaFX SDK, the webkit part is >> where >> things go wrong (if they go wrong), and have that somehow automated would >> be very helpful. >> >> - Johan > -- 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 Sat Aug 25 15:18:54 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 25 Aug 2018 08:18:54 -0700 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 Message-ID: <41e69ff5-28cb-cc71-4352-d957edf7f1ac@oracle.com> Please review the following on GitHub: https://bugs.openjdk.java.net/browse/JDK-8209967 https://github.com/javafxports/openjdk-jfx/pull/169 This bumps the minimum version of gradle for openjfx 12 to the current 4.8 version (which is the version used by our builds and by gradlew). This is needed in preparation for eventually bumping the minimum boot JDK to 11 after JDK 11 ships. -- Kevin From kevin.rushforth at oracle.com Sat Aug 25 16:09:43 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 25 Aug 2018 09:09:43 -0700 Subject: [12] RFR: 8209967: Bump minimum gradle version to 4.8 for JDK 11 In-Reply-To: <41e69ff5-28cb-cc71-4352-d957edf7f1ac@oracle.com> References: <41e69ff5-28cb-cc71-4352-d957edf7f1ac@oracle.com> Message-ID: <3e9032d2-fd6a-1f29-c557-8e4466ce146a@oracle.com> [resend with the correct subject line] On 8/25/2018 8:18 AM, Kevin Rushforth wrote: > Please review the following on GitHub: > > https://bugs.openjdk.java.net/browse/JDK-8209967 > https://github.com/javafxports/openjdk-jfx/pull/169 > > This bumps the minimum version of gradle for openjfx 12 to the current > 4.8 version (which is the version used by our builds and by gradlew). > This is needed in preparation for eventually bumping the minimum boot > JDK to 11 after JDK 11 ships. > > -- Kevin > From kevin.rushforth at oracle.com Sat Aug 25 16:12:54 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 25 Aug 2018 09:12:54 -0700 Subject: IGNORE: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 In-Reply-To: <41e69ff5-28cb-cc71-4352-d957edf7f1ac@oracle.com> References: <41e69ff5-28cb-cc71-4352-d957edf7f1ac@oracle.com> Message-ID: Please ignore this subject line. I re-sent the RFR with the correct subject line. There is not yet a proposed fix to review for updating the minimum boot JDK to 11 (nor will there be for another 3-4 weeks until JDK 11 is released). Sorry for the mix-up. -- Kevin From arunprasad.rajkumar at oracle.com Sat Aug 25 17:01:57 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Sat, 25 Aug 2018 22:31:57 +0530 Subject: building webkit In-Reply-To: <62be0ee0-7609-0086-8f20-1d239584c85f@bestsolution.at> References: <62be0ee0-7609-0086-8f20-1d239584c85f@bestsolution.at> Message-ID: <4C540054-5B1B-4390-9689-3D99D4EB26DD@oracle.com> As Kevin mentioned, I tried to make WebKit build work on Travis with few hacks(using ccache). It seemed to be working, but not consistently all the time. > How does AdoptJDK solve problems of long build times? Can we not adopt > their build chain/infrastructure? Looks like they host their own CI infra without relying on Travis/Appveyor. > On 25-Aug-2018, at 6:34 PM, Tom Schindl wrote: > > Hi, > > How does AdoptJDK solve problems of long build times? Can we not adopt > their build chain/infrastructure? > > Tom > > On 25.08.18 15:00, Kevin Rushforth wrote: >> Yes, this should be possible to do. Even without build changes, we could >> build just the SDK + WebKit (and maybe media, too, or maybe a separate >> job for that). The problem is that even building just WebKit takes >> longer than Travis / Appveyor will allow. See PR #121 [1]. Arun can >> comment further. >> >> Irrespective of the above, as long as a compatible SDK (meaning an SDK >> built from the current tip of jfx-dev/rt) is available for download, the >> build can point to it, and will use the jfxwebkit and media natives from >> that build. So if we had a nightly build available, most developers >> could use that (it wouldn't help anyone making native changes to WebKit, >> but would be fine for most developers who don't). >> >> -- Kevin >> >> [1] https://github.com/javafxports/openjdk-jfx/pull/121 >> >> >> On 8/25/2018 12:27 AM, Johan Vos wrote: >>> We currently don't build WebKit with Appveyor/Travis, as the combined >>> build >>> time would be too long. >>> >>> I'm wondering though if it would be possible to have separate build jobs >>> for webkit? Typically, when building a JavaFX SDK, the webkit part is >>> where >>> things go wrong (if they go wrong), and have that somehow automated would >>> be very helpful. >>> >>> - Johan >> > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From johan.vos at gluonhq.com Sat Aug 25 17:16:39 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 25 Aug 2018 19:16:39 +0200 Subject: building webkit In-Reply-To: <62be0ee0-7609-0086-8f20-1d239584c85f@bestsolution.at> References: <62be0ee0-7609-0086-8f20-1d239584c85f@bestsolution.at> Message-ID: Using AdoptOpenJDK infrastructure would be great, but we're sort of stuck on Ansible. The AdoptOpenJDK build farm uses Ansible for provisioning systems with the required components. We're almost there with an Ansible script for Linux, but Windows turns out to be extremely complicated (at least for me, with 0 experience in Ansible). - Johan On Sat, Aug 25, 2018 at 3:15 PM Tom Schindl wrote: > Hi, > > How does AdoptJDK solve problems of long build times? Can we not adopt > their build chain/infrastructure? > > Tom > > On 25.08.18 15:00, Kevin Rushforth wrote: > > Yes, this should be possible to do. Even without build changes, we could > > build just the SDK + WebKit (and maybe media, too, or maybe a separate > > job for that). The problem is that even building just WebKit takes > > longer than Travis / Appveyor will allow. See PR #121 [1]. Arun can > > comment further. > > > > Irrespective of the above, as long as a compatible SDK (meaning an SDK > > built from the current tip of jfx-dev/rt) is available for download, the > > build can point to it, and will use the jfxwebkit and media natives from > > that build. So if we had a nightly build available, most developers > > could use that (it wouldn't help anyone making native changes to WebKit, > > but would be fine for most developers who don't). > > > > -- Kevin > > > > [1] https://github.com/javafxports/openjdk-jfx/pull/121 > > > > > > On 8/25/2018 12:27 AM, Johan Vos wrote: > >> We currently don't build WebKit with Appveyor/Travis, as the combined > >> build > >> time would be too long. > >> > >> I'm wondering though if it would be possible to have separate build jobs > >> for webkit? Typically, when building a JavaFX SDK, the webkit part is > >> where > >> things go wrong (if they go wrong), and have that somehow automated > would > >> be very helpful. > >> > >> - Johan > > > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > From johan.vos at gluonhq.com Sat Aug 25 17:17:30 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 25 Aug 2018 19:17:30 +0200 Subject: building webkit In-Reply-To: <4C540054-5B1B-4390-9689-3D99D4EB26DD@oracle.com> References: <62be0ee0-7609-0086-8f20-1d239584c85f@bestsolution.at> <4C540054-5B1B-4390-9689-3D99D4EB26DD@oracle.com> Message-ID: Is the non-consistency due to varying build times, which may lead to canceled jobs? On Sat, Aug 25, 2018 at 7:12 PM Arunprasad Rajkumar < arunprasad.rajkumar at oracle.com> wrote: > As Kevin mentioned, I tried to make WebKit build work on Travis with few > hacks(using ccache). It seemed to be working, but not consistently all the > time. > > > How does AdoptJDK solve problems of long build times? Can we not adopt > > their build chain/infrastructure? > > Looks like they host their own CI infra without relying on Travis/Appveyor. > > > On 25-Aug-2018, at 6:34 PM, Tom Schindl > wrote: > > > > Hi, > > > > How does AdoptJDK solve problems of long build times? Can we not adopt > > their build chain/infrastructure? > > > > Tom > > > > On 25.08.18 15:00, Kevin Rushforth wrote: > >> Yes, this should be possible to do. Even without build changes, we could > >> build just the SDK + WebKit (and maybe media, too, or maybe a separate > >> job for that). The problem is that even building just WebKit takes > >> longer than Travis / Appveyor will allow. See PR #121 [1]. Arun can > >> comment further. > >> > >> Irrespective of the above, as long as a compatible SDK (meaning an SDK > >> built from the current tip of jfx-dev/rt) is available for download, the > >> build can point to it, and will use the jfxwebkit and media natives from > >> that build. So if we had a nightly build available, most developers > >> could use that (it wouldn't help anyone making native changes to WebKit, > >> but would be fine for most developers who don't). > >> > >> -- Kevin > >> > >> [1] https://github.com/javafxports/openjdk-jfx/pull/121 > >> > >> > >> On 8/25/2018 12:27 AM, Johan Vos wrote: > >>> We currently don't build WebKit with Appveyor/Travis, as the combined > >>> build > >>> time would be too long. > >>> > >>> I'm wondering though if it would be possible to have separate build > jobs > >>> for webkit? Typically, when building a JavaFX SDK, the webkit part is > >>> where > >>> things go wrong (if they go wrong), and have that somehow automated > would > >>> be very helpful. > >>> > >>> - Johan > >> > > > > -- > > Tom Schindl, CTO > > BestSolution.at EDV Systemhaus GmbH > > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > > From arunprasad.rajkumar at oracle.com Sat Aug 25 17:43:51 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Sat, 25 Aug 2018 23:13:51 +0530 Subject: building webkit In-Reply-To: References: <62be0ee0-7609-0086-8f20-1d239584c85f@bestsolution.at> <4C540054-5B1B-4390-9689-3D99D4EB26DD@oracle.com> Message-ID: <0902B257-CFEA-4EBD-8CAF-EE51E76647C3@oracle.com> Build time is kinda constant, with 2 cores, It would take around 1hr 15mins to complete. I need to restart the job several times to complete the incremental build with ccache doing some object file caching. > On 25-Aug-2018, at 10:47 PM, Johan Vos wrote: > > Is the non-consistency due to varying build times, which may lead to canceled jobs? > > On Sat, Aug 25, 2018 at 7:12 PM Arunprasad Rajkumar > wrote: > As Kevin mentioned, I tried to make WebKit build work on Travis with few hacks(using ccache). It seemed to be working, but not consistently all the time. > > > How does AdoptJDK solve problems of long build times? Can we not adopt > > their build chain/infrastructure? > > Looks like they host their own CI infra without relying on Travis/Appveyor. > > > On 25-Aug-2018, at 6:34 PM, Tom Schindl > wrote: > > > > Hi, > > > > How does AdoptJDK solve problems of long build times? Can we not adopt > > their build chain/infrastructure? > > > > Tom > > > > On 25.08.18 15:00, Kevin Rushforth wrote: > >> Yes, this should be possible to do. Even without build changes, we could > >> build just the SDK + WebKit (and maybe media, too, or maybe a separate > >> job for that). The problem is that even building just WebKit takes > >> longer than Travis / Appveyor will allow. See PR #121 [1]. Arun can > >> comment further. > >> > >> Irrespective of the above, as long as a compatible SDK (meaning an SDK > >> built from the current tip of jfx-dev/rt) is available for download, the > >> build can point to it, and will use the jfxwebkit and media natives from > >> that build. So if we had a nightly build available, most developers > >> could use that (it wouldn't help anyone making native changes to WebKit, > >> but would be fine for most developers who don't). > >> > >> -- Kevin > >> > >> [1] https://github.com/javafxports/openjdk-jfx/pull/121 > >> > >> > >> On 8/25/2018 12:27 AM, Johan Vos wrote: > >>> We currently don't build WebKit with Appveyor/Travis, as the combined > >>> build > >>> time would be too long. > >>> > >>> I'm wondering though if it would be possible to have separate build jobs > >>> for webkit? Typically, when building a JavaFX SDK, the webkit part is > >>> where > >>> things go wrong (if they go wrong), and have that somehow automated would > >>> be very helpful. > >>> > >>> - Johan > >> > > > > -- > > Tom Schindl, CTO > > BestSolution.at EDV Systemhaus GmbH > > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > From tom.schindl at bestsolution.at Sat Aug 25 19:03:05 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 25 Aug 2018 21:03:05 +0200 Subject: building webkit In-Reply-To: <4C540054-5B1B-4390-9689-3D99D4EB26DD@oracle.com> References: <62be0ee0-7609-0086-8f20-1d239584c85f@bestsolution.at> <4C540054-5B1B-4390-9689-3D99D4EB26DD@oracle.com> Message-ID: <8532BEC0-7EC2-43C0-B902-0696450393BF@bestsolution.at> I think in the longrun using the adoptjdk approch is the one to follow. Tom Von meinem iPhone gesendet > Am 25.08.2018 um 19:01 schrieb Arunprasad Rajkumar : > > As Kevin mentioned, I tried to make WebKit build work on Travis with few hacks(using ccache). It seemed to be working, but not consistently all the time. > >> How does AdoptJDK solve problems of long build times? Can we not adopt >> their build chain/infrastructure? > > Looks like they host their own CI infra without relying on Travis/Appveyor. > >> On 25-Aug-2018, at 6:34 PM, Tom Schindl wrote: >> >> Hi, >> >> How does AdoptJDK solve problems of long build times? Can we not adopt >> their build chain/infrastructure? >> >> Tom >> >>> On 25.08.18 15:00, Kevin Rushforth wrote: >>> Yes, this should be possible to do. Even without build changes, we could >>> build just the SDK + WebKit (and maybe media, too, or maybe a separate >>> job for that). The problem is that even building just WebKit takes >>> longer than Travis / Appveyor will allow. See PR #121 [1]. Arun can >>> comment further. >>> >>> Irrespective of the above, as long as a compatible SDK (meaning an SDK >>> built from the current tip of jfx-dev/rt) is available for download, the >>> build can point to it, and will use the jfxwebkit and media natives from >>> that build. So if we had a nightly build available, most developers >>> could use that (it wouldn't help anyone making native changes to WebKit, >>> but would be fine for most developers who don't). >>> >>> -- Kevin >>> >>> [1] https://github.com/javafxports/openjdk-jfx/pull/121 >>> >>> >>>> On 8/25/2018 12:27 AM, Johan Vos wrote: >>>> We currently don't build WebKit with Appveyor/Travis, as the combined >>>> build >>>> time would be too long. >>>> >>>> I'm wondering though if it would be possible to have separate build jobs >>>> for webkit? Typically, when building a JavaFX SDK, the webkit part is >>>> where >>>> things go wrong (if they go wrong), and have that somehow automated would >>>> be very helpful. >>>> >>>> - Johan >>> >> >> -- >> Tom Schindl, CTO >> BestSolution.at EDV Systemhaus GmbH >> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > From mike.ennen at gmail.com Sat Aug 25 20:40:07 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Sat, 25 Aug 2018 13:40:07 -0700 Subject: Review-Request for JDK-8209970 Message-ID: Hi, I'd like to request a review for JDK-8209970 available as a PR on Github: https://github.com/javafxports/openjdk-jfx/pull/168 https://bugs.openjdk.java.net/browse/JDK-8209970 Thanks. -- Michael Ennen From johan.vos at gluonhq.com Sun Aug 26 14:05:23 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 26 Aug 2018 16:05:23 +0200 Subject: Why are there only platform-specific Maven artifacts? In-Reply-To: References: Message-ID: The platform-specific code is a general Java issue that needs to be solved one day. Your suggestion basically comes down to moving the classfiles from the platform-specific jars into the empty jars, right? A problem with this is that currently, the jars are platform-dependent as well (e.g. no OpenGL on win). Apart from that, your comments about libraries make sense: libraries don't care about platforms. But I think this could be better fixed at the level of the build tools (maven/gradle), combined with the module-info: if your library depends on e.g. javafx.controls, it should be enough to have that in your module-info.java. The current situation is an artificial semi-parallel dependency system, where dependencies are added with classifiers in e.g. build.gradle or pom.xml and without classifiers in module-info.java - Johan On Fri, Aug 24, 2018 at 11:34 PM Sam Carlberg wrote: > As I see it, providing only platform-specific artifacts makes it difficult > or impossible for third-party JavaFX libraries or frameworks to depend on > the JavaFX API and pass it along to consumers. Libraries don't care about > the platform-specific code - that's up the final application to determine - > but are forced to arbitrarily choose one of the Windows, Mac, or Linux JARs > anyway. I suppose they could use a compileOnly configuration, but that > forces all downstream consumers to re-declare the JavaFX dependencies (and > keep track of the dependencies of the library, too!) > > IMO it makes more sense to publish the general API classes into a > classifier-less JAR (which are now the "empty JARs") and place the > platform-specific classes and binaries in platform-specific artifacts with > a different name. For example, JavaFX could have a "javafx-graphics" > artifact for the platform-agnostic classes, and a `java-graphics-platform" > for platform-specific code, with classifiers to specify the platform. This > does run into the "empty JAR" issue again, but it'd be limited in scope to > only the final application. > > -- > Sam Carlberg > From la.tinca at gmail.com Sun Aug 26 14:59:54 2018 From: la.tinca at gmail.com (=?UTF-8?Q?Zsolt_K=C3=BAti?=) Date: Sun, 26 Aug 2018 16:59:54 +0200 Subject: how to implement delayed calculation of node/shape Message-ID: Hi, Some of my classes extend Path or Group and constructed by non-trivial algorithms that may use many properties, either standard (like strokeWidth) or non-standard ones. Setting a property calculates a new state at present. When several properties are set it means a lot of unnecessary calculations done. I would like to delay geometry/shape calculations similar the way Node/Shape do. They signal their state changes by dirty flagging and on pulse necessary synchronization does recalculations when being dirty. However relevant methods despite being public are deprecated (tipically ones starting with impl_) and cannot be relied upon. Is there a way to achive that kind of design for own classes? Thx! Zsolt From mp at jugs.org Sun Aug 26 15:16:04 2018 From: mp at jugs.org (Michael Paus) Date: Sun, 26 Aug 2018 17:16:04 +0200 Subject: how to implement delayed calculation of node/shape In-Reply-To: References: Message-ID: <112eb328-2790-b221-81c6-77e6269a4679@jugs.org> One possible solution for this would be to use an AnimationTimer. Maintain a dirty state somewhere and check that when the AnimationTimer gets called for the next pulse. Am 26.08.18 um 16:59 schrieb Zsolt K?ti: > Hi, > Some of my classes extend Path or Group and constructed by non-trivial > algorithms that may use many properties, either standard (like strokeWidth) > or non-standard ones. Setting a property calculates a new state at present. > When several properties are set it means a lot of unnecessary calculations > done. > > I would like to delay geometry/shape calculations similar the way > Node/Shape do. They signal their state changes by dirty flagging and on > pulse necessary synchronization does recalculations when being dirty. > However relevant methods despite being public are deprecated (tipically > ones starting with impl_) and cannot be relied upon. > > Is there a way to achive that kind of design for own classes? > Thx! > > Zsolt From la.tinca at gmail.com Mon Aug 27 07:48:20 2018 From: la.tinca at gmail.com (=?UTF-8?Q?Zsolt_K=C3=BAti?=) Date: Mon, 27 Aug 2018 09:48:20 +0200 Subject: how to implement delayed calculation of node/shape In-Reply-To: <112eb328-2790-b221-81c6-77e6269a4679@jugs.org> References: <112eb328-2790-b221-81c6-77e6269a4679@jugs.org> Message-ID: Thank you for the idea, I'll explore it. On Sun, Aug 26, 2018 at 5:16 PM Michael Paus wrote: > One possible solution for this would be to use an AnimationTimer. > Maintain a dirty state somewhere and check that when the AnimationTimer > gets called for the next pulse. > > Am 26.08.18 um 16:59 schrieb Zsolt K?ti: > > Hi, > > Some of my classes extend Path or Group and constructed by non-trivial > > algorithms that may use many properties, either standard (like > strokeWidth) > > or non-standard ones. Setting a property calculates a new state at > present. > > When several properties are set it means a lot of unnecessary > calculations > > done. > > > > I would like to delay geometry/shape calculations similar the way > > Node/Shape do. They signal their state changes by dirty flagging and on > > pulse necessary synchronization does recalculations when being dirty. > > However relevant methods despite being public are deprecated (tipically > > ones starting with impl_) and cannot be relied upon. > > > > Is there a way to achive that kind of design for own classes? > > Thx! > > > > Zsolt > > > From tom.schindl at bestsolution.at Mon Aug 27 10:15:51 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 27 Aug 2018 12:15:51 +0200 Subject: how to implement delayed calculation of node/shape In-Reply-To: References: <112eb328-2790-b221-81c6-77e6269a4679@jugs.org> Message-ID: <384290f2-4fae-e175-2489-74dfa296d8ba@bestsolution.at> Why not do the necessary stuff on the next layout-pass? Tom On 27.08.18 09:48, Zsolt K?ti wrote: > Thank you for the idea, I'll explore it. > > On Sun, Aug 26, 2018 at 5:16 PM Michael Paus wrote: > >> One possible solution for this would be to use an AnimationTimer. >> Maintain a dirty state somewhere and check that when the AnimationTimer >> gets called for the next pulse. >> >> Am 26.08.18 um 16:59 schrieb Zsolt K?ti: >>> Hi, >>> Some of my classes extend Path or Group and constructed by non-trivial >>> algorithms that may use many properties, either standard (like >> strokeWidth) >>> or non-standard ones. Setting a property calculates a new state at >> present. >>> When several properties are set it means a lot of unnecessary >> calculations >>> done. >>> >>> I would like to delay geometry/shape calculations similar the way >>> Node/Shape do. They signal their state changes by dirty flagging and on >>> pulse necessary synchronization does recalculations when being dirty. >>> However relevant methods despite being public are deprecated (tipically >>> ones starting with impl_) and cannot be relied upon. >>> >>> Is there a way to achive that kind of design for own classes? >>> Thx! >>> >>> Zsolt >> >> >> -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From la.tinca at gmail.com Mon Aug 27 11:14:46 2018 From: la.tinca at gmail.com (=?UTF-8?Q?Zsolt_K=C3=BAti?=) Date: Mon, 27 Aug 2018 13:14:46 +0200 Subject: how to implement delayed calculation of node/shape In-Reply-To: <384290f2-4fae-e175-2489-74dfa296d8ba@bestsolution.at> References: <112eb328-2790-b221-81c6-77e6269a4679@jugs.org> <384290f2-4fae-e175-2489-74dfa296d8ba@bestsolution.at> Message-ID: >From Scene doc: "The scene graph detects dynamic node changes which affect layout (such as a change in size or content) and calls requestLayout(), which marks that branch as needing layout so that on the next pulse, a top-down layout pass is executed on that branch by invoking layout() on that branch's root. During that layout pass, the layoutChildren() callback method will be called on each parent to layout its children. This mechanism is designed to maximize layout efficiency by ensuring multiple layout requests are coalesced and processed in a single pass rather than executing re-layout on on each minute change." Parent class has a layoutChildren() method that can be overriden. Do you mean processing my own classes here depending on their dirty state? If not, can you elaborate on that suggestion? Thanks. On Mon, Aug 27, 2018 at 12:16 PM Tom Schindl wrote: > Why not do the necessary stuff on the next layout-pass? > > Tom > > On 27.08.18 09:48, Zsolt K?ti wrote: > > Thank you for the idea, I'll explore it. > > > > On Sun, Aug 26, 2018 at 5:16 PM Michael Paus wrote: > > > >> One possible solution for this would be to use an AnimationTimer. > >> Maintain a dirty state somewhere and check that when the AnimationTimer > >> gets called for the next pulse. > >> > >> Am 26.08.18 um 16:59 schrieb Zsolt K?ti: > >>> Hi, > >>> Some of my classes extend Path or Group and constructed by non-trivial > >>> algorithms that may use many properties, either standard (like > >> strokeWidth) > >>> or non-standard ones. Setting a property calculates a new state at > >> present. > >>> When several properties are set it means a lot of unnecessary > >> calculations > >>> done. > >>> > >>> I would like to delay geometry/shape calculations similar the way > >>> Node/Shape do. They signal their state changes by dirty flagging and on > >>> pulse necessary synchronization does recalculations when being dirty. > >>> However relevant methods despite being public are deprecated (tipically > >>> ones starting with impl_) and cannot be relied upon. > >>> > >>> Is there a way to achive that kind of design for own classes? > >>> Thx! > >>> > >>> Zsolt > >> > >> > >> > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > From sam.carlberg at gmail.com Mon Aug 27 19:02:12 2018 From: sam.carlberg at gmail.com (Sam Carlberg) Date: Mon, 27 Aug 2018 15:02:12 -0400 Subject: Why are there only platform-specific Maven artifacts? In-Reply-To: References: Message-ID: It would be moving the platform-independent classes (ie the public API) into the empty jars, leaving the platform-specific classes and binaries where they are in the platform JARs. The service loader mechanism seems suitable for tying the APi and platform modules together at runtime. I don't think module-info is suited for dependency management. It has no way to specify versions or platforms (or classifiers in general). Maven and Gradle will still need that information to be able to resolve artifacts. On Sun, Aug 26, 2018 at 10:05 AM Johan Vos wrote: > The platform-specific code is a general Java issue that needs to be solved > one day. Your suggestion basically comes down to moving the classfiles from > the platform-specific jars into the empty jars, right? > A problem with this is that currently, the jars are platform-dependent as > well (e.g. no OpenGL on win). > > Apart from that, your comments about libraries make sense: libraries don't > care about platforms. But I think this could be better fixed at the level > of the build tools (maven/gradle), combined with the module-info: if your > library depends on e.g. javafx.controls, it should be enough to have that > in your module-info.java. > > The current situation is an artificial semi-parallel dependency system, > where dependencies are added with classifiers in e.g. build.gradle or > pom.xml and without classifiers in module-info.java > > - Johan > > On Fri, Aug 24, 2018 at 11:34 PM Sam Carlberg > wrote: > >> As I see it, providing only platform-specific artifacts makes it difficult >> or impossible for third-party JavaFX libraries or frameworks to depend on >> the JavaFX API and pass it along to consumers. Libraries don't care about >> the platform-specific code - that's up the final application to determine >> - >> but are forced to arbitrarily choose one of the Windows, Mac, or Linux >> JARs >> anyway. I suppose they could use a compileOnly configuration, but that >> forces all downstream consumers to re-declare the JavaFX dependencies (and >> keep track of the dependencies of the library, too!) >> >> IMO it makes more sense to publish the general API classes into a >> classifier-less JAR (which are now the "empty JARs") and place the >> platform-specific classes and binaries in platform-specific artifacts with >> a different name. For example, JavaFX could have a "javafx-graphics" >> artifact for the platform-agnostic classes, and a `java-graphics-platform" >> for platform-specific code, with classifiers to specify the platform. This >> does run into the "empty JAR" issue again, but it'd be limited in scope to >> only the final application. >> >> -- >> Sam Carlberg >> > -- Sam Carlberg From kevin.rushforth at oracle.com Mon Aug 27 20:24:01 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 27 Aug 2018 13:24:01 -0700 Subject: Why are there only platform-specific Maven artifacts? In-Reply-To: References: Message-ID: What you suggest would not be possible without considerable refactoring of the modules with native code, since the Java module system does not allow modules to be split across jars. -- Kevin On 8/27/2018 12:02 PM, Sam Carlberg wrote: > It would be moving the platform-independent classes (ie the public API) > into the empty jars, leaving the platform-specific classes and binaries > where they are in the platform JARs. The service loader mechanism seems > suitable for tying the APi and platform modules together at runtime. > > I don't think module-info is suited for dependency management. It has no > way to specify versions or platforms (or classifiers in general). Maven and > Gradle will still need that information to be able to resolve artifacts. > > On Sun, Aug 26, 2018 at 10:05 AM Johan Vos wrote: > >> The platform-specific code is a general Java issue that needs to be solved >> one day. Your suggestion basically comes down to moving the classfiles from >> the platform-specific jars into the empty jars, right? >> A problem with this is that currently, the jars are platform-dependent as >> well (e.g. no OpenGL on win). >> >> Apart from that, your comments about libraries make sense: libraries don't >> care about platforms. But I think this could be better fixed at the level >> of the build tools (maven/gradle), combined with the module-info: if your >> library depends on e.g. javafx.controls, it should be enough to have that >> in your module-info.java. >> >> The current situation is an artificial semi-parallel dependency system, >> where dependencies are added with classifiers in e.g. build.gradle or >> pom.xml and without classifiers in module-info.java >> >> - Johan >> >> On Fri, Aug 24, 2018 at 11:34 PM Sam Carlberg >> wrote: >> >>> As I see it, providing only platform-specific artifacts makes it difficult >>> or impossible for third-party JavaFX libraries or frameworks to depend on >>> the JavaFX API and pass it along to consumers. Libraries don't care about >>> the platform-specific code - that's up the final application to determine >>> - >>> but are forced to arbitrarily choose one of the Windows, Mac, or Linux >>> JARs >>> anyway. I suppose they could use a compileOnly configuration, but that >>> forces all downstream consumers to re-declare the JavaFX dependencies (and >>> keep track of the dependencies of the library, too!) >>> >>> IMO it makes more sense to publish the general API classes into a >>> classifier-less JAR (which are now the "empty JARs") and place the >>> platform-specific classes and binaries in platform-specific artifacts with >>> a different name. For example, JavaFX could have a "javafx-graphics" >>> artifact for the platform-agnostic classes, and a `java-graphics-platform" >>> for platform-specific code, with classifiers to specify the platform. This >>> does run into the "empty JAR" issue again, but it'd be limited in scope to >>> only the final application. >>> >>> -- >>> Sam Carlberg >>> From joeri at lodgon.com Tue Aug 28 13:09:23 2018 From: joeri at lodgon.com (Joeri Sykora) Date: Tue, 28 Aug 2018 15:09:23 +0200 Subject: [RFR] 8210020: MAVEN_VERSION should use short release version for fcs builds Message-ID: Hi, please review the fix for JDK-8210020 available as a PR on Github: https://github.com/javafxports/openjdk-jfx/pull/177 https://bugs.openjdk.java.net/browse/JDK-8210020 Thanks, Joeri From kevin.rushforth at oracle.com Tue Aug 28 14:34:57 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 28 Aug 2018 07:34:57 -0700 Subject: [RFR] 8210020: MAVEN_VERSION should use short release version for fcs builds In-Reply-To: References: Message-ID: Since this is a P1 stopper, it is approved for openjfx11. I just pushed it. Thanks. -- Kevin On 8/28/2018 6:09 AM, Joeri Sykora wrote: > Hi, > > please review the fix for JDK-8210020 available as a PR on > Github: > > https://github.com/javafxports/openjdk-jfx/pull/177 > > https://bugs.openjdk.java.net/browse/JDK-8210020 > > Thanks, > Joeri From kevin.rushforth at oracle.com Tue Aug 28 21:12:41 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 28 Aug 2018 14:12:41 -0700 Subject: [12] RFR: 8209652: Ensemble: Update version of Lucene to 7.4.0 Message-ID: <2c0c9b65-2fdb-7e7a-7b44-25f381af9648@oracle.com> Phil, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8209652 http://cr.openjdk.java.net/~kcr/8209652/webrev/ This bumps the version of Apache Lucene used by Ensemble to the latest 7.4.0 release. -- Kevin From mnachev.nscenter.eu at gmail.com Tue Aug 28 21:41:13 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Wed, 29 Aug 2018 00:41:13 +0300 Subject: GUI code testing for JDK 10/11 - Keys, Mouse, TestNG, Maven, etc. Message-ID: Hi, What are the possible options for GUI code testing for JDK 10/11? I tried TestFX , but this project does not support JDK 10/11. Additionally, it does not support TestNG. I do not want to use JUnit, because it does not have the necessary functionality, such as ordered/sorted execution of the methods in each class. Regards, Miro. From mike.ennen at gmail.com Tue Aug 28 22:49:40 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Tue, 28 Aug 2018 15:49:40 -0700 Subject: GUI code testing for JDK 10/11 - Keys, Mouse, TestNG, Maven, etc. In-Reply-To: References: Message-ID: Hello, I am the current maintainer of TestFX and a (new) contributor to OpenJFX working on this exact area. TestFX does support Java 10. We are currently working on supporting Java 11, as can be seen here: https://github.com/TestFX/TestFX/pull/606. In JavaFX 11com.sun.glass.ui.Robot was moved to the public API as javafx.scene.robot.Robot so it is now easier to use the built-in Robot to test a JavaFX GUI application. TestFX offers some nice conveniences on top of the base Robot (namely, a nice way to target specific nodes in the scene graph and assert on their expected states). In summary, TestFX will soon support JavaFX 11. You can use the public API Robot if you do not wish to use TestFX. TestFX does not currently support TestNG - a contribution in that regard to TestFX would be great. You can see the sub-projects for Junit 4/5 are quite small: Although things are in a state of flux with regards to how the JUnit sub-projects work with respect to Jan Ortner's work in https://github.com/TestFX/TestFX/pull/615. Therefore if you were interested in contributing TestNG support to TestFX it would be advisable to base the work off of Jan Ortner's work in 615. Also, I should mention, that the basic robot functionality for Glass has been around since before Java 8 and could always be used, although it was a private API so any code written for it could break at any time. Now that it is part of the public API that is no longer a concern. I should also mention that it is possible to use the AWT Robot with JavaFX and bypass the JavaFX Robot entirely. Thanks, Michael Ennen On Tue, Aug 28, 2018 at 2:42 PM Miroslav Nachev < mnachev.nscenter.eu at gmail.com> wrote: > Hi, > > What are the possible options for GUI code testing for JDK 10/11? > > I tried TestFX , but this project does > not support JDK 10/11. Additionally, it does not support TestNG. I do not > want to use JUnit, because it does not have the necessary functionality, > such as ordered/sorted execution of the methods in each class. > > > Regards, > Miro. From johan.vos at gluonhq.com Wed Aug 29 08:28:30 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 29 Aug 2018 10:28:30 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: Hi Steve, This has been applied in 11-ea+24 which is now in maven central. Thanks, - Johan On Thu, Aug 9, 2018 at 3:32 PM Steve Hruda wrote: > Johan, > another temporary fix could be the META-INF attribute > "Automatic-Module-Name". E.g. set it at the empty jar to > javafx.controls.workaround > https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#main-attributes > > Regards, > Steve > > Am Sa., 14. Juli 2018 um 12:16 Uhr schrieb Steve Hruda < > steve.hruda at gmail.com>: > >> 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 >>>> >>> > > -- > Mit freundlichen Gr??en > Steve Hruda > From johan.vos at gluonhq.com Wed Aug 29 08:29:15 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 29 Aug 2018 10:29:15 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: Thanks, that worked perfect. ea-24 is available now. - Johan On Wed, Aug 22, 2018 at 3:03 PM Lennart B?rjeson wrote: > Sound reasonable, thank you. > > In the meantime (waiting for the next version of the maven artefacts) I've > updated my PR (https://github.com/johanvos/javafx11samples/pull/1) for > your javafx11samples with a build.gradle work-around to filter out the > empty javafx-jars. > > This makes your samples run with Java 11, gradle 4.9 and openjdx 11-ea+19. > > /Lennart > > > 22 aug. 2018 kl. 14:11 skrev Johan Vos : > > I spent some more time on this. > Adding the Automatic-Module-Name seems the easiest fix to me. I created a > PR at https://github.com/javafxports/openjdk-jfx/pull/162 for this. > > Having the platform-name hardcoded in the artifact Id would require > upfront magic in build.gradle or pom.xml to prevent the need to put a > platform hardcoded in the build.gradle or pom.xml. > Removing the empty jars never gives a result that works fine for both > maven and gradle, see > https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 > > In the end, the real fix for this should be in maven/gradle. We currently > need to specify dependencies in both the module-info.java as well as in the > pom.xml. That doesn't sound right. I would assume that the gradle Java > plugin should check if a dependency contains a module-info.class, and if > so, parse it and process it. > > - Johan > > > > On Thu, Aug 16, 2018 at 11:26 AM Lennart B?rjeson > wrote: > >> FWIW, I've fixed the Gradle builds in the current javafx11samples and >> sent you a pull request. >> >> I know these samples are only temporary, but I believe I'm not the only >> gradle user who's been frustrated by not having any working example to try >> out. >> >> My fix still uses the 11.0.0-SNAPSHOT builds and sets the classifier in >> the dependencies using Gradle's OPeratingSystem class. >> >> >> >> Best regards, >> >> /Lennart >> >> >> > From steve.hruda at gmail.com Wed Aug 29 09:48:24 2018 From: steve.hruda at gmail.com (Steve Hruda) Date: Wed, 29 Aug 2018 11:48:24 +0200 Subject: JavaFX 11 maven snapshots - empty jars In-Reply-To: References: <08aa21c3-bf6b-017f-acf1-c0cbd49886b9@oracle.com> Message-ID: Thanks Johan for the update. I will test it asap. Best Regards, Steve Am Mi., 29. Aug. 2018 um 10:28 Uhr schrieb Johan Vos : > Hi Steve, > > This has been applied in 11-ea+24 which is now in maven central. > > Thanks, > > - Johan > > On Thu, Aug 9, 2018 at 3:32 PM Steve Hruda wrote: > >> Johan, >> another temporary fix could be the META-INF attribute >> "Automatic-Module-Name". E.g. set it at the empty jar to >> javafx.controls.workaround >> https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#main-attributes >> >> Regards, >> Steve >> >> Am Sa., 14. Juli 2018 um 12:16 Uhr schrieb Steve Hruda < >> steve.hruda at gmail.com>: >> >>> 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 < >>>>> steve.hruda at gmail.com> >>>>> >> 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 >>>>> >>>> >> >> -- >> Mit freundlichen Gr??en >> Steve Hruda >> > -- Mit freundlichen Gr??en Steve Hruda From mnachev.nscenter.eu at gmail.com Wed Aug 29 15:55:39 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Wed, 29 Aug 2018 18:55:39 +0300 Subject: GUI code testing for JDK 10/11 - Keys, Mouse, TestNG, Maven, etc. In-Reply-To: References: Message-ID: Hi Mike, Thank you very much for the reply. It will be my pleasure to develop TestFX for TestNG. Yesterday I noticed, that the Robot in JDK11 is not working properly. After first use, it throws an exception. Also for JDK 8 and 10, TestFX does not work correctly or I do not know how to use it. The cursor is positioned in the wrong place, and so on. The examples that are given do not work. Can the problem be that I run the examples from NetBeans 9? Regards, Miro. On Wed, Aug 29, 2018 at 1:49 AM Michael Ennen wrote: > Hello, > > *I am the current maintainer of TestFX and a (new) contributor to OpenJFX > working* > *on this exact area. TestFX does support Java 10. We are currently working > on* > *supporting Java 11, as can be seen here: > https://github.com/TestFX/TestFX/pull/606 > .* > *In JavaFX 11com.sun.glass.ui.Robot was moved to the public API as* > *javafx.scene.robot.Robot so it is now easier to use the built-in Robot to > test a* > *JavaFX GUI application.* > > *TestFX offers some nice conveniences on top of the base Robot (namely,* > *a nice way to target specific nodes in the scene graph and assert on > their* > *expected states).* > > *In summary, TestFX will soon support JavaFX 11. You can use the public > API* > *Robot if you do not wish to use TestFX. TestFX does not currently support* > *TestNG - a contribution in that regard to TestFX would be great. You can > see* > > > *the sub-projects for Junit 4/5 are quite small:* > *Although things are in a state of flux with regards to how the JUnit > sub-projects* > *work with respect to Jan Ortner's work in > https://github.com/TestFX/TestFX/pull/615 > .* > *Therefore if you were interested in contributing TestNG support to TestFX > it would* > *be advisable to base the work off of Jan Ortner's work in 615.* > > *Also, I should mention, that the basic robot functionality for Glass has > been* > *around since before Java 8 and could always be used, although it was a > private* > *API so any code written for it could break at any time. Now that it is > part of the* > *public API that is no longer a concern.* > > *I should also mention that it is possible to use the AWT Robot with > JavaFX and* > *bypass the JavaFX Robot entirely.* > > Thanks, > Michael Ennen > > On Tue, Aug 28, 2018 at 2:42 PM Miroslav Nachev < > mnachev.nscenter.eu at gmail.com> wrote: > >> Hi, >> >> What are the possible options for GUI code testing for JDK 10/11? >> >> I tried TestFX , but this project does >> not support JDK 10/11. Additionally, it does not support TestNG. I do not >> want to use JUnit, because it does not have the necessary functionality, >> such as ordered/sorted execution of the methods in each class. >> >> >> Regards, >> Miro. > > From amnojeeuw at gmail.com Wed Aug 29 19:26:21 2018 From: amnojeeuw at gmail.com (Amno Jeeuw) Date: Wed, 29 Aug 2018 15:26:21 -0400 Subject: A good place to post questions Message-ID: Does anyone know of a place where I can ask questions for Java Beginners. I have some experience with C++, but I need help with Java/JavaFX. Thanks in advance *ArbolOne Using Fire Fox and Thunderbird. Developing for Android using Java, C/C++, HTM/CSS and JS as our platform has been exciting and most rewarding. [ S? ]* From nlisker at gmail.com Wed Aug 29 20:12:32 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 29 Aug 2018 23:12:32 +0300 Subject: A good place to post questions In-Reply-To: References: Message-ID: Reddit is a good place to start: https://www.reddit.com/r/javahelp/ On Wed, Aug 29, 2018 at 10:27 PM Amno Jeeuw wrote: > Does anyone know of a place where I can ask questions for Java Beginners. I > have some experience with C++, but I need help with Java/JavaFX. > Thanks in advance > > *ArbolOne > Using Fire Fox and Thunderbird. > Developing for Android using Java, C/C++, HTM/CSS and JS as our > platform has been exciting and most rewarding. > [ S? ]* > From mike.ennen at gmail.com Wed Aug 29 21:12:27 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 29 Aug 2018 14:12:27 -0700 Subject: GUI code testing for JDK 10/11 - Keys, Mouse, TestNG, Maven, etc. In-Reply-To: References: Message-ID: We need to release a new version of TestFX that should fix the cursor positioning issues. It may be more appropriate to continue this discussion on the TestFX issue tracker. Feel free to open an issue for TestNG support. Thanks, Michael Ennen On Wed, Aug 29, 2018 at 8:56 AM Miroslav Nachev < mnachev.nscenter.eu at gmail.com> wrote: > Hi Mike, > > Thank you very much for the reply. It will be my pleasure to develop > TestFX for TestNG. > > Yesterday I noticed, that the Robot in JDK11 is not working properly. > After first use, it throws an exception. > > Also for JDK 8 and 10, TestFX does not work correctly or I do not know how > to use it. The cursor is positioned in the wrong place, and so on. The > examples that are given do not work. Can the problem be that I run the > examples from NetBeans 9? > > > Regards, > Miro. > > On Wed, Aug 29, 2018 at 1:49 AM Michael Ennen > wrote: > >> Hello, >> >> *I am the current maintainer of TestFX and a (new) contributor to OpenJFX >> working* >> *on this exact area. TestFX does support Java 10. We are currently >> working on* >> *supporting Java 11, as can be seen here: >> https://github.com/TestFX/TestFX/pull/606 >> .* >> *In JavaFX 11com.sun.glass.ui.Robot was moved to the public API as* >> *javafx.scene.robot.Robot so it is now easier to use the built-in Robot >> to test a* >> *JavaFX GUI application.* >> >> *TestFX offers some nice conveniences on top of the base Robot (namely,* >> *a nice way to target specific nodes in the scene graph and assert on >> their* >> *expected states).* >> >> *In summary, TestFX will soon support JavaFX 11. You can use the public >> API* >> *Robot if you do not wish to use TestFX. TestFX does not currently >> support* >> *TestNG - a contribution in that regard to TestFX would be great. You can >> see* >> >> >> *the sub-projects for Junit 4/5 are quite small:* >> *Although things are in a state of flux with regards to how the JUnit >> sub-projects* >> *work with respect to Jan Ortner's work in >> https://github.com/TestFX/TestFX/pull/615 >> .* >> *Therefore if you were interested in contributing TestNG support to >> TestFX it would* >> *be advisable to base the work off of Jan Ortner's work in 615.* >> >> *Also, I should mention, that the basic robot functionality for Glass has >> been* >> *around since before Java 8 and could always be used, although it was a >> private* >> *API so any code written for it could break at any time. Now that it is >> part of the* >> *public API that is no longer a concern.* >> >> *I should also mention that it is possible to use the AWT Robot with >> JavaFX and* >> *bypass the JavaFX Robot entirely.* >> >> Thanks, >> Michael Ennen >> >> On Tue, Aug 28, 2018 at 2:42 PM Miroslav Nachev < >> mnachev.nscenter.eu at gmail.com> wrote: >> >>> Hi, >>> >>> What are the possible options for GUI code testing for JDK 10/11? >>> >>> I tried TestFX , but this project does >>> not support JDK 10/11. Additionally, it does not support TestNG. I do not >>> want to use JUnit, because it does not have the necessary functionality, >>> such as ordered/sorted execution of the methods in each class. >>> >>> >>> Regards, >>> Miro. >> >> From mike.ennen at gmail.com Wed Aug 29 22:43:37 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 29 Aug 2018 15:43:37 -0700 Subject: JDK-8090930: Add Support for Extended Mouse Buttons Message-ID: Hello All, I am working on JDK-8090930 which is a request to add support for the BACK/FORWARD mouse buttons that are supported by some mice. I have opened a proof-of-concept pull request on Github which can be found here: https://github.com/javafxports/openjdk-jfx/pull/173 This is still in the early stages (no CSR has been created yet, however there is a preliminary one in the comments on the above Github issue) but Kevin wanted me to post a notification to this list so that people can review and comment on it (and I think that's a good idea, too). Thanks, Michael Ennen From kevin.rushforth at oracle.com Thu Aug 30 16:40:35 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 30 Aug 2018 09:40:35 -0700 Subject: [8u] RFR: JDK-8201553: Update FX build to use gradle 4.8 Message-ID: <6a771c09-b5c2-1bf5-2e25-802bdd66772d@oracle.com> Phil & Arun, Please review the following backport request to update the version of gradle used to build FX 8u to gradle 4.8: https://bugs.openjdk.java.net/browse/JDK-8201553 http://cr.openjdk.java.net/~kcr/8201553/8u/webrev.00/ Details are in JBS. -- Kevin From nlisker at gmail.com Thu Aug 30 20:58:45 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 30 Aug 2018 23:58:45 +0300 Subject: Animation enhancements Message-ID: Hi All, Iv'e taken upon myself to handle most of the enhancement proposals for animations (I could fine). A list of all these can be found here [1]. Some of the proposals are more viable than others (I do not outright suggest that they all be implemented). For those of you who are interested in this area, I ask for you input on these (here or on the issues), or other related enhancements you'd like so we can gather enough public opinion and plan ahead. [1] https://bugs.openjdk.java.net/browse/JDK-8092408?jql=project%20%3D%20JDK%20AND%20issuetype%20%3D%20Enhancement%20AND%20component%20%3D%20javafx%20AND%20Subcomponent%20%3D%20animation%20AND%20assignee%20%3D%20nlisker Thanks, Nir From kevin.rushforth at oracle.com Fri Aug 31 00:05:56 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 30 Aug 2018 17:05:56 -0700 Subject: [12] RFR: JDK-8210219: GlassClipboard.cpp fails to compile with newer versions of VS2017 Message-ID: Please review the following: https://bugs.openjdk.java.net/browse/JDK-8210219 https://github.com/javafxports/openjdk-jfx/pull/185 The review is happening on GitHub. This bug is causing the GitHub AppVeyor builds to fail, since they upgraded to a newer version yesterday, but will affect anyone who installs a recent Visual Studio compiler. Details are in JBS and the GitHub PR. -- Kevin From arunprasad.rajkumar at oracle.com Fri Aug 31 09:32:51 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Fri, 31 Aug 2018 15:02:51 +0530 Subject: [RFR][8u-dev] JDK-8210216: Build of 8u-dev fails on 32-bit Linux after fix for JDK-8207159 Message-ID: Hi Kevin, Please review the fix for the bug JDK-8210216. Root cause and solution is updated in JBS. Thanks, Arun From dhruvi.vaza at ecosmob.com Fri Aug 31 13:53:48 2018 From: dhruvi.vaza at ecosmob.com (Dhruvi Vaza) Date: Fri, 31 Aug 2018 19:23:48 +0530 Subject: Javafx memory leak issue Message-ID: Hello, I am using javafx webview in my desktop application to load a url. I am opening webview on dialog. When I press a button to open a dialog containing webview. I get memory leak issue. sometimes it leads to crashing of application. Please give me proper solution. *The below code I have used:* public class HelpDialogController { @FXML private BorderPane helpDialogMainBorderPane; @FXML private WebView helpDialogWebView; public WebEngine webEngine; public static HelpDialogController instance; /** * Initializes the controller class. */ @FXML public void initialize() { // TODO instance = this; webEngine = helpDialogWebView.getEngine(); webEngine.load("https://csgpay.com/support?mobile_app=true"); webEngine.setJavaScriptEnabled(true); // Delete cookies java.net.CookieHandler.setDefault(new java.net.CookieManager()); } -- Thanks & Regards, Dhruvi Vaza Jr. Software Developer Ecosmob Technologies Pvt. Ltd. From mike at plan99.net Fri Aug 31 16:18:03 2018 From: mike at plan99.net (Mike Hearn) Date: Fri, 31 Aug 2018 09:18:03 -0700 Subject: Docs hosting for Java 11? Message-ID: As JavaFX is being removed in Java 11, presumably the docs that come with it won't be hosted by Oracle/openjdk.net anymore. And this is a problem because the way you get JavaFX and its tools will no longer be obvious to newcomers, who won't have read this list or know that it's on Maven. Are there any plans to take the existing set of docs here: https://docs.oracle.com/javase/8/javase-clienttechnologies.htm which despite not being updated for a while are still fine, and moving them to a new OpenJFX website somewhere? openjfx.org works but is sitting on a domain park page, and javafx.org is owned but doesn't resolve or load. From kevin.rushforth at oracle.com Fri Aug 31 16:28:03 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 31 Aug 2018 09:28:03 -0700 Subject: Docs hosting for Java 11? In-Reply-To: References: Message-ID: Hosting the FX 8 docs somewhere else wouldn't be useful. I presume you are asking whether the FX 11 docs could be hosted somewhere? We currently host the EA docs along with EA builds of OpenJFX 11 [1]. That will disappear at some point, although we will provide a link to the Project Download page [2], which in turn has a pointer to Gluon's JavaFX page [3]. That's where developers will go to get builds of JavaFX going forward. Gluon had been talking about hosting the docs somewhere (maybe on GitHub(, so perhaps Johan can comment. -- Kevin [1] http://jdk.java.net/openjfx/ [2] https://wiki.openjdk.java.net/display/OpenJFX/Download [3] https://gluonhq.com/products/javafx/ On 8/31/2018 9:18 AM, Mike Hearn wrote: > As JavaFX is being removed in Java 11, presumably the docs that come with > it won't be hosted by Oracle/openjdk.net anymore. > And this is a problem because the way you get JavaFX and its tools will no > longer be obvious to newcomers, who won't have read this list or know that > it's on Maven. > > Are there any plans to take the existing set of docs here: > > https://docs.oracle.com/javase/8/javase-clienttechnologies.htm > > which despite not being updated for a while are still fine, and moving them > to a new OpenJFX website somewhere? openjfx.org works but is sitting on a > domain park page, and javafx.org is owned but doesn't resolve or load. From mike at plan99.net Fri Aug 31 16:36:09 2018 From: mike at plan99.net (Mike Hearn) Date: Fri, 31 Aug 2018 12:36:09 -0400 Subject: Docs hosting for Java 11? In-Reply-To: References: Message-ID: I was actually referring to all the docs that *aren't* JavaDocs, like the tutorials, the CSS reference, the getting started guides, interop guides etc. As far as I know they haven't been updated since Java 8, however the API is backwards compatible so they are still useful learning materials. I am also not sure if they're open source licensed though. It would be a huge pity and a big drag on adoption if the community had to effectively produce an all new set of non-API docs _from scratch_. From kevin.rushforth at oracle.com Fri Aug 31 17:21:56 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 31 Aug 2018 10:21:56 -0700 Subject: Docs hosting for Java 11? In-Reply-To: References: Message-ID: <91a927cc-e374-2d53-337f-2020d1cbae7b@oracle.com> Ah, OK. As far as I know, the FX 8 non-API docs aren't going anywhere, but as you note they also aren't being updated. They are not under an open-source license. You would need to read the license to see what the terms of use are and whether that would meet your needs. -- Kevin On 8/31/2018 9:36 AM, Mike Hearn wrote: > I was actually referring to all the docs that *aren't* JavaDocs, like > the tutorials, the CSS reference, the getting started guides, interop > guides etc. > > As far as I know they haven't been updated since Java 8, however the > API is backwards compatible so they are still useful learning > materials. I am also not sure if they're open source licensed though. > > It would be a huge pity and a big drag on adoption if the community > had to effectively produce an all new set of non-API docs _from scratch_. > > From mike at plan99.net Fri Aug 31 18:51:19 2018 From: mike at plan99.net (Mike Hearn) Date: Fri, 31 Aug 2018 14:51:19 -0400 Subject: Docs hosting for Java 11? In-Reply-To: <91a927cc-e374-2d53-337f-2020d1cbae7b@oracle.com> References: <91a927cc-e374-2d53-337f-2020d1cbae7b@oracle.com> Message-ID: Well, I'm not thinking about my needs here - I've already learned the framework. I'm more wondering how people will learn and get the tools for JavaFX development in future. Up until Java 11 you could at least go to a single website, click on fairly obvious links, end up at the Java 8 docs for JavaFX and start learning. Post Java 11 .... where do users go? A wiki page? That seems rather hard to find. Given the Oracle has graciously open sourced so much of the Oracle JDK for OpenJDK, I wonder if there's any chance of the docs being open sourced too so they can be reformatted, refreshed and put onto a new website by the community? It seems a shame to let them bit-rot. On Fri, Aug 31, 2018 at 19:21:56, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > Ah, OK. As far as I know, the FX 8 non-API docs aren't going anywhere, but > as you note they also aren't being updated. > > They are not under an open-source license. You would need to read the > license to see what the terms of use are and whether that would meet your > needs. > > -- Kevin > > > On 8/31/2018 9:36 AM, Mike Hearn wrote: > > I was actually referring to all the docs that *aren't* JavaDocs, like the > tutorials, the CSS reference, the getting started guides, interop guides > etc. > > As far as I know they haven't been updated since Java 8, however the API > is backwards compatible so they are still useful learning materials. I am > also not sure if they're open source licensed though. > > It would be a huge pity and a big drag on adoption if the community had to > effectively produce an all new set of non-API docs _from scratch_. > > From kevin.rushforth at oracle.com Fri Aug 31 18:58:31 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 31 Aug 2018 11:58:31 -0700 Subject: Docs hosting for Java 11? In-Reply-To: References: <91a927cc-e374-2d53-337f-2020d1cbae7b@oracle.com> Message-ID: I can at least ask whether this would be possible. -- Kevin On 8/31/2018 11:51 AM, Mike Hearn wrote: > Well, I'm not thinking about my needs here - I've already learned the > framework. I'm more wondering how people will learn and get the tools > for JavaFX development in future. Up until Java 11 you could at least > go to a single website, click on fairly obvious links, end up at the > Java 8 docs for JavaFX and start learning. Post Java 11 .... where do > users go? A wiki page? That seems rather hard to find. > > Given the Oracle has graciously open sourced so much of the Oracle JDK > for OpenJDK, I wonder if there's any chance of the docs being open > sourced too so they can be reformatted, refreshed and put onto a new > website by the community? It seems a shame to let them bit-rot. > > > > On Fri, Aug 31, 2018 at 19:21:56, Kevin Rushforth > > wrote: > > Ah, OK. As far as I know, the FX 8 non-API docs aren't going > anywhere, but as you note they also aren't being updated. > > They are not under an open-source license. You would need to read > the license to see what the terms of use are and whether that > would meet your needs. > > -- Kevin > > > On 8/31/2018 9:36 AM, Mike Hearn wrote: >> I was actually referring to all the docs that *aren't* JavaDocs, >> like the tutorials, the CSS reference, the getting started >> guides, interop guides etc. >> >> As far as I know they haven't been updated since Java 8, however >> the API is backwards compatible so they are still useful learning >> materials. I am also not sure if they're open source licensed though. >> >> It would be a huge pity and a big drag on adoption if the >> community had to effectively produce an all new set of non-API >> docs _from scratch_. > > From mike at plan99.net Fri Aug 31 19:08:14 2018 From: mike at plan99.net (Mike Hearn) Date: Fri, 31 Aug 2018 15:08:14 -0400 Subject: Docs hosting for Java 11? In-Reply-To: References: <91a927cc-e374-2d53-337f-2020d1cbae7b@oracle.com> Message-ID: Thanks! From tom.schindl at bestsolution.at Fri Aug 31 21:41:28 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 31 Aug 2018 23:41:28 +0200 Subject: Docs hosting for Java 11? In-Reply-To: References: <91a927cc-e374-2d53-337f-2020d1cbae7b@oracle.com> Message-ID: <37028dd1-557b-96b2-361c-f7b47f118877@bestsolution.at> Well historically I think that some of those document fxml/css have been released under BSD. I know that because I needed that to ship e(fx)clipse. See http://cr.openjdk.java.net/~kcr/RT-34389/javafx-samples-8.0.0-ea/src/Ensemble8/cssref/cssref.html Tom On 31.08.18 20:58, Kevin Rushforth wrote: > I can at least ask whether this would be possible. > > -- Kevin > > > On 8/31/2018 11:51 AM, Mike Hearn wrote: >> Well, I'm not thinking about my needs here - I've already learned the >> framework. I'm more wondering how people will learn and get the tools >> for JavaFX development in future. Up until Java 11 you could at least >> go to a single website, click on fairly obvious links, end up at the >> Java 8 docs for JavaFX and start learning. Post Java 11 .... where do >> users go? A wiki page? That seems rather hard to find. >> >> Given the Oracle has graciously open sourced so much of the Oracle JDK >> for OpenJDK, I wonder if there's any chance of the docs being open >> sourced too so they can be reformatted, refreshed and put onto a new >> website by the community? It seems a shame to let them bit-rot. >> >> >> >> On Fri, Aug 31, 2018 at 19:21:56, Kevin Rushforth >> > wrote: >> >> ??? Ah, OK. As far as I know, the FX 8 non-API docs aren't going >> ??? anywhere, but as you note they also aren't being updated. >> >> ??? They are not under an open-source license. You would need to read >> ??? the license to see what the terms of use are and whether that >> ??? would meet your needs. >> >> ??? -- Kevin >> >> >> ??? On 8/31/2018 9:36 AM, Mike Hearn wrote: >>> ??? I was actually referring to all the docs that *aren't* JavaDocs, >>> ??? like the tutorials, the CSS reference, the getting started >>> ??? guides, interop guides etc. >>> >>> ??? As far as I know they haven't been updated since Java 8, however >>> ??? the API is backwards compatible so they are still useful learning >>> ??? materials. I am also not sure if they're open source licensed >>> though. >>> >>> ??? It would be a huge pity and a big drag on adoption if the >>> ??? community had to effectively produce an all new set of non-API >>> ??? docs _from scratch_. >> >> > -- 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 Fri Aug 31 21:58:40 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 31 Aug 2018 14:58:40 -0700 Subject: Docs hosting for Java 11? In-Reply-To: <37028dd1-557b-96b2-361c-f7b47f118877@bestsolution.at> References: <91a927cc-e374-2d53-337f-2020d1cbae7b@oracle.com> <37028dd1-557b-96b2-361c-f7b47f118877@bestsolution.at> Message-ID: <8441dc22-e1d8-0fd2-9e06-2ceb75d8fd2a@oracle.com> Right. One thing to also note is that the CSS ref and FXML ref are part of the API docs and are maintained. It's the tutorials that aren't. -- Kevin On 8/31/2018 2:41 PM, Tom Schindl wrote: > Well historically I think that some of those document fxml/css have been > released under BSD. I know that because I needed that to ship e(fx)clipse. > > See > http://cr.openjdk.java.net/~kcr/RT-34389/javafx-samples-8.0.0-ea/src/Ensemble8/cssref/cssref.html > > Tom > > On 31.08.18 20:58, Kevin Rushforth wrote: >> I can at least ask whether this would be possible. >> >> -- Kevin >> >> >> On 8/31/2018 11:51 AM, Mike Hearn wrote: >>> Well, I'm not thinking about my needs here - I've already learned the >>> framework. I'm more wondering how people will learn and get the tools >>> for JavaFX development in future. Up until Java 11 you could at least >>> go to a single website, click on fairly obvious links, end up at the >>> Java 8 docs for JavaFX and start learning. Post Java 11 .... where do >>> users go? A wiki page? That seems rather hard to find. >>> >>> Given the Oracle has graciously open sourced so much of the Oracle JDK >>> for OpenJDK, I wonder if there's any chance of the docs being open >>> sourced too so they can be reformatted, refreshed and put onto a new >>> website by the community? It seems a shame to let them bit-rot. >>> >>> >>> >>> On Fri, Aug 31, 2018 at 19:21:56, Kevin Rushforth >>> > wrote: >>> >>> ??? Ah, OK. As far as I know, the FX 8 non-API docs aren't going >>> ??? anywhere, but as you note they also aren't being updated. >>> >>> ??? They are not under an open-source license. You would need to read >>> ??? the license to see what the terms of use are and whether that >>> ??? would meet your needs. >>> >>> ??? -- Kevin >>> >>> >>> ??? On 8/31/2018 9:36 AM, Mike Hearn wrote: >>>> ??? I was actually referring to all the docs that *aren't* JavaDocs, >>>> ??? like the tutorials, the CSS reference, the getting started >>>> ??? guides, interop guides etc. >>>> >>>> ??? As far as I know they haven't been updated since Java 8, however >>>> ??? the API is backwards compatible so they are still useful learning >>>> ??? materials. I am also not sure if they're open source licensed >>>> though. >>>> >>>> ??? It would be a huge pity and a big drag on adoption if the >>>> ??? community had to effectively produce an all new set of non-API >>>> ??? docs _from scratch_. >>>