From johan.vos at gluonhq.com Sat Dec 1 19:36:45 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 1 Dec 2018 20:36:45 +0100 Subject: 12-ea builds Message-ID: Hi, We uploaded JavaFX 12-ea+3 yesterday at https://gluonhq.com/products/javafx/#ea and the artifacts are in maven central. (see https://twitter.com/GluonHQ/status/1068456348097134592) >From now on, our intention is to tag the dev repository every thursday with an incremental build number (12-ea+4 should be tagged Dec 6), and builds will be available every Friday. Especially with the fast release cadence, I think it is very important that ea-builds are tested very well. Of course I do not recommend using an EA release in production, but it should be easy to use it in development, especially if you are using maven/gradle to build your apps (create a version property in pom.xml or build.gradle, use that in the dependency declaration, and simply update that version whenever a new ea is available) Thanks, - Johan From donlaiq at gmail.com Sat Dec 1 19:44:08 2018 From: donlaiq at gmail.com (Don Laiquit) Date: Sat, 1 Dec 2018 16:44:08 -0300 Subject: Crypto FX Wallet Message-ID: Hello comunity: Maybe you have some free time and you would like to watch a new project based on Java FX. It's a wallet for cryptocoins based on Bitcoin https://github.com/donlaiq/cryptofxwallet I hope you can give me your feedback about it and help me to do it better. Regards. From sam.carlberg at gmail.com Sat Dec 1 19:45:55 2018 From: sam.carlberg at gmail.com (Sam Carlberg) Date: Sat, 1 Dec 2018 14:45:55 -0500 Subject: org.openjfx:javafx-fxml:11 is empty module In-Reply-To: References: Message-ID: All JavaFX components are split into three platform-specific artifacts for windows, mac, and linux. You'll need to set the artifact classifier in your build system to use the artifact for your system, eg "org.openjfx:javafx-fxml:11:linux" for gradle On Fri, Nov 30, 2018, 5:45 AM Ashley Bye wrote: > I'm trying to import the JavaFX FXML module into a project in IntelliJ. > However, none of the expected classes, e.g. FXMLLoader, are available. When > I look in the external library, the javafx-fxml dependency is empty except > for the MANIFEST.MF in META-INF. I'm either depending on the wrong thing or > there is a problem, but since I can't find any other reference to this > problem, I suspect it's me. Any help would be appreciated. > > Ashley > From diego.cirujano-cuesta at zeiss.com Mon Dec 3 08:12:01 2018 From: diego.cirujano-cuesta at zeiss.com (Cirujano Cuesta, Diego) Date: Mon, 3 Dec 2018 08:12:01 +0000 Subject: openjfx contribution documentation Message-ID: Hi all! We are surprised about the documentation of JavaFX. We could not make a test in openjfx running in the IDE: We followed the following the instructions: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX Here we used the following Ubuntu packages: sudo apt install ksh libasound2-dev libgl1-mesa-dev libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libjpeg-dev libpng-dev libx11-dev libxml2-dev libxslt1-dev libxt-dev libxxf86vm-dev pkg-config x11proto-core-dev x11proto-xf86vidmode-dev libavcodec-dev mercurial libgtk2.0-dev libgtk-3-dev libxtst-dev libudev-dev libavformat-dev (1)We used libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev instead of versions 0.1 as specified in the documentation. We also achieve to build openjfx in Ubuntu 18.04 LTS(without webview). Could we update the documentation to Ubuntu 18.04? $ bash ./gradlew Builds correctly. Following https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code : $ bash ./gradlew clean sdk apps test -x :web:test also works. But when we try to develop in Intellij, it does not work properly. We followed the following steps: https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingIntelliJIDEA (2)And we cannot build in the IDE. Dependency problems. We achieved to make it works somehow but it does not make sense to have the .idea in the repo if it does not work/help. It is confusing. Could we update the documentation as I mention in (1) -I would do it but I do not have the rights/pull request to do it-, the gradle commands(make use of the gradle wrapper), the .idea configuration(2). I think documentation is very important and must be up-to-date. This is the way to get contributions. We wanted to create 2 pull request but we spent the available time analyzing why the tests were not working. I would like to create a VM with the javafx development setup(It will be around 9GB). I think it will help to contribute to JavaFX. What do you think? Thank you very much! Diego From lenborje at gmail.com Mon Dec 3 10:12:55 2018 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Mon, 3 Dec 2018 11:12:55 +0100 Subject: Gradle plugin dependency problem Message-ID: <6145B918-4ED9-489D-BC81-51B9A2273785@gmail.com> Is this the right place to ask questions on the gradle plugin (org.openjfx.javafxplugin) ? I'm trying to migrate to Java 11 and openjfx. I have a gradle setup with multiple projects, which seems to be problematic. Base: Mostly non-GUI, code but still some references to javafx GUI: The javafx GUI, depends on Base Release: Release artefact packaging, depends on both Base and GUI. The basic problem seems to be I can't use the org.openjfx.javafxplugin in a project which another projects depends on, since the plugin apparently injects the javafx library artefacts *after" the configuration phase. The relevant section of my build.gradle in the Base project is: ---BEGIN---------- plugins { id 'java' id 'maven' id 'application' id 'wrapper' id 'eclipse' id "me.champeau.gradle.jmh" version '0.4.6' id 'org.openjfx.javafxplugin' version '0.0.5' } javafx { modules = [ 'javafx.controls' ] } --END------------- If I remove the javafx section, the gradle can execute, but my project won't build. :-( (I can't resolve this by moving all javafx usage to the GUI project, since the Release project (release artefact packaging) would still depend on GUI.) Cf. error below: $ ./gradlew build > Configure project : allProjects: Base: project.version=1.6.10-SNAPSHOT allProjects: GUI: project.version=1.6.10-SNAPSHOT allProjects: Release: project.version=1.6.10-SNAPSHOT > Configure project :Base test: configure FAILURE: Build failed with an exception. * What went wrong: A problem occurred configuring project ':Base'. > Cannot change dependencies of configuration ':Base:compile' after it has been included in dependency resolution. * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org BUILD FAILED in 1s From swpalmer at gmail.com Mon Dec 3 17:21:39 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 3 Dec 2018 12:21:39 -0500 Subject: JavaFX Media module crashes jdeps Message-ID: <717D11D7-3F77-48EA-BD00-FB6A94EA64DD@gmail.com> I use a Gradle script to run jdeps to get a module list for jlink. This command line (excuse the long paths into the Gradle cache): jdeps --print-module-deps --module-path C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-fxml\11.0.1\2ef70dd2fee84fa4f18c9cbdcabe91e93e8b08ea\javafx-fxml-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-web\11.0.1\4912c3f5184d1bea0f8d25af976aab1a521081ac\javafx-web-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-controls\11.0.1\c4a7cbfbb28713a29883f7c1c3433b841239f8e7\javafx-controls-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-controls\11.0.1\61cf91bf3494d0616216f49c9e1d183d170adf0a\javafx-controls-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-swing\11.0.1\c02350b12b940cb6ed14f1755e056c6e557f8b48\javafx-swing-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-media\11.0.1\d261eabc16e8037e403785dcd822b9d42079dc42\javafx-media-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-media\11.0.1\fd095047b7d06f6c7b16afe8cf9dffccab5d4494\javafx-media-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-graphics\11.0.1\8ec761df8ab0df38ea43f4e7a3018a2991f786f6\javafx-graphics-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-graphics\11.0.1\e062cb01783effc6413abbd94d1838f6b0add209\javafx-graphics-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-base\11.0.1\24f4f0f3a4c3e1ea536e463781fe799e3a7ac857\javafx-base-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-base\11.0.1\f1354a284f4151d20358e776f6ff68ee35bbb96d\javafx-base-11.0.1.jar C:\path\to\my\Application.jar Causes this exception: Exception in thread "main" java.lang.NullPointerException at jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.requiresTransitive(ModuleGraphBuilder.java:124) at jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.buildGraph(ModuleGraphBuilder.java:110) at jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.reduced(ModuleGraphBuilder.java:65) at jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.modules(ModuleExportsAnalyzer.java:124) at jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:97) at jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1023) at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:560) at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:519) at jdk.jdeps/com.sun.tools.jdeps.Main.main(Main.java:49) Without the JavaFX modules listed the output works fine. So I started to narrow it down and found that javafx-media-11.0.1-win.jar seems to cause the exception If I make a Java runtime that includes the same JavaFX modules (with media) and use --system instead of --module-path it also works fine. Got any ideas what might be going on? Thanks, Scott From kevin.rushforth at oracle.com Mon Dec 3 17:27:54 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 3 Dec 2018 09:27:54 -0800 Subject: JavaFX Media module crashes jdeps In-Reply-To: <717D11D7-3F77-48EA-BD00-FB6A94EA64DD@gmail.com> References: <717D11D7-3F77-48EA-BD00-FB6A94EA64DD@gmail.com> Message-ID: I guess you are running into: https://bugs.openjdk.java.net/browse/JDK-8211887 -- Kevin On 12/3/2018 9:21 AM, Scott Palmer wrote: > I use a Gradle script to run jdeps to get a module list for jlink. > > This command line (excuse the long paths into the Gradle cache): > > jdeps --print-module-deps --module-path C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-fxml\11.0.1\2ef70dd2fee84fa4f18c9cbdcabe91e93e8b08ea\javafx-fxml-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-web\11.0.1\4912c3f5184d1bea0f8d25af976aab1a521081ac\javafx-web-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-controls\11.0.1\c4a7cbfbb28713a29883f7c1c3433b841239f8e7\javafx-controls-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-controls\11.0.1\61cf91bf3494d0616216f49c9e1d183d170adf0a\javafx-controls-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-swing\11.0.1\c02350b12b940cb6ed14f1755e056c6e557f8b48\javafx-swing-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-media\11.0.1\d261eabc16e8037e403785dcd822b9d42079dc42\javafx-media-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-media\11.0.1\fd095047b7d06f6c7b16afe8cf9dffccab5d4494\javafx-media-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-graphics\11.0.1\8ec761df8ab0df38ea43f4e7a3018a2991f786f6\javafx-graphics-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-graphics\11.0.1\e062cb01783effc6413abbd94d1838f6b0add209\javafx-graphics-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-base\11.0.1\24f4f0f3a4c3e1ea536e463781fe799e3a7ac857\javafx-base-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-base\11.0.1\f1354a284f4151d20358e776f6ff68ee35bbb96d\javafx-base-11.0.1.jar C:\path\to\my\Application.jar > > Causes this exception: > Exception in thread "main" java.lang.NullPointerException > at jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.requiresTransitive(ModuleGraphBuilder.java:124) > at jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.buildGraph(ModuleGraphBuilder.java:110) > at jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.reduced(ModuleGraphBuilder.java:65) > at jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.modules(ModuleExportsAnalyzer.java:124) > at jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:97) > at jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1023) > at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:560) > at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:519) > at jdk.jdeps/com.sun.tools.jdeps.Main.main(Main.java:49) > > Without the JavaFX modules listed the output works fine. > > So I started to narrow it down and found that javafx-media-11.0.1-win.jar seems to cause the exception > > If I make a Java runtime that includes the same JavaFX modules (with media) and use --system instead of --module-path it also works fine. > > Got any ideas what might be going on? > > Thanks, > > Scott > From kevin.rushforth at oracle.com Mon Dec 3 17:45:05 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 3 Dec 2018 09:45:05 -0800 Subject: JavaFX Media module crashes jdeps In-Reply-To: References: <717D11D7-3F77-48EA-BD00-FB6A94EA64DD@gmail.com> Message-ID: I should add that fixing the following bug in JavaFX should avoid the problem: https://bugs.openjdk.java.net/browse/JDK-8211900 It's on my list to fix for openjfx12. -- Kevin On 12/3/2018 9:27 AM, Kevin Rushforth wrote: > I guess you are running into: > > https://bugs.openjdk.java.net/browse/JDK-8211887 > > -- Kevin > > On 12/3/2018 9:21 AM, Scott Palmer wrote: >> I use a Gradle script to run jdeps to get a module list for jlink. >> >> This command line (excuse the long paths into the Gradle cache): >> >> jdeps --print-module-deps --module-path >> C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-fxml\11.0.1\2ef70dd2fee84fa4f18c9cbdcabe91e93e8b08ea\javafx-fxml-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-web\11.0.1\4912c3f5184d1bea0f8d25af976aab1a521081ac\javafx-web-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-controls\11.0.1\c4a7cbfbb28713a29883f7c1c3433b841239f8e7\javafx-controls-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-controls\11.0.1\61cf91bf3494d0616216f49c9e1d183d170adf0a\javafx-controls-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-swing\11.0.1\c02350b12b940cb6ed14f1755e056c6e557f8b48\javafx-swing-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-media\11.0.1\d261eabc16e8037e403785dcd822b9d42079dc42\javafx-media-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-media\11.0.1\fd095047b7d06f6c7b16afe8cf9dffccab5d4494\javafx-media-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-graphics\11.0.1\8ec761df8ab0df38ea43f4e7a3018a2991f786f6\javafx-graphics-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-graphics\11.0.1\e062cb01783effc6413abbd94d1838f6b0add209\javafx-graphics-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-base\11.0.1\24f4f0f3a4c3e1ea536e463781fe799e3a7ac857\javafx-base-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-base\11.0.1\f1354a284f4151d20358e776f6ff68ee35bbb96d\javafx-base-11.0.1.jar >> C:\path\to\my\Application.jar >> >> Causes this exception: >> Exception in thread "main" java.lang.NullPointerException >> ???????? at >> jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.requiresTransitive(ModuleGraphBuilder.java:124) >> ???????? at >> jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.buildGraph(ModuleGraphBuilder.java:110) >> ???????? at >> jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.reduced(ModuleGraphBuilder.java:65) >> ???????? at >> jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.modules(ModuleExportsAnalyzer.java:124) >> ???????? at >> jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:97) >> ???????? at >> jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1023) >> ???????? at >> jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:560) >> ???????? at >> jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:519) >> ???????? at jdk.jdeps/com.sun.tools.jdeps.Main.main(Main.java:49) >> >> Without the JavaFX modules listed the output works fine. >> >> So I started to narrow it down and found that >> javafx-media-11.0.1-win.jar seems to cause the exception >> >> If I make a Java runtime that includes the same JavaFX modules (with >> media) and use --system instead of --module-path it also works fine. >> >> Got any ideas what might be going on? >> >> Thanks, >> >> Scott >> > > From ambarish.rapte at oracle.com Mon Dec 3 18:58:53 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 3 Dec 2018 10:58:53 -0800 (PST) Subject: [12] RFR : JDK-8214035 : Unable to render cmyk jpeg image Message-ID: <4438e120-6ab4-4375-a5fa-bb94a03ff12f@default> Hi, Please take a look at this bug fix, Webrev: http://cr.openjdk.java.net/~arapte/fx/8214035/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8214035 Regards, Ambarish From swpalmer at gmail.com Mon Dec 3 19:43:19 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 3 Dec 2018 14:43:19 -0500 Subject: JavaFX Media module crashes jdeps In-Reply-To: References: <717D11D7-3F77-48EA-BD00-FB6A94EA64DD@gmail.com> Message-ID: Thanks, that does seem to be the issue. Is this the sort of thing that might be back-ported to a 11.0.2 release? I'm trying to automate as much of my build as possible and special casing stuff to work around issues like this makes things a bit messy. It's just one of several little things that is making moving beyond JDK 8 a rather tedious affair. Almost there though... Cheers, Scott On Mon, Dec 3, 2018 at 12:45 PM Kevin Rushforth wrote: > I should add that fixing the following bug in JavaFX should avoid the > problem: > > https://bugs.openjdk.java.net/browse/JDK-8211900 > > It's on my list to fix for openjfx12. > > -- Kevin > > > On 12/3/2018 9:27 AM, Kevin Rushforth wrote: > > I guess you are running into: > > > > https://bugs.openjdk.java.net/browse/JDK-8211887 > > > > -- Kevin > > > > On 12/3/2018 9:21 AM, Scott Palmer wrote: > >> I use a Gradle script to run jdeps to get a module list for jlink. > >> > >> This command line (excuse the long paths into the Gradle cache): > >> > >> jdeps --print-module-deps --module-path > >> > C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-fxml\11.0.1\2ef70dd2fee84fa4f18c9cbdcabe91e93e8b08ea\javafx-fxml-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-web\11.0.1\4912c3f5184d1bea0f8d25af976aab1a521081ac\javafx-web-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-controls\11.0.1\c4a7cbfbb28713a29883f7c1c3433b841239f8e7\javafx-controls-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-controls\11.0.1\61cf91bf3494d0616216f49c9e1d183d170adf0a\javafx-controls-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-swing\11.0.1\c02350b12b940cb6ed14f1755e056c6e557f8b48\javafx-swing-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-media\11.0.1\d261eabc16e8037e403785dcd822b9d42079dc42\javafx-media-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-media\11.0.1\fd095047b7d06f6c7b16afe8cf9dffccab5d4494\javafx-media-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-graphics\11.0.1\8ec761df8ab0df38ea43f4e7a3018a2991f786f6\javafx-graphics-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-graphics\11.0.1\e062cb01783effc6413abbd94d1838f6b0add209\javafx-graphics-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-base\11.0.1\24f4f0f3a4c3e1ea536e463781fe799e3a7ac857\javafx-base-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-base\11.0.1\f1354a284f4151d20358e776f6ff68ee35bbb96d\javafx-base-11.0.1.jar > > >> C:\path\to\my\Application.jar > >> > >> Causes this exception: > >> Exception in thread "main" java.lang.NullPointerException > >> at > >> > jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.requiresTransitive(ModuleGraphBuilder.java:124) > >> at > >> > jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.buildGraph(ModuleGraphBuilder.java:110) > >> at > >> > jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.reduced(ModuleGraphBuilder.java:65) > >> at > >> > jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.modules(ModuleExportsAnalyzer.java:124) > >> at > >> > jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:97) > >> at > >> > jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1023) > >> at > >> jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:560) > >> at > >> jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:519) > >> at jdk.jdeps/com.sun.tools.jdeps.Main.main(Main.java:49) > >> > >> Without the JavaFX modules listed the output works fine. > >> > >> So I started to narrow it down and found that > >> javafx-media-11.0.1-win.jar seems to cause the exception > >> > >> If I make a Java runtime that includes the same JavaFX modules (with > >> media) and use --system instead of --module-path it also works fine. > >> > >> Got any ideas what might be going on? > >> > >> Thanks, > >> > >> Scott > >> > > > > > > > From youngty1997 at gmail.com Mon Dec 3 23:56:39 2018 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 3 Dec 2018 17:56:39 -0600 Subject: JavaFX fails to build with multiple different issues Message-ID: <4b8c89a1-89fa-c723-92c4-2afd85e3bf8a@gmail.com> So here is an odd one: JavaFX is now longer building on Arch Linux even on a previous source directory that did compile just fine. I'm guessing that something was updated and isn't compatible with JavaFX's build scripts but I'm not entirely sure what exactly it is. (Note: just to make sure the files didn't magically become corrupt or something I redownloaded from the Github mirror. Same issue.) First error is this: ~/openjdk-jfx-develop/buildSrc/src/main/groovy/com/sun/javafx/gradle/NativeCompileTask.groovy: 118: The variable [files] is declared final but is reassigned . At [118:21]? @ line 118, column 21. ?????????????????????? files += file; which is easy enough to fix by simply removing final from line 105. Even though this was clearly an issue(why use final on local variables? I've never understood why people do it...), I'm not entirely sure why it's throwing an error now. Is it because Groovy is a scripting language and the build scripts never used to follow that logic path? Next issue is this: > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer which I'm not sure on how to resolve. Thinking that it may be related to my custom built JDK I tried swapping it out for an older one that I know worked before and yet it fails all the same. From mike.ennen at gmail.com Tue Dec 4 00:52:00 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 3 Dec 2018 17:52:00 -0700 Subject: JavaFX fails to build with multiple different issues In-Reply-To: <4b8c89a1-89fa-c723-92c4-2afd85e3bf8a@gmail.com> References: <4b8c89a1-89fa-c723-92c4-2afd85e3bf8a@gmail.com> Message-ID: The first one is definitely a bug and I would consider opening a PR to remove the final modifier on https://github.com/javafxports/openjdk-jfx. The second one is a gradle error - what gradle command-line invocation are you using? On Mon, Dec 3, 2018 at 4:58 PM Ty Young wrote: > So here is an odd one: JavaFX is now longer building on Arch Linux even > on a previous source directory that did compile just fine. I'm guessing > that something was updated and isn't compatible with JavaFX's build > scripts but I'm not entirely sure what exactly it is. > > > (Note: just to make sure the files didn't magically become corrupt or > something I redownloaded from the Github mirror. Same issue.) > > > First error is this: > > > ~/openjdk-jfx-develop/buildSrc/src/main/groovy/com/sun/javafx/gradle/NativeCompileTask.groovy: > > 118: The variable [files] is declared final but is reassigned > . At [118:21] @ line 118, column 21. > files += file; > > > which is easy enough to fix by simply removing final from line 105. Even > though this was clearly an issue(why use final on local variables? I've > never understood why people do it...), I'm not entirely sure why it's > throwing an error now. Is it because Groovy is a scripting language and > the build scripts never used to follow that logic path? > > > Next issue is this: > > > > Could not get unknown property 'moduleEmptyPublicationJarLinux' for > task set of type org.gradle.api.internal.tasks.DefaultTaskContainer > > > which I'm not sure on how to resolve. Thinking that it may be related to > my custom built JDK I tried swapping it out for an older one that I know > worked before and yet it fails all the same. > > -- Michael Ennen From youngty1997 at gmail.com Tue Dec 4 03:08:30 2018 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 3 Dec 2018 21:08:30 -0600 Subject: JavaFX fails to build with multiple different issues In-Reply-To: References: <4b8c89a1-89fa-c723-92c4-2afd85e3bf8a@gmail.com> Message-ID: <6cf54a01-c16d-2f94-7300-3e074e1492ef@gmail.com> On 12/3/18 6:52 PM, Michael Ennen wrote: > The first one is definitely a bug and I would consider opening a PR to > remove > the final modifier on https://github.com/javafxports/openjdk-jfx. Done. This is the first time I've ever done a PR request so if there is anything wrong besides not signing away my left kidney with my own blood then let me know(/joke). I don't think it has any negative impact seeing as how the code requires the instance to be mutable anyway unless this really is a different code path from before(why would it be?) but I can't exactly check either way until I can compile and it's wrong either way. > > The second one is a gradle error - what gradle command-line invocation > are you using? "gradle build" though just doing "gradle" or even "gradle clean" results in the same fail. All tasks are borked would be my guess. > > On Mon, Dec 3, 2018 at 4:58 PM Ty Young > wrote: > > So here is an odd one: JavaFX is now longer building on Arch Linux > even > on a previous source directory that did compile just fine. I'm > guessing > that something was updated and isn't compatible with JavaFX's build > scripts but I'm not entirely sure what exactly it is. > > > (Note: just to make sure the files didn't magically become corrupt or > something I redownloaded from the Github mirror. Same issue.) > > > First error is this: > > > ~/openjdk-jfx-develop/buildSrc/src/main/groovy/com/sun/javafx/gradle/NativeCompileTask.groovy: > > 118: The variable [files] is declared final but is reassigned > . At [118:21]? @ line 118, column 21. > ??????????????????????? files += file; > > > which is easy enough to fix by simply removing final from line > 105. Even > though this was clearly an issue(why use final on local variables? > I've > never understood why people do it...), I'm not entirely sure why it's > throwing an error now. Is it because Groovy is a scripting > language and > the build scripts never used to follow that logic path? > > > Next issue is this: > > > ?> Could not get unknown property 'moduleEmptyPublicationJarLinux' > for > task set of type org.gradle.api.internal.tasks.DefaultTaskContainer > > > which I'm not sure on how to resolve. Thinking that it may be > related to > my custom built JDK I tried swapping it out for an older one that > I know > worked before and yet it fails all the same. > > > > -- > Michael Ennen From Dell.Green at ideaworks.co.uk Tue Dec 4 17:37:36 2018 From: Dell.Green at ideaworks.co.uk (Dell Green) Date: Tue, 4 Dec 2018 17:37:36 +0000 Subject: RFR: 8167068 Error undefined pixcoord Message-ID: Please review the fix for The Bug Synopsis: https://github.com/javafxports/openjdk-jfx/pull/312 https://github.com/javafxports/openjdk-jfx/issues/273 https://bugs.openjdk.java.net/browse/JDK-8167068 From mike.ennen at gmail.com Tue Dec 4 20:43:42 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Tue, 4 Dec 2018 13:43:42 -0700 Subject: JavaFX fails to build with multiple different issues In-Reply-To: <6cf54a01-c16d-2f94-7300-3e074e1492ef@gmail.com> References: <4b8c89a1-89fa-c723-92c4-2afd85e3bf8a@gmail.com> <6cf54a01-c16d-2f94-7300-3e074e1492ef@gmail.com> Message-ID: Thanks for opening the PR! That's the beauty of the public Github repository. The changeset looks good. In order to get it accepted you will need to sign the OCA (Oracle Contributor Agreement) but Kevin or another Oracle dev should help you through that process by commenting on the PR. You took the first step, so thank you. As for the gradle task issue the only half-baked suggestion I can offer is to try "gradlew all test" instead of "gradle build/clean". On Tue, Dec 4, 2018 at 3:34 AM Ty Young wrote: > > On 12/3/18 6:52 PM, Michael Ennen wrote: > > The first one is definitely a bug and I would consider opening a PR to > > remove > > the final modifier on https://github.com/javafxports/openjdk-jfx. > > > Done. This is the > first time I've ever done a PR request so if there is anything wrong > besides not signing away my left kidney with my own blood then let me > know(/joke). I don't think it has any negative impact seeing as how the > code requires the instance to be mutable anyway unless this really is a > different code path from before(why would it be?) but I can't exactly > check either way until I can compile and it's wrong either way. > > > > > > > The second one is a gradle error - what gradle command-line invocation > > are you using? > > > "gradle build" though just doing "gradle" or even "gradle clean" results > in the same fail. All tasks are borked would be my guess. > > > > > > On Mon, Dec 3, 2018 at 4:58 PM Ty Young > > wrote: > > > > So here is an odd one: JavaFX is now longer building on Arch Linux > > even > > on a previous source directory that did compile just fine. I'm > > guessing > > that something was updated and isn't compatible with JavaFX's build > > scripts but I'm not entirely sure what exactly it is. > > > > > > (Note: just to make sure the files didn't magically become corrupt or > > something I redownloaded from the Github mirror. Same issue.) > > > > > > First error is this: > > > > > > > ~/openjdk-jfx-develop/buildSrc/src/main/groovy/com/sun/javafx/gradle/NativeCompileTask.groovy: > > > > 118: The variable [files] is declared final but is reassigned > > . At [118:21] @ line 118, column 21. > > files += file; > > > > > > which is easy enough to fix by simply removing final from line > > 105. Even > > though this was clearly an issue(why use final on local variables? > > I've > > never understood why people do it...), I'm not entirely sure why it's > > throwing an error now. Is it because Groovy is a scripting > > language and > > the build scripts never used to follow that logic path? > > > > > > Next issue is this: > > > > > > > Could not get unknown property 'moduleEmptyPublicationJarLinux' > > for > > task set of type org.gradle.api.internal.tasks.DefaultTaskContainer > > > > > > which I'm not sure on how to resolve. Thinking that it may be > > related to > > my custom built JDK I tried swapping it out for an older one that > > I know > > worked before and yet it fails all the same. > > > > > > > > -- > > Michael Ennen > -- Michael Ennen From lenborje at gmail.com Wed Dec 5 09:55:39 2018 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Wed, 5 Dec 2018 10:55:39 +0100 Subject: Gradle plugin dependency problem In-Reply-To: <6145B918-4ED9-489D-BC81-51B9A2273785@gmail.com> References: <6145B918-4ED9-489D-BC81-51B9A2273785@gmail.com> Message-ID: <5693E05B-6431-4DF9-9267-FA2C04C61E20@gmail.com> I've found and corrected the problem in the plugin and submitted a pull request. Cf. https://github.com/openjfx/javafx-gradle-plugin/pull/15 Best regards, /Lennart B?rjeson > 3 dec. 2018 kl. 11:12 skrev Lennart B?rjeson : > > Is this the right place to ask questions on the gradle plugin (org.openjfx.javafxplugin) ? > > I'm trying to migrate to Java 11 and openjfx. I have a gradle setup with multiple projects, which seems to be problematic. > > Base: Mostly non-GUI, code but still some references to javafx > GUI: The javafx GUI, depends on Base > Release: Release artefact packaging, depends on both Base and GUI. > > The basic problem seems to be I can't use the org.openjfx.javafxplugin in a project which another projects depends on, since the plugin apparently injects the javafx library artefacts *after" the configuration phase. > > > The relevant section of my build.gradle in the Base project is: > > > ---BEGIN---------- > > plugins { > id 'java' > id 'maven' > id 'application' > id 'wrapper' > id 'eclipse' > id "me.champeau.gradle.jmh" version '0.4.6' > id 'org.openjfx.javafxplugin' version '0.0.5' > } > > javafx { > modules = [ 'javafx.controls' ] > } > > --END------------- > > > If I remove the javafx section, the gradle can execute, but my project won't build. :-( > > (I can't resolve this by moving all javafx usage to the GUI project, since the Release project (release artefact packaging) would still depend on GUI.) > > > Cf. error below: > > > > > > $ ./gradlew build > >> Configure project : > allProjects: Base: project.version=1.6.10-SNAPSHOT > allProjects: GUI: project.version=1.6.10-SNAPSHOT > allProjects: Release: project.version=1.6.10-SNAPSHOT > >> Configure project :Base > test: configure > > FAILURE: Build failed with an exception. > > * What went wrong: > A problem occurred configuring project ':Base'. >> Cannot change dependencies of configuration ':Base:compile' after it has been included in dependency resolution. > > * Try: > Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. > > * Get more help at https://help.gradle.org > > BUILD FAILED in 1s > From stmura at gmail.com Thu Dec 6 13:33:24 2018 From: stmura at gmail.com (Stefan Murawski) Date: Thu, 6 Dec 2018 14:33:24 +0100 Subject: OpenJDK 8 and JavaFx for Windows 7 Message-ID: Hi, this probably an annoying question, but I cannot find a solution. I am trying to find a JavaFX build that is compatible with OpenJDK 8 and Windows. So far I tried: Taking the AdoptOpenJDK Build for Windows 64 and JavaFX Drop-In from https://chriswhocodes.com/. This works very well for Windows 10. But on Windows I cannot start the application due to missing DLLS (I presume). My hunt through the internet led me to a post which basically said: OpenJDK 8 and JavaFx will never work on Windows 7. Is this true? The Reasoning behind my search is the desire to switch to an openjdk which is supported a bit longer than the oracle 8 jdk, but with javafx for Windows integrated. The new JavaFX page only deals with JavaFx11, sadly. If there is a way to build javafx myself, so that it works with WIndows7/10/OpenJDK please kindly guide me to a description. Thanks for any help, Stefan Murwaski From mp at jugs.org Thu Dec 6 13:43:47 2018 From: mp at jugs.org (Michael Paus) Date: Thu, 6 Dec 2018 14:43:47 +0100 Subject: OpenJDK 8 and JavaFx for Windows 7 In-Reply-To: References: Message-ID: <49acbb6a-dbd2-6be4-ca30-9f4c67fc0f2a@jugs.org> Have a look at: https://aws.amazon.com/de/corretto/ Windows is supported and it includes JavaFX but I don't know whether this is compatible with the old Windows 7. Michael Am 06.12.18 um 14:33 schrieb Stefan Murawski: > Hi, > > this probably an annoying question, but I cannot find a solution. > > I am trying to find a JavaFX build that is compatible with OpenJDK 8 and > Windows. > > So far I tried: > Taking the AdoptOpenJDK Build for Windows 64 and JavaFX Drop-In from > https://chriswhocodes.com/. > > This works very well for Windows 10. But on Windows I cannot start the > application due to missing DLLS (I presume). > > My hunt through the internet led me to a post which basically said: > OpenJDK 8 and JavaFx will never work on Windows 7. > Is this true? > > The Reasoning behind my search is the desire to switch to an openjdk which > is supported a bit longer than the oracle 8 jdk, but with javafx for > Windows integrated. > > The new JavaFX page only deals with JavaFx11, sadly. > > If there is a way to build javafx myself, so that it works with > WIndows7/10/OpenJDK please kindly guide me to a description. > > Thanks for any help, > Stefan Murwaski From stmura at gmail.com Thu Dec 6 14:31:45 2018 From: stmura at gmail.com (Stefan Murawski) Date: Thu, 6 Dec 2018 15:31:45 +0100 Subject: OpenJDK 8 and JavaFx for Windows 7 In-Reply-To: <49acbb6a-dbd2-6be4-ca30-9f4c67fc0f2a@jugs.org> References: <49acbb6a-dbd2-6be4-ca30-9f4c67fc0f2a@jugs.org> Message-ID: Hi, thanks for the coretto tip. But the MSI for the Windows JRE does not contain javafx. Cheers, Stefan Am Do., 6. Dez. 2018 um 14:44 Uhr schrieb Michael Paus : > Have a look at: https://aws.amazon.com/de/corretto/ > Windows is supported and it includes JavaFX > but I don't know whether this is compatible with the old Windows 7. > Michael > > Am 06.12.18 um 14:33 schrieb Stefan Murawski: > > Hi, > > > > this probably an annoying question, but I cannot find a solution. > > > > I am trying to find a JavaFX build that is compatible with OpenJDK 8 and > > Windows. > > > > So far I tried: > > Taking the AdoptOpenJDK Build for Windows 64 and JavaFX Drop-In from > > https://chriswhocodes.com/. > > > > This works very well for Windows 10. But on Windows I cannot start the > > application due to missing DLLS (I presume). > > > > My hunt through the internet led me to a post which basically said: > > OpenJDK 8 and JavaFx will never work on Windows 7. > > Is this true? > > > > The Reasoning behind my search is the desire to switch to an openjdk > which > > is supported a bit longer than the oracle 8 jdk, but with javafx for > > Windows integrated. > > > > The new JavaFX page only deals with JavaFx11, sadly. > > > > If there is a way to build javafx myself, so that it works with > > WIndows7/10/OpenJDK please kindly guide me to a description. > > > > Thanks for any help, > > Stefan Murwaski > > > From mp at jugs.org Thu Dec 6 14:35:47 2018 From: mp at jugs.org (Michael Paus) Date: Thu, 6 Dec 2018 15:35:47 +0100 Subject: OpenJDK 8 and JavaFx for Windows 7 In-Reply-To: References: <49acbb6a-dbd2-6be4-ca30-9f4c67fc0f2a@jugs.org> Message-ID: Are you sure? According to this article and other sources it does support JavaFX: Search for JavaFX. Am 06.12.18 um 15:31 schrieb Stefan Murawski: > Hi, > > thanks for the coretto tip. But the MSI for the Windows JRE does not > contain javafx. > > Cheers, > Stefan > > Am Do., 6. Dez. 2018 um 14:44?Uhr schrieb Michael Paus >: > > Have a look at: https://aws.amazon.com/de/corretto/ > Windows is supported and it includes JavaFX > but I don't know whether this is compatible with the old Windows 7. > Michael > > Am 06.12.18 um 14:33 schrieb Stefan Murawski: > > Hi, > > > > this probably an annoying question, but I cannot find a solution. > > > > I am trying to find a JavaFX build that is compatible with > OpenJDK 8 and > > Windows. > > > > So far I tried: > > Taking the AdoptOpenJDK Build for Windows 64 and JavaFX Drop-In from > > https://chriswhocodes.com/. > > > > This works very well for Windows 10. But on Windows I cannot > start the > > application due to missing DLLS (I presume). > > > > My hunt through the internet led me to a post which basically said: > > OpenJDK 8 and JavaFx will never work on Windows 7. > > Is this true? > > > > The Reasoning behind my search is the desire to switch to an > openjdk which > > is supported a bit longer than the oracle 8 jdk, but with javafx for > > Windows integrated. > > > > The new JavaFX page only deals with JavaFx11, sadly. > > > > If there is a way to build javafx myself, so that it works with > > WIndows7/10/OpenJDK please kindly guide me to a description. > > > > Thanks for any help, > > Stefan Murwaski > > From stmura at gmail.com Thu Dec 6 15:01:29 2018 From: stmura at gmail.com (Stefan Murawski) Date: Thu, 6 Dec 2018 16:01:29 +0100 Subject: OpenJDK 8 and JavaFx for Windows 7 In-Reply-To: References: <49acbb6a-dbd2-6be4-ca30-9f4c67fc0f2a@jugs.org> Message-ID: The msi extracts 2 folders. The 8jre Folder, that does not contain javafx. And the jdk Folder wich has a jre with javafx. Thanks for making me look again (I checked the jre8 Folder only at first). Cheers, Stefan Am Do., 6. Dez. 2018 um 15:35 Uhr schrieb Michael Paus : > Are you sure? According to this article and other sources it does support > JavaFX: > > > Search for JavaFX. > > Am 06.12.18 um 15:31 schrieb Stefan Murawski: > > Hi, > > thanks for the coretto tip. But the MSI for the Windows JRE does not > contain javafx. > > Cheers, > Stefan > > Am Do., 6. Dez. 2018 um 14:44 Uhr schrieb Michael Paus : > >> Have a look at: https://aws.amazon.com/de/corretto/ >> Windows is supported and it includes JavaFX >> but I don't know whether this is compatible with the old Windows 7. >> Michael >> >> Am 06.12.18 um 14:33 schrieb Stefan Murawski: >> > Hi, >> > >> > this probably an annoying question, but I cannot find a solution. >> > >> > I am trying to find a JavaFX build that is compatible with OpenJDK 8 and >> > Windows. >> > >> > So far I tried: >> > Taking the AdoptOpenJDK Build for Windows 64 and JavaFX Drop-In from >> > https://chriswhocodes.com/. >> > >> > This works very well for Windows 10. But on Windows I cannot start the >> > application due to missing DLLS (I presume). >> > >> > My hunt through the internet led me to a post which basically said: >> > OpenJDK 8 and JavaFx will never work on Windows 7. >> > Is this true? >> > >> > The Reasoning behind my search is the desire to switch to an openjdk >> which >> > is supported a bit longer than the oracle 8 jdk, but with javafx for >> > Windows integrated. >> > >> > The new JavaFX page only deals with JavaFx11, sadly. >> > >> > If there is a way to build javafx myself, so that it works with >> > WIndows7/10/OpenJDK please kindly guide me to a description. >> > >> > Thanks for any help, >> > Stefan Murwaski >> >> >> > From turikhay at gmail.com Thu Dec 6 15:07:00 2018 From: turikhay at gmail.com (Artur Khusainov) Date: Thu, 6 Dec 2018 20:07:00 +0500 Subject: OpenJDK 8 and JavaFx for Windows 7 In-Reply-To: References: Message-ID: I confirm that JavaFX 11 (and 12 so far) still support Windows 7, both x86 and x64. What wouldn't 8? :) What DLLs are missing exactly? If your application use media (e.g. MediaPlayer), then it will fail to start with missing gstreamer-lite (glib-lite.dll) library. JavaFX doesn't build media and WebKit by default. You should specify them explicitly: ./gradlew -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true build ??, 6 ???. 2018 ?., 18:35 Stefan Murawski : > Hi, > > this probably an annoying question, but I cannot find a solution. > > I am trying to find a JavaFX build that is compatible with OpenJDK 8 and > Windows. > > So far I tried: > Taking the AdoptOpenJDK Build for Windows 64 and JavaFX Drop-In from > https://chriswhocodes.com/. > > This works very well for Windows 10. But on Windows I cannot start the > application due to missing DLLS (I presume). > > My hunt through the internet led me to a post which basically said: > OpenJDK 8 and JavaFx will never work on Windows 7. > Is this true? > > The Reasoning behind my search is the desire to switch to an openjdk which > is supported a bit longer than the oracle 8 jdk, but with javafx for > Windows integrated. > > The new JavaFX page only deals with JavaFx11, sadly. > > If there is a way to build javafx myself, so that it works with > WIndows7/10/OpenJDK please kindly guide me to a description. > > Thanks for any help, > Stefan Murwaski > From swpalmer at gmail.com Fri Dec 7 20:19:11 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 7 Dec 2018 15:19:11 -0500 Subject: OpenJFX JMOD Files Message-ID: Is there a reason not to make the jmod files available as artifacts on Maven Central? The idea being that I can then use dependency management in my Gradle script and not require the extra setup and configuration of a JavaFX SDK - yet still be able to use the jmod files as input to jlink. I would rather create a runtime with the native libraries in place than use the modular jars and have the penalty of extracting native libraries at runtime. It seems I may need to use both the modular jars and the jmods because apparently jmods can't be used at runtime. That makes debugging awkward. Regards, Scott From thepossiblep at gmail.com Sat Dec 8 02:17:56 2018 From: thepossiblep at gmail.com (thepooran) Date: Sat, 8 Dec 2018 07:47:56 +0530 Subject: Javafx - graphics Message-ID: I am working on vector based graphic editor software and I've just started it with javafx. The most challenging part, I guess, is to make this software vector based. I think it could be done by making graphics rendering system in java and then use it as a part of that software but I don't know how to do it. Please help me to solve this problem. From bourges.laurent at gmail.com Sat Dec 8 08:25:38 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 8 Dec 2018 09:25:38 +0100 Subject: Javafx - graphics In-Reply-To: References: Message-ID: Hi, This is not stack overflow, neither a support list ! OpenJFX-dev is dedicated to OpenJFX dev, ie enhancing the JavaFX implementation. Concerning Vector Graphics, I made MarlinFX, the 2d shape rasterizer for openjfx, ie Shape to pixel coverage converter integrated in Prism. Laurent Le sam. 8 d?c. 2018 ? 03:19, thepooran a ?crit : > I am working on vector based graphic editor software and I've just started > it with javafx. The most challenging part, I guess, is to make this > software vector based. > > I think it could be done by making graphics rendering system in java and > then use it as a part of that software but I don't know how to do it. > > Please help me to solve this problem. > From kevin.rushforth at oracle.com Sat Dec 8 14:37:56 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 8 Dec 2018 06:37:56 -0800 Subject: Javafx - graphics In-Reply-To: References: Message-ID: <6f31937e-6b74-34a1-dd51-13de2797f6c2@oracle.com> This mailing list is for discussions relating to the development of JavaFX itself, and is not a place to ask for help in developing your application. -- Kevin On 12/7/2018 6:17 PM, thepooran wrote: > I am working on vector based graphic editor software and I've just started > it with javafx. The most challenging part, I guess, is to make this > software vector based. > > I think it could be done by making graphics rendering system in java and > then use it as a part of that software but I don't know how to do it. > > Please help me to solve this problem. From johan.vos at gluonhq.com Sun Dec 9 19:36:11 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 9 Dec 2018 20:36:11 +0100 Subject: OpenJFX JMOD Files In-Reply-To: References: Message-ID: Hi Scott, I got the use case. I think it should be possible, although in general uploading to the OSS sonatype repository requires uploading jars for the classes, sources and javadoc. There is no procedure yet (afaik) for uploading mods, but we can see if that works. - Johan On Fri, Dec 7, 2018 at 11:20 PM Scott Palmer wrote: > Is there a reason not to make the jmod files available as artifacts on > Maven Central? > > The idea being that I can then use dependency management in my Gradle > script and not require the extra setup and configuration of a JavaFX SDK - > yet still be able to use the jmod files as input to jlink. I would rather > create a runtime with the native libraries in place than use the modular > jars and have the penalty of extracting native libraries at runtime. > > It seems I may need to use both the modular jars and the jmods because > apparently jmods can't be used at runtime. That makes debugging awkward. > > > Regards, > > Scott > From mblaesing at doppel-helix.eu Mon Dec 10 17:58:38 2018 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Mon, 10 Dec 2018 18:58:38 +0100 Subject: OpenJFX JMOD Files In-Reply-To: References: Message-ID: <3eb04227deacae370ef86eb2a1d6278e26e9a7da.camel@doppel-helix.eu> Hi Johan, I was in a similar situation for JNA (Java Native Access) and found, that sonatype accepts other package types than jar/javadoc/sources. To support opening JNI libraries, the native parts need to be packed differently. This packaging is an "aar" (Android Archive). I did not ask sonatype, but just modified the upload, to include the aar together with the primary jar, javadocs and source. You can see for the jna library itself: https://repo1.maven.org/maven2/net/java/dev/jna/jna/5.1.0/ JNA uses the maven deploy plugin with the deploy-file goal and uploads the files together (from the ant build script): Maybe that helps Matthias Am Sonntag, den 09.12.2018, 20:36 +0100 schrieb Johan Vos: > I got the use case. I think it should be possible, although in general > uploading to the OSS sonatype repository requires uploading jars for the > classes, sources and javadoc. There is no procedure yet (afaik) for > uploading mods, but we can see if that works. > > - Johan > > On Fri, Dec 7, 2018 at 11:20 PM Scott Palmer wrote: > > > Is there a reason not to make the jmod files available as artifacts on > > Maven Central? From augustnagro at gmail.com Mon Dec 10 19:16:07 2018 From: augustnagro at gmail.com (August Nagro) Date: Mon, 10 Dec 2018 13:16:07 -0600 Subject: OpenJFX JMOD Files In-Reply-To: <3eb04227deacae370ef86eb2a1d6278e26e9a7da.camel@doppel-helix.eu> References: <3eb04227deacae370ef86eb2a1d6278e26e9a7da.camel@doppel-helix.eu> Message-ID: I wouldn't recommend publishing JMOD files on maven central since the file format is not yet stable (based on zip currently, but ideally will change to better compression in the future). JMOD seems to be 'unfinished business' from JPMS. Ex, https://stackoverflow.com/questions/44732915/why-did-java-9-introduce-the-jmod-file-format#comment76578978_44736159 I've also found that for some reason building modular FX applications with jlink + JMOD files produces significantly bigger runtime images than with the SDK. On Mon, Dec 10, 2018 at 11:59 AM Matthias Bl?sing wrote: > Hi Johan, > > I was in a similar situation for JNA (Java Native Access) and found, > that sonatype accepts other package types than jar/javadoc/sources. > > To support opening JNI libraries, the native parts need to be packed > differently. This packaging is an "aar" (Android Archive). I did not > ask sonatype, but just modified the upload, to include the aar together > with the primary jar, javadocs and source. > > You can see for the jna library itself: > > https://repo1.maven.org/maven2/net/java/dev/jna/jna/5.1.0/ > > JNA uses the maven deploy plugin with the deploy-file goal and uploads > the files together (from the ant build script): > > > value="org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file"/> > > > > > value="-Dfiles=${maven-sources-jar},${maven-javadoc-jar},${dist-aar}"/> > > > > > Maybe that helps > > Matthias > > Am Sonntag, den 09.12.2018, 20:36 +0100 schrieb Johan Vos: > > I got the use case. I think it should be possible, although in general > > uploading to the OSS sonatype repository requires uploading jars for the > > classes, sources and javadoc. There is no procedure yet (afaik) for > > uploading mods, but we can see if that works. > > > > - Johan > > > > On Fri, Dec 7, 2018 at 11:20 PM Scott Palmer wrote: > > > > > Is there a reason not to make the jmod files available as artifacts on > > > Maven Central? > > From swpalmer at gmail.com Mon Dec 10 22:52:27 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 10 Dec 2018 17:52:27 -0500 Subject: OpenJFX JMOD Files In-Reply-To: References: <3eb04227deacae370ef86eb2a1d6278e26e9a7da.camel@doppel-helix.eu> Message-ID: <137E3257-CF6A-47F6-BD39-523A9C075752@gmail.com> Inline > On Dec 10, 2018, at 2:16 PM, August Nagro wrote: > > I wouldn't recommend publishing JMOD files on maven central since the file format is not yet stable (based on zip currently, but ideally will change to better compression in the future). JMOD seems to be 'unfinished business' from JPMS. I don?t see that as a problem as new versions can be uploaded as required. > > I've also found that for some reason building modular FX applications with jlink + JMOD files produces significantly bigger runtime images than with the SDK. Well I don?t know what the full difference is, but for one the jmod-based runtime would have the native libraries in compressed. The class data may also be uncompressed depending on the jlink options used. It?s too bad this is such a mess. JMOD files can?t be used at runtime, but they have a mechanism to hold native libraries. JAR files lack that mechanism so they can?t be used to make a proper runtime image. I don?t know why a convention for including native libraries (in the META-INFO folder for example) wasn?t established, but I suspect it had to do with all the improvements they wanted for JMOD that didn?t happen anyway. JMOD now is just a mangled jar that isn?t particularly useful. How do you debug code that has native libraries without the expense of creating a runtime? Regards, Scott > >> On Mon, Dec 10, 2018 at 11:59 AM Matthias Bl?sing wrote: >> Hi Johan, >> >> I was in a similar situation for JNA (Java Native Access) and found, >> that sonatype accepts other package types than jar/javadoc/sources. >> >> To support opening JNI libraries, the native parts need to be packed >> differently. This packaging is an "aar" (Android Archive). I did not >> ask sonatype, but just modified the upload, to include the aar together >> with the primary jar, javadocs and source. >> >> You can see for the jna library itself: >> >> https://repo1.maven.org/maven2/net/java/dev/jna/jna/5.1.0/ >> >> JNA uses the maven deploy plugin with the deploy-file goal and uploads >> the files together (from the ant build script): >> >> >> >> >> >> >> >> >> >> >> >> >> Maybe that helps >> >> Matthias >> >> Am Sonntag, den 09.12.2018, 20:36 +0100 schrieb Johan Vos: >> > I got the use case. I think it should be possible, although in general >> > uploading to the OSS sonatype repository requires uploading jars for the >> > classes, sources and javadoc. There is no procedure yet (afaik) for >> > uploading mods, but we can see if that works. >> > >> > - Johan >> > >> > On Fri, Dec 7, 2018 at 11:20 PM Scott Palmer wrote: >> > >> > > Is there a reason not to make the jmod files available as artifacts on >> > > Maven Central? >> From augustnagro at gmail.com Mon Dec 10 23:26:14 2018 From: augustnagro at gmail.com (August Nagro) Date: Mon, 10 Dec 2018 17:26:14 -0600 Subject: OpenJFX JMOD Files In-Reply-To: References: <3eb04227deacae370ef86eb2a1d6278e26e9a7da.camel@doppel-helix.eu> Message-ID: > I don?t see that as a problem as new versions can be uploaded as required. Don't you think it would be an issue if Oracle decided to change the JAR format from ZIP to something else? I agree with the rest of your reply though. On Mon, Dec 10, 2018 at 1:16 PM August Nagro wrote: > I wouldn't recommend publishing JMOD files on maven central since the file > format is not yet stable (based on zip currently, but ideally will change > to better compression in the future). JMOD seems to be 'unfinished > business' from JPMS. > > Ex, > https://stackoverflow.com/questions/44732915/why-did-java-9-introduce-the-jmod-file-format#comment76578978_44736159 > > > I've also found that for some reason building modular FX applications with > jlink + JMOD files produces significantly bigger runtime images than with > the SDK. > > > On Mon, Dec 10, 2018 at 11:59 AM Matthias Bl?sing < > mblaesing at doppel-helix.eu> wrote: > >> Hi Johan, >> >> I was in a similar situation for JNA (Java Native Access) and found, >> that sonatype accepts other package types than jar/javadoc/sources. >> >> To support opening JNI libraries, the native parts need to be packed >> differently. This packaging is an "aar" (Android Archive). I did not >> ask sonatype, but just modified the upload, to include the aar together >> with the primary jar, javadocs and source. >> >> You can see for the jna library itself: >> >> https://repo1.maven.org/maven2/net/java/dev/jna/jna/5.1.0/ >> >> JNA uses the maven deploy plugin with the deploy-file goal and uploads >> the files together (from the ant build script): >> >> >> > value="org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file"/> >> >> >> >> >> > value="-Dfiles=${maven-sources-jar},${maven-javadoc-jar},${dist-aar}"/> >> >> >> >> >> Maybe that helps >> >> Matthias >> >> Am Sonntag, den 09.12.2018, 20:36 +0100 schrieb Johan Vos: >> > I got the use case. I think it should be possible, although in general >> > uploading to the OSS sonatype repository requires uploading jars for the >> > classes, sources and javadoc. There is no procedure yet (afaik) for >> > uploading mods, but we can see if that works. >> > >> > - Johan >> > >> > On Fri, Dec 7, 2018 at 11:20 PM Scott Palmer >> wrote: >> > >> > > Is there a reason not to make the jmod files available as artifacts on >> > > Maven Central? >> >> From pankaj.b.bansal at oracle.com Tue Dec 11 09:27:44 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 11 Dec 2018 14:57:44 +0530 Subject: [12] RFR: JDK-8208070: [macOS] Write a manual test for fix done for JDK-8191885 Message-ID: <0bc84c84-09e6-5013-953c-13ea3c5a8493@oracle.com> Hi Kevin/Murali, Please review the fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8208070 webrev: http://cr.openjdk.java.net/~pbansal/8208070/webrev.00/ Regards, Pankaj From murali.billa at oracle.com Tue Dec 11 18:57:10 2018 From: murali.billa at oracle.com (Murali Billa) Date: Tue, 11 Dec 2018 10:57:10 -0800 (PST) Subject: [12] RFR: JDK-8215231: Remove the redundant file readAsText.html Message-ID: Hi Kevin, Please review the simple fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8215231 Webrev: http://cr.openjdk.java.net/~mbilla/8215231/webrev.01/ Thanks, Murali From kevin.rushforth at oracle.com Tue Dec 11 19:01:00 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 11 Dec 2018 11:01:00 -0800 Subject: [12] RFR: JDK-8215231: Remove the redundant file readAsText.html In-Reply-To: References: Message-ID: +1 On 12/11/2018 10:57 AM, Murali Billa wrote: > Hi Kevin, > > Please review the simple fix. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8215231 > Webrev: http://cr.openjdk.java.net/~mbilla/8215231/webrev.01/ > > Thanks, > Murali From prasanta.sadhukhan at oracle.com Thu Dec 13 09:52:16 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 13 Dec 2018 15:22:16 +0530 Subject: [12] RFR JDK-8211249:Refactor javafx.swing implementation to get rid of unneeded abstraction layer Message-ID: Hi Kevin,All, Please review a cleanup of the abstraction layer done during refactoring of fx swing interop implementation. Bug: https://bugs.openjdk.java.net/browse/JDK-8211249 webrev: http://cr.openjdk.java.net/~psadhukhan/fx/8211249/webrev.0/ Regards Prasanta From sverre.moe at gmail.com Thu Dec 13 18:25:07 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 13 Dec 2018 19:25:07 +0100 Subject: Filling the Packager gap In-Reply-To: References: Message-ID: Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos : > Hi, > > As promised, we looked into an interim solution for the packager-gap. Work > for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. > We backported the required changes to an OpenJDK 11 mirror: > https://github.com/johanvos/openjdk-mobile11/tree/packager > > With this, we created modified OpenJDK 11 builds that contain the packager > (wrapper/exe + module including native library). They can be downloaded and > tested/used at > > http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip > > For Windows, you have to unzip the bundle in the same directory as the JDK, > as the packager wrapper expect to find the java binary at the same level. > > Note that these are not products. We use them internally to create > installers (e.g. we're using them for Scene Builder 11 and that works > fine), and they do what we expect them to do, but there are no guarantees > of course so at least for now I recommend using them in development only > (or even better, look at the changes and contribute to > https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) > > - Johan > Has anyone been able to use jpackager with bundle resources? The jpackager says to put these on the class path Using default package resource [menu icon] (add package/linux/app.png to the class path to customize) Using default package resource [Menu shortcut descriptor] (add package/linux/app.desktop to the class path to customize) Using default package resource [RPM spec file] (add package/linux/app.spec to the class path to customize) I have mentioned on corejdk mailinglist that the help output should mention how to do this. The jpackager does not support any classpath argument. The old javapackager did have an argument for setting classpath. Editing the jpackager bash script to include "-cp /path/to/project/build/deploy/" does not work. Considering that jdk.packager is a java module, I even tried to add the directory where package/linux is to the module-path. --module-path "/path/to/project/build/deploy":${JAVA_PACKAGER_PATH} It seems jpackager has been re-targeted for Java 13. I just hope it will continue to be usable for package Java 11 applications. The backported jpackager is working fine except for this resource problem. /Sverre From kevin.rushforth at oracle.com Thu Dec 13 19:30:31 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Dec 2018 11:30:31 -0800 Subject: Filling the Packager gap In-Reply-To: References: Message-ID: <3513e399-c63a-a2fe-74da-d75eec858eb7@oracle.com> [including Andy] On 12/13/2018 10:25 AM, Sverre Moe wrote: > Has anyone been able to use jpackager with bundle resources? > The jpackager says to put these on the class path > Using default package resource [menu icon] (add package/linux/app.png to > the class path to customize) > Using default package resource [Menu shortcut descriptor] (add > package/linux/app.desktop to the class path to customize) > Using default package resource [RPM spec file] (add package/linux/app.spec > to the class path to customize) > I have mentioned on corejdk mailinglist that the help output should mention > how to do this. > The jpackager does not support any classpath argument. The old javapackager > did have an argument for setting classpath. > Editing the jpackager bash script to include "-cp > /path/to/project/build/deploy/" does not work. > Considering that jdk.packager is a java module, I even tried to add the > directory where package/linux is to the module-path. > --module-path "/path/to/project/build/deploy":${JAVA_PACKAGER_PATH} Andy can probably comment on this. > It seems jpackager has been re-targeted for Java 13. I just hope it will > continue to be usable for package Java 11 applications. The backported > jpackager is working fine except for this resource problem. Yes, the jpackage tool (recently renamed to drop the 'r') will have the ability to package JDK 11 applications. -- Kevin From johan.vos at gluonhq.com Fri Dec 14 12:47:36 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 14 Dec 2018 13:47:36 +0100 Subject: Filling the Packager gap In-Reply-To: References: Message-ID: Hi Sverre, Scene Builder 11 is built using that backported packager, but not everything was working yet. It is not the intention to make a real product based on this backported code -- we just did it to fill the gap until the jpackage tool is available. My understanding is that once the jpackage tool is released, you should be able to use it to bundle Java(FX) 11 based apps. The first EA version of the jpackage tool is available now, so I think this is now the way forward: http://jdk.java.net/jpackage/ - Johan On Sun, Nov 11, 2018 at 11:00 PM Sverre Moe wrote: > Johan, > has there been any new updates to jpackager in JDK12 since you backported > it? > > I have found some problems with jpackager. Perhaps they might have been > fixed later. > I mentioned this to core-list-dev mailinglist on jpackager thread. > > 1) > The control file for debian package does not set correct description > > --name test > --description This is a Test Application > > /tmp/jdk.packager607148779833718376/linux/control > Package: test > Description: test > > The RPM gets it correctly > Summary : test > Description : > This is a Test Application > > 2) > Category is not set on either DEB or RPM > --category > Category or group of the application. > --category "Some/Category/Application" > Group: Unspecified > Section: unknown > > Perhaps I have misunderstood what this category is for, because I see this > it is set in the generated application.desktop, but It should definitely > also be set in the RPM and DEB. > > /Sverre > > Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos : > >> Hi, >> >> As promised, we looked into an interim solution for the packager-gap. Work >> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. >> We backported the required changes to an OpenJDK 11 mirror: >> https://github.com/johanvos/openjdk-mobile11/tree/packager >> >> With this, we created modified OpenJDK 11 builds that contain the packager >> (wrapper/exe + module including native library). They can be downloaded >> and >> tested/used at >> >> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip >> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip >> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip >> >> For Windows, you have to unzip the bundle in the same directory as the >> JDK, >> as the packager wrapper expect to find the java binary at the same level. >> >> Note that these are not products. We use them internally to create >> installers (e.g. we're using them for Scene Builder 11 and that works >> fine), and they do what we expect them to do, but there are no guarantees >> of course so at least for now I recommend using them in development only >> (or even better, look at the changes and contribute to >> https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) >> >> - Johan >> > From sverre.moe at gmail.com Fri Dec 14 15:31:04 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Fri, 14 Dec 2018 16:31:04 +0100 Subject: Filling the Packager gap In-Reply-To: References: Message-ID: Den fre. 14. des. 2018 kl. 13:47 skrev Johan Vos : > Hi Sverre, > > Scene Builder 11 is built using that backported packager, but not > everything was working yet. > It is not the intention to make a real product based on this backported > code -- we just did it to fill the gap until the jpackage tool is available. > > My understanding is that once the jpackage tool is released, you should be > able to use it to bundle Java(FX) 11 based apps. > > The first EA version of the jpackage tool is available now, so I think > this is now the way forward: http://jdk.java.net/jpackage/ > > - Johan > Thanks for the clarification. I have been looking through the source code of your backported jpackager to gain some insight, and I should perhaps instead be looking at the main source code for the jpackage. I will start using this JDK12 build of jpackager and see if it has the same issues regarding the bundle resources. Perhaps also the core-libs-dev at openjdk.java.net is the better place to discuss jpackage on forward. I reported some issues with jpackage some time ago that has been added to its JDK bugs list. /Sverre From victor.dyakov at oracle.com Fri Dec 14 16:07:44 2018 From: victor.dyakov at oracle.com (Victor D'yakov) Date: Fri, 14 Dec 2018 08:07:44 -0800 Subject: Fwd: jpackage EA Build 0 In-Reply-To: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> References: <15570225-5d8a-626b-9a56-310e4118b5e4@oracle.com> Message-ID: <52b5224d-c230-ffeb-b8e9-3ca01f797f52@oracle.com> FYI. Thiscore-libs-dev at openjdk.java.net mailing list is the place to discuss jpackage on forward and we encourage to share your feedback here atcore-libs-dev at openjdk.java.net . Victor -------- Forwarded Message -------- Subject: jpackage EA Build 0 Date: Fri, 14 Dec 2018 07:46:30 -0500 From: Andy Herrick Organization: Oracle Corporation To: core-libs-dev at openjdk.java.net I am pleased to announce that the first EA build of jpackage is now available at : https://jdk.java.net/jpackage/ This is an early access build of JEP 343: Packaging Tool , aimed at testing a prototype implementation of jpackage, This build is intended for developers interested in jpackage, and is provided as a convenience so that they don't need to build from the source code (branch="JDK-8200758-branch"). Warning: This build is based on an incomplete version of JDK 12 . Please send feedback via e-mail to core-libs-dev at openjdk.java.net /Andy -------------- next part -------------- An embedded message was scrubbed... From: Andy Herrick Subject: JEP 343: Packaging Tool Implementation - Status Update Date: Mon, 10 Dec 2018 13:21:42 -0500 Size: 7156 URL: From phidias51 at gmail.com Fri Dec 14 16:23:52 2018 From: phidias51 at gmail.com (Mark Fortner) Date: Fri, 14 Dec 2018 08:23:52 -0800 Subject: JPackage package types Message-ID: I know that there are a number of projects out there for building web assembly artifacts from Java projects (TeaVM and JWebAssembly to name a couple). I'm curious if anyone on the JPackage team is looking into the possibility of generating Web Assembly as one of the supported deployment strategies. This might be a viable alternative to applets, and would make it possible to deploy JavaFX applications to browsers. Cheers, Mark From kevin.rushforth at oracle.com Fri Dec 14 18:47:02 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Dec 2018 10:47:02 -0800 Subject: JPackage package types In-Reply-To: References: Message-ID: <4b58c694-e8df-16ad-d237-17be0f6783e6@oracle.com> No exploration of WebAssembly has been done. This would effectively be a new platform for Java and JavaFX (i.e., it isn't just a matter of bundling up a Linux app in a "WebAssembly" blob as an alternative to an rpm). Getting an FX app (or any Java app with native code) running in WebAssembly would need to be done first. While it might be an interesting area for somebody to explore, there are doubtless many challenges that would need to be overcome before worrying about how to use jpackage to package it all up. -- Kevin On 12/14/2018 8:23 AM, Mark Fortner wrote: > I know that there are a number of projects out there for building web > assembly artifacts from Java projects (TeaVM and JWebAssembly to name a > couple). I'm curious if anyone on the JPackage team is looking into the > possibility of generating Web Assembly as one of the supported deployment > strategies. This might be a viable alternative to applets, and would make > it possible to deploy JavaFX applications to browsers. > > Cheers, > > Mark From hjohn at xs4all.nl Sat Dec 15 01:46:20 2018 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 15 Dec 2018 02:46:20 +0100 Subject: Q: Rotated labels, layout and reflow Message-ID: <16bc1ce7-77e1-ca6f-6d2e-589153b6ee55@xs4all.nl> Hi list, I get the impression that rotation of Labels needs to be something that is directly supported by Label instead of handling this with a Rotate transform (setRotate). I want to achieve something quite trivial if no rotation was involved, a layout like this, an HBox with 3 labels in it: +-HBox------------------------------------------------------------+ | | Long text that can reflow to multiple | | | Short Text | lines if needed... | Short Text | | | | | +-----------------------------------------------------------------+ The center label would be given grow Priority.ALWAYS. Now... the rotated version just goes wrong in so many ways. First, I need to use Groups in order to get the layout bounds reasonable... however, these are unaware of how much space is available and will kill the reflow in the center Label. If I put a Group around the whole HBox, the same issue occurs as the Group blocks any awareness of how big the area is where the three labels are going to appear, effectively rendering the center label as one long line. What I'm actually trying to achieve is a layout that looks like this: +----+-------------------+ | | | | | | | | | | | | | | | | | | | | | | | | From hjohn at xs4all.nl Sat Dec 15 01:50:00 2018 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 15 Dec 2018 02:50:00 +0100 Subject: Q: Rotated labels, layout and reflow Message-ID: <9b79ab23-dc78-662e-8dfc-afc30a404cf3@xs4all.nl> (Sent this twice, first message got sent prematurely) Hi list, I get the impression that rotation of Labels needs to be something that is directly supported by Label instead of handling this with a Rotate transform (setRotate). I want to achieve something quite trivial if no rotation was involved, a layout like this, an HBox with 3 labels in it: +-HBox------------------------------------------------------------+ | | Long text that can reflow to multiple | | | Short Text | lines if needed... | Short Text | | | | | +-----------------------------------------------------------------+ The center label would be given grow Priority.ALWAYS. Now... the rotated version just goes wrong in so many ways. First, I need to use Groups in order to get the layout bounds reasonable... however, these are unaware of how much space is available and will kill the reflow in the center Label. If I put a Group around the whole HBox, the same issue occurs as the Group blocks any awareness of how big the area is where the three labels are going to appear, effectively rendering the center label as one long line. What I'm actually trying to achieve is a layout that looks like this: +----+-------------------+ | T | | | e | | | x | | | t | | +----+ | | | | | T | | | e | Image | | x | | | t | | | | | +----+ | | T | | | e | | | x | | | t | | +----+-------------------+ Except of course the left area should be the rotated HBox. Is this really not possible at the moment, without using a Canvas or something and a lot of layout calculations (to get reflow working)? Any feedback appreciated :) --John From johnvalrose at gmail.com Sat Dec 15 02:14:54 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 15 Dec 2018 13:14:54 +1100 Subject: Q: Rotated labels, layout and reflow In-Reply-To: <9b79ab23-dc78-662e-8dfc-afc30a404cf3@xs4all.nl> References: <9b79ab23-dc78-662e-8dfc-afc30a404cf3@xs4all.nl> Message-ID: My feedback would to ask this kind of question on a more appropriate list or forum. I believe this list is exclusively to discuss issues related to the development of OpenJFX itself. Graciously, John-Val > On 15 Dec 2018, at 12:50, John Hendrikx wrote: > > > (Sent this twice, first message got sent prematurely) > > Hi list, > > I get the impression that rotation of Labels needs to be something that is directly supported by Label instead of handling this with a Rotate transform (setRotate). > > I want to achieve something quite trivial if no rotation was involved, a layout like this, an HBox with 3 labels in it: > > +-HBox------------------------------------------------------------+ > | | Long text that can reflow to multiple | | > | Short Text | lines if needed... | Short Text | > | | | | > +-----------------------------------------------------------------+ > > The center label would be given grow Priority.ALWAYS. > > Now... the rotated version just goes wrong in so many ways. > > First, I need to use Groups in order to get the layout bounds reasonable... however, these are unaware of how much space is available and will kill the reflow in the center Label. > > If I put a Group around the whole HBox, the same issue occurs as the Group blocks any awareness of how big the area is where the three labels are going to appear, effectively rendering the center label as one long line. > > What I'm actually trying to achieve is a layout that looks like this: > > +----+-------------------+ > | T | | > | e | | > | x | | > | t | | > +----+ | > | | | > | T | | > | e | Image | > | x | | > | t | | > | | | > +----+ | > | T | | > | e | | > | x | | > | t | | > +----+-------------------+ > > Except of course the left area should be the rotated HBox. > > Is this really not possible at the moment, without using a Canvas or something and a lot of layout calculations (to get reflow working)? > > Any feedback appreciated :) > > --John From tbee at tbee.org Sat Dec 15 08:18:30 2018 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 15 Dec 2018 09:18:30 +0100 Subject: Q: Rotated labels, layout and reflow In-Reply-To: References: <9b79ab23-dc78-662e-8dfc-afc30a404cf3@xs4all.nl> Message-ID: <35b5f9b6-b094-396b-8a0b-78c2bded5f3b@tbee.org> It's a bit grey. If this goes towards a bug in the layout, it could be considered OpenJFX development. It could also go towards a patch, because instead of using Canvas I would suggest (John) to look at the HBox and see if you can figure out why it is not doing what you want. And if that is too complex; write a layout that does this, and contribute it to OpenJFX, ControlsFX or JFXtras. (I believe OpenJFX also is the sum of all the extending libraries, not making the suck-it-all-in mistake Java made.) The layout logic should be similar to when doing it in Canvas, only reusable. Also I have found that when rotating is involved, a lot of layouts do not what you expect them to do. Have you given MigLayout a try? It sometimes has surprising results (both positive and negative) ;-) On 15-12-2018 03:14, John-Val Rose wrote: > My feedback would to ask this kind of question on a more appropriate list or forum. > > I believe this list is exclusively to discuss issues related to the development of OpenJFX itself. > > Graciously, > > John-Val > >> On 15 Dec 2018, at 12:50, John Hendrikx wrote: >> >> >> (Sent this twice, first message got sent prematurely) >> >> Hi list, >> >> I get the impression that rotation of Labels needs to be something that is directly supported by Label instead of handling this with a Rotate transform (setRotate). >> >> I want to achieve something quite trivial if no rotation was involved, a layout like this, an HBox with 3 labels in it: >> >> +-HBox------------------------------------------------------------+ >> | | Long text that can reflow to multiple | | >> | Short Text | lines if needed... | Short Text | >> | | | | >> +-----------------------------------------------------------------+ >> >> The center label would be given grow Priority.ALWAYS. >> >> Now... the rotated version just goes wrong in so many ways. >> >> First, I need to use Groups in order to get the layout bounds reasonable... however, these are unaware of how much space is available and will kill the reflow in the center Label. >> >> If I put a Group around the whole HBox, the same issue occurs as the Group blocks any awareness of how big the area is where the three labels are going to appear, effectively rendering the center label as one long line. >> >> What I'm actually trying to achieve is a layout that looks like this: >> >> +----+-------------------+ >> | T | | >> | e | | >> | x | | >> | t | | >> +----+ | >> | | | >> | T | | >> | e | Image | >> | x | | >> | t | | >> | | | >> +----+ | >> | T | | >> | e | | >> | x | | >> | t | | >> +----+-------------------+ >> >> Except of course the left area should be the rotated HBox. >> >> Is this really not possible at the moment, without using a Canvas or something and a lot of layout calculations (to get reflow working)? >> >> Any feedback appreciated :) >> >> --John From johnvalrose at gmail.com Sat Dec 15 10:35:37 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 15 Dec 2018 21:35:37 +1100 Subject: Q: Rotated labels, layout and reflow In-Reply-To: <35b5f9b6-b094-396b-8a0b-78c2bded5f3b@tbee.org> References: <9b79ab23-dc78-662e-8dfc-afc30a404cf3@xs4all.nl> <35b5f9b6-b094-396b-8a0b-78c2bded5f3b@tbee.org> Message-ID: Tom, you are right - it is a bit grey and I'm glad you were able to offer better advice than I could. Sorry to John for possibly coming across as rude. I wasn't trying to be. I simply didn't think this was the best place to get your question answered. *Graciously,* *John-Val* On Sat, 15 Dec 2018 at 19:19, Tom Eugelink wrote: > It's a bit grey. If this goes towards a bug in the layout, it could be > considered OpenJFX development. It could also go towards a patch, because > instead of using Canvas I would suggest (John) to look at the HBox and see > if you can figure out why it is not doing what you want. And if that is too > complex; write a layout that does this, and contribute it to OpenJFX, > ControlsFX or JFXtras. (I believe OpenJFX also is the sum of all the > extending libraries, not making the suck-it-all-in mistake Java made.) The > layout logic should be similar to when doing it in Canvas, only reusable. > > Also I have found that when rotating is involved, a lot of layouts do not > what you expect them to do. Have you given MigLayout a try? It sometimes > has surprising results (both positive and negative) ;-) > > > > > On 15-12-2018 03:14, John-Val Rose wrote: > > My feedback would to ask this kind of question on a more appropriate > list or forum. > > > > I believe this list is exclusively to discuss issues related to the > development of OpenJFX itself. > > > > Graciously, > > > > John-Val > > > >> On 15 Dec 2018, at 12:50, John Hendrikx wrote: > >> > >> > >> (Sent this twice, first message got sent prematurely) > >> > >> Hi list, > >> > >> I get the impression that rotation of Labels needs to be something that > is directly supported by Label instead of handling this with a Rotate > transform (setRotate). > >> > >> I want to achieve something quite trivial if no rotation was involved, > a layout like this, an HBox with 3 labels in it: > >> > >> +-HBox------------------------------------------------------------+ > >> | | Long text that can reflow to multiple | | > >> | Short Text | lines if needed... | Short Text | > >> | | | | > >> +-----------------------------------------------------------------+ > >> > >> The center label would be given grow Priority.ALWAYS. > >> > >> Now... the rotated version just goes wrong in so many ways. > >> > >> First, I need to use Groups in order to get the layout bounds > reasonable... however, these are unaware of how much space is available and > will kill the reflow in the center Label. > >> > >> If I put a Group around the whole HBox, the same issue occurs as the > Group blocks any awareness of how big the area is where the three labels > are going to appear, effectively rendering the center label as one long > line. > >> > >> What I'm actually trying to achieve is a layout that looks like this: > >> > >> +----+-------------------+ > >> | T | | > >> | e | | > >> | x | | > >> | t | | > >> +----+ | > >> | | | > >> | T | | > >> | e | Image | > >> | x | | > >> | t | | > >> | | | > >> +----+ | > >> | T | | > >> | e | | > >> | x | | > >> | t | | > >> +----+-------------------+ > >> > >> Except of course the left area should be the rotated HBox. > >> > >> Is this really not possible at the moment, without using a Canvas or > something and a lot of layout calculations (to get reflow working)? > >> > >> Any feedback appreciated :) > >> > >> --John > > > From hjohn at xs4all.nl Sat Dec 15 11:06:03 2018 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 15 Dec 2018 12:06:03 +0100 Subject: Q: Rotated labels, layout and reflow In-Reply-To: <35b5f9b6-b094-396b-8a0b-78c2bded5f3b@tbee.org> References: <9b79ab23-dc78-662e-8dfc-afc30a404cf3@xs4all.nl> <35b5f9b6-b094-396b-8a0b-78c2bded5f3b@tbee.org> Message-ID: <651f72e0-5cb1-6199-30f5-940024b5773c@xs4all.nl> I asked here because, although not a bug, it may be a good feature to support -- and I was looking for confirmation that this really isn't currently possible. It's not a bug because a rotation transform is expected to not change the layout bounds. Making use of Group fixes the layout bounds but makes it impossible to do proper dynamic layouts with labels that have been rotated 90 degrees. Questions similar like this one, without good resolutions, show up on forums and stackoverflow, and, looking at the bug database, I think even some of the graph components part of JavaFX that support rotated labels have similar layout problems when texts needs to be cut-off or reflowed in such labels. I even looked at MigLayout already, and noticed a similar issue reported there where rotated labels are not handled properly, probably because the layout bounds don't take the rotation into account, which no doubt MigLayout relies on to do its thing. Now, I would love to contribute a fix for this (I contributed some small things before), however I think this might be a tough issue to resolve. The way I see it, this cannot be solved without Label taking the rotation into account itself and providing proper layout bounds -- this is needed because Label decides if text reflow needs to occur depending on where it is placed, and this information is lost when it is put in a Group. So I think Label(ed) would need a new Rotate property, which only supports 0, 90, 180 and 270 degrees, or perhaps an extension to the text direction property (left-right, right-left, top-down, down-top), but I think that it serves a different purpose that is independent from rotation. With this extra information, Label can then do the proper layout calculations with potential reflow of text and provide correct layout bounds. The actual text rendering would also need to be rotated somehow, and I'm not quite sure how that would be accomplished yet for Labels. All in all, it sounds like quite some effort that would need a good design, especially since Label already has a short-cut property to add a Rotate transform that cannot be re-used for this, so a new property would have to make the difference very clear. --John On 15/12/2018 09:18, Tom Eugelink wrote: > It's a bit grey. If this goes towards a bug in the layout, it could be > considered OpenJFX development. It could also go towards a patch, > because instead of using Canvas I would suggest (John) to look at the > HBox and see if you can figure out why it is not doing what you want. > And if that is too complex; write a layout that does this, and > contribute it to OpenJFX, ControlsFX or JFXtras. (I believe OpenJFX also > is the sum of all the extending libraries, not making the suck-it-all-in > mistake Java made.) The layout logic should be similar to when doing it > in Canvas, only reusable. > > Also I have found that when rotating is involved, a lot of layouts do > not what you expect them to do. Have you given MigLayout a try? It > sometimes has surprising results (both positive and negative) ;-) > > > > > On 15-12-2018 03:14, John-Val Rose wrote: >> My feedback would to ask this kind of question on a more appropriate >> list or forum. >> >> I believe this list is exclusively to discuss issues related to the >> development of OpenJFX itself. >> >> Graciously, >> >> John-Val >> >>> On 15 Dec 2018, at 12:50, John Hendrikx wrote: >>> >>> >>> (Sent this twice, first message got sent prematurely) >>> >>> Hi list, >>> >>> I get the impression that rotation of Labels needs to be something >>> that is directly supported by Label instead of handling this with a >>> Rotate transform (setRotate). >>> >>> I want to achieve something quite trivial if no rotation was >>> involved, a layout like this, an HBox with 3 labels in it: >>> >>> +-HBox------------------------------------------------------------+ >>> | | Long text that can reflow to multiple | | >>> | Short Text | lines if needed... | Short Text | >>> | | | | >>> +-----------------------------------------------------------------+ >>> >>> The center label would be given grow Priority.ALWAYS. >>> >>> Now... the rotated version just goes wrong in so many ways. >>> >>> First, I need to use Groups in order to get the layout bounds >>> reasonable... however, these are unaware of how much space is >>> available and will kill the reflow in the center Label. >>> >>> If I put a Group around the whole HBox, the same issue occurs as the >>> Group blocks any awareness of how big the area is where the three >>> labels are going to appear, effectively rendering the center label as >>> one long line. >>> >>> What I'm actually trying to achieve is a layout that looks like this: >>> >>> +----+-------------------+ >>> | T | | >>> | e | | >>> | x | | >>> | t | | >>> +----+ | >>> | | | >>> | T | | >>> | e | Image | >>> | x | | >>> | t | | >>> | | | >>> +----+ | >>> | T | | >>> | e | | >>> | x | | >>> | t | | >>> +----+-------------------+ >>> >>> Except of course the left area should be the rotated HBox. >>> >>> Is this really not possible at the moment, without using a Canvas or >>> something and a lot of layout calculations (to get reflow working)? >>> >>> Any feedback appreciated :) >>> >>> --John > > From johnvalrose at gmail.com Sat Dec 15 11:17:27 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 15 Dec 2018 22:17:27 +1100 Subject: Q: Rotated labels, layout and reflow In-Reply-To: <651f72e0-5cb1-6199-30f5-940024b5773c@xs4all.nl> References: <9b79ab23-dc78-662e-8dfc-afc30a404cf3@xs4all.nl> <35b5f9b6-b094-396b-8a0b-78c2bded5f3b@tbee.org> <651f72e0-5cb1-6199-30f5-940024b5773c@xs4all.nl> Message-ID: <13B88727-A1B3-481D-B62F-875731D65485@gmail.com> Yes, you are absolutely right John and again I?m sorry that I did not initially see the relevance of your question for this list. I do now and I like your ideas :-) > On 15 Dec 2018, at 22:06, John Hendrikx wrote: > > > I asked here because, although not a bug, it may be a good feature to support -- and I was looking for confirmation that this really isn't currently possible. It's not a bug because a rotation transform is expected to not change the layout bounds. Making use of Group fixes the layout bounds but makes it impossible to do proper dynamic layouts with labels that have been rotated 90 degrees. > > Questions similar like this one, without good resolutions, show up on forums and stackoverflow, and, looking at the bug database, I think even some of the graph components part of JavaFX that support rotated labels have similar layout problems when texts needs to be cut-off or reflowed in such labels. > > I even looked at MigLayout already, and noticed a similar issue reported there where rotated labels are not handled properly, probably because the layout bounds don't take the rotation into account, which no doubt MigLayout relies on to do its thing. > > Now, I would love to contribute a fix for this (I contributed some small things before), however I think this might be a tough issue to resolve. The way I see it, this cannot be solved without Label taking the rotation into account itself and providing proper layout bounds -- this is needed because Label decides if text reflow needs to occur depending on where it is placed, and this information is lost when it is put in a Group. > > So I think Label(ed) would need a new Rotate property, which only supports 0, 90, 180 and 270 degrees, or perhaps an extension to the text direction property (left-right, right-left, top-down, down-top), but I think that it serves a different purpose that is independent from rotation. > > With this extra information, Label can then do the proper layout calculations with potential reflow of text and provide correct layout bounds. The actual text rendering would also need to be rotated somehow, and I'm not quite sure how that would be accomplished yet for Labels. > > All in all, it sounds like quite some effort that would need a good design, especially since Label already has a short-cut property to add a Rotate transform that cannot be re-used for this, so a new property would have to make the difference very clear. > > --John > >> On 15/12/2018 09:18, Tom Eugelink wrote: >> It's a bit grey. If this goes towards a bug in the layout, it could be >> considered OpenJFX development. It could also go towards a patch, >> because instead of using Canvas I would suggest (John) to look at the >> HBox and see if you can figure out why it is not doing what you want. >> And if that is too complex; write a layout that does this, and >> contribute it to OpenJFX, ControlsFX or JFXtras. (I believe OpenJFX also >> is the sum of all the extending libraries, not making the suck-it-all-in >> mistake Java made.) The layout logic should be similar to when doing it >> in Canvas, only reusable. >> >> Also I have found that when rotating is involved, a lot of layouts do >> not what you expect them to do. Have you given MigLayout a try? It >> sometimes has surprising results (both positive and negative) ;-) >> >> >> >> >>> On 15-12-2018 03:14, John-Val Rose wrote: >>> My feedback would to ask this kind of question on a more appropriate >>> list or forum. >>> >>> I believe this list is exclusively to discuss issues related to the >>> development of OpenJFX itself. >>> >>> Graciously, >>> >>> John-Val >>> >>>> On 15 Dec 2018, at 12:50, John Hendrikx wrote: >>>> >>>> >>>> (Sent this twice, first message got sent prematurely) >>>> >>>> Hi list, >>>> >>>> I get the impression that rotation of Labels needs to be something >>>> that is directly supported by Label instead of handling this with a >>>> Rotate transform (setRotate). >>>> >>>> I want to achieve something quite trivial if no rotation was >>>> involved, a layout like this, an HBox with 3 labels in it: >>>> >>>> +-HBox------------------------------------------------------------+ >>>> | | Long text that can reflow to multiple | | >>>> | Short Text | lines if needed... | Short Text | >>>> | | | | >>>> +-----------------------------------------------------------------+ >>>> >>>> The center label would be given grow Priority.ALWAYS. >>>> >>>> Now... the rotated version just goes wrong in so many ways. >>>> >>>> First, I need to use Groups in order to get the layout bounds >>>> reasonable... however, these are unaware of how much space is >>>> available and will kill the reflow in the center Label. >>>> >>>> If I put a Group around the whole HBox, the same issue occurs as the >>>> Group blocks any awareness of how big the area is where the three >>>> labels are going to appear, effectively rendering the center label as >>>> one long line. >>>> >>>> What I'm actually trying to achieve is a layout that looks like this: >>>> >>>> +----+-------------------+ >>>> | T | | >>>> | e | | >>>> | x | | >>>> | t | | >>>> +----+ | >>>> | | | >>>> | T | | >>>> | e | Image | >>>> | x | | >>>> | t | | >>>> | | | >>>> +----+ | >>>> | T | | >>>> | e | | >>>> | x | | >>>> | t | | >>>> +----+-------------------+ >>>> >>>> Except of course the left area should be the rotated HBox. >>>> >>>> Is this really not possible at the moment, without using a Canvas or >>>> something and a lot of layout calculations (to get reflow working)? >>>> >>>> Any feedback appreciated :) >>>> >>>> --John >> >> From pankaj.b.bansal at oracle.com Tue Dec 18 07:54:33 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 17 Dec 2018 23:54:33 -0800 (PST) Subject: [12] JDK-8211280: [Linux] JavaFX build fails on Linux with gcc8 Message-ID: <84709e4a-5eab-4c3c-9c34-8e5bc78d998c@default> Hi Kevin/Murali, Please review the fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8211280 webrev: http://cr.openjdk.java.net/~pbansal/8211280/webrev.00/ Regards, Pankaj From arunprasad.rajkumar at oracle.com Tue Dec 18 18:16:29 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 18 Dec 2018 23:46:29 +0530 Subject: RFR: 8214119: Update to 607.1 version of WebKit Message-ID: <250C9D0E-0CEA-428B-AB3E-61A4BC223388@oracle.com> Hi Kevin, Murali, Johan, Joeri, Please review the following patch which merges GTK WebKit 2.22(607.1) into jfx-dev: http://cr.openjdk.java.net/~arajkumar/8214119/webrev Above link has a webrev and a changeset file, 1. rt-non-native-webkit ? Contains changes other than "modules/javafx.web/src/main/native", it will be useful _only_ for review, don?t apply the patch from it. 2. rt.changeset.gz ? Actual changeset file in compressed format which contains all the changes from ?rt? directory(including WebKit native changes), uncompress before using it(gunzip rt.changeset.gz) and do the following steps., $ hg clone http://hg.openjdk.java.net/openjfx/jfx-dev/rt $ cd rt $ hg import --no-commit rt.changeset #(from rt.changset.gz) This changeset requires the following versions of toolchains to build properly, * MSVC- 2017-15.5.5 or higher on Windows * GCC 7.3.0 or higher on Linux * Xcode 9.4 or higher on MacOS Thanks, Arun From johan.vos at gluonhq.com Wed Dec 19 07:18:28 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 19 Dec 2018 08:18:28 +0100 Subject: inconsistent class lookup in native code Message-ID: I noticed the behavior in the native-glass code for calling back in the Java layer differs fundamentally between linux and mac. On Linux, the JNI_OnLoad call will initialize the required classes/methods/fields for calling back into Java, and class lookup is done as follows: clazz = env->FindClass("com/sun/glass/ui/gtk/GtkApplication"); On Mac, however, the lookup is done via calls to a GlassHelper, e.g. jclass cls = [GlassHelper ClassForName:"com.sun.glass.ui.mac.MacApplication" withEnv:jEnv]; Inside the GlassHelper, the java.lang.Class is looked up via JNI code, and then a Java call to Class.forName() is done: jclass jcls = (*env)->FindClass(env, "java/lang/Class"); forNameMID = (*env)->GetStaticMethodID(env, classCls, "forName", "(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;"); jclass foundClass = (*env)->CallStaticObjectMethod(env, classCls, forNameMID,classNameStr, JNI_TRUE, glassClassLoader); I wonder why there is a difference between linux and mac here? In general, I see similar code between the linux/mac native directories. Most code that leads to callbacks into the Java layer is very similar. Therefore, I think for long-term maintainability, we might benefit from having a native-glass/share directory where most of this shared code can reside in (similar to the share/native directory in OpenJDK modules). This would prevent having to change all implementations if something in the low-level (private) API of javafx.graphics changes. - Johan From pankaj.b.bansal at oracle.com Wed Dec 19 07:22:54 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 18 Dec 2018 23:22:54 -0800 (PST) Subject: [12] JDK-8210411: JavaFX crashes on Ubuntu 18.04 with Wayland Message-ID: Hi All, Please review the fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8210411 Webrev: http://cr.openjdk.java.net/~pbansal/8210411/webrev.00/ Regards, Pankaj From mike.ennen at gmail.com Wed Dec 19 08:10:00 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 19 Dec 2018 01:10:00 -0700 Subject: Review-Request for JDK-8215629 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/328 https://bugs.openjdk.java.net/browse/JDK-8215629 Thanks. -- Michael Ennen From hjohn at xs4all.nl Wed Dec 19 08:55:26 2018 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 19 Dec 2018 09:55:26 +0100 Subject: Q: Rotated labels, layout and reflow In-Reply-To: <13B88727-A1B3-481D-B62F-875731D65485@gmail.com> References: <9b79ab23-dc78-662e-8dfc-afc30a404cf3@xs4all.nl> <35b5f9b6-b094-396b-8a0b-78c2bded5f3b@tbee.org> <651f72e0-5cb1-6199-30f5-940024b5773c@xs4all.nl> <13B88727-A1B3-481D-B62F-875731D65485@gmail.com> Message-ID: <71996491-65ae-30e5-3ca9-be025196cdb1@xs4all.nl> Update. I did an attempt to add this functionally to Label itself, by editing LabeledSkinBase, and with a few minor modifications (mainly swapping width/height variables in a few places), I managed to get this to work. Creating my own control wasn't really possible as the LabeledSkinBase is using text measurement methods that aren't public API so far, and which I would also need for a vertical label, so these changes had to be done directly in LabeledSkinBase. However, I found an acceptable work-around as well, extending upon the idea of how Group works. Wrapping a Label into a Pane, swapping all its compute*Width/Height methods to call the opposite version, and making sure ContentBias is set to Vertical, and you can get a working label that reflows correctly while being rendered vertically. I posted a sample on StackOverflow here: https://stackoverflow.com/questions/16921495/javafx-rotate-label-issue/53847417#53847417 --John On 15/12/2018 12:17, John-Val Rose wrote: > Yes, you are absolutely right John and again I?m sorry that I did not initially see the relevance of your question for this list. > > I do now and I like your ideas :-) > >> On 15 Dec 2018, at 22:06, John Hendrikx wrote: >> >> >> I asked here because, although not a bug, it may be a good feature to support -- and I was looking for confirmation that this really isn't currently possible. It's not a bug because a rotation transform is expected to not change the layout bounds. Making use of Group fixes the layout bounds but makes it impossible to do proper dynamic layouts with labels that have been rotated 90 degrees. >> >> Questions similar like this one, without good resolutions, show up on forums and stackoverflow, and, looking at the bug database, I think even some of the graph components part of JavaFX that support rotated labels have similar layout problems when texts needs to be cut-off or reflowed in such labels. >> >> I even looked at MigLayout already, and noticed a similar issue reported there where rotated labels are not handled properly, probably because the layout bounds don't take the rotation into account, which no doubt MigLayout relies on to do its thing. >> >> Now, I would love to contribute a fix for this (I contributed some small things before), however I think this might be a tough issue to resolve. The way I see it, this cannot be solved without Label taking the rotation into account itself and providing proper layout bounds -- this is needed because Label decides if text reflow needs to occur depending on where it is placed, and this information is lost when it is put in a Group. >> >> So I think Label(ed) would need a new Rotate property, which only supports 0, 90, 180 and 270 degrees, or perhaps an extension to the text direction property (left-right, right-left, top-down, down-top), but I think that it serves a different purpose that is independent from rotation. >> >> With this extra information, Label can then do the proper layout calculations with potential reflow of text and provide correct layout bounds. The actual text rendering would also need to be rotated somehow, and I'm not quite sure how that would be accomplished yet for Labels. >> >> All in all, it sounds like quite some effort that would need a good design, especially since Label already has a short-cut property to add a Rotate transform that cannot be re-used for this, so a new property would have to make the difference very clear. >> >> --John >> >>> On 15/12/2018 09:18, Tom Eugelink wrote: >>> It's a bit grey. If this goes towards a bug in the layout, it could be >>> considered OpenJFX development. It could also go towards a patch, >>> because instead of using Canvas I would suggest (John) to look at the >>> HBox and see if you can figure out why it is not doing what you want. >>> And if that is too complex; write a layout that does this, and >>> contribute it to OpenJFX, ControlsFX or JFXtras. (I believe OpenJFX also >>> is the sum of all the extending libraries, not making the suck-it-all-in >>> mistake Java made.) The layout logic should be similar to when doing it >>> in Canvas, only reusable. >>> >>> Also I have found that when rotating is involved, a lot of layouts do >>> not what you expect them to do. Have you given MigLayout a try? It >>> sometimes has surprising results (both positive and negative) ;-) >>> >>> >>> >>> >>>> On 15-12-2018 03:14, John-Val Rose wrote: >>>> My feedback would to ask this kind of question on a more appropriate >>>> list or forum. >>>> >>>> I believe this list is exclusively to discuss issues related to the >>>> development of OpenJFX itself. >>>> >>>> Graciously, >>>> >>>> John-Val >>>> >>>>> On 15 Dec 2018, at 12:50, John Hendrikx wrote: >>>>> >>>>> >>>>> (Sent this twice, first message got sent prematurely) >>>>> >>>>> Hi list, >>>>> >>>>> I get the impression that rotation of Labels needs to be something >>>>> that is directly supported by Label instead of handling this with a >>>>> Rotate transform (setRotate). >>>>> >>>>> I want to achieve something quite trivial if no rotation was >>>>> involved, a layout like this, an HBox with 3 labels in it: >>>>> >>>>> +-HBox------------------------------------------------------------+ >>>>> | | Long text that can reflow to multiple | | >>>>> | Short Text | lines if needed... | Short Text | >>>>> | | | | >>>>> +-----------------------------------------------------------------+ >>>>> >>>>> The center label would be given grow Priority.ALWAYS. >>>>> >>>>> Now... the rotated version just goes wrong in so many ways. >>>>> >>>>> First, I need to use Groups in order to get the layout bounds >>>>> reasonable... however, these are unaware of how much space is >>>>> available and will kill the reflow in the center Label. >>>>> >>>>> If I put a Group around the whole HBox, the same issue occurs as the >>>>> Group blocks any awareness of how big the area is where the three >>>>> labels are going to appear, effectively rendering the center label as >>>>> one long line. >>>>> >>>>> What I'm actually trying to achieve is a layout that looks like this: >>>>> >>>>> +----+-------------------+ >>>>> | T | | >>>>> | e | | >>>>> | x | | >>>>> | t | | >>>>> +----+ | >>>>> | | | >>>>> | T | | >>>>> | e | Image | >>>>> | x | | >>>>> | t | | >>>>> | | | >>>>> +----+ | >>>>> | T | | >>>>> | e | | >>>>> | x | | >>>>> | t | | >>>>> +----+-------------------+ >>>>> >>>>> Except of course the left area should be the rotated HBox. >>>>> >>>>> Is this really not possible at the moment, without using a Canvas or >>>>> something and a lot of layout calculations (to get reflow working)? >>>>> >>>>> Any feedback appreciated :) >>>>> >>>>> --John >>> >>> > From tbee at tbee.org Wed Dec 19 09:14:12 2018 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 19 Dec 2018 10:14:12 +0100 Subject: Q: Rotated labels, layout and reflow In-Reply-To: <71996491-65ae-30e5-3ca9-be025196cdb1@xs4all.nl> References: <9b79ab23-dc78-662e-8dfc-afc30a404cf3@xs4all.nl> <35b5f9b6-b094-396b-8a0b-78c2bded5f3b@tbee.org> <651f72e0-5cb1-6199-30f5-940024b5773c@xs4all.nl> <13B88727-A1B3-481D-B62F-875731D65485@gmail.com> <71996491-65ae-30e5-3ca9-be025196cdb1@xs4all.nl> Message-ID: <8d648ce2-7bea-0911-8074-8a1b70d02e40@tbee.org> Hey John, Is VerticalLabel implementation good enough to add to any of the open source projects? Tom On 19-12-2018 09:55, John Hendrikx wrote: > Update. > > I did an attempt to add this functionally to Label itself, by editing LabeledSkinBase, and with a few minor modifications (mainly swapping width/height variables in a few places), I managed to get this to work. > > Creating my own control wasn't really possible as the LabeledSkinBase is using text measurement methods that aren't public API so far, and which I would also need for a vertical label, so these changes had to be done directly in LabeledSkinBase. > > However, I found an acceptable work-around as well, extending upon the idea of how Group works.? Wrapping a Label into a Pane, swapping all its compute*Width/Height methods to call the opposite version, and making sure ContentBias is set to Vertical, and you can get a working label that reflows correctly while being rendered vertically. > > I posted a sample on StackOverflow here: https://stackoverflow.com/questions/16921495/javafx-rotate-label-issue/53847417#53847417 > > --John > > > On 15/12/2018 12:17, John-Val Rose wrote: >> Yes, you are absolutely right John and again I?m sorry that I did not initially see the relevance of your question for this list. >> >> I do now and I like your ideas :-) >> >>> On 15 Dec 2018, at 22:06, John Hendrikx wrote: >>> >>> >>> I asked here because, although not a bug, it may be a good feature to support -- and I was looking for confirmation that this really isn't currently possible.? It's not a bug because a rotation transform is expected to not change the layout bounds.? Making use of Group fixes the layout bounds but makes it impossible to do proper dynamic layouts with labels that have been rotated 90 degrees. >>> >>> Questions similar like this one, without good resolutions, show up on forums and stackoverflow, and, looking at the bug database, I think even some of the graph components part of JavaFX that support rotated labels have similar layout problems when texts needs to be cut-off or reflowed in such labels. >>> >>> I even looked at MigLayout already, and noticed a similar issue reported there where rotated labels are not handled properly, probably because the layout bounds don't take the rotation into account, which no doubt MigLayout relies on to do its thing. >>> >>> Now, I would love to contribute a fix for this (I contributed some small things before), however I think this might be a tough issue to resolve. The way I see it, this cannot be solved without Label taking the rotation into account itself and providing proper layout bounds -- this is needed because Label decides if text reflow needs to occur depending on where it is placed, and this information is lost when it is put in a Group. >>> >>> So I think Label(ed) would need a new Rotate property, which only supports 0, 90, 180 and 270 degrees, or perhaps an extension to the text direction property (left-right, right-left, top-down, down-top), but I think that it serves a different purpose that is independent from rotation. >>> >>> With this extra information, Label can then do the proper layout calculations with potential reflow of text and provide correct layout bounds.? The actual text rendering would also need to be rotated somehow, and I'm not quite sure how that would be accomplished yet for Labels. >>> >>> All in all, it sounds like quite some effort that would need a good design, especially since Label already has a short-cut property to add a Rotate transform that cannot be re-used for this, so a new property would have to make the difference very clear. >>> >>> --John >>> >>>> On 15/12/2018 09:18, Tom Eugelink wrote: >>>> It's a bit grey. If this goes towards a bug in the layout, it could be >>>> considered OpenJFX development. It could also go towards a patch, >>>> because instead of using Canvas I would suggest (John) to look at the >>>> HBox and see if you can figure out why it is not doing what you want. >>>> And if that is too complex; write a layout that does this, and >>>> contribute it to OpenJFX, ControlsFX or JFXtras. (I believe OpenJFX also >>>> is the sum of all the extending libraries, not making the suck-it-all-in >>>> mistake Java made.) The layout logic should be similar to when doing it >>>> in Canvas, only reusable. >>>> >>>> Also I have found that when rotating is involved, a lot of layouts do >>>> not what you expect them to do. Have you given MigLayout a try? It >>>> sometimes has surprising results (both positive and negative) ;-) >>>> >>>> >>>> >>>> >>>>> On 15-12-2018 03:14, John-Val Rose wrote: >>>>> My feedback would to ask this kind of question on a more appropriate >>>>> list or forum. >>>>> >>>>> I believe this list is exclusively to discuss issues related to the >>>>> development of OpenJFX itself. >>>>> >>>>> Graciously, >>>>> >>>>> John-Val >>>>> >>>>>> On 15 Dec 2018, at 12:50, John Hendrikx wrote: >>>>>> >>>>>> >>>>>> (Sent this twice, first message got sent prematurely) >>>>>> >>>>>> Hi list, >>>>>> >>>>>> I get the impression that rotation of Labels needs to be something >>>>>> that is directly supported by Label instead of handling this with a >>>>>> Rotate transform (setRotate). >>>>>> >>>>>> I want to achieve something quite trivial if no rotation was >>>>>> involved, a layout like this, an HBox with 3 labels in it: >>>>>> >>>>>> ?+-HBox------------------------------------------------------------+ >>>>>> ?|??????????? | Long text that can reflow to multiple |??????????? | >>>>>> ?| Short Text | lines if needed...??????????????????? | Short Text | >>>>>> ?|??????????? | |??????????? | >>>>>> ?+-----------------------------------------------------------------+ >>>>>> >>>>>> The center label would be given grow Priority.ALWAYS. >>>>>> >>>>>> Now... the rotated version just goes wrong in so many ways. >>>>>> >>>>>> First, I need to use Groups in order to get the layout bounds >>>>>> reasonable... however, these are unaware of how much space is >>>>>> available and will kill the reflow in the center Label. >>>>>> >>>>>> If I put a Group around the whole HBox, the same issue occurs as the >>>>>> Group blocks any awareness of how big the area is where the three >>>>>> labels are going to appear, effectively rendering the center label as >>>>>> one long line. >>>>>> >>>>>> What I'm actually trying to achieve is a layout that looks like this: >>>>>> >>>>>> ? +----+-------------------+ >>>>>> ? |? T |?????????????????? | >>>>>> ? |? e |?????????????????? | >>>>>> ? |? x |?????????????????? | >>>>>> ? |? t |?????????????????? | >>>>>> ? +----+?????????????????? | >>>>>> ? |??? |?????????????????? | >>>>>> ? |? T |?????????????????? | >>>>>> ? |? e |?????? Image?????? | >>>>>> ? |? x |?????????????????? | >>>>>> ? |? t |?????????????????? | >>>>>> ? |??? |?????????????????? | >>>>>> ? +----+?????????????????? | >>>>>> ? |? T |?????????????????? | >>>>>> ? |? e |?????????????????? | >>>>>> ? |? x |?????????????????? | >>>>>> ? |? t |?????????????????? | >>>>>> ? +----+-------------------+ >>>>>> >>>>>> Except of course the left area should be the rotated HBox. >>>>>> >>>>>> Is this really not possible at the moment, without using a Canvas or >>>>>> something and a lot of layout calculations (to get reflow working)? >>>>>> >>>>>> Any feedback appreciated :) >>>>>> >>>>>> --John >>>> >>>> >> From prasanta.sadhukhan at oracle.com Wed Dec 19 09:20:14 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 19 Dec 2018 14:50:14 +0530 Subject: [12] RFR JDK-8211248: Create manual drag and drop tests for FX / Swing interop Message-ID: Hi Kevin, All Please review few manual tests being added to test swingnode/jfxpanel DnD feature. Bug:https://bugs.openjdk.java.net/browse/JDK-8211248 webrev: http://cr.openjdk.java.net/~psadhukhan/fx/8211248/webrev.0/ Regards Prasanta From alan at whiteware.org Wed Dec 19 13:28:14 2018 From: alan at whiteware.org (Alan White (Drum Score Editor)) Date: Wed, 19 Dec 2018 13:28:14 +0000 Subject: Javapackager 10 to bundle OpenJDK 11 runtime Message-ID: <9A29B02D-FB62-410B-BD2C-B6E82B9F3ADC@whiteware.org> I understand the guidance for apps created with OpenJDK 11, is to use the javapackager from jdk 10. The old basedir parameter that could be used to direct the packager to use a specific runtime is no longer present. Is there any mechanism I?ve missed in order to have the packager from jdk10 bundle the 11 runtime plse? Thanks From kevin.rushforth at oracle.com Wed Dec 19 13:30:52 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Dec 2018 05:30:52 -0800 Subject: RFR: 8214119: Update to 607.1 version of WebKit In-Reply-To: <250C9D0E-0CEA-428B-AB3E-61A4BC223388@oracle.com> References: <250C9D0E-0CEA-428B-AB3E-61A4BC223388@oracle.com> Message-ID: <17fabcbd-945d-c9d7-f010-6e13e81efec2@oracle.com> Looks good to me. +1 -- Kevin On 12/18/2018 10:16 AM, Arunprasad Rajkumar wrote: > Hi Kevin, Murali, Johan, Joeri, > > Please review the following patch which merges GTK WebKit 2.22(607.1) into jfx-dev: > > http://cr.openjdk.java.net/~arajkumar/8214119/webrev > > Above link has a webrev and a changeset file, > > 1. rt-non-native-webkit ? Contains changes other than "modules/javafx.web/src/main/native", it will be useful _only_ for review, don?t apply the patch from it. > > 2. rt.changeset.gz ? Actual changeset file in compressed format which contains all the changes from ?rt? directory(including WebKit native changes), uncompress before using it(gunzip rt.changeset.gz) and do the following steps., > > $ hg clone http://hg.openjdk.java.net/openjfx/jfx-dev/rt > $ cd rt > $ hg import --no-commit rt.changeset #(from rt.changset.gz) > > This changeset requires the following versions of toolchains to build properly, > > * MSVC- 2017-15.5.5 or higher on Windows > * GCC 7.3.0 or higher on Linux > * Xcode 9.4 or higher on MacOS > > Thanks, > Arun From kevin.rushforth at oracle.com Wed Dec 19 13:51:15 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Dec 2018 05:51:15 -0800 Subject: Javapackager 10 to bundle OpenJDK 11 runtime In-Reply-To: <9A29B02D-FB62-410B-BD2C-B6E82B9F3ADC@whiteware.org> References: <9A29B02D-FB62-410B-BD2C-B6E82B9F3ADC@whiteware.org> Message-ID: <494d59b2-40f5-7cf6-4efc-8a22bdd7d92f@oracle.com> I doubt that will work. We are developing a replacement tool, jpackage [1], which will be part of OpenJDK. It is planned for JDK 13, and will support JDK 11 or later as a Java runtime. You can download an early access of this tool on jdk.java.net [2]. Discussion on jpackage is happening on the core-libs-dev mailing list [3]. Alternatively, Gluon has a standalone version of javapackager that will work with JDK 11. Johan Vos can provide a pointer. -- Kevin [1] https://openjdk.java.net/jeps/343 [2] http://jdk.java.net/jpackage/ [3] http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev On 12/19/2018 5:28 AM, Alan White (Drum Score Editor) wrote: > I understand the guidance for apps created with OpenJDK 11, is to use the javapackager from jdk 10. > > The old basedir parameter that could be used to direct the packager to use a specific runtime is no longer present. > > Is there any mechanism I?ve missed in order to have the packager from jdk10 bundle the 11 runtime plse? > > Thanks From alan at whiteware.org Wed Dec 19 14:51:15 2018 From: alan at whiteware.org (Alan White (Drum Score Editor)) Date: Wed, 19 Dec 2018 14:51:15 +0000 Subject: Javapackager 10 to bundle OpenJDK 11 runtime In-Reply-To: <494d59b2-40f5-7cf6-4efc-8a22bdd7d92f@oracle.com> References: <9A29B02D-FB62-410B-BD2C-B6E82B9F3ADC@whiteware.org> <494d59b2-40f5-7cf6-4efc-8a22bdd7d92f@oracle.com> Message-ID: <218BEBC5-25FB-4637-B2FA-45C75A2F6A8F@whiteware.org> Thanks. I?ll grab the Glueon ones for now to finish the app migration to 11, ie get off jdk 8 before January, and start working with the EA jpackager and migrate when suitable. Alan > On 19 Dec 2018, at 13:51, Kevin Rushforth wrote: > > I doubt that will work. > > We are developing a replacement tool, jpackage [1], which will be part of OpenJDK. It is planned for JDK 13, and will support JDK 11 or later as a Java runtime. You can download an early access of this tool on jdk.java.net [2]. Discussion on jpackage is happening on the core-libs-dev mailing list [3]. Alternatively, Gluon has a standalone version of javapackager that will work with JDK 11. Johan Vos can provide a pointer. > > -- Kevin > > [1] https://openjdk.java.net/jeps/343 > [2] http://jdk.java.net/jpackage/ > [3] http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > >> On 12/19/2018 5:28 AM, Alan White (Drum Score Editor) wrote: >> I understand the guidance for apps created with OpenJDK 11, is to use the javapackager from jdk 10. >> >> The old basedir parameter that could be used to direct the packager to use a specific runtime is no longer present. >> >> Is there any mechanism I?ve missed in order to have the packager from jdk10 bundle the 11 runtime plse? >> >> Thanks > From murali.billa at oracle.com Wed Dec 19 16:33:08 2018 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 19 Dec 2018 08:33:08 -0800 (PST) Subject: RFR: 8214119: Update to 607.1 version of WebKit In-Reply-To: <17fabcbd-945d-c9d7-f010-6e13e81efec2@oracle.com> References: <250C9D0E-0CEA-428B-AB3E-61A4BC223388@oracle.com> <17fabcbd-945d-c9d7-f010-6e13e81efec2@oracle.com> Message-ID: Looks fine. +1 One minor observation: WCFontImpl.java -> Regarding log.fine(String.format("str='%s' length=%d", str, str.length()));, I see earlier code which followed below format for ?length? log.fine(String.format("str='%s' (length=%d)", str, str.length())); Thanks, Murali -----Original Message----- From: Kevin Rushforth Sent: Wednesday, December 19, 2018 7:01 PM To: Arunprasad Rajkumar ; Murali Billa ; Johan Vos ; Joeri Sykora Cc: Praveen Srivastava ; Victor D'yakov ; openjfx-dev at openjdk.java.net List Subject: Re: RFR: 8214119: Update to 607.1 version of WebKit Looks good to me. +1 -- Kevin On 12/18/2018 10:16 AM, Arunprasad Rajkumar wrote: > Hi Kevin, Murali, Johan, Joeri, > > Please review the following patch which merges GTK WebKit 2.22(607.1) into jfx-dev: > > http://cr.openjdk.java.net/~arajkumar/8214119/webrev > > Above link has a webrev and a changeset file, > > 1. rt-non-native-webkit ? Contains changes other than "modules/javafx.web/src/main/native", it will be useful _only_ for review, don?t apply the patch from it. > > 2. rt.changeset.gz ? Actual changeset file in compressed format which contains all the changes from ?rt? directory(including WebKit native changes), uncompress before using it(gunzip rt.changeset.gz) and do the following steps., > > $ hg clone http://hg.openjdk.java.net/openjfx/jfx-dev/rt > $ cd rt > $ hg import --no-commit rt.changeset #(from rt.changset.gz) > > This changeset requires the following versions of toolchains to build properly, > > * MSVC- 2017-15.5.5 or higher on Windows > * GCC 7.3.0 or higher on Linux > * Xcode 9.4 or higher on MacOS > > Thanks, > Arun From johan.vos at gluonhq.com Wed Dec 19 18:10:05 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 19 Dec 2018 19:10:05 +0100 Subject: Javapackager 10 to bundle OpenJDK 11 runtime In-Reply-To: <494d59b2-40f5-7cf6-4efc-8a22bdd7d92f@oracle.com> References: <9A29B02D-FB62-410B-BD2C-B6E82B9F3ADC@whiteware.org> <494d59b2-40f5-7cf6-4efc-8a22bdd7d92f@oracle.com> Message-ID: The packager that works with Java 11 and JavaFX 11 is at http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-osx.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip (see http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022500.html ). However, I highly recommend testing the early access version of jpackage. That is the way forward for the packager. - Johan On Wed, Dec 19, 2018 at 6:36 PM Kevin Rushforth wrote: > I doubt that will work. > > We are developing a replacement tool, jpackage [1], which will be part > of OpenJDK. It is planned for JDK 13, and will support JDK 11 or later > as a Java runtime. You can download an early access of this tool on > jdk.java.net [2]. Discussion on jpackage is happening on the > core-libs-dev mailing list [3]. Alternatively, Gluon has a standalone > version of javapackager that will work with JDK 11. Johan Vos can > provide a pointer. > > -- Kevin > > [1] https://openjdk.java.net/jeps/343 > [2] http://jdk.java.net/jpackage/ > [3] http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > > On 12/19/2018 5:28 AM, Alan White (Drum Score Editor) wrote: > > I understand the guidance for apps created with OpenJDK 11, is to use > the javapackager from jdk 10. > > > > The old basedir parameter that could be used to direct the packager to > use a specific runtime is no longer present. > > > > Is there any mechanism I?ve missed in order to have the packager from > jdk10 bundle the 11 runtime plse? > > > > Thanks > > From arunprasad.rajkumar at oracle.com Thu Dec 20 08:30:02 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Thu, 20 Dec 2018 14:00:02 +0530 Subject: RFR JDK-8211399: libxslt fails to build with glibc 2.26 Message-ID: <354F076A-FD66-4D01-B7E6-F9F0682CA83F@oracle.com> Hi, Please review the following PR targeted for JDK-8211399. https://github.com/javafxports/openjdk-jfx/pull/314 https://bugs.openjdk.java.net/browse/JDK-8211399 Thanks, Arun From diegocirujano at gmail.com Thu Dec 20 18:03:52 2018 From: diegocirujano at gmail.com (Diego Cirujano) Date: Thu, 20 Dec 2018 19:03:52 +0100 Subject: JDK-8152395: Fix toolbar overflow control Message-ID: Hi, I'd like to request a review for JDK-8152395 available as a PR on Github: *https://github.com/javafxports/openjdk-jfx/pull/318 * JBS: *https://bugs.openjdk.java.net/browse/JDK-8152395 * Thanks. Diego From kevin.rushforth at oracle.com Thu Dec 20 19:32:40 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 Dec 2018 11:32:40 -0800 Subject: [12] JDK-8210411: JavaFX crashes on Ubuntu 18.04 with Wayland In-Reply-To: References: Message-ID: +1 -- Kevin On 12/18/2018 11:22 PM, Pankaj Bansal wrote: > Hi All, > > > > Please review the fix. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210411 > > Webrev: http://cr.openjdk.java.net/~pbansal/8210411/webrev.00/ > > > > Regards, > > Pankaj From kevin.rushforth at oracle.com Fri Dec 21 21:32:09 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Dec 2018 13:32:09 -0800 Subject: [8u-dev announce] Future contributions to openjfx/8u-dev Message-ID: <1b2b1803-5052-979b-f8f9-391661f327eb@oracle.com> As has been previously announced [1][2], Oracle will no longer contribute to the JDK 8 Updates Project after the January 2019 quarterly CPU release of JDK 8u202. Since JavaFX for JDK 8 is delivered as a part of the JDK, Oracle will also no longer contribute to the OpenJFX 8u-dev code line (8u-dev/rt repo) after JDK 8u202 ships. This means that Oracle will be stepping down as the maintainer of the openjfx/8u-dev code line after January, and will call for a new maintainer. If a suitable party steps forward to maintain the OpenJFX 8 Updates code line after the final Oracle-led JDK 8 Update release has been published, we will discuss how to best enable such a transition on this Project's mailing list. I wanted to send this before the holidays, although I realize it might get lost in the shuffle, so I will resend it after the first of the year, along with a formal call for interested parties who wish to put their name forward as a maintainer for the openjfx/8u-dev release. -- Kevin [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007341.html [2] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007923.html From tom.schindl at bestsolution.at Fri Dec 21 21:39:41 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 21 Dec 2018 22:39:41 +0100 Subject: [8u-dev announce] Future contributions to openjfx/8u-dev In-Reply-To: <1b2b1803-5052-979b-f8f9-391661f327eb@oracle.com> References: <1b2b1803-5052-979b-f8f9-391661f327eb@oracle.com> Message-ID: <6786cef7-31a3-33c8-c4ee-f65e5ded30fc@bestsolution.at> Hi, Could we get a mirror of 8u setup for github as well? I wanted to ask for that since some time but always forgot to do so. Tom On 21.12.18 22:32, Kevin Rushforth wrote: > As has been previously announced [1][2], Oracle will no longer > contribute to the JDK 8 Updates Project after the January 2019 quarterly > CPU release of JDK 8u202. Since JavaFX for JDK 8 is delivered as a part > of the JDK, Oracle will also no longer contribute to the OpenJFX 8u-dev > code line (8u-dev/rt repo) after JDK 8u202 ships. > > This means that Oracle will be stepping down as the maintainer of the > openjfx/8u-dev code line after January, and will call for a new > maintainer. If a suitable party steps forward to maintain the OpenJFX 8 > Updates code line after the final Oracle-led JDK 8 Update release has > been published, we will discuss how to best enable such a transition on > this Project's mailing list. > > I wanted to send this before the holidays, although I realize it might > get lost in the shuffle, so I will resend it after the first of the > year, along with a formal call for interested parties who wish to put > their name forward as a maintainer for the openjfx/8u-dev release. > > -- Kevin > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007341.html > [2] > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007923.html > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From samir.hadzic.pro at gmail.com Thu Dec 27 10:39:38 2018 From: samir.hadzic.pro at gmail.com (Sam') Date: Thu, 27 Dec 2018 11:39:38 +0100 Subject: Review request for JDK-8207957 Message-ID: Hi, I've made a PR here https://github.com/javafxports/openjdk-jfx/pull/289 regarding https://bugs.openjdk.java.net/browse/JDK-8207957 Anyone interested in the TableView (TreeTableView) can review and gives its opinion regarding the subject. Cheers, Sam'