From andrey.rusakov at oracle.com Thu Sep 1 09:37:10 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Thu, 1 Sep 2016 12:37:10 +0300 Subject: JDK-8165224 Review request Message-ID: Hello, everyone. Please have a look at my review request for test bug: Jira issue: https://bugs.openjdk.java.net/browse/JDK-8165224 Webrev: http://cr.openjdk.java.net/~arusakov/8165224/webrev.00/ Thanks in advance. From andrey.rusakov at oracle.com Thu Sep 1 15:29:53 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Thu, 1 Sep 2016 18:29:53 +0300 Subject: JDK-8165224 Review request In-Reply-To: References: Message-ID: <7472eb77-3c63-6c39-e3f4-981bcf3e2cc5@oracle.com> Hello, everyone. Please have a look at my review request for test bug: Jira issue: https://bugs.openjdk.java.net/browse/JDK-8165238 Webrev: http://cr.openjdk.java.net/~arusakov/8165238/webrev.00/ Thanks in advance. From chris.bensen at oracle.com Fri Sep 2 00:50:12 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Thu, 1 Sep 2016 17:50:12 -0700 Subject: [9] Review Request: Message-ID: Kevin, Please review this change to fix the .properties files. JIRA: https://bugs.openjdk.java.net/browse/JDK-8165057 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165057/webrev.00/ Chris From vadim.pakhnushev at oracle.com Fri Sep 2 16:28:17 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 2 Sep 2016 19:28:17 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <2d1194f4-229c-07c0-3e63-cf5629c6a7b8@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 james.graham at oracle.com Fri Sep 2 19:24:43 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 2 Sep 2016 12:24:43 -0700 Subject: [9] Review request for 8090176: Pisces software renderer shows incomplete border images in particular situation Message-ID: <40531bb7-88df-2b64-b5f8-70734ee1ae19@oracle.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8090176 webrev for 9u: http://cr.openjdk.java.net/~flar/JDK-8090176/webrev.9u.01/ The webrev is prepared for 8u, but I will be holding off on submitting that for backport review until the fix has baked in the 9u-dev repo for a couple of weeks... ...jim From kevin.rushforth at oracle.com Sat Sep 3 16:36:04 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 03 Sep 2016 09:36:04 -0700 Subject: In(Sanity) Testing Mondays In-Reply-To: <2d1194f4-229c-07c0-3e63-cf5629c6a7b8@oracle.com> References: <2d1194f4-229c-07c0-3e63-cf5629c6a7b8@oracle.com> Message-ID: <57CAFBF4.8050308@oracle.com> Note that Monday is a US holiday so testing will be light this week. -- Kevin 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 vadim.pakhnushev at oracle.com Mon Sep 5 11:49:56 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 5 Sep 2016 14:49:56 +0300 Subject: [9] Review request for 8137141: Fatal error in Method::build_method_counters when called from libglass.so Message-ID: Hi David, Kevin, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8137141 http://cr.openjdk.java.net/~vadim/8137141/webrev.00/ Thanks, Vadim From james.graham at oracle.com Tue Sep 6 17:52:41 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 6 Sep 2016 10:52:41 -0700 Subject: [9] Review request for 8090176: Pisces software renderer shows incomplete border images in particular situation In-Reply-To: <40531bb7-88df-2b64-b5f8-70734ee1ae19@oracle.com> References: <40531bb7-88df-2b64-b5f8-70734ee1ae19@oracle.com> Message-ID: <37266008-8f67-1f4e-6504-3a0129fac415@oracle.com> There is now an updated fix that addresses a potential performance loss when simple 1:1 blits were accidentally getting redirected through interpolate-per-pixel code by the first fix... http://cr.openjdk.java.net/~flar/JDK-8090176/webrev.9u.02/ ...jim On 9/2/16 12:24 PM, Jim Graham wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8090176 > webrev for 9u: http://cr.openjdk.java.net/~flar/JDK-8090176/webrev.9u.01/ > > The webrev is prepared for 8u, but I will be holding off on submitting that for backport review until the fix has baked > in the 9u-dev repo for a couple of weeks... > > ...jim From chris.bensen at oracle.com Tue Sep 6 18:55:20 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 6 Sep 2016 11:55:20 -0700 Subject: [9] Review Request: 8165548 javapackager -help shows --modulepath not --module-path Message-ID: Kevin, Please review this simple string change. JIRA: https://bugs.openjdk.java.net/browse/JDK-8165548 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165548/webrev.00/ Chris From kevin.rushforth at oracle.com Wed Sep 7 00:08:28 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Sep 2016 17:08:28 -0700 Subject: [PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene In-Reply-To: <57B4C7B3.4090004@oracle.com> References: <39317253-63D5-4FD3-A0FE-D506D0830237@nyssen.org> <2F35F2DC-CFB9-4DBF-B5D7-0CC9DA80C2A5@nyssen.org> <57B1FB54.5000804@oracle.com> <57B4C7B3.4090004@oracle.com> Message-ID: <57CF5A7C.3030301@oracle.com> Approved, assuming the changes to the wild-import are done by Alexander along with a correctly formatted changeset commit message. -- Kevin Kevin Rushforth wrote: > 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 guru.hb at oracle.com Wed Sep 7 04:25:44 2016 From: guru.hb at oracle.com (Guru Hb) Date: Wed, 7 Sep 2016 09:55:44 +0530 Subject: [9] Review Request for 8165508: Incorrect Bug ID in comment for JDK-8164076 Message-ID: Hi Ankit, Murali & Kevin, Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8165508 Webrev : http://cr.openjdk.java.net/~ghb/8165508/webrev.00/index.html Thanks, Guru From a.ankit.srivastava at oracle.com Wed Sep 7 06:47:19 2016 From: a.ankit.srivastava at oracle.com (Ankit Srivastava) Date: Tue, 6 Sep 2016 23:47:19 -0700 (PDT) Subject: [9] Review Request 8165173 : DRT test canvas/philip/tests/2d.path.clip.empty.html fails with 8u112 Message-ID: Hi Kevin, Murali and Guru, Please review the below patch. JBS: https://bugs.openjdk.java.net/browse/JDK-8165173 Webrev : http://cr.openjdk.java.net/~asrivastava/8165173/webrev.00/ Tested on Win64 and Linux 64 The null path check was redundant and was applied making an assumption that null path can't be a use case. But it seems we have a use case in the form of drt test case "2d.path.clip.empty.html". Regards, Ankit From swpalmer at gmail.com Wed Sep 7 16:03:55 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 7 Sep 2016 12:03:55 -0400 Subject: Packager Images for Mac DMG and PKG Backgrounds Message-ID: <6A42F68D-FFDC-4B74-971D-086829CDD7C3@gmail.com> I?m packaging a Java application on Mac. As I want to be able to install it as a service or run it as a regular application, I?m building both a .dmg and .pkg. I'm trying to use two different custom images for my Disk Image and for my .pkg background. I can?t seem to make that work. The packager seems to want a file named ?{AppName}-background.png? for both cases. I?m currently doing this through the javafx-gradle plugin from https://github.com/FibreFoX/javafx-gradle-plugin The source code for MacDmgBunder.java and MacPkgBundler.java have constants that indicate: static final DEFAULT_BACKGROUND_IMAGE = ?background_dmg.png? and static final DEFAULT_BACKGROUND_IMAGE = ?background_pkg.png? However my attempts to name files with ?{AppName}-background_dmg.png? and ?{AppName}-background_pkg.png? did not have any effect. E.g.: "{dropinResourcesRoot}/packager/macosx/Example Application-background_pkg.png? doesn?t get used and instead I am told to customize it by placing a file named ?Example Application-background.png? in that location: "Using default package resource [pkg background image] (add package/macosx/Example Application-background.png to the class path to customize)" The build process only picks up the file with "-background.png" : "Using custom package resource [pkg background image] (loaded from package/macosx/Example Application-background.png)? I?m running Java 8u102. I updated my OpenJFX source to that tag and double checked the MacPkgBundler.java code and it still has the background_pkg.png constant and it appears to use it on line 358, but something isn?t working properly it seems. Regards, Scott From swpalmer at gmail.com Wed Sep 7 16:27:28 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 7 Sep 2016 12:27:28 -0400 Subject: Packager Images for Mac DMG and PKG Backgrounds In-Reply-To: <6A42F68D-FFDC-4B74-971D-086829CDD7C3@gmail.com> References: <6A42F68D-FFDC-4B74-971D-086829CDD7C3@gmail.com> Message-ID: <9832C602-EE8C-47F8-92A5-1F25E5C77589@gmail.com> As I continued my search I gained a better understanding of the packager code and see that the file name is in fixed for both DMG and PKG bundlers to use the same ?-background.png? suffix. :-( This is done in the getConfig_BackgroundImage method of the PKG bundler and the getConfig_VolumeBackground method of the DMG bundler. It should be fixed as otherwise you can?t run all bundlers in a sane way with customizations. Regards, Scott > On Sep 7, 2016, at 12:03 PM, Scott Palmer wrote: > > I?m packaging a Java application on Mac. As I want to be able to install it as a service or run it as a regular application, I?m building both a .dmg and .pkg. I'm trying to use two different custom images for my Disk Image and for my .pkg background. I can?t seem to make that work. > The packager seems to want a file named ?{AppName}-background.png? for both cases. > > I?m currently doing this through the javafx-gradle plugin from https://github.com/FibreFoX/javafx-gradle-plugin > > > The source code for MacDmgBunder.java and MacPkgBundler.java have constants that indicate: > > static final DEFAULT_BACKGROUND_IMAGE = ?background_dmg.png? > > and > > static final DEFAULT_BACKGROUND_IMAGE = ?background_pkg.png? > > > However my attempts to name files with ?{AppName}-background_dmg.png? and ?{AppName}-background_pkg.png? did not have any effect. E.g.: > > "{dropinResourcesRoot}/packager/macosx/Example Application-background_pkg.png? > > doesn?t get used and instead I am told to customize it by placing a file named ?Example Application-background.png? in that location: > > "Using default package resource [pkg background image] (add package/macosx/Example Application-background.png to the class path to customize)" > > The build process only picks up the file with "-background.png" : > > "Using custom package resource [pkg background image] (loaded from package/macosx/Example Application-background.png)? > > > I?m running Java 8u102. I updated my OpenJFX source to that tag and double checked the MacPkgBundler.java code and it still has the background_pkg.png constant and it appears to use it on line 358, but something isn?t working properly it seems. > > > Regards, > > Scott > From chris.bensen at oracle.com Wed Sep 7 16:35:58 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 7 Sep 2016 09:35:58 -0700 Subject: Packager Images for Mac DMG and PKG Backgrounds In-Reply-To: <9832C602-EE8C-47F8-92A5-1F25E5C77589@gmail.com> References: <6A42F68D-FFDC-4B74-971D-086829CDD7C3@gmail.com> <9832C602-EE8C-47F8-92A5-1F25E5C77589@gmail.com> Message-ID: Hi Scott, Please file a bug. Thanks, Chris > On Sep 7, 2016, at 9:27 AM, Scott Palmer wrote: > > As I continued my search I gained a better understanding of the packager code and see that the file name is in fixed for both DMG and PKG bundlers to use the same ?-background.png? suffix. > > :-( > > This is done in the getConfig_BackgroundImage method of the PKG bundler and the getConfig_VolumeBackground method of the DMG bundler. > > It should be fixed as otherwise you can?t run all bundlers in a sane way with customizations. > > Regards, > > Scott > > >> On Sep 7, 2016, at 12:03 PM, Scott Palmer wrote: >> >> I?m packaging a Java application on Mac. As I want to be able to install it as a service or run it as a regular application, I?m building both a .dmg and .pkg. I'm trying to use two different custom images for my Disk Image and for my .pkg background. I can?t seem to make that work. >> The packager seems to want a file named ?{AppName}-background.png? for both cases. >> >> I?m currently doing this through the javafx-gradle plugin from https://github.com/FibreFoX/javafx-gradle-plugin >> >> >> The source code for MacDmgBunder.java and MacPkgBundler.java have constants that indicate: >> >> static final DEFAULT_BACKGROUND_IMAGE = ?background_dmg.png? >> >> and >> >> static final DEFAULT_BACKGROUND_IMAGE = ?background_pkg.png? >> >> >> However my attempts to name files with ?{AppName}-background_dmg.png? and ?{AppName}-background_pkg.png? did not have any effect. E.g.: >> >> "{dropinResourcesRoot}/packager/macosx/Example Application-background_pkg.png? >> >> doesn?t get used and instead I am told to customize it by placing a file named ?Example Application-background.png? in that location: >> >> "Using default package resource [pkg background image] (add package/macosx/Example Application-background.png to the class path to customize)" >> >> The build process only picks up the file with "-background.png" : >> >> "Using custom package resource [pkg background image] (loaded from package/macosx/Example Application-background.png)? >> >> >> I?m running Java 8u102. I updated my OpenJFX source to that tag and double checked the MacPkgBundler.java code and it still has the background_pkg.png constant and it appears to use it on line 358, but something isn?t working properly it seems. >> >> >> Regards, >> >> Scott >> > From swpalmer at gmail.com Wed Sep 7 19:12:41 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 7 Sep 2016 15:12:41 -0400 Subject: Packager Images for Mac DMG and PKG Backgrounds In-Reply-To: References: <6A42F68D-FFDC-4B74-971D-086829CDD7C3@gmail.com> <9832C602-EE8C-47F8-92A5-1F25E5C77589@gmail.com> Message-ID: <6156435B-3F79-4666-AE65-CA9B5623BA13@gmail.com> Done. https://bugs.openjdk.java.net/browse/JDK-8165630 > On Sep 7, 2016, at 12:35 PM, Chris Bensen wrote: > > Hi Scott, > > Please file a bug. > > Thanks, > Chris > > >> On Sep 7, 2016, at 9:27 AM, Scott Palmer wrote: >> >> As I continued my search I gained a better understanding of the packager code and see that the file name is in fixed for both DMG and PKG bundlers to use the same ?-background.png? suffix. >> >> :-( >> >> This is done in the getConfig_BackgroundImage method of the PKG bundler and the getConfig_VolumeBackground method of the DMG bundler. >> >> It should be fixed as otherwise you can?t run all bundlers in a sane way with customizations. >> >> Regards, >> >> Scott >> >> >>> On Sep 7, 2016, at 12:03 PM, Scott Palmer wrote: >>> >>> I?m packaging a Java application on Mac. As I want to be able to install it as a service or run it as a regular application, I?m building both a .dmg and .pkg. I'm trying to use two different custom images for my Disk Image and for my .pkg background. I can?t seem to make that work. >>> The packager seems to want a file named ?{AppName}-background.png? for both cases. >>> >>> I?m currently doing this through the javafx-gradle plugin from https://github.com/FibreFoX/javafx-gradle-plugin >>> >>> >>> The source code for MacDmgBunder.java and MacPkgBundler.java have constants that indicate: >>> >>> static final DEFAULT_BACKGROUND_IMAGE = ?background_dmg.png? >>> >>> and >>> >>> static final DEFAULT_BACKGROUND_IMAGE = ?background_pkg.png? >>> >>> >>> However my attempts to name files with ?{AppName}-background_dmg.png? and ?{AppName}-background_pkg.png? did not have any effect. E.g.: >>> >>> "{dropinResourcesRoot}/packager/macosx/Example Application-background_pkg.png? >>> >>> doesn?t get used and instead I am told to customize it by placing a file named ?Example Application-background.png? in that location: >>> >>> "Using default package resource [pkg background image] (add package/macosx/Example Application-background.png to the class path to customize)" >>> >>> The build process only picks up the file with "-background.png" : >>> >>> "Using custom package resource [pkg background image] (loaded from package/macosx/Example Application-background.png)? >>> >>> >>> I?m running Java 8u102. I updated my OpenJFX source to that tag and double checked the MacPkgBundler.java code and it still has the background_pkg.png constant and it appears to use it on line 358, but something isn?t working properly it seems. >>> >>> >>> Regards, >>> >>> Scott >>> >> > From chien.yang at oracle.com Thu Sep 8 05:17:53 2016 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 07 Sep 2016 22:17:53 -0700 Subject: [9] Code Review Request For 8165378: HelloDialog program in apps/toys uses setAccessible Message-ID: <57D0F481.8000103@oracle.com> Hi Kevin, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8165378 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8165378/webrev.00/ Thanks, - Chien From chien.yang at oracle.com Fri Sep 9 14:21:28 2016 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 09 Sep 2016 07:21:28 -0700 Subject: [9] Code Review Request For 8165363: PlatformImpl in javafx.graphics uses setAccessible to access method in javafx.swing Message-ID: <57D2C568.8020700@oracle.com> Hi Kevin, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8165363 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8165363/webrev.00/ Thanks, - Chien From vadim.pakhnushev at oracle.com Fri Sep 9 14:30:14 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 9 Sep 2016 17:30:14 +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 chris.bensen at oracle.com Fri Sep 9 16:23:51 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Fri, 9 Sep 2016 09:23:51 -0700 Subject: [9] Review Request: 8165721 jmods folder is not auto discovered Message-ID: <957A6AB3-27C5-482A-BA70-3CA904BE73B4@oracle.com> Kevin, Please review this change to auto discovery of the jmods directory. JIRA: https://bugs.openjdk.java.net/browse/JDK-8165721 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165721/webrev.00/ Chris From david.dehaven at oracle.com Fri Sep 9 23:25:24 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 9 Sep 2016 16:25:24 -0700 Subject: RfR: [9] 8156563: JavaFX Ensemble8 media sample hang and crash Message-ID: <229CAE84-E785-4F68-8119-542CB659CF03@oracle.com> Alexander, Kevin, please review my fix for AVFMediaPlayer crashes on OSX: JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8156563 Webrev: http://cr.openjdk.java.net/~ddehaven/8156563/rt.0/ I believe this addresses other crashes that have been reported too, those will be resolved as duplicates. -DrD- From kevin.rushforth at oracle.com Fri Sep 9 23:52:16 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 09 Sep 2016 16:52:16 -0700 Subject: [9] Review request: 8165373: Ensemble8 uses setAccessible to access methods and fields of various classes Message-ID: <57D34B30.8030206@oracle.com> Hi Vadim, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8165373 http://cr.openjdk.java.net/~kcr/8165373/webrev.01/ Details are in the bug report. Thanks. -- Kevin From kevin.rushforth at oracle.com Fri Sep 9 23:57:24 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 09 Sep 2016 16:57:24 -0700 Subject: [9] review request: 8095297: [Windows] Ensemble 8: Spinner example layout is broken Message-ID: <57D34C64.3040405@oracle.com> Hi Vadim or Jonathan, Please review the following to backport (forward-port) a fix that went into 8u-dev last year shortly after we forked 9-dev and stropped auto-syncing. This needs to be pushed to 9 or will cause a regression. https://bugs.openjdk.java.net/browse/JDK-8095297 http://cr.openjdk.java.net/~kcr/8095297/webrev-9.00/ Details are in JBS. Thanks. -- Kevin From alexander at nyssen.org Sat Sep 10 11:58:54 2016 From: alexander at nyssen.org (=?utf-8?Q?Alexander_Ny=C3=9Fen?=) Date: Sat, 10 Sep 2016 13:58:54 +0200 Subject: Review request for 8143596: FXCanvas does not forward touch gestures to embedded scene Message-ID: Hi Alexander Z., Kevin, I have adopted my latest patch for JDK-8143596 (uploaded yesterday as patch file) to the latest tip and created a webrev for it (the uploaded patch is therefore now obsolete): https://bugs.openjdk.java.net/browse/JDK-8143596 http://cr.openjdk.java.net/~anyssen/8143596/webrev.00/ Best Regards, Alexander From David.Hill at Oracle.com Sun Sep 11 15:17:43 2016 From: David.Hill at Oracle.com (David Hill) Date: Sun, 11 Sep 2016 11:17:43 -0400 Subject: review: Rework build to enable future jigsaw aware JDK9 build Message-ID: <57D57597.9040707@Oracle.com> Kevin, would you review this build change please. https://bugs.openjdk.java.net/browse/JDK-8165809 http://cr.openjdk.java.net/~ddhill/8165809.1 -- 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 alexander at nyssen.org Tue Sep 13 10:57:57 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Tue, 13 Sep 2016 12:57:57 +0200 Subject: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135 Message-ID: Hi all, I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base and was astonished to see that all dependencies to javafx.embed.swt.* now seem to be regarded as JDK internal API. I assume this is just a temporal inconsistency. Therefore, let me ask when it is planned to transfer the javafx.swt module into a proper named JIGSAW module to resolve this. The Eclipse community relies on using the javafx.swt module in an OSGi environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would certainly be good if conformance tests could be started as early as possible. Best Regards, Alexander From kevin.rushforth at oracle.com Tue Sep 13 13:42:40 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Sep 2016 06:42:40 -0700 Subject: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135 In-Reply-To: References: Message-ID: <57D80250.3010406@oracle.com> That seems surprising since javafx.swt is not part of the JDK runtime image. I suspect that this is either an issue with jdeps itself or with how you are running jdeps. What was the command line you were using? As for your second question, the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer, but that still needs to be tested. We currently do all of our own testing by adding it as an automatic module on the module path as follows: $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules javafx.swt my.pkg.MyApp -- Kevin Alexander Nyssen wrote: > Hi all, > > I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base and was astonished to see that all dependencies to javafx.embed.swt.* now seem to be regarded as JDK internal API. I assume this is just a temporal inconsistency. Therefore, let me ask when it is planned to transfer the javafx.swt module into a proper named JIGSAW module to resolve this. The Eclipse community relies on using the javafx.swt module in an OSGi environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would certainly be good if conformance tests could be started as early as possible. > > Best Regards, > Alexander > > From alexander at nyssen.org Tue Sep 13 13:58:22 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Tue, 13 Sep 2016 15:58:22 +0200 Subject: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135 In-Reply-To: <57D80250.3010406@oracle.com> References: <57D80250.3010406@oracle.com> Message-ID: <7A8E45F9-D8E2-4D37-86E1-44C2BB755CA4@nyssen.org> Hi Kevin, > Am 13.09.2016 um 15:42 schrieb Kevin Rushforth : > > That seems surprising since javafx.swt is not part of the JDK runtime image. I suspect that this is either an issue with jdeps itself or with how you are running jdeps. What was the command line you were using? I used: for i in */bin; do /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps -jdkinternals $i; done >> deps.txt > > As for your second question, the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer, but that still needs to be tested. We currently do all of our own testing by adding it as an automatic module on the module path as follows: > > $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules javafx.swt my.pkg.MyApp I see. Is there a concrete schedule? > > ? Kevin Best Regards, Alexander > > > Alexander Nyssen wrote: >> Hi all, >> >> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base and was astonished to see that all dependencies to javafx.embed.swt.* now seem to be regarded as JDK internal API. I assume this is just a temporal inconsistency. Therefore, let me ask when it is planned to transfer the javafx.swt module into a proper named JIGSAW module to resolve this. The Eclipse community relies on using the javafx.swt module in an OSGi environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would certainly be good if conformance tests could be started as early as possible. >> >> Best Regards, >> Alexander >> >> From kevin.rushforth at oracle.com Tue Sep 13 14:30:15 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Sep 2016 07:30:15 -0700 Subject: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135 In-Reply-To: <7A8E45F9-D8E2-4D37-86E1-44C2BB755CA4@nyssen.org> References: <57D80250.3010406@oracle.com> <7A8E45F9-D8E2-4D37-86E1-44C2BB755CA4@nyssen.org> Message-ID: <57D80D77.7020109@oracle.com> Alexander Nyssen wrote: > Hi Kevin, > >> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth >> >: >> >> That seems surprising since javafx.swt is not part of the JDK runtime >> image. I suspect that this is either an issue with jdeps itself or >> with how you are running jdeps. What was the command line you were using? > > I used: for i in */bin; do > /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps > -jdkinternals $i; done >> deps.txt That doesn't show how javafx-swt.jar is being referenced. javafx-swt.jar is delivered with the JDK, but is not loaded by default (or at least it should not be). >> As for your second question, the expectation is that javafx.swt will >> be added as an automatic (and thus named) module in a layer, but that >> still needs to be tested. We currently do all of our own testing by >> adding it as an automatic module on the module path as follows: >> >> $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules >> javafx.swt my.pkg.MyApp > > I see. Is there a concrete schedule? If you mean is there a concrete schedule for the Eclipse folks to do the work to verify that javafx.swt can be loaded in a layer, I can't comment on that, since this work is outside the scope of the JDK. Perhaps Tom Schindl can respond? -- Kevin > >> >> ? Kevin > > Best Regards, > Alexander > >> >> >> Alexander Nyssen wrote: >>> Hi all, >>> >>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF >>> code base and was astonished to see that all dependencies to >>> javafx.embed.swt.* now seem to be regarded as JDK internal API. I >>> assume this is just a temporal inconsistency. Therefore, let me ask >>> when it is planned to transfer the javafx.swt module into a proper >>> named JIGSAW module to resolve this. The Eclipse community relies on >>> using the javafx.swt module in an OSGi environment (see >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would >>> certainly be good if conformance tests could be started as early as >>> possible. >>> >>> Best Regards, >>> Alexander >>> >>> > From swpalmer at gmail.com Tue Sep 13 15:03:46 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 13 Sep 2016 11:03:46 -0400 Subject: What does the nicetohave label in JIRA mean? Message-ID: I just noticed it was applied to a bug I am watching, JDK-8089573 (JavaFX printing does not work on Mac) The issue seems to be more critical to me than what the words "nicetohave" would imply, but perhaps it simply means that it has been deferred? Scott From kevin.rushforth at oracle.com Tue Sep 13 15:10:24 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Sep 2016 08:10:24 -0700 Subject: What does the nicetohave label in JIRA mean? In-Reply-To: References: Message-ID: <57D816E0.9020405@oracle.com> We're using that label to track JavaFX, AWT, Java2D, and Swing bugs that have been moved out of JDK 9, but which we would still like to fix if time permits. -- Kevin Scott Palmer wrote: > I just noticed it was applied to a bug I am watching, JDK-8089573 (JavaFX > printing does not work on Mac) > The issue seems to be more critical to me than what the words "nicetohave" > would imply, but perhaps it simply means that it has been deferred? > > Scott > From philip.race at oracle.com Tue Sep 13 15:23:27 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 13 Sep 2016 08:23:27 -0700 Subject: What does the nicetohave label in JIRA mean? In-Reply-To: <57D816E0.9020405@oracle.com> References: <57D816E0.9020405@oracle.com> Message-ID: <57D819EF.1090003@oracle.com> This one is still targeted to 9, and so far as I can tell that has always been the case. The "release team" for the whole JDK 9 release have allowed that bugs that existed in 8 GA may be deferred out of 9 if there is not time to fix them. The logic behind that is (I think) that it is not a regression that stops you moving from 8 to 9 if it already existed since 8 GA. This one is more subtle than that .. it did not start to manifest until versions of MacOS later than any available when 8 GA shipped. Regardless of labels it is clear that this is one that needs to be addressed. -phil. On 9/13/16, 8:10 AM, Kevin Rushforth wrote: > We're using that label to track JavaFX, AWT, Java2D, and Swing bugs > that have been moved out of JDK 9, but which we would still like to > fix if time permits. > > -- Kevin > > > Scott Palmer wrote: >> I just noticed it was applied to a bug I am watching, JDK-8089573 >> (JavaFX >> printing does not work on Mac) >> The issue seems to be more critical to me than what the words >> "nicetohave" >> would imply, but perhaps it simply means that it has been deferred? >> >> Scott From David.Hill at Oracle.com Tue Sep 13 16:42:32 2016 From: David.Hill at Oracle.com (David Hill) Date: Tue, 13 Sep 2016 12:42:32 -0400 Subject: review: change checkWhiteSpace to match jcheck extension list Message-ID: <57D82C78.7040307@Oracle.com> Kevin, https://bugs.openjdk.java.net/browse/JDK-8165963 (JDK-8165963) change checkWhiteSpace to match jcheck extension list diff in 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 chris.bensen at oracle.com Tue Sep 13 17:06:22 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 13 Sep 2016 10:06:22 -0700 Subject: [9] Review Request: 8165882 Java Packager Cleanup Message-ID: <984242F1-D87C-413C-85AC-D65A43202EB8@oracle.com> Kevin, Just some minor cleanup. JIRA: https://bugs.openjdk.java.net/browse/JDK-8165882 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165882/webrev.00/ Chris From chris.bensen at oracle.com Tue Sep 13 18:16:11 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 13 Sep 2016 11:16:11 -0700 Subject: [9] Review Request: 8147392 [launcher] Change Linux to use JLI rather than JNI Message-ID: Kevin, This change goes hand in hand with the change in JDK-8165524 that will be pushed shortly. JNI is the only way to launch a modular application, so the Java Package?s launcher needs to be changed on Linux to launch this way (Windows has already been changed). JIRA: https://bugs.openjdk.java.net/browse/JDK-8147392 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8147392/webrev.00/ Chris From alexander at nyssen.org Tue Sep 13 18:31:46 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Tue, 13 Sep 2016 20:31:46 +0200 Subject: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135 In-Reply-To: <57D80D77.7020109@oracle.com> References: <57D80250.3010406@oracle.com> <7A8E45F9-D8E2-4D37-86E1-44C2BB755CA4@nyssen.org> <57D80D77.7020109@oracle.com> Message-ID: Hi Kevin, > Am 13.09.2016 um 16:30 schrieb Kevin Rushforth : > > > > Alexander Nyssen wrote: >> Hi Kevin, >> >>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth >: >>> >>> That seems surprising since javafx.swt is not part of the JDK runtime image. I suspect that this is either an issue with jdeps itself or with how you are running jdeps. What was the command line you were using? >> >> I used: for i in */bin; do /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps -jdkinternals $i; done >> deps.txt > > That doesn't show how javafx-swt.jar is being referenced. javafx-swt.jar is delivered with the JDK, but is not loaded by default (or at least it should not be). Is there a way to find out? Do I have to provide additional options? Using jdk-9-ea109 the same command line did not result in javafx.swt being regarded as JDK internal. > > >>> As for your second question, the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer, but that still needs to be tested. We currently do all of our own testing by adding it as an automatic module on the module path as follows: >>> >>> $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules javafx.swt my.pkg.MyApp >> >> I see. Is there a concrete schedule? > > If you mean is there a concrete schedule for the Eclipse folks to do the work to verify that javafx.swt can be loaded in a layer, I can't comment on that, since this work is outside the scope of the JDK. Perhaps Tom Schindl can respond? I thought the plan was to turn javafx.swt into an explicit module and not an (implicit) automatic one, and I was referring to when this was finalized. Seems I got that wrong. > > ? Kevin Best Regards, Alexander > >> >>> >>> ? Kevin >> >> Best Regards, >> Alexander >> >>> >>> >>> Alexander Nyssen wrote: >>>> Hi all, >>>> >>>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base and was astonished to see that all dependencies to javafx.embed.swt.* now seem to be regarded as JDK internal API. I assume this is just a temporal inconsistency. Therefore, let me ask when it is planned to transfer the javafx.swt module into a proper named JIGSAW module to resolve this. The Eclipse community relies on using the javafx.swt module in an OSGi environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would certainly be good if conformance tests could be started as early as possible. >>>> >>>> Best Regards, >>>> Alexander >>>> >>>> >> From chris.bensen at oracle.com Tue Sep 13 21:17:35 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 13 Sep 2016 14:17:35 -0700 Subject: [9] Review Request: 8165059 Many jdk.packager properties files are missing from javafxsdk.tbom Message-ID: Kevin, Files for translation. JIRA: https://bugs.openjdk.java.net/browse/JDK-8165059 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165059/webrev.00/ Chris From tom.schindl at bestsolution.at Tue Sep 13 22:51:49 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 14 Sep 2016 00:51:49 +0200 Subject: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135 In-Reply-To: References: <57D80250.3010406@oracle.com> <7A8E45F9-D8E2-4D37-86E1-44C2BB755CA4@nyssen.org> <57D80D77.7020109@oracle.com> Message-ID: <6c771229-9986-bca9-86fb-27e67f3e47e5@bestsolution.at> Hi, javafx.swt can never be a module loaded by default but we need to construct a new layer who has the SWT-Bundle-Classloader as the parent. So no it will not be an automic-module but a named one loaded in a secondary layer (eg by the efxclipse OSGi-Adapter-Hook) - at least this is the theory. I didn't have time yet to follow this path yet. Tom On 13.09.16 20:31, Alexander Nyssen wrote: > Hi Kevin, > >> Am 13.09.2016 um 16:30 schrieb Kevin Rushforth : >> >> >> >> Alexander Nyssen wrote: >>> Hi Kevin, >>> >>>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth >: >>>> >>>> That seems surprising since javafx.swt is not part of the JDK runtime image. I suspect that this is either an issue with jdeps itself or with how you are running jdeps. What was the command line you were using? >>> >>> I used: for i in */bin; do /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps -jdkinternals $i; done >> deps.txt >> >> That doesn't show how javafx-swt.jar is being referenced. javafx-swt.jar is delivered with the JDK, but is not loaded by default (or at least it should not be). > > Is there a way to find out? Do I have to provide additional options? Using jdk-9-ea109 the same command line did not result in javafx.swt being regarded as JDK internal. > >> >> >>>> As for your second question, the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer, but that still needs to be tested. We currently do all of our own testing by adding it as an automatic module on the module path as follows: >>>> >>>> $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules javafx.swt my.pkg.MyApp >>> >>> I see. Is there a concrete schedule? >> >> If you mean is there a concrete schedule for the Eclipse folks to do the work to verify that javafx.swt can be loaded in a layer, I can't comment on that, since this work is outside the scope of the JDK. Perhaps Tom Schindl can respond? > > I thought the plan was to turn javafx.swt into an explicit module and not an (implicit) automatic one, and I was referring to when this was finalized. Seems I got that wrong. > >> >> ? Kevin > > Best Regards, > Alexander > >> >>> >>>> >>>> ? Kevin >>> >>> Best Regards, >>> Alexander >>> >>>> >>>> >>>> Alexander Nyssen wrote: >>>>> Hi all, >>>>> >>>>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base and was astonished to see that all dependencies to javafx.embed.swt.* now seem to be regarded as JDK internal API. I assume this is just a temporal inconsistency. Therefore, let me ask when it is planned to transfer the javafx.swt module into a proper named JIGSAW module to resolve this. The Eclipse community relies on using the javafx.swt module in an OSGi environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would certainly be good if conformance tests could be started as early as possible. >>>>> >>>>> Best Regards, >>>>> Alexander >>>>> >>>>> >>> > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From alexander at nyssen.org Wed Sep 14 06:51:27 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Wed, 14 Sep 2016 08:51:27 +0200 Subject: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135 In-Reply-To: <6c771229-9986-bca9-86fb-27e67f3e47e5@bestsolution.at> References: <57D80250.3010406@oracle.com> <7A8E45F9-D8E2-4D37-86E1-44C2BB755CA4@nyssen.org> <57D80D77.7020109@oracle.com> <6c771229-9986-bca9-86fb-27e67f3e47e5@bestsolution.at> Message-ID: Hi Tom, Kevin, I have to admit that - now - I am somehow confused. At first glance "the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer? and "it will not be an autom[at]ic-module but a named one loaded in a [?] layer? sounds like a contradiction. Tom, did you plan to ?repackage? the automatic (and thus implicitly defined) javafx.swt module as an explicit one as part of e(fx)clipse, or did you - like me - expect that javafx.swt will yet be turned into an explicit module by the OpenJFX team? Best Regards, Alexander > Am 14.09.2016 um 00:51 schrieb Tom Schindl : > > Hi, > > javafx.swt can never be a module loaded by default but we need to > construct a new layer who has the SWT-Bundle-Classloader as the parent. > > So no it will not be an automic-module but a named one loaded in a > secondary layer (eg by the efxclipse OSGi-Adapter-Hook) - at least this > is the theory. I didn't have time yet to follow this path yet. > > Tom > > On 13.09.16 20:31, Alexander Nyssen wrote: >> Hi Kevin, >> >>> Am 13.09.2016 um 16:30 schrieb Kevin Rushforth : >>> >>> >>> >>> Alexander Nyssen wrote: >>>> Hi Kevin, >>>> >>>>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth >: >>>>> >>>>> That seems surprising since javafx.swt is not part of the JDK runtime image. I suspect that this is either an issue with jdeps itself or with how you are running jdeps. What was the command line you were using? >>>> >>>> I used: for i in */bin; do /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps -jdkinternals $i; done >> deps.txt >>> >>> That doesn't show how javafx-swt.jar is being referenced. javafx-swt.jar is delivered with the JDK, but is not loaded by default (or at least it should not be). >> >> Is there a way to find out? Do I have to provide additional options? Using jdk-9-ea109 the same command line did not result in javafx.swt being regarded as JDK internal. >> >>> >>> >>>>> As for your second question, the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer, but that still needs to be tested. We currently do all of our own testing by adding it as an automatic module on the module path as follows: >>>>> >>>>> $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules javafx.swt my.pkg.MyApp >>>> >>>> I see. Is there a concrete schedule? >>> >>> If you mean is there a concrete schedule for the Eclipse folks to do the work to verify that javafx.swt can be loaded in a layer, I can't comment on that, since this work is outside the scope of the JDK. Perhaps Tom Schindl can respond? >> >> I thought the plan was to turn javafx.swt into an explicit module and not an (implicit) automatic one, and I was referring to when this was finalized. Seems I got that wrong. >> >>> >>> ? Kevin >> >> Best Regards, >> Alexander >> >>> >>>> >>>>> >>>>> ? Kevin >>>> >>>> Best Regards, >>>> Alexander >>>> >>>>> >>>>> >>>>> Alexander Nyssen wrote: >>>>>> Hi all, >>>>>> >>>>>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base and was astonished to see that all dependencies to javafx.embed.swt.* now seem to be regarded as JDK internal API. I assume this is just a temporal inconsistency. Therefore, let me ask when it is planned to transfer the javafx.swt module into a proper named JIGSAW module to resolve this. The Eclipse community relies on using the javafx.swt module in an OSGi environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would certainly be good if conformance tests could be started as early as possible. >>>>>> >>>>>> Best Regards, >>>>>> Alexander >>>>>> >>>>>> >>>> >> > > > -- > Thomas Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From tom.schindl at bestsolution.at Wed Sep 14 07:26:57 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 14 Sep 2016 09:26:57 +0200 Subject: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135 In-Reply-To: References: <57D80250.3010406@oracle.com> <7A8E45F9-D8E2-4D37-86E1-44C2BB755CA4@nyssen.org> <57D80D77.7020109@oracle.com> <6c771229-9986-bca9-86fb-27e67f3e47e5@bestsolution.at> Message-ID: I expect javafx.swt to be shipped with the jdk/jre - i can not repackage and ship openjfx code from eclipse.org Tom Von meinem iPhone gesendet > Am 14.09.2016 um 08:51 schrieb Alexander Nyssen : > > Hi Tom, Kevin, > > I have to admit that - now - I am somehow confused. At first glance "the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer? and "it will not be an autom[at]ic-module but a named one loaded in a [?] layer? sounds like a contradiction. Tom, did you plan to ?repackage? the automatic (and thus implicitly defined) javafx.swt module as an explicit one as part of e(fx)clipse, or did you - like me - expect that javafx.swt will yet be turned into an explicit module by the OpenJFX team? > > Best Regards, > Alexander > >> Am 14.09.2016 um 00:51 schrieb Tom Schindl : >> >> Hi, >> >> javafx.swt can never be a module loaded by default but we need to >> construct a new layer who has the SWT-Bundle-Classloader as the parent. >> >> So no it will not be an automic-module but a named one loaded in a >> secondary layer (eg by the efxclipse OSGi-Adapter-Hook) - at least this >> is the theory. I didn't have time yet to follow this path yet. >> >> Tom >> >>> On 13.09.16 20:31, Alexander Nyssen wrote: >>> Hi Kevin, >>> >>>> Am 13.09.2016 um 16:30 schrieb Kevin Rushforth : >>>> >>>> >>>> >>>> Alexander Nyssen wrote: >>>>> Hi Kevin, >>>>> >>>>>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth >: >>>>>> >>>>>> That seems surprising since javafx.swt is not part of the JDK runtime image. I suspect that this is either an issue with jdeps itself or with how you are running jdeps. What was the command line you were using? >>>>> >>>>> I used: for i in */bin; do /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps -jdkinternals $i; done >> deps.txt >>>> >>>> That doesn't show how javafx-swt.jar is being referenced. javafx-swt.jar is delivered with the JDK, but is not loaded by default (or at least it should not be). >>> >>> Is there a way to find out? Do I have to provide additional options? Using jdk-9-ea109 the same command line did not result in javafx.swt being regarded as JDK internal. >>> >>>> >>>> >>>>>> As for your second question, the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer, but that still needs to be tested. We currently do all of our own testing by adding it as an automatic module on the module path as follows: >>>>>> >>>>>> $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules javafx.swt my.pkg.MyApp >>>>> >>>>> I see. Is there a concrete schedule? >>>> >>>> If you mean is there a concrete schedule for the Eclipse folks to do the work to verify that javafx.swt can be loaded in a layer, I can't comment on that, since this work is outside the scope of the JDK. Perhaps Tom Schindl can respond? >>> >>> I thought the plan was to turn javafx.swt into an explicit module and not an (implicit) automatic one, and I was referring to when this was finalized. Seems I got that wrong. >>> >>>> >>>> ? Kevin >>> >>> Best Regards, >>> Alexander >>> >>>> >>>>> >>>>>> >>>>>> ? Kevin >>>>> >>>>> Best Regards, >>>>> Alexander >>>>> >>>>>> >>>>>> >>>>>> Alexander Nyssen wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base and was astonished to see that all dependencies to javafx.embed.swt.* now seem to be regarded as JDK internal API. I assume this is just a temporal inconsistency. Therefore, let me ask when it is planned to transfer the javafx.swt module into a proper named JIGSAW module to resolve this. The Eclipse community relies on using the javafx.swt module in an OSGi environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would certainly be good if conformance tests could be started as early as possible. >>>>>>> >>>>>>> Best Regards, >>>>>>> Alexander >> >> >> -- >> Thomas Schindl, CTO >> BestSolution.at EDV Systemhaus GmbH >> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck >> http://www.bestsolution.at/ >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > From alexander at nyssen.org Wed Sep 14 08:08:02 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Wed, 14 Sep 2016 10:08:02 +0200 Subject: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135 In-Reply-To: References: <57D80250.3010406@oracle.com> <7A8E45F9-D8E2-4D37-86E1-44C2BB755CA4@nyssen.org> <57D80D77.7020109@oracle.com> <6c771229-9986-bca9-86fb-27e67f3e47e5@bestsolution.at> Message-ID: <5B3BF754-D64E-4D45-825E-A40A2EB69596@nyssen.org> Tom, just to make that explicit: you expected it to be shipped as an explicit and not as an automatic, implicit module by the OpenJFX team? Regards, Alexander > Am 14.09.2016 um 09:26 schrieb Tom Schindl : > > I expect javafx.swt to be shipped with the jdk/jre - i can not repackage and ship openjfx code from eclipse.org > > Tom > > Von meinem iPhone gesendet > >> Am 14.09.2016 um 08:51 schrieb Alexander Nyssen : >> >> Hi Tom, Kevin, >> >> I have to admit that - now - I am somehow confused. At first glance "the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer? and "it will not be an autom[at]ic-module but a named one loaded in a [?] layer? sounds like a contradiction. Tom, did you plan to ?repackage? the automatic (and thus implicitly defined) javafx.swt module as an explicit one as part of e(fx)clipse, or did you - like me - expect that javafx.swt will yet be turned into an explicit module by the OpenJFX team? >> >> Best Regards, >> Alexander >> >>> Am 14.09.2016 um 00:51 schrieb Tom Schindl : >>> >>> Hi, >>> >>> javafx.swt can never be a module loaded by default but we need to >>> construct a new layer who has the SWT-Bundle-Classloader as the parent. >>> >>> So no it will not be an automic-module but a named one loaded in a >>> secondary layer (eg by the efxclipse OSGi-Adapter-Hook) - at least this >>> is the theory. I didn't have time yet to follow this path yet. >>> >>> Tom >>> >>>> On 13.09.16 20:31, Alexander Nyssen wrote: >>>> Hi Kevin, >>>> >>>>> Am 13.09.2016 um 16:30 schrieb Kevin Rushforth : >>>>> >>>>> >>>>> >>>>> Alexander Nyssen wrote: >>>>>> Hi Kevin, >>>>>> >>>>>>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth >: >>>>>>> >>>>>>> That seems surprising since javafx.swt is not part of the JDK runtime image. I suspect that this is either an issue with jdeps itself or with how you are running jdeps. What was the command line you were using? >>>>>> >>>>>> I used: for i in */bin; do /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps -jdkinternals $i; done >> deps.txt >>>>> >>>>> That doesn't show how javafx-swt.jar is being referenced. javafx-swt.jar is delivered with the JDK, but is not loaded by default (or at least it should not be). >>>> >>>> Is there a way to find out? Do I have to provide additional options? Using jdk-9-ea109 the same command line did not result in javafx.swt being regarded as JDK internal. >>>> >>>>> >>>>> >>>>>>> As for your second question, the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer, but that still needs to be tested. We currently do all of our own testing by adding it as an automatic module on the module path as follows: >>>>>>> >>>>>>> $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules javafx.swt my.pkg.MyApp >>>>>> >>>>>> I see. Is there a concrete schedule? >>>>> >>>>> If you mean is there a concrete schedule for the Eclipse folks to do the work to verify that javafx.swt can be loaded in a layer, I can't comment on that, since this work is outside the scope of the JDK. Perhaps Tom Schindl can respond? >>>> >>>> I thought the plan was to turn javafx.swt into an explicit module and not an (implicit) automatic one, and I was referring to when this was finalized. Seems I got that wrong. >>>> >>>>> >>>>> ? Kevin >>>> >>>> Best Regards, >>>> Alexander >>>> >>>>> >>>>>> >>>>>>> >>>>>>> ? Kevin >>>>>> >>>>>> Best Regards, >>>>>> Alexander >>>>>> >>>>>>> >>>>>>> >>>>>>> Alexander Nyssen wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base and was astonished to see that all dependencies to javafx.embed.swt.* now seem to be regarded as JDK internal API. I assume this is just a temporal inconsistency. Therefore, let me ask when it is planned to transfer the javafx.swt module into a proper named JIGSAW module to resolve this. The Eclipse community relies on using the javafx.swt module in an OSGi environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would certainly be good if conformance tests could be started as early as possible. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Alexander >>> >>> >>> -- >>> Thomas Schindl, CTO >>> BestSolution.at EDV Systemhaus GmbH >>> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck >>> http://www.bestsolution.at/ >>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck >> > From vadim.pakhnushev at oracle.com Wed Sep 14 11:52:37 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 14 Sep 2016 14:52:37 +0300 Subject: [9] Review request for 8144258: Ensemble Advanced Media sample hangs after going full screen Message-ID: <6e427bb5-258e-08bc-39c6-6a464909e460@oracle.com> Hi David, Alexander, Please review this fix: https://bugs.openjdk.java.net/browse/JDK-8144258 http://cr.openjdk.java.net/~vadim/8144258/webrev.00/ Thanks, Vadim From kevin.rushforth at oracle.com Wed Sep 14 20:38:52 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Sep 2016 13:38:52 -0700 Subject: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135 In-Reply-To: <5B3BF754-D64E-4D45-825E-A40A2EB69596@nyssen.org> References: <57D80250.3010406@oracle.com> <7A8E45F9-D8E2-4D37-86E1-44C2BB755CA4@nyssen.org> <57D80D77.7020109@oracle.com> <6c771229-9986-bca9-86fb-27e67f3e47e5@bestsolution.at> <5B3BF754-D64E-4D45-825E-A40A2EB69596@nyssen.org> Message-ID: <57D9B55C.1080300@oracle.com> I can't speak to what Tom is expecting, but javafx-swt.jar will not be an explicit module. It will be delivered as an automatic (implicit) module. This is required because swt.jar is not modularized. The proposed approach of loading this into a Layer defined by the OSGi-Adapter-Hook should work without the javafx-swt.jar file needing to have a module-info.class file (at least the Jigsaw team believes that it will work). This still needs to be tested. -- Kevin Alexander Nyssen wrote: > Tom, > > just to make that explicit: you expected it to be shipped as an explicit and not as an automatic, implicit module by the OpenJFX team? > > Regards, > Alexander > > >> Am 14.09.2016 um 09:26 schrieb Tom Schindl : >> >> I expect javafx.swt to be shipped with the jdk/jre - i can not repackage and ship openjfx code from eclipse.org >> >> Tom >> >> Von meinem iPhone gesendet >> >> >>> Am 14.09.2016 um 08:51 schrieb Alexander Nyssen : >>> >>> Hi Tom, Kevin, >>> >>> I have to admit that - now - I am somehow confused. At first glance "the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer? and "it will not be an autom[at]ic-module but a named one loaded in a [?] layer? sounds like a contradiction. Tom, did you plan to ?repackage? the automatic (and thus implicitly defined) javafx.swt module as an explicit one as part of e(fx)clipse, or did you - like me - expect that javafx.swt will yet be turned into an explicit module by the OpenJFX team? >>> >>> Best Regards, >>> Alexander >>> >>> >>>> Am 14.09.2016 um 00:51 schrieb Tom Schindl : >>>> >>>> Hi, >>>> >>>> javafx.swt can never be a module loaded by default but we need to >>>> construct a new layer who has the SWT-Bundle-Classloader as the parent. >>>> >>>> So no it will not be an automic-module but a named one loaded in a >>>> secondary layer (eg by the efxclipse OSGi-Adapter-Hook) - at least this >>>> is the theory. I didn't have time yet to follow this path yet. >>>> >>>> Tom >>>> >>>> >>>>> On 13.09.16 20:31, Alexander Nyssen wrote: >>>>> Hi Kevin, >>>>> >>>>> >>>>>> Am 13.09.2016 um 16:30 schrieb Kevin Rushforth : >>>>>> >>>>>> >>>>>> >>>>>> Alexander Nyssen wrote: >>>>>> >>>>>>> Hi Kevin, >>>>>>> >>>>>>> >>>>>>>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth >: >>>>>>>> >>>>>>>> That seems surprising since javafx.swt is not part of the JDK runtime image. I suspect that this is either an issue with jdeps itself or with how you are running jdeps. What was the command line you were using? >>>>>>>> >>>>>>> I used: for i in */bin; do /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps -jdkinternals $i; done >> deps.txt >>>>>>> >>>>>> That doesn't show how javafx-swt.jar is being referenced. javafx-swt.jar is delivered with the JDK, but is not loaded by default (or at least it should not be). >>>>>> >>>>> Is there a way to find out? Do I have to provide additional options? Using jdk-9-ea109 the same command line did not result in javafx.swt being regarded as JDK internal. >>>>> >>>>> >>>>>> >>>>>>>> As for your second question, the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer, but that still needs to be tested. We currently do all of our own testing by adding it as an automatic module on the module path as follows: >>>>>>>> >>>>>>>> $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules javafx.swt my.pkg.MyApp >>>>>>>> >>>>>>> I see. Is there a concrete schedule? >>>>>>> >>>>>> If you mean is there a concrete schedule for the Eclipse folks to do the work to verify that javafx.swt can be loaded in a layer, I can't comment on that, since this work is outside the scope of the JDK. Perhaps Tom Schindl can respond? >>>>>> >>>>> I thought the plan was to turn javafx.swt into an explicit module and not an (implicit) automatic one, and I was referring to when this was finalized. Seems I got that wrong. >>>>> >>>>> >>>>>> ? Kevin >>>>>> >>>>> Best Regards, >>>>> Alexander >>>>> >>>>> >>>>>>>> ? Kevin >>>>>>>> >>>>>>> Best Regards, >>>>>>> Alexander >>>>>>> >>>>>>> >>>>>>>> Alexander Nyssen wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base and was astonished to see that all dependencies to javafx.embed.swt.* now seem to be regarded as JDK internal API. I assume this is just a temporal inconsistency. Therefore, let me ask when it is planned to transfer the javafx.swt module into a proper named JIGSAW module to resolve this. The Eclipse community relies on using the javafx.swt module in an OSGi environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would certainly be good if conformance tests could be started as early as possible. >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Alexander >>>>>>>>> >>>> -- >>>> Thomas Schindl, CTO >>>> BestSolution.at EDV Systemhaus GmbH >>>> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck >>>> http://www.bestsolution.at/ >>>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck >>>> > > From alexander at nyssen.org Thu Sep 15 05:16:04 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Thu, 15 Sep 2016 07:16:04 +0200 Subject: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135 In-Reply-To: <57D9B55C.1080300@oracle.com> References: <57D80250.3010406@oracle.com> <7A8E45F9-D8E2-4D37-86E1-44C2BB755CA4@nyssen.org> <57D80D77.7020109@oracle.com> <6c771229-9986-bca9-86fb-27e67f3e47e5@bestsolution.at> <5B3BF754-D64E-4D45-825E-A40A2EB69596@nyssen.org> <57D9B55C.1080300@oracle.com> Message-ID: <69993F2F-0D98-4DD6-8374-17D3A80D7827@nyssen.org> Hi Kevin, > Am 14.09.2016 um 22:38 schrieb Kevin Rushforth : > > I can't speak to what Tom is expecting, but javafx-swt.jar will not be an explicit module. It will be delivered as an automatic (implicit) module. This is required because swt.jar is not modularized. of course you can?t. Neither can I, but I thought it worth to ask explicitly here in order to unveil a potential misunderstanding. I personally thought the plan was to turn javafx-swt.jar into an explicit module and to have swt.jar as the automatic one, which is the reason I asked for a schedule. So thanks for clarifying this. > > The proposed approach of loading this into a Layer defined by the OSGi-Adapter-Hook should work without the javafx-swt.jar file needing to have a module-info.class file (at least the Jigsaw team believes that it will work). This still needs to be tested. If I can support this to some extent please let me know. We (that is the Eclipse Graphical Editing Framework project in this case) will basically be lost if this is not going to work, as we have committed ourselves to JavaFX and FXCanvas is our single ?bridge? back to the Eclipse Workbench/SWT world. > > ? Kevin Best Regards Alexander > > > Alexander Nyssen wrote: >> >> Tom, >> >> just to make that explicit: you expected it to be shipped as an explicit and not as an automatic, implicit module by the OpenJFX team? >> >> Regards, >> Alexander >> >> >>> Am 14.09.2016 um 09:26 schrieb Tom Schindl : >>> >>> I expect javafx.swt to be shipped with the jdk/jre - i can not repackage and ship openjfx code from eclipse.org >>> >>> Tom >>> >>> Von meinem iPhone gesendet >>> >>> >>>> Am 14.09.2016 um 08:51 schrieb Alexander Nyssen : >>>> >>>> Hi Tom, Kevin, >>>> >>>> I have to admit that - now - I am somehow confused. At first glance "the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer? and "it will not be an autom[at]ic-module but a named one loaded in a [?] layer? sounds like a contradiction. Tom, did you plan to ?repackage? the automatic (and thus implicitly defined) javafx.swt module as an explicit one as part of e(fx)clipse, or did you - like me - expect that javafx.swt will yet be turned into an explicit module by the OpenJFX team? >>>> >>>> Best Regards, >>>> Alexander >>>> >>>> >>>>> Am 14.09.2016 um 00:51 schrieb Tom Schindl : >>>>> >>>>> Hi, >>>>> >>>>> javafx.swt can never be a module loaded by default but we need to >>>>> construct a new layer who has the SWT-Bundle-Classloader as the parent. >>>>> >>>>> So no it will not be an automic-module but a named one loaded in a >>>>> secondary layer (eg by the efxclipse OSGi-Adapter-Hook) - at least this >>>>> is the theory. I didn't have time yet to follow this path yet. >>>>> >>>>> Tom >>>>> >>>>> >>>>>> On 13.09.16 20:31, Alexander Nyssen wrote: >>>>>> Hi Kevin, >>>>>> >>>>>> >>>>>>> Am 13.09.2016 um 16:30 schrieb Kevin Rushforth : >>>>>>> >>>>>>> >>>>>>> >>>>>>> Alexander Nyssen wrote: >>>>>>> >>>>>>>> Hi Kevin, >>>>>>>> >>>>>>>> >>>>>>>>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth >: >>>>>>>>> >>>>>>>>> That seems surprising since javafx.swt is not part of the JDK runtime image. I suspect that this is either an issue with jdeps itself or with how you are running jdeps. What was the command line you were using? >>>>>>>>> >>>>>>>> I used: for i in */bin; do /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps -jdkinternals $i; done >> deps.txt >>>>>>>> >>>>>>> That doesn't show how javafx-swt.jar is being referenced. javafx-swt.jar is delivered with the JDK, but is not loaded by default (or at least it should not be). >>>>>>> >>>>>> Is there a way to find out? Do I have to provide additional options? Using jdk-9-ea109 the same command line did not result in javafx.swt being regarded as JDK internal. >>>>>> >>>>>> >>>>>>> >>>>>>>>> As for your second question, the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer, but that still needs to be tested. We currently do all of our own testing by adding it as an automatic module on the module path as follows: >>>>>>>>> >>>>>>>>> $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules javafx.swt my.pkg.MyApp >>>>>>>>> >>>>>>>> I see. Is there a concrete schedule? >>>>>>>> >>>>>>> If you mean is there a concrete schedule for the Eclipse folks to do the work to verify that javafx.swt can be loaded in a layer, I can't comment on that, since this work is outside the scope of the JDK. Perhaps Tom Schindl can respond? >>>>>>> >>>>>> I thought the plan was to turn javafx.swt into an explicit module and not an (implicit) automatic one, and I was referring to when this was finalized. Seems I got that wrong. >>>>>> >>>>>> >>>>>>> ? Kevin >>>>>>> >>>>>> Best Regards, >>>>>> Alexander >>>>>> >>>>>> >>>>>>>>> ? Kevin >>>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Alexander >>>>>>>> >>>>>>>> >>>>>>>>> Alexander Nyssen wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base and was astonished to see that all dependencies to javafx.embed.swt.* now seem to be regarded as JDK internal API. I assume this is just a temporal inconsistency. Therefore, let me ask when it is planned to transfer the javafx.swt module into a proper named JIGSAW module to resolve this. The Eclipse community relies on using the javafx.swt module in an OSGi environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428 ), and it would certainly be good if conformance tests could be started as early as possible. >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> Alexander >>>>>>>>>> >>>>> -- >>>>> Thomas Schindl, CTO >>>>> BestSolution.at EDV Systemhaus GmbH >>>>> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck >>>>> http://www.bestsolution.at/ >>>>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck >>>>> >> >> From alexander at nyssen.org Fri Sep 16 05:47:04 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Fri, 16 Sep 2016 07:47:04 +0200 Subject: Review request [2] for 8143596: FXCanvas does not forward touch gestures to embedded scene References: Message-ID: <983CE1A2-8050-49F7-8D8A-08DA33365984@nyssen.org> Hallo Alexander Z., Kevin, I have adjusted the patch for JDK-8143596 to reflect the initial review finding of Alexander Z. and to fix some whitespace issues: https://bugs.openjdk.java.net/browse/JDK-8143596 http://cr.openjdk.java.net/~anyssen/8143596/webrev.01/ Best Regards Alexander > Anfang der weitergeleiteten Nachricht: > > Von: Alexander Ny?en > Betreff: Review request for 8143596: FXCanvas does not forward touch gestures to embedded scene > Datum: 10. September 2016 um 13:58:54 MESZ > An: openjfx-dev at openjdk.java.net > > Hi Alexander Z., Kevin, > > I have adopted my latest patch for JDK-8143596 (uploaded yesterday as patch file) to the latest tip and created a webrev for it (the uploaded patch is therefore now obsolete): > > https://bugs.openjdk.java.net/browse/JDK-8143596 > http://cr.openjdk.java.net/~anyssen/8143596/webrev.00/ > > Best Regards, > Alexander From alexander at nyssen.org Fri Sep 16 09:03:06 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Fri, 16 Sep 2016 11:03:06 +0200 Subject: Necessity of com.sun.javafx.embed.AbstractEvents Message-ID: <6E46B049-3B8B-4DF2-8692-F559866753DB@nyssen.org> Hi Alexander Z., Kevin, while working on JDK-8143596 (FXCanvas does not forward touch gestures to embedded scene) I came across some ?smell? that I would like to discuss. That is, the information about events that is exchanged between JFXPanel/FXCanvas and the EmbeddedScene/EmbeddedStage is currently encoded via constants of com.sun.javafx.embed.AbstractEvents. That is, FXCanvas and JFXPanel map SWT and AWT event information to constants in AbstractEvents, which are finally mapped to a JavaFX representations within EmbeddedScene. Without knowing the motivation behind this indirection, and without having tried it in detail yet, for me it seems as if AbstractEvents was superfluous and JavaFX representations could directly be used to transfer this information instead. In case of EmbeddedSceneInterface#inputMethodEvent() for instance, AbstractEvents was already bypassed, as here EventType is used as a parameter (instead of an AbstractEvents constant). Also, the modifier constants defined within AbstractEvents are only used in case of key events, while for mouse (and now gesture events) boolean parameters are used to transport this information (which could also be done in case of key events). What do you think? In case you share my assessment I would propose to file a separate issue for this, and I could offer to investigate it after JDK-8143596 has been resolved (I would not want to mingle it). Best Regards, Alexander From vadim.pakhnushev at oracle.com Fri Sep 16 15:12:11 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 16 Sep 2016 18:12:11 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <55a3ebfe-67d6-4a6b-3fc3-1f19681a2acb@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 kevin.rushforth at oracle.com Fri Sep 16 15:16:03 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 16 Sep 2016 08:16:03 -0700 Subject: In(Sanity) Testing Mondays In-Reply-To: <55a3ebfe-67d6-4a6b-3fc3-1f19681a2acb@oracle.com> References: <55a3ebfe-67d6-4a6b-3fc3-1f19681a2acb@oracle.com> Message-ID: <57DC0CB3.4050506@oracle.com> As next week is JavaOne, I won't be online during the day on Monday. Unless there is an unexpected show-stopper bug, please consider the repo to be "unlocked" at 1pm PT on Monday. -- Kevin 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 chris.bensen at oracle.com Fri Sep 16 22:01:56 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Fri, 16 Sep 2016 15:01:56 -0700 Subject: [9] Review Request: Message-ID: <4A6DE9E8-AC9D-4ADE-84D9-A83BE89A769F@oracle.com> Kevin, Add modules and limit modules are broken in some situations. JIRA: https://bugs.openjdk.java.net/browse/JDK-8166172 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8166172/webrev.00/ Chris From artem.ananiev at oracle.com Fri Sep 16 22:12:57 2016 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 16 Sep 2016 15:12:57 -0700 Subject: Necessity of com.sun.javafx.embed.AbstractEvents In-Reply-To: <6E46B049-3B8B-4DF2-8692-F559866753DB@nyssen.org> References: <6E46B049-3B8B-4DF2-8692-F559866753DB@nyssen.org> Message-ID: <57DC6E69.2090903@oracle.com> Hi, Alexander, I believe I introduced that extra abstraction layer for FX/Swing events long time ago. At that time, we thought we might eventually want to embed different components than just JavaFX, but it doesn't make any sense these days. JFXPanel and FXCanvas contain a lot of FX specific code, they can't be used to embed anything than FX. I agree that AbstractEvents is redundant and can be replaced by FX events. BTW, SwingNode (which is opposite to JFXPanel, it's to embed Swing into FX) doesn't use AbstractEvents, but operates directly with FX events. Thanks, Artem On 9/16/16, 2:03 AM, Alexander Nyssen wrote: > Hi Alexander Z., Kevin, > > while working on JDK-8143596 (FXCanvas does not forward touch > gestures to embedded scene) I came across some ?smell? that I would > like to discuss. That is, the information about events that is > exchanged between JFXPanel/FXCanvas and the > EmbeddedScene/EmbeddedStage is currently encoded via constants of > com.sun.javafx.embed.AbstractEvents. That is, FXCanvas and JFXPanel > map SWT and AWT event information to constants in AbstractEvents, > which are finally mapped to a JavaFX representations within > EmbeddedScene. > > Without knowing the motivation behind this indirection, and without > having tried it in detail yet, for me it seems as if AbstractEvents > was superfluous and JavaFX representations could directly be used to > transfer this information instead. In case of > EmbeddedSceneInterface#inputMethodEvent() for instance, > AbstractEvents was already bypassed, as here EventType is used as a > parameter (instead of an AbstractEvents constant). Also, the modifier > constants defined within AbstractEvents are only used in case of key > events, while for mouse (and now gesture events) boolean parameters > are used to transport this information (which could also be done in > case of key events). > > What do you think? In case you share my assessment I would propose to > file a separate issue for this, and I could offer to investigate it > after JDK-8143596 has been resolved (I would not want to mingle it). > > Best Regards, > Alexander From David.Hill at Oracle.com Sat Sep 17 02:46:40 2016 From: David.Hill at Oracle.com (David Hill) Date: Fri, 16 Sep 2016 22:46:40 -0400 Subject: review: @native annotations Message-ID: <57DCAE90.2050607@Oracle.com> Kevin, Guru, The javac tool now provides the ability to generate native headers as needed. This removes the need to run the javah tool as a separate step in the build pipeline. The feature is enabled in javac by using the new -h option, which is used to specify a directory in which the header files should be written. Header files will be generated for any class which has either native methods, or constant fields annotated with a new annotation of type java.lang.annotation.Native. (Since JDK 1.8) This should ease the transition to a modular build by allowing us to remove one extra javah step. These two change sets add @Native annotations to classes that we need in native that are not currently being generated automatically with javac -h. In two cases, I removed "empty" header includes (the javah generated header does not have any meaningful content). https://bugs.openjdk.java.net/browse/JDK-8166230 http://cr.openjdk.java.net/~ddhill/8166230 graphics, media https://bugs.openjdk.java.net/browse/JDK-8166231 http://cr.openjdk.java.net/~ddhill/8166231 webkit Note that the actual conversion to using the javac -h step will happen at a later date. These changesets just allow us to get ready for that future, and reduce the risk of merge conflicts later. -- 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 alexander at nyssen.org Sun Sep 18 10:04:04 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Sun, 18 Sep 2016 12:04:04 +0200 Subject: Necessity of com.sun.javafx.embed.AbstractEvents In-Reply-To: <57DC6E69.2090903@oracle.com> References: <6E46B049-3B8B-4DF2-8692-F559866753DB@nyssen.org> <57DC6E69.2090903@oracle.com> Message-ID: <6BF4167F-0D34-4A02-AFE9-587C40714628@nyssen.org> Hi Artem, > Am 17.09.2016 um 00:12 schrieb Artem Ananiev : > > Hi, Alexander, > > I believe I introduced that extra abstraction layer for FX/Swing events long time ago. At that time, we thought we might eventually want to embed different components than just JavaFX, but it doesn't make any sense these days. JFXPanel and FXCanvas contain a lot of FX specific code, they can't be used to embed anything than FX. I agree that AbstractEvents is redundant and can be replaced by FX events. thanks for clarifying this. I have raised JDK-8166242 (Removal of com.sun.javafx.embed.AbstractEvents) to keep track of the issue. > > BTW, SwingNode (which is opposite to JFXPanel, it's to embed Swing into FX) doesn't use AbstractEvents, but operates directly with FX events. That sounds like an additional argument for the removal of AbstractEvents. Thanks for having pointed that out. Just to mention it (in case somebody searches for such functionality), within GEF we have introduced something comparable for embedding SWT controls (in the context of an FXCanvas). We called it FXControlAdapter (https://github.com/eclipse/gef/blob/master/org.eclipse.gef.fx.swt/src/org/eclipse/gef/fx/swt/controls/FXControlAdapter.java). It?s still pretty basic, but might be a good starting point. > > Thanks, > > Artem Best Regards, Alexander > > On 9/16/16, 2:03 AM, Alexander Nyssen wrote: >> Hi Alexander Z., Kevin, >> >> while working on JDK-8143596 (FXCanvas does not forward touch >> gestures to embedded scene) I came across some ?smell? that I would >> like to discuss. That is, the information about events that is >> exchanged between JFXPanel/FXCanvas and the >> EmbeddedScene/EmbeddedStage is currently encoded via constants of >> com.sun.javafx.embed.AbstractEvents. That is, FXCanvas and JFXPanel >> map SWT and AWT event information to constants in AbstractEvents, >> which are finally mapped to a JavaFX representations within >> EmbeddedScene. >> >> Without knowing the motivation behind this indirection, and without >> having tried it in detail yet, for me it seems as if AbstractEvents >> was superfluous and JavaFX representations could directly be used to >> transfer this information instead. In case of >> EmbeddedSceneInterface#inputMethodEvent() for instance, >> AbstractEvents was already bypassed, as here EventType is used as a >> parameter (instead of an AbstractEvents constant). Also, the modifier >> constants defined within AbstractEvents are only used in case of key >> events, while for mouse (and now gesture events) boolean parameters >> are used to transport this information (which could also be done in >> case of key events). >> >> What do you think? In case you share my assessment I would propose to >> file a separate issue for this, and I could offer to investigate it >> after JDK-8143596 has been resolved (I would not want to mingle it). >> >> Best Regards, > >> Alexander From guru.hb at oracle.com Mon Sep 19 22:15:10 2016 From: guru.hb at oracle.com (Guru Hb) Date: Tue, 20 Sep 2016 03:45:10 +0530 Subject: [9] Review request for 8165853: Loading "https://www.windyty.com" with JavaFX WebView crashes JVM. Message-ID: <83eee2dd-086c-aa6f-d968-754c13b57174@oracle.com> Hi Kevin, Arun & Murali, Please review the fix for (RC and fix updated in JBS) JBS : https://bugs.openjdk.java.net/browse/JDK-8165853 Webrev : http://cr.openjdk.java.net/~ghb/8165853/webrev.00/index.html Thanks, Guru From sproket at videotron.ca Mon Sep 19 23:01:49 2016 From: sproket at videotron.ca (Dan Howard) Date: Mon, 19 Sep 2016 19:01:49 -0400 Subject: [9] Review request for 8165853: Loading "https://www.windyty.com" with JavaFX WebView crashes JVM. In-Reply-To: References: Message-ID: I can't even right-click view source. Is this Flash or something? On 9/19/2016 6:15 PM, Guru Hb wrote: > Hi Kevin, Arun & Murali, > > Please review the fix for (RC and fix updated in JBS) > JBS : https://bugs.openjdk.java.net/browse/JDK-8165853 > Webrev : http://cr.openjdk.java.net/~ghb/8165853/webrev.00/index.html > > Thanks, > Guru > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From guru.hb at oracle.com Tue Sep 20 03:32:03 2016 From: guru.hb at oracle.com (Guru Hb) Date: Tue, 20 Sep 2016 09:02:03 +0530 Subject: [9] Review request for 8165853: Loading "https://www.windyty.com" with JavaFX WebView crashes JVM. In-Reply-To: References: Message-ID: <3682e4d2-0e06-e73d-fcc1-8cc8ef05af86@oracle.com> Its canvas. We can view source from Chrome / Firefox. a. Shortcut keys 'Ctrl + U' (win), 'CMD + Option + U' in chrome (there should be similar in Firefox as well) . b. Right click on Non canvas element (Windy logo which is at top center of the webpage , or 'Overlay' Bottom Right). b. Launch dev tool before launching windyty.com and use the debugger tabs. -Guru On 20/9/16 4:31 AM, Dan Howard wrote: > I can't even right-click view source. Is this Flash or something? > > > On 9/19/2016 6:15 PM, Guru Hb wrote: >> Hi Kevin, Arun & Murali, >> >> Please review the fix for (RC and fix updated in JBS) >> JBS : https://bugs.openjdk.java.net/browse/JDK-8165853 >> Webrev : http://cr.openjdk.java.net/~ghb/8165853/webrev.00/index.html >> >> Thanks, >> Guru >> > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > From tai.hu at veroanalytics.com Tue Sep 20 22:56:23 2016 From: tai.hu at veroanalytics.com (Tai Hu) Date: Tue, 20 Sep 2016 18:56:23 -0400 Subject: How to Read JavaFX Pulse Log Message Message-ID: <60431EDA-C825-4C54-95B0-9190E35FC4F5@veroanalytics.com> Hi, Is there any document or tutorial about how to interpret JavaFX Pulse log message? I turned on Pulse Logger for my application and see the log message as follows, PULSE: 575 [143ms:20ms] T12 (-143 +143ms): Layout Pass T12 (0 +0ms): CSS Pass T12 (1 +0ms): Layout Pass T12 (1 +0ms): Update bounds T12 (1 +0ms): Waiting for previous rendering T12 (1 +0ms): Copy state to render graph T12 (2 +0ms): CSS Pass T12 (3 +1ms): Layout Pass T12 (4 +0ms): Update bounds T12 (5 +0ms): Waiting for previous rendering T12 (5 +2ms): Copy state to render graph T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 (8 +5ms): Painting T9 (13 +1ms): Presenting T9 (14 +0ms): Dirty Opts Computed T9 : Slow shape path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 : Slow background path for null T9 (14 +5ms): Painting T9 (19 +0ms): Presenting Counters: Cached region shape image used: 3 NGRegion renderBackgroundShape slow path: 1 NGRegion renderBackgrounds slow path: 26 Nodes rendered: 212 Nodes visited during render: 227 There is a lot of "Slow background path for null?. Is that indicating a problem? If so, how can I fix it? Thanks, Tai From alexander at nyssen.org Wed Sep 21 06:58:39 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Wed, 21 Sep 2016 08:58:39 +0200 Subject: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac Message-ID: Hi all, having updated 9-dev to the latest tip, the gradle build now fails on my Mac with the following errors. Updating JIGSAW home to ea136 did not resolve the problems. Any ideas? Best Regards, Alexander :graphics:compilePrismCompilers /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:26: error: package com.sun.scenario.effect.compiler does not exist import com.sun.scenario.effect.compiler.JSLC; ^ /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:27: error: package com.sun.scenario.effect.compiler.JSLC does not exist import com.sun.scenario.effect.compiler.JSLC.JSLCInfo; ^ /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:28: error: package com.sun.scenario.effect.compiler does not exist import com.sun.scenario.effect.compiler.JSLParser; ^ /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:29: error: package com.sun.scenario.effect.compiler.model does not exist import com.sun.scenario.effect.compiler.model.BaseType; ^ /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:30: error: package com.sun.scenario.effect.compiler.model does not exist import com.sun.scenario.effect.compiler.model.Qualifier; ^ /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:31: error: package com.sun.scenario.effect.compiler.model does not exist import com.sun.scenario.effect.compiler.model.Variable; ^ /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:32: error: package com.sun.scenario.effect.compiler.tree does not exist import com.sun.scenario.effect.compiler.tree.ProgramUnit; ^ /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:33: error: package com.sun.scenario.effect.compiler.tree does not exist import com.sun.scenario.effect.compiler.tree.TreeScanner; ^ /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:34: error: package com.sun.scenario.effect.compiler.tree does not exist import com.sun.scenario.effect.compiler.tree.VariableExpr; ^ /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:205: error: cannot find symbol private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, MaskType maskType) ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:211: error: cannot find symbol private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, AlphaMaskType maskType) ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:217: error: cannot find symbol private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, String maskName, ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:228: error: cannot find symbol private static ShaderInfo getPaintInfo(JSLCInfo jslcinfo, String paintName, ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:239: error: cannot find symbol private static void compileColorPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:248: error: cannot find symbol private static void compileGradientPaint(JSLCInfo jslcinfo, ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:272: error: cannot find symbol private static void compileAlphaGradientPaint(JSLCInfo jslcinfo, ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:285: error: cannot find symbol private static void compilePatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:295: error: cannot find symbol private static void compileAlphaPatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:305: error: cannot find symbol private static void compileSolidTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:314: error: cannot find symbol private static void compileMaskTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:324: error: cannot find symbol private static void compileLCDShader(JSLCInfo jslcinfo, String suffix, boolean alphaTest) ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:408: error: cannot find symbol private static void compileShader(JSLCInfo jslcinfo, ShaderInfo info) ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:414: error: cannot find symbol private static void compileShader(JSLCInfo jslcinfo, ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:454: error: cannot find symbol private static String readShaderFile(JSLCInfo jslcinfo, String name) ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:460: error: cannot find symbol private static long shaderFileTime(JSLCInfo jslcinfo, String name) { ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:507: error: cannot find symbol class PrismLoaderBackend extends TreeScanner { ^ symbol: class TreeScanner /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:508: error: cannot find symbol private JSLParser parser; ^ symbol: class JSLParser location: class PrismLoaderBackend /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { ^ symbol: class JSLParser location: class PrismLoaderBackend /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { ^ symbol: class ProgramUnit location: class PrismLoaderBackend /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:549: error: cannot find symbol public void visitVariableExpr(VariableExpr e) { ^ symbol: class VariableExpr location: class PrismLoaderBackend /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: package JSLC does not exist JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); ^ /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: cannot find symbol JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); ^ symbol: variable JSLC location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:422: error: cannot find symbol if (JSLC.outOfDate(outFile, sourcetime)) { ^ symbol: variable JSLC location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:423: error: cannot find symbol if (pinfo == null) pinfo = JSLC.getParserInfo(source); ^ symbol: variable JSLC location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:425: error: cannot find symbol JSLC.write(loaderBackend.getGlueCode(name), outFile); ^ symbol: variable JSLC location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol JSLCInfo jslcinfo = new JSLCInfo(); ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol JSLCInfo jslcinfo = new JSLCInfo(); ^ symbol: class JSLCInfo location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:467: error: cannot find symbol nameMap.put(JSLC.OUT_D3D, "prism-d3d/build/gensrc/{pkg}/d3d/hlsl/{name}.hlsl"); ^ symbol: variable JSLC location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:468: error: cannot find symbol nameMap.put(JSLC.OUT_ES2, "prism-es2/build/gensrc/{pkg}/es2/glsl/{name}.frag"); ^ symbol: variable JSLC location: class CompileJSL /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:518: error: cannot find symbol Reader template = new InputStreamReader(getClass().getResourceAsStream(type + "Glue.stg")); ^ symbol: method getClass() location: class PrismLoaderBackend /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:524: error: cannot find symbol Map vars = parser.getSymbolTable().getGlobalVariables(); ^ symbol: class Variable location: class PrismLoaderBackend /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:528: error: cannot find symbol for (Variable v : vars.values()) { ^ symbol: class Variable location: class PrismLoaderBackend /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:529: error: cannot find symbol if (v.getQualifier() == Qualifier.PARAM) { ^ symbol: variable Qualifier location: class PrismLoaderBackend /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:531: error: cannot find symbol if (v.getType().getBaseType() == BaseType.SAMPLER) { ^ symbol: variable BaseType location: class PrismLoaderBackend /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:548: error: method does not override or implement a method from a supertype @Override ^ 45 errors :graphics:compilePrismCompilers FAILED From vadim.pakhnushev at oracle.com Wed Sep 21 08:02:56 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 21 Sep 2016 11:02:56 +0300 Subject: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac In-Reply-To: References: Message-ID: <28560249-0a59-1201-61c1-886553b3f8cf@oracle.com> Hi Alexander, This happens because in the https://bugs.openjdk.java.net/browse/JDK-8165809 these parts of build were reworked. You could start with gradle cleanAll, if it doesn't help, then rm -r build buildSrc/build should help. Thanks, Vadim On 21.09.2016 9:58, Alexander Nyssen wrote: > Hi all, > > having updated 9-dev to the latest tip, the gradle build now fails on my Mac with the following errors. Updating JIGSAW home to ea136 did not resolve the problems. Any ideas? > > Best Regards, > Alexander > > :graphics:compilePrismCompilers > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:26: error: package com.sun.scenario.effect.compiler does not exist > import com.sun.scenario.effect.compiler.JSLC; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:27: error: package com.sun.scenario.effect.compiler.JSLC does not exist > import com.sun.scenario.effect.compiler.JSLC.JSLCInfo; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:28: error: package com.sun.scenario.effect.compiler does not exist > import com.sun.scenario.effect.compiler.JSLParser; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:29: error: package com.sun.scenario.effect.compiler.model does not exist > import com.sun.scenario.effect.compiler.model.BaseType; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:30: error: package com.sun.scenario.effect.compiler.model does not exist > import com.sun.scenario.effect.compiler.model.Qualifier; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:31: error: package com.sun.scenario.effect.compiler.model does not exist > import com.sun.scenario.effect.compiler.model.Variable; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:32: error: package com.sun.scenario.effect.compiler.tree does not exist > import com.sun.scenario.effect.compiler.tree.ProgramUnit; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:33: error: package com.sun.scenario.effect.compiler.tree does not exist > import com.sun.scenario.effect.compiler.tree.TreeScanner; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:34: error: package com.sun.scenario.effect.compiler.tree does not exist > import com.sun.scenario.effect.compiler.tree.VariableExpr; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:205: error: cannot find symbol > private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, MaskType maskType) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:211: error: cannot find symbol > private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, AlphaMaskType maskType) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:217: error: cannot find symbol > private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, String maskName, > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:228: error: cannot find symbol > private static ShaderInfo getPaintInfo(JSLCInfo jslcinfo, String paintName, > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:239: error: cannot find symbol > private static void compileColorPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:248: error: cannot find symbol > private static void compileGradientPaint(JSLCInfo jslcinfo, > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:272: error: cannot find symbol > private static void compileAlphaGradientPaint(JSLCInfo jslcinfo, > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:285: error: cannot find symbol > private static void compilePatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:295: error: cannot find symbol > private static void compileAlphaPatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:305: error: cannot find symbol > private static void compileSolidTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:314: error: cannot find symbol > private static void compileMaskTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:324: error: cannot find symbol > private static void compileLCDShader(JSLCInfo jslcinfo, String suffix, boolean alphaTest) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:408: error: cannot find symbol > private static void compileShader(JSLCInfo jslcinfo, ShaderInfo info) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:414: error: cannot find symbol > private static void compileShader(JSLCInfo jslcinfo, > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:454: error: cannot find symbol > private static String readShaderFile(JSLCInfo jslcinfo, String name) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:460: error: cannot find symbol > private static long shaderFileTime(JSLCInfo jslcinfo, String name) { > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:507: error: cannot find symbol > class PrismLoaderBackend extends TreeScanner { > ^ > symbol: class TreeScanner > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:508: error: cannot find symbol > private JSLParser parser; > ^ > symbol: class JSLParser > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol > public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { > ^ > symbol: class JSLParser > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol > public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { > ^ > symbol: class ProgramUnit > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:549: error: cannot find symbol > public void visitVariableExpr(VariableExpr e) { > ^ > symbol: class VariableExpr > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: package JSLC does not exist > JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: cannot find symbol > JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); > ^ > symbol: variable JSLC > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:422: error: cannot find symbol > if (JSLC.outOfDate(outFile, sourcetime)) { > ^ > symbol: variable JSLC > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:423: error: cannot find symbol > if (pinfo == null) pinfo = JSLC.getParserInfo(source); > ^ > symbol: variable JSLC > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:425: error: cannot find symbol > JSLC.write(loaderBackend.getGlueCode(name), outFile); > ^ > symbol: variable JSLC > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol > JSLCInfo jslcinfo = new JSLCInfo(); > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol > JSLCInfo jslcinfo = new JSLCInfo(); > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:467: error: cannot find symbol > nameMap.put(JSLC.OUT_D3D, "prism-d3d/build/gensrc/{pkg}/d3d/hlsl/{name}.hlsl"); > ^ > symbol: variable JSLC > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:468: error: cannot find symbol > nameMap.put(JSLC.OUT_ES2, "prism-es2/build/gensrc/{pkg}/es2/glsl/{name}.frag"); > ^ > symbol: variable JSLC > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:518: error: cannot find symbol > Reader template = new InputStreamReader(getClass().getResourceAsStream(type + "Glue.stg")); > ^ > symbol: method getClass() > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:524: error: cannot find symbol > Map vars = parser.getSymbolTable().getGlobalVariables(); > ^ > symbol: class Variable > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:528: error: cannot find symbol > for (Variable v : vars.values()) { > ^ > symbol: class Variable > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:529: error: cannot find symbol > if (v.getQualifier() == Qualifier.PARAM) { > ^ > symbol: variable Qualifier > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:531: error: cannot find symbol > if (v.getType().getBaseType() == BaseType.SAMPLER) { > ^ > symbol: variable BaseType > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:548: error: method does not override or implement a method from a supertype > @Override > ^ > 45 errors > :graphics:compilePrismCompilers FAILED > > From alexander at nyssen.org Wed Sep 21 08:23:21 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Wed, 21 Sep 2016 10:23:21 +0200 Subject: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac In-Reply-To: <28560249-0a59-1201-61c1-886553b3f8cf@oracle.com> References: <28560249-0a59-1201-61c1-886553b3f8cf@oracle.com> Message-ID: Hi Vadim, unfortunately both does not help, the problem persists. Best Regards, Alexander > Am 21.09.2016 um 10:02 schrieb Vadim Pakhnushev : > > Hi Alexander, > > This happens because in the https://bugs.openjdk.java.net/browse/JDK-8165809 these parts of build were reworked. > You could start with gradle cleanAll, if it doesn't help, then rm -r build buildSrc/build should help. > > Thanks, > Vadim > > On 21.09.2016 9:58, Alexander Nyssen wrote: >> Hi all, >> >> having updated 9-dev to the latest tip, the gradle build now fails on my Mac with the following errors. Updating JIGSAW home to ea136 did not resolve the problems. Any ideas? >> >> Best Regards, >> Alexander >> >> :graphics:compilePrismCompilers >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:26: error: package com.sun.scenario.effect.compiler does not exist >> import com.sun.scenario.effect.compiler.JSLC; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:27: error: package com.sun.scenario.effect.compiler.JSLC does not exist >> import com.sun.scenario.effect.compiler.JSLC.JSLCInfo; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:28: error: package com.sun.scenario.effect.compiler does not exist >> import com.sun.scenario.effect.compiler.JSLParser; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:29: error: package com.sun.scenario.effect.compiler.model does not exist >> import com.sun.scenario.effect.compiler.model.BaseType; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:30: error: package com.sun.scenario.effect.compiler.model does not exist >> import com.sun.scenario.effect.compiler.model.Qualifier; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:31: error: package com.sun.scenario.effect.compiler.model does not exist >> import com.sun.scenario.effect.compiler.model.Variable; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:32: error: package com.sun.scenario.effect.compiler.tree does not exist >> import com.sun.scenario.effect.compiler.tree.ProgramUnit; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:33: error: package com.sun.scenario.effect.compiler.tree does not exist >> import com.sun.scenario.effect.compiler.tree.TreeScanner; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:34: error: package com.sun.scenario.effect.compiler.tree does not exist >> import com.sun.scenario.effect.compiler.tree.VariableExpr; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:205: error: cannot find symbol >> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, MaskType maskType) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:211: error: cannot find symbol >> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, AlphaMaskType maskType) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:217: error: cannot find symbol >> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, String maskName, >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:228: error: cannot find symbol >> private static ShaderInfo getPaintInfo(JSLCInfo jslcinfo, String paintName, >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:239: error: cannot find symbol >> private static void compileColorPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:248: error: cannot find symbol >> private static void compileGradientPaint(JSLCInfo jslcinfo, >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:272: error: cannot find symbol >> private static void compileAlphaGradientPaint(JSLCInfo jslcinfo, >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:285: error: cannot find symbol >> private static void compilePatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:295: error: cannot find symbol >> private static void compileAlphaPatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:305: error: cannot find symbol >> private static void compileSolidTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:314: error: cannot find symbol >> private static void compileMaskTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:324: error: cannot find symbol >> private static void compileLCDShader(JSLCInfo jslcinfo, String suffix, boolean alphaTest) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:408: error: cannot find symbol >> private static void compileShader(JSLCInfo jslcinfo, ShaderInfo info) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:414: error: cannot find symbol >> private static void compileShader(JSLCInfo jslcinfo, >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:454: error: cannot find symbol >> private static String readShaderFile(JSLCInfo jslcinfo, String name) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:460: error: cannot find symbol >> private static long shaderFileTime(JSLCInfo jslcinfo, String name) { >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:507: error: cannot find symbol >> class PrismLoaderBackend extends TreeScanner { >> ^ >> symbol: class TreeScanner >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:508: error: cannot find symbol >> private JSLParser parser; >> ^ >> symbol: class JSLParser >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol >> public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { >> ^ >> symbol: class JSLParser >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol >> public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { >> ^ >> symbol: class ProgramUnit >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:549: error: cannot find symbol >> public void visitVariableExpr(VariableExpr e) { >> ^ >> symbol: class VariableExpr >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: package JSLC does not exist >> JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: cannot find symbol >> JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); >> ^ >> symbol: variable JSLC >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:422: error: cannot find symbol >> if (JSLC.outOfDate(outFile, sourcetime)) { >> ^ >> symbol: variable JSLC >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:423: error: cannot find symbol >> if (pinfo == null) pinfo = JSLC.getParserInfo(source); >> ^ >> symbol: variable JSLC >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:425: error: cannot find symbol >> JSLC.write(loaderBackend.getGlueCode(name), outFile); >> ^ >> symbol: variable JSLC >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol >> JSLCInfo jslcinfo = new JSLCInfo(); >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol >> JSLCInfo jslcinfo = new JSLCInfo(); >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:467: error: cannot find symbol >> nameMap.put(JSLC.OUT_D3D, "prism-d3d/build/gensrc/{pkg}/d3d/hlsl/{name}.hlsl"); >> ^ >> symbol: variable JSLC >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:468: error: cannot find symbol >> nameMap.put(JSLC.OUT_ES2, "prism-es2/build/gensrc/{pkg}/es2/glsl/{name}.frag"); >> ^ >> symbol: variable JSLC >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:518: error: cannot find symbol >> Reader template = new InputStreamReader(getClass().getResourceAsStream(type + "Glue.stg")); >> ^ >> symbol: method getClass() >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:524: error: cannot find symbol >> Map vars = parser.getSymbolTable().getGlobalVariables(); >> ^ >> symbol: class Variable >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:528: error: cannot find symbol >> for (Variable v : vars.values()) { >> ^ >> symbol: class Variable >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:529: error: cannot find symbol >> if (v.getQualifier() == Qualifier.PARAM) { >> ^ >> symbol: variable Qualifier >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:531: error: cannot find symbol >> if (v.getType().getBaseType() == BaseType.SAMPLER) { >> ^ >> symbol: variable BaseType >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:548: error: method does not override or implement a method from a supertype >> @Override >> ^ >> 45 errors >> :graphics:compilePrismCompilers FAILED >> >> > From vadim.pakhnushev at oracle.com Wed Sep 21 10:11:23 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 21 Sep 2016 13:11:23 +0300 Subject: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac In-Reply-To: References: <28560249-0a59-1201-61c1-886553b3f8cf@oracle.com> Message-ID: And you don't have any local modifications? That's strange, I just tried it on my mac and it works fine. Let's see your gradle --debug log then. Vadim On 21.09.2016 11:23, Alexander Nyssen wrote: > Hi Vadim, > > unfortunately both does not help, the problem persists. > > Best Regards, > Alexander > >> Am 21.09.2016 um 10:02 schrieb Vadim Pakhnushev : >> >> Hi Alexander, >> >> This happens because in the https://bugs.openjdk.java.net/browse/JDK-8165809 these parts of build were reworked. >> You could start with gradle cleanAll, if it doesn't help, then rm -r build buildSrc/build should help. >> >> Thanks, >> Vadim >> >> On 21.09.2016 9:58, Alexander Nyssen wrote: >>> Hi all, >>> >>> having updated 9-dev to the latest tip, the gradle build now fails on my Mac with the following errors. Updating JIGSAW home to ea136 did not resolve the problems. Any ideas? >>> >>> Best Regards, >>> Alexander >>> >>> :graphics:compilePrismCompilers >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:26: error: package com.sun.scenario.effect.compiler does not exist >>> import com.sun.scenario.effect.compiler.JSLC; >>> ^ >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:27: error: package com.sun.scenario.effect.compiler.JSLC does not exist >>> import com.sun.scenario.effect.compiler.JSLC.JSLCInfo; >>> ^ >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:28: error: package com.sun.scenario.effect.compiler does not exist >>> import com.sun.scenario.effect.compiler.JSLParser; >>> ^ >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:29: error: package com.sun.scenario.effect.compiler.model does not exist >>> import com.sun.scenario.effect.compiler.model.BaseType; >>> ^ >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:30: error: package com.sun.scenario.effect.compiler.model does not exist >>> import com.sun.scenario.effect.compiler.model.Qualifier; >>> ^ >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:31: error: package com.sun.scenario.effect.compiler.model does not exist >>> import com.sun.scenario.effect.compiler.model.Variable; >>> ^ >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:32: error: package com.sun.scenario.effect.compiler.tree does not exist >>> import com.sun.scenario.effect.compiler.tree.ProgramUnit; >>> ^ >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:33: error: package com.sun.scenario.effect.compiler.tree does not exist >>> import com.sun.scenario.effect.compiler.tree.TreeScanner; >>> ^ >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:34: error: package com.sun.scenario.effect.compiler.tree does not exist >>> import com.sun.scenario.effect.compiler.tree.VariableExpr; >>> ^ >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:205: error: cannot find symbol >>> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, MaskType maskType) >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:211: error: cannot find symbol >>> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, AlphaMaskType maskType) >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:217: error: cannot find symbol >>> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, String maskName, >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:228: error: cannot find symbol >>> private static ShaderInfo getPaintInfo(JSLCInfo jslcinfo, String paintName, >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:239: error: cannot find symbol >>> private static void compileColorPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:248: error: cannot find symbol >>> private static void compileGradientPaint(JSLCInfo jslcinfo, >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:272: error: cannot find symbol >>> private static void compileAlphaGradientPaint(JSLCInfo jslcinfo, >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:285: error: cannot find symbol >>> private static void compilePatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:295: error: cannot find symbol >>> private static void compileAlphaPatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:305: error: cannot find symbol >>> private static void compileSolidTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:314: error: cannot find symbol >>> private static void compileMaskTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:324: error: cannot find symbol >>> private static void compileLCDShader(JSLCInfo jslcinfo, String suffix, boolean alphaTest) >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:408: error: cannot find symbol >>> private static void compileShader(JSLCInfo jslcinfo, ShaderInfo info) >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:414: error: cannot find symbol >>> private static void compileShader(JSLCInfo jslcinfo, >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:454: error: cannot find symbol >>> private static String readShaderFile(JSLCInfo jslcinfo, String name) >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:460: error: cannot find symbol >>> private static long shaderFileTime(JSLCInfo jslcinfo, String name) { >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:507: error: cannot find symbol >>> class PrismLoaderBackend extends TreeScanner { >>> ^ >>> symbol: class TreeScanner >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:508: error: cannot find symbol >>> private JSLParser parser; >>> ^ >>> symbol: class JSLParser >>> location: class PrismLoaderBackend >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol >>> public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { >>> ^ >>> symbol: class JSLParser >>> location: class PrismLoaderBackend >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol >>> public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { >>> ^ >>> symbol: class ProgramUnit >>> location: class PrismLoaderBackend >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:549: error: cannot find symbol >>> public void visitVariableExpr(VariableExpr e) { >>> ^ >>> symbol: class VariableExpr >>> location: class PrismLoaderBackend >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: package JSLC does not exist >>> JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); >>> ^ >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: cannot find symbol >>> JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); >>> ^ >>> symbol: variable JSLC >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:422: error: cannot find symbol >>> if (JSLC.outOfDate(outFile, sourcetime)) { >>> ^ >>> symbol: variable JSLC >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:423: error: cannot find symbol >>> if (pinfo == null) pinfo = JSLC.getParserInfo(source); >>> ^ >>> symbol: variable JSLC >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:425: error: cannot find symbol >>> JSLC.write(loaderBackend.getGlueCode(name), outFile); >>> ^ >>> symbol: variable JSLC >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol >>> JSLCInfo jslcinfo = new JSLCInfo(); >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol >>> JSLCInfo jslcinfo = new JSLCInfo(); >>> ^ >>> symbol: class JSLCInfo >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:467: error: cannot find symbol >>> nameMap.put(JSLC.OUT_D3D, "prism-d3d/build/gensrc/{pkg}/d3d/hlsl/{name}.hlsl"); >>> ^ >>> symbol: variable JSLC >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:468: error: cannot find symbol >>> nameMap.put(JSLC.OUT_ES2, "prism-es2/build/gensrc/{pkg}/es2/glsl/{name}.frag"); >>> ^ >>> symbol: variable JSLC >>> location: class CompileJSL >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:518: error: cannot find symbol >>> Reader template = new InputStreamReader(getClass().getResourceAsStream(type + "Glue.stg")); >>> ^ >>> symbol: method getClass() >>> location: class PrismLoaderBackend >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:524: error: cannot find symbol >>> Map vars = parser.getSymbolTable().getGlobalVariables(); >>> ^ >>> symbol: class Variable >>> location: class PrismLoaderBackend >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:528: error: cannot find symbol >>> for (Variable v : vars.values()) { >>> ^ >>> symbol: class Variable >>> location: class PrismLoaderBackend >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:529: error: cannot find symbol >>> if (v.getQualifier() == Qualifier.PARAM) { >>> ^ >>> symbol: variable Qualifier >>> location: class PrismLoaderBackend >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:531: error: cannot find symbol >>> if (v.getType().getBaseType() == BaseType.SAMPLER) { >>> ^ >>> symbol: variable BaseType >>> location: class PrismLoaderBackend >>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:548: error: method does not override or implement a method from a supertype >>> @Override >>> ^ >>> 45 errors >>> :graphics:compilePrismCompilers FAILED >>> >>> From alexander at nyssen.org Wed Sep 21 11:35:14 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Wed, 21 Sep 2016 13:35:14 +0200 Subject: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac In-Reply-To: References: <28560249-0a59-1201-61c1-886553b3f8cf@oracle.com> Message-ID: <8E326CC0-C454-4132-9082-274E40B5389F@nyssen.org> Hi Vadim, you were right. My build.gradle was tampered. Sorry for the noise. Best Regards, Alexander > Am 21.09.2016 um 12:11 schrieb Vadim Pakhnushev : > > And you don't have any local modifications? > That's strange, I just tried it on my mac and it works fine. > Let's see your gradle --debug log then. > > Vadim > > On 21.09.2016 11:23, Alexander Nyssen wrote: >> Hi Vadim, >> >> unfortunately both does not help, the problem persists. >> >> Best Regards, >> Alexander >> >>> Am 21.09.2016 um 10:02 schrieb Vadim Pakhnushev : >>> >>> Hi Alexander, >>> >>> This happens because in the https://bugs.openjdk.java.net/browse/JDK-8165809 these parts of build were reworked. >>> You could start with gradle cleanAll, if it doesn't help, then rm -r build buildSrc/build should help. >>> >>> Thanks, >>> Vadim >>> >>> On 21.09.2016 9:58, Alexander Nyssen wrote: >>>> Hi all, >>>> >>>> having updated 9-dev to the latest tip, the gradle build now fails on my Mac with the following errors. Updating JIGSAW home to ea136 did not resolve the problems. Any ideas? >>>> >>>> Best Regards, >>>> Alexander >>>> >>>> :graphics:compilePrismCompilers >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:26: error: package com.sun.scenario.effect.compiler does not exist >>>> import com.sun.scenario.effect.compiler.JSLC; >>>> ^ >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:27: error: package com.sun.scenario.effect.compiler.JSLC does not exist >>>> import com.sun.scenario.effect.compiler.JSLC.JSLCInfo; >>>> ^ >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:28: error: package com.sun.scenario.effect.compiler does not exist >>>> import com.sun.scenario.effect.compiler.JSLParser; >>>> ^ >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:29: error: package com.sun.scenario.effect.compiler.model does not exist >>>> import com.sun.scenario.effect.compiler.model.BaseType; >>>> ^ >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:30: error: package com.sun.scenario.effect.compiler.model does not exist >>>> import com.sun.scenario.effect.compiler.model.Qualifier; >>>> ^ >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:31: error: package com.sun.scenario.effect.compiler.model does not exist >>>> import com.sun.scenario.effect.compiler.model.Variable; >>>> ^ >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:32: error: package com.sun.scenario.effect.compiler.tree does not exist >>>> import com.sun.scenario.effect.compiler.tree.ProgramUnit; >>>> ^ >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:33: error: package com.sun.scenario.effect.compiler.tree does not exist >>>> import com.sun.scenario.effect.compiler.tree.TreeScanner; >>>> ^ >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:34: error: package com.sun.scenario.effect.compiler.tree does not exist >>>> import com.sun.scenario.effect.compiler.tree.VariableExpr; >>>> ^ >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:205: error: cannot find symbol >>>> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, MaskType maskType) >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:211: error: cannot find symbol >>>> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, AlphaMaskType maskType) >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:217: error: cannot find symbol >>>> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, String maskName, >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:228: error: cannot find symbol >>>> private static ShaderInfo getPaintInfo(JSLCInfo jslcinfo, String paintName, >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:239: error: cannot find symbol >>>> private static void compileColorPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:248: error: cannot find symbol >>>> private static void compileGradientPaint(JSLCInfo jslcinfo, >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:272: error: cannot find symbol >>>> private static void compileAlphaGradientPaint(JSLCInfo jslcinfo, >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:285: error: cannot find symbol >>>> private static void compilePatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:295: error: cannot find symbol >>>> private static void compileAlphaPatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:305: error: cannot find symbol >>>> private static void compileSolidTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:314: error: cannot find symbol >>>> private static void compileMaskTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:324: error: cannot find symbol >>>> private static void compileLCDShader(JSLCInfo jslcinfo, String suffix, boolean alphaTest) >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:408: error: cannot find symbol >>>> private static void compileShader(JSLCInfo jslcinfo, ShaderInfo info) >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:414: error: cannot find symbol >>>> private static void compileShader(JSLCInfo jslcinfo, >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:454: error: cannot find symbol >>>> private static String readShaderFile(JSLCInfo jslcinfo, String name) >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:460: error: cannot find symbol >>>> private static long shaderFileTime(JSLCInfo jslcinfo, String name) { >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:507: error: cannot find symbol >>>> class PrismLoaderBackend extends TreeScanner { >>>> ^ >>>> symbol: class TreeScanner >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:508: error: cannot find symbol >>>> private JSLParser parser; >>>> ^ >>>> symbol: class JSLParser >>>> location: class PrismLoaderBackend >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol >>>> public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { >>>> ^ >>>> symbol: class JSLParser >>>> location: class PrismLoaderBackend >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol >>>> public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { >>>> ^ >>>> symbol: class ProgramUnit >>>> location: class PrismLoaderBackend >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:549: error: cannot find symbol >>>> public void visitVariableExpr(VariableExpr e) { >>>> ^ >>>> symbol: class VariableExpr >>>> location: class PrismLoaderBackend >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: package JSLC does not exist >>>> JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); >>>> ^ >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: cannot find symbol >>>> JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); >>>> ^ >>>> symbol: variable JSLC >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:422: error: cannot find symbol >>>> if (JSLC.outOfDate(outFile, sourcetime)) { >>>> ^ >>>> symbol: variable JSLC >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:423: error: cannot find symbol >>>> if (pinfo == null) pinfo = JSLC.getParserInfo(source); >>>> ^ >>>> symbol: variable JSLC >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:425: error: cannot find symbol >>>> JSLC.write(loaderBackend.getGlueCode(name), outFile); >>>> ^ >>>> symbol: variable JSLC >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol >>>> JSLCInfo jslcinfo = new JSLCInfo(); >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol >>>> JSLCInfo jslcinfo = new JSLCInfo(); >>>> ^ >>>> symbol: class JSLCInfo >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:467: error: cannot find symbol >>>> nameMap.put(JSLC.OUT_D3D, "prism-d3d/build/gensrc/{pkg}/d3d/hlsl/{name}.hlsl"); >>>> ^ >>>> symbol: variable JSLC >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:468: error: cannot find symbol >>>> nameMap.put(JSLC.OUT_ES2, "prism-es2/build/gensrc/{pkg}/es2/glsl/{name}.frag"); >>>> ^ >>>> symbol: variable JSLC >>>> location: class CompileJSL >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:518: error: cannot find symbol >>>> Reader template = new InputStreamReader(getClass().getResourceAsStream(type + "Glue.stg")); >>>> ^ >>>> symbol: method getClass() >>>> location: class PrismLoaderBackend >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:524: error: cannot find symbol >>>> Map vars = parser.getSymbolTable().getGlobalVariables(); >>>> ^ >>>> symbol: class Variable >>>> location: class PrismLoaderBackend >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:528: error: cannot find symbol >>>> for (Variable v : vars.values()) { >>>> ^ >>>> symbol: class Variable >>>> location: class PrismLoaderBackend >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:529: error: cannot find symbol >>>> if (v.getQualifier() == Qualifier.PARAM) { >>>> ^ >>>> symbol: variable Qualifier >>>> location: class PrismLoaderBackend >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:531: error: cannot find symbol >>>> if (v.getType().getBaseType() == BaseType.SAMPLER) { >>>> ^ >>>> symbol: variable BaseType >>>> location: class PrismLoaderBackend >>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:548: error: method does not override or implement a method from a supertype >>>> @Override >>>> ^ >>>> 45 errors >>>> :graphics:compilePrismCompilers FAILED >>>> >>>> > From David.Hill at Oracle.com Wed Sep 21 13:39:01 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 21 Sep 2016 09:39:01 -0400 Subject: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac In-Reply-To: References: Message-ID: <57E28D75.8020509@Oracle.com> On 9/21/16, 2:58 AM, Alexander Nyssen wrote: > Hi all, > > having updated 9-dev to the latest tip, the gradle build now fails on my Mac with the following errors. Updating JIGSAW home to ea136 did not resolve the problems. Any ideas? What version of gradle are you using ? Dave > > Best Regards, > Alexander > > :graphics:compilePrismCompilers > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:26: error: package com.sun.scenario.effect.compiler does not exist > import com.sun.scenario.effect.compiler.JSLC; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:27: error: package com.sun.scenario.effect.compiler.JSLC does not exist > import com.sun.scenario.effect.compiler.JSLC.JSLCInfo; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:28: error: package com.sun.scenario.effect.compiler does not exist > import com.sun.scenario.effect.compiler.JSLParser; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:29: error: package com.sun.scenario.effect.compiler.model does not exist > import com.sun.scenario.effect.compiler.model.BaseType; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:30: error: package com.sun.scenario.effect.compiler.model does not exist > import com.sun.scenario.effect.compiler.model.Qualifier; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:31: error: package com.sun.scenario.effect.compiler.model does not exist > import com.sun.scenario.effect.compiler.model.Variable; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:32: error: package com.sun.scenario.effect.compiler.tree does not exist > import com.sun.scenario.effect.compiler.tree.ProgramUnit; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:33: error: package com.sun.scenario.effect.compiler.tree does not exist > import com.sun.scenario.effect.compiler.tree.TreeScanner; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:34: error: package com.sun.scenario.effect.compiler.tree does not exist > import com.sun.scenario.effect.compiler.tree.VariableExpr; > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:205: error: cannot find symbol > private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, MaskType maskType) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:211: error: cannot find symbol > private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, AlphaMaskType maskType) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:217: error: cannot find symbol > private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, String maskName, > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:228: error: cannot find symbol > private static ShaderInfo getPaintInfo(JSLCInfo jslcinfo, String paintName, > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:239: error: cannot find symbol > private static void compileColorPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:248: error: cannot find symbol > private static void compileGradientPaint(JSLCInfo jslcinfo, > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:272: error: cannot find symbol > private static void compileAlphaGradientPaint(JSLCInfo jslcinfo, > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:285: error: cannot find symbol > private static void compilePatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:295: error: cannot find symbol > private static void compileAlphaPatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:305: error: cannot find symbol > private static void compileSolidTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:314: error: cannot find symbol > private static void compileMaskTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:324: error: cannot find symbol > private static void compileLCDShader(JSLCInfo jslcinfo, String suffix, boolean alphaTest) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:408: error: cannot find symbol > private static void compileShader(JSLCInfo jslcinfo, ShaderInfo info) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:414: error: cannot find symbol > private static void compileShader(JSLCInfo jslcinfo, > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:454: error: cannot find symbol > private static String readShaderFile(JSLCInfo jslcinfo, String name) > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:460: error: cannot find symbol > private static long shaderFileTime(JSLCInfo jslcinfo, String name) { > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:507: error: cannot find symbol > class PrismLoaderBackend extends TreeScanner { > ^ > symbol: class TreeScanner > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:508: error: cannot find symbol > private JSLParser parser; > ^ > symbol: class JSLParser > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol > public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { > ^ > symbol: class JSLParser > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol > public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { > ^ > symbol: class ProgramUnit > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:549: error: cannot find symbol > public void visitVariableExpr(VariableExpr e) { > ^ > symbol: class VariableExpr > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: package JSLC does not exist > JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); > ^ > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: cannot find symbol > JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); > ^ > symbol: variable JSLC > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:422: error: cannot find symbol > if (JSLC.outOfDate(outFile, sourcetime)) { > ^ > symbol: variable JSLC > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:423: error: cannot find symbol > if (pinfo == null) pinfo = JSLC.getParserInfo(source); > ^ > symbol: variable JSLC > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:425: error: cannot find symbol > JSLC.write(loaderBackend.getGlueCode(name), outFile); > ^ > symbol: variable JSLC > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol > JSLCInfo jslcinfo = new JSLCInfo(); > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol > JSLCInfo jslcinfo = new JSLCInfo(); > ^ > symbol: class JSLCInfo > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:467: error: cannot find symbol > nameMap.put(JSLC.OUT_D3D, "prism-d3d/build/gensrc/{pkg}/d3d/hlsl/{name}.hlsl"); > ^ > symbol: variable JSLC > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:468: error: cannot find symbol > nameMap.put(JSLC.OUT_ES2, "prism-es2/build/gensrc/{pkg}/es2/glsl/{name}.frag"); > ^ > symbol: variable JSLC > location: class CompileJSL > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:518: error: cannot find symbol > Reader template = new InputStreamReader(getClass().getResourceAsStream(type + "Glue.stg")); > ^ > symbol: method getClass() > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:524: error: cannot find symbol > Map vars = parser.getSymbolTable().getGlobalVariables(); > ^ > symbol: class Variable > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:528: error: cannot find symbol > for (Variable v : vars.values()) { > ^ > symbol: class Variable > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:529: error: cannot find symbol > if (v.getQualifier() == Qualifier.PARAM) { > ^ > symbol: variable Qualifier > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:531: error: cannot find symbol > if (v.getType().getBaseType() == BaseType.SAMPLER) { > ^ > symbol: variable BaseType > location: class PrismLoaderBackend > /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:548: error: method does not override or implement a method from a supertype > @Override > ^ > 45 errors > :graphics:compilePrismCompilers FAILED > > -- 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 alexander at nyssen.org Wed Sep 21 13:42:39 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Wed, 21 Sep 2016 15:42:39 +0200 Subject: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac In-Reply-To: <57E28D75.8020509@Oracle.com> References: <57E28D75.8020509@Oracle.com> Message-ID: <4AD3813D-C5D2-4E98-A829-916E11131113@nyssen.org> Hi Dave, I am using 2.11, as recommend. But as already said, the problem was on my side. Best Regards, Alexander > Am 21.09.2016 um 15:39 schrieb David Hill : > > On 9/21/16, 2:58 AM, Alexander Nyssen wrote: >> Hi all, >> >> having updated 9-dev to the latest tip, the gradle build now fails on my Mac with the following errors. Updating JIGSAW home to ea136 did not resolve the problems. Any ideas? > > What version of gradle are you using ? > > > Dave >> >> Best Regards, >> Alexander >> >> :graphics:compilePrismCompilers >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:26: error: package com.sun.scenario.effect.compiler does not exist >> import com.sun.scenario.effect.compiler.JSLC; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:27: error: package com.sun.scenario.effect.compiler.JSLC does not exist >> import com.sun.scenario.effect.compiler.JSLC.JSLCInfo; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:28: error: package com.sun.scenario.effect.compiler does not exist >> import com.sun.scenario.effect.compiler.JSLParser; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:29: error: package com.sun.scenario.effect.compiler.model does not exist >> import com.sun.scenario.effect.compiler.model.BaseType; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:30: error: package com.sun.scenario.effect.compiler.model does not exist >> import com.sun.scenario.effect.compiler.model.Qualifier; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:31: error: package com.sun.scenario.effect.compiler.model does not exist >> import com.sun.scenario.effect.compiler.model.Variable; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:32: error: package com.sun.scenario.effect.compiler.tree does not exist >> import com.sun.scenario.effect.compiler.tree.ProgramUnit; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:33: error: package com.sun.scenario.effect.compiler.tree does not exist >> import com.sun.scenario.effect.compiler.tree.TreeScanner; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:34: error: package com.sun.scenario.effect.compiler.tree does not exist >> import com.sun.scenario.effect.compiler.tree.VariableExpr; >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:205: error: cannot find symbol >> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, MaskType maskType) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:211: error: cannot find symbol >> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, AlphaMaskType maskType) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:217: error: cannot find symbol >> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, String maskName, >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:228: error: cannot find symbol >> private static ShaderInfo getPaintInfo(JSLCInfo jslcinfo, String paintName, >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:239: error: cannot find symbol >> private static void compileColorPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:248: error: cannot find symbol >> private static void compileGradientPaint(JSLCInfo jslcinfo, >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:272: error: cannot find symbol >> private static void compileAlphaGradientPaint(JSLCInfo jslcinfo, >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:285: error: cannot find symbol >> private static void compilePatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:295: error: cannot find symbol >> private static void compileAlphaPatternPaint(JSLCInfo jslcinfo, ShaderInfo maskInfo, boolean alphaTest) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:305: error: cannot find symbol >> private static void compileSolidTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:314: error: cannot find symbol >> private static void compileMaskTexture(JSLCInfo jslcinfo, String suffix, boolean alphaTest) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:324: error: cannot find symbol >> private static void compileLCDShader(JSLCInfo jslcinfo, String suffix, boolean alphaTest) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:408: error: cannot find symbol >> private static void compileShader(JSLCInfo jslcinfo, ShaderInfo info) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:414: error: cannot find symbol >> private static void compileShader(JSLCInfo jslcinfo, >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:454: error: cannot find symbol >> private static String readShaderFile(JSLCInfo jslcinfo, String name) >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:460: error: cannot find symbol >> private static long shaderFileTime(JSLCInfo jslcinfo, String name) { >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:507: error: cannot find symbol >> class PrismLoaderBackend extends TreeScanner { >> ^ >> symbol: class TreeScanner >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:508: error: cannot find symbol >> private JSLParser parser; >> ^ >> symbol: class JSLParser >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol >> public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { >> ^ >> symbol: class JSLParser >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:512: error: cannot find symbol >> public PrismLoaderBackend(JSLParser parser, ProgramUnit program) { >> ^ >> symbol: class ProgramUnit >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:549: error: cannot find symbol >> public void visitVariableExpr(VariableExpr e) { >> ^ >> symbol: class VariableExpr >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: package JSLC does not exist >> JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); >> ^ >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:419: error: cannot find symbol >> JSLC.ParserInfo pinfo = JSLC.compile(jslcinfo, source, sourcetime); >> ^ >> symbol: variable JSLC >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:422: error: cannot find symbol >> if (JSLC.outOfDate(outFile, sourcetime)) { >> ^ >> symbol: variable JSLC >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:423: error: cannot find symbol >> if (pinfo == null) pinfo = JSLC.getParserInfo(source); >> ^ >> symbol: variable JSLC >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:425: error: cannot find symbol >> JSLC.write(loaderBackend.getGlueCode(name), outFile); >> ^ >> symbol: variable JSLC >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol >> JSLCInfo jslcinfo = new JSLCInfo(); >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:465: error: cannot find symbol >> JSLCInfo jslcinfo = new JSLCInfo(); >> ^ >> symbol: class JSLCInfo >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:467: error: cannot find symbol >> nameMap.put(JSLC.OUT_D3D, "prism-d3d/build/gensrc/{pkg}/d3d/hlsl/{name}.hlsl"); >> ^ >> symbol: variable JSLC >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:468: error: cannot find symbol >> nameMap.put(JSLC.OUT_ES2, "prism-es2/build/gensrc/{pkg}/es2/glsl/{name}.frag"); >> ^ >> symbol: variable JSLC >> location: class CompileJSL >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:518: error: cannot find symbol >> Reader template = new InputStreamReader(getClass().getResourceAsStream(type + "Glue.stg")); >> ^ >> symbol: method getClass() >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:524: error: cannot find symbol >> Map vars = parser.getSymbolTable().getGlobalVariables(); >> ^ >> symbol: class Variable >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:528: error: cannot find symbol >> for (Variable v : vars.values()) { >> ^ >> symbol: class Variable >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:529: error: cannot find symbol >> if (v.getQualifier() == Qualifier.PARAM) { >> ^ >> symbol: variable Qualifier >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:531: error: cannot find symbol >> if (v.getType().getBaseType() == BaseType.SAMPLER) { >> ^ >> symbol: variable BaseType >> location: class PrismLoaderBackend >> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:548: error: method does not override or implement a method from a supertype >> @Override >> ^ >> 45 errors >> :graphics:compilePrismCompilers FAILED >> >> > > > -- > 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 VARD.ANTINYAN at cse.gu.se Wed Sep 21 15:38:35 2016 From: VARD.ANTINYAN at cse.gu.se (Vard Antinyan) Date: Wed, 21 Sep 2016 15:38:35 +0000 Subject: code complexity survey Message-ID: <08cb0ab158534645b6b6a9d322be8b83@cse.gu.se> Dear openjfx developers, We have undertaken a task to assess code complexity triggers and generate recommendations for developing simple and understandable code. Our intension is to share the results with you, developers, so everyone can learn the triggers behind complex software. We need your help for rigorous results. My request to you is - if you get 5-10 min. time, would you please consider to answer the questions of this survey on code complexity? https://goo.gl/forms/h9WXZ8VSEw7BUyHg1 You are welcome to learn preliminary results through this link: https://www.facebook.com/SoftwareCodeQuality/photos/?tab=album&album_id=1639816749664288 The results will be shared in a public webpage and everyone possible will be invited to learn and discuss them. Your knowledge and experience is vital for achieving substantial and generalizable results, and your effort is much appreciated! Sincerely Vard Antinyan PhD candidate in University of Gothenburg, Sweden Tel: 0046317725707 From swpalmer at gmail.com Wed Sep 21 18:08:38 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 21 Sep 2016 14:08:38 -0400 Subject: Warnings when running with -Xcheck:jni Message-ID: I noticed several warnings coming from javaFX when I ran my app with -X:check:jni Is that something worth filing an issue over,or is it basically a known thing and we don't particularly care? E.g.: WARNING in native method: JNI call made without checking exceptions when required to from CallStaticObjectMethodV at com.sun.glass.ui.win.WinDnDClipboard.push(Native Method) at com.sun.glass.ui.win.WinSystemClipboard.pushToSystem(WinSystemClipboard.java:234) at com.sun.glass.ui.SystemClipboard.flush(SystemClipboard.java:51) at com.sun.glass.ui.ClipboardAssistance.flush(ClipboardAssistance.java:59) at com.sun.javafx.tk.quantum.QuantumClipboard.flush(QuantumClipboard.java:274) at com.sun.javafx.tk.quantum.QuantumToolkit.startDrag(QuantumToolkit.java:1224) at javafx.scene.Scene$DnDGesture.dragDetectedProcessed(Scene.java:2953) WARNING: JNI local refs: zu, exceeds capacity: zu at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:191) at com.sun.glass.ui.win.WinApplication$$Lambda$57/665296081.run(Unknown Source) at java.lang.Thread.run(Unknown Source) WARNING in native method: JNI call made without checking exceptions when required to from CallStaticObjectMethodV at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:191) at com.sun.glass.ui.win.WinApplication$$Lambda$57/665296081.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Regards, Scott From kevin.rushforth at oracle.com Wed Sep 21 18:17:56 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 21 Sep 2016 11:17:56 -0700 Subject: Warnings when running with -Xcheck:jni In-Reply-To: References: Message-ID: <57E2CED4.4050208@oracle.com> We do care at least about the first one (pending exceptions), and we should fix them. Can you file a bug? As for the 'exceeds capacity' warning for JNI local refs we haven't in general cared about these (I don't know of any VM for which this would cause a problem), but we still might want to see if we can do something to silence these warnings. Thanks. -- Kevin Scott Palmer wrote: > I noticed several warnings coming from javaFX when I ran my app with > -X:check:jni > > Is that something worth filing an issue over,or is it basically a known > thing and we don't particularly care? > > E.g.: > > WARNING in native method: JNI call made without checking exceptions when > required to from CallStaticObjectMethodV > at com.sun.glass.ui.win.WinDnDClipboard.push(Native Method) > at > com.sun.glass.ui.win.WinSystemClipboard.pushToSystem(WinSystemClipboard.java:234) > at com.sun.glass.ui.SystemClipboard.flush(SystemClipboard.java:51) > at > com.sun.glass.ui.ClipboardAssistance.flush(ClipboardAssistance.java:59) > at > com.sun.javafx.tk.quantum.QuantumClipboard.flush(QuantumClipboard.java:274) > at > com.sun.javafx.tk.quantum.QuantumToolkit.startDrag(QuantumToolkit.java:1224) > at > javafx.scene.Scene$DnDGesture.dragDetectedProcessed(Scene.java:2953) > > > > WARNING: JNI local refs: zu, exceeds capacity: zu > at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at > com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:191) > at > com.sun.glass.ui.win.WinApplication$$Lambda$57/665296081.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > WARNING in native method: JNI call made without checking exceptions when > required to from CallStaticObjectMethodV > at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at > com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:191) > at > com.sun.glass.ui.win.WinApplication$$Lambda$57/665296081.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > > Regards, > > Scott > From David.Hill at Oracle.com Wed Sep 21 18:51:57 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 21 Sep 2016 14:51:57 -0400 Subject: review @Native in graphics windows build Message-ID: <57E2D6CD.8060000@Oracle.com> Kevin, Chien, https://bugs.openjdk.java.net/browse/JDK-8166471 webrev: http://cr.openjdk.java.net/~ddhill/8166471 -- 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 matthieu at brouillard.fr Thu Sep 22 06:33:01 2016 From: matthieu at brouillard.fr (Matthieu BROUILLARD) Date: Thu, 22 Sep 2016 08:33:01 +0200 Subject: How to Read JavaFX Pulse Log Message In-Reply-To: <60431EDA-C825-4C54-95B0-9190E35FC4F5@veroanalytics.com> References: <60431EDA-C825-4C54-95B0-9190E35FC4F5@veroanalytics.com> Message-ID: Hi Tai, I cannot help you interpreting the pulse log but with recent oracle JDK you can use Java Mission Control & the JavaFX plugin/extension to have a deep understanding of all pulses and of the different steps within the pulse (CSS parsing/rendering, layouting, painting, ...) Regards, Matthieu On Wed, Sep 21, 2016 at 12:56 AM, Tai Hu wrote: > Hi, > Is there any document or tutorial about how to interpret JavaFX Pulse > log message? I turned on Pulse Logger for my application and see the log > message as follows, > > PULSE: 575 [143ms:20ms] > T12 (-143 +143ms): Layout Pass > T12 (0 +0ms): CSS Pass > T12 (1 +0ms): Layout Pass > T12 (1 +0ms): Update bounds > T12 (1 +0ms): Waiting for previous rendering > T12 (1 +0ms): Copy state to render graph > T12 (2 +0ms): CSS Pass > T12 (3 +1ms): Layout Pass > T12 (4 +0ms): Update bounds > T12 (5 +0ms): Waiting for previous rendering > T12 (5 +2ms): Copy state to render graph > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 (8 +5ms): Painting > T9 (13 +1ms): Presenting > T9 (14 +0ms): Dirty Opts Computed > T9 : Slow shape path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 : Slow background path for null > T9 (14 +5ms): Painting > T9 (19 +0ms): Presenting > Counters: > Cached region shape image used: 3 > NGRegion renderBackgroundShape slow path: 1 > NGRegion renderBackgrounds slow path: 26 > Nodes rendered: 212 > Nodes visited during render: 227 > > There is a lot of "Slow background path for null?. Is that indicating a > problem? If so, how can I fix it? > > Thanks, > > Tai From alexander at nyssen.org Thu Sep 22 06:54:49 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Thu, 22 Sep 2016 08:54:49 +0200 Subject: Review request for 8166242: Removal of com.sun.javafx.embed.AbstractEvents Message-ID: <57B9DC29-39B3-422A-B69D-7B3DAA8CD3FD@nyssen.org> Hallo Kevin, Alexander Z, Vadim, I have created an initial patch for the replacement of AbstractEvents with direct usage of JavaFX representations: https://bugs.openjdk.java.net/browse/JDK-8166242 http://cr.openjdk.java.net/~anyssen/8166242/webrev.00/ Best Regards, Alexander From kevin.rushforth at oracle.com Thu Sep 22 12:21:04 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 22 Sep 2016 05:21:04 -0700 Subject: Review request for 8166242: Removal of com.sun.javafx.embed.AbstractEvents In-Reply-To: <57B9DC29-39B3-422A-B69D-7B3DAA8CD3FD@nyssen.org> References: <57B9DC29-39B3-422A-B69D-7B3DAA8CD3FD@nyssen.org> Message-ID: <57E3CCB0.2040905@oracle.com> Hi Alexander, Since this is an enhancement, it needs to go through the FC extension process indicated here: http://openjdk.java.net/projects/jdk9/fc-extension-process First and foremost, we will need to assess the impact of the change and whether this is the right time to consider such a change. I note that since this does not add additional functionality, but just refactors existing functionality to be easier to maintain, we might at least consider it when/if the recently announced schedule slip for JDK 9 becomes effective. -- Kevin Alexander Nyssen wrote: > Hallo Kevin, Alexander Z, Vadim, > > I have created an initial patch for the replacement of AbstractEvents with direct usage of JavaFX representations: > > https://bugs.openjdk.java.net/browse/JDK-8166242 > http://cr.openjdk.java.net/~anyssen/8166242/webrev.00/ > > Best Regards, > Alexander From alexander at nyssen.org Thu Sep 22 13:27:13 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Thu, 22 Sep 2016 15:27:13 +0200 Subject: Review request for 8166242: Removal of com.sun.javafx.embed.AbstractEvents In-Reply-To: <57E3CCB0.2040905@oracle.com> References: <57B9DC29-39B3-422A-B69D-7B3DAA8CD3FD@nyssen.org> <57E3CCB0.2040905@oracle.com> Message-ID: Hi Kevin, I had already expected something like this (while I did not know the process in detail). It's definitely not an urgent thing, postponing it will not block other work. I already investigated it now, because applying it would probably make things easier when fixing other issues related to FXCanvas. Best Regards, Alexander > Am 22.09.2016 um 14:21 schrieb Kevin Rushforth : > > Hi Alexander, > > Since this is an enhancement, it needs to go through the FC extension process indicated here: > > http://openjdk.java.net/projects/jdk9/fc-extension-process > > First and foremost, we will need to assess the impact of the change and whether this is the right time to consider such a change. I note that since this does not add additional functionality, but just refactors existing functionality to be easier to maintain, we might at least consider it when/if the recently announced schedule slip for JDK 9 becomes effective. > > -- Kevin > > > Alexander Nyssen wrote: >> Hallo Kevin, Alexander Z, Vadim, >> >> I have created an initial patch for the replacement of AbstractEvents with direct usage of JavaFX representations: >> >> https://bugs.openjdk.java.net/browse/JDK-8166242 http://cr.openjdk.java.net/~anyssen/8166242/webrev.00/ >> >> Best Regards, >> Alexander From chris.bensen at oracle.com Thu Sep 22 15:25:03 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Thu, 22 Sep 2016 08:25:03 -0700 Subject: [9] Review Request: 8165383 [packager] -native image generates all bundlers Message-ID: <3D1138B6-F8E6-4AFA-B5A1-78A34D9F0D5C@oracle.com> Kevin, The -native CLI argument is 100% working. "-native image? for example generates all bundles rather than just the image. This obviously fixes that. Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165383/webrev.00/ JIRA: https://bugs.openjdk.java.net/browse/JDK-8165383 Chris From David.Hill at Oracle.com Thu Sep 22 18:46:09 2016 From: David.Hill at Oracle.com (David Hill) Date: Thu, 22 Sep 2016 14:46:09 -0400 Subject: review: @Native for mac Message-ID: <57E426F1.10003@Oracle.com> Kevin, Chien, https://bugs.openjdk.java.net/browse/JDK-8166564 http://cr.openjdk.java.net/~ddhill/8166564 -- 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 arunprasad.rajkumar at oracle.com Fri Sep 23 05:35:57 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Fri, 23 Sep 2016 11:05:57 +0530 Subject: [webkit] [9] Review request for 8166265: jfxwebkit.dll is missing file detail for 8u112 and 9 Message-ID: <6ff307fd-bbe4-dddf-591c-03346a78d0b3@oracle.com> Hello Kevin, Guru, Murali, Please review the following fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8166265 Webrev: http://cr.openjdk.java.net/~arajkumar/8166265/webrev.00 Analysis: Newly merged WebKit doesn't include version.res file generated by build.gradle, version.res file contains "Product details" which need to be incorporated to jfxwebkit.dll. Regards, Arun From vadim.pakhnushev at oracle.com Fri Sep 23 14:30:40 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 23 Sep 2016 17:30:40 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <7cb8a2d8-b7ed-0958-15e1-33b3888c8f81@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 David.Hill at Oracle.com Fri Sep 23 19:20:56 2016 From: David.Hill at Oracle.com (David Hill) Date: Fri, 23 Sep 2016 15:20:56 -0400 Subject: Review: separate building of ant-javafx.jar from fxpackager proper Message-ID: <57E58098.8020004@Oracle.com> Chris, Kevin, https://bugs.openjdk.java.net/browse/JDK-8166570 In a future modular build, ant-javafx.jar will need to be compiled separately from the fxpackager module sources. This is because a module compile cannot be dependent on a non-module (like the ant jar) webrev: http://cr.openjdk.java.net/~ddhill/8166570 Please note: this is the minimum I needed to split out the compile of the ant dependent stuff. I suspect that there might be a few more items that could be moved (like the resources maybe) into the new source set, but that will be for a later commit. I tested this by comparing the results of the files in build/sdk/lib/ant-javafx.jar, and modular-sdk/modules/jdk.packager against a current Linux build. -- 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 derijcke.erik at gmail.com Sat Sep 24 21:18:42 2016 From: derijcke.erik at gmail.com (Erik De Rijcke) Date: Sat, 24 Sep 2016 23:18:42 +0200 Subject: Wayland support for JavaFX In-Reply-To: References: <54CA9FF4.1020701@Oracle.com> <54CAAAEE.1080906@Oracle.com> Message-ID: Heads up. A working monocle poc is now available here: https://github.com/udevbe/wayland-javafx Enjoy! Erik On Fri, Jan 30, 2015 at 10:23 PM, Erik De Rijcke wrote: > Innitial (currently nont working) code lives at: > https://github.com/Zubnix/wayland-javafx > > I do have a few questions: > - How are you supposed to handle events coming from the display system > itself? For example, I don't see any X events being handled. How/where > should that be done? > - How does the client rendering loop works? Like in X, in wayland you > have to "flush" queued op requests to the compositor. How/where should that > be done? > > Erik > > On Thu, Jan 29, 2015 at 10:49 PM, David Hill > wrote: > >> On 1/29/15, 4:35 PM, Erik De Rijcke wrote: >> >> I'll probably test it on the Weston (the Wayland reference compositor) >> and secretly also on my own compositor both running on my PC hardware. The >> thing is, Wayland clients don't really care what the hardware supports. The >> *real* egl context is set up in the compositor and with a little mesa >> trickery, is made available to the client. (see http://ppaalanen. >> blogspot.be/2012/03/what-does-egl-do-in-wayland-stack.html ). So the >> client doesn't need to know how to setup an egl context. If egl is >> unavailable or undesired, the client can/should be able to fall back to >> software rendering, which is simply done by filling a buffer with pixels >> and asking the compositor to dislay it. >> >> I'm having a look at the EGL->Framebuffer and Software -> Framebuffer and >> at first glance seems like a very easy thing to port to Wayland (that is, >> easy as easy goes in software development...). I'm not quite sure what you >> mean with the 'own virtual windows'. It sounds a bit like a use case for >> wayland's subsurface ( http://ppaalanen.blogspot.be/ >> 2013/11/sub-surfaces-now.html ) which afaik does exactly that. >> >> Mesa maybe the tricky part. The software renderer has demonstrated shader >> compatability issues in the past with JFX. These are shaders that are happy >> across a range of other devices. >> >> It still might be interesting to try it with the software -> framebuffer >> path. >> >> Good luck and let us appraised. >> >> Dave >> >> Erik >> >> On Thu, Jan 29, 2015 at 10:02 PM, David Hill >> wrote: >> >>> On 1/29/15, 3:47 PM, Erik De Rijcke wrote: >>> >>>> Hi all, >>>> >>>> I'm looking at running javafx on wayland ( >>>> http://wayland.freedesktop.org >>>> ). First of all, I was wondering if anyone else knows of any attempts to >>>> avoid duplicate work, as for now google turns op empty. >>>> >>>> Secondly, I'm looking for sources on how to write a new javafx platform. >>>> Google points me to monocle and it's *Platform implementations. Are >>>> there >>>> other sources of documentation or pointers or 'must-known's? >>>> >>>> I already made wayland java bindings ( >>>> https://github.com/Zubnix/wayland-java-bindings ) and wrote a simple >>>> wayland compositor ( https://github.com/Zubnix/westmalle ) all in pure >>>> Java. So the wayland part is already covered. >>>> >>>> Thanks in advance, I'll update this post with my progressions. >>>> >>> >>> I am not aware of anyone doing a wayland port yet. It certainly should >>> be a reasonable thing to do, using Glass/Monocle, we already support a >>> similar setup with EGL->Framebuffer and Software -> Framebuffer. >>> >>> Glancing at your wayland-java-bindings I see mention of EGL :-) >>> >>> Note however, Monocle does its own "windows" virtually. Wayland was >>> designed as a composition as well as a framebuffer engine. Monocle will >>> want to create a mono native window which acts as our display, that we then >>> render onto. >>> >>> Note that Monocle supports a number of platforms and rendering paths, >>> starting in PlatformFactory. >>> >>> Which hardware are you going to try this on ? >>> >>> Dave >>> >>> >>> >>>> Erik >>>> >>> >>> >>> -- >>> 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) >>> >>> >> >> >> -- >> 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 semyon.sadetsky at oracle.com Mon Sep 26 07:58:42 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 26 Sep 2016 10:58:42 +0300 Subject: Intel D3D should be disabled? Message-ID: <706380bb-c9f0-c9e6-a48f-3c00481ddd34@oracle.com> Hello, JDK 9 has D3D disabled for all Intell video adapters as https://bugs.openjdk.java.net/browse/JDK-8039444 was pushed. But FX still enables it. I can see artifacts described in https://bugs.openjdk.java.net/browse/JDK-8146042 in FX apps. Should a ticket be filed to disable Intel D3D in FX? --Semyon From kevin.rushforth at oracle.com Mon Sep 26 16:53:22 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 26 Sep 2016 09:53:22 -0700 Subject: Intel D3D should be disabled? In-Reply-To: <706380bb-c9f0-c9e6-a48f-3c00481ddd34@oracle.com> References: <706380bb-c9f0-c9e6-a48f-3c00481ddd34@oracle.com> Message-ID: <57E95282.1070108@oracle.com> No, I do not think this is the right approach. JavaFX has always enabled D3D on Intel HD, so this would be a performance regression. Please do file a new bug about the artifacts, though. -- Kevin Semyon Sadetsky wrote: > Hello, > > JDK 9 has D3D disabled for all Intell video adapters as > https://bugs.openjdk.java.net/browse/JDK-8039444 was pushed. > > But FX still enables it. I can see artifacts described in > https://bugs.openjdk.java.net/browse/JDK-8146042 in FX apps. > > Should a ticket be filed to disable Intel D3D in FX? > > --Semyon > > From arunprasad.rajkumar at oracle.com Tue Sep 27 06:23:23 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 27 Sep 2016 11:53:23 +0530 Subject: [webkit] [9] Review request for 8166759: jfxwebkit.dll is missing file detail for 8u112 and 9 Message-ID: <1610409E-3860-4AF1-B7EF-11A8005EFE42@oracle.com> Hello Kevin, Guru, Murali, Please review the following fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8166759 Webrev: http://cr.openjdk.java.net/~arajkumar/8166759/webrev.00 Analysis: Newly merged WexbKit doesn't include version.res file generated by build.gradle, version.res file contains "Product details" which need to be incorporated to jfxwebkit.dll. Regards, Arun From viplove.paliwal at oracle.com Tue Sep 27 13:44:37 2016 From: viplove.paliwal at oracle.com (Viplove Paliwal) Date: Tue, 27 Sep 2016 19:14:37 +0530 Subject: Review request for 8166776: Add HelloWebView with navigation and stop button Message-ID: <837f1058-491b-5b19-738e-5a392f163e0d@oracle.com> Hi Kevin, Arun & Guru, Please review the fix for JBS : https://bugs.openjdk.java.net/browse/JDK-8166776 Webrev : http://cr.openjdk.java.net/~ghb/vpaliwal/8166776/webrev.00/ Fix description is updated in JBS. Thanks, Viplove From chris.bensen at oracle.com Tue Sep 27 17:03:32 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 27 Sep 2016 10:03:32 -0700 Subject: [9] Review Request: 8165383 [packager] -native image generates all bundlers In-Reply-To: <3D1138B6-F8E6-4AFA-B5A1-78A34D9F0D5C@oracle.com> References: <3D1138B6-F8E6-4AFA-B5A1-78A34D9F0D5C@oracle.com> Message-ID: <8B440B42-1D0A-458C-95F3-9E3652FFAC65@oracle.com> Kevin, have you had time to review this? Chris > On Sep 22, 2016, at 8:25 AM, Chris Bensen wrote: > > Kevin, > > The -native CLI argument is 100% working. "-native image? for example generates all bundles rather than just the image. This obviously fixes that. > > Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165383/webrev.00/ > JIRA: https://bugs.openjdk.java.net/browse/JDK-8165383 > > Chris From james.graham at oracle.com Wed Sep 28 04:09:44 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 27 Sep 2016 21:09:44 -0700 Subject: [9] Review request: 8166565 [hidpi] a flickering scrollbar when using Caspian style sheet Message-ID: JBS: https://bugs.openjdk.java.net/browse/JDK-8166565 webrev: http://cr.openjdk.java.net/~flar/JDK-8166565/webrev.00/ I made the 6 new snapXY() methods in Region public for convenience here. They are all new for 9 and had been protected, now they are public. As noted in the bug report comment, there are a couple of places where I could not decide if the call should be for snapFooX() or snapFooY() and made a best guess and added a comment. Please advise. Also, advise if someone else should be CC'd on the review thread...? ...jim From vadim.pakhnushev at oracle.com Wed Sep 28 14:04:18 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 28 Sep 2016 17:04:18 +0300 Subject: [9] Review request for 8163486: NumberAxis: inaccurate rendering of ticks when tick unit is low Message-ID: <87b8c6e5-b35a-fc21-43b7-4ee2a5562441@oracle.com> Hi Jonathan, Kevin, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8163486 http://cr.openjdk.java.net/~vadim/8163486/webrev.00/ Thanks, Vadim From derijcke.erik at gmail.com Wed Sep 28 14:22:19 2016 From: derijcke.erik at gmail.com (Erik De Rijcke) Date: Wed, 28 Sep 2016 16:22:19 +0200 Subject: GLS language errors (Was: Internal error: Error loading stock shader FillRoundRect_LinearGradient,_PAD on Vivante ARM) In-Reply-To: <56D7248B.8090400@oracle.com> References: <56D1E6A4.80301@cuhka.com> <56D32F81.7060708@cuhka.com> <56D597E4.2050805@cuhka.com> <56D5CD0C.3050704@cuhka.com> <56D64062.5050105@oracle.com> <56D699FF.3010806@cuhka.com> <56D7248B.8090400@oracle.com> Message-ID: Hi all, Any follow up on this? I'm experiencing the same issue here (latest openjfx8 on wayland using mesa egl/gles2). Erik On Wed, Mar 2, 2016 at 6:36 PM, Chien Yang wrote: > Hi Maurice, > > Can you please file a JIRA on this issue? > > Thanks, > - Chien > > > On 3/1/16, 11:45 PM, Maurice wrote: > >> >> Jim, >> >> A solution in line of that of Johan Vos [1] works. JavaFX can be run and >> doesn't crash on startup when compiling the shaders. I think they should be >> taken into account for at least JavaFX 9, as it reduces a very serious bug >> to a possible optimization. >> >> Maurice. >> >> [1] https://bitbucket.org/javafxports/8u60-rt/commits/595633bbaa >> e36f98d85d47d276294442ea43488c >> >> Op 02-03-16 om 02:22 schreef Jim Graham: >> >>> The thing about this use of pixcoord is that the same information can be >>> supplied much more efficiently as a pair of texture coordinates. The value >>> of pixcoord ends up being a linear equation over the area of the primitive >>> which is exactly what texture coordinate samples give you for free. >>> >>> I believe some of the other gradient methods use that texture coordinate >>> technique to avoid having to use pixcoord, but the issue is that we've >>> hard-coded all of our VertexBuffer streams to have exactly 2 sets of >>> texture coordinates and so you only get room to pass in so many values and >>> these (i.e. this family of) shaders are already using those texture >>> coordinates to pass in too many values to leave enough free for the >>> gradient fractions. >>> >>> This shader could be avoided, I believe, by rasterizing the shape into >>> an alpha mask and using one of the alpha mask gradient shaders that doesn't >>> rely on pixcoord. In fact, in some embedded environments these shaders >>> have so many computations per pixel that running the shape rasterizer on >>> the CPU actually wins performance (and especially if you cache the alpha >>> masks as some of our NGShape nodes do)... >>> >>> ...jim >>> >>> On 3/1/16 9:10 AM, Maurice wrote: >>> >> >> From kevin.rushforth at oracle.com Wed Sep 28 16:06:25 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 28 Sep 2016 09:06:25 -0700 Subject: GLS language errors (Was: Internal error: Error loading stock shader FillRoundRect_LinearGradient,_PAD on Vivante ARM) In-Reply-To: References: <56D1E6A4.80301@cuhka.com> <56D32F81.7060708@cuhka.com> <56D597E4.2050805@cuhka.com> <56D5CD0C.3050704@cuhka.com> <56D64062.5050105@oracle.com> <56D699FF.3010806@cuhka.com> <56D7248B.8090400@oracle.com> Message-ID: <57EBEA81.1000103@oracle.com> I don't find a bug relating to this, so it seems the bug was never filed. Can you please file one? Thanks. -- Kevin Erik De Rijcke wrote: > Hi all, > > Any follow up on this? I'm experiencing the same issue here (latest > openjfx8 on wayland using mesa egl/gles2). > > Erik > > On Wed, Mar 2, 2016 at 6:36 PM, Chien Yang wrote: > > >> Hi Maurice, >> >> Can you please file a JIRA on this issue? >> >> Thanks, >> - Chien >> >> >> On 3/1/16, 11:45 PM, Maurice wrote: >> >> >>> Jim, >>> >>> A solution in line of that of Johan Vos [1] works. JavaFX can be run and >>> doesn't crash on startup when compiling the shaders. I think they should be >>> taken into account for at least JavaFX 9, as it reduces a very serious bug >>> to a possible optimization. >>> >>> Maurice. >>> >>> [1] https://bitbucket.org/javafxports/8u60-rt/commits/595633bbaa >>> e36f98d85d47d276294442ea43488c >>> >>> Op 02-03-16 om 02:22 schreef Jim Graham: >>> >>> >>>> The thing about this use of pixcoord is that the same information can be >>>> supplied much more efficiently as a pair of texture coordinates. The value >>>> of pixcoord ends up being a linear equation over the area of the primitive >>>> which is exactly what texture coordinate samples give you for free. >>>> >>>> I believe some of the other gradient methods use that texture coordinate >>>> technique to avoid having to use pixcoord, but the issue is that we've >>>> hard-coded all of our VertexBuffer streams to have exactly 2 sets of >>>> texture coordinates and so you only get room to pass in so many values and >>>> these (i.e. this family of) shaders are already using those texture >>>> coordinates to pass in too many values to leave enough free for the >>>> gradient fractions. >>>> >>>> This shader could be avoided, I believe, by rasterizing the shape into >>>> an alpha mask and using one of the alpha mask gradient shaders that doesn't >>>> rely on pixcoord. In fact, in some embedded environments these shaders >>>> have so many computations per pixel that running the shape rasterizer on >>>> the CPU actually wins performance (and especially if you cache the alpha >>>> masks as some of our NGShape nodes do)... >>>> >>>> ...jim >>>> >>>> On 3/1/16 9:10 AM, Maurice wrote: >>>> >>>> >>> From kevin.rushforth at oracle.com Wed Sep 28 20:31:52 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 28 Sep 2016 13:31:52 -0700 Subject: [9,8u] Review request: 8150982: Crash when calling WebEngine.print on background thread Message-ID: <57EC28B8.5090306@oracle.com> Phil, Please review the fix for the following related bugs: https://bugs.openjdk.java.net/browse/JDK-8150982 https://bugs.openjdk.java.net/browse/JDK-8165098 http://cr.openjdk.java.net/~kcr/8150982/webrev.00/ -- Kevin From jonathan.giles at oracle.com Wed Sep 28 20:35:58 2016 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 29 Sep 2016 09:35:58 +1300 Subject: [9] Review request: 8166013: NestedTableColumnHeader: must use factory method for header creation always Message-ID: <0baa9ca7-24fb-6132-4e69-6831ee7b3719@oracle.com> Kevin and / or Vadim, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8166013 http://cr.openjdk.java.net/~jgiles/8166013.1/ Thanks! -- -- Jonathan From jonathan.giles at oracle.com Wed Sep 28 20:39:08 2016 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 29 Sep 2016 09:39:08 +1300 Subject: [9] Review request: 8166021: NestedTableColumnHeader: package private access to skin prevents custom headers Message-ID: Kevin and / or Vadim, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8166021 http://cr.openjdk.java.net/~jgiles/8166021/ Thanks! -- -- Jonathan From chris.bensen at oracle.com Wed Sep 28 22:42:15 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 28 Sep 2016 15:42:15 -0700 Subject: [9] Review Request: 8166544 ANT issues in Mac developer build Message-ID: <0C94AACB-C783-4DE4-9F28-7C81387472A6@oracle.com> Kevin, Java Packager ANT scripts need to work with non modular jars. This fixes that. Webrev: https://bugs.openjdk.java.net/browse/JDK-8166544 JIRA: http://cr.openjdk.java.net/~cbensen/JDK-8166544/ Chris From jonathan.giles at oracle.com Thu Sep 29 00:35:08 2016 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 29 Sep 2016 13:35:08 +1300 Subject: [9] Review request: 8166025: TableColumnHeader: loses custom style classes Message-ID: <8bd14359-ac33-90ed-b0a8-75cf53a550a7@oracle.com> Kevin and / or Vadim, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8166025 http://cr.openjdk.java.net/~jgiles/8166025.3/ Thanks! -- Jonathan From james.graham at oracle.com Thu Sep 29 03:38:57 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 28 Sep 2016 20:38:57 -0700 Subject: [9] Review request: 8166565 [hidpi] a flickering scrollbar when using Caspian style sheet In-Reply-To: References: Message-ID: <93b67362-dd54-e038-f7b4-dab69ed9e0d3@oracle.com> An updated webrev is available, incorporating the feedback in the JBS comments: http://cr.openjdk.java.net/~flar/JDK-8166565/webrev.01/ ...jim On 9/27/16 9:09 PM, Jim Graham wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8166565 > webrev: http://cr.openjdk.java.net/~flar/JDK-8166565/webrev.00/ > > I made the 6 new snapXY() methods in Region public for convenience here. They are all new for 9 and had been protected, > now they are public. > > As noted in the bug report comment, there are a couple of places where I could not decide if the call should be for > snapFooX() or snapFooY() and made a best guess and added a comment. Please advise. > > Also, advise if someone else should be CC'd on the review thread...? > > ...jim From derijcke.erik at gmail.com Thu Sep 29 08:59:47 2016 From: derijcke.erik at gmail.com (Erik De Rijcke) Date: Thu, 29 Sep 2016 10:59:47 +0200 Subject: GLS language errors (Was: Internal error: Error loading stock shader FillRoundRect_LinearGradient,_PAD on Vivante ARM) In-Reply-To: <57EBEA81.1000103@oracle.com> References: <56D1E6A4.80301@cuhka.com> <56D32F81.7060708@cuhka.com> <56D597E4.2050805@cuhka.com> <56D5CD0C.3050704@cuhka.com> <56D64062.5050105@oracle.com> <56D699FF.3010806@cuhka.com> <56D7248B.8090400@oracle.com> <57EBEA81.1000103@oracle.com> Message-ID: I filed a report but it seems to be under review(?). On Wed, Sep 28, 2016 at 6:06 PM, Kevin Rushforth wrote: > I don't find a bug relating to this, so it seems the bug was never filed. > > Can you please file one? > > Thanks. > > -- Kevin > > > > Erik De Rijcke wrote: > >> Hi all, >> >> Any follow up on this? I'm experiencing the same issue here (latest >> openjfx8 on wayland using mesa egl/gles2). >> >> Erik >> >> On Wed, Mar 2, 2016 at 6:36 PM, Chien Yang wrote: >> >> >> >>> Hi Maurice, >>> >>> Can you please file a JIRA on this issue? >>> >>> Thanks, >>> - Chien >>> >>> >>> On 3/1/16, 11:45 PM, Maurice wrote: >>> >>> >>> >>>> Jim, >>>> >>>> A solution in line of that of Johan Vos [1] works. JavaFX can be run and >>>> doesn't crash on startup when compiling the shaders. I think they >>>> should be >>>> taken into account for at least JavaFX 9, as it reduces a very serious >>>> bug >>>> to a possible optimization. >>>> >>>> Maurice. >>>> >>>> [1] https://bitbucket.org/javafxports/8u60-rt/commits/595633bbaa >>>> e36f98d85d47d276294442ea43488c >>>> >>>> Op 02-03-16 om 02:22 schreef Jim Graham: >>>> >>>> >>>> >>>>> The thing about this use of pixcoord is that the same information can >>>>> be >>>>> supplied much more efficiently as a pair of texture coordinates. The >>>>> value >>>>> of pixcoord ends up being a linear equation over the area of the >>>>> primitive >>>>> which is exactly what texture coordinate samples give you for free. >>>>> >>>>> I believe some of the other gradient methods use that texture >>>>> coordinate >>>>> technique to avoid having to use pixcoord, but the issue is that we've >>>>> hard-coded all of our VertexBuffer streams to have exactly 2 sets of >>>>> texture coordinates and so you only get room to pass in so many values >>>>> and >>>>> these (i.e. this family of) shaders are already using those texture >>>>> coordinates to pass in too many values to leave enough free for the >>>>> gradient fractions. >>>>> >>>>> This shader could be avoided, I believe, by rasterizing the shape into >>>>> an alpha mask and using one of the alpha mask gradient shaders that >>>>> doesn't >>>>> rely on pixcoord. In fact, in some embedded environments these shaders >>>>> have so many computations per pixel that running the shape rasterizer >>>>> on >>>>> the CPU actually wins performance (and especially if you cache the >>>>> alpha >>>>> masks as some of our NGShape nodes do)... >>>>> >>>>> ...jim >>>>> >>>>> On 3/1/16 9:10 AM, Maurice wrote: >>>>> >>>>> >>>>> >>>> >>>> >>> From murali.billa at oracle.com Thu Sep 29 11:15:16 2016 From: murali.billa at oracle.com (Murali Billa) Date: Thu, 29 Sep 2016 04:15:16 -0700 (PDT) Subject: [9] Review request for 8166677: HTMLEditor freezes after restoring previously maximized window 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: ? Hi Kevin, Arun, Guru, Please review the following fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8166677 Webrev: http://cr.openjdk.java.net/~mbilla/8166677/webrev.00/ ? Thanks, Murali From vadim.pakhnushev at oracle.com Fri Sep 30 14:30:11 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 30 Sep 2016 17:30:11 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <6a2f6121-16d8-d033-b13c-4e0cb885002b@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