From vadim.pakhnushev at oracle.com Mon Aug 1 10:58:00 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 1 Aug 2016 13:58:00 +0300 Subject: [9] Review request for 8152418: Memory Leak in StackedBarChart when series are removed Message-ID: <320817f4-2654-8640-8212-3b0bcd2a71f2@oracle.com> Hi Jonathan, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8152418 http://cr.openjdk.java.net/~vadim/8152418/webrev.00/ Thanks, Vadim From kevin.rushforth at oracle.com Mon Aug 1 20:35:01 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 01 Aug 2016 13:35:01 -0700 Subject: FX 9-dev repo reorg complete -- 9-dev is unlocked Message-ID: <579FB275.8060203@oracle.com> The fix for https://bugs.openjdk.java.net/browse/JDK-8161705 to reorganize the repo has been pushed to FX 9-dev, so the 9-dev repo is unlocked now. The FX source code has been reorganized as follows: base --> javafx.base controls --> javafx.controls fxml --> javafx.fxml fxpackager --> jdk.packager fxpackagerservices --> jdk.packager.services graphics --> javafx.graphics jmx --> javafx.jmx media --> javafx.media swing --> javafx.swing swt --> javafx.swt web --> javafx.web As I mentioned in the heads-up e-mail last week, you will need to fix up any inflight patches to match the new location of these files. You will also need to adjust the paths of any new changesets that are pushed to 9 and need to be backported to 8u. Dave will send out more information about this. -- Kevin From David.Hill at Oracle.com Mon Aug 1 20:37:57 2016 From: David.Hill at Oracle.com (David Hill) Date: Mon, 01 Aug 2016 16:37:57 -0400 Subject: Migrating FX patches to/from module paths Message-ID: <579FB325.1030409@Oracle.com> Hi all, with the rather large change set that just landed in openjfx, there will be some developers with a need to convert existing patches for use with the new module source paths, or need to back port a patch to the old module source paths. We have provided a set of scripts that can be used to help with this conversion. Old style to new style (ex: module/graphics ---> module/javafx.graphics) bash tools/scripts/fix_patch_8_9 < old_patch > new_patch New style to old style, likely for back porting (ex: module/javafx.graphics ---> module/graphics) bash tools/scripts/fix_patch_9_8 < old_patch > new_patch Note: * these scripts only modify the "diff paths" and should not modify the actual contents of the file changes. * testing has validated the rather complex regex in the scripts, but ... triple check that the resulting patch is correct! Likely the new_patch will fail to apply cleanly if there is an error, but check the resulting diffs to make sure. * your mileage may vary. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From David.Hill at Oracle.com Mon Aug 1 21:52:07 2016 From: David.Hill at Oracle.com (David Hill) Date: Mon, 01 Aug 2016 17:52:07 -0400 Subject: review: Add xpatch argfile creation script Message-ID: <579FC487.5000206@Oracle.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8162872 This adds a simple script that will create a "xpatch" file for a modular build output. This xpatch file will resemble the current build/xpatch.args file created by the build. This script is needed if you want to copy/download or whatever the build output to another location. The arguments in the file really have to be full paths to enable Java to find them. Script is attached to the JBS. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From chien.yang at oracle.com Tue Aug 2 00:11:42 2016 From: chien.yang at oracle.com (Chien Yang) Date: Mon, 1 Aug 2016 17:11:42 -0700 Subject: Code Review Request For 8162883: ESC button fails to cancel Dialog Message-ID: <579FE53E.8000709@oracle.com> Hi Jonathan and Kevin, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8162883 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8162883/webrev.00/ Thanks, - Chien From vadim.pakhnushev at oracle.com Tue Aug 2 14:24:27 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 2 Aug 2016 17:24:27 +0300 Subject: [9] Review request for 8150264: LineChart does not display correctly when a XYChart.Series is cleared and repopulated. Message-ID: <2d629b5d-b241-5e5a-217d-6a37aae0b97b@oracle.com> Jonathan, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8150264 http://cr.openjdk.java.net/~vadim/8150264/webrev.00/ Thanks, Vadim From murali.billa at oracle.com Tue Aug 2 16:43:27 2016 From: murali.billa at oracle.com (Murali Billa) Date: Tue, 2 Aug 2016 09:43:27 -0700 (PDT) Subject: [9] Review request for 8090216: HTMLEditor: font bold doesn't work when an indent is set In-Reply-To: <5d429381-0799-e757-c070-827af4746317@oracle.com> References: <5d429381-0799-e757-c070-827af4746317@oracle.com> Message-ID: ? Hi Kevin, Arun, Guru, Please review the following fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8090216 Webrev: http://cr.openjdk.java.net/~mbilla/8090216/webrev.00/ Thanks, Murali From chien.yang at oracle.com Tue Aug 2 23:24:07 2016 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 02 Aug 2016 16:24:07 -0700 Subject: Code Review Request For 8156078: Stage alwaysOnTop property not reset to false if permission is denied Message-ID: <57A12B97.6010004@oracle.com> Hi Kevin, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8156078 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8156078/webrev.00/ Thanks, - Chien From David.Hill at Oracle.com Tue Aug 2 23:32:02 2016 From: David.Hill at Oracle.com (David Hill) Date: Tue, 02 Aug 2016 19:32:02 -0400 Subject: review: (JDK-8163010) support macosx with fix_patch scripts Message-ID: <57A12D72.4020803@Oracle.com> Kevin, I really dislike platform specific code :-) yet another review (JDK-8163010) support macosx with fix_patch scripts attached new versions of the files as it is a pretty big makeover. Diff is in the jbs. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From David.Hill at Oracle.com Wed Aug 3 15:11:38 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 03 Aug 2016 11:11:38 -0400 Subject: Result: New OpenJFX Committer:Ankit Srivastava Message-ID: <57A209AA.6030302@Oracle.com> Voting for Ankit Srivastava (asrivastava) to OpenJFX Committer [1] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Dave [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-May/013881.html -- David Hill Java Embedded Development "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein (1957 - ) From philip.race at oracle.com Wed Aug 3 17:38:03 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 03 Aug 2016 10:38:03 -0700 Subject: RFR: 8130762: PrintJob doesn't update copies number Message-ID: <57A22BFB.10500@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8130762. Eval + diff in-line in the bug report. -phil. From murali.billa at oracle.com Wed Aug 3 18:27:24 2016 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 3 Aug 2016 11:27:24 -0700 (PDT) Subject: [9] Review request for 8162977: General sibling selector is broken for selected input boxes in WebView In-Reply-To: References: <5d429381-0799-e757-c070-827af4746317@oracle.com> Message-ID: ? ? Hi Kevin, Arun, Guru, Please review the following fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8162977 Webrev: http://cr.openjdk.java.net/~mbilla/8162977/webrev.00/ Thanks, Murali From alexander.zvegintsev at oracle.com Thu Aug 4 00:40:19 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 4 Aug 2016 03:40:19 +0300 Subject: [9] Review request for 8087498 [Mac] : Full screen mode fails for certain StageStyles Message-ID: Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8087498/00 for the issue https://bugs.openjdk.java.net/browse/JDK-8087498 -- -- Thanks, Alexander. From alexander.zvegintsev at oracle.com Thu Aug 4 00:40:32 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 4 Aug 2016 03:40:32 +0300 Subject: [9] Review request for 8163137 [Mac] : Maximizing a window with Cmd+Green button with Screen-Size hides it Message-ID: <67188f0f-d865-69c9-2e23-dd8434e5c572@oracle.com> Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8163137/00 for the issue https://bugs.openjdk.java.net/browse/JDK-8163137 -- -- Thanks, Alexander. From alexander.zvegintsev at oracle.com Thu Aug 4 00:40:37 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 4 Aug 2016 03:40:37 +0300 Subject: [9] Review request for 8089337 : JDK crash on Mac 10.10 with very large stage Message-ID: Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8089337/00 for the issue https://bugs.openjdk.java.net/browse/JDK-8089337 -- -- Thanks, Alexander. From a.ankit.srivastava at oracle.com Thu Aug 4 10:56:45 2016 From: a.ankit.srivastava at oracle.com (Ankit Srivastava) Date: Thu, 4 Aug 2016 03:56:45 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Andrey Rusakov In-Reply-To: <5793825F.2050606@oracle.com> References: <5793825F.2050606@oracle.com> Message-ID: <169ae972-38ea-4f40-8135-bf2d9e53acb4@default> Vote: Yes -----Original Message----- From: Kevin Rushforth Sent: Saturday, July 23, 2016 8:13 PM To: openjfx-dev at openjdk.java.net; Andrey Rusakov Subject: CFV: New OpenJFX Committer: Andrey Rusakov I hereby nominate Andrey Rusakov [1] to OpenJFX Committer. Andrey is a member of JavaFX SQE team at Oracle working on test development, who has contributed 19 changesets [5] to OpenJFX, at least 8 of which are significant. Votes are due by August 6, 2016. Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. Thanks, -- Kevin [1] http://openjdk.java.net/census#arusakov [2] http://openjdk.java.net/census#openjfx [3] http://openjdk.java.net/bylaws#lazy-consensus [4] http://openjdk.java.net/projects#project-committer [5] List of changesets: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a1e73dd4613e http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/7cce7ed57d89 http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/34e657660c5c http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0e78b9e0f50e http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/d356db6612c7 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1be0ce8c6667 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/adbed89b4b79 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/30fbc7690076 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b6bd30234e94 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9b0f70918dc4 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/38c836fde6ab http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bee64c78137a http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1e1aea3def0f http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/c20f5594ed04 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f34e58cb89ff http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/558c27a5d330 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/8ab04be9195b http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f741badededf http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/2e6d6f449f08 From vadim.pakhnushev at oracle.com Thu Aug 4 12:17:36 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Thu, 4 Aug 2016 15:17:36 +0300 Subject: [9] Review request for 8161673: Scatter-Chart is incompatible with ListProperty Message-ID: Jonathan, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8161673 http://cr.openjdk.java.net/~vadim/8161673/webrev.00/ Thanks, Vadim From arunprasad.rajkumar at oracle.com Thu Aug 4 12:48:12 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Thu, 4 Aug 2016 18:18:12 +0530 Subject: [webkit] [9] Review request for 8162949: [WebView] WebView can't display social network icons on wellsfargo.com In-Reply-To: <5d429381-0799-e757-c070-827af4746317@oracle.com> References: <5d429381-0799-e757-c070-827af4746317@oracle.com> Message-ID: Hello Kevin, Guru, Murali, Please review the following fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8162949 Webrev: http://cr.openjdk.java.net/~arajkumar/8162949/webrev.00 Regards, Arun From info at turvamies.fi Thu Aug 4 13:50:26 2016 From: info at turvamies.fi (Turvamies IT Security Services) Date: Thu, 4 Aug 2016 13:50:26 +0000 Subject: Compiling OpenJFX on OpenBSD Message-ID: <20160804135026.7d19ac76@uusilauta.turvamies.local> Hello, world! Apologies for the cross post, but since the bsd-port-dev list appears to be very quiet (and since I'm in a hurry), I'll post my question here too. I'm attempting to compile OpenJFX (rt-b41445afa464) on OpenBSD CURRENT (2016-08-04) since the official OpenBSD package (and port) of OpenJDK does not include OpenJFX. I have managed to install and/or compile all the dependencies, including gradle, but got stuck while compiling OpenJFX itself: $ pwd /tmp/rt-b41445afa464 $ env JAVA_HOME=/usr/local/jdk-1.8.0 JDK_HOME=/usr/local/jdk-1.8.0 JRE_HOME=/usr/local/jdk-1.8.0 PATH=/usr/local/jdk-1.8.0/bin:/tmp/.gradle/wrapper/dists/gradle-2.14-bin/76oc0mnc3ieqtsukq90mp0rxk/gradle-2.14/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin $ gradle --debug [...] 08:38:44.707 [INFO] [org.gradle.configuration.project.BuildScriptProcessor] Evaluating root project 'rt-b41445afa464' using build file '/tmp/rt-b41445afa464/build.gradle'. 08:38:44.727 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on cp_proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y /tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910). 08:38:44.728 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. 08:38:44.729 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on cp_proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910). 08:38:44.732 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). 08:38:44.733 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. 08:38:44.734 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). 08:38:45.852 [INFO] [org.gradle.api.Project] Applying COMPILE_FLAGS_FILE 'buildSrc/.gradle' 08:38:45.859 [DEBUG] [org.gradle.configuration.project.BuildScriptProcessor] Timing: Running the build script took 1.151 secs 08:38:45.902 [ERROR] [org.gradle.BuildExceptionReporter] 08:38:45.904 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build failed with an exception. 08:38:45.906 [ERROR] [org.gradle.BuildExceptionReporter] 08:38:45.907 [ERROR] [org.gradle.BuildExceptionReporter] * Where: 08:38:45.908 [ERROR] [org.gradle.BuildExceptionReporter] Build file '/tmp/rt-b41445afa464/build.gradle' line: 614 08:38:45.909 [ERROR] [org.gradle.BuildExceptionReporter] 08:38:45.910 [ERROR] [org.gradle.BuildExceptionReporter] * What went wrong: 08:38:45.911 [ERROR] [org.gradle.BuildExceptionReporter] A problem occurred evaluating root project 'rt-b41445afa464'. 08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter] > String index out of range: 0 08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter] 08:38:45.913 [ERROR] [org.gradle.BuildExceptionReporter] * Try: 08:38:45.914 [ERROR] [org.gradle.BuildExceptionReporter] Run with --stacktrace option to get the stack trace. 08:38:45.916 [LIFECYCLE] [org.gradle.BuildResultLogger] 08:38:45.917 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED 08:38:45.918 [LIFECYCLE] [org.gradle.BuildResultLogger] 08:38:45.919 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: 29.999 secs 08:38:45.931 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Cache Plugin Resolution Cache (/tmp/.gradle/caches/2.14/plugin-resolution) was closed 0 times. I don't quite know how to debug this further. Any tips would be much appreciated! Yours, Jyri -- Turvamies IT Security Services P.S. FYI, here's gradle --debug output: :buildSrc:generateGrammarSource UP-TO-DATE :buildSrc:compileJava UP-TO-DATE :buildSrc:compileGroovy UP-TO-DATE :buildSrc:processResources UP-TO-DATE :buildSrc:classes UP-TO-DATE :buildSrc:jar UP-TO-DATE :buildSrc:assemble UP-TO-DATE :buildSrc:compileTestJava UP-TO-DATE :buildSrc:compileTestGroovy UP-TO-DATE :buildSrc:processTestResources UP-TO-DATE :buildSrc:testClasses UP-TO-DATE :buildSrc:test UP-TO-DATE :buildSrc:check UP-TO-DATE :buildSrc:build UP-TO-DATE FAILURE: Build failed with an exception. * Where: Build file '/tmp/rt-b41445afa464/build.gradle' line: 614 * What went wrong: A problem occurred evaluating root project 'rt-b41445afa464'. > String index out of range: 0 * Try: Run with --info or --debug option to get more log output. * Exception is: org.gradle.api.GradleScriptException: A problem occurred evaluating root project 'rt-b41445afa464'. at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:93) at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl$2.run(DefaultScriptPluginFactory.java:177) at org.gradle.configuration.ProjectScriptTarget.addConfiguration(ProjectScriptTarget.java:77) at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:182) at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:38) at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:25) at org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34) at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:55) at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:540) at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:93) at org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:42) at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:35) at org.gradle.initialization.DefaultGradleLauncher$2.run(DefaultGradleLauncher.java:124) at org.gradle.internal.Factories$1.create(Factories.java:22) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53) at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:121) at org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:32) at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:98) at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:92) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63) at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:92) at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:83) at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:99) at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28) at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:48) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:30) at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:81) at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:46) at org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:51) at org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:28) at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43) at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173) at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:239) at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:212) at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35) at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:205) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169) at org.gradle.launcher.Main.doAction(Main.java:33) at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:55) at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:36) at org.gradle.launcher.GradleMain.main(GradleMain.java:23) Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at org.gradle.groovy.scripts.AbstractUriScriptSource.classNameFromPath(AbstractUriScriptSource.java:54) at org.gradle.groovy.scripts.AbstractUriScriptSource.getClassName(AbstractUriScriptSource.java:40) at org.gradle.groovy.scripts.DelegatingScriptSource.getClassName(DelegatingScriptSource.java:32) at org.gradle.groovy.scripts.internal.BuildScopeInMemoryCachingScriptClassCompiler.compile(BuildScopeInMemoryCachingScriptClassCompiler.java:45) at org.gradle.groovy.scripts.DefaultScriptCompilerFactory$ScriptCompilerImpl.compile(DefaultScriptCompilerFactory.java:50) at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:152) at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyScript(DefaultObjectConfigurationAction.java:102) at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$000(DefaultObjectConfigurationAction.java:36) at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$1.run(DefaultObjectConfigurationAction.java:62) at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:136) at org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46) at org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.java:34) at build_17kvkvc4f9j45htivwn1v303b$_run_closure5.doCall(/tmp/rt-b41445afa464/build.gradle:614) at build_17kvkvc4f9j45htivwn1v303b.run(/tmp/rt-b41445afa464/build.gradle:612) at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:91) ... 47 more BUILD FAILED Total time: 19.946 secs From David.Hill at Oracle.com Thu Aug 4 14:18:09 2016 From: David.Hill at Oracle.com (David Hill) Date: Thu, 04 Aug 2016 10:18:09 -0400 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <20160804135026.7d19ac76@uusilauta.turvamies.local> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> Message-ID: <57A34EA1.2030009@Oracle.com> On 8/4/16, 9:50 AM, Turvamies IT Security Services wrote: > Hello, world! This really looks like a Gradle failure to me. First there is the bit about the lock being held, then issues with the cache (are you behind a blocking firewall, proxy set ?), then the exceptions in gradle itself. I think most of the team is using Gradle 2.11, so it might be remotely possible that is the issue too. I would assume you have looked at: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX, There are prebuilt binaries out there if you just want to have binaries to play with: http://chriswhocodes.com/ > > Apologies for the cross post, but since the bsd-port-dev list appears to be > very quiet (and since I'm in a hurry), I'll post my question here too. > > I'm attempting to compile OpenJFX (rt-b41445afa464) on OpenBSD CURRENT > (2016-08-04) since the official OpenBSD package (and port) of OpenJDK > does not include OpenJFX. > > I have managed to install and/or compile all the dependencies, > including gradle, but got stuck while compiling OpenJFX itself: > > $ pwd > /tmp/rt-b41445afa464 > > $ env > JAVA_HOME=/usr/local/jdk-1.8.0 > JDK_HOME=/usr/local/jdk-1.8.0 > JRE_HOME=/usr/local/jdk-1.8.0 > PATH=/usr/local/jdk-1.8.0/bin:/tmp/.gradle/wrapper/dists/gradle-2.14-bin/76oc0mnc3ieqtsukq90mp0rxk/gradle-2.14/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin > > $ gradle --debug > [...] > 08:38:44.707 [INFO] [org.gradle.configuration.project.BuildScriptProcessor] Evaluating root project 'rt-b41445afa464' using build file '/tmp/rt-b41445afa464/build.gradle'. > > 08:38:44.727 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on cp_proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y /tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910). > > 08:38:44.728 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. > > 08:38:44.729 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on cp_proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910). > > 08:38:44.732 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). > > 08:38:44.733 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. > > 08:38:44.734 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). > > 08:38:45.852 [INFO] [org.gradle.api.Project] Applying COMPILE_FLAGS_FILE 'buildSrc/.gradle' > > 08:38:45.859 [DEBUG] [org.gradle.configuration.project.BuildScriptProcessor] Timing: Running the build script took 1.151 secs > > 08:38:45.902 [ERROR] [org.gradle.BuildExceptionReporter] > > 08:38:45.904 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build failed with an exception. > > 08:38:45.906 [ERROR] [org.gradle.BuildExceptionReporter] > > 08:38:45.907 [ERROR] [org.gradle.BuildExceptionReporter] * Where: > > 08:38:45.908 [ERROR] [org.gradle.BuildExceptionReporter] Build file '/tmp/rt-b41445afa464/build.gradle' line: > > 614 08:38:45.909 [ERROR] [org.gradle.BuildExceptionReporter] > > 08:38:45.910 [ERROR] [org.gradle.BuildExceptionReporter] * What went wrong: > > 08:38:45.911 [ERROR] [org.gradle.BuildExceptionReporter] A problem occurred evaluating root project 'rt-b41445afa464'. > > 08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter]> String index out of range: 0 > > 08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter] > > 08:38:45.913 [ERROR] [org.gradle.BuildExceptionReporter] * Try: > > 08:38:45.914 [ERROR] [org.gradle.BuildExceptionReporter] Run with --stacktrace option to get the stack trace. > > 08:38:45.916 [LIFECYCLE] [org.gradle.BuildResultLogger] > > 08:38:45.917 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED > > 08:38:45.918 [LIFECYCLE] [org.gradle.BuildResultLogger] > > 08:38:45.919 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: 29.999 secs > > 08:38:45.931 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Cache Plugin Resolution Cache (/tmp/.gradle/caches/2.14/plugin-resolution) was closed 0 times. > > I don't quite know how to debug this further. > > Any tips would be much appreciated! > > Yours, > > Jyri > -- > Turvamies IT Security Services > > P.S. FYI, here's gradle --debug output: > > :buildSrc:generateGrammarSource UP-TO-DATE > :buildSrc:compileJava UP-TO-DATE > :buildSrc:compileGroovy UP-TO-DATE > :buildSrc:processResources UP-TO-DATE > :buildSrc:classes UP-TO-DATE > :buildSrc:jar UP-TO-DATE > :buildSrc:assemble UP-TO-DATE > :buildSrc:compileTestJava UP-TO-DATE > :buildSrc:compileTestGroovy UP-TO-DATE > :buildSrc:processTestResources UP-TO-DATE > :buildSrc:testClasses UP-TO-DATE > :buildSrc:test UP-TO-DATE > :buildSrc:check UP-TO-DATE > :buildSrc:build UP-TO-DATE > > FAILURE: Build failed with an exception. > > * Where: > Build file '/tmp/rt-b41445afa464/build.gradle' line: 614 > > * What went wrong: > A problem occurred evaluating root project 'rt-b41445afa464'. >> String index out of range: 0 > * Try: > Run with --info or --debug option to get more log output. > > * Exception is: > org.gradle.api.GradleScriptException: A problem occurred evaluating root project 'rt-b41445afa464'. > at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:93) > at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl$2.run(DefaultScriptPluginFactory.java:177) > at org.gradle.configuration.ProjectScriptTarget.addConfiguration(ProjectScriptTarget.java:77) > at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:182) > at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:38) > at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:25) > at org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34) > at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:55) > at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:540) > at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:93) > at org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:42) > at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:35) > at org.gradle.initialization.DefaultGradleLauncher$2.run(DefaultGradleLauncher.java:124) > at org.gradle.internal.Factories$1.create(Factories.java:22) > at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) > at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53) > at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:121) > at org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:32) > at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:98) > at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:92) > at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) > at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63) > at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:92) > at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:83) > at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:99) > at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28) > at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35) > at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:48) > at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:30) > at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:81) > at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:46) > at org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:51) > at org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:28) > at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43) > at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173) > at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:239) > at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:212) > at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35) > at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24) > at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33) > at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22) > at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:205) > at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169) > at org.gradle.launcher.Main.doAction(Main.java:33) > at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) > at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:55) > at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:36) > at org.gradle.launcher.GradleMain.main(GradleMain.java:23) > Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0 > at org.gradle.groovy.scripts.AbstractUriScriptSource.classNameFromPath(AbstractUriScriptSource.java:54) > at org.gradle.groovy.scripts.AbstractUriScriptSource.getClassName(AbstractUriScriptSource.java:40) > at org.gradle.groovy.scripts.DelegatingScriptSource.getClassName(DelegatingScriptSource.java:32) > at org.gradle.groovy.scripts.internal.BuildScopeInMemoryCachingScriptClassCompiler.compile(BuildScopeInMemoryCachingScriptClassCompiler.java:45) > at org.gradle.groovy.scripts.DefaultScriptCompilerFactory$ScriptCompilerImpl.compile(DefaultScriptCompilerFactory.java:50) > at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:152) > at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyScript(DefaultObjectConfigurationAction.java:102) > at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$000(DefaultObjectConfigurationAction.java:36) > at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$1.run(DefaultObjectConfigurationAction.java:62) > at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:136) > at org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46) > at org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.java:34) > at build_17kvkvc4f9j45htivwn1v303b$_run_closure5.doCall(/tmp/rt-b41445afa464/build.gradle:614) > at build_17kvkvc4f9j45htivwn1v303b.run(/tmp/rt-b41445afa464/build.gradle:612) > at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:91) > ... 47 more > > > BUILD FAILED > > Total time: 19.946 secs -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From philip.race at oracle.com Thu Aug 4 14:28:57 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 04 Aug 2016 07:28:57 -0700 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <57A34EA1.2030009@Oracle.com> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> Message-ID: <57A35129.3000702@oracle.com> On 8/4/16, 7:18 AM, David Hill wrote: > On 8/4/16, 9:50 AM, Turvamies IT Security Services wrote: >> Hello, world! > > This really looks like a Gradle failure to me. That is what I said when this was posted to build-dev. > First there is the bit about the lock being held, then issues with the > cache (are you behind a blocking firewall, proxy set ?), then the > exceptions in gradle itself. > > I think most of the team is using Gradle 2.11, so it might be remotely > possible that is the issue too. 2.13 works for me but I am not using BSD ... > > I would assume you have looked at: > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX, > > There are prebuilt binaries out there if you just want to have > binaries to play with: > > http://chriswhocodes.com/ None of these are for BSD (SFAICS). -phil. >> >> Apologies for the cross post, but since the bsd-port-dev list appears >> to be >> very quiet (and since I'm in a hurry), I'll post my question here too. >> >> I'm attempting to compile OpenJFX (rt-b41445afa464) on OpenBSD CURRENT >> (2016-08-04) since the official OpenBSD package (and port) of OpenJDK >> does not include OpenJFX. >> >> I have managed to install and/or compile all the dependencies, >> including gradle, but got stuck while compiling OpenJFX itself: >> >> $ pwd >> /tmp/rt-b41445afa464 >> >> $ env >> JAVA_HOME=/usr/local/jdk-1.8.0 >> JDK_HOME=/usr/local/jdk-1.8.0 >> JRE_HOME=/usr/local/jdk-1.8.0 >> PATH=/usr/local/jdk-1.8.0/bin:/tmp/.gradle/wrapper/dists/gradle-2.14-bin/76oc0mnc3ieqtsukq90mp0rxk/gradle-2.14/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin >> >> >> $ gradle --debug >> [...] >> 08:38:44.707 [INFO] >> [org.gradle.configuration.project.BuildScriptProcessor] Evaluating >> root project 'rt-b41445afa464' using build file >> '/tmp/rt-b41445afa464/build.gradle'. >> >> 08:38:44.727 [DEBUG] >> [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire >> shared lock on cp_proj remapped class cache for >> ctdme4j40oppm9q0pdgqhpn3y >> /tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910). >> >> 08:38:44.728 [DEBUG] >> [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. >> >> 08:38:44.729 [DEBUG] >> [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on >> cp_proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y >> (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910). >> >> 08:38:44.732 [DEBUG] >> [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire >> shared lock on proj remapped class cache for >> ctdme4j40oppm9q0pdgqhpn3y >> (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). >> >> 08:38:44.733 [DEBUG] >> [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. >> >> 08:38:44.734 [DEBUG] >> [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on >> proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y >> (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). >> >> >> 08:38:45.852 [INFO] [org.gradle.api.Project] Applying >> COMPILE_FLAGS_FILE 'buildSrc/.gradle' >> >> 08:38:45.859 [DEBUG] >> [org.gradle.configuration.project.BuildScriptProcessor] Timing: >> Running the build script took 1.151 secs >> >> 08:38:45.902 [ERROR] [org.gradle.BuildExceptionReporter] >> >> 08:38:45.904 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: >> Build failed with an exception. >> >> 08:38:45.906 [ERROR] [org.gradle.BuildExceptionReporter] >> >> 08:38:45.907 [ERROR] [org.gradle.BuildExceptionReporter] * Where: >> >> 08:38:45.908 [ERROR] [org.gradle.BuildExceptionReporter] Build file >> '/tmp/rt-b41445afa464/build.gradle' line: >> >> 614 08:38:45.909 [ERROR] [org.gradle.BuildExceptionReporter] >> >> 08:38:45.910 [ERROR] [org.gradle.BuildExceptionReporter] * What went >> wrong: >> >> 08:38:45.911 [ERROR] [org.gradle.BuildExceptionReporter] A problem >> occurred evaluating root project 'rt-b41445afa464'. >> >> 08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter]> String >> index out of range: 0 >> >> 08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter] >> >> 08:38:45.913 [ERROR] [org.gradle.BuildExceptionReporter] * Try: >> >> 08:38:45.914 [ERROR] [org.gradle.BuildExceptionReporter] Run with >> --stacktrace option to get the stack trace. >> >> 08:38:45.916 [LIFECYCLE] [org.gradle.BuildResultLogger] >> >> 08:38:45.917 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED >> >> 08:38:45.918 [LIFECYCLE] [org.gradle.BuildResultLogger] >> >> 08:38:45.919 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: >> 29.999 secs >> >> 08:38:45.931 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] >> Cache Plugin Resolution Cache >> (/tmp/.gradle/caches/2.14/plugin-resolution) was closed 0 times. >> >> I don't quite know how to debug this further. >> >> Any tips would be much appreciated! >> >> Yours, >> >> Jyri >> -- >> Turvamies IT Security Services >> >> P.S. FYI, here's gradle --debug output: >> >> :buildSrc:generateGrammarSource UP-TO-DATE >> :buildSrc:compileJava UP-TO-DATE >> :buildSrc:compileGroovy UP-TO-DATE >> :buildSrc:processResources UP-TO-DATE >> :buildSrc:classes UP-TO-DATE >> :buildSrc:jar UP-TO-DATE >> :buildSrc:assemble UP-TO-DATE >> :buildSrc:compileTestJava UP-TO-DATE >> :buildSrc:compileTestGroovy UP-TO-DATE >> :buildSrc:processTestResources UP-TO-DATE >> :buildSrc:testClasses UP-TO-DATE >> :buildSrc:test UP-TO-DATE >> :buildSrc:check UP-TO-DATE >> :buildSrc:build UP-TO-DATE >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Build file '/tmp/rt-b41445afa464/build.gradle' line: 614 >> >> * What went wrong: >> A problem occurred evaluating root project 'rt-b41445afa464'. >>> String index out of range: 0 >> * Try: >> Run with --info or --debug option to get more log output. >> >> * Exception is: >> org.gradle.api.GradleScriptException: A problem occurred evaluating >> root project 'rt-b41445afa464'. >> at >> org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:93) >> at >> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl$2.run(DefaultScriptPluginFactory.java:177) >> at >> org.gradle.configuration.ProjectScriptTarget.addConfiguration(ProjectScriptTarget.java:77) >> at >> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:182) >> at >> org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:38) >> at >> org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:25) >> at >> org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34) >> at >> org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:55) >> at >> org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:540) >> at >> org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:93) >> at >> org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:42) >> at >> org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:35) >> at >> org.gradle.initialization.DefaultGradleLauncher$2.run(DefaultGradleLauncher.java:124) >> at org.gradle.internal.Factories$1.create(Factories.java:22) >> at >> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) >> at >> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53) >> at >> org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:121) >> at >> org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:32) >> at >> org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:98) >> at >> org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:92) >> at >> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) >> at >> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63) >> at >> org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:92) >> at >> org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:83) >> at >> org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:99) >> at >> org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28) >> at >> org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35) >> at >> org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:48) >> at >> org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:30) >> at >> org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:81) >> at >> org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:46) >> at >> org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:51) >> at >> org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:28) >> at >> org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43) >> at >> org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173) >> at >> org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:239) >> at >> org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:212) >> at >> org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35) >> at >> org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24) >> at >> org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33) >> at >> org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22) >> at >> org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:205) >> at >> org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169) >> at org.gradle.launcher.Main.doAction(Main.java:33) >> at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) >> at >> org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:55) >> at >> org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:36) >> at org.gradle.launcher.GradleMain.main(GradleMain.java:23) >> Caused by: java.lang.StringIndexOutOfBoundsException: String index >> out of range: 0 >> at >> org.gradle.groovy.scripts.AbstractUriScriptSource.classNameFromPath(AbstractUriScriptSource.java:54) >> at >> org.gradle.groovy.scripts.AbstractUriScriptSource.getClassName(AbstractUriScriptSource.java:40) >> at >> org.gradle.groovy.scripts.DelegatingScriptSource.getClassName(DelegatingScriptSource.java:32) >> at >> org.gradle.groovy.scripts.internal.BuildScopeInMemoryCachingScriptClassCompiler.compile(BuildScopeInMemoryCachingScriptClassCompiler.java:45) >> at >> org.gradle.groovy.scripts.DefaultScriptCompilerFactory$ScriptCompilerImpl.compile(DefaultScriptCompilerFactory.java:50) >> at >> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:152) >> at >> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyScript(DefaultObjectConfigurationAction.java:102) >> at >> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$000(DefaultObjectConfigurationAction.java:36) >> at >> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$1.run(DefaultObjectConfigurationAction.java:62) >> at >> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:136) >> at >> org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46) >> at >> org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.java:34) >> at >> build_17kvkvc4f9j45htivwn1v303b$_run_closure5.doCall(/tmp/rt-b41445afa464/build.gradle:614) >> at >> build_17kvkvc4f9j45htivwn1v303b.run(/tmp/rt-b41445afa464/build.gradle:612) >> at >> org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:91) >> ... 47 more >> >> >> BUILD FAILED >> >> Total time: 19.946 secs > > From kevin.rushforth at oracle.com Thu Aug 4 14:30:17 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 04 Aug 2016 07:30:17 -0700 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <57A35129.3000702@oracle.com> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35129.3000702@oracle.com> Message-ID: <57A35179.2040601@oracle.com> In particular, we have run into some problems using gradle 2.14 (it fails running 'gradle test' on all platforms), so please download gradle 2.11 (2.12 and 2.13 are also known to work). Alternatively, you can use gradlew as follows: gradle wrapper --gradle-version 2.11 gradlew sdk -- Kevin Philip Race wrote: > > > On 8/4/16, 7:18 AM, David Hill wrote: >> On 8/4/16, 9:50 AM, Turvamies IT Security Services wrote: >>> Hello, world! >> >> This really looks like a Gradle failure to me. > > That is what I said when this was posted to build-dev. > >> First there is the bit about the lock being held, then issues with >> the cache (are you behind a blocking firewall, proxy set ?), then the >> exceptions in gradle itself. >> >> I think most of the team is using Gradle 2.11, so it might be >> remotely possible that is the issue too. > > 2.13 works for me but I am not using BSD ... > >> >> I would assume you have looked at: >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX, >> >> There are prebuilt binaries out there if you just want to have >> binaries to play with: >> >> http://chriswhocodes.com/ > > None of these are for BSD (SFAICS). > > -phil. > >>> >>> Apologies for the cross post, but since the bsd-port-dev list >>> appears to be >>> very quiet (and since I'm in a hurry), I'll post my question here too. >>> >>> I'm attempting to compile OpenJFX (rt-b41445afa464) on OpenBSD CURRENT >>> (2016-08-04) since the official OpenBSD package (and port) of OpenJDK >>> does not include OpenJFX. >>> >>> I have managed to install and/or compile all the dependencies, >>> including gradle, but got stuck while compiling OpenJFX itself: >>> >>> $ pwd >>> /tmp/rt-b41445afa464 >>> >>> $ env >>> JAVA_HOME=/usr/local/jdk-1.8.0 >>> JDK_HOME=/usr/local/jdk-1.8.0 >>> JRE_HOME=/usr/local/jdk-1.8.0 >>> PATH=/usr/local/jdk-1.8.0/bin:/tmp/.gradle/wrapper/dists/gradle-2.14-bin/76oc0mnc3ieqtsukq90mp0rxk/gradle-2.14/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin >>> >>> >>> $ gradle --debug >>> [...] >>> 08:38:44.707 [INFO] >>> [org.gradle.configuration.project.BuildScriptProcessor] Evaluating >>> root project 'rt-b41445afa464' using build file >>> '/tmp/rt-b41445afa464/build.gradle'. >>> >>> 08:38:44.727 [DEBUG] >>> [org.gradle.cache.internal.DefaultFileLockManager] Waiting to >>> acquire shared lock on cp_proj remapped class cache for >>> ctdme4j40oppm9q0pdgqhpn3y >>> /tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910). >>> >>> >>> 08:38:44.728 [DEBUG] >>> [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. >>> >>> 08:38:44.729 [DEBUG] >>> [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on >>> cp_proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y >>> (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910). >>> >>> >>> 08:38:44.732 [DEBUG] >>> [org.gradle.cache.internal.DefaultFileLockManager] Waiting to >>> acquire shared lock on proj remapped class cache for >>> ctdme4j40oppm9q0pdgqhpn3y >>> (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). >>> >>> >>> 08:38:44.733 [DEBUG] >>> [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. >>> >>> 08:38:44.734 [DEBUG] >>> [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on >>> proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y >>> (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). >>> >>> >>> 08:38:45.852 [INFO] [org.gradle.api.Project] Applying >>> COMPILE_FLAGS_FILE 'buildSrc/.gradle' >>> >>> 08:38:45.859 [DEBUG] >>> [org.gradle.configuration.project.BuildScriptProcessor] Timing: >>> Running the build script took 1.151 secs >>> >>> 08:38:45.902 [ERROR] [org.gradle.BuildExceptionReporter] >>> >>> 08:38:45.904 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: >>> Build failed with an exception. >>> >>> 08:38:45.906 [ERROR] [org.gradle.BuildExceptionReporter] >>> >>> 08:38:45.907 [ERROR] [org.gradle.BuildExceptionReporter] * Where: >>> >>> 08:38:45.908 [ERROR] [org.gradle.BuildExceptionReporter] Build file >>> '/tmp/rt-b41445afa464/build.gradle' line: >>> >>> 614 08:38:45.909 [ERROR] [org.gradle.BuildExceptionReporter] >>> >>> 08:38:45.910 [ERROR] [org.gradle.BuildExceptionReporter] * What went >>> wrong: >>> >>> 08:38:45.911 [ERROR] [org.gradle.BuildExceptionReporter] A problem >>> occurred evaluating root project 'rt-b41445afa464'. >>> >>> 08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter]> String >>> index out of range: 0 >>> >>> 08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter] >>> >>> 08:38:45.913 [ERROR] [org.gradle.BuildExceptionReporter] * Try: >>> >>> 08:38:45.914 [ERROR] [org.gradle.BuildExceptionReporter] Run with >>> --stacktrace option to get the stack trace. >>> >>> 08:38:45.916 [LIFECYCLE] [org.gradle.BuildResultLogger] >>> >>> 08:38:45.917 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED >>> >>> 08:38:45.918 [LIFECYCLE] [org.gradle.BuildResultLogger] >>> >>> 08:38:45.919 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: >>> 29.999 secs >>> >>> 08:38:45.931 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] >>> Cache Plugin Resolution Cache >>> (/tmp/.gradle/caches/2.14/plugin-resolution) was closed 0 times. >>> >>> I don't quite know how to debug this further. >>> >>> Any tips would be much appreciated! >>> >>> Yours, >>> >>> Jyri >>> -- >>> Turvamies IT Security Services >>> >>> P.S. FYI, here's gradle --debug output: >>> >>> :buildSrc:generateGrammarSource UP-TO-DATE >>> :buildSrc:compileJava UP-TO-DATE >>> :buildSrc:compileGroovy UP-TO-DATE >>> :buildSrc:processResources UP-TO-DATE >>> :buildSrc:classes UP-TO-DATE >>> :buildSrc:jar UP-TO-DATE >>> :buildSrc:assemble UP-TO-DATE >>> :buildSrc:compileTestJava UP-TO-DATE >>> :buildSrc:compileTestGroovy UP-TO-DATE >>> :buildSrc:processTestResources UP-TO-DATE >>> :buildSrc:testClasses UP-TO-DATE >>> :buildSrc:test UP-TO-DATE >>> :buildSrc:check UP-TO-DATE >>> :buildSrc:build UP-TO-DATE >>> >>> FAILURE: Build failed with an exception. >>> >>> * Where: >>> Build file '/tmp/rt-b41445afa464/build.gradle' line: 614 >>> >>> * What went wrong: >>> A problem occurred evaluating root project 'rt-b41445afa464'. >>>> String index out of range: 0 >>> * Try: >>> Run with --info or --debug option to get more log output. >>> >>> * Exception is: >>> org.gradle.api.GradleScriptException: A problem occurred evaluating >>> root project 'rt-b41445afa464'. >>> at >>> org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:93) >>> >>> at >>> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl$2.run(DefaultScriptPluginFactory.java:177) >>> >>> at >>> org.gradle.configuration.ProjectScriptTarget.addConfiguration(ProjectScriptTarget.java:77) >>> >>> at >>> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:182) >>> >>> at >>> org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:38) >>> >>> at >>> org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:25) >>> >>> at >>> org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34) >>> >>> at >>> org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:55) >>> >>> at >>> org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:540) >>> >>> at >>> org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:93) >>> >>> at >>> org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:42) >>> >>> at >>> org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:35) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher$2.run(DefaultGradleLauncher.java:124) >>> >>> at org.gradle.internal.Factories$1.create(Factories.java:22) >>> at >>> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) >>> >>> at >>> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:121) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:32) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:98) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:92) >>> >>> at >>> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) >>> >>> at >>> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:92) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:83) >>> >>> at >>> org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:99) >>> >>> at >>> org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28) >>> >>> at >>> org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35) >>> >>> at >>> org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:48) >>> >>> at >>> org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:30) >>> >>> at >>> org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:81) >>> >>> at >>> org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:46) >>> >>> at >>> org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:51) >>> >>> at >>> org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:28) >>> >>> at >>> org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43) >>> at >>> org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173) >>> >>> at >>> org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:239) >>> >>> at >>> org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:212) >>> >>> at >>> org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35) >>> >>> at >>> org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24) >>> >>> at >>> org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33) >>> >>> at >>> org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22) >>> >>> at >>> org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:205) >>> >>> at >>> org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169) >>> >>> at org.gradle.launcher.Main.doAction(Main.java:33) >>> at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) >>> at >>> org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:55) >>> >>> at >>> org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:36) >>> >>> at org.gradle.launcher.GradleMain.main(GradleMain.java:23) >>> Caused by: java.lang.StringIndexOutOfBoundsException: String index >>> out of range: 0 >>> at >>> org.gradle.groovy.scripts.AbstractUriScriptSource.classNameFromPath(AbstractUriScriptSource.java:54) >>> >>> at >>> org.gradle.groovy.scripts.AbstractUriScriptSource.getClassName(AbstractUriScriptSource.java:40) >>> >>> at >>> org.gradle.groovy.scripts.DelegatingScriptSource.getClassName(DelegatingScriptSource.java:32) >>> >>> at >>> org.gradle.groovy.scripts.internal.BuildScopeInMemoryCachingScriptClassCompiler.compile(BuildScopeInMemoryCachingScriptClassCompiler.java:45) >>> >>> at >>> org.gradle.groovy.scripts.DefaultScriptCompilerFactory$ScriptCompilerImpl.compile(DefaultScriptCompilerFactory.java:50) >>> >>> at >>> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:152) >>> >>> at >>> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyScript(DefaultObjectConfigurationAction.java:102) >>> >>> at >>> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$000(DefaultObjectConfigurationAction.java:36) >>> >>> at >>> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$1.run(DefaultObjectConfigurationAction.java:62) >>> >>> at >>> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:136) >>> >>> at >>> org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46) >>> >>> at >>> org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.java:34) >>> >>> at >>> build_17kvkvc4f9j45htivwn1v303b$_run_closure5.doCall(/tmp/rt-b41445afa464/build.gradle:614) >>> >>> at >>> build_17kvkvc4f9j45htivwn1v303b.run(/tmp/rt-b41445afa464/build.gradle:612) >>> >>> at >>> org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:91) >>> >>> ... 47 more >>> >>> >>> BUILD FAILED >>> >>> Total time: 19.946 secs >> >> From vadim.pakhnushev at oracle.com Thu Aug 4 14:28:12 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Thu, 4 Aug 2016 17:28:12 +0300 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <57A34EA1.2030009@Oracle.com> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> Message-ID: I'd say the culprit is here: 08:38:45.852 [INFO] [org.gradle.api.Project] Applying COMPILE_FLAGS_FILE 'buildSrc/.gradle' I think that COMPILE_TARGETS is "" since it's not a "mac", not a "win" nor a "linux". Vadim On 04.08.2016 17:18, David Hill wrote: > On 8/4/16, 9:50 AM, Turvamies IT Security Services wrote: >> Hello, world! > > This really looks like a Gradle failure to me. First there is the bit > about the lock being held, then issues with the cache (are you behind > a blocking firewall, proxy set ?), then the exceptions in gradle itself. > > I think most of the team is using Gradle 2.11, so it might be remotely > possible that is the issue too. > > I would assume you have looked at: > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX, > > There are prebuilt binaries out there if you just want to have > binaries to play with: > > http://chriswhocodes.com/ >> >> Apologies for the cross post, but since the bsd-port-dev list appears >> to be >> very quiet (and since I'm in a hurry), I'll post my question here too. >> >> I'm attempting to compile OpenJFX (rt-b41445afa464) on OpenBSD CURRENT >> (2016-08-04) since the official OpenBSD package (and port) of OpenJDK >> does not include OpenJFX. >> >> I have managed to install and/or compile all the dependencies, >> including gradle, but got stuck while compiling OpenJFX itself: >> >> $ pwd >> /tmp/rt-b41445afa464 >> >> $ env >> JAVA_HOME=/usr/local/jdk-1.8.0 >> JDK_HOME=/usr/local/jdk-1.8.0 >> JRE_HOME=/usr/local/jdk-1.8.0 >> PATH=/usr/local/jdk-1.8.0/bin:/tmp/.gradle/wrapper/dists/gradle-2.14-bin/76oc0mnc3ieqtsukq90mp0rxk/gradle-2.14/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin >> >> >> $ gradle --debug >> [...] >> 08:38:44.707 [INFO] >> [org.gradle.configuration.project.BuildScriptProcessor] Evaluating >> root project 'rt-b41445afa464' using build file >> '/tmp/rt-b41445afa464/build.gradle'. >> >> 08:38:44.727 [DEBUG] >> [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire >> shared lock on cp_proj remapped class cache for >> ctdme4j40oppm9q0pdgqhpn3y >> /tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910). >> >> 08:38:44.728 [DEBUG] >> [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. >> >> 08:38:44.729 [DEBUG] >> [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on >> cp_proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y >> (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910). >> >> 08:38:44.732 [DEBUG] >> [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire >> shared lock on proj remapped class cache for >> ctdme4j40oppm9q0pdgqhpn3y >> (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). >> >> 08:38:44.733 [DEBUG] >> [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. >> >> 08:38:44.734 [DEBUG] >> [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on >> proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y >> (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). >> >> >> 08:38:45.852 [INFO] [org.gradle.api.Project] Applying >> COMPILE_FLAGS_FILE 'buildSrc/.gradle' >> >> 08:38:45.859 [DEBUG] >> [org.gradle.configuration.project.BuildScriptProcessor] Timing: >> Running the build script took 1.151 secs >> >> 08:38:45.902 [ERROR] [org.gradle.BuildExceptionReporter] >> >> 08:38:45.904 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: >> Build failed with an exception. >> >> 08:38:45.906 [ERROR] [org.gradle.BuildExceptionReporter] >> >> 08:38:45.907 [ERROR] [org.gradle.BuildExceptionReporter] * Where: >> >> 08:38:45.908 [ERROR] [org.gradle.BuildExceptionReporter] Build file >> '/tmp/rt-b41445afa464/build.gradle' line: >> >> 614 08:38:45.909 [ERROR] [org.gradle.BuildExceptionReporter] >> >> 08:38:45.910 [ERROR] [org.gradle.BuildExceptionReporter] * What went >> wrong: >> >> 08:38:45.911 [ERROR] [org.gradle.BuildExceptionReporter] A problem >> occurred evaluating root project 'rt-b41445afa464'. >> >> 08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter]> String >> index out of range: 0 >> >> 08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter] >> >> 08:38:45.913 [ERROR] [org.gradle.BuildExceptionReporter] * Try: >> >> 08:38:45.914 [ERROR] [org.gradle.BuildExceptionReporter] Run with >> --stacktrace option to get the stack trace. >> >> 08:38:45.916 [LIFECYCLE] [org.gradle.BuildResultLogger] >> >> 08:38:45.917 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED >> >> 08:38:45.918 [LIFECYCLE] [org.gradle.BuildResultLogger] >> >> 08:38:45.919 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: >> 29.999 secs >> >> 08:38:45.931 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] >> Cache Plugin Resolution Cache >> (/tmp/.gradle/caches/2.14/plugin-resolution) was closed 0 times. >> >> I don't quite know how to debug this further. >> >> Any tips would be much appreciated! >> >> Yours, >> >> Jyri >> -- >> Turvamies IT Security Services >> >> P.S. FYI, here's gradle --debug output: >> >> :buildSrc:generateGrammarSource UP-TO-DATE >> :buildSrc:compileJava UP-TO-DATE >> :buildSrc:compileGroovy UP-TO-DATE >> :buildSrc:processResources UP-TO-DATE >> :buildSrc:classes UP-TO-DATE >> :buildSrc:jar UP-TO-DATE >> :buildSrc:assemble UP-TO-DATE >> :buildSrc:compileTestJava UP-TO-DATE >> :buildSrc:compileTestGroovy UP-TO-DATE >> :buildSrc:processTestResources UP-TO-DATE >> :buildSrc:testClasses UP-TO-DATE >> :buildSrc:test UP-TO-DATE >> :buildSrc:check UP-TO-DATE >> :buildSrc:build UP-TO-DATE >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Build file '/tmp/rt-b41445afa464/build.gradle' line: 614 >> >> * What went wrong: >> A problem occurred evaluating root project 'rt-b41445afa464'. >>> String index out of range: 0 >> * Try: >> Run with --info or --debug option to get more log output. >> >> * Exception is: >> org.gradle.api.GradleScriptException: A problem occurred evaluating >> root project 'rt-b41445afa464'. >> at >> org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:93) >> at >> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl$2.run(DefaultScriptPluginFactory.java:177) >> at >> org.gradle.configuration.ProjectScriptTarget.addConfiguration(ProjectScriptTarget.java:77) >> at >> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:182) >> at >> org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:38) >> at >> org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:25) >> at >> org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34) >> at >> org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:55) >> at >> org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:540) >> at >> org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:93) >> at >> org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:42) >> at >> org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:35) >> at >> org.gradle.initialization.DefaultGradleLauncher$2.run(DefaultGradleLauncher.java:124) >> at org.gradle.internal.Factories$1.create(Factories.java:22) >> at >> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) >> at >> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53) >> at >> org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:121) >> at >> org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:32) >> at >> org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:98) >> at >> org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:92) >> at >> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) >> at >> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63) >> at >> org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:92) >> at >> org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:83) >> at >> org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:99) >> at >> org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28) >> at >> org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35) >> at >> org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:48) >> at >> org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:30) >> at >> org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:81) >> at >> org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:46) >> at >> org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:51) >> at >> org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:28) >> at >> org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43) >> at >> org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173) >> at >> org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:239) >> at >> org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:212) >> at >> org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35) >> at >> org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24) >> at >> org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33) >> at >> org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22) >> at >> org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:205) >> at >> org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169) >> at org.gradle.launcher.Main.doAction(Main.java:33) >> at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) >> at >> org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:55) >> at >> org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:36) >> at org.gradle.launcher.GradleMain.main(GradleMain.java:23) >> Caused by: java.lang.StringIndexOutOfBoundsException: String index >> out of range: 0 >> at >> org.gradle.groovy.scripts.AbstractUriScriptSource.classNameFromPath(AbstractUriScriptSource.java:54) >> at >> org.gradle.groovy.scripts.AbstractUriScriptSource.getClassName(AbstractUriScriptSource.java:40) >> at >> org.gradle.groovy.scripts.DelegatingScriptSource.getClassName(DelegatingScriptSource.java:32) >> at >> org.gradle.groovy.scripts.internal.BuildScopeInMemoryCachingScriptClassCompiler.compile(BuildScopeInMemoryCachingScriptClassCompiler.java:45) >> at >> org.gradle.groovy.scripts.DefaultScriptCompilerFactory$ScriptCompilerImpl.compile(DefaultScriptCompilerFactory.java:50) >> at >> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:152) >> at >> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyScript(DefaultObjectConfigurationAction.java:102) >> at >> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$000(DefaultObjectConfigurationAction.java:36) >> at >> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$1.run(DefaultObjectConfigurationAction.java:62) >> at >> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:136) >> at >> org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46) >> at >> org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.java:34) >> at >> build_17kvkvc4f9j45htivwn1v303b$_run_closure5.doCall(/tmp/rt-b41445afa464/build.gradle:614) >> at >> build_17kvkvc4f9j45htivwn1v303b.run(/tmp/rt-b41445afa464/build.gradle:612) >> at >> org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:91) >> ... 47 more >> >> >> BUILD FAILED >> >> Total time: 19.946 secs > > From kevin.rushforth at oracle.com Thu Aug 4 14:33:39 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 04 Aug 2016 07:33:39 -0700 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> Message-ID: <57A35243.9030406@oracle.com> Ah, you might be right, in which case gradle 2.11 won't solve his problem. -- Kevin Vadim Pakhnushev wrote: > I'd say the culprit is here: > > 08:38:45.852 [INFO] [org.gradle.api.Project] Applying > COMPILE_FLAGS_FILE 'buildSrc/.gradle' > > I think that COMPILE_TARGETS is "" since it's not a "mac", not a "win" > nor a "linux". > > Vadim > > On 04.08.2016 17:18, David Hill wrote: >> On 8/4/16, 9:50 AM, Turvamies IT Security Services wrote: >>> Hello, world! >> >> This really looks like a Gradle failure to me. First there is the bit >> about the lock being held, then issues with the cache (are you behind >> a blocking firewall, proxy set ?), then the exceptions in gradle itself. >> >> I think most of the team is using Gradle 2.11, so it might be >> remotely possible that is the issue too. >> >> I would assume you have looked at: >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX, >> >> There are prebuilt binaries out there if you just want to have >> binaries to play with: >> >> http://chriswhocodes.com/ >>> >>> Apologies for the cross post, but since the bsd-port-dev list >>> appears to be >>> very quiet (and since I'm in a hurry), I'll post my question here too. >>> >>> I'm attempting to compile OpenJFX (rt-b41445afa464) on OpenBSD CURRENT >>> (2016-08-04) since the official OpenBSD package (and port) of OpenJDK >>> does not include OpenJFX. >>> >>> I have managed to install and/or compile all the dependencies, >>> including gradle, but got stuck while compiling OpenJFX itself: >>> >>> $ pwd >>> /tmp/rt-b41445afa464 >>> >>> $ env >>> JAVA_HOME=/usr/local/jdk-1.8.0 >>> JDK_HOME=/usr/local/jdk-1.8.0 >>> JRE_HOME=/usr/local/jdk-1.8.0 >>> PATH=/usr/local/jdk-1.8.0/bin:/tmp/.gradle/wrapper/dists/gradle-2.14-bin/76oc0mnc3ieqtsukq90mp0rxk/gradle-2.14/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin >>> >>> >>> $ gradle --debug >>> [...] >>> 08:38:44.707 [INFO] >>> [org.gradle.configuration.project.BuildScriptProcessor] Evaluating >>> root project 'rt-b41445afa464' using build file >>> '/tmp/rt-b41445afa464/build.gradle'. >>> >>> 08:38:44.727 [DEBUG] >>> [org.gradle.cache.internal.DefaultFileLockManager] Waiting to >>> acquire shared lock on cp_proj remapped class cache for >>> ctdme4j40oppm9q0pdgqhpn3y >>> /tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910). >>> >>> >>> 08:38:44.728 [DEBUG] >>> [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. >>> >>> 08:38:44.729 [DEBUG] >>> [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on >>> cp_proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y >>> (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910). >>> >>> >>> 08:38:44.732 [DEBUG] >>> [org.gradle.cache.internal.DefaultFileLockManager] Waiting to >>> acquire shared lock on proj remapped class cache for >>> ctdme4j40oppm9q0pdgqhpn3y >>> (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). >>> >>> >>> 08:38:44.733 [DEBUG] >>> [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. >>> >>> 08:38:44.734 [DEBUG] >>> [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on >>> proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y >>> (/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). >>> >>> >>> 08:38:45.852 [INFO] [org.gradle.api.Project] Applying >>> COMPILE_FLAGS_FILE 'buildSrc/.gradle' >>> >>> 08:38:45.859 [DEBUG] >>> [org.gradle.configuration.project.BuildScriptProcessor] Timing: >>> Running the build script took 1.151 secs >>> >>> 08:38:45.902 [ERROR] [org.gradle.BuildExceptionReporter] >>> >>> 08:38:45.904 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: >>> Build failed with an exception. >>> >>> 08:38:45.906 [ERROR] [org.gradle.BuildExceptionReporter] >>> >>> 08:38:45.907 [ERROR] [org.gradle.BuildExceptionReporter] * Where: >>> >>> 08:38:45.908 [ERROR] [org.gradle.BuildExceptionReporter] Build file >>> '/tmp/rt-b41445afa464/build.gradle' line: >>> >>> 614 08:38:45.909 [ERROR] [org.gradle.BuildExceptionReporter] >>> >>> 08:38:45.910 [ERROR] [org.gradle.BuildExceptionReporter] * What went >>> wrong: >>> >>> 08:38:45.911 [ERROR] [org.gradle.BuildExceptionReporter] A problem >>> occurred evaluating root project 'rt-b41445afa464'. >>> >>> 08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter]> String >>> index out of range: 0 >>> >>> 08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter] >>> >>> 08:38:45.913 [ERROR] [org.gradle.BuildExceptionReporter] * Try: >>> >>> 08:38:45.914 [ERROR] [org.gradle.BuildExceptionReporter] Run with >>> --stacktrace option to get the stack trace. >>> >>> 08:38:45.916 [LIFECYCLE] [org.gradle.BuildResultLogger] >>> >>> 08:38:45.917 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED >>> >>> 08:38:45.918 [LIFECYCLE] [org.gradle.BuildResultLogger] >>> >>> 08:38:45.919 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: >>> 29.999 secs >>> >>> 08:38:45.931 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] >>> Cache Plugin Resolution Cache >>> (/tmp/.gradle/caches/2.14/plugin-resolution) was closed 0 times. >>> >>> I don't quite know how to debug this further. >>> >>> Any tips would be much appreciated! >>> >>> Yours, >>> >>> Jyri >>> -- >>> Turvamies IT Security Services >>> >>> P.S. FYI, here's gradle --debug output: >>> >>> :buildSrc:generateGrammarSource UP-TO-DATE >>> :buildSrc:compileJava UP-TO-DATE >>> :buildSrc:compileGroovy UP-TO-DATE >>> :buildSrc:processResources UP-TO-DATE >>> :buildSrc:classes UP-TO-DATE >>> :buildSrc:jar UP-TO-DATE >>> :buildSrc:assemble UP-TO-DATE >>> :buildSrc:compileTestJava UP-TO-DATE >>> :buildSrc:compileTestGroovy UP-TO-DATE >>> :buildSrc:processTestResources UP-TO-DATE >>> :buildSrc:testClasses UP-TO-DATE >>> :buildSrc:test UP-TO-DATE >>> :buildSrc:check UP-TO-DATE >>> :buildSrc:build UP-TO-DATE >>> >>> FAILURE: Build failed with an exception. >>> >>> * Where: >>> Build file '/tmp/rt-b41445afa464/build.gradle' line: 614 >>> >>> * What went wrong: >>> A problem occurred evaluating root project 'rt-b41445afa464'. >>>> String index out of range: 0 >>> * Try: >>> Run with --info or --debug option to get more log output. >>> >>> * Exception is: >>> org.gradle.api.GradleScriptException: A problem occurred evaluating >>> root project 'rt-b41445afa464'. >>> at >>> org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:93) >>> >>> at >>> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl$2.run(DefaultScriptPluginFactory.java:177) >>> >>> at >>> org.gradle.configuration.ProjectScriptTarget.addConfiguration(ProjectScriptTarget.java:77) >>> >>> at >>> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:182) >>> >>> at >>> org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:38) >>> >>> at >>> org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:25) >>> >>> at >>> org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34) >>> >>> at >>> org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:55) >>> >>> at >>> org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:540) >>> >>> at >>> org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:93) >>> >>> at >>> org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:42) >>> >>> at >>> org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:35) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher$2.run(DefaultGradleLauncher.java:124) >>> >>> at org.gradle.internal.Factories$1.create(Factories.java:22) >>> at >>> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) >>> >>> at >>> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:121) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:32) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:98) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:92) >>> >>> at >>> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) >>> >>> at >>> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:92) >>> >>> at >>> org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:83) >>> >>> at >>> org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:99) >>> >>> at >>> org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28) >>> >>> at >>> org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35) >>> >>> at >>> org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:48) >>> >>> at >>> org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:30) >>> >>> at >>> org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:81) >>> >>> at >>> org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:46) >>> >>> at >>> org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:51) >>> >>> at >>> org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:28) >>> >>> at >>> org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43) >>> at >>> org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173) >>> >>> at >>> org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:239) >>> >>> at >>> org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:212) >>> >>> at >>> org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35) >>> >>> at >>> org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24) >>> >>> at >>> org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33) >>> >>> at >>> org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22) >>> >>> at >>> org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:205) >>> >>> at >>> org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169) >>> >>> at org.gradle.launcher.Main.doAction(Main.java:33) >>> at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) >>> at >>> org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:55) >>> >>> at >>> org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:36) >>> >>> at org.gradle.launcher.GradleMain.main(GradleMain.java:23) >>> Caused by: java.lang.StringIndexOutOfBoundsException: String index >>> out of range: 0 >>> at >>> org.gradle.groovy.scripts.AbstractUriScriptSource.classNameFromPath(AbstractUriScriptSource.java:54) >>> >>> at >>> org.gradle.groovy.scripts.AbstractUriScriptSource.getClassName(AbstractUriScriptSource.java:40) >>> >>> at >>> org.gradle.groovy.scripts.DelegatingScriptSource.getClassName(DelegatingScriptSource.java:32) >>> >>> at >>> org.gradle.groovy.scripts.internal.BuildScopeInMemoryCachingScriptClassCompiler.compile(BuildScopeInMemoryCachingScriptClassCompiler.java:45) >>> >>> at >>> org.gradle.groovy.scripts.DefaultScriptCompilerFactory$ScriptCompilerImpl.compile(DefaultScriptCompilerFactory.java:50) >>> >>> at >>> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:152) >>> >>> at >>> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyScript(DefaultObjectConfigurationAction.java:102) >>> >>> at >>> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$000(DefaultObjectConfigurationAction.java:36) >>> >>> at >>> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$1.run(DefaultObjectConfigurationAction.java:62) >>> >>> at >>> org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:136) >>> >>> at >>> org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46) >>> >>> at >>> org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.java:34) >>> >>> at >>> build_17kvkvc4f9j45htivwn1v303b$_run_closure5.doCall(/tmp/rt-b41445afa464/build.gradle:614) >>> >>> at >>> build_17kvkvc4f9j45htivwn1v303b.run(/tmp/rt-b41445afa464/build.gradle:612) >>> >>> at >>> org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:91) >>> >>> ... 47 more >>> >>> >>> BUILD FAILED >>> >>> Total time: 19.946 secs >> >> > From info at turvamies.fi Thu Aug 4 14:48:04 2016 From: info at turvamies.fi (Turvamies IT Security Services) Date: Thu, 4 Aug 2016 14:48:04 +0000 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <57A35243.9030406@oracle.com> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> Message-ID: <20160804144804.63000001@uusilauta.turvamies.local> Guys, I think you're spot on with the COMPILE_TARGETS notion. I did tried compiling gradle 2.11 anyways, but that failed since https://downloads.gradle.org/distributions-snapshots/gradle-2.11-20160112230025+0000-bin.zip does not exist anymore. Any ideas how to proceed from here? Apparently I'll have to come up with a custom OpenBSD COMPILE_TARGET, right? Yours, Jyri -- Turvamies IT Security Services On Thu, 04 Aug 2016 07:33:39 -0700 Kevin Rushforth wrote: > Ah, you might be right, in which case gradle 2.11 won't solve his > problem. > > -- Kevin > > > Vadim Pakhnushev wrote: > > I'd say the culprit is here: > > > > 08:38:45.852 [INFO] [org.gradle.api.Project] Applying > > COMPILE_FLAGS_FILE 'buildSrc/.gradle' > > > > I think that COMPILE_TARGETS is "" since it's not a "mac", not a > > "win" nor a "linux". > > > > Vadim From David.Hill at Oracle.com Thu Aug 4 16:41:16 2016 From: David.Hill at Oracle.com (David Hill) Date: Thu, 04 Aug 2016 12:41:16 -0400 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <20160804144804.63000001@uusilauta.turvamies.local> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> <20160804144804.63000001@uusilauta.turvamies.local> Message-ID: <57A3702C.6060205@Oracle.com> On 8/4/16, 10:48 AM, Turvamies IT Security Services wrote: > Guys, > > I think you're spot on with the COMPILE_TARGETS notion. If you are game, you could try extending this: ext.IS_LINUX = OS_NAME.contains("linux") to be ext.IS_LINUX = OS_NAME.contains("linux") || OS_NAME.contains(what ever is set for bsd) and see what happens. > > I did tried compiling gradle 2.11 anyways, but that failed since > https://downloads.gradle.org/distributions-snapshots/gradle-2.11-20160112230025+0000-bin.zip > does not exist anymore. > > Any ideas how to proceed from here? Apparently I'll have to come up > with a custom OpenBSD COMPILE_TARGET, right? > > Yours, > > Jyri > -- > Turvamies IT Security Services > > On Thu, 04 Aug 2016 07:33:39 -0700 > Kevin Rushforth wrote: > >> Ah, you might be right, in which case gradle 2.11 won't solve his >> problem. >> >> -- Kevin >> >> >> Vadim Pakhnushev wrote: >>> I'd say the culprit is here: >>> >>> 08:38:45.852 [INFO] [org.gradle.api.Project] Applying >>> COMPILE_FLAGS_FILE 'buildSrc/.gradle' >>> >>> I think that COMPILE_TARGETS is "" since it's not a "mac", not a >>> "win" nor a "linux". >>> >>> Vadim -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From David.Hill at Oracle.com Thu Aug 4 16:58:42 2016 From: David.Hill at Oracle.com (David Hill) Date: Thu, 04 Aug 2016 12:58:42 -0400 Subject: review: Build should fail fast with unsupported OS/ARCH Message-ID: <57A37442.3060902@Oracle.com> thanks to Jyri's email, I have a simple fix to fail quickly and with a understandable error message. jbs: https://bugs.openjdk.java.net/browse/JDK-8163196 simple diff inside jbs -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From jyri.hovila at iki.fi Thu Aug 4 17:32:18 2016 From: jyri.hovila at iki.fi (Jyri Hovila [iki.fi]) Date: Thu, 4 Aug 2016 17:32:18 +0000 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <57A3702C.6060205@Oracle.com> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> <20160804144804.63000001@uusilauta.turvamies.local> <57A3702C.6060205@Oracle.com> Message-ID: <20160804173218.2a3981ff@uusilauta.turvamies.local> David, Thanks for the tip! I'm definitely into tweaking with this. > ext.IS_LINUX = OS_NAME.contains("linux") || OS_NAME.contains(what > ever is set for bsd) > > and see what happens. I edited build.gradle: Now there's an issue with g++, apparently due to differences in command line options between OpenBSD and Linux versions of g++: $ gradle sdk [...] :fxpackager:linkLinuxLauncher/usr/bin/ld: cannot find -ldl collect2: ld returned 1 exit status FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':fxpackager:linkLinuxLauncher'. > Process 'command 'g++'' finished with non-zero exit value 1 Here's the stacktrace information: * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':fxpackager:linkLinuxLauncher'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46) at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35) at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:66) at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58) at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53) at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:203) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:185) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:66) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:50) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:25) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:110) at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37) at org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23) at org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecuter.java:43) at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:30) at org.gradle.initialization.DefaultGradleLauncher$4.run(DefaultGradleLauncher.java:153) at org.gradle.internal.Factories$1.create(Factories.java:22) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53) at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:150) at org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:32) at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:98) at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:92) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63) at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:92) at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:83) at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:99) at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28) at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:48) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:30) at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:81) at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:46) at org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:51) at org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:28) at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43) at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173) at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:239) at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:212) at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35) at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:205) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169) at org.gradle.launcher.Main.doAction(Main.java:33) at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:55) at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:36) at org.gradle.launcher.GradleMain.main(GradleMain.java:23) Caused by: org.gradle.process.internal.ExecException: Process 'command 'g++'' finished with non-zero exit value 1 at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:367) at org.gradle.process.internal.DefaultExecAction.execute(DefaultExecAction.java:31) at org.gradle.api.internal.file.DefaultFileOperations.exec(DefaultFileOperations.java:176) at org.gradle.api.internal.project.AbstractProject.exec(AbstractProject.java:856) at org.gradle.api.internal.project.AbstractProject.exec(AbstractProject.java:852) at org.gradle.api.Project$exec$2.call(Unknown Source) at LinkTask.compile(LinkTask.groovy:40) at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:75) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:228) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:221) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:210) at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:621) at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:604) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61) ... 57 more Any ideas on how to proceed? Yours, Jyri -- Turvamies IT Security Services From info at turvamies.fi Thu Aug 4 17:40:04 2016 From: info at turvamies.fi (Turvamies IT Security Services) Date: Thu, 4 Aug 2016 17:40:04 +0000 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <20160804173218.2a3981ff@uusilauta.turvamies.local> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> <20160804144804.63000001@uusilauta.turvamies.local> <57A3702C.6060205@Oracle.com> <20160804173218.2a3981ff@uusilauta.turvamies.local> Message-ID: <20160804174004.43c7cafb@uusilauta.turvamies.local> > I edited build.gradle: ...but forgot to provide the details, so here: build.gradle, lines 253-254: // ext.IS_LINUX = OS_NAME.contains("linux") ext.IS_LINUX = OS_NAME.contains("linux") || OS_NAME.contains("openbsd") The above modification allows gradle to ALMOST build OpenJFX on OpenBSD. The next issue to be solved is the incompatibility in g++ flags. OpenBSD's g++ man page can be found here: http://man.openbsd.org/OpenBSD-current/man1/gcc.1 Yours, Jyri -- Turvamies IT Security Services From info at turvamies.fi Thu Aug 4 17:51:17 2016 From: info at turvamies.fi (Turvamies IT Security Services) Date: Thu, 4 Aug 2016 17:51:17 +0000 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <20160804173218.2a3981ff@uusilauta.turvamies.local> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> <20160804144804.63000001@uusilauta.turvamies.local> <57A3702C.6060205@Oracle.com> <20160804173218.2a3981ff@uusilauta.turvamies.local> Message-ID: <20160804175117.42bc35d8@uusilauta.turvamies.local> Actually, the problem appears to be with ld rather than g++. This thread gave me a hint: https://forums.freebsd.org/threads/5799/ "ldl is libdl. It is a linuxism. FreeBSD does not have a libdl. The same functionality that is in linux's libdl is provided in FreeBSD's libc. So you should be able to simply remove -ldl from CFLAGS and try compile." I know I should edit build.gradle further so that ldl is not included in CFLAGS when compiling on OpenBSD, but I have not worked with gradle build files and would very much appreciate it if you guys could help me out in crafting the proper target definitions for OpenBSD. - Jyri -- Turvamies IT Security Services From David.Hill at Oracle.com Thu Aug 4 17:59:03 2016 From: David.Hill at Oracle.com (David Hill) Date: Thu, 04 Aug 2016 13:59:03 -0400 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <20160804175117.42bc35d8@uusilauta.turvamies.local> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> <20160804144804.63000001@uusilauta.turvamies.local> <57A3702C.6060205@Oracle.com> <20160804173218.2a3981ff@uusilauta.turvamies.local> <20160804175117.42bc35d8@uusilauta.turvamies.local> Message-ID: <57A38267.1010106@Oracle.com> On 8/4/16, 1:51 PM, Turvamies IT Security Services wrote: > Actually, the problem appears to be with ld rather than g++. > > This thread gave me a hint: https://forums.freebsd.org/threads/5799/ > > "ldl is libdl. It is a linuxism. FreeBSD does not have a libdl. The > same functionality that is in linux's libdl is provided in FreeBSD's > libc. So you should be able to simply remove -ldl from CFLAGS and try > compile." > > I know I should edit build.gradle further so that ldl is not included > in CFLAGS when compiling on OpenBSD, but I have not worked with gradle > build files and would very much appreciate it if you guys could help me > out in crafting the proper target definitions for OpenBSD. The definitions are in buildSrc/linux.gradle The challenge would be fixing this in a way that would not break the linux builds. In theory, it would be possible to clone linux.gradle to bsd.gradle, fix the compile line issues in that configuration and then build with gradle -PCOMPILE_TARGETS=bsd With the change you have done, we would treat the platform as similar to linux, but with a configuration of bsd. Dave > > - Jyri > -- > Turvamies IT Security Services -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From info at turvamies.fi Thu Aug 4 18:05:26 2016 From: info at turvamies.fi (Turvamies IT Security Services) Date: Thu, 4 Aug 2016 18:05:26 +0000 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <57A38267.1010106@Oracle.com> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> <20160804144804.63000001@uusilauta.turvamies.local> <57A3702C.6060205@Oracle.com> <20160804173218.2a3981ff@uusilauta.turvamies.local> <20160804175117.42bc35d8@uusilauta.turvamies.local> <57A38267.1010106@Oracle.com> Message-ID: <20160804180526.1cc32272@uusilauta.turvamies.local> Dave, thanks again for the info! > The definitions are in buildSrc/linux.gradle Ok. > The challenge would be fixing this in a way that would not break the > linux builds. I think the latter option would make a lot more sense. > In theory, it would be possible to clone linux.gradle to bsd.gradle, > fix the compile line issues in that configuration and then build with > > gradle -PCOMPILE_TARGETS=bsd > > With the change you have done, we would treat the platform as similar > to linux, but with a configuration of bsd. I'll take on this asap, although I'll target OpenBSD specifically. After all, there are many BSD distributions around (one of them being Darwin, of course) with many differences between them. I'll refrain myself to OpenBSD for now. It will be easy to expand from there. - Jyri -- Turvamies IT Security Services From David.Hill at Oracle.com Thu Aug 4 18:14:36 2016 From: David.Hill at Oracle.com (David Hill) Date: Thu, 04 Aug 2016 14:14:36 -0400 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <20160804180526.1cc32272@uusilauta.turvamies.local> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> <20160804144804.63000001@uusilauta.turvamies.local> <57A3702C.6060205@Oracle.com> <20160804173218.2a3981ff@uusilauta.turvamies.local> <20160804175117.42bc35d8@uusilauta.turvamies.local> <57A38267.1010106@Oracle.com> <20160804180526.1cc32272@uusilauta.turvamies.local> Message-ID: <57A3860C.2080109@Oracle.com> On 8/4/16, 2:05 PM, Turvamies IT Security Services wrote: > Dave, > > thanks again for the info! > >> The definitions are in buildSrc/linux.gradle > Ok. > >> The challenge would be fixing this in a way that would not break the >> linux builds. > I think the latter option would make a lot more sense. > >> In theory, it would be possible to clone linux.gradle to bsd.gradle, >> fix the compile line issues in that configuration and then build with >> >> gradle -PCOMPILE_TARGETS=bsd >> >> With the change you have done, we would treat the platform as similar >> to linux, but with a configuration of bsd. > I'll take on this asap, although I'll target OpenBSD specifically. > After all, there are many BSD distributions around (one of them being > Darwin, of course) with many differences between them. I'll refrain > myself to OpenBSD for now. It will be easy to expand from there. Great. If you have questions, I am likely the one to help with this issue, though I have a rather large heap on my plate right now, so response time will vary. dave > - Jyri > -- > Turvamies IT Security Services -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From jyri.hovila at iki.fi Thu Aug 4 18:35:36 2016 From: jyri.hovila at iki.fi (Jyri Hovila [iki.fi]) Date: Thu, 4 Aug 2016 18:35:36 +0000 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <57A3860C.2080109@Oracle.com> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> <20160804144804.63000001@uusilauta.turvamies.local> <57A3702C.6060205@Oracle.com> <20160804173218.2a3981ff@uusilauta.turvamies.local> <20160804175117.42bc35d8@uusilauta.turvamies.local> <57A38267.1010106@Oracle.com> <20160804180526.1cc32272@uusilauta.turvamies.local> <57A3860C.2080109@Oracle.com> Message-ID: <20160804183536.2d0e0845@uusilauta.turvamies.local> Dave, thanks for the support! I'm first trying to simply modify the Linux build file in order to find out an OpenBSD compatible approach without having to do it all from scratch. So, step #1 was to just remove line 175 (LINUX.launcher.linkFlags = ["-ldl"]) from buildSrc/linux.gradle. Now gradle sdk gives me this: FAILURE: Build failed with an exception. * Where: Build file '/tmp/rt-b41445afa464/build.gradle' line: 1929 * What went wrong: A problem occurred evaluating root project 'rt-b41445afa464'. > Ambiguous method overloading for method java.util.ArrayList#addAll. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [interface java.util.Collection] [interface java.lang.Iterable] [interface java.util.Iterator] Any ideas? Yours, Jyri -- Turvamies IT Security Services From vadim.pakhnushev at oracle.com Thu Aug 4 18:56:44 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Thu, 4 Aug 2016 21:56:44 +0300 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <20160804183536.2d0e0845@uusilauta.turvamies.local> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> <20160804144804.63000001@uusilauta.turvamies.local> <57A3702C.6060205@Oracle.com> <20160804173218.2a3981ff@uusilauta.turvamies.local> <20160804175117.42bc35d8@uusilauta.turvamies.local> <57A38267.1010106@Oracle.com> <20160804180526.1cc32272@uusilauta.turvamies.local> <57A3860C.2080109@Oracle.com> <20160804183536.2d0e0845@uusilauta.turvamies.local> Message-ID: On 04.08.2016 21:35, wrote: > Dave, > > thanks for the support! > > I'm first trying to simply modify the Linux build file in order to find > out an OpenBSD compatible approach without having to do it all from > scratch. So, step #1 was to just remove line 175 > (LINUX.launcher.linkFlags = ["-ldl"]) from buildSrc/linux.gradle. > > Now gradle sdk gives me this: > > FAILURE: Build failed with an exception. > > * Where: > Build file '/tmp/rt-b41445afa464/build.gradle' line: 1929 > > * What went wrong: > A problem occurred evaluating root project 'rt-b41445afa464'. >> Ambiguous method overloading for method java.util.ArrayList#addAll. > Cannot resolve which method to invoke for [null] due to overlapping > prototypes between: > [interface java.util.Collection] > [interface java.lang.Iterable] > [interface java.util.Iterator] > > Any ideas? I think that if you would look at the line 1929 of build.gradle then probably there is a line linkParams.addAll(LINUX.launcher.linkFlags) so when you removed the line from the linux.gradle the linkFlags field became null hence the error. So maybe you should remove only "-ldl", not the whole line like this: LINUX.launcher.linkFlags = []; Vadim > > Yours, > > Jyri > -- > Turvamies IT Security Services From info at turvamies.fi Thu Aug 4 19:28:53 2016 From: info at turvamies.fi (Turvamies IT Security Services) Date: Thu, 4 Aug 2016 19:28:53 +0000 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> <20160804144804.63000001@uusilauta.turvamies.local> <57A3702C.6060205@Oracle.com> <20160804173218.2a3981ff@uusilauta.turvamies.local> <20160804175117.42bc35d8@uusilauta.turvamies.local> <57A38267.1010106@Oracle.com> <20160804180526.1cc32272@uusilauta.turvamies.local> <57A3860C.2080109@Oracle.com> <20160804183536.2d0e0845@uusilauta.turvamies.local> Message-ID: <20160804192853.5f77f3b9@uusilauta.turvamies.local> Vadim, right on spot again! > I think that if you would look at the line 1929 of build.gradle then > probably there is a line > linkParams.addAll(LINUX.launcher.linkFlags) > so when you removed the line from the linux.gradle the linkFlags > field became null hence the error. > So maybe you should remove only "-ldl", not the whole line like this: > LINUX.launcher.linkFlags = []; Of course - how stupid of me. We're one step further, entering the lovely c++ compatibility problems: $ gradle sdk [...] :fxpackager:compileLinuxLibraryIn file included from /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Lock.h:37, from /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Lock.cpp:34: /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:161: error: expected ',' or '...' before 'Application' /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:162: error: ISO C++ forbids declaration of 'TString' with no type /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:164: error: 'TProcessID' does not name a type /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:216: error: expected ',' or '...' before 'Key' /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:216: error: ISO C++ forbids declaration of 'TString' with no type /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:225: error: expected ',' or '...' before 'SectionName' /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:225: error: ISO C++ forbids declaration of 'TString' with no type /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:226: error: expected ',' or '...' before 'SectionName' /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:226: error: ISO C++ forbids declaration of 'TString' with no type /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:227: error: expected ',' or '...' before 'SectionName' /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:227: error: ISO C++ forbids declaration of 'TString' with no type /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:253: error: 'TString' has not been declared The above rant goes on, complaining of the same issues for every (?) file in modules/fxpackager/src/main/native/library/common. Looking at Lock.cpp and others, I can not find a clear reason nor a solution to the problems. - Jyri -- Turvamies IT Security Services From vadim.pakhnushev at oracle.com Thu Aug 4 19:41:14 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Thu, 4 Aug 2016 22:41:14 +0300 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <20160804192853.5f77f3b9@uusilauta.turvamies.local> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> <20160804144804.63000001@uusilauta.turvamies.local> <57A3702C.6060205@Oracle.com> <20160804173218.2a3981ff@uusilauta.turvamies.local> <20160804175117.42bc35d8@uusilauta.turvamies.local> <57A38267.1010106@Oracle.com> <20160804180526.1cc32272@uusilauta.turvamies.local> <57A3860C.2080109@Oracle.com> <20160804183536.2d0e0845@uusilauta.turvamies.local> <20160804192853.5f77f3b9@uusilauta.turvamies.local> Message-ID: Basically that's the same issue. If you would look at the start of Platform.h you could see that we define POSIX if it's mac or linux and WINDOWS otherwise. Based on that we include all needed headers. I guess you need to add ifdef bsd somewhere near linux (I'm sure you know how to do that) Vadim On 04.08.2016 22:28, Turvamies IT Security Services wrote: > Vadim, > > right on spot again! > >> I think that if you would look at the line 1929 of build.gradle then >> probably there is a line >> linkParams.addAll(LINUX.launcher.linkFlags) >> so when you removed the line from the linux.gradle the linkFlags >> field became null hence the error. >> So maybe you should remove only "-ldl", not the whole line like this: >> LINUX.launcher.linkFlags = []; > Of course - how stupid of me. > > We're one step further, entering the lovely c++ compatibility problems: > > $ gradle sdk > [...] > :fxpackager:compileLinuxLibraryIn file included from /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Lock.h:37, > from /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Lock.cpp:34: > /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:161: error: expected ',' or '...' before 'Application' > /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:162: error: ISO C++ forbids declaration of 'TString' with no type > /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:164: error: 'TProcessID' does not name a type > /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:216: error: expected ',' or '...' before 'Key' > /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:216: error: ISO C++ forbids declaration of 'TString' with no type > /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:225: error: expected ',' or '...' before 'SectionName' > /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:225: error: ISO C++ forbids declaration of 'TString' with no type > /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:226: error: expected ',' or '...' before 'SectionName' > /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:226: error: ISO C++ forbids declaration of 'TString' with no type > /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:227: error: expected ',' or '...' before 'SectionName' > /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:227: error: ISO C++ forbids declaration of 'TString' with no type > /tmp/rt-b41445afa464/modules/fxpackager/src/main/native/library/common/Platform.h:253: error: 'TString' has not been declared > > The above rant goes on, complaining of the same issues for every (?) > file in modules/fxpackager/src/main/native/library/common. > > Looking at Lock.cpp and others, I can not find a clear reason nor a > solution to the problems. > > - Jyri > -- > Turvamies IT Security Services From vadim.pakhnushev at oracle.com Fri Aug 5 14:32:35 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 5 Aug 2016 17:32:35 +0300 Subject: In(Sanity) Testing Mondays Message-ID: Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From David.Hill at Oracle.com Fri Aug 5 17:44:28 2016 From: David.Hill at Oracle.com (David Hill) Date: Fri, 05 Aug 2016 13:44:28 -0400 Subject: In(Sanity) Testing Mondays In-Reply-To: References: Message-ID: <57A4D07C.7080208@Oracle.com> On 8/5/16, 10:32 AM, Vadim Pakhnushev wrote: > Reminder, Monday is our weekly sanity testing. > I just updated the OpenJFX Wiki - the section onSandbox Testing with JDK9 It would be good for us to transitioning to using modules when testing as that is what we will be delivering. Using "built" or downloaded modules is really easy with the @xpatch.args mechanism which is detailed on the wiki page. As an added bonus - any of the internal test scripts that use jfxrun will now honor the JFX_XPATCH if JIGSAW_HOME is set. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From kevin.rushforth at oracle.com Fri Aug 5 17:49:17 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 05 Aug 2016 10:49:17 -0700 Subject: In(Sanity) Testing Mondays In-Reply-To: <57A4D07C.7080208@Oracle.com> References: <57A4D07C.7080208@Oracle.com> Message-ID: <57A4D19D.3060105@oracle.com> +1 If you aren't testing in JIGSAW mode then you aren't testing what we ship. Further, once Dave implements https://bugs.openjdk.java.net/browse/JDK-8161704 then legacy mode will necessarily go away. -- Kevin David Hill wrote: > On 8/5/16, 10:32 AM, Vadim Pakhnushev wrote: >> Reminder, Monday is our weekly sanity testing. >> > I just updated the OpenJFX Wiki - the section onSandbox Testing with > JDK9 > > > > It would be good for us to transitioning to using modules when testing > as that is what we will be delivering. > > Using "built" or downloaded modules is really easy with the > @xpatch.args mechanism which is detailed on the wiki page. > > As an added bonus - any of the internal test scripts that use jfxrun > will now honor the JFX_XPATCH if JIGSAW_HOME is set. > > From chien.yang at oracle.com Fri Aug 5 20:24:28 2016 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 5 Aug 2016 13:24:28 -0700 Subject: [8udev (backport)] Code Review Request For 8163302: Stage alwaysOnTop property not reset to false if permission is denied Message-ID: <84b4a2d8-a361-9bba-6368-edd1533b80ed@oracle.com> Hi Kevin, Please review the proposed backport: JIRA: https://bugs.openjdk.java.net/browse/JDK-8163302 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8163302/webrev.00/ Thanks, - Chien From kevin.rushforth at oracle.com Fri Aug 5 20:47:01 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 05 Aug 2016 13:47:01 -0700 Subject: [8udev (backport)] Code Review Request For 8163302: Stage alwaysOnTop property not reset to false if permission is denied In-Reply-To: <84b4a2d8-a361-9bba-6368-edd1533b80ed@oracle.com> References: <84b4a2d8-a361-9bba-6368-edd1533b80ed@oracle.com> Message-ID: <57A4FB45.1040203@oracle.com> This review request is using the wrong Bug ID. We never use the backport ID for anything (ever), so please resend with the correct subject line, which should have the Bug ID of the main bug: 8156078 Thanks. -- Kevin Chien Yang wrote: > Hi Kevin, > > Please review the proposed backport: > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8163302 > > Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8163302/webrev.00/ > > Thanks, > > - Chien > From chien.yang at oracle.com Fri Aug 5 20:57:35 2016 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 5 Aug 2016 13:57:35 -0700 Subject: [8udev (backport)] Code Review Request For 8156078: Stage alwaysOnTop property not reset to false if permission is denied Message-ID: Hi Kevin, Please review the proposed backport: JIRA: https://bugs.openjdk.java.net/browse/JDK-8156078 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8156078/backport.00/ Thanks, - Chien From chien.yang at oracle.com Fri Aug 5 20:58:55 2016 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 5 Aug 2016 13:58:55 -0700 Subject: [8udev (backport)] Code Review Request For 8163302: Stage alwaysOnTop property not reset to false if permission is denied In-Reply-To: <57A4FB45.1040203@oracle.com> References: <84b4a2d8-a361-9bba-6368-edd1533b80ed@oracle.com> <57A4FB45.1040203@oracle.com> Message-ID: <6e5b58c1-9121-4677-fd1f-d1866823b5fc@oracle.com> Thanks for the reminder. I have just resent it with the main Bug ID and updated the JIRA. - Chien On 08/05/16 13:47, Kevin Rushforth wrote: > This review request is using the wrong Bug ID. We never use the > backport ID for anything (ever), so please resend with the correct > subject line, which should have the Bug ID of the main bug: 8156078 > > Thanks. > > -- Kevin > > > Chien Yang wrote: >> Hi Kevin, >> >> Please review the proposed backport: >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8163302 >> >> Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8163302/webrev.00/ >> >> Thanks, >> >> - Chien >> From kevin.rushforth at oracle.com Fri Aug 5 22:09:53 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 05 Aug 2016 15:09:53 -0700 Subject: [9] Review request: 8162783: [Windows] HiDPI screenshot artifacts using glass Robot Message-ID: <57A50EB1.7030907@oracle.com> Hi Jim and Dave, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8162783 http://cr.openjdk.java.net/~kcr/8162783/webrev.00/ Details are in the bug report. Thanks. -- Kevin From kevin.rushforth at oracle.com Sat Aug 6 14:47:41 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 06 Aug 2016 07:47:41 -0700 Subject: Result: New OpenJFX Committer: Andrey Rusakov Message-ID: <57A5F88D.5060904@oracle.com> Voting for Andrey Rusakov [1] to OpenJFX Committer [2] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] http://openjdk.java.net/census#arusakov [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2016-July/019468.html From info at turvamies.fi Mon Aug 8 04:59:23 2016 From: info at turvamies.fi (Turvamies IT Security Services) Date: Mon, 8 Aug 2016 04:59:23 +0000 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <20160804192853.5f77f3b9@uusilauta.turvamies.local> References: <20160804135026.7d19ac76@uusilauta.turvamies.local> <57A34EA1.2030009@Oracle.com> <57A35243.9030406@oracle.com> <20160804144804.63000001@uusilauta.turvamies.local> <57A3702C.6060205@Oracle.com> <20160804173218.2a3981ff@uusilauta.turvamies.local> <20160804175117.42bc35d8@uusilauta.turvamies.local> <57A38267.1010106@Oracle.com> <20160804180526.1cc32272@uusilauta.turvamies.local> <57A3860C.2080109@Oracle.com> <20160804183536.2d0e0845@uusilauta.turvamies.local> <20160804192853.5f77f3b9@uusilauta.turvamies.local> Message-ID: <20160808045923.2f1e9e75@uusilauta.turvamies.local> Hi everyone! Just a heads-up on the "compiling OpenJFX on OpenBSD" front: I've been busy with some other urgent tasks for few days, but will continue working with the project until I find a fully functional non-hack solution. I love OpenBSD for it's strict and clear design and the enforcing of correct procedures, and although it sometimes (well, basically always) means having to do some extra work in order to get your stuff compiled, it's always been worth the trouble. Having OpenJFX available on OpenBSD would open the door for running many currently unavailable Java based programs on OpenBSD, so I'm more than willing to share my time to make it work. If there are others on this list who would like to actively participate, I'll be happy to receive help from more experienced coders. I pretty much know what I'm doing but I'm still much more talented in the area of [server] systems design than coding/porting. Yours, Jyri From guru.hb at oracle.com Mon Aug 8 07:00:54 2016 From: guru.hb at oracle.com (Guru Hb) Date: Mon, 8 Aug 2016 12:30:54 +0530 Subject: [9] Review request: 8163183: [test] Correct assertEquals ("", actual, expected) in LoadTest.loadJarFile In-Reply-To: <57A50EB1.7030907@oracle.com> References: <57A50EB1.7030907@oracle.com> Message-ID: <57A82E26.9010600@oracle.com> Hi Kevin & Arun, Please review the fix for JBS : https://bugs.openjdk.java.net/browse/JDK-8163183 Webrev : http://cr.openjdk.java.net/~ghb/8163183/webrev.00/ Thanks, Guru From kevin.rushforth at oracle.com Mon Aug 8 21:53:03 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Aug 2016 14:53:03 -0700 Subject: [9, 8u] Review request: 8159726: Cleanup whitespace and file permission in tests repo Message-ID: <57A8FF3F.8090104@oracle.com> Andrey, Please review the following white-space-only change: https://bugs.openjdk.java.net/browse/JDK-8159726 http://cr.openjdk.java.net/~kcr/8159726/webrev-9.01/ With this change the openjfx tests repo in both 8u and 9 will be jcheck compliant. Thanks. -- Kevin From kevin.rushforth at oracle.com Tue Aug 9 01:10:47 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Aug 2016 18:10:47 -0700 Subject: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene. In-Reply-To: References: <8f6f91a9-0ea9-1769-d22d-ca3e19b8c5b7@oracle.com> <579A231B.8030009@oracle.com> <9C6E80F0-6826-43A5-8483-3C570B932D10@nyssen.org> <579A2CD5.5020600@oracle.com> Message-ID: <57A92D97.6000302@oracle.com> I uploaded the patch, reviewed it, and provided comments in the bug report. The short version is: * The new API looks good * There is a missing '@since 9' in the javadoc comments along with a few typos / style issues * Rather than using reflection and setAccessible in the implementation, please add a public getHostContainer method to EmbeddedWindow (since it is an internal method, there is no concern with doing that -- it isn't API). Additionally, I requested JDK 9 release team approval for this. The approval process can proceed in parallel with your addressing the issues I raised. -- Kevin Alexander Nyssen wrote: > Hi Kevin, > > attached please find a revised patch. My comments are inlined. > >> Am 28.07.2016 um 18:03 schrieb Kevin Rushforth >> >: >> >> Hi >> >> Alexander Nyssen wrote: >>> Hi, >>> >>> I have added my comments below: >>> >>> >>>> Am 28.07.2016 um 17:22 schrieb Kevin Rushforth >>>> >: >>>> >>>> I got the attachment, since Alexander also CCed me directly. I will >>>> attach it shortly. >>> >>> Thanks! >> >> Done. >> > >>>> I do have two comments on this: >>>> >>>> 1) We are past Feature Freeze, so all Enhancements need formal JDK >>>> 9 R-team approval [1][2]. In this case, the justification can be >>>> internal API that is no longer accessible in JDK 9 due to Jigsaw (I >>>> would be very reluctant to consider any other Enhancement request >>>> this late in the process), but I will need to look at it and then >>>> take it through the approval process, provided that I feel it is in >>>> scope. >>> >>> I was not aware about this, but I would of course appreciate if it >>> could be included (due to Jigsaw). Thanks for considering it at least. >> >> I'll take a closer look tomorrow or Monday (no more time today). At >> first glance it seems like something reasonable to take forward. > > That sounds promising. Thanks! > >> >>>> 2) Some of the changes you list seem unrelated to this enhancement >>>> and are better done as separate issues (e.g., the rework of the >>>> SWTCursorsTest). Also, I am unconvinced of the need to force GTK 2; >>>> in fact it seems at odds with the work we have done with JEP 283 [3]. >>> >>> Well, the test case refactoring is somehow related, as I introduced >>> the common SWT rule while introducing the second SWT test. However, >>> I could provide it as a separate contribution if that was wished >>> (and a JIRA issue was provided), but the rest of this contribution >>> of course requires it as a prerequisite. If this enhancement could >>> not be included in JDK 9, I would have to provide it as a separate >>> contribution, as I would have to re-introduce FXCanvasTest in other >>> succeeding bugfix contributions (JDK-8143596, JDK-8143596). >> >> I see. I did take a quick look at this and the test changes seem fine >> as part of this. I see you created the new test with 'hg cp' (or >> similar) which records it as a copy of the SWTCursorsTest.java file, >> which given the number of changes is not needed (and not really >> useful), but that's easy to fix. > > Done (I copied it within IntelliJ and the IDE seems to have applied hg > copy). > >> >> There are several white space changes in FXCanvas.java that should be >> reverted. Our policy is that we do not make unrelated changes, >> including white space changes, in portions of a file that aren't >> otherwise modified by a patch. > > Done (I used the IntelliJ formatter). > >> >>> The GTK2 flag I introduced just affects SWT. As the swt library that >>> is bundled is rather old (3.7.2) that seemed to be safer (we have >>> observed quite a few problems when running SWT on GTK3). We can of >>> course remove it if tests are not affected by it. >> >> We don't actually bundle swt itself, although we do download an old >> copy to link against, and to run tests against. In any case, given >> that our minimum Linux platform for JDK 9 is Ubuntu 16.04, it might >> not have GTK2 installed by default. Please revert this change to >> build.gradle. If test issues arise on Linux we will deal with it at >> that time (possibly by moving to a newer version of swt to run tests). > > I removed the SWT option. However, the previous logger message is no > longer valid and should be removed, so the patch still contains a > change to build.gradle. > >> >> Thanks. >> >> ? Kevin > > Regards, > Alexander > > > ------------------------------------------------------------------------ > > >> >> >>> >>>> >>>> ? Kevin >>> >>> Regards, >>> Alexander >>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004485.html >>>> [2] http://openjdk.java.net/projects/jdk9/fc-extension-process >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8145568 >>>> >>>> >>>> Phil Race wrote: >>>>> The mailing list rejects attachments so we got nothing. >>>>> >>>>> -phil. >>>>> >>>>> On 7/28/2016 8:06 AM, Alexander Nyssen wrote: >>>>>> Hi Kevin, all, >>>>>> >>>>>> attached please find a patch that fixes JDK-8160325. The patch >>>>>> comprises the following changes: >>>>>> >>>>>> - Provided static FXCanvas#getFXCanvas(Scene) method to obtain >>>>>> the FXCanvas instance embedding the given Scene instance. >>>>>> - Added EmbeddedWindow.getHost() so the HostInterface can be >>>>>> retrieved. >>>>>> - Added FXCanvasTest with a test method to test correct behavior >>>>>> of FXCanvas#getFXCanvas(Scene). >>>>>> - Introduced SwtTest JUnit MethodRule to have more concise tests >>>>>> and ensure it is also used by SWTCursorsTest. >>>>>> - Ensured SWT tests are executed using GTK2 on Linux. >>>>>> >>>>>> I reworked the existing SWTCursorsTest while introducing >>>>>> FXCanvasTest to be more concise. >>>>>> >>>>>> Regards, >>>>>> Alexander >>>>>> >>>>> >>> > From alexander at nyssen.org Tue Aug 9 06:39:03 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Tue, 9 Aug 2016 08:39:03 +0200 Subject: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene. In-Reply-To: <57A92D97.6000302@oracle.com> References: <8f6f91a9-0ea9-1769-d22d-ca3e19b8c5b7@oracle.com> <579A231B.8030009@oracle.com> <9C6E80F0-6826-43A5-8483-3C570B932D10@nyssen.org> <579A2CD5.5020600@oracle.com> <57A92D97.6000302@oracle.com> Message-ID: <4764FA63-8ED6-481E-9B63-DC919B85A02B@nyssen.org> Hi Kevin, thanks for your feedback. Please fin my comments inline. > Am 09.08.2016 um 03:10 schrieb Kevin Rushforth : > > I uploaded the patch, reviewed it, and provided comments in the bug report. The short version is: > > * The new API looks good > > * There is a missing '@since 9' in the javadoc comments along with a few typos / style issues I will take care of it. Is there a style guide? > > * Rather than using reflection and setAccessible in the implementation, please add a public getHostContainer method to EmbeddedWindow (since it is an internal method, there is no concern with doing that -- it isn't API). Such a getHost() method was already introduced to EmbeddedWindow as part of the patch (to obtain the HostContainer from it). The reflection code within getFXCanvas() is used to access the enclosing instance (i.e. the FXCanvas) of the HostContainer. We could only circumvent this by introducing a constructor to HostContainer and by passing in the enclosing FXCanvas instance explicitly (so we can query it via an explicit getter, which would have to be introduced in addition). Would you prefer that? > > Additionally, I requested JDK 9 release team approval for this. The approval process can proceed in parallel with your addressing the issues I raised. > > ? Kevin Regards, Alexander > > > Alexander Nyssen wrote: >> Hi Kevin, >> >> attached please find a revised patch. My comments are inlined. >> >>> Am 28.07.2016 um 18:03 schrieb Kevin Rushforth >: >>> >>> Hi >>> >>> Alexander Nyssen wrote: >>>> Hi, >>>> >>>> I have added my comments below: >>>> >>>> >>>>> Am 28.07.2016 um 17:22 schrieb Kevin Rushforth >: >>>>> >>>>> I got the attachment, since Alexander also CCed me directly. I will attach it shortly. >>>> >>>> Thanks! >>> >>> Done. >>> >> >>>>> I do have two comments on this: >>>>> >>>>> 1) We are past Feature Freeze, so all Enhancements need formal JDK 9 R-team approval [1][2]. In this case, the justification can be internal API that is no longer accessible in JDK 9 due to Jigsaw (I would be very reluctant to consider any other Enhancement request this late in the process), but I will need to look at it and then take it through the approval process, provided that I feel it is in scope. >>>> >>>> I was not aware about this, but I would of course appreciate if it could be included (due to Jigsaw). Thanks for considering it at least. >>> >>> I'll take a closer look tomorrow or Monday (no more time today). At first glance it seems like something reasonable to take forward. >> >> That sounds promising. Thanks! >> >>> >>>>> 2) Some of the changes you list seem unrelated to this enhancement and are better done as separate issues (e.g., the rework of the SWTCursorsTest). Also, I am unconvinced of the need to force GTK 2; in fact it seems at odds with the work we have done with JEP 283 [3]. >>>> >>>> Well, the test case refactoring is somehow related, as I introduced the common SWT rule while introducing the second SWT test. However, I could provide it as a separate contribution if that was wished (and a JIRA issue was provided), but the rest of this contribution of course requires it as a prerequisite. If this enhancement could not be included in JDK 9, I would have to provide it as a separate contribution, as I would have to re-introduce FXCanvasTest in other succeeding bugfix contributions (JDK-8143596, JDK-8143596). >>> >>> I see. I did take a quick look at this and the test changes seem fine as part of this. I see you created the new test with 'hg cp' (or similar) which records it as a copy of the SWTCursorsTest.java file, which given the number of changes is not needed (and not really useful), but that's easy to fix. >> >> Done (I copied it within IntelliJ and the IDE seems to have applied hg copy). >> >>> >>> There are several white space changes in FXCanvas.java that should be reverted. Our policy is that we do not make unrelated changes, including white space changes, in portions of a file that aren't otherwise modified by a patch. >> >> Done (I used the IntelliJ formatter). >>> >>>> The GTK2 flag I introduced just affects SWT. As the swt library that is bundled is rather old (3.7.2) that seemed to be safer (we have observed quite a few problems when running SWT on GTK3). We can of course remove it if tests are not affected by it. >>> >>> We don't actually bundle swt itself, although we do download an old copy to link against, and to run tests against. In any case, given that our minimum Linux platform for JDK 9 is Ubuntu 16.04, it might not have GTK2 installed by default. Please revert this change to build.gradle. If test issues arise on Linux we will deal with it at that time (possibly by moving to a newer version of swt to run tests). >> >> I removed the SWT option. However, the previous logger message is no longer valid and should be removed, so the patch still contains a change to build.gradle. >> >>> >>> Thanks. >>> >>> ? Kevin >> >> Regards, >> Alexander >> >> >> ------------------------------------------------------------------------ >> >> >>> >>> >>>> >>>>> >>>>> ? Kevin >>>> >>>> Regards, >>>> Alexander >>>> >>>>> >>>>> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004485.html >>>>> [2] http://openjdk.java.net/projects/jdk9/fc-extension-process >>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8145568 >>>>> >>>>> >>>>> Phil Race wrote: >>>>>> The mailing list rejects attachments so we got nothing. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 7/28/2016 8:06 AM, Alexander Nyssen wrote: >>>>>>> Hi Kevin, all, >>>>>>> >>>>>>> attached please find a patch that fixes JDK-8160325. The patch comprises the following changes: >>>>>>> >>>>>>> - Provided static FXCanvas#getFXCanvas(Scene) method to obtain the FXCanvas instance embedding the given Scene instance. >>>>>>> - Added EmbeddedWindow.getHost() so the HostInterface can be retrieved. >>>>>>> - Added FXCanvasTest with a test method to test correct behavior of FXCanvas#getFXCanvas(Scene). >>>>>>> - Introduced SwtTest JUnit MethodRule to have more concise tests and ensure it is also used by SWTCursorsTest. >>>>>>> - Ensured SWT tests are executed using GTK2 on Linux. >>>>>>> >>>>>>> I reworked the existing SWTCursorsTest while introducing FXCanvasTest to be more concise. >>>>>>> >>>>>>> Regards, >>>>>>> Alexander >>>>>>> >>>>>> >>>> >> From vadim.pakhnushev at oracle.com Tue Aug 9 08:38:27 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 9 Aug 2016 11:38:27 +0300 Subject: [9] Review request for 8163454: PieChart legend is not updated while invisible Message-ID: Jonathan, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8163454 http://cr.openjdk.java.net/~vadim/8163454/webrev.00/ Thanks, Vadim From vadim.pakhnushev at oracle.com Tue Aug 9 15:10:38 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 9 Aug 2016 18:10:38 +0300 Subject: [9] Review request for 8163358: BubbleChart.updateLegend should add all LegendItems with setAll Message-ID: <7cb9ff6e-8a08-e92c-133a-e92af4e00fd9@oracle.com> Hi Jonathan, Kevin, Could you please review this enhancement: https://bugs.openjdk.java.net/browse/JDK-8163358 http://cr.openjdk.java.net/~vadim/8163358/webrev.00/ Thanks, Vadim From chien.yang at oracle.com Tue Aug 9 17:00:03 2016 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 09 Aug 2016 10:00:03 -0700 Subject: [9] Code Review Request For 8163383: Fix doclint errors and warnings in javafx.base module Message-ID: <57AA0C13.2030100@oracle.com> Hi Kevin, Please review this proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8163383 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8163383/webrev.00/ Thanks, - Chien From David.Hill at Oracle.com Tue Aug 9 17:46:11 2016 From: David.Hill at Oracle.com (David Hill) Date: Tue, 09 Aug 2016 13:46:11 -0400 Subject: review: Support Gradle version 2.14+ Message-ID: <57AA16E3.8050909@Oracle.com> jbs: https://bugs.openjdk.java.net/browse/JDK-8163502 webrev: http://cr.openjdk.java.net/~ddhill/8163502/ Had to handle a couple of new package renames. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From David.Hill at Oracle.com Tue Aug 9 20:12:49 2016 From: David.Hill at Oracle.com (David Hill) Date: Tue, 09 Aug 2016 16:12:49 -0400 Subject: review: Add HelloDirectoryChooser toy. Message-ID: <57AA3941.6060208@Oracle.com> Kevin or Chien, could you review this toy addition: https://bugs.openjdk.java.net/browse/JDK-8163514 webrev: http://cr.openjdk.java.net/~ddhill/8163514 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From kevin.rushforth at oracle.com Tue Aug 9 20:24:23 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 09 Aug 2016 13:24:23 -0700 Subject: URGENT: do not pull from openjfx/9-dev/rt Message-ID: <57AA3BF7.50901@oracle.com> There was an inadventent push to openjfx/9-dev/rt. Please do not pull as we will be rolling back this mistake. If you already pulled changes, I will send out instructions for fixing your repo. -- Kevin From kevin.rushforth at oracle.com Tue Aug 9 22:05:14 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 09 Aug 2016 15:05:14 -0700 Subject: ACTION REQUIRED: 9-dev/rt is fixed but you must check your repo and reclone if needed Message-ID: <57AA539A.60308@oracle.com> All, The extra 262 changesets that were mistakenly pushed to the openjfx/9-dev/rt repo have been removed from the server. THE FOLLOWING ACTION IS REQUIRED: If you have pulled changes to a local clone of the repo today, then you must reclone your repo. To find out if you are affected, do this: cd 9-dev/rt # wherever your local rt repo is hg log -r 0e9adfde11bc If you see a changeset listed then you have a problem. If it is present, you will see something like this: changeset: 9975:0e9adfde11bc parent: 9030:7e39fa663761 summary: Initial pass at reading data from stdout from a spawned process. And you must throw away and reclone your repo, after saving any local patches in progress. You must not continue using this repo. A GOOD status is this: abort: unknown revision '0e9adfde11bc' meaning that the offending changeset is not there. Until we have jcheck enabled there is no automated way to keep the bad changeset from showing up again. So be very careful. If you see anything that looks like it will generate a merge changeset, stop and don't complete the merge. Make sure you use 'hg outgoing' before you push -- a good habit to get into in any case. Please let me know if there are any questions about this. -- Kevin From David.Hill at Oracle.com Wed Aug 10 00:44:01 2016 From: David.Hill at Oracle.com (David Hill) Date: Tue, 09 Aug 2016 20:44:01 -0400 Subject: review: protect FileChooser return from internal NPE Message-ID: <57AA78D1.3060400@Oracle.com> Kevin, protect FileChooser return from internal NPE https://bugs.openjdk.java.net/browse/JDK-8163526 inline in jbs. Tested with a problem reproducer on windows. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From james.graham at oracle.com Wed Aug 10 01:41:20 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 9 Aug 2016 18:41:20 -0700 Subject: [9] Review request for 8159892: Ubuntu 16.04: invalid rendering of FX app stage in case of scaling Message-ID: <3744a038-8445-4524-1e89-5b449d9a2130@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8159892 webrev: http://cr.openjdk.java.net/~flar/JDK-8159892/webrev.00/ There are a number of bugs filed on this, or very similar issues as well - all related to broken DPI scaling on GTK3. It looks like there is a simple way of disabling automatic scaling for GTK3 so we can do our own (which has been working fairly well so far for GTK2 and is preferable to the integer-operation scaling we'd get automatically via the integer-dominated APIs of GDK/GTK). Questions: - Is this the best bug ID to use for this fix? I used it as it was the first one that I looked at and it had screen shots of the problem that immediately pointed me to the underlying problem. Other bugids are mentioned in the bug report as being "possible dups" and most of them should be a duplicate, but so far I've only tested the test case shown in the screen shots of 8159892... - The new function is specifically in 3.10 of the GTK 3 libraries. Should I add additional protections in case a system has an earlier 3.XX version of GTK3? - Minor note - I discovered after publishing the webrev that the function is defined, declared, loaded and stubbed in inconsistent locations in the list of functions - not really an issue, but I'll try to normalize where it appears in all of the various function lists if I have to recut the webrev... ...jim From vadim.pakhnushev at oracle.com Wed Aug 10 11:21:02 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 10 Aug 2016 14:21:02 +0300 Subject: [9] Review request for 8163576: StackedBarChart.getSeriesSize is unneeded Message-ID: Hi Jonathan, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8163576 http://cr.openjdk.java.net/~vadim/8163576/webrev.00/ Thanks, Vadim From kevin.rushforth at oracle.com Wed Aug 10 20:06:59 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Aug 2016 13:06:59 -0700 Subject: [9] Review request: 8144768: Update version numbers in FX docs for JDK 9 Message-ID: <57AB8963.3070800@oracle.com> Dave, Please review this (hopefully) simple fix: https://bugs.openjdk.java.net/browse/JDK-8144768 http://cr.openjdk.java.net/~kcr/8144768/webrev.01/ Thanks. -- Kevin From james.graham at oracle.com Wed Aug 10 23:31:59 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 10 Aug 2016 16:31:59 -0700 Subject: [9] Review request for 8159892: Ubuntu 16.04: invalid rendering of FX app stage in case of scaling In-Reply-To: <3744a038-8445-4524-1e89-5b449d9a2130@oracle.com> References: <3744a038-8445-4524-1e89-5b449d9a2130@oracle.com> Message-ID: <5fd67eca-4506-6a3c-703e-d326f10a5e16@oracle.com> New webrev: http://cr.openjdk.java.net/~flar/JDK-8159892/webrev.01/ This one makes the presence of the new functions being used optional. Details are in JBS. With respect to my comment below about the consistency of declarations and definitions, there didn't seem to be much consistency in the order of things as it exists so I moved a couple of the functions purely for my own OCD enjoyment, but didn't sweat the details too much... ...jim On 8/9/16 6:41 PM, Jim Graham wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8159892 > webrev: http://cr.openjdk.java.net/~flar/JDK-8159892/webrev.00/ > > There are a number of bugs filed on this, or very similar issues as well - all related to broken DPI scaling on GTK3. > > It looks like there is a simple way of disabling automatic scaling for GTK3 so we can do our own (which has been working > fairly well so far for GTK2 and is preferable to the integer-operation scaling we'd get automatically via the > integer-dominated APIs of GDK/GTK). > > Questions: > > - Is this the best bug ID to use for this fix? I used it as it was the first one that I looked at and it had screen > shots of the problem that immediately pointed me to the underlying problem. Other bugids are mentioned in the bug > report as being "possible dups" and most of them should be a duplicate, but so far I've only tested the test case shown > in the screen shots of 8159892... > > - The new function is specifically in 3.10 of the GTK 3 libraries. Should I add additional protections in case a system > has an earlier 3.XX version of GTK3? > > - Minor note - I discovered after publishing the webrev that the function is defined, declared, loaded and stubbed in > inconsistent locations in the list of functions - not really an issue, but I'll try to normalize where it appears in all > of the various function lists if I have to recut the webrev... > > ...jim From guru.hb at oracle.com Thu Aug 11 09:19:31 2016 From: guru.hb at oracle.com (Guru Hb) Date: Thu, 11 Aug 2016 14:49:31 +0530 Subject: [9] Review request 8163582: JavaFX browser can get stuck in an infinite loop when calling path.getTotalLength() In-Reply-To: <1cac2cd1-9e13-fec7-e1d5-59998fe1b24f@oracle.com> References: <42096db5-3686-f2fb-ce65-f74a3f607b86@oracle.com> <7ac9a346-2b91-fc15-60ad-5a0dd9be66a2@oracle.com> <5b0bb5ee-70c7-3e6d-35ef-1d57b6393c51@oracle.com> <1cac2cd1-9e13-fec7-e1d5-59998fe1b24f@oracle.com> Message-ID: Hi Kevin, Arun & Murali, Please review the fix for : JBS : https://bugs.openjdk.java.net/browse/JDK-8163582 Webrev : http://cr.openjdk.java.net/~ghb/8163582/webrev.00/ RC : Merged back JDK-8090035 and added Unit test case. Thanks, Guru From itaisha at gmail.com Thu Aug 11 13:13:51 2016 From: itaisha at gmail.com (Itai) Date: Thu, 11 Aug 2016 16:13:51 +0300 Subject: Memory leaks on Linux with hardware renderer In-Reply-To: <5790E678.8020905@oracle.com> References: <579008D1.1030407@oracle.com> <57900B89.2070401@oracle.com> <5790E678.8020905@oracle.com> Message-ID: I'm sorry to see the issue could still not be reproduced on any OpenJFX team members. Meanwhile, I have noticed a user on reddit (JavaFX sub-reddit) had the same issue: https://www.reddit.com/r/JavaFX/comments/4nr2ln/memory_leak_when_calling_imageviewsettranslatex/ . However, they have managed to profile it (VisualVM has a bug making it nearly impossible to CPU profile JavaFX programs), and found out a lot of time is taken by `com.sun.prism.es2.X11GLContext.makeCurrent`. Taking this lead, I have found this: http://www.gamedev.net/topic/679705-glxmakecurrent-slowly-leaks-memory/ Sadly I don't know enough about OpenGL to understand most of it, but it seems to me like it's the same issue, so possibly it's not a Java issue at all. However, maybe it can be avoided? In this linked post it is mentioned that the leak only happens when having two windows, but in JavaFX this always happens, so maybe there is a redundant call to `makeCurrent`? Hope this helps to find the source of the problem, and if it's indeed outside of Java/JavaFX scope - report it to the relevant project. On Thu, Jul 21, 2016 at 6:12 PM, Kevin Rushforth wrote: > Thanks. I added this to the bug report for https://bugs.openjdk.java.net/ > browse/JDK-8161911 > > -- Kevin > > > > Rahman USTA wrote: > > Hello Kevin; > > One of our user reported "Must be a memory leak somewhere" in AsciidocFX > project. It seems a similar issue. > > You can see the issue here https://github.com/ > asciidocfx/AsciidocFX/issues/227 > > Thanks. > > 2016-07-21 2:38 GMT+03:00 Kevin Rushforth : > >> I'll add a comment to that effect (although our incident triage team is >> good about spotting such duplicates). >> >> -- Kevin >> >> >> Itai wrote: >> >>> Thank you. Having gotten no reply, and seeing the bug report was closed >>> and with not means of commenting in the bug report system, I have since >>> (about an hour ago) filed a more detailed report (JI-9042009). I believe >>> they could be safely merged, but the second one does contain some more >>> info. >>> On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth < >>> kevin.rushforth at oracle.com > wrote: >>> >>> JI-9041860 has now been transferred to the JDK project as: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8161911 >>> >>> Our support engineer was not able to reproduce the problem, so >>> closed it as such. Based on the additional information you >>> provided, I have reopened the bug and will ask someone on our team >>> with a physical Linux setup to try to reproduce it. >>> >>> To answer your question, we are not aware of any such leaks. >>> >>> -- Kevin >>> >>> >>> >>> Itai wrote: >>> >>> I'm experiencing multiple memory leaks with JavaFX on Linux, >>> to the point >>> where I'm not sure which bug to report, as it seems like a >>> systematic >>> issue. >>> >>> The memory leak seems to be completely absent when using the >>> software >>> renderer (-Dprism.order=sw), and does not seem to happen on >>> Windows >>> (presumably not on Mac either, although I have no Mac to test >>> it). >>> >>> Test cases include: >>> >>> 1. Use ProgressIndicator with progress set to Indeterminate - >>> with default >>> (HW) renderer memory consumption quickly rises, climbing to >>> 8GB and more if >>> not killed. With software renderer memory usage is reasonable. >>> 2. Using Scene Builder - after a few minutes with Scene >>> Builder it quickly >>> gobbles up all system memory - again, problem seems to go away >>> if using >>> software renderer. This test is less repeatable, as some >>> actions seem more >>> detrimental than others. >>> 3. Using Transitions on nodes (See attached code "Demo.java". >>> I have filed >>> a bug report about this issue, JI-9041860). Running with >>> default renderer >>> the simple program reaches 3GB within 30 seconds, and memory >>> continues to >>> climb. On software renderer memory consumption remains <100MB >>> for a minute >>> and more. >>> >>> As I said, I am no longer sure it is prudent to report >>> specific bugs, as >>> this seems to be some low-level problem. I just want to know >>> if this is a >>> known issue and if there is any way to get around it (besides >>> using the >>> software pipe, which obviously has it's own disadvantages). >>> >>> >>> For reference, I'm using Debian (testing, updated today), >>> kernel version >>> 4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 (kms >>> driver), >>> OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is identical >>> on Oracle >>> version). >>> >>> If there is any other information needed please let me know. >>> If this is a >>> known issue I apologize, but I have tried searching and didn't >>> find any >>> reports of such behavior. >>> >>> Thank you. >>> >>> >>> > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta > > From james.graham at oracle.com Thu Aug 11 21:08:59 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 11 Aug 2016 14:08:59 -0700 Subject: Memory leaks on Linux with hardware renderer In-Reply-To: References: <579008D1.1030407@oracle.com> <57900B89.2070401@oracle.com> <5790E678.8020905@oracle.com> Message-ID: <19b542e8-e710-f303-5932-1322e92f19c8@oracle.com> It looks like we create a dummy drawable for the context and install it when we are done with the frame. This appeared in rev bbb8d2772b37, but it looks like that revision involved removing the unnecessary RenderingContext class, so we may have been doing something similar via the RenderingContext class and the code was merely moved into SwapChain when the other class was deleted. Further investigation would be needed, but my mercurial rev/diffing skills are pretty primitive. Anyone care to dig a little on this and figure out if there is a reason for us to unset the drawable at the end of a frame? In either case, if we had 2 windows open, and that will happen if there is a simple popup on a choice box or a menu item I think unfortunately, then we'd still have the problem so whether or not it happens with a single window with no popup items in it, it still looks like we could potentially trigger this in common cases anyway. We should track the fix to GLX and make sure we document required patches if there is a fix... ...jim On 8/11/16 6:13 AM, Itai wrote: > I'm sorry to see the issue could still not be reproduced on any OpenJFX > team members. > > Meanwhile, I have noticed a user on reddit (JavaFX sub-reddit) had the same > issue: > https://www.reddit.com/r/JavaFX/comments/4nr2ln/memory_leak_when_calling_imageviewsettranslatex/ > . > However, they have managed to profile it (VisualVM has a bug making it > nearly impossible to CPU profile JavaFX programs), and found out a lot of > time is taken by `com.sun.prism.es2.X11GLContext.makeCurrent`. > > Taking this lead, I have found this: > http://www.gamedev.net/topic/679705-glxmakecurrent-slowly-leaks-memory/ > > Sadly I don't know enough about OpenGL to understand most of it, but it > seems to me like it's the same issue, so possibly it's not a Java issue at > all. However, maybe it can be avoided? In this linked post it is mentioned > that the leak only happens when having two windows, but in JavaFX this > always happens, so maybe there is a redundant call to `makeCurrent`? > > Hope this helps to find the source of the problem, and if it's indeed > outside of Java/JavaFX scope - report it to the relevant project. > > On Thu, Jul 21, 2016 at 6:12 PM, Kevin Rushforth > wrote: > >> Thanks. I added this to the bug report for https://bugs.openjdk.java.net/ >> browse/JDK-8161911 >> >> -- Kevin >> >> >> >> Rahman USTA wrote: >> >> Hello Kevin; >> >> One of our user reported "Must be a memory leak somewhere" in AsciidocFX >> project. It seems a similar issue. >> >> You can see the issue here https://github.com/ >> asciidocfx/AsciidocFX/issues/227 >> >> Thanks. >> >> 2016-07-21 2:38 GMT+03:00 Kevin Rushforth : >> >>> I'll add a comment to that effect (although our incident triage team is >>> good about spotting such duplicates). >>> >>> -- Kevin >>> >>> >>> Itai wrote: >>> >>>> Thank you. Having gotten no reply, and seeing the bug report was closed >>>> and with not means of commenting in the bug report system, I have since >>>> (about an hour ago) filed a more detailed report (JI-9042009). I believe >>>> they could be safely merged, but the second one does contain some more >>>> info. >>>> On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com > wrote: >>>> >>>> JI-9041860 has now been transferred to the JDK project as: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8161911 >>>> >>>> Our support engineer was not able to reproduce the problem, so >>>> closed it as such. Based on the additional information you >>>> provided, I have reopened the bug and will ask someone on our team >>>> with a physical Linux setup to try to reproduce it. >>>> >>>> To answer your question, we are not aware of any such leaks. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Itai wrote: >>>> >>>> I'm experiencing multiple memory leaks with JavaFX on Linux, >>>> to the point >>>> where I'm not sure which bug to report, as it seems like a >>>> systematic >>>> issue. >>>> >>>> The memory leak seems to be completely absent when using the >>>> software >>>> renderer (-Dprism.order=sw), and does not seem to happen on >>>> Windows >>>> (presumably not on Mac either, although I have no Mac to test >>>> it). >>>> >>>> Test cases include: >>>> >>>> 1. Use ProgressIndicator with progress set to Indeterminate - >>>> with default >>>> (HW) renderer memory consumption quickly rises, climbing to >>>> 8GB and more if >>>> not killed. With software renderer memory usage is reasonable. >>>> 2. Using Scene Builder - after a few minutes with Scene >>>> Builder it quickly >>>> gobbles up all system memory - again, problem seems to go away >>>> if using >>>> software renderer. This test is less repeatable, as some >>>> actions seem more >>>> detrimental than others. >>>> 3. Using Transitions on nodes (See attached code "Demo.java". >>>> I have filed >>>> a bug report about this issue, JI-9041860). Running with >>>> default renderer >>>> the simple program reaches 3GB within 30 seconds, and memory >>>> continues to >>>> climb. On software renderer memory consumption remains <100MB >>>> for a minute >>>> and more. >>>> >>>> As I said, I am no longer sure it is prudent to report >>>> specific bugs, as >>>> this seems to be some low-level problem. I just want to know >>>> if this is a >>>> known issue and if there is any way to get around it (besides >>>> using the >>>> software pipe, which obviously has it's own disadvantages). >>>> >>>> >>>> For reference, I'm using Debian (testing, updated today), >>>> kernel version >>>> 4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 (kms >>>> driver), >>>> OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is identical >>>> on Oracle >>>> version). >>>> >>>> If there is any other information needed please let me know. >>>> If this is a >>>> known issue I apologize, but I have tried searching and didn't >>>> find any >>>> reports of such behavior. >>>> >>>> Thank you. >>>> >>>> >>>> >> >> >> -- >> Rahman USTA >> Istanbul JUG >> https://github.com/rahmanusta >> >> From kevin.rushforth at oracle.com Thu Aug 11 22:00:51 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 Aug 2016 15:00:51 -0700 Subject: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene. In-Reply-To: <4764FA63-8ED6-481E-9B63-DC919B85A02B@nyssen.org> References: <8f6f91a9-0ea9-1769-d22d-ca3e19b8c5b7@oracle.com> <579A231B.8030009@oracle.com> <9C6E80F0-6826-43A5-8483-3C570B932D10@nyssen.org> <579A2CD5.5020600@oracle.com> <57A92D97.6000302@oracle.com> <4764FA63-8ED6-481E-9B63-DC919B85A02B@nyssen.org> Message-ID: <57ACF593.3060205@oracle.com> Alexander Nyssen wrote: > Hi Kevin, > > thanks for your feedback. Please fin my comments inline. > > >> Am 09.08.2016 um 03:10 schrieb Kevin Rushforth : >> >> I uploaded the patch, reviewed it, and provided comments in the bug report. The short version is: >> >> * The new API looks good >> >> * There is a missing '@since 9' in the javadoc comments along with a few typos / style issues >> > > I will take care of it. Is there a style guide? > Not a current one. The ones I pointed out in the JBS issue were either grammatical or capitalization (other than the '@since' which is required for all new API). >> * Rather than using reflection and setAccessible in the implementation, please add a public getHostContainer method to EmbeddedWindow (since it is an internal method, there is no concern with doing that -- it isn't API). >> > > Such a getHost() method was already introduced to EmbeddedWindow as part of the patch (to obtain the HostContainer from it). The reflection code within getFXCanvas() is used to access the enclosing instance (i.e. the FXCanvas) of the HostContainer. We could only circumvent this by introducing a constructor to HostContainer and by passing in the enclosing FXCanvas instance explicitly (so we can query it via an explicit getter, which would have to be introduced in addition). Would you prefer that? > Ah, I see what you are doing now. There is an easier way, then. Just add a default (package) scope 'fxCanvas' variable in the inner class initialized to 'FXCanvas.this' and you will be able to access it directly, since an instance of an inner class can always get access to the instance of the enclosing class. private class HostContainer implements HostInterface { final FXCanvas fxCanvas = FXCanvas.this; ... I updated the bug report with this and the other style issues. I haven't tested it yet, but other than the listed issues it looks very close to being done. -- Kevin > >> Additionally, I requested JDK 9 release team approval for this. The approval process can proceed in parallel with your addressing the issues I raised. >> >> ? Kevin >> > > Regards, > Alexander > > >> Alexander Nyssen wrote: >> >>> Hi Kevin, >>> >>> attached please find a revised patch. My comments are inlined. >>> >>> >>>> Am 28.07.2016 um 18:03 schrieb Kevin Rushforth >: >>>> >>>> Hi >>>> >>>> Alexander Nyssen wrote: >>>> >>>>> Hi, >>>>> >>>>> I have added my comments below: >>>>> >>>>> >>>>> >>>>>> Am 28.07.2016 um 17:22 schrieb Kevin Rushforth >: >>>>>> >>>>>> I got the attachment, since Alexander also CCed me directly. I will attach it shortly. >>>>>> >>>>> Thanks! >>>>> >>>> Done. >>>> >>>> >>>>>> I do have two comments on this: >>>>>> >>>>>> 1) We are past Feature Freeze, so all Enhancements need formal JDK 9 R-team approval [1][2]. In this case, the justification can be internal API that is no longer accessible in JDK 9 due to Jigsaw (I would be very reluctant to consider any other Enhancement request this late in the process), but I will need to look at it and then take it through the approval process, provided that I feel it is in scope. >>>>>> >>>>> I was not aware about this, but I would of course appreciate if it could be included (due to Jigsaw). Thanks for considering it at least. >>>>> >>>> I'll take a closer look tomorrow or Monday (no more time today). At first glance it seems like something reasonable to take forward. >>>> >>> That sounds promising. Thanks! >>> >>> >>>>>> 2) Some of the changes you list seem unrelated to this enhancement and are better done as separate issues (e.g., the rework of the SWTCursorsTest). Also, I am unconvinced of the need to force GTK 2; in fact it seems at odds with the work we have done with JEP 283 [3]. >>>>>> >>>>> Well, the test case refactoring is somehow related, as I introduced the common SWT rule while introducing the second SWT test. However, I could provide it as a separate contribution if that was wished (and a JIRA issue was provided), but the rest of this contribution of course requires it as a prerequisite. If this enhancement could not be included in JDK 9, I would have to provide it as a separate contribution, as I would have to re-introduce FXCanvasTest in other succeeding bugfix contributions (JDK-8143596, JDK-8143596). >>>>> >>>> I see. I did take a quick look at this and the test changes seem fine as part of this. I see you created the new test with 'hg cp' (or similar) which records it as a copy of the SWTCursorsTest.java file, which given the number of changes is not needed (and not really useful), but that's easy to fix. >>>> >>> Done (I copied it within IntelliJ and the IDE seems to have applied hg copy). >>> >>> >>>> There are several white space changes in FXCanvas.java that should be reverted. Our policy is that we do not make unrelated changes, including white space changes, in portions of a file that aren't otherwise modified by a patch. >>>> >>> Done (I used the IntelliJ formatter). >>> >>>>> The GTK2 flag I introduced just affects SWT. As the swt library that is bundled is rather old (3.7.2) that seemed to be safer (we have observed quite a few problems when running SWT on GTK3). We can of course remove it if tests are not affected by it. >>>>> >>>> We don't actually bundle swt itself, although we do download an old copy to link against, and to run tests against. In any case, given that our minimum Linux platform for JDK 9 is Ubuntu 16.04, it might not have GTK2 installed by default. Please revert this change to build.gradle. If test issues arise on Linux we will deal with it at that time (possibly by moving to a newer version of swt to run tests). >>>> >>> I removed the SWT option. However, the previous logger message is no longer valid and should be removed, so the patch still contains a change to build.gradle. >>> >>> >>>> Thanks. >>>> >>>> ? Kevin >>>> >>> Regards, >>> Alexander >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>>> >>>>>> ? Kevin >>>>>> >>>>> Regards, >>>>> Alexander >>>>> >>>>> >>>>>> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004485.html >>>>>> [2] http://openjdk.java.net/projects/jdk9/fc-extension-process >>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8145568 >>>>>> >>>>>> >>>>>> Phil Race wrote: >>>>>> >>>>>>> The mailing list rejects attachments so we got nothing. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 7/28/2016 8:06 AM, Alexander Nyssen wrote: >>>>>>> >>>>>>>> Hi Kevin, all, >>>>>>>> >>>>>>>> attached please find a patch that fixes JDK-8160325. The patch comprises the following changes: >>>>>>>> >>>>>>>> - Provided static FXCanvas#getFXCanvas(Scene) method to obtain the FXCanvas instance embedding the given Scene instance. >>>>>>>> - Added EmbeddedWindow.getHost() so the HostInterface can be retrieved. >>>>>>>> - Added FXCanvasTest with a test method to test correct behavior of FXCanvas#getFXCanvas(Scene). >>>>>>>> - Introduced SwtTest JUnit MethodRule to have more concise tests and ensure it is also used by SWTCursorsTest. >>>>>>>> - Ensured SWT tests are executed using GTK2 on Linux. >>>>>>>> >>>>>>>> I reworked the existing SWTCursorsTest while introducing FXCanvasTest to be more concise. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Alexander >>>>>>>> >>>>>>>> > > From chien.yang at oracle.com Thu Aug 11 22:39:16 2016 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 11 Aug 2016 15:39:16 -0700 Subject: Memory leaks on Linux with hardware renderer In-Reply-To: <19b542e8-e710-f303-5932-1322e92f19c8@oracle.com> References: <579008D1.1030407@oracle.com> <57900B89.2070401@oracle.com> <5790E678.8020905@oracle.com> <19b542e8-e710-f303-5932-1322e92f19c8@oracle.com> Message-ID: <57ACFE94.1020302@oracle.com> Based on my recollection, this oddity (2 contexts) is because we use CALayer on Mac. We have tested in early prototype, when we did the switch from JOGL to native GL, Prism implementation on Linux works fine with a single GL context. - Chien On 8/11/2016 2:08 PM, Jim Graham wrote: > It looks like we create a dummy drawable for the context and install > it when we are done with the frame. This appeared in rev > bbb8d2772b37, but it looks like that revision involved removing the > unnecessary RenderingContext class, so we may have been doing > something similar via the RenderingContext class and the code was > merely moved into SwapChain when the other class was deleted. Further > investigation would be needed, but my mercurial rev/diffing skills are > pretty primitive. Anyone care to dig a little on this and figure out > if there is a reason for us to unset the drawable at the end of a frame? > > In either case, if we had 2 windows open, and that will happen if > there is a simple popup on a choice box or a menu item I think > unfortunately, then we'd still have the problem so whether or not it > happens with a single window with no popup items in it, it still looks > like we could potentially trigger this in common cases anyway. We > should track the fix to GLX and make sure we document required patches > if there is a fix... > > ...jim > > On 8/11/16 6:13 AM, Itai wrote: >> I'm sorry to see the issue could still not be reproduced on any OpenJFX >> team members. >> >> Meanwhile, I have noticed a user on reddit (JavaFX sub-reddit) had >> the same >> issue: >> https://www.reddit.com/r/JavaFX/comments/4nr2ln/memory_leak_when_calling_imageviewsettranslatex/ >> >> . >> However, they have managed to profile it (VisualVM has a bug making it >> nearly impossible to CPU profile JavaFX programs), and found out a >> lot of >> time is taken by `com.sun.prism.es2.X11GLContext.makeCurrent`. >> >> Taking this lead, I have found this: >> http://www.gamedev.net/topic/679705-glxmakecurrent-slowly-leaks-memory/ >> >> Sadly I don't know enough about OpenGL to understand most of it, but it >> seems to me like it's the same issue, so possibly it's not a Java >> issue at >> all. However, maybe it can be avoided? In this linked post it is >> mentioned >> that the leak only happens when having two windows, but in JavaFX this >> always happens, so maybe there is a redundant call to `makeCurrent`? >> >> Hope this helps to find the source of the problem, and if it's indeed >> outside of Java/JavaFX scope - report it to the relevant project. >> >> On Thu, Jul 21, 2016 at 6:12 PM, Kevin Rushforth >> >> wrote: >> >>> Thanks. I added this to the bug report for >>> https://bugs.openjdk.java.net/ >>> browse/JDK-8161911 >>> >>> -- Kevin >>> >>> >>> >>> Rahman USTA wrote: >>> >>> Hello Kevin; >>> >>> One of our user reported "Must be a memory leak somewhere" in >>> AsciidocFX >>> project. It seems a similar issue. >>> >>> You can see the issue here https://github.com/ >>> asciidocfx/AsciidocFX/issues/227 >>> >>> Thanks. >>> >>> 2016-07-21 2:38 GMT+03:00 Kevin Rushforth : >>> >>>> I'll add a comment to that effect (although our incident triage >>>> team is >>>> good about spotting such duplicates). >>>> >>>> -- Kevin >>>> >>>> >>>> Itai wrote: >>>> >>>>> Thank you. Having gotten no reply, and seeing the bug report was >>>>> closed >>>>> and with not means of commenting in the bug report system, I have >>>>> since >>>>> (about an hour ago) filed a more detailed report (JI-9042009). I >>>>> believe >>>>> they could be safely merged, but the second one does contain some >>>>> more >>>>> info. >>>>> On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com > >>>>> wrote: >>>>> >>>>> JI-9041860 has now been transferred to the JDK project as: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8161911 >>>>> >>>>> Our support engineer was not able to reproduce the problem, so >>>>> closed it as such. Based on the additional information you >>>>> provided, I have reopened the bug and will ask someone on our >>>>> team >>>>> with a physical Linux setup to try to reproduce it. >>>>> >>>>> To answer your question, we are not aware of any such leaks. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Itai wrote: >>>>> >>>>> I'm experiencing multiple memory leaks with JavaFX on Linux, >>>>> to the point >>>>> where I'm not sure which bug to report, as it seems like a >>>>> systematic >>>>> issue. >>>>> >>>>> The memory leak seems to be completely absent when using the >>>>> software >>>>> renderer (-Dprism.order=sw), and does not seem to happen on >>>>> Windows >>>>> (presumably not on Mac either, although I have no Mac to test >>>>> it). >>>>> >>>>> Test cases include: >>>>> >>>>> 1. Use ProgressIndicator with progress set to Indeterminate - >>>>> with default >>>>> (HW) renderer memory consumption quickly rises, climbing to >>>>> 8GB and more if >>>>> not killed. With software renderer memory usage is >>>>> reasonable. >>>>> 2. Using Scene Builder - after a few minutes with Scene >>>>> Builder it quickly >>>>> gobbles up all system memory - again, problem seems to go >>>>> away >>>>> if using >>>>> software renderer. This test is less repeatable, as some >>>>> actions seem more >>>>> detrimental than others. >>>>> 3. Using Transitions on nodes (See attached code "Demo.java". >>>>> I have filed >>>>> a bug report about this issue, JI-9041860). Running with >>>>> default renderer >>>>> the simple program reaches 3GB within 30 seconds, and memory >>>>> continues to >>>>> climb. On software renderer memory consumption remains <100MB >>>>> for a minute >>>>> and more. >>>>> >>>>> As I said, I am no longer sure it is prudent to report >>>>> specific bugs, as >>>>> this seems to be some low-level problem. I just want to know >>>>> if this is a >>>>> known issue and if there is any way to get around it (besides >>>>> using the >>>>> software pipe, which obviously has it's own disadvantages). >>>>> >>>>> >>>>> For reference, I'm using Debian (testing, updated today), >>>>> kernel version >>>>> 4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 (kms >>>>> driver), >>>>> OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is >>>>> identical >>>>> on Oracle >>>>> version). >>>>> >>>>> If there is any other information needed please let me know. >>>>> If this is a >>>>> known issue I apologize, but I have tried searching and >>>>> didn't >>>>> find any >>>>> reports of such behavior. >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> >>> >>> >>> -- >>> Rahman USTA >>> Istanbul JUG >>> https://github.com/rahmanusta >>> >>> From kevin.rushforth at oracle.com Thu Aug 11 22:46:14 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 Aug 2016 15:46:14 -0700 Subject: Memory leaks on Linux with hardware renderer In-Reply-To: <57ACFE94.1020302@oracle.com> References: <579008D1.1030407@oracle.com> <57900B89.2070401@oracle.com> <5790E678.8020905@oracle.com> <19b542e8-e710-f303-5932-1322e92f19c8@oracle.com> <57ACFE94.1020302@oracle.com> Message-ID: <57AD0036.6080705@oracle.com> To add to what Chien and Jim said, we use 1 context (ignoring Mac where glass also has a context) and N+1 drawables for N windows. We use a drawable per Window (including popup Windows used for Tooltip, ComboBox, etc), and a dummy drawable for when we are "in between" frames. The switch to the dummy drawable is necessary to allow our resources disposal mechanism to work. And as Jim mentioned, Popup windows are common enough that we would still do frequent calls to glXMakeCurrent even without the dummy drawable. -- Kevin Chien Yang wrote: > Based on my recollection, this oddity (2 contexts) is because we use > CALayer on Mac. We have tested in early prototype, when we did the > switch from JOGL to native GL, Prism implementation on Linux works > fine with a single GL context. > > - Chien > > On 8/11/2016 2:08 PM, Jim Graham wrote: >> It looks like we create a dummy drawable for the context and install >> it when we are done with the frame. This appeared in rev >> bbb8d2772b37, but it looks like that revision involved removing the >> unnecessary RenderingContext class, so we may have been doing >> something similar via the RenderingContext class and the code was >> merely moved into SwapChain when the other class was deleted. >> Further investigation would be needed, but my mercurial rev/diffing >> skills are pretty primitive. Anyone care to dig a little on this and >> figure out if there is a reason for us to unset the drawable at the >> end of a frame? >> >> In either case, if we had 2 windows open, and that will happen if >> there is a simple popup on a choice box or a menu item I think >> unfortunately, then we'd still have the problem so whether or not it >> happens with a single window with no popup items in it, it still >> looks like we could potentially trigger this in common cases anyway. >> We should track the fix to GLX and make sure we document required >> patches if there is a fix... >> >> ...jim >> >> On 8/11/16 6:13 AM, Itai wrote: >>> I'm sorry to see the issue could still not be reproduced on any OpenJFX >>> team members. >>> >>> Meanwhile, I have noticed a user on reddit (JavaFX sub-reddit) had >>> the same >>> issue: >>> https://www.reddit.com/r/JavaFX/comments/4nr2ln/memory_leak_when_calling_imageviewsettranslatex/ >>> >>> . >>> However, they have managed to profile it (VisualVM has a bug making it >>> nearly impossible to CPU profile JavaFX programs), and found out a >>> lot of >>> time is taken by `com.sun.prism.es2.X11GLContext.makeCurrent`. >>> >>> Taking this lead, I have found this: >>> http://www.gamedev.net/topic/679705-glxmakecurrent-slowly-leaks-memory/ >>> >>> Sadly I don't know enough about OpenGL to understand most of it, but it >>> seems to me like it's the same issue, so possibly it's not a Java >>> issue at >>> all. However, maybe it can be avoided? In this linked post it is >>> mentioned >>> that the leak only happens when having two windows, but in JavaFX this >>> always happens, so maybe there is a redundant call to `makeCurrent`? >>> >>> Hope this helps to find the source of the problem, and if it's indeed >>> outside of Java/JavaFX scope - report it to the relevant project. >>> >>> On Thu, Jul 21, 2016 at 6:12 PM, Kevin Rushforth >>> >>> wrote: >>> >>>> Thanks. I added this to the bug report for >>>> https://bugs.openjdk.java.net/ >>>> browse/JDK-8161911 >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Rahman USTA wrote: >>>> >>>> Hello Kevin; >>>> >>>> One of our user reported "Must be a memory leak somewhere" in >>>> AsciidocFX >>>> project. It seems a similar issue. >>>> >>>> You can see the issue here https://github.com/ >>>> asciidocfx/AsciidocFX/issues/227 >>>> >>>> Thanks. >>>> >>>> 2016-07-21 2:38 GMT+03:00 Kevin Rushforth >>>> : >>>> >>>>> I'll add a comment to that effect (although our incident triage >>>>> team is >>>>> good about spotting such duplicates). >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Itai wrote: >>>>> >>>>>> Thank you. Having gotten no reply, and seeing the bug report was >>>>>> closed >>>>>> and with not means of commenting in the bug report system, I have >>>>>> since >>>>>> (about an hour ago) filed a more detailed report (JI-9042009). I >>>>>> believe >>>>>> they could be safely merged, but the second one does contain some >>>>>> more >>>>>> info. >>>>>> On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth < >>>>>> kevin.rushforth at oracle.com > >>>>>> wrote: >>>>>> >>>>>> JI-9041860 has now been transferred to the JDK project as: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8161911 >>>>>> >>>>>> Our support engineer was not able to reproduce the problem, so >>>>>> closed it as such. Based on the additional information you >>>>>> provided, I have reopened the bug and will ask someone on our >>>>>> team >>>>>> with a physical Linux setup to try to reproduce it. >>>>>> >>>>>> To answer your question, we are not aware of any such leaks. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Itai wrote: >>>>>> >>>>>> I'm experiencing multiple memory leaks with JavaFX on Linux, >>>>>> to the point >>>>>> where I'm not sure which bug to report, as it seems like a >>>>>> systematic >>>>>> issue. >>>>>> >>>>>> The memory leak seems to be completely absent when using the >>>>>> software >>>>>> renderer (-Dprism.order=sw), and does not seem to happen on >>>>>> Windows >>>>>> (presumably not on Mac either, although I have no Mac to >>>>>> test >>>>>> it). >>>>>> >>>>>> Test cases include: >>>>>> >>>>>> 1. Use ProgressIndicator with progress set to >>>>>> Indeterminate - >>>>>> with default >>>>>> (HW) renderer memory consumption quickly rises, climbing to >>>>>> 8GB and more if >>>>>> not killed. With software renderer memory usage is >>>>>> reasonable. >>>>>> 2. Using Scene Builder - after a few minutes with Scene >>>>>> Builder it quickly >>>>>> gobbles up all system memory - again, problem seems to go >>>>>> away >>>>>> if using >>>>>> software renderer. This test is less repeatable, as some >>>>>> actions seem more >>>>>> detrimental than others. >>>>>> 3. Using Transitions on nodes (See attached code >>>>>> "Demo.java". >>>>>> I have filed >>>>>> a bug report about this issue, JI-9041860). Running with >>>>>> default renderer >>>>>> the simple program reaches 3GB within 30 seconds, and memory >>>>>> continues to >>>>>> climb. On software renderer memory consumption remains >>>>>> <100MB >>>>>> for a minute >>>>>> and more. >>>>>> >>>>>> As I said, I am no longer sure it is prudent to report >>>>>> specific bugs, as >>>>>> this seems to be some low-level problem. I just want to know >>>>>> if this is a >>>>>> known issue and if there is any way to get around it >>>>>> (besides >>>>>> using the >>>>>> software pipe, which obviously has it's own disadvantages). >>>>>> >>>>>> >>>>>> For reference, I'm using Debian (testing, updated today), >>>>>> kernel version >>>>>> 4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 (kms >>>>>> driver), >>>>>> OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is >>>>>> identical >>>>>> on Oracle >>>>>> version). >>>>>> >>>>>> If there is any other information needed please let me know. >>>>>> If this is a >>>>>> known issue I apologize, but I have tried searching and >>>>>> didn't >>>>>> find any >>>>>> reports of such behavior. >>>>>> >>>>>> Thank you. >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Rahman USTA >>>> Istanbul JUG >>>> https://github.com/rahmanusta >>>> >>>> > From alexander at nyssen.org Fri Aug 12 05:46:25 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Fri, 12 Aug 2016 07:46:25 +0200 Subject: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene. In-Reply-To: <57ACF593.3060205@oracle.com> References: <8f6f91a9-0ea9-1769-d22d-ca3e19b8c5b7@oracle.com> <579A231B.8030009@oracle.com> <9C6E80F0-6826-43A5-8483-3C570B932D10@nyssen.org> <579A2CD5.5020600@oracle.com> <57A92D97.6000302@oracle.com> <4764FA63-8ED6-481E-9B63-DC919B85A02B@nyssen.org> <57ACF593.3060205@oracle.com> Message-ID: <1DF1D32C-A194-4BC8-8AAD-A4BA640D87C4@nyssen.org> Hi Kevin, attached please find a revised patch that contains the corrections you requested. The patch is now applicable to the new module structure (modues with 'javafx.' prefix). Regards, Alexander > Am 12.08.2016 um 00:00 schrieb Kevin Rushforth : > > > > Alexander Nyssen wrote: >> >> Hi Kevin, >> >> thanks for your feedback. Please fin my comments inline. >> >> >>> Am 09.08.2016 um 03:10 schrieb Kevin Rushforth : >>> >>> I uploaded the patch, reviewed it, and provided comments in the bug report. The short version is: >>> >>> * The new API looks good >>> >>> * There is a missing '@since 9' in the javadoc comments along with a few typos / style issues >>> >> I will take care of it. Is there a style guide? >> > > Not a current one. The ones I pointed out in the JBS issue were either grammatical or capitalization (other than the '@since' which is required for all new API). > >>> * Rather than using reflection and setAccessible in the implementation, please add a public getHostContainer method to EmbeddedWindow (since it is an internal method, there is no concern with doing that -- it isn't API). >>> >> Such a getHost() method was already introduced to EmbeddedWindow as part of the patch (to obtain the HostContainer from it). The reflection code within getFXCanvas() is used to access the enclosing instance (i.e. the FXCanvas) of the HostContainer. We could only circumvent this by introducing a constructor to HostContainer and by passing in the enclosing FXCanvas instance explicitly (so we can query it via an explicit getter, which would have to be introduced in addition). Would you prefer that? >> > > Ah, I see what you are doing now. There is an easier way, then. Just add a default (package) scope 'fxCanvas' variable in the inner class initialized to 'FXCanvas.this' and you will be able to access it directly, since an instance of an inner class can always get access to the instance of the enclosing class. > > private class HostContainer implements HostInterface { > final FXCanvas fxCanvas = FXCanvas.this; > ... > > I updated the bug report with this and the other style issues. I haven't tested it yet, but other than the listed issues it looks very close to being done. > > -- Kevin > > >> >>> Additionally, I requested JDK 9 release team approval for this. The approval process can proceed in parallel with your addressing the issues I raised. >>> >>> ? Kevin >>> >> Regards, >> Alexander >> >> >>> Alexander Nyssen wrote: >>> >>>> Hi Kevin, >>>> >>>> attached please find a revised patch. My comments are inlined. >>>> >>>> >>>>> Am 28.07.2016 um 18:03 schrieb Kevin Rushforth >: >>>>> >>>>> Hi >>>>> >>>>> Alexander Nyssen wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have added my comments below: >>>>>> >>>>>> >>>>>> >>>>>>> Am 28.07.2016 um 17:22 schrieb Kevin Rushforth >: >>>>>>> >>>>>>> I got the attachment, since Alexander also CCed me directly. I will attach it shortly. >>>>>>> >>>>>> Thanks! >>>>>> >>>>> Done. >>>>> >>>>> >>>>>>> I do have two comments on this: >>>>>>> >>>>>>> 1) We are past Feature Freeze, so all Enhancements need formal JDK 9 R-team approval [1][2]. In this case, the justification can be internal API that is no longer accessible in JDK 9 due to Jigsaw (I would be very reluctant to consider any other Enhancement request this late in the process), but I will need to look at it and then take it through the approval process, provided that I feel it is in scope. >>>>>>> >>>>>> I was not aware about this, but I would of course appreciate if it could be included (due to Jigsaw). Thanks for considering it at least. >>>>>> >>>>> I'll take a closer look tomorrow or Monday (no more time today). At first glance it seems like something reasonable to take forward. >>>>> >>>> That sounds promising. Thanks! >>>> >>>> >>>>>>> 2) Some of the changes you list seem unrelated to this enhancement and are better done as separate issues (e.g., the rework of the SWTCursorsTest). Also, I am unconvinced of the need to force GTK 2; in fact it seems at odds with the work we have done with JEP 283 [3]. >>>>>>> >>>>>> Well, the test case refactoring is somehow related, as I introduced the common SWT rule while introducing the second SWT test. However, I could provide it as a separate contribution if that was wished (and a JIRA issue was provided), but the rest of this contribution of course requires it as a prerequisite. If this enhancement could not be included in JDK 9, I would have to provide it as a separate contribution, as I would have to re-introduce FXCanvasTest in other succeeding bugfix contributions (JDK-8143596, JDK-8143596). >>>>>> >>>>> I see. I did take a quick look at this and the test changes seem fine as part of this. I see you created the new test with 'hg cp' (or similar) which records it as a copy of the SWTCursorsTest.java file, which given the number of changes is not needed (and not really useful), but that's easy to fix. >>>>> >>>> Done (I copied it within IntelliJ and the IDE seems to have applied hg copy). >>>> >>>> >>>>> There are several white space changes in FXCanvas.java that should be reverted. Our policy is that we do not make unrelated changes, including white space changes, in portions of a file that aren't otherwise modified by a patch. >>>>> >>>> Done (I used the IntelliJ formatter). >>>> >>>>>> The GTK2 flag I introduced just affects SWT. As the swt library that is bundled is rather old (3.7.2) that seemed to be safer (we have observed quite a few problems when running SWT on GTK3). We can of course remove it if tests are not affected by it. >>>>>> >>>>> We don't actually bundle swt itself, although we do download an old copy to link against, and to run tests against. In any case, given that our minimum Linux platform for JDK 9 is Ubuntu 16.04, it might not have GTK2 installed by default. Please revert this change to build.gradle. If test issues arise on Linux we will deal with it at that time (possibly by moving to a newer version of swt to run tests). >>>>> >>>> I removed the SWT option. However, the previous logger message is no longer valid and should be removed, so the patch still contains a change to build.gradle. >>>> >>>> >>>>> Thanks. >>>>> >>>>> ? Kevin >>>>> >>>> Regards, >>>> Alexander >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>>> >>>>>>> ? Kevin >>>>>>> >>>>>> Regards, >>>>>> Alexander >>>>>> >>>>>> >>>>>>> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004485.html >>>>>>> [2] http://openjdk.java.net/projects/jdk9/fc-extension-process >>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8145568 >>>>>>> >>>>>>> >>>>>>> Phil Race wrote: >>>>>>> >>>>>>>> The mailing list rejects attachments so we got nothing. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 7/28/2016 8:06 AM, Alexander Nyssen wrote: >>>>>>>> >>>>>>>>> Hi Kevin, all, >>>>>>>>> >>>>>>>>> attached please find a patch that fixes JDK-8160325. The patch comprises the following changes: >>>>>>>>> >>>>>>>>> - Provided static FXCanvas#getFXCanvas(Scene) method to obtain the FXCanvas instance embedding the given Scene instance. >>>>>>>>> - Added EmbeddedWindow.getHost() so the HostInterface can be retrieved. >>>>>>>>> - Added FXCanvasTest with a test method to test correct behavior of FXCanvas#getFXCanvas(Scene). >>>>>>>>> - Introduced SwtTest JUnit MethodRule to have more concise tests and ensure it is also used by SWTCursorsTest. >>>>>>>>> - Ensured SWT tests are executed using GTK2 on Linux. >>>>>>>>> >>>>>>>>> I reworked the existing SWTCursorsTest while introducing FXCanvasTest to be more concise. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexander >>>>>>>>> >>>>>>>>> >> From alexander at nyssen.org Fri Aug 12 14:04:02 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Fri, 12 Aug 2016 16:04:02 +0200 Subject: [PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene Message-ID: <39317253-63D5-4FD3-A0FE-D506D0830237@nyssen.org> Hi Kevin, attached please find an initial patch for https://bugs.openjdk.java.net/browse/JDK-8161282 . The patch is not as minimal as I had hoped, as the EmbeddedSceneInterface had to be changed to differentiate between mouse and scroll events (while up to now, scroll events are handled as mouse events), but for me this seemed necessary to fix this issue properly. As a result, JFXPanel had to be adjusted as well to comply to the changes in the EmbeddedSceneInterface, while its behavior should not have changed. As horizontal mouse events cannot be synthesized via Display.post(Event) yet (an open issue for SWT), I did not add an automated test, but instead added a manual one (FXCanvasMouseWheelEventsTest). Therefore, this patch does not depend on the patch I provided earlier for JDK-8160325. Best Regards, Alexander From vadim.pakhnushev at oracle.com Fri Aug 12 14:42:49 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 12 Aug 2016 17:42:49 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <495ab1fd-60cb-064b-37ee-e89ba0353561@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From guru.hb at oracle.com Fri Aug 12 17:28:40 2016 From: guru.hb at oracle.com (Guru Hb) Date: Fri, 12 Aug 2016 22:58:40 +0530 Subject: [9] Review request 8163971: Revert "MiscellaneousTest.testRT26306 and testWebViewWithoutSceneGraph" Indentation done while JDK-8163582 fix In-Reply-To: References: <42096db5-3686-f2fb-ce65-f74a3f607b86@oracle.com> <7ac9a346-2b91-fc15-60ad-5a0dd9be66a2@oracle.com> <5b0bb5ee-70c7-3e6d-35ef-1d57b6393c51@oracle.com> <1cac2cd1-9e13-fec7-e1d5-59998fe1b24f@oracle.com> Message-ID: Hi Kevin, Please review the fix for JBS : https://bugs.openjdk.java.net/browse/JDK-8163971 Webrev : http://cr.openjdk.java.net/~ghb/8163971/webrev.00/ Accidentally Indent two other Unit test case while merging JDK-8163582. Thanks, Guru From oliver at bugabinga.net Sun Aug 14 09:09:29 2016 From: oliver at bugabinga.net (Oliver Krylow) Date: Sun, 14 Aug 2016 11:09:29 +0200 Subject: Compiling OpenJFX on OpenBSD In-Reply-To: <20160808045923.2f1e9e75@uusilauta.turvamies.local> Message-ID: From daniel.gloeckner at 360t.com Mon Aug 15 13:46:05 2016 From: daniel.gloeckner at 360t.com (=?iso-8859-1?Q?Daniel_Gl=F6ckner?=) Date: Mon, 15 Aug 2016 13:46:05 +0000 Subject: Structuring CSS Stylesheets Message-ID: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C057A@EOFFICE-EX01.360t.com> Hi, We recently came across a number of performance issues which were caused by our poor CSS. Our stylesheet contained too many selectors, specifically too many generic selectors targeting "common" JavaFX controls (.text, .label etc.). We found the culprits by patching the JRE, adding some statistics to SimpleSelector and CompoundSelector. I was wondering whether there are easier ways but anyway, it works ;) We've meanwhile improved our CSS performance (by making a bunch of selectors more specific) but want to re-structure the stylesheets to be more future-proof (with even better performance ;)). Could you quickly comment on the following idea? Our CSS is already divided into several stylesheets (e.g. table.css, some-dialog.css etc.). These stylesheets are all imported via @import into a global theme.css. theme.css is then added to the scene. We're thinking about adding the individual stylesheets only to nodes which need them, for example our UI component factory would add table.css to a TableView's list of stylesheets (tv. getStylesheets().add("/path/to/table.css"). The global theme.css would be minimal and only define colors and fonts. What do you think about this approach? Will this work nicely with caching of CSS styles in JavaFX? Kind regards, Daniel From david.grieve at oracle.com Mon Aug 15 14:35:19 2016 From: david.grieve at oracle.com (David Grieve) Date: Mon, 15 Aug 2016 10:35:19 -0400 Subject: Structuring CSS Stylesheets In-Reply-To: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C057A@EOFFICE-EX01.360t.com> References: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C057A@EOFFICE-EX01.360t.com> Message-ID: On 8/15/16 9:46 AM, Daniel Gl?ckner wrote: > Hi, > > We recently came across a number of performance issues which were caused by our poor CSS. > > Our stylesheet contained too many selectors, specifically too many generic selectors targeting "common" JavaFX controls (.text, .label etc.). Make the selectors as specific as possible. Avoid the universal selector '*' if you can. > > We found the culprits by patching the JRE, adding some statistics to SimpleSelector and CompoundSelector. I was wondering whether there are easier ways but anyway, it works ;) This sounds like some code that would be good to share with the community. :) > > We've meanwhile improved our CSS performance (by making a bunch of selectors more specific) but want to re-structure the stylesheets to be more future-proof (with even better performance ;)). > > Could you quickly comment on the following idea? > > Our CSS is already divided into several stylesheets (e.g. table.css, some-dialog.css etc.). > These stylesheets are all imported via @import into a global theme.css. theme.css is then added to the scene. > > We're thinking about adding the individual stylesheets only to nodes which need them, for example our UI component factory would add table.css to a TableView's list of stylesheets (tv. getStylesheets().add("/path/to/table.css"). The global theme.css would be minimal and only define colors and fonts. > > What do you think about this approach? Will this work nicely with caching of CSS styles in JavaFX? I think if you are going to go this route, you might want to use Region#getUserAgentStylesheets() which adds the styles as user-agent styles. But I don't think it will buy you much in terms of CSS performance. If you the biggest bang for your buck relative to JavaFX CSS performance, avoid style lookup and relative font sizes. > > Kind regards, > Daniel From daniel.gloeckner at 360t.com Mon Aug 15 14:52:38 2016 From: daniel.gloeckner at 360t.com (=?iso-8859-1?Q?Daniel_Gl=F6ckner?=) Date: Mon, 15 Aug 2016 14:52:38 +0000 Subject: Structuring CSS Stylesheets In-Reply-To: References: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C057A@EOFFICE-EX01.360t.com> Message-ID: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C1617@EOFFICE-EX01.360t.com> Hi, Thanks a lot for your comments, David. > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf > Of David Grieve > Sent: Monday, August 15, 2016 4:35 PM > To: openjfx-dev at openjdk.java.net > Subject: Re: Structuring CSS Stylesheets > > > > On 8/15/16 9:46 AM, Daniel Gl?ckner wrote: > > Hi, > > > > We recently came across a number of performance issues which were caused > by our poor CSS. > > > > Our stylesheet contained too many selectors, specifically too many generic > selectors targeting "common" JavaFX controls (.text, .label etc.). > Make the selectors as specific as possible. Avoid the universal selector '*' if you > can. > > > > We found the culprits by patching the JRE, adding some statistics to > > SimpleSelector and CompoundSelector. I was wondering whether there are > > easier ways but anyway, it works ;) > This sounds like some code that would be good to share with the community. :) [DG] Sure thing. It's not too complicated and doesn't use external libs. Any hint where I could post it / paste it? > > > > We've meanwhile improved our CSS performance (by making a bunch of > selectors more specific) but want to re-structure the stylesheets to be more > future-proof (with even better performance ;)). > > > > Could you quickly comment on the following idea? > > > > Our CSS is already divided into several stylesheets (e.g. table.css, some- > dialog.css etc.). > > These stylesheets are all imported via @import into a global theme.css. > theme.css is then added to the scene. > > > > We're thinking about adding the individual stylesheets only to nodes which > need them, for example our UI component factory would add table.css to a > TableView's list of stylesheets (tv. getStylesheets().add("/path/to/table.css"). > The global theme.css would be minimal and only define colors and fonts. > > > > What do you think about this approach? Will this work nicely with caching of > CSS styles in JavaFX? > I think if you are going to go this route, you might want to use > Region#getUserAgentStylesheets() which adds the styles as user-agent styles. > But I don't think it will buy you much in terms of CSS performance. [DG] We also want to control / override the CSS of standard JavaFX controls like TreeTableView. Ideally we don't need to sub class them so we would need to use parent. getStylesheets().add(), right? > > If you the biggest bang for your buck relative to JavaFX CSS performance, avoid > style lookup and relative font sizes. [DG] Could you explain what you mean by "avoid style lookups"? From daniel.gloeckner at 360t.com Mon Aug 15 14:53:40 2016 From: daniel.gloeckner at 360t.com (=?iso-8859-1?Q?Daniel_Gl=F6ckner?=) Date: Mon, 15 Aug 2016 14:53:40 +0000 Subject: Focus Traversal of Nodes / Cells in TreeTableView Message-ID: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C1627@EOFFICE-EX01.360t.com> Hi, We're trying to implement an editable data grid using a TreeTableView. The tree table contains nodes: List> columns = ...; theTreeTable.getColumns().setAll(columns); Some of the nodes are custom controls (basically advanced text fields) which are editable: someColumn.setCellValueFactory(cellDate -> { SomeModel lineModel = cellDate.getValue().getValue(); Node someEditor = GuiComponentUtils.createEditorComponent(); someEditor.setModel(lineModel); return new SimpleObjectProperty<>( someEditor); }); The task at hand is to make these controls focus traversable (column by column and row by row). We have to consider the case that the table is not fully visible, i.e. wrapped in a ScrollPane. This does not work out of the box since the components might not exist if they are not visible. Any ideas how this could be implemented? Is this case considered at all in JavaFX's implementation of focus traversal? Maybe it will be in Java 9? Kind regards, Daniel From david.grieve at oracle.com Mon Aug 15 15:54:00 2016 From: david.grieve at oracle.com (David Grieve) Date: Mon, 15 Aug 2016 11:54:00 -0400 Subject: Structuring CSS Stylesheets In-Reply-To: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C1617@EOFFICE-EX01.360t.com> References: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C057A@EOFFICE-EX01.360t.com> <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C1617@EOFFICE-EX01.360t.com> Message-ID: <46bedd2a-bb5b-a5ba-31b4-b2696c524d4a@oracle.com> On 8/15/16 10:52 AM, Daniel Gl?ckner wrote: >>> We found the culprits by patching the JRE, adding some statistics to >>> SimpleSelector and CompoundSelector. I was wondering whether there are >>> easier ways but anyway, it works ;) >> This sounds like some code that would be good to share with the community. :) > [DG] Sure thing. It's not too complicated and doesn't use external libs. Any hint where I could post it / paste it? See https://wiki.openjdk.java.net/display/OpenJFX/Community for how to contribute > need them, for example our UI component factory would add table.css to a > TableView's list of stylesheets (tv. getStylesheets().add("/path/to/table.css"). > The global theme.css would be minimal and only define colors and fonts. >>> What do you think about this approach? Will this work nicely with caching of >> CSS styles in JavaFX? >> I think if you are going to go this route, you might want to use >> Region#getUserAgentStylesheets() which adds the styles as user-agent styles. >> But I don't think it will buy you much in terms of CSS performance. > [DG] We also want to control / override the CSS of standard JavaFX controls like TreeTableView. Ideally we don't need to sub class them so we would need to use parent. getStylesheets().add(), right? I doubt that getUserAgentStylesheets() or getStylesheets() is going to have much impact. My guess is that having the stylesheets added to the scene is going to be your best bet. I say this because the code that does the style matching has to combine styles together from Region#getUserAgentStylesheets() and Parent#getStylesheets(), whereas the styles from scene stylesheets are already combined. You have to think of these different sources of styles as sets of styles. When you have Region or Parent stylesheets, you have to create a union of those styles with the default user-agent stylesheets (e.g., caspian.css). With just scene stylesheets, you have just one set (this isn't 100% accurate, but close enough for this discussion). >> If you the biggest bang for your buck relative to JavaFX CSS performance, avoid >> style lookup and relative font sizes. > [DG] Could you explain what you mean by "avoid style lookups"? You know about styles like '-fx-base' used in caspian.css. You change the color for -fx-base and the basic colors of the UI change. This magic happens at runtime. So if I have a label in a cell in a table, and it has a style "-fx-border-color: -fx-base", JavaFX will - at runtime - try to resolve -fx-base into an actual color. It starts at the leaf and looks tries to resolve -fx-base. If it can't resolve it, it looks for a style in the parent node, and so on up the parent-chain all the way to the root node. The worst case scenario, then, is that there are no styles that resolve the value until you get to .root. This is what I mean by 'style lookups'. Its great stuff (the brainchild of Jasper Potts) because I can change the look of my UI just by setting '-fx-base'. But if I were developing a UI and I didn't care to let the users of my UI make such changes, I'd go through and remove all the lookups in caspian.css (not trivial because there are many many lookups - not just -fx-base). Or use a pre-processor such as SASS or LESS. The same sort of lookup happens when you have an em (or other relative size) because you need a font or a font-size to complete the calculation. In most cases, the lookup for a font or font-size goes all the way to .root, where it fails and falls back on Font.getDefault(). But its a trade off since em sizes let your UI more easily scale to different displays. From kevin.rushforth at oracle.com Mon Aug 15 16:02:27 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Aug 2016 09:02:27 -0700 Subject: Structuring CSS Stylesheets In-Reply-To: <46bedd2a-bb5b-a5ba-31b4-b2696c524d4a@oracle.com> References: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C057A@EOFFICE-EX01.360t.com> <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C1617@EOFFICE-EX01.360t.com> <46bedd2a-bb5b-a5ba-31b4-b2696c524d4a@oracle.com> Message-ID: <57B1E793.1080808@oracle.com> One slight correction on how to contribute below. David Grieve wrote: > > > On 8/15/16 10:52 AM, Daniel Gl?ckner wrote: >>>> We found the culprits by patching the JRE, adding some statistics to >>>> SimpleSelector and CompoundSelector. I was wondering whether there are >>>> easier ways but anyway, it works ;) >>> This sounds like some code that would be good to share with the >>> community. :) >> [DG] Sure thing. It's not too complicated and doesn't use external >> libs. Any hint where I could post it / paste it? > See https://wiki.openjdk.java.net/display/OpenJFX/Community for how to > contribute That page is just a placeholder, and finding what you need in the sub-pages a bit tricky. See the following page for how to contribute: http://openjdk.java.net/contribute/ -- Kevin >> need them, for example our UI component factory would add table.css to a >> TableView's list of stylesheets (tv. >> getStylesheets().add("/path/to/table.css"). >> The global theme.css would be minimal and only define colors and fonts. >>>> What do you think about this approach? Will this work nicely with >>>> caching of >>> CSS styles in JavaFX? >>> I think if you are going to go this route, you might want to use >>> Region#getUserAgentStylesheets() which adds the styles as user-agent >>> styles. >>> But I don't think it will buy you much in terms of CSS performance. >> [DG] We also want to control / override the CSS of standard JavaFX >> controls like TreeTableView. Ideally we don't need to sub class them >> so we would need to use parent. getStylesheets().add(), right? > I doubt that getUserAgentStylesheets() or getStylesheets() is going to > have much impact. My guess is that having the stylesheets added to the > scene is going to be your best bet. I say this because the code that > does the style matching has to combine styles together from > Region#getUserAgentStylesheets() and Parent#getStylesheets(), whereas > the styles from scene stylesheets are already combined. You have to > think of these different sources of styles as sets of styles. When you > have Region or Parent stylesheets, you have to create a union of those > styles with the default user-agent stylesheets (e.g., caspian.css). > With just scene stylesheets, you have just one set (this isn't 100% > accurate, but close enough for this discussion). > >>> If you the biggest bang for your buck relative to JavaFX CSS >>> performance, avoid >>> style lookup and relative font sizes. >> [DG] Could you explain what you mean by "avoid style lookups"? > You know about styles like '-fx-base' used in caspian.css. You change > the color for -fx-base and the basic colors of the UI change. This > magic happens at runtime. So if I have a label in a cell in a table, > and it has a style "-fx-border-color: -fx-base", JavaFX will - at > runtime - try to resolve -fx-base into an actual color. It starts at > the leaf and looks tries to resolve -fx-base. If it can't resolve it, > it looks for a style in the parent node, and so on up the parent-chain > all the way to the root node. The worst case scenario, then, is that > there are no styles that resolve the value until you get to .root. > > This is what I mean by 'style lookups'. > > Its great stuff (the brainchild of Jasper Potts) because I can change > the look of my UI just by setting '-fx-base'. But if I were developing > a UI and I didn't care to let the users of my UI make such changes, > I'd go through and remove all the lookups in caspian.css (not trivial > because there are many many lookups - not just -fx-base). Or use a > pre-processor such as SASS or LESS. > > The same sort of lookup happens when you have an em (or other relative > size) because you need a font or a font-size to complete the > calculation. In most cases, the lookup for a font or font-size goes > all the way to .root, where it fails and falls back on > Font.getDefault(). But its a trade off since em sizes let your UI more > easily scale to different displays. > From alexander at nyssen.org Mon Aug 15 17:18:47 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Mon, 15 Aug 2016 19:18:47 +0200 Subject: [PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene In-Reply-To: <39317253-63D5-4FD3-A0FE-D506D0830237@nyssen.org> References: <39317253-63D5-4FD3-A0FE-D506D0830237@nyssen.org> Message-ID: <2F35F2DC-CFB9-4DBF-B5D7-0CC9DA80C2A5@nyssen.org> Hi Kevin, please consider the following updated patch instead, which contains an additional null-check. Regards Alexander > Am 12.08.2016 um 16:04 schrieb Alexander Nyssen : > > Hi Kevin, > > attached please find an initial patch for https://bugs.openjdk.java.net/browse/JDK-8161282 . > > The patch is not as minimal as I had hoped, as the EmbeddedSceneInterface had to be changed to differentiate between mouse and scroll events (while up to now, scroll events are handled as mouse events), but for me this seemed necessary to fix this issue properly. As a result, JFXPanel had to be adjusted as well to comply to the changes in the EmbeddedSceneInterface, while its behavior should not have changed. > > As horizontal mouse events cannot be synthesized via Display.post(Event) yet (an open issue for SWT), I did not add an automated test, but instead added a manual one (FXCanvasMouseWheelEventsTest). Therefore, this patch does not depend on the patch I provided earlier for JDK-8160325. > > Best Regards, > Alexander > > > > From kevin.rushforth at oracle.com Mon Aug 15 17:26:44 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Aug 2016 10:26:44 -0700 Subject: [PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene In-Reply-To: <2F35F2DC-CFB9-4DBF-B5D7-0CC9DA80C2A5@nyssen.org> References: <39317253-63D5-4FD3-A0FE-D506D0830237@nyssen.org> <2F35F2DC-CFB9-4DBF-B5D7-0CC9DA80C2A5@nyssen.org> Message-ID: <57B1FB54.5000804@oracle.com> OK, I'll upload this revised version of the patch today. -- Kevin Alexander Nyssen wrote: > Hi Kevin, > > please consider the following updated patch instead, which contains an > additional null-check. > > Regards > Alexander > > > ------------------------------------------------------------------------ > > >> Am 12.08.2016 um 16:04 schrieb Alexander Nyssen > >: >> >> Hi Kevin, >> >> attached please find an initial patch for >> https://bugs.openjdk.java.net/browse/JDK-8161282. >> >> The patch is not as minimal as I had hoped, as the >> EmbeddedSceneInterface had to be changed to differentiate between >> mouse and scroll events (while up to now, scroll events are handled >> as mouse events), but for me this seemed necessary to fix this issue >> properly. As a result, JFXPanel had to be adjusted as well to comply >> to the changes in the EmbeddedSceneInterface, while its behavior >> should not have changed. >> >> As horizontal mouse events cannot be synthesized via >> Display.post(Event) yet (an open issue for SWT), I did not add an >> automated test, but instead added a manual one >> (FXCanvasMouseWheelEventsTest). Therefore, this patch does not depend >> on the patch I provided earlier for JDK-8160325. >> >> Best Regards, >> Alexander >> >> >> >> > > = From kevin.rushforth at oracle.com Mon Aug 15 22:45:47 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Aug 2016 15:45:47 -0700 Subject: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene. In-Reply-To: <1DF1D32C-A194-4BC8-8AAD-A4BA640D87C4@nyssen.org> References: <8f6f91a9-0ea9-1769-d22d-ca3e19b8c5b7@oracle.com> <579A231B.8030009@oracle.com> <9C6E80F0-6826-43A5-8483-3C570B932D10@nyssen.org> <579A2CD5.5020600@oracle.com> <57A92D97.6000302@oracle.com> <4764FA63-8ED6-481E-9B63-DC919B85A02B@nyssen.org> <57ACF593.3060205@oracle.com> <1DF1D32C-A194-4BC8-8AAD-A4BA640D87C4@nyssen.org> Message-ID: <57B2461B.2010905@oracle.com> The 2016-08-12 revision looks fine to me, except for a missing space as noted in JBS (no need for a new patch if that is the only issue found). While we wait for approval from the JDK 9 release team, we need another reviewer for this. Alexander Z: can you take a look? -- Kevin Alexander Nyssen wrote: > Hi Kevin, > > attached please find a revised patch that contains the corrections you > requested. The patch is now applicable to the new module structure > (modues with 'javafx.' prefix). > > Regards, > Alexander > > > ------------------------------------------------------------------------ > > >> Am 12.08.2016 um 00:00 schrieb Kevin Rushforth >> >: >> >> >> >> Alexander Nyssen wrote: >>> Hi Kevin, >>> >>> thanks for your feedback. Please fin my comments inline. >>> >>> >>>> Am 09.08.2016 um 03:10 schrieb Kevin Rushforth : >>>> >>>> I uploaded the patch, reviewed it, and provided comments in the bug report. The short version is: >>>> >>>> * The new API looks good >>>> >>>> * There is a missing '@since 9' in the javadoc comments along with a few typos / style issues >>>> >>> I will take care of it. Is there a style guide? >>> >> >> Not a current one. The ones I pointed out in the JBS issue were >> either grammatical or capitalization (other than the '@since' which >> is required for all new API). >> >>>> * Rather than using reflection and setAccessible in the implementation, please add a public getHostContainer method to EmbeddedWindow (since it is an internal method, there is no concern with doing that -- it isn't API). >>>> >>> Such a getHost() method was already introduced to EmbeddedWindow as part of the patch (to obtain the HostContainer from it). The reflection code within getFXCanvas() is used to access the enclosing instance (i.e. the FXCanvas) of the HostContainer. We could only circumvent this by introducing a constructor to HostContainer and by passing in the enclosing FXCanvas instance explicitly (so we can query it via an explicit getter, which would have to be introduced in addition). Would you prefer that? >>> >> >> Ah, I see what you are doing now. There is an easier way, then. Just >> add a default (package) scope 'fxCanvas' variable in the inner class >> initialized to 'FXCanvas.this' and you will be able to access it >> directly, since an instance of an inner class can always get access >> to the instance of the enclosing class. >> >> private class HostContainer implements HostInterface { >> final FXCanvas fxCanvas = FXCanvas.this; >> ... >> >> I updated the bug report with this and the other style issues. I >> haven't tested it yet, but other than the listed issues it looks very >> close to being done. >> >> -- Kevin >> >> >>> >>>> Additionally, I requested JDK 9 release team approval for this. The approval process can proceed in parallel with your addressing the issues I raised. >>>> >>>> ? Kevin >>>> >>> Regards, >>> Alexander >>> >>> >>>> Alexander Nyssen wrote: >>>> >>>>> Hi Kevin, >>>>> >>>>> attached please find a revised patch. My comments are inlined. >>>>> >>>>> >>>>>> Am 28.07.2016 um 18:03 schrieb Kevin Rushforth >: >>>>>> >>>>>> Hi >>>>>> >>>>>> Alexander Nyssen wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have added my comments below: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 28.07.2016 um 17:22 schrieb Kevin Rushforth >: >>>>>>>> >>>>>>>> I got the attachment, since Alexander also CCed me directly. I will attach it shortly. >>>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>> Done. >>>>>> >>>>>> >>>>>>>> I do have two comments on this: >>>>>>>> >>>>>>>> 1) We are past Feature Freeze, so all Enhancements need formal JDK 9 R-team approval [1][2]. In this case, the justification can be internal API that is no longer accessible in JDK 9 due to Jigsaw (I would be very reluctant to consider any other Enhancement request this late in the process), but I will need to look at it and then take it through the approval process, provided that I feel it is in scope. >>>>>>>> >>>>>>> I was not aware about this, but I would of course appreciate if it could be included (due to Jigsaw). Thanks for considering it at least. >>>>>>> >>>>>> I'll take a closer look tomorrow or Monday (no more time today). At first glance it seems like something reasonable to take forward. >>>>>> >>>>> That sounds promising. Thanks! >>>>> >>>>> >>>>>>>> 2) Some of the changes you list seem unrelated to this enhancement and are better done as separate issues (e.g., the rework of the SWTCursorsTest). Also, I am unconvinced of the need to force GTK 2; in fact it seems at odds with the work we have done with JEP 283 [3]. >>>>>>>> >>>>>>> Well, the test case refactoring is somehow related, as I introduced the common SWT rule while introducing the second SWT test. However, I could provide it as a separate contribution if that was wished (and a JIRA issue was provided), but the rest of this contribution of course requires it as a prerequisite. If this enhancement could not be included in JDK 9, I would have to provide it as a separate contribution, as I would have to re-introduce FXCanvasTest in other succeeding bugfix contributions (JDK-8143596, JDK-8143596). >>>>>>> >>>>>> I see. I did take a quick look at this and the test changes seem fine as part of this. I see you created the new test with 'hg cp' (or similar) which records it as a copy of the SWTCursorsTest.java file, which given the number of changes is not needed (and not really useful), but that's easy to fix. >>>>>> >>>>> Done (I copied it within IntelliJ and the IDE seems to have applied hg copy). >>>>> >>>>> >>>>>> There are several white space changes in FXCanvas.java that should be reverted. Our policy is that we do not make unrelated changes, including white space changes, in portions of a file that aren't otherwise modified by a patch. >>>>>> >>>>> Done (I used the IntelliJ formatter). >>>>> >>>>>>> The GTK2 flag I introduced just affects SWT. As the swt library that is bundled is rather old (3.7.2) that seemed to be safer (we have observed quite a few problems when running SWT on GTK3). We can of course remove it if tests are not affected by it. >>>>>>> >>>>>> We don't actually bundle swt itself, although we do download an old copy to link against, and to run tests against. In any case, given that our minimum Linux platform for JDK 9 is Ubuntu 16.04, it might not have GTK2 installed by default. Please revert this change to build.gradle. If test issues arise on Linux we will deal with it at that time (possibly by moving to a newer version of swt to run tests). >>>>>> >>>>> I removed the SWT option. However, the previous logger message is no longer valid and should be removed, so the patch still contains a change to build.gradle. >>>>> >>>>> >>>>>> Thanks. >>>>>> >>>>>> ? Kevin >>>>>> >>>>> Regards, >>>>> Alexander >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>>> >>>>>>>> ? Kevin >>>>>>>> >>>>>>> Regards, >>>>>>> Alexander >>>>>>> >>>>>>> >>>>>>>> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004485.html >>>>>>>> [2] http://openjdk.java.net/projects/jdk9/fc-extension-process >>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8145568 >>>>>>>> >>>>>>>> >>>>>>>> Phil Race wrote: >>>>>>>> >>>>>>>>> The mailing list rejects attachments so we got nothing. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 7/28/2016 8:06 AM, Alexander Nyssen wrote: >>>>>>>>> >>>>>>>>>> Hi Kevin, all, >>>>>>>>>> >>>>>>>>>> attached please find a patch that fixes JDK-8160325. The patch comprises the following changes: >>>>>>>>>> >>>>>>>>>> - Provided static FXCanvas#getFXCanvas(Scene) method to obtain the FXCanvas instance embedding the given Scene instance. >>>>>>>>>> - Added EmbeddedWindow.getHost() so the HostInterface can be retrieved. >>>>>>>>>> - Added FXCanvasTest with a test method to test correct behavior of FXCanvas#getFXCanvas(Scene). >>>>>>>>>> - Introduced SwtTest JUnit MethodRule to have more concise tests and ensure it is also used by SWTCursorsTest. >>>>>>>>>> - Ensured SWT tests are executed using GTK2 on Linux. >>>>>>>>>> >>>>>>>>>> I reworked the existing SWTCursorsTest while introducing FXCanvasTest to be more concise. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Alexander >>>>>>>>>> >>>>>>>>>> >>> > > = From chien.yang at oracle.com Tue Aug 16 00:00:09 2016 From: chien.yang at oracle.com (Chien Yang) Date: Mon, 15 Aug 2016 17:00:09 -0700 Subject: [9] Code Review Request For 8130675:Document that setting scene on stage changes stage size unless explicitly set Message-ID: <57B25789.3050709@oracle.com> Hi Kevin, Please review this proposed doc fix: JIRA:https://bugs.openjdk.java.net/browse/JDK-8130675 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8130675/webrev.00/ Thanks, - Chien From alexander at nyssen.org Tue Aug 16 06:55:11 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Tue, 16 Aug 2016 08:55:11 +0200 Subject: Marking synthesized scroll events as such. Message-ID: <338FEA67-2DE4-40F5-B673-7C3BE100540B@nyssen.org> Hi all, as I am currently working on FXCanvas, there is one aspect I would like to discuss, which is closely related to JDK-8161282 (FXCanvas does not forward horizontal mouse scroll events to the embedded scene) and JDK-8143596 (FXCanvas does not forward touch gestures to embedded scene), namely handling of synthesized scroll events. That is, SWT synthesizes mouse wheel scroll events from PAN gesture events, and these are forwarded to the embedded scene (the patch I provided for JDK-8161282 does not change this behavior, it simply ensures horizontal and vertical mouse wheel events are processed equally) while not being marked as synthesized (unlike MouseEvent, ScrollEvent does not provide a ?synthesized? flag). JavaFX natively seems to do likewise with SWIPE events, which seem to yield synthesized scroll events as well. Wouldn?t it be appropriate to introduce a synthesized flag and mark such kind of events as being synthesized? Within the Eclipse GEF?s FXCanvasEx we have sorted out scroll events synthesized form PAN events completely (and any client code may do likewise without accessing internal API, so this is no JIGSAW related issue), but I think it in general be nice if client code could properly decide, whether it wants to deal with these events or rather handle the native gesture events instead (as soon as JDK-8143596 is resolved this would even be possible in an SWT-integrated scenario). I would raise an issue via webbug for this, if my thoughts are shared. Regards, Alexander From alexander at nyssen.org Tue Aug 16 07:24:04 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Tue, 16 Aug 2016 09:24:04 +0200 Subject: [PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene In-Reply-To: <57B1FB54.5000804@oracle.com> References: <39317253-63D5-4FD3-A0FE-D506D0830237@nyssen.org> <2F35F2DC-CFB9-4DBF-B5D7-0CC9DA80C2A5@nyssen.org> <57B1FB54.5000804@oracle.com> Message-ID: You might even take the one I attached. I just recognized I still had some unused imports in the manual test case (I am still not familiar with IntelliJ). Regards, Alexander > Am 15.08.2016 um 19:26 schrieb Kevin Rushforth : > > OK, I'll upload this revised version of the patch today. > > -- Kevin > > > Alexander Nyssen wrote: >> >> Hi Kevin, >> >> please consider the following updated patch instead, which contains an additional null-check. >> >> Regards >> Alexander >> >> >> >> >>> Am 12.08.2016 um 16:04 schrieb Alexander Nyssen >: >>> >>> Hi Kevin, >>> >>> attached please find an initial patch for https://bugs.openjdk.java.net/browse/JDK-8161282 . >>> >>> The patch is not as minimal as I had hoped, as the EmbeddedSceneInterface had to be changed to differentiate between mouse and scroll events (while up to now, scroll events are handled as mouse events), but for me this seemed necessary to fix this issue properly. As a result, JFXPanel had to be adjusted as well to comply to the changes in the EmbeddedSceneInterface, while its behavior should not have changed. >>> >>> As horizontal mouse events cannot be synthesized via Display.post(Event) yet (an open issue for SWT), I did not add an automated test, but instead added a manual one (FXCanvasMouseWheelEventsTest). Therefore, this patch does not depend on the patch I provided earlier for JDK-8160325. >>> >>> Best Regards, >>> Alexander >>> >>> >>> >>> >> >> = From daniel.gloeckner at 360t.com Tue Aug 16 07:52:16 2016 From: daniel.gloeckner at 360t.com (=?iso-8859-1?Q?Daniel_Gl=F6ckner?=) Date: Tue, 16 Aug 2016 07:52:16 +0000 Subject: Structuring CSS Stylesheets In-Reply-To: <57B1E793.1080808@oracle.com> References: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C057A@EOFFICE-EX01.360t.com> <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C1617@EOFFICE-EX01.360t.com> <46bedd2a-bb5b-a5ba-31b4-b2696c524d4a@oracle.com> <57B1E793.1080808@oracle.com> Message-ID: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5C183E@EOFFICE-EX01.360t.com> Hi, > -----Original Message----- > From: Kevin Rushforth [mailto:kevin.rushforth at oracle.com] > Sent: Monday, August 15, 2016 6:02 PM > To: David Grieve > Cc: Daniel Gl?ckner; openjfx-dev at openjdk.java.net > Subject: Re: Structuring CSS Stylesheets > > One slight correction on how to contribute below. > > > David Grieve wrote: > > > > > > On 8/15/16 10:52 AM, Daniel Gl?ckner wrote: > >>>> We found the culprits by patching the JRE, adding some statistics > >>>> to SimpleSelector and CompoundSelector. I was wondering whether > >>>> there are easier ways but anyway, it works ;) > >>> This sounds like some code that would be good to share with the > >>> community. :) > >> [DG] Sure thing. It's not too complicated and doesn't use external > >> libs. Any hint where I could post it / paste it? > > See https://wiki.openjdk.java.net/display/OpenJFX/Community for how to > > contribute > > That page is just a placeholder, and finding what you need in the sub-pages a > bit tricky. See the following page for how to contribute: > > http://openjdk.java.net/contribute/ > > -- Kevin > > > >> need them, for example our UI component factory would add table.css > >> to a TableView's list of stylesheets (tv. > >> getStylesheets().add("/path/to/table.css"). > >> The global theme.css would be minimal and only define colors and fonts. > >>>> What do you think about this approach? Will this work nicely with > >>>> caching of > >>> CSS styles in JavaFX? > >>> I think if you are going to go this route, you might want to use > >>> Region#getUserAgentStylesheets() which adds the styles as user-agent > >>> styles. > >>> But I don't think it will buy you much in terms of CSS performance. > >> [DG] We also want to control / override the CSS of standard JavaFX > >> controls like TreeTableView. Ideally we don't need to sub class them > >> so we would need to use parent. getStylesheets().add(), right? > > I doubt that getUserAgentStylesheets() or getStylesheets() is going to > > have much impact. My guess is that having the stylesheets added to the > > scene is going to be your best bet. I say this because the code that > > does the style matching has to combine styles together from > > Region#getUserAgentStylesheets() and Parent#getStylesheets(), whereas > > the styles from scene stylesheets are already combined. You have to > > think of these different sources of styles as sets of styles. When you > > have Region or Parent stylesheets, you have to create a union of those > > styles with the default user-agent stylesheets (e.g., caspian.css). > > With just scene stylesheets, you have just one set (this isn't 100% > > accurate, but close enough for this discussion). OK. So if we're talking about performance it might be a good idea to add the CSS to the scene and make sure that all CSS selectors are efficient. > > > >>> If you the biggest bang for your buck relative to JavaFX CSS > >>> performance, avoid style lookup and relative font sizes. > >> [DG] Could you explain what you mean by "avoid style lookups"? > > You know about styles like '-fx-base' used in caspian.css. You change > > the color for -fx-base and the basic colors of the UI change. This > > magic happens at runtime. So if I have a label in a cell in a table, > > and it has a style "-fx-border-color: -fx-base", JavaFX will - at > > runtime - try to resolve -fx-base into an actual color. It starts at > > the leaf and looks tries to resolve -fx-base. If it can't resolve it, > > it looks for a style in the parent node, and so on up the parent-chain > > all the way to the root node. The worst case scenario, then, is that > > there are no styles that resolve the value until you get to .root. > > > > This is what I mean by 'style lookups'. > > > > Its great stuff (the brainchild of Jasper Potts) because I can change > > the look of my UI just by setting '-fx-base'. But if I were developing > > a UI and I didn't care to let the users of my UI make such changes, > > I'd go through and remove all the lookups in caspian.css (not trivial > > because there are many many lookups - not just -fx-base). Or use a > > pre-processor such as SASS or LESS. > > > > The same sort of lookup happens when you have an em (or other relative > > size) because you need a font or a font-size to complete the > > calculation. In most cases, the lookup for a font or font-size goes > > all the way to .root, where it fails and falls back on > > Font.getDefault(). But its a trade off since em sizes let your UI more > > easily scale to different displays. > > Thanks a lot for the in-depth explanation. We're using a lot of style lookups in our CSS, mostly to define colors similar to -fx-base in your example. We will look at using a preprocessor as you suggested. This was anyway on our TODO list to be able to support user specific font sizes. From alexander at nyssen.org Tue Aug 16 11:36:30 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Tue, 16 Aug 2016 13:36:30 +0200 Subject: Marking synthesized scroll events as such. In-Reply-To: <338FEA67-2DE4-40F5-B673-7C3BE100540B@nyssen.org> References: <338FEA67-2DE4-40F5-B673-7C3BE100540B@nyssen.org> Message-ID: <307A4A90-D13D-4103-AEA6-8A6C6764F39B@nyssen.org> Having started to work on JDK-8143596 today, I have to provide an update on this: those PAN gesture events that are emulated by SWT should indeed be ignored by FXCanvas (as done by our FXCanvasEX implementation), because: a) SCROLL gestures (START, SCROLL, FINISH) may otherwise not be properly recognized by JavaFX code (because they are always ?disturbed? by intermediate synthesized mouse scroll events). b) JavaFX does not emulate such events, so forwarding would result in a different behavior in case of the SWT integration (compared to JavaFX native). Regards, Alexander > Am 16.08.2016 um 08:55 schrieb Alexander Nyssen : > > Hi all, > > as I am currently working on FXCanvas, there is one aspect I would like to discuss, which is closely related to JDK-8161282 (FXCanvas does not forward horizontal mouse scroll events to the embedded scene) and JDK-8143596 (FXCanvas does not forward touch gestures to embedded scene), namely handling of synthesized scroll events. That is, SWT synthesizes mouse wheel scroll events from PAN gesture events, and these are forwarded to the embedded scene (the patch I provided for JDK-8161282 does not change this behavior, it simply ensures horizontal and vertical mouse wheel events are processed equally) while not being marked as synthesized (unlike MouseEvent, ScrollEvent does not provide a ?synthesized? flag). JavaFX natively seems to do likewise with SWIPE events, which seem to yield synthesized scroll events as well. > > Wouldn?t it be appropriate to introduce a synthesized flag and mark such kind of events as being synthesized? Within the Eclipse GEF?s FXCanvasEx we have sorted out scroll events synthesized form PAN events completely (and any client code may do likewise without accessing internal API, so this is no JIGSAW related issue), but I think it in general be nice if client code could properly decide, whether it wants to deal with these events or rather handle the native gesture events instead (as soon as JDK-8143596 is resolved this would even be possible in an SWT-integrated scenario). > > I would raise an issue via webbug for this, if my thoughts are shared. > > Regards, > Alexander > > From alexander.zvegintsev at oracle.com Tue Aug 16 12:24:06 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 16 Aug 2016 15:24:06 +0300 Subject: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene. In-Reply-To: <57B2461B.2010905@oracle.com> References: <8f6f91a9-0ea9-1769-d22d-ca3e19b8c5b7@oracle.com> <579A231B.8030009@oracle.com> <9C6E80F0-6826-43A5-8483-3C570B932D10@nyssen.org> <579A2CD5.5020600@oracle.com> <57A92D97.6000302@oracle.com> <4764FA63-8ED6-481E-9B63-DC919B85A02B@nyssen.org> <57ACF593.3060205@oracle.com> <1DF1D32C-A194-4BC8-8AAD-A4BA640D87C4@nyssen.org> <57B2461B.2010905@oracle.com> Message-ID: <7ffb2aa3-16f2-e096-54f5-9576b5e48f28@oracle.com> Looks fine to me too. On 8/16/16 1:45 AM, Kevin Rushforth wrote: > The 2016-08-12 revision looks fine to me, except for a missing space > as noted in JBS (no need for a new patch if that is the only issue found). > > While we wait for approval from the JDK 9 release team, we need > another reviewer for this. > > Alexander Z: can you take a look? > > -- Kevin > > > Alexander Nyssen wrote: >> Hi Kevin, >> >> attached please find a revised patch that contains the corrections >> you requested. The patch is now applicable to the new module >> structure (modues with 'javafx.' prefix). >> >> Regards, >> Alexander >> >> >> ------------------------------------------------------------------------ >> >> >>> Am 12.08.2016 um 00:00 schrieb Kevin Rushforth >>> >: >>> >>> >>> >>> Alexander Nyssen wrote: >>>> Hi Kevin, >>>> >>>> thanks for your feedback. Please fin my comments inline. >>>> >>>> >>>>> Am 09.08.2016 um 03:10 schrieb Kevin Rushforth: >>>>> >>>>> I uploaded the patch, reviewed it, and provided comments in the bug report. The short version is: >>>>> >>>>> * The new API looks good >>>>> >>>>> * There is a missing '@since 9' in the javadoc comments along with a few typos / style issues >>>>> >>>> I will take care of it. Is there a style guide? >>>> >>> >>> Not a current one. The ones I pointed out in the JBS issue were >>> either grammatical or capitalization (other than the '@since' which >>> is required for all new API). >>> >>>>> * Rather than using reflection and setAccessible in the implementation, please add a public getHostContainer method to EmbeddedWindow (since it is an internal method, there is no concern with doing that -- it isn't API). >>>>> >>>> Such a getHost() method was already introduced to EmbeddedWindow as part of the patch (to obtain the HostContainer from it). The reflection code within getFXCanvas() is used to access the enclosing instance (i.e. the FXCanvas) of the HostContainer. We could only circumvent this by introducing a constructor to HostContainer and by passing in the enclosing FXCanvas instance explicitly (so we can query it via an explicit getter, which would have to be introduced in addition). Would you prefer that? >>>> >>> >>> Ah, I see what you are doing now. There is an easier way, then. Just >>> add a default (package) scope 'fxCanvas' variable in the inner class >>> initialized to 'FXCanvas.this' and you will be able to access it >>> directly, since an instance of an inner class can always get access >>> to the instance of the enclosing class. >>> >>> private class HostContainer implements HostInterface { >>> final FXCanvas fxCanvas = FXCanvas.this; >>> ... >>> >>> I updated the bug report with this and the other style issues. I >>> haven't tested it yet, but other than the listed issues it looks >>> very close to being done. >>> >>> -- Kevin >>> >>> >>>> >>>>> Additionally, I requested JDK 9 release team approval for this. The approval process can proceed in parallel with your addressing the issues I raised. >>>>> >>>>> ? Kevin >>>>> >>>> Regards, >>>> Alexander >>>> >>>> >>>>> Alexander Nyssen wrote: >>>>> >>>>>> Hi Kevin, >>>>>> >>>>>> attached please find a revised patch. My comments are inlined. >>>>>> >>>>>> >>>>>>> Am 28.07.2016 um 18:03 schrieb Kevin Rushforth >: >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>> Alexander Nyssen wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have added my comments below: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Am 28.07.2016 um 17:22 schrieb Kevin Rushforth >: >>>>>>>>> >>>>>>>>> I got the attachment, since Alexander also CCed me directly. I will attach it shortly. >>>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>> Done. >>>>>>> >>>>>>> >>>>>>>>> I do have two comments on this: >>>>>>>>> >>>>>>>>> 1) We are past Feature Freeze, so all Enhancements need formal JDK 9 R-team approval [1][2]. In this case, the justification can be internal API that is no longer accessible in JDK 9 due to Jigsaw (I would be very reluctant to consider any other Enhancement request this late in the process), but I will need to look at it and then take it through the approval process, provided that I feel it is in scope. >>>>>>>>> >>>>>>>> I was not aware about this, but I would of course appreciate if it could be included (due to Jigsaw). Thanks for considering it at least. >>>>>>>> >>>>>>> I'll take a closer look tomorrow or Monday (no more time today). At first glance it seems like something reasonable to take forward. >>>>>>> >>>>>> That sounds promising. Thanks! >>>>>> >>>>>> >>>>>>>>> 2) Some of the changes you list seem unrelated to this enhancement and are better done as separate issues (e.g., the rework of the SWTCursorsTest). Also, I am unconvinced of the need to force GTK 2; in fact it seems at odds with the work we have done with JEP 283 [3]. >>>>>>>>> >>>>>>>> Well, the test case refactoring is somehow related, as I introduced the common SWT rule while introducing the second SWT test. However, I could provide it as a separate contribution if that was wished (and a JIRA issue was provided), but the rest of this contribution of course requires it as a prerequisite. If this enhancement could not be included in JDK 9, I would have to provide it as a separate contribution, as I would have to re-introduce FXCanvasTest in other succeeding bugfix contributions (JDK-8143596, JDK-8143596). >>>>>>>> >>>>>>> I see. I did take a quick look at this and the test changes seem fine as part of this. I see you created the new test with 'hg cp' (or similar) which records it as a copy of the SWTCursorsTest.java file, which given the number of changes is not needed (and not really useful), but that's easy to fix. >>>>>>> >>>>>> Done (I copied it within IntelliJ and the IDE seems to have applied hg copy). >>>>>> >>>>>> >>>>>>> There are several white space changes in FXCanvas.java that should be reverted. Our policy is that we do not make unrelated changes, including white space changes, in portions of a file that aren't otherwise modified by a patch. >>>>>>> >>>>>> Done (I used the IntelliJ formatter). >>>>>> >>>>>>>> The GTK2 flag I introduced just affects SWT. As the swt library that is bundled is rather old (3.7.2) that seemed to be safer (we have observed quite a few problems when running SWT on GTK3). We can of course remove it if tests are not affected by it. >>>>>>>> >>>>>>> We don't actually bundle swt itself, although we do download an old copy to link against, and to run tests against. In any case, given that our minimum Linux platform for JDK 9 is Ubuntu 16.04, it might not have GTK2 installed by default. Please revert this change to build.gradle. If test issues arise on Linux we will deal with it at that time (possibly by moving to a newer version of swt to run tests). >>>>>>> >>>>>> I removed the SWT option. However, the previous logger message is no longer valid and should be removed, so the patch still contains a change to build.gradle. >>>>>> >>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> ? Kevin >>>>>>> >>>>>> Regards, >>>>>> Alexander >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>>> ? Kevin >>>>>>>>> >>>>>>>> Regards, >>>>>>>> Alexander >>>>>>>> >>>>>>>> >>>>>>>>> [1]http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004485.html >>>>>>>>> [2]http://openjdk.java.net/projects/jdk9/fc-extension-process >>>>>>>>> [3]https://bugs.openjdk.java.net/browse/JDK-8145568 >>>>>>>>> >>>>>>>>> >>>>>>>>> Phil Race wrote: >>>>>>>>> >>>>>>>>>> The mailing list rejects attachments so we got nothing. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 7/28/2016 8:06 AM, Alexander Nyssen wrote: >>>>>>>>>> >>>>>>>>>>> Hi Kevin, all, >>>>>>>>>>> >>>>>>>>>>> attached please find a patch that fixes JDK-8160325. The patch comprises the following changes: >>>>>>>>>>> >>>>>>>>>>> - Provided static FXCanvas#getFXCanvas(Scene) method to obtain the FXCanvas instance embedding the given Scene instance. >>>>>>>>>>> - Added EmbeddedWindow.getHost() so the HostInterface can be retrieved. >>>>>>>>>>> - Added FXCanvasTest with a test method to test correct behavior of FXCanvas#getFXCanvas(Scene). >>>>>>>>>>> - Introduced SwtTest JUnit MethodRule to have more concise tests and ensure it is also used by SWTCursorsTest. >>>>>>>>>>> - Ensured SWT tests are executed using GTK2 on Linux. >>>>>>>>>>> >>>>>>>>>>> I reworked the existing SWTCursorsTest while introducing FXCanvasTest to be more concise. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Alexander >>>>>>>>>>> >>>>>>>>>>> >>>> >> >> = -- Thanks, Alexander. From alexander.zvegintsev at oracle.com Tue Aug 16 12:37:58 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 16 Aug 2016 15:37:58 +0300 Subject: [PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene In-Reply-To: References: <39317253-63D5-4FD3-A0FE-D506D0830237@nyssen.org> <2F35F2DC-CFB9-4DBF-B5D7-0CC9DA80C2A5@nyssen.org> <57B1FB54.5000804@oracle.com> Message-ID: <27b04bd2-8e00-9c2a-1023-99d9177dab67@oracle.com> Hi Alexander, The fix looks good to me, except the wild card import change in FXCanvas.java(there is no need for a new patch, if it is the only issue found) On 8/16/16 10:24 AM, Alexander Nyssen wrote: > You might even take the one I attached. I just recognized I still had some unused imports in the manual test case (I am still not familiar with IntelliJ). > > Regards, > Alexander > > > >> Am 15.08.2016 um 19:26 schrieb Kevin Rushforth : >> >> OK, I'll upload this revised version of the patch today. >> >> -- Kevin >> >> >> Alexander Nyssen wrote: >>> Hi Kevin, >>> >>> please consider the following updated patch instead, which contains an additional null-check. >>> >>> Regards >>> Alexander >>> >>> >>> >>> >>>> Am 12.08.2016 um 16:04 schrieb Alexander Nyssen >: >>>> >>>> Hi Kevin, >>>> >>>> attached please find an initial patch for https://bugs.openjdk.java.net/browse/JDK-8161282 . >>>> >>>> The patch is not as minimal as I had hoped, as the EmbeddedSceneInterface had to be changed to differentiate between mouse and scroll events (while up to now, scroll events are handled as mouse events), but for me this seemed necessary to fix this issue properly. As a result, JFXPanel had to be adjusted as well to comply to the changes in the EmbeddedSceneInterface, while its behavior should not have changed. >>>> >>>> As horizontal mouse events cannot be synthesized via Display.post(Event) yet (an open issue for SWT), I did not add an automated test, but instead added a manual one (FXCanvasMouseWheelEventsTest). Therefore, this patch does not depend on the patch I provided earlier for JDK-8160325. >>>> >>>> Best Regards, >>>> Alexander >>>> >>>> >>>> >>>> >>> = -- Thanks, Alexander. From felix.bembrick at gmail.com Tue Aug 16 05:50:02 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 16 Aug 2016 15:50:02 +1000 Subject: Exception running FXMark with JavaFX 9 Message-ID: I am trying to port FXMark from Java 8 to Java 9 but encounter this exception: Caused by: java.lang.IllegalAccessError: class com.bembrick.fxmark.HUD (in unnamed module @0x59223fd5) cannot access class com.sun.javafx.perf.PerformanceTracker (in module javafx.graphics) because module javafx.graphics does not export com.sun.javafx.perf to unnamed module @0x59223fd5 How do I access PerformanceTracker in Java/JavaFX 9? Thanks, Felix From dalibor.topic at oracle.com Tue Aug 16 14:17:16 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 16 Aug 2016 16:17:16 +0200 Subject: Exception running FXMark with JavaFX 9 In-Reply-To: References: Message-ID: <20a1f27b-c0c2-ba71-20e9-cf01c7ccc3b4@oracle.com> On 16.08.2016 07:50, Felix Bembrick wrote: > How do I access PerformanceTracker in Java/JavaFX 9? Please see http://openjdk.java.net/jeps/261 cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From chien.yang at oracle.com Wed Aug 17 06:45:19 2016 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 16 Aug 2016 23:45:19 -0700 Subject: [9] Code Review Request For 8164141: [Javadoc] Replace references of Stage with Window in the Window class Message-ID: <57B407FF.5090506@oracle.com> Hi Kevin, Please review the proposed doc fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8164141 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8164141/webrev.00/ Thanks, - Chien From vadim.pakhnushev at oracle.com Wed Aug 17 12:08:08 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 17 Aug 2016 15:08:08 +0300 Subject: [9] Review request for 8164096: ListChangeListener on ReadOnlyListWrapper's getReadOnlyProperty() does not reset change Message-ID: <288c1a5e-8f17-bf4c-d993-93489d6f3fd3@oracle.com> Hi Chien, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8164096 http://cr.openjdk.java.net/~vadim/8164096/webrev.00/ Thanks, Vadim From felix.bembrick at gmail.com Wed Aug 17 07:50:02 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Wed, 17 Aug 2016 17:50:02 +1000 Subject: Exception running FXMark with JavaFX 9 In-Reply-To: References: Message-ID: OK, I have read the article and followed Rahman's advice (thanks!) and here are my VM args now: -Djavafx.animation.fullspeed=true -addmods ALL-DEFAULT,java.se.ee -XaddExports:javafx.graphics/com.sun.javafx.stage=ALL-UNNAMED -XaddExports:javafx.base/com.sun.javafx.collections=ALL-UNNAMED -XaddExports:javafx.base/com.sun.javafx.property=ALL-UNNAMED -XaddExports:javafx.base/com.sun.javafx=ALL-UNNAMED -XaddExports:javafx.base/com.sun.javafx.event=ALL-UNNAMED -XaddExports:javafx.base/com.sun.javafx.perf=ALL-UNNAMED But, when I run FXMark I now get this error: Error occurred during initialization of VM java.lang.IllegalArgumentException: package com.sun.javafx.perf not in contents at java.lang.reflect.Module.implAddExports(java.base at 9-ea/Module.java:591) at java.lang.reflect.Module.access$400(java.base at 9-ea/Module.java:86) at java.lang.reflect.Module$1.addExportsToAllUnnamed(java.base at 9-ea /Module.java:1109) at jdk.internal.module.Modules.addExportsToAllUnnamed(java.base at 9-ea /Modules.java:124) at jdk.internal.module.ModuleBootstrap.addExtraExports(java.base at 9-ea /ModuleBootstrap.java:476) at jdk.internal.module.ModuleBootstrap.boot(java.base at 9-ea /ModuleBootstrap.java:322) at java.lang.System.initPhase2(java.base at 9-ea/System.java:1930) Can anyone point out what I am doing wrong? Cheers, Felix On 17 August 2016 at 00:22, Rahman USTA wrote: > Dear Felix; > > I'm running AsciidocFX with the following JVM parameters. They can help > you. > > -Djava.awt.headless=false > -XaddExports:javafx.graphics/ > com.sun.javafx.stage=ALL-UNNAMED -addmods ALL-DEFAULT,java.se.ee > -XaddExports:javafx.base/com.sun.javafx.collections=ALL-UNNAMED > -XaddExports:javafx.base/com.sun.javafx.property=ALL-UNNAMED > -XaddExports:javafx.base/com.sun.javafx=ALL-UNNAMED > -XaddExports:javafx.base/com.sun.javafx.event=ALL-UNNAMED > -addmods javafx.deploy,ALL-SYSTEM > > I thought that the followings may help you > > -addmods ALL-DEFAULT,java.se.ee -XaddExports:javafx.base/com. > sun.javafx.perf=ALL-UNNAMED > > Thanks. > > 2016-08-16 8:50 GMT+03:00 Felix Bembrick : > >> I am trying to port FXMark from Java 8 to Java 9 but encounter this >> exception: >> >> Caused by: java.lang.IllegalAccessError: class com.bembrick.fxmark.HUD (in >> unnamed module @0x59223fd5) cannot access class >> com.sun.javafx.perf.PerformanceTracker (in module javafx.graphics) >> because >> module javafx.graphics does not export com.sun.javafx.perf to unnamed >> module @0x59223fd5 >> >> How do I access PerformanceTracker in Java/JavaFX 9? >> >> Thanks, >> >> Felix >> > > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta > From vadim.pakhnushev at oracle.com Wed Aug 17 12:45:03 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 17 Aug 2016 15:45:03 +0300 Subject: Exception running FXMark with JavaFX 9 In-Reply-To: References: Message-ID: <30a31733-4756-851d-e06b-9720b8ebb8cb@oracle.com> Felix, The com.sun.javafx.perf.PerformanceTracker is in the javafx.graphics module. Vadim On 17.08.2016 10:50, Felix Bembrick wrote: > OK, I have read the article and followed Rahman's advice (thanks!) and here > are my VM args now: > > -Djavafx.animation.fullspeed=true > -addmods ALL-DEFAULT,java.se.ee > -XaddExports:javafx.graphics/com.sun.javafx.stage=ALL-UNNAMED > -XaddExports:javafx.base/com.sun.javafx.collections=ALL-UNNAMED > -XaddExports:javafx.base/com.sun.javafx.property=ALL-UNNAMED > -XaddExports:javafx.base/com.sun.javafx=ALL-UNNAMED > -XaddExports:javafx.base/com.sun.javafx.event=ALL-UNNAMED > -XaddExports:javafx.base/com.sun.javafx.perf=ALL-UNNAMED > > But, when I run FXMark I now get this error: > > Error occurred during initialization of VM > java.lang.IllegalArgumentException: package com.sun.javafx.perf not in > contents > at java.lang.reflect.Module.implAddExports(java.base at 9-ea/Module.java:591) > at java.lang.reflect.Module.access$400(java.base at 9-ea/Module.java:86) > at java.lang.reflect.Module$1.addExportsToAllUnnamed(java.base at 9-ea > /Module.java:1109) > at jdk.internal.module.Modules.addExportsToAllUnnamed(java.base at 9-ea > /Modules.java:124) > at jdk.internal.module.ModuleBootstrap.addExtraExports(java.base at 9-ea > /ModuleBootstrap.java:476) > at jdk.internal.module.ModuleBootstrap.boot(java.base at 9-ea > /ModuleBootstrap.java:322) > at java.lang.System.initPhase2(java.base at 9-ea/System.java:1930) > > Can anyone point out what I am doing wrong? > > Cheers, > > Felix > > > On 17 August 2016 at 00:22, Rahman USTA wrote: > >> Dear Felix; >> >> I'm running AsciidocFX with the following JVM parameters. They can help >> you. >> >> -Djava.awt.headless=false >> -XaddExports:javafx.graphics/ >> com.sun.javafx.stage=ALL-UNNAMED -addmods ALL-DEFAULT,java.se.ee >> -XaddExports:javafx.base/com.sun.javafx.collections=ALL-UNNAMED >> -XaddExports:javafx.base/com.sun.javafx.property=ALL-UNNAMED >> -XaddExports:javafx.base/com.sun.javafx=ALL-UNNAMED >> -XaddExports:javafx.base/com.sun.javafx.event=ALL-UNNAMED >> -addmods javafx.deploy,ALL-SYSTEM >> >> I thought that the followings may help you >> >> -addmods ALL-DEFAULT,java.se.ee -XaddExports:javafx.base/com. >> sun.javafx.perf=ALL-UNNAMED >> >> Thanks. >> >> 2016-08-16 8:50 GMT+03:00 Felix Bembrick : >> >>> I am trying to port FXMark from Java 8 to Java 9 but encounter this >>> exception: >>> >>> Caused by: java.lang.IllegalAccessError: class com.bembrick.fxmark.HUD (in >>> unnamed module @0x59223fd5) cannot access class >>> com.sun.javafx.perf.PerformanceTracker (in module javafx.graphics) >>> because >>> module javafx.graphics does not export com.sun.javafx.perf to unnamed >>> module @0x59223fd5 >>> >>> How do I access PerformanceTracker in Java/JavaFX 9? >>> >>> Thanks, >>> >>> Felix >>> >> >> >> -- >> Rahman USTA >> Istanbul JUG >> https://github.com/rahmanusta >> From felix.bembrick at gmail.com Wed Aug 17 13:24:53 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Wed, 17 Aug 2016 23:24:53 +1000 Subject: Exception running FXMark with JavaFX 9 In-Reply-To: <30a31733-4756-851d-e06b-9720b8ebb8cb@oracle.com> References: <30a31733-4756-851d-e06b-9720b8ebb8cb@oracle.com> Message-ID: <0A88CEE3-277A-411A-9607-F8D33562DFA8@gmail.com> Ah, thanks Vadim. That would certainly explain the exception! Cheers, Felix > On 17 Aug 2016, at 22:45, Vadim Pakhnushev wrote: > > Felix, > > The com.sun.javafx.perf.PerformanceTracker is in the javafx.graphics module. > > Vadim > >> On 17.08.2016 10:50, Felix Bembrick wrote: >> OK, I have read the article and followed Rahman's advice (thanks!) and here >> are my VM args now: >> >> -Djavafx.animation.fullspeed=true >> -addmods ALL-DEFAULT,java.se.ee >> -XaddExports:javafx.graphics/com.sun.javafx.stage=ALL-UNNAMED >> -XaddExports:javafx.base/com.sun.javafx.collections=ALL-UNNAMED >> -XaddExports:javafx.base/com.sun.javafx.property=ALL-UNNAMED >> -XaddExports:javafx.base/com.sun.javafx=ALL-UNNAMED >> -XaddExports:javafx.base/com.sun.javafx.event=ALL-UNNAMED >> -XaddExports:javafx.base/com.sun.javafx.perf=ALL-UNNAMED >> >> But, when I run FXMark I now get this error: >> >> Error occurred during initialization of VM >> java.lang.IllegalArgumentException: package com.sun.javafx.perf not in >> contents >> at java.lang.reflect.Module.implAddExports(java.base at 9-ea/Module.java:591) >> at java.lang.reflect.Module.access$400(java.base at 9-ea/Module.java:86) >> at java.lang.reflect.Module$1.addExportsToAllUnnamed(java.base at 9-ea >> /Module.java:1109) >> at jdk.internal.module.Modules.addExportsToAllUnnamed(java.base at 9-ea >> /Modules.java:124) >> at jdk.internal.module.ModuleBootstrap.addExtraExports(java.base at 9-ea >> /ModuleBootstrap.java:476) >> at jdk.internal.module.ModuleBootstrap.boot(java.base at 9-ea >> /ModuleBootstrap.java:322) >> at java.lang.System.initPhase2(java.base at 9-ea/System.java:1930) >> >> Can anyone point out what I am doing wrong? >> >> Cheers, >> >> Felix >> >> >>> On 17 August 2016 at 00:22, Rahman USTA wrote: >>> >>> Dear Felix; >>> >>> I'm running AsciidocFX with the following JVM parameters. They can help >>> you. >>> >>> -Djava.awt.headless=false >>> -XaddExports:javafx.graphics/ >>> com.sun.javafx.stage=ALL-UNNAMED -addmods ALL-DEFAULT,java.se.ee >>> -XaddExports:javafx.base/com.sun.javafx.collections=ALL-UNNAMED >>> -XaddExports:javafx.base/com.sun.javafx.property=ALL-UNNAMED >>> -XaddExports:javafx.base/com.sun.javafx=ALL-UNNAMED >>> -XaddExports:javafx.base/com.sun.javafx.event=ALL-UNNAMED >>> -addmods javafx.deploy,ALL-SYSTEM >>> >>> I thought that the followings may help you >>> >>> -addmods ALL-DEFAULT,java.se.ee -XaddExports:javafx.base/com. >>> sun.javafx.perf=ALL-UNNAMED >>> >>> Thanks. >>> >>> 2016-08-16 8:50 GMT+03:00 Felix Bembrick : >>> >>>> I am trying to port FXMark from Java 8 to Java 9 but encounter this >>>> exception: >>>> >>>> Caused by: java.lang.IllegalAccessError: class com.bembrick.fxmark.HUD (in >>>> unnamed module @0x59223fd5) cannot access class >>>> com.sun.javafx.perf.PerformanceTracker (in module javafx.graphics) >>>> because >>>> module javafx.graphics does not export com.sun.javafx.perf to unnamed >>>> module @0x59223fd5 >>>> >>>> How do I access PerformanceTracker in Java/JavaFX 9? >>>> >>>> Thanks, >>>> >>>> Felix >>> >>> >>> -- >>> Rahman USTA >>> Istanbul JUG >>> https://github.com/rahmanusta > From alexander at nyssen.org Wed Aug 17 15:26:53 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Wed, 17 Aug 2016 17:26:53 +0200 Subject: [PATCH] 8143596: FXCanvas does not forward touch gestures to embedded scene Message-ID: <45BD3796-EC35-4885-889E-6AFAAAD8CF89@nyssen.org> Hi all, Kevin, attached please find a patch for JDK-8143596 (FXCanvas does not forward touch gestures to embedded scene). The patch depends on the most recent patch I provided for JDK-8161282 (revision 15_08_16, which was already uploaded). I developed and tested it on MacOSX, as SWT does not support any gestures on Linux. I could not test it on Windows yet, but will try to do so tomorrow (I cannot use my virtual machine but need to get hold of a windows device with touch support). I have added a simple manual test but no automated test yet. Best Regards, Alexander From daniel.gloeckner at 360t.com Wed Aug 17 15:39:22 2016 From: daniel.gloeckner at 360t.com (=?iso-8859-1?Q?Daniel_Gl=F6ckner?=) Date: Wed, 17 Aug 2016 15:39:22 +0000 Subject: End-to-end performance tests for distributed JavaFX application Message-ID: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5CD2A4@eoffice-ex02.360t.com> Hi, We're looking at developing a performance benchmark suite for our distributed JavaFX application. We want end-to-end metrics which include rendering / event processing in the UI. Example 1) @T_0 server sends update to client, @T_1 client receives the update, @T_2 the update is rendered. Measure T_2 - T_0. Example 2) @T_0 user clicks on a button which triggers a remote action, @T_1 UI has performed the remote call, @T_2 the server has reacted to the call. Measure T_2 - T_0. We want to automate the performance tests so we would need some kind of test driver which would start the UI and "click buttons". Maybe TestFX (https://github.com/TestFX/TestFX), Automaton (https://github.com/renatoathaydes/Automaton) or JemmyFX (https://jemmy.java.net/JemmyFXGuide/jemmy-guide.html) would be a good candidate for this job (example 2). Also, we would need to detect when an update is rendered (example 1). Does anyone on this list have experience with such performance measurements? Any hints appreciated ;) Kind regards, Daniel From kevin.rushforth at oracle.com Wed Aug 17 20:23:15 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 Aug 2016 13:23:15 -0700 Subject: [PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene In-Reply-To: References: <39317253-63D5-4FD3-A0FE-D506D0830237@nyssen.org> <2F35F2DC-CFB9-4DBF-B5D7-0CC9DA80C2A5@nyssen.org> <57B1FB54.5000804@oracle.com> Message-ID: <57B4C7B3.4090004@oracle.com> Uploaded the new version. Alexander Zvegintsev will sponsor this patch, and I will review it. My one quick comment -- in addition to the wild-card imports which Alexander Z caught, and said he would take care of -- is that the format of the commit message is not quite right. See the following page for formatting rules on the changeset commit message: http://openjdk.java.net/guide/producingChangeset.html Thanks. -- Kevin Alexander Nyssen wrote: > You might even take the one I attached. I just recognized I still had > some unused imports in the manual test case (I am still not familiar > with IntelliJ). > > Regards, > Alexander > > > ------------------------------------------------------------------------ > > >> Am 15.08.2016 um 19:26 schrieb Kevin Rushforth >> >: >> >> OK, I'll upload this revised version of the patch today. >> >> -- Kevin >> >> >> Alexander Nyssen wrote: >>> Hi Kevin, >>> >>> please consider the following updated patch instead, which contains >>> an additional null-check. >>> >>> Regards >>> Alexander >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>>> Am 12.08.2016 um 16:04 schrieb Alexander Nyssen >>>> >: >>>> >>>> Hi Kevin, >>>> >>>> attached please find an initial patch >>>> for https://bugs.openjdk.java.net/browse/JDK-8161282. >>>> >>>> The patch is not as minimal as I had hoped, as the >>>> EmbeddedSceneInterface had to be changed to differentiate between >>>> mouse and scroll events (while up to now, scroll events are handled >>>> as mouse events), but for me this seemed necessary to fix this >>>> issue properly. As a result, JFXPanel had to be adjusted as well to >>>> comply to the changes in the EmbeddedSceneInterface, while its >>>> behavior should not have changed. >>>> >>>> As horizontal mouse events cannot be synthesized via >>>> Display.post(Event) yet (an open issue for SWT), I did not add an >>>> automated test, but instead added a manual one >>>> (FXCanvasMouseWheelEventsTest). Therefore, this patch does not >>>> depend on the patch I provided earlier for JDK-8160325. >>>> >>>> Best Regards, >>>> Alexander >>>> >>>> >>>> >>>> >>> >>> = > > = From kevin.rushforth at oracle.com Wed Aug 17 21:42:45 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 Aug 2016 14:42:45 -0700 Subject: [PATCH] 8143596: FXCanvas does not forward touch gestures to embedded scene In-Reply-To: <45BD3796-EC35-4885-889E-6AFAAAD8CF89@nyssen.org> References: <45BD3796-EC35-4885-889E-6AFAAAD8CF89@nyssen.org> Message-ID: <57B4DA55.4080402@oracle.com> I uploaded the patch. I also added a comment [1] to the bug report with a concern about updating the dependent SWT library. You can read the details in the bug report. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8143596?focusedCommentId=13989256&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13989256 Alexander Nyssen wrote: > Hi all, Kevin, > > attached please find a patch for JDK-8143596 > (FXCanvas does not > forward touch gestures to embedded scene). The patch depends on the > most recent patch I provided for JDK-8161282 (revision 15_08_16, which > was already uploaded). I developed and tested it on MacOSX, as SWT > does not support any gestures on Linux. I could not test it on Windows > yet, but will try to do so tomorrow (I cannot use my virtual machine > but need to get hold of a windows device with touch support). I have > added a simple manual test but no automated test yet. > > Best Regards, > Alexander > > = > ------------------------------------------------------------------------ > From james.graham at oracle.com Wed Aug 17 23:14:33 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 17 Aug 2016 16:14:33 -0700 Subject: [9] Review request for JDK-8160073: menu issues in case of two-display configuration Message-ID: JBS: https://bugs.openjdk.java.net/browse/JDK-8160073 webrev: http://cr.openjdk.java.net/~flar/JDK-8160073/webrev.00/ The details are in the comments in the bug report. To summarize: - send a notification when DPI changes to reevaluate scene.getXY() - correctly scale event screen coordinates for Mouse/Scroll/Gesture events (code is copied from Menu event code that was already doing it) ...jim From arunprasad.rajkumar at oracle.com Thu Aug 18 11:51:06 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Thu, 18 Aug 2016 17:21:06 +0530 Subject: [webkit] [9] Review request for 8164314: [WebView] Debug build is no longer working in OSX Message-ID: <20094D19-EF02-4A7E-80A5-BB75509743C1@oracle.com> Hello Kevin, Guru, Murali, Please review the simple debug build fix for OSX. JIRA: https://bugs.openjdk.java.net/browse/JDK-8164314 Webrev: http://cr.openjdk.java.net/~arajkumar/8164314/webrev.00 Regards, Arun From alexander at nyssen.org Thu Aug 18 14:22:19 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Thu, 18 Aug 2016 16:22:19 +0200 Subject: [PATCH] 8143596: FXCanvas does not forward touch gestures to embedded scene In-Reply-To: <57B4DA55.4080402@oracle.com> References: <45BD3796-EC35-4885-889E-6AFAAAD8CF89@nyssen.org> <57B4DA55.4080402@oracle.com> Message-ID: <331CE3EF-77EA-4A0B-893E-ECD4F9766BE1@nyssen.org> Hi Kevin, I think we can go for option 1) and can approach the manual test as you outlined in your second comment. Attached please find an updated patch, which no longer contains the SWT upgrade but instead provides a respective comment within the manual test. I have also updated the manual test to provide detailed test steps and expectations, which were still missing in the initial patch. I could get hold of a Windows PC with touch screen today and can confirm proper behavior there as well. Please note that while my patch contains handling of SWIPE events, I was not able to obtain any SWIPE events from SWT, neither on Windows 10 nor on MaxOS El Capitan, while PAN, ROTATE, and ZOOM events were properly delivered on both platforms (which is why I have excluded SWIPE from the manual test). I further noticed one difference of behavior on both platforms: while on MacOS SWT delivers inertia events for PAN, this is not the case on Windows (here, the gesture end event is always the last event that is delivered), but this is rather an SWT issue and cannot be handled by FXCanvas. Even while we go with option 1), upgrading the SWT library would not be a bad idea, as the version currently used (3.7.2) is from 2012. Maybe you could open a separate issue for it, which does not ?block? this issue but simply ?relates? to it? Best Regards, Alexander > Am 17.08.2016 um 23:42 schrieb Kevin Rushforth : > > I uploaded the patch. I also added a comment [1] to the bug report with a concern about updating the dependent SWT library. You can read the details in the bug report. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8143596?focusedCommentId=13989256&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13989256 > > > Alexander Nyssen wrote: >> Hi all, Kevin, >> >> attached please find a patch for JDK-8143596 (FXCanvas does not forward touch gestures to embedded scene). The patch depends on the most recent patch I provided for JDK-8161282 (revision 15_08_16, which was already uploaded). I developed and tested it on MacOSX, as SWT does not support any gestures on Linux. I could not test it on Windows yet, but will try to do so tomorrow (I cannot use my virtual machine but need to get hold of a windows device with touch support). I have added a simple manual test but no automated test yet. >> >> Best Regards, >> Alexander >> >> = >> ------------------------------------------------------------------------ >> From rahman.usta.88 at gmail.com Fri Aug 19 12:31:57 2016 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Fri, 19 Aug 2016 15:31:57 +0300 Subject: Deprecated JavaFX Internal APIs Message-ID: Hello; OpenJDK publishes JDK Internal APIs and Java 9 changes here https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool Is it possible to update this document with JavaFX row ? or is there any wiki for JavaFX like that? Thanks. -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From andrey.rusakov at oracle.com Fri Aug 19 14:27:07 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Fri, 19 Aug 2016 17:27:07 +0300 Subject: Review request: JDK-8164212 Message-ID: <9a4c9252-c697-04e1-0b4f-7ab5bfaf13a3@oracle.com> Hello, guys. I have another improvement for our test workspace, so please have a look at it. Fix is applicable for both 8/tests and 9/tests without change. Jira: https://bugs.openjdk.java.net/browse/JDK-8164212 Webrev, 9: http://cr.openjdk.java.net/~arusakov/8164212/webrev-9.00/ Webrev, 8: http://cr.openjdk.java.net/~arusakov/8164212/webrev-8.00/ Thanks in advance. From vadim.pakhnushev at oracle.com Fri Aug 19 14:36:25 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 19 Aug 2016 17:36:25 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <39cc3456-dc56-0998-b73c-6509d4264f72@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From arunprasad.rajkumar at oracle.com Fri Aug 19 17:10:45 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Fri, 19 Aug 2016 22:40:45 +0530 Subject: [webkit] [9] Review request for 8164495: [WebView] Backout changeset 653ce34aafba Message-ID: <7D0E4B32-FC2A-48E2-B70C-E9A50AEE9683@oracle.com> Hello Kevin, Guru, Murali, Please review the simple fix to revert the unintentional change. JIRA: https://bugs.openjdk.java.net/browse/JDK-8164495 Webrev: http://cr.openjdk.java.net/~arajkumar/8164495/webrev.00/ Regards, Arun From guru.hb at oracle.com Fri Aug 19 18:31:56 2016 From: guru.hb at oracle.com (Guru Hb) Date: Sat, 20 Aug 2016 00:01:56 +0530 Subject: [9][tests]Review request for 8164498 : Backout changeset c9f45449d053 which has wrong bug id and commit message Message-ID: Hi Kevin, Please review the change for (Backing out the changes done for JDK-8163084 with wrong bug ID and commit message). Webrev : http://cr.openjdk.java.net/~ghb/rbgangad/8164498/webrev.00/ JBS : https://bugs.openjdk.java.net/browse/JDK-8164498 Thanks, Guru From David.Hill at Oracle.com Mon Aug 22 13:22:45 2016 From: David.Hill at Oracle.com (David Hill) Date: Mon, 22 Aug 2016 09:22:45 -0400 Subject: HEADS UP and review for new gnu style java command line options Message-ID: <57BAFCA5.4040609@Oracle.com> HEADS UP: On Monday August 29th, after the Sanity testing period, I will be commiting a change that will require a JIGSAW_HOME that is build jdk-9+132 or later. That build is now available for download from the JDK9 EA site . This updated JDK9 uses new GNU style command line options for the JDK 9 additions, and the older versions will be retired in the coming weeks. The JavaFX build will fail with the older JDK9 builds that do not have the new options. The supported options are defined here , and in general are not going to impact most developers. Please download and reset your JIGSAW_HOME to point to jdk-9+132 (or later) now. A last note: We still require JDK9 ea build 109 as teh bootstrap JDK ( JDK_HOME/JAVA_HOME ) Kevin, please review: Update FX to use new gnu style java command line options Webrev: http://cr.openjdk.java.net/~ddhill/8163316.3 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From daniel.gloeckner at 360t.com Tue Aug 23 11:51:39 2016 From: daniel.gloeckner at 360t.com (=?iso-8859-1?Q?Daniel_Gl=F6ckner?=) Date: Tue, 23 Aug 2016 11:51:39 +0000 Subject: Playing a sound at regular intervals Message-ID: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5DB417@EOFFICE-EX01.360t.com> Hi, We're trying to play a notification sound at a regular interval (every 500ms) in a loop. It should sound like "bing.bing.bing." and not like "bing......bing..bing...bing" if you know what I mean ;) >From the JavaDoc we were guessing that an efficient way to do this would be to set cycle count to indefinite on the audio clip / on the media player and call play() once. Observations: - Cycle count doesn't work for mp3 files. No problem, just use WAV. - The playback does not happen at regular intervals. -> not usable in this scenario Our solution so far has been to have a scheduled executor which calls audioclip.play() every 500 ms. This creates a new thread every time (see stack trace below) and we don't like this approach. Are there any experts for NativeMediaPlayer on this mailing list? Kind regards, Daniel Daemon Thread [Thread-21] (Suspended) owns: NativeMediaAudioClipPlayer (id=1523) NativeMediaPlayer$EventQueueThread(Thread).init(ThreadGroup, Runnable, String, long, AccessControlContext) line: 365 NativeMediaPlayer$EventQueueThread(Thread).init(ThreadGroup, Runnable, String, long) line: 349 NativeMediaPlayer$EventQueueThread(Thread).() line: 445 NativeMediaPlayer$EventQueueThread.(NativeMediaPlayer) line: 386 GSTMediaPlayer(NativeMediaPlayer).(NativeMedia) line: 109 GSTMediaPlayer.(GSTMedia) line: 46 GSTMediaPlayer.(Locator) line: 62 GSTPlatform.createMediaPlayer(Locator) line: 121 PlatformManager.createMediaPlayer(Locator) line: 201 NativeMediaManager.getPlayer(Locator) line: 222 MediaManager.getPlayer(Locator) line: 104 NativeMediaAudioClipPlayer.play() line: 319 NativeMediaAudioClipPlayer.clipScheduler() line: 112 NativeMediaAudioClipPlayer.access$000() line: 47 NativeMediaAudioClipPlayer$Enthreaderator.lambda$static$4() line: 85 2056540299.run() line: not available Thread.run() line: 745 From rahman.usta.88 at gmail.com Tue Aug 23 13:40:07 2016 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Tue, 23 Aug 2016 16:40:07 +0300 Subject: NullPointerException in LabeledSkinBase Message-ID: Hello; I got this NullPointerException in my JavaFX application, but it is not reproducible. OS: Windows 7 Ver: Microsoft Windows [Version 6.1.7601] java version "1.8.0_101" Java(TM) SE Runtime Environment (build 1.8.0_101-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode) java.lang.NullPointerException at com.sun.javafx.text.PrismTextLayout.shape(PrismTextLayout.java:869) at com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1064) at com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:223) at com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:246) at com.sun.javafx.scene.control.skin.Utils.computeTextWidth(Utils.java:120) at com.sun.javafx.scene.control.skin.LabeledSkinBase.computeMinLabeledPartWidth(LabeledSkinBase.j ava:661) at com.sun.javafx.scene.control.skin.LabeledSkinBase.computeMinWidth(LabeledSkinBase.java:633) at javafx.scene.control.Control.computeMinWidth(Control.java:470) at javafx.scene.Parent.minWidth(Parent.java:943) at javafx.scene.layout.Region.minWidth(Region.java:1383) at javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1667) at javafx.scene.layout.HBox.getAreaWidths(HBox.java:455) at javafx.scene.layout.HBox.computeContentWidth(HBox.java:532) at javafx.scene.layout.HBox.computeMinWidth(HBox.java:402) at javafx.scene.Parent.minWidth(Parent.java:943) at javafx.scene.layout.Region.minWidth(Region.java:1383) at javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1667) at javafx.scene.layout.HBox.getAreaWidths(HBox.java:455) at javafx.scene.layout.HBox.computeContentWidth(HBox.java:532) at javafx.scene.layout.HBox.computeMinWidth(HBox.java:402) at javafx.scene.Parent.minWidth(Parent.java:943) at javafx.scene.layout.Region.minWidth(Region.java:1383) at javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1667) at javafx.scene.layout.BorderPane.getAreaWidth(BorderPane.java:609) at javafx.scene.layout.BorderPane.computeMinWidth(BorderPane.java:369) at javafx.scene.Parent.minWidth(Parent.java:943) at javafx.scene.layout.Region.minWidth(Region.java:1383) at javafx.scene.layout.BorderPane.layoutChildren(BorderPane.java:484) at javafx.scene.Parent.layout(Parent.java:1087) at javafx.scene.Parent.layout(Parent.java:1093) at javafx.scene.Scene.doLayoutPass(Scene.java:552) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2397) at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolkit.java:319) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:191) at java.lang.Thread.run(Thread.java:745) Thanks -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From david.dehaven at oracle.com Tue Aug 23 14:15:40 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 23 Aug 2016 07:15:40 -0700 Subject: Playing a sound at regular intervals In-Reply-To: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5DB417@EOFFICE-EX01.360t.com> References: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5DB417@EOFFICE-EX01.360t.com> Message-ID: > We're trying to play a notification sound at a regular interval (every 500ms) in a loop. > > It should sound like "bing.bing.bing." and not like "bing......bing..bing...bing" if you know what I mean ;) > > From the JavaDoc we were guessing that an efficient way to do this would be to set cycle count to indefinite on the audio clip / on the media player and call play() once. > > Observations: > - Cycle count doesn't work for mp3 files. No problem, just use WAV. > - The playback does not happen at regular intervals. -> not usable in this scenario > > Our solution so far has been to have a scheduled executor which calls audioclip.play() every 500 ms. This creates a new thread every time (see stack trace below) and we don't like this approach. For the moment this is a better solution, until we can get a few internal things fixed in AudioClip. In the current implementation there will always be at least one new thread created. There are bugs filed on this already, specifically: https://bugs.openjdk.java.net/browse/JDK-8090414 https://bugs.openjdk.java.net/browse/JDK-8087423 And possibly related: https://bugs.openjdk.java.net/browse/JDK-8088375 -DrD- From swpalmer at gmail.com Tue Aug 23 23:31:23 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 23 Aug 2016 19:31:23 -0400 Subject: Playing a sound at regular intervals In-Reply-To: References: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5DB417@EOFFICE-EX01.360t.com> Message-ID: <85457024-4BEB-4BDA-A7CE-4A8A5D1D7907@gmail.com> FYI... This issue is not visible to me https://bugs.openjdk.java.net/browse/JDK-8090414 Scott > On Aug 23, 2016, at 10:15 AM, David DeHaven wrote: > > >> We're trying to play a notification sound at a regular interval (every 500ms) in a loop. >> >> It should sound like "bing.bing.bing." and not like "bing......bing..bing...bing" if you know what I mean ;) >> >> From the JavaDoc we were guessing that an efficient way to do this would be to set cycle count to indefinite on the audio clip / on the media player and call play() once. >> >> Observations: >> - Cycle count doesn't work for mp3 files. No problem, just use WAV. >> - The playback does not happen at regular intervals. -> not usable in this scenario >> >> Our solution so far has been to have a scheduled executor which calls audioclip.play() every 500 ms. This creates a new thread every time (see stack trace below) and we don't like this approach. > > For the moment this is a better solution, until we can get a few internal things fixed in AudioClip. > > In the current implementation there will always be at least one new thread created. > > > There are bugs filed on this already, specifically: > https://bugs.openjdk.java.net/browse/JDK-8090414 > https://bugs.openjdk.java.net/browse/JDK-8087423 > > And possibly related: > https://bugs.openjdk.java.net/browse/JDK-8088375 > > -DrD- > From daniel.gloeckner at 360t.com Wed Aug 24 07:11:29 2016 From: daniel.gloeckner at 360t.com (=?iso-8859-1?Q?Daniel_Gl=F6ckner?=) Date: Wed, 24 Aug 2016 07:11:29 +0000 Subject: Playing a sound at regular intervals In-Reply-To: References: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5DB417@EOFFICE-EX01.360t.com> Message-ID: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5DD874@EOFFICE-EX01.360t.com> Hi, Thanks for the explanation. For now we'll use AudioInputStream / Clip from javax.sound.sampled which seems wo work nicely for WAV clips. That API also offers continuous playback but without strange delays ;) Kind regards, Daniel > -----Original Message----- > From: David DeHaven [mailto:david.dehaven at oracle.com] > Sent: Tuesday, August 23, 2016 4:16 PM > To: Daniel Gl?ckner > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Playing a sound at regular intervals > > > > We're trying to play a notification sound at a regular interval (every 500ms) > in a loop. > > > > It should sound like "bing.bing.bing." and not like "bing......bing..bing...bing" if > you know what I mean ;) > > > > From the JavaDoc we were guessing that an efficient way to do this would be > to set cycle count to indefinite on the audio clip / on the media player and call > play() once. > > > > Observations: > > - Cycle count doesn't work for mp3 files. No problem, just use WAV. > > - The playback does not happen at regular intervals. -> not usable in this > scenario > > > > Our solution so far has been to have a scheduled executor which calls > audioclip.play() every 500 ms. This creates a new thread every time (see stack > trace below) and we don't like this approach. > > For the moment this is a better solution, until we can get a few internal things > fixed in AudioClip. > > In the current implementation there will always be at least one new thread > created. > > > There are bugs filed on this already, specifically: > https://bugs.openjdk.java.net/browse/JDK-8090414 > https://bugs.openjdk.java.net/browse/JDK-8087423 > > And possibly related: > https://bugs.openjdk.java.net/browse/JDK-8088375 > > -DrD- From murali.billa at oracle.com Wed Aug 24 11:49:15 2016 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 24 Aug 2016 04:49:15 -0700 (PDT) Subject: [9] Review request for 8162979: Website weibo.com cannot be loaded In-Reply-To: References: <5d429381-0799-e757-c070-827af4746317@oracle.com> Message-ID: <4816ea91-3506-4e52-84f6-86f04768d6f3@default> ? Hi Kevin, Arun, Guru, Please review the following fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8162979 Webrev: http://cr.openjdk.java.net/~mbilla/8162979/webrev.00/ ? Thanks, Murali From david.dehaven at oracle.com Wed Aug 24 14:34:41 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 24 Aug 2016 07:34:41 -0700 Subject: Playing a sound at regular intervals In-Reply-To: <85457024-4BEB-4BDA-A7CE-4A8A5D1D7907@gmail.com> References: <6D5AA6A29F1039459FDD3C00A9F5DE98EC5DB417@EOFFICE-EX01.360t.com> <85457024-4BEB-4BDA-A7CE-4A8A5D1D7907@gmail.com> Message-ID: <35B58DD4-C3F3-4D3B-92A3-8C8FC3F40B7B@oracle.com> I see no reason for that, I'll clean it up and make it public. -DrD- > FYI... This issue is not visible to me https://bugs.openjdk.java.net/browse/JDK-8090414 > > > Scott > >> On Aug 23, 2016, at 10:15 AM, David DeHaven wrote: >> >> >>> We're trying to play a notification sound at a regular interval (every 500ms) in a loop. >>> >>> It should sound like "bing.bing.bing." and not like "bing......bing..bing...bing" if you know what I mean ;) >>> >>> From the JavaDoc we were guessing that an efficient way to do this would be to set cycle count to indefinite on the audio clip / on the media player and call play() once. >>> >>> Observations: >>> - Cycle count doesn't work for mp3 files. No problem, just use WAV. >>> - The playback does not happen at regular intervals. -> not usable in this scenario >>> >>> Our solution so far has been to have a scheduled executor which calls audioclip.play() every 500 ms. This creates a new thread every time (see stack trace below) and we don't like this approach. >> >> For the moment this is a better solution, until we can get a few internal things fixed in AudioClip. >> >> In the current implementation there will always be at least one new thread created. >> >> >> There are bugs filed on this already, specifically: >> https://bugs.openjdk.java.net/browse/JDK-8090414 >> https://bugs.openjdk.java.net/browse/JDK-8087423 >> >> And possibly related: >> https://bugs.openjdk.java.net/browse/JDK-8088375 >> >> -DrD- >> From chris.bensen at oracle.com Wed Aug 24 17:26:54 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 24 Aug 2016 10:26:54 -0700 Subject: [9] Review Request: 8155956 Java Packager runtime argument Message-ID: <65881E75-0051-401F-ABA6-7F997976264C@oracle.com> Kevin, Please review change for Java Packager runtime argument and a few other minor changes. Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8155956/webrev.00/ JIRA: https://bugs.openjdk.java.net/browse/JDK-8155956 Chris From kevin.rushforth at oracle.com Thu Aug 25 20:16:37 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Aug 2016 13:16:37 -0700 Subject: PLEASE READ: Using jcheck with FX repos + no more post-commit reviews Message-ID: <57BF5225.70809@oracle.com> All OpenJFX Developers, As I think most of you know, we are (more slowly than I would like) moving towards enabling jcheck for FX repos. This work is tracked by JDK-8145561 [1]. As the next step along this path, I have created an OpenJFX "Using jcheck" [2] Wiki page with instructions for running jcheck with OpenJFX. All committers must read this page before pushing any code to an OpenJFX repo. Until we enable jcheck on the server, it will still be a manual process -- you have to remember to run 'hg jcheck' before you push, but at least this will make it very easy to do so. Along with the move towards jcheck, and also because we are just about to start rampdown phase 1 for JDK 9, we are eliminating the post-commit review of OpenJFX changesets. This change is documented on the updated OpenJFX "Code Reviews" [3] policy page. This is more in line with policy governing the rest of the JDK and is what jcheck requires. This policy change is effective Friday, Aug 26 (tomorrow) at noon Pacific time. Please let me know if you have any questions. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8145561 [2] https://wiki.openjdk.java.net/display/OpenJFX/Using+jcheck [3] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews From chris.bensen at oracle.com Thu Aug 25 23:07:02 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Thu, 25 Aug 2016 16:07:02 -0700 Subject: [9] Review Request: 8164248 [packager] New Modular Arguments to be made public for Packager API Message-ID: <0BD44B52-E07C-4A08-BAE4-DB5A2A23F9E5@oracle.com> Kevin, Please review the change to make all the modular arguments part of the Java Packager public API. JIRA: https://bugs.openjdk.java.net/browse/JDK-8164248 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8164248/webrev.00/ Thanks, Chris From vadim.pakhnushev at oracle.com Fri Aug 26 14:34:45 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 26 Aug 2016 17:34:45 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <726a7054-a6f9-0584-697a-bfaaaabed0aa@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From swpalmer at gmail.com Sun Aug 28 21:57:09 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 28 Aug 2016 17:57:09 -0400 Subject: javapackager - Is it JDK or JFX? Message-ID: I?m curious where the javapackager tool belongs. It used to be called javafxpackager, and the source code seems to still live in the ?fxpackager? folder of the OpenJFX repository, which is why I?m asking on this list. I noticed that builds of the JDK that don?t include JavaFX (e.g. Linux ARM) don?t have the javapackager. Then I thought to add JavaFX to that JDK by way of some of the community-produced binaries, and noticed that the OpenJFX builds for ARM don?t include javapackager either. That seems a bit strange? If javapackager is part of either OpenJDK or OpenJFX I would have expected to see it show up. I find javapackager to be one of the most useful additions to the JDK, but it?s unclear how it fits in. Is the omission of javapackager from Linux ARM builds intentional? If so, why is that? Regards, Scott From james.graham at oracle.com Mon Aug 29 00:16:58 2016 From: james.graham at oracle.com (Jim Graham) Date: Sun, 28 Aug 2016 17:16:58 -0700 Subject: [9, 8u] Review request for 8087565: Scaling problem on OSX Retina Message-ID: <2010b15d-4ff2-aec8-216d-72caf77dcaad@oracle.com> Same patch applies to both (modulo source code paths). jbs: https://bugs.openjdk.java.net/browse/JDK-8087565 8u webrev: http://cr.openjdk.java.net/~flar/JDK-8087565/webrev.8u.00/ 9u webrev: http://cr.openjdk.java.net/~flar/JDK-8087565/webrev.9u.00/ This is a minor improvement on the earlier fix for JDK-8145516 to ensure that we communicate the scale of a newly mapped view to the FX code regardless of how the window/view are made visible... ...jim From guru.hb at oracle.com Mon Aug 29 10:53:27 2016 From: guru.hb at oracle.com (Guru Hb) Date: Mon, 29 Aug 2016 16:23:27 +0530 Subject: Review request for 8144263 : [WebView, OS X] Webkit rendering artifacts with inertia scrolling In-Reply-To: References: Message-ID: Hi Kevin, Arun & Murali, Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8144263 Webrev : http://cr.openjdk.java.net/~ghb/8144263/webrev.00/ RC and Solution updated in JBS. Thanks, Guru From kevin.rushforth at oracle.com Mon Aug 29 12:43:36 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Aug 2016 05:43:36 -0700 Subject: javapackager - Is it JDK or JFX? In-Reply-To: References: Message-ID: <57C42DF8.1080407@oracle.com> Hi Scott, Chris Bensen can provide more detail if needed. The javafxpackager was renamed to the javapackager in JDK 8u20. The intention being to make it useful for non-JavaFX programs as well as JavaFX programs. In JDK 9, part of the functionality was moved to the JDK repo, but it needs more refactoring before the rest of the non-FX-specific code can be built without needing FX. It is too late to do this for JDK 9, but the intention is to do it for a future release (possibly JDK 10, or could be done in a 9.x update release). Until then you will need to build JDK + FX to include the javapackager. -- Kevin Scott Palmer wrote: > I?m curious where the javapackager tool belongs. It used to be called javafxpackager, and the source code seems to still live in the ?fxpackager? folder of the OpenJFX repository, which is why I?m asking on this list. > > I noticed that builds of the JDK that don?t include JavaFX (e.g. Linux ARM) don?t have the javapackager. Then I thought to add JavaFX to that JDK by way of some of the community-produced binaries, and noticed that the OpenJFX builds for ARM don?t include javapackager either. That seems a bit strange? If javapackager is part of either OpenJDK or OpenJFX I would have expected to see it show up. > > I find javapackager to be one of the most useful additions to the JDK, but it?s unclear how it fits in. Is the omission of javapackager from Linux ARM builds intentional? If so, why is that? > > Regards, > > Scott From chris.bensen at oracle.com Mon Aug 29 14:21:18 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Mon, 29 Aug 2016 07:21:18 -0700 Subject: javapackager - Is it JDK or JFX? In-Reply-To: <57C42DF8.1080407@oracle.com> References: <57C42DF8.1080407@oracle.com> Message-ID: Hi Scott, As Kevin say?s the Java Packager lives in the FX repository at the moment under the fxpackager folder. I can?t comment on what is included in the community-produced binaries, but the Java Packager isn?t shipped with any ARM builds that I?m aware of. Currently it is only for X86 Windows, Linux and Mac. I?ll take this as a request though? Chris > On Aug 29, 2016, at 5:43 AM, Kevin Rushforth wrote: > > Hi Scott, > > Chris Bensen can provide more detail if needed. The javafxpackager was renamed to the javapackager in JDK 8u20. The intention being to make it useful for non-JavaFX programs as well as JavaFX programs. In JDK 9, part of the functionality was moved to the JDK repo, but it needs more refactoring before the rest of the non-FX-specific code can be built without needing FX. It is too late to do this for JDK 9, but the intention is to do it for a future release (possibly JDK 10, or could be done in a 9.x update release). Until then you will need to build JDK + FX to include the javapackager. > > -- Kevin > > > Scott Palmer wrote: >> I?m curious where the javapackager tool belongs. It used to be called javafxpackager, and the source code seems to still live in the ?fxpackager? folder of the OpenJFX repository, which is why I?m asking on this list. >> >> I noticed that builds of the JDK that don?t include JavaFX (e.g. Linux ARM) don?t have the javapackager. Then I thought to add JavaFX to that JDK by way of some of the community-produced binaries, and noticed that the OpenJFX builds for ARM don?t include javapackager either. That seems a bit strange? If javapackager is part of either OpenJDK or OpenJFX I would have expected to see it show up. >> >> I find javapackager to be one of the most useful additions to the JDK, but it?s unclear how it fits in. Is the omission of javapackager from Linux ARM builds intentional? If so, why is that? >> >> Regards, >> >> Scott From kevin.rushforth at oracle.com Mon Aug 29 14:25:36 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Aug 2016 07:25:36 -0700 Subject: In(Sanity) Testing Mondays In-Reply-To: <726a7054-a6f9-0584-697a-bfaaaabed0aa@oracle.com> References: <726a7054-a6f9-0584-697a-bfaaaabed0aa@oracle.com> Message-ID: <57C445E0.30202@oracle.com> Note that a late fix for JDK-8163316 [1] was approved for this week in order to unblock the fix for JDK-8160851 [2][3]. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8163316 [2] https://bugs.openjdk.java.net/browse/JDK-8160851 [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009216.html Vadim Pakhnushev wrote: > Reminder, Monday is our weekly sanity testing. > > You can find your testing assignment at: > https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing > > Also please remember that the repo will be locked from 1am PST until > 1pm PST. > > Happy testing! > > Thanks, > Vadim From David.Hill at Oracle.com Mon Aug 29 14:31:51 2016 From: David.Hill at Oracle.com (David Hill) Date: Mon, 29 Aug 2016 10:31:51 -0400 Subject: HEADS UP and review for new gnu style java command line options Message-ID: <57C44757.6090904@Oracle.com> HEADS UP: I just commited a change that will require a JIGSAW_HOME that is build jdk-9+132 or later. That build is now available for download from the JDK9 EA site (actually b133) . This commit went in a bit early to squeeze it into this weeks promotion to allow the JDK team to remove the old command line options. This updated JDK9 uses new GNU style command line options for the JDK 9 additions, and the older versions will be retired DJK9 build 135. The JavaFX build will fail with the older JDK9 builds that do not have the new options. The supported options are defined here , and in general are not going to impact most developers. Please download and reset your JIGSAW_HOME to point to jdk-9+132 (or later) now. A last note: We still require JDK9 ea build 109 as the bootstrap JDK ( JDK_HOME/JAVA_HOME ) -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From vadim.pakhnushev at oracle.com Mon Aug 29 15:04:43 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 29 Aug 2016 18:04:43 +0300 Subject: [9] Review request for 8134315: [LineChart] Blurry elements since 8u60 Message-ID: <73b1f564-1f3c-777d-221c-74ccf5bfa4e3@oracle.com> Hi Jim, Jonathan, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8134315 http://cr.openjdk.java.net/~vadim/8134315/webrev.00/ Thanks, Vadim From philip.race at oracle.com Mon Aug 29 22:30:36 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 29 Aug 2016 15:30:36 -0700 Subject: RFR: 8087632: The printer job status shows "ERROR" after setting the pages range and printing the content. Message-ID: <57C4B78C.5080900@oracle.com> Bug : https://bugs.openjdk.java.net/browse/JDK-8087632 Webrev: http://cr.openjdk.java.net/~prr/8087632/ Eval. is in the JBS bug. -phil. From murali.billa at oracle.com Tue Aug 30 07:52:08 2016 From: murali.billa at oracle.com (Murali Billa) Date: Tue, 30 Aug 2016 00:52:08 -0700 (PDT) Subject: [9] Review request for 8164914: Add Test Case for JDK-8162979 In-Reply-To: <4816ea91-3506-4e52-84f6-86f04768d6f3@default> References: <5d429381-0799-e757-c070-827af4746317@oracle.com> <4816ea91-3506-4e52-84f6-86f04768d6f3@default> Message-ID: <1ab92023-3096-4b38-9957-d6886e1789f3@default> ? Hi Kevin, Arun, Guru, Please review the following fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8164914 Webrev: http://cr.openjdk.java.net/~mbilla/8164914/webrev.00/ Thanks, Murali From alexander.matveev at oracle.com Tue Aug 30 23:57:22 2016 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 30 Aug 2016 16:57:22 -0700 Subject: [9] Review request for 8160988: NoClassDefFound exception when using getDeclaredMethod method of MediaView class Message-ID: <7de39156-0328-47a2-16f6-ebed9646a1b6@oracle.com> Hi Kevin and David, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8160988 Removed dependency on IOSMediaPlayer. Thanks, Alexander From chris.bensen at oracle.com Wed Aug 31 16:30:44 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 31 Aug 2016 09:30:44 -0700 Subject: [9] Review Request: 8163076 javapackager bundling fails due to issue in JAVA-API Message-ID: <2D356F86-0E0B-4C80-A72B-8A835593734A@oracle.com> Kevin, Please review this change to fix invoking the Java Packager through the Java Packager API. JIRA: https://bugs.openjdk.java.net/browse/JDK-8163076 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8163076/webrev.00/ Chris From tai.hu at veroanalytics.com Wed Aug 31 19:08:24 2016 From: tai.hu at veroanalytics.com (Tai Hu) Date: Wed, 31 Aug 2016 15:08:24 -0400 Subject: JavaFX XYChart with CategoryAxis Performance Issue Message-ID: <364FD586-FFD1-4EE6-9A33-F41FA6D1D7A0@veroanalytics.com> I am using JavaFX XYChart to plot some big data set (10000+ points). If both X and Y axis are NumberAxis, my line chart could render in a reasonable time, if I set chart.setCreateSymbol(false). However, if one of axis is a CategoryAxis, then performance is horrible. I think the problem is CategoryAxis creates a tick for each one of 10000+ strings. I already tried to set tick visibility to false, which help a bit, but still too slow. Is there anyway to improve this? Thanks, Tai From jonathan.giles at oracle.com Wed Aug 31 21:04:27 2016 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 1 Sep 2016 09:04:27 +1200 Subject: JavaFX XYChart with CategoryAxis Performance Issue In-Reply-To: <364FD586-FFD1-4EE6-9A33-F41FA6D1D7A0@veroanalytics.com> References: <364FD586-FFD1-4EE6-9A33-F41FA6D1D7A0@veroanalytics.com> Message-ID: <545b5314-dcbc-f847-0884-98f85ea54087@oracle.com> Without a small snippet of code that reproduces the problem, not really. If you can create a self-contained test that demonstrates the problem, I can take a look at it. -- Jonathan On 1/09/16 7:08 AM, Tai Hu wrote: > I am using JavaFX XYChart to plot some big data set (10000+ points). If both X and Y axis are NumberAxis, my line chart could render in a reasonable time, if I set chart.setCreateSymbol(false). However, if one of axis is a CategoryAxis, then performance is horrible. I think the problem is CategoryAxis creates a tick for each one of 10000+ strings. I already tried to set tick visibility to false, which help a bit, but still too slow. Is there anyway to improve this? > > Thanks, > > Tai From tai.hu at veroanalytics.com Wed Aug 31 21:39:14 2016 From: tai.hu at veroanalytics.com (Tai Hu) Date: Wed, 31 Aug 2016 17:39:14 -0400 Subject: JavaFX XYChart with CategoryAxis Performance Issue In-Reply-To: <545b5314-dcbc-f847-0884-98f85ea54087@oracle.com> References: <364FD586-FFD1-4EE6-9A33-F41FA6D1D7A0@veroanalytics.com> <545b5314-dcbc-f847-0884-98f85ea54087@oracle.com> Message-ID: <5F03B299-E21B-4276-A617-3C8390848E71@veroanalytics.com> Jonathan, That is my bad. Here is a simple self-contained test. I could plot 10000 in 40 seconds (Our goal is to bring down to 5 seconds) on my MacBook Pro (i5 CPU). If I increased number to 100K (that will be the upper limit for our application), chart did not render in 6 minutes and I have to kill the program. By the way, I am using JDK 8u102. Thanks, Tai -------------- next part -------------- > On Aug 31, 2016, at 5:04 PM, Jonathan Giles wrote: > > Without a small snippet of code that reproduces the problem, not really. If you can create a self-contained test that demonstrates the problem, I can take a look at it. > > -- Jonathan > > On 1/09/16 7:08 AM, Tai Hu wrote: >> I am using JavaFX XYChart to plot some big data set (10000+ points). If both X and Y axis are NumberAxis, my line chart could render in a reasonable time, if I set chart.setCreateSymbol(false). However, if one of axis is a CategoryAxis, then performance is horrible. I think the problem is CategoryAxis creates a tick for each one of 10000+ strings. I already tried to set tick visibility to false, which help a bit, but still too slow. Is there anyway to improve this? >> >> Thanks, >> >> Tai > From guru.hb at oracle.com Wed Aug 31 21:39:23 2016 From: guru.hb at oracle.com (Guru Hb) Date: Thu, 1 Sep 2016 03:09:23 +0530 Subject: [9] Review request for 8164076: [Windows] JavaFX crash in WebPage.twkOpen in 8u112 when closing WebView while debugging In-Reply-To: References: Message-ID: <46c11ccc-23d8-7ed2-f495-782de667c69c@oracle.com> Hi Kevin, Murali & Ankit, Please review the fix for JBS : https://bugs.openjdk.java.net/browse/JDK-8164076 Webrev : http://cr.openjdk.java.net/~ghb/8164960/webrev.00/ RC and Solution updated in JBS. Thanks, Guru