From john at status6.com Mon Feb 4 21:09:20 2019 From: john at status6.com (John Neffenger) Date: Mon, 4 Feb 2019 13:09:20 -0800 Subject: RFR: 8217605: Add support for e-paper displays Message-ID: Please review the changes for "Add support for e-paper displays." https://bugs.openjdk.java.net/browse/JDK-8217605 https://github.com/javafxports/openjdk-jfx/pull/369 The "18 changed files with 3,622 additions and 2 deletions" reported by GitHub breaks down into the following actual lines of code (as measured by "cloc"): 1,014 Java source code 287 Java unit test code 405 C source code 120 C header file ----- 1,826 total lines of code Only two existing files were modified. I added nine lines in "armv6hf.gradle" to include the Monocle EPD Platform in the build, and one line in "addExports" to allow the new unit test programs to run. buildSrc/armv6hf.gradle modules/javafx.graphics/src/test/addExports I'll make some videos of my JavaFX test application to demonstrate the features of the new platform. Thank you, John From johan.vos at gluonhq.com Tue Feb 5 08:20:48 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 5 Feb 2019 09:20:48 +0100 Subject: OpenJFX 12 is in Rampdown Phase Two (RDP2) Message-ID: To: OpenJFX Developers As a reminder, OpenJFX 12 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 to openjfx/12-dev. We will use the same rules for RDP2 that the JDK uses [2], with three modifications: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 12 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx12-fix-request", "openjfx12-fix-yes", "openjfx12-fix-no" and "openjfx12-fix-nmi", "openjfx12-enhancement-request", "openjfx12-enhancement-yes", "openjfx12-enhancement-no" and "openjfx12-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 openjfx13 at this point. I do not expect many P3 bugs to be approved. Note that if a fix is approved to push to 12-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 12-dev --> jfx-dev for the duration of the openjfx12 release. Now that we are in RDP2, the goal is to stabilize what is there, with priority on fixing bugs that are new in openjfx12. We need to be extremely careful about including anything that introduces risk. Let us know if there are any questions. -- Kevin & Johan [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-October/022761.html [2] http://openjdk.java.net/jeps/3 From johan.vos at gluonhq.com Tue Feb 5 11:48:25 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 5 Feb 2019 12:48:25 +0100 Subject: external mousewheel slow scrolling Message-ID: Hi Phil, The fix for JDK-8183399 [1] introduced a new issue: if an external mouse with a real mousewheel is used for scrolling, the new scrollvalues are a factor 10 too low. I created a new bug for this (JDK-8218424) [2] and Jose created a PR to fix this [3]. I'll review that PR shortly. Can you also review this PR? Thanks, - Johan [1] https://bugs.openjdk.java.net/browse/JDK-8183399 [2] https://bugs.openjdk.java.net/browse/JDK-8218424 [3] https://github.com/javafxports/openjdk-jfx/pull/371 From arunprasad.rajkumar at oracle.com Fri Feb 8 07:58:47 2019 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Fri, 8 Feb 2019 13:28:47 +0530 Subject: RFR JDK-8218611: [DRT] fast/xslt tests fails with Unsupported encoding windows-1251 Message-ID: <13B0CA40-9AF2-4D65-83E9-C1973ABA742E@oracle.com> Hi, Please review the following PR, https://github.com/javafxports/openjdk-jfx/pull/373 JBS: https://bugs.openjdk.java.net/browse/JDK-8218611 Thanks, Arun From info at michaelhoffer.de Fri Feb 8 21:26:13 2019 From: info at michaelhoffer.de (Michael Hoffer) Date: Fri, 8 Feb 2019 22:26:13 +0100 Subject: How are library developers supposed to specify JavaFX dependencies (on JFX/JDK >= 11)? Message-ID: <2605B1C1-94D7-4B1E-9004-DAEAD3A7F572@michaelhoffer.de> Hi, first of all, thanks for moving JavaFX forward. I just tried to migrate some of my JavaFX libraries from JDK 8 to 11. The migration story is already great for application developers. Well done. However, the documentation seems to lack significant information for library developers. I ran into the following problem: How do I declare platform independent dependencies as a library developer? Currently, I am forced to specify the platform dependent version in my build script (be it explicit via `$platform` or implicit via the new JavaFX Gradle plugin). Am I right, that there's no real platform independent jar file + platform dependent jar? I only see merged jars where platform dependent Java code + platform dependent natives are mixed with platform independent Java code. But that would mean that a user of my library would need to specify the JavaFX dependencies in his/her project. But how do users know which platform-dependent modules to declare as dependency? That?s something we usually expect Maven/Gradle to handle for us. TL;DR: - What is the intended way for declaring JavaFX dependencies for third party JavaFX libraries (NOT apps) for JDK >=11 - What?s the reason for not splitting the dependencies into platform dependent and platform independent parts as it is done by other Java libraries? Thanks, Michael -- Dr. Michael Hoffer Web: mihosoft.eu Twitter: @mihosoft Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) Goethe-Universit?t Kettenhofweg 139 60325 Frankfurt am Main phone: +49 69 798 25254 info at michaelhoffer.de From nlisker at gmail.com Sat Feb 9 08:23:02 2019 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 9 Feb 2019 10:23:02 +0200 Subject: Two bugs in JFXPanel (OpenJFX 11.01) In-Reply-To: <000a01d4b4a1$8a4af6d0$9ee0e470$@gmail.com> References: <000a01d4b4a1$8a4af6d0$9ee0e470$@gmail.com> Message-ID: Hi Thimo, It looks like Kevin replied to you on GitHub with how to proceed. Is something unclear? - Nir On Fri, Feb 8, 2019 at 11:29 PM Thimo von Rauchhaupt < t.rauchhaupt at googlemail.com> wrote: > Hi everyone, > > > > I am quite unsure if I made everything right. So if not, please tell me how > to contribute the project with bugreports / -fixes. > > > > I found two bugs in the JFXPanel and filed issues at the github javafxports > page: > > https://github.com/javafxports/openjdk-jfx/issues/356 - Single click > becomes > double click under raceconditions if focus must be gained > > https://github.com/javafxports/openjdk-jfx/issues/359 - Unnecessary Up and > Downscaling in multi monitor environments. > > > > Best regards, > > Thimo > > > > > > From johan.vos at gluonhq.com Sun Feb 10 15:16:10 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 10 Feb 2019 16:16:10 +0100 Subject: How are library developers supposed to specify JavaFX dependencies (on JFX/JDK >= 11)? In-Reply-To: <2605B1C1-94D7-4B1E-9004-DAEAD3A7F572@michaelhoffer.de> References: <2605B1C1-94D7-4B1E-9004-DAEAD3A7F572@michaelhoffer.de> Message-ID: Hi Michael, You have to make a clear distinction between modules and jars. Libraries should be one or more modules, and their dependencies should be declared in a module-info.java There are no platform-dependent modules in JavaFX. If your library depends on javafx.graphics, you declare that in your module-info.java. You don't declare any platform-specific things in the module-info.java. As such, the "module" concept is close to the WORA concept of Java. As a library developer, you leverage the public API's exposed by the JavaFX modules. Those API's are platform-independent and well documented. Nice and clean. The jar-question is something completely different. Ideally, tools (mvn/gradle) should be able to work well with modules, and integrate platform-specific requests (e.g. I'm on linux, my project depends on module fxyz, which depends on javafx.graphics, now download the required jars and put them on the modulepath). Unfortunately, we're not there yet. We are in the awkward situation where you have to duplicate dependencies from your module-info.java into jar dependencies a pom.xml. Since the JavaFX modules *contain* (not expose!) platform-specific code (cleanly hidden from the end-user though, via the module concept), this leads to the ugly situation where you have platform-specific jars in a pom.xml. Maven deals with it pretty well, since it works well with the classifier concept. If you publish your library, you need to make sure you do not add a classifier to the jar dependencies you put in a pom.xml. Your library does not depend on a specific platform jar -- this is something that is dealt with by the end-project. The single most important thing is that you get your module dependencies right. The second thing is that for now, you need to duplicate work by providing similar dependencies in a pom.xml, and those should not have a classifier. As for splitting the jars between a platform-specific jar and a generic jar, I don't see a need for this. Libraries should write code against a module, not against a jar. - Johan On Fri, Feb 8, 2019 at 11:57 PM Michael Hoffer wrote: > Hi, > > first of all, thanks for moving JavaFX forward. I just tried to migrate > some of my JavaFX libraries from JDK 8 to 11. The migration story is > already great for application developers. Well done. However, the > documentation seems to lack significant information for library developers. > I ran into the following problem: > > How do I declare platform independent dependencies as a library developer? > Currently, I am forced to specify the platform dependent version in my > build script (be it explicit via `$platform` or implicit via the new JavaFX > Gradle plugin). Am I right, that there's no real platform independent jar > file + platform dependent jar? I only see merged jars where platform > dependent Java code + platform dependent natives are mixed with platform > independent Java code. > > But that would mean that a user of my library would need to specify the > JavaFX dependencies in his/her project. But how do users know which > platform-dependent modules to declare as dependency? That?s something we > usually expect Maven/Gradle to handle for us. > > TL;DR: > > - What is the intended way for declaring JavaFX dependencies for third > party JavaFX libraries (NOT apps) for JDK >=11 > - What?s the reason for not splitting the dependencies into platform > dependent and platform independent parts as it is done by other Java > libraries? > > Thanks, > Michael > > -- > Dr. Michael Hoffer > > Web: mihosoft.eu > Twitter: @mihosoft > > Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) > Goethe-Universit?t > Kettenhofweg 139 > 60325 Frankfurt am Main > phone: +49 69 798 25254 <+49%2069%2079825254> > info at michaelhoffer.de From john at status6.com Tue Feb 12 01:23:16 2019 From: john at status6.com (John Neffenger) Date: Mon, 11 Feb 2019 17:23:16 -0800 Subject: New unit tests 12 times slower under Gradle Message-ID: <2efeb9a8-1e93-27c9-beb1-bf0c5bf0f029@status6.com> I have four new JavaFX Graphics unit tests that copy bytes from a byte buffer to another byte buffer or write them to a byte channel [1]. They take less than 3 seconds to run under Ant, whether within NetBeans or from the command line. Those same tests take 34 seconds to run in the JavaFX Gradle build, with or without the Gradle daemon, running on the same hardware in the same Ubuntu LXD container and with the same OpenJDK version 11.0.2. When compiling, Ant passes "-g" while the Gradle build passes "-g:source,lines,vars" for the debugging information. Both Ant and Gradle pass the "-ea" option for the Java runtime to enable assertions. I added statements to measure the timing of each test, and it appears they're executing more slowly within the test methods themselves: $ ~/bin/ant.sh test [junit] Testsuite: test.com.sun.glass.ui.monocle.FramebufferY8Test [junit] FramebufferY8Test.onlyOnce: 2,212 ms [junit] FramebufferY8Test.writeTo16: 258 ms [junit] FramebufferY8Test.writeTo32: 105 ms [junit] FramebufferY8Test.copyto16: 142 ms [junit] FramebufferY8Test.copyto32: 34 ms [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.839 sec $ gradle --info :graphics:test test.com.sun.glass.ui.monocle.FramebufferY8Test STANDARD_OUT FramebufferY8Test.onlyOnce: 2,290 ms test.com.sun.glass.ui.monocle.FramebufferY8Test > copyTo16 STANDARD_OUT FramebufferY8Test.copyto16: 5,586 ms test.com.sun.glass.ui.monocle.FramebufferY8Test > copyTo32 STANDARD_OUT FramebufferY8Test.copyto32: 10,763 ms test.com.sun.glass.ui.monocle.FramebufferY8Test > writeTo16 STANDARD_OUT FramebufferY8Test.writeTo16: 5,376 ms test.com.sun.glass.ui.monocle.FramebufferY8Test > writeTo32 STANDARD_OUT FramebufferY8Test.writeTo32: 10,608 ms If I run Gradle with "--debug", I see extra "memory status events" that I don't see in other tests. Below is the "copyTo32" test, for example, which takes only 34 milliseconds for Ant but over 10 seconds for Gradle: 16:01:54.832 [DEBUG] [TestEventLogger] test.com.sun.glass.ui.monocle.FramebufferY8Test > copyTo32 STARTED 16:01:59.293 [LIFECYCLE] [org.gradle.process.internal.health.memory.MemoryManager] 16:01:59.293 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 16705933312, Free: 14666444800} 16:01:59.293 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 4177526784, Committed: 314572800} 16:01:59.840 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 4177526784, Committed: 330301440} 16:02:04.294 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 16705933312, Free: 14666657792} 16:02:04.294 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 4177526784, Committed: 314572800} 16:02:04.840 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 4177526784, Committed: 330301440} 16:01:54.850 [LIFECYCLE] [org.gradle.internal.operations.DefaultBuildOperationExecutor] 16:01:54.850 [LIFECYCLE] [org.gradle.internal.operations.DefaultBuildOperationExecutor] > Task :graphics:test 16:02:05.229 [DEBUG] [TestEventLogger] 16:02:05.229 [DEBUG] [TestEventLogger] test.com.sun.glass.ui.monocle.FramebufferY8Test > copyTo32 STANDARD_OUT 16:02:05.229 [DEBUG] [TestEventLogger] FramebufferY8Test.copyto32: 10,397 ms 16:02:05.229 [DEBUG] [TestEventLogger] 16:02:05.229 [DEBUG] [TestEventLogger] test.com.sun.glass.ui.monocle.FramebufferY8Test > copyTo32 PASSED I would appreciate any suggestions for what I might try next. Thank you, John [1] https://github.com/javafxports/openjdk-jfx/blob/7a64f767fae875b154d36a4817ef1e25625c3143/modules/javafx.graphics/src/test/java/test/com/sun/glass/ui/monocle/FramebufferY8Test.java From john at status6.com Tue Feb 12 19:25:34 2019 From: john at status6.com (John Neffenger) Date: Tue, 12 Feb 2019 11:25:34 -0800 Subject: New unit tests 12 times slower under Gradle (solved) In-Reply-To: <2efeb9a8-1e93-27c9-beb1-bf0c5bf0f029@status6.com> References: <2efeb9a8-1e93-27c9-beb1-bf0c5bf0f029@status6.com> Message-ID: I figured it out. It's the old version of JUnit that we're using. Although we're building OpenJFX with Gradle 4.8, which bundles JUnit 4.12, our "build.gradle" file specifies the older JUnit 4.8.2 (which is downloaded, along with Hamcrest 1.1, into the Gradle cache under "~/.gradle/caches"). And JUnit 4.8.2 is more than 57 times slower than JUnit 4.12 when comparing primitive arrays! The change that makes it so much faster is the call to "Arrays.deepEquals", not found in the older version: public abstract class ComparisonCriteria { public void arrayEquals(String message, Object expecteds, Object actuals) throws ArrayComparisonFailure { if (expecteds == actuals || Arrays.deepEquals( new Object[] {expecteds}, new Object[] {actuals})) { // The reflection-based loop below is potentially very slow, // especially for primitive arrays. The deepEquals check // allows us to circumvent it in the usual case where the // arrays are exactly equal. return; } ... } ... } Mystery solved! Can we upgrade to JUnit 4.12 (and Hamcrest 1.3) in the build? John From kevin.rushforth at oracle.com Tue Feb 12 19:48:09 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 12 Feb 2019 11:48:09 -0800 Subject: New unit tests 12 times slower under Gradle (solved) In-Reply-To: References: <2efeb9a8-1e93-27c9-beb1-bf0c5bf0f029@status6.com> Message-ID: <9dfc2302-ba18-36c2-9a77-323eecfbee20@oracle.com> Hi John, > Mystery solved! Can we upgrade to JUnit 4.12 (and Hamcrest 1.3) in the build? Yes, we can likely do this for openjfx13. As with any update to third-party code (or any new third-party code), we will need legal approval, which I can do. On a somewhat-related topic, we will likely upgrade to gradle 5.x in this time frame as well. -- Kevin On 2/12/2019 11:25 AM, John Neffenger wrote: > I figured it out. It's the old version of JUnit that we're using. > > Although we're building OpenJFX with Gradle 4.8, which bundles JUnit > 4.12, our "build.gradle" file specifies the older JUnit 4.8.2 (which > is downloaded, along with Hamcrest 1.1, into the Gradle cache under > "~/.gradle/caches"). > > And JUnit 4.8.2 is more than 57 times slower than JUnit 4.12 when > comparing primitive arrays! > > The change that makes it so much faster is the call to > "Arrays.deepEquals", not found in the older version: > > public abstract class ComparisonCriteria { > ??? public void arrayEquals(String message, > ??????????? Object expecteds, Object actuals) > ??????????? throws ArrayComparisonFailure { > ??????? if (expecteds == actuals > ??????????? || Arrays.deepEquals( > ??????????????? new Object[] {expecteds}, new Object[] {actuals})) { > ??????????? // The reflection-based loop below is potentially very slow, > ??????????? // especially for primitive arrays. The deepEquals check > ??????????? // allows us to circumvent it in the usual case where the > ??????????? // arrays are exactly equal. > ??????????? return; > ??????? } > ??????? ... > ??? } > ??? ... > } > > Mystery solved! Can we upgrade to JUnit 4.12 (and Hamcrest 1.3) in the > build? > > John From nlisker at gmail.com Wed Feb 13 13:56:37 2019 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 13 Feb 2019 15:56:37 +0200 Subject: Review Request: JDK-8211014: Fix mistakes in FX API docs Message-ID: Hi, Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8211014 http://cr.openjdk.java.net/~nlisker/8211014/webrev.00/ Thanks, Nir From kevin.rushforth at oracle.com Thu Feb 14 22:57:10 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Feb 2019 14:57:10 -0800 Subject: [13] RFR: JDK-8218174: Add missing license file for Mesa header files Message-ID: <7a94aa70-cd29-ae4d-6d7c-9d9dd483c3ae@oracle.com> Phil, Please review the following simple fix to add a missing *.md file for the Mesa3D header files: https://bugs.openjdk.java.net/browse/JDK-8218174 http://cr.openjdk.java.net/~kcr/8218174/webrev/ -- Kevin From kevin.rushforth at oracle.com Thu Feb 14 23:00:23 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Feb 2019 15:00:23 -0800 Subject: [13] RFR: JDK-8219008: Update OpenGL Headers to version 4.6 Message-ID: Please review the following on Github to update the version of the Khronos OpenGL header files to GL 4.6. Details are in the PR. https://bugs.openjdk.java.net/browse/JDK-8219008 https://github.com/javafxports/openjdk-jfx/pull/378 -- Kevin From mike.ennen at gmail.com Fri Feb 15 22:38:03 2019 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 15 Feb 2019 15:38:03 -0700 Subject: [13] RFR: JDK-8218170: Upgrade antlr to version 4.7.2 Message-ID: Please review the following on Github to update the version of antlr to 4.7.2. Details are in the PR. https://bugs.openjdk.java.net/browse/JDK-8218170 https://github.com/javafxports/openjdk-jfx/pull/372 -- Michael Ennen From arunprasad.rajkumar at oracle.com Sat Feb 16 17:43:34 2019 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Sat, 16 Feb 2019 23:13:34 +0530 Subject: [RFR] JDK-8215775: Scrollbars from web pages appear to be absolute, overlapping everything Message-ID: Hi, Please review the following PR, https://github.com/javafxports/openjdk-jfx/pull/349 https://bugs.openjdk.java.net/browse/JDK-8215775 Thanks, Arun From donlaiq at gmail.com Mon Feb 18 20:38:37 2019 From: donlaiq at gmail.com (Don Laiquit) Date: Mon, 18 Feb 2019 17:38:37 -0300 Subject: Crypto FX Wallet 0.0.2 Message-ID: Hello everyone, I have released an update of the crypto wallet based on JavaFX 11. https://github.com/donlaiq/cryptofxwallet Here it's a link to learn about how to use it: https://www.youtube.com/watch?v=3amZLwUk7C4 I hope you have time to review it and, eventually, to help me to do it better. Thanks. Don. From abhinay_agarwal at live.com Tue Feb 19 16:23:57 2019 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Tue, 19 Feb 2019 16:23:57 +0000 Subject: EventDispatcher for a EventTarget Message-ID: Hi, I have been using "com.sun.javafx.event.EventHandlerManger" for adding/setting event handlers to an EventTarget (including all Nodes). With JavaFX 9, this class wasn't move to the public API and in every project where I need add/set a custom handler for an event on an EventTarget, I have to create my own EventDispatcher. EventHandlerManger already a basic implementation of a dispatcher and it would make it super easy if it were a public API. Is there a reason why it wasn't made public? Does an alternative exists? Thanks and regards, Abhinay From arunprasad.rajkumar at oracle.com Wed Feb 20 11:06:34 2019 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 20 Feb 2019 16:36:34 +0530 Subject: [RFR] 8211308: Support HTTP/2 in WebView Message-ID: Hi, Please review the following Github PR which uses new HttpClient interface (introduced since JDK11[1]) to support HTTP/2. https://github.com/javafxports/openjdk-jfx/pull/247 https://bugs.openjdk.java.net/browse/JDK-8211308 Note: There is a runtime property ?com.sun.webkit.useHTTP2Loader" added to switch back to legacy interface. By default it is enabled to use new HttpClient interface. [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/package-summary.html Thanks, Arun From nicolas.therrien at motorolasolutions.com Wed Feb 20 18:55:49 2019 From: nicolas.therrien at motorolasolutions.com (Nicolas Therrien) Date: Wed, 20 Feb 2019 13:55:49 -0500 Subject: Distributing JavaFX 11 Application Message-ID: Hi! What is the proper way to create distributable packages of a JavaFx Application? I have a Java 11 application which I build as a module. The distribution includes a "modules" folder with all dependencies in it, and a script to launch the module. This assembly works if I build it on the same machine as I am going to be running it on. However, I realized that depending on which build agent the assembly is going to be created, the platform specific javafx dependencies may not match the target assembly. For example, if the build agent is a linux build agent, the windows and mac assembly contains linux javafx runtime. Maven will always pull the platform-specific libraries of the system it is running on. This was not a problem when JavaFx was part of the JDK since the correct runtime libraries were installed on the system already. What is the correct way to create a windows or linux package in a build platform independent way? I found an article which showed how to force maven to include all platforms as dependencies, but then I have to add dependency on each transitive library. Sounds like a lot of trouble for a simple task. How do you guys package your apps for various platforms? *Nicolas Therrien* Senior Software Developer *[image: https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]* *o*: +1.819.931.2053 From sverre.moe at gmail.com Wed Feb 20 19:49:57 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 20 Feb 2019 20:49:57 +0100 Subject: Distributing JavaFX 11 Application In-Reply-To: References: Message-ID: You could use the new jpackage to create a native runtime of your application. The jpackager is now targeted for JDK 13, but can still be used to create a native Java 11 application. You can download an EA build of JDK 13 with jpackage http://jdk.java.net/jpackage/ You would need to build on each platform, Linux, Windows, Mac. You mentioned you use Maven. When Java 9 came out I had already moved over to Gradle, so not familiar with the maven configuration. Here is a Gradle task to create a Java 11 runtime using jlink with the Java 11 jmods task createRuntime(type: Exec) { dependsOn installDist inputs.dir(installDist.outputs.files.singleFile) outputs.dir("${buildDir}/runtime") doFirst { delete "${buildDir}/runtime" } def libDir = new File(installDist.outputs.files.singleFile, "lib").path commandLine '/usr/java/jdk-11/bin/jlink', '--module-path', "/usr/java/jdk-11/jmods:${libDir}", '--add-modules', 'eu.yourmodule.application', '--output', "${buildDir}/runtime" } You then use this runtime with jpackage to create a native application image or installer. task createPackage(type: Exec) { dependsOn createRuntime commandLine '/usr/java/jdk-13/bin/jpackage', 'create-installer', '--verbose', '--force', '--name', project.name, '--app-version', project.version, '--module', "${mainClassName}", '--resource-dir', "${buildDir}/package", '--runtime-image', "${buildDir}/runtime", '--output', "${buildDir}/native" } /Sverre Den ons. 20. feb. 2019 kl. 19:57 skrev Nicolas Therrien < nicolas.therrien at motorolasolutions.com>: > Hi! > > What is the proper way to create distributable packages of a JavaFx > Application? > > I have a Java 11 application which I build as a module. The distribution > includes a "modules" folder with all dependencies in it, and a script to > launch the module. > > This assembly works if I build it on the same machine as I am going to be > running it on. However, I realized that depending on which build agent the > assembly is going to be created, the platform specific javafx dependencies > may not match the target assembly. For example, if the build agent is a > linux build agent, the windows and mac assembly contains linux javafx > runtime. > > Maven will always pull the platform-specific libraries of the system it is > running on. > > This was not a problem when JavaFx was part of the JDK since the correct > runtime libraries were installed on the system already. > > What is the correct way to create a windows or linux package in a build > platform independent way? > > I found an article which showed how to force maven to include all platforms > as dependencies, but then I have to add dependency on each transitive > library. Sounds like a lot of trouble for a simple task. > > How do you guys package your apps for various platforms? > > *Nicolas Therrien* > > Senior Software Developer > > *[image: > > https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]* > > *o*: +1.819.931.2053 > From augustnagro at gmail.com Fri Feb 22 05:46:02 2019 From: augustnagro at gmail.com (August Nagro) Date: Thu, 21 Feb 2019 23:46:02 -0600 Subject: javafx.base requires java.desktop Message-ID: I noticed that the javafx base module requires java.desktop, and therefore all of swing. Is this dependency really required for this package (or any javafx module other than the swing adapter)? - August From johan.vos at gluonhq.com Fri Feb 22 12:31:49 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 22 Feb 2019 13:31:49 +0100 Subject: properties for Prism and Glass Message-ID: Both Prism and Glass provide a top-level API and rely on specific implementations. On desktop, the specific implementations do not require properties to be set, as the defaults are obtained from properties like " os.name" etc. However, they can be overruled. On embedded, it is more likely that users have to specify the properties. For example, on the Raspberry Pi one would typically use -Dembedded=monocle -Dglass.platform=Monocle (note the lowercase monocle versus Monocle) Currently, there are inconsistencies in how the properties for Glass and Prism are obtained. Prism: the base class for determining properties is com.sun.javafx.PlatformUtil, in the javafx.base module. A property named "embeddedType" is used to determine which native library to load (e.g. prism_es2_monocle) and to determine which GLFactory has to be used (e.g. com.sun.prism.es2.X11GLFactory). Glass: the base class for determining properties is com.sun.glass.ui.Platform, in the javafx.graphics module. The return value of determinePlatform() (which can be macosx, windows, linux, gtk, ios or anything user-specified defined via a property named "glass.platform" e.g. Monocle) is used to determine which class implements the PlatformFactory (e.g. com.sun.glass.ui.monocle.MonoclePlatformFactory). While Glass and Prism are clearly 2 different things, I think the properties that ultimately decides which factories and native libs to be loaded could belong in the same module (instead of javafx.base AND javafx.graphics) Further, I think it would be good to be more consistent in the naming and use for example "prism.platform" . Thoughts, - Johan From kevin.rushforth at oracle.com Fri Feb 22 14:05:16 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 22 Feb 2019 06:05:16 -0800 Subject: javafx.base requires java.desktop In-Reply-To: References: Message-ID: <1ee25980-4a96-6a1e-bf8f-dc8965de1a63@oracle.com> There are two dependencies that would be nice to get rid of in the future, but both will require work. 1) javafx.base requires java.desktop This is to support the JavaBeans adapter classes. We could change this to be an optional dependency since they aren't needed unless an application uses them in which case the app would have loaded java.desktop. I suspect that this would be a fairly small effort. 2) javafx.graphics requires java.desktop The main reason for this is the implementation of printing, which uses Java2D printing under the covers. Replacing the existing JavaFX printing implementation with a native one would be a large effort. -- Kevin On 2/21/2019 9:46 PM, August Nagro wrote: > I noticed that the javafx base module requires java.desktop, and therefore > all of swing. Is this dependency really required for this package (or any > javafx module other than the swing adapter)? > > - August From pyokagan at gmail.com Fri Feb 22 10:54:53 2019 From: pyokagan at gmail.com (Paul Tan) Date: Fri, 22 Feb 2019 18:54:53 +0800 Subject: [13] RFR: JDK-8201539: WICCreateImagingFactory: defer CoUninitialize() call to thread exit Message-ID: Please review the following PR on GitHub which fixes a crash that occurs when JavaFX is used with Monocle's headless platform (used in TestFX's headless mode). https://github.com/javafxports/openjdk-jfx/pull/367 https://bugs.openjdk.java.net/browse/JDK-8201539 Regards, Paul From nicolas.therrien at motorolasolutions.com Tue Feb 26 01:17:25 2019 From: nicolas.therrien at motorolasolutions.com (Nicolas Therrien) Date: Mon, 25 Feb 2019 20:17:25 -0500 Subject: Distributing JavaFX 11 Application In-Reply-To: References: Message-ID: Hi! Thanks Sverre for your response and help in this matter! I am learning more about Jpackage. However, the need to build on each OS platform to produce installers is a drawback from our previous Java 8 packages and I was asked to find another solution. The good news is that I have managed to find a way to build multi-platform Java 11 packages on any OS platform. I wanted to share that knowledge back with the group. The project dependencies are set as usual: org.openjfx javafx-controls 11.0.2 org.openjfx javafx-fxml 11.0.2 Then the project uses simple launch scripts like this: windows: start javaw -Dfile.encoding=UTF-8 --module-path modules --module modulename/class.package.Main linux: java -Dfile.encoding=UTF-8 --module-path modules --module modulename/class.package.Main These commands expect the proper jar files to be in the directory named "modules". The project uses Maven's copy dependencies like this: org.apache.maven.plugins maven-dependency-plugin copy-dependencies prepare-package copy-dependencies ${project.build.directory}/staging/modules runtime linux,win copy-linux-dependencies prepare-package copy-dependencies ${project.build.directory}/staging-linux-specific/modules runtime linux copy-windows-dependencies prepare-package copy-dependencies ${project.build.directory}/staging-windows-specific/modules runtime win Note the classifier filters which allow windows/linux specific files to be separated and stored in different staging areas. The OS-agnostic staging area uses exludes, while the OS-specific areas use includes. Finally, the assemblies are created with multiple maven assembly xml files which merge together the common staging area with the OS-specific staging area corresponding to the assembly. The result is a single OS-agnostic build which will produce one artifact per OS platform assembly. Resulting assemblies are ready to be run on their respective OSes. It also allows building a single larger package which includes all OSes. I've tested it on different build agents and it works well. Hopefully this classifier trick will help or inspire someone else :) Cheers, and thanks again for sharing your knowledge about JPackage! I am still looking into that as it looks promising in the future. Especially for creating packages that include the JVM, which is by the way a limitation of the approach I presented here. It requires the user to have Java 11 installed. *Nicolas Therrien* Senior Software Developer *[image: https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]* *o*: +1.819.931.2053 On Wed, Feb 20, 2019 at 2:50 PM Sverre Moe wrote: > You could use the new jpackage to create a native runtime of your > application. > The jpackager is now targeted for JDK 13, but can still be used to create > a native Java 11 application. > > You can download an EA build of JDK 13 with jpackage > http://jdk.java.net/jpackage/ > > > You would need to build on each platform, Linux, Windows, Mac. > > You mentioned you use Maven. When Java 9 came out I had already moved over > to Gradle, so not familiar with the maven configuration. > Here is a Gradle task to create a Java 11 runtime using jlink with the > Java 11 jmods > > task createRuntime(type: Exec) { > dependsOn installDist > > inputs.dir(installDist.outputs.files.singleFile) > outputs.dir("${buildDir}/runtime") > > doFirst { > delete "${buildDir}/runtime" > } > > def libDir = new File(installDist.outputs.files.singleFile, "lib").path > > commandLine '/usr/java/jdk-11/bin/jlink', > '--module-path', "/usr/java/jdk-11/jmods:${libDir}", > '--add-modules', 'eu.yourmodule.application', > '--output', "${buildDir}/runtime" > } > > You then use this runtime with jpackage to create a native application > image or installer. > > task createPackage(type: Exec) { > dependsOn createRuntime > > commandLine '/usr/java/jdk-13/bin/jpackage', 'create-installer', > '--verbose', > '--force', > '--name', project.name > > , > '--app-version', project.version, > '--module', "${mainClassName}", > '--resource-dir', "${buildDir}/package", > '--runtime-image', "${buildDir}/runtime", > '--output', "${buildDir}/native" > } > > /Sverre > > Den ons. 20. feb. 2019 kl. 19:57 skrev Nicolas Therrien < > nicolas.therrien at motorolasolutions.com>: > >> Hi! >> >> What is the proper way to create distributable packages of a JavaFx >> Application? >> >> I have a Java 11 application which I build as a module. The distribution >> includes a "modules" folder with all dependencies in it, and a script to >> launch the module. >> >> This assembly works if I build it on the same machine as I am going to be >> running it on. However, I realized that depending on which build agent the >> assembly is going to be created, the platform specific javafx dependencies >> may not match the target assembly. For example, if the build agent is a >> linux build agent, the windows and mac assembly contains linux javafx >> runtime. >> >> Maven will always pull the platform-specific libraries of the system it is >> running on. >> >> This was not a problem when JavaFx was part of the JDK since the correct >> runtime libraries were installed on the system already. >> >> What is the correct way to create a windows or linux package in a build >> platform independent way? >> >> I found an article which showed how to force maven to include all >> platforms >> as dependencies, but then I have to add dependency on each transitive >> library. Sounds like a lot of trouble for a simple task. >> >> How do you guys package your apps for various platforms? >> >> *Nicolas Therrien* >> >> Senior Software Developer >> >> *[image: >> >> https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]* >> >> *o*: +1.819.931.2053 >> > From wookey.dean at gmail.com Thu Feb 28 13:42:13 2019 From: wookey.dean at gmail.com (Dean Wookey) Date: Thu, 28 Feb 2019 15:42:13 +0200 Subject: JDK-8089986: Potential fix for beeping on windows. Message-ID: Hi, On Windows, a beep sound always plays when using accelerators/mnemonics with the alt key, even if those accelerators exist. It's only supposed to beep when no such key combination is registered. I've found a solution which never beeps which I believe is preferable, however I'm a bit out of my depth here. https://github.com/DeanWookey/openjdk-jfx/commit/3f8520e22f5090a35097005254133f2eac8f97cc, based on this stack overflow post: https://stackoverflow.com/questions/3662192/disable-messagebeep-on-invalid-syskeypress It appears like Javafx doesn't use the system menu at all? And hence we can safely respond to the WM_MENUCHAR message by closing the system menu? Dean