From arunprasad.rajkumar at oracle.com Fri Mar 1 12:06:30 2019 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Fri, 1 Mar 2019 17:36:30 +0530 Subject: [RFR] JDK-8219917: [WebView] Sub-resource integrity check fails Message-ID: <766B208E-3035-41CE-9F54-EDCBA2A6EE5B@oracle.com> Hi, Please review following Github PR, https://github.com/javafxports/openjdk-jfx/pull/392 JBS: https://bugs.openjdk.java.net/browse/JDK-8219917 Thanks, Arun From David at Cesal.cz Sat Mar 2 10:57:20 2019 From: David at Cesal.cz (=?iso-8859-2?Q?David_=C8esal?=) Date: Sat, 2 Mar 2019 11:57:20 +0100 Subject: Multiple vertical touch events at once - OpenJDK 11.0.2 Message-ID: <0a9601d4d0e6$b5c132a0$214397e0$@Cesal.cz> Hello, several times a day I observe multiple touch events at once, whereas I touch only with one finger to one place. These touches are always vertical = almost the same X coordination, but the large area in Y coordination. I'm using resolution 1920x1080. I've tried 2 different touch monitors, but the same behaviour - both iiyama T2235MSC-B1. I've written C++ touch application to check my touch screen, but it's perfectly okay, no this behaviour in C++. Only in Java FX. I'm using OpenJDK 11.0.2 and Windows 10. Every time this happens only when I touch the screen. Is there any cache for touch events in JavaFX, which is not properly cleaned? Have you observed this as well? What can I do? This is a showstopper for my whole app in production. Problem starts at [DEBUG] 2019-03-01T12:03:38.740+01:00 [JavaFX Application Thread] (BaseScene.java:193) - TOUCH_PRESSED target button - ID fastB1, classes button keyboardBtn fastB1Style [DEBUG] 2019-03-01T12:03:38.740+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 1, touchPoint count = 1, point = [1163.0, 77.0] [DEBUG] 2019-03-01T12:03:38.740+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 77.0], state = PRESSED [DEBUG] 2019-03-01T12:03:38.741+01:00 [JavaFX Application Thread] (BaseScene.java:193) - TOUCH_PRESSED target button - ID fastB2, classes button keyboardBtn fastB2Style [DEBUG] 2019-03-01T12:03:38.741+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 2, touchPoint count = 2, point = [1153.0, 148.0] [DEBUG] 2019-03-01T12:03:38.741+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 77.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.741+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1153.0, 148.0], state = PRESSED . Many other events come one by one till approx 8 stationary events at one: [DEBUG] 2019-03-01T12:03:38.745+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 77.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.745+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1153.0, 148.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.745+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 239.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 314.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1159.0, 413.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 482.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1154.0, 539.0], state = PRESSED [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:193) - TOUCH_PRESSED target button - ID null, classes button keyboardBtn [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 8, touchPoint count = 8, point = [1150.0, 975.0] [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 77.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1153.0, 148.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 239.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.747+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 314.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.747+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1159.0, 413.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.747+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 482.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.747+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1154.0, 539.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.747+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1150.0, 975.0], state = PRESSED [DEBUG] 2019-03-01T12:03:38.806+01:00 [JavaFX Application Thread] (BaseScene.java:193) - TOUCH_RELEASED target button - ID fastB1, classes button keyboardBtn fastB1Style [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 18, touchPoint count = 8, point = [1163.0, 77.0] [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 77.0], state = RELEASED [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1153.0, 148.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 239.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 314.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1159.0, 413.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 482.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1154.0, 539.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1150.0, 975.0], state = STATIONARY . and then decreasing one by one begins: [DEBUG] 2019-03-01T12:03:38.812+01:00 [JavaFX Application Thread] (BaseScene.java:197) - TOUCH_RELEASED No target/parent button/label - target is javafx.scene.control.TextField [DEBUG] 2019-03-01T12:03:38.812+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 23, touchPoint count = 3, point = [1160.0, 482.0] [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 482.0], state = RELEASED [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1154.0, 539.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1150.0, 975.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:193) - TOUCH_RELEASED target button - ID null, classes button lightGreen2 keyboardBtn [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 24, touchPoint count = 2, point = [1154.0, 539.0] [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1154.0, 539.0], state = RELEASED [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1150.0, 975.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.840+01:00 [JavaFX Application Thread] (BaseScene.java:193) - TOUCH_RELEASED target button - ID null, classes button keyboardBtn [DEBUG] 2019-03-01T12:03:38.841+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 30, touchPoint count = 1, point = [1151.0, 975.0] [DEBUG] 2019-03-01T12:03:38.841+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1151.0, 975.0], state = RELEASED Thank you! David From thevenet.fred at free.fr Sat Mar 2 15:11:26 2019 From: thevenet.fred at free.fr (Frederic Thevenet) Date: Sat, 2 Mar 2019 16:11:26 +0100 Subject: RFR: 8220012 Accordion control doesn't keeps reference to child pane after it is removed Message-ID: <005501d4d10a$3543a210$9fcae630$@free.fr> Please review the fix for: JDK -8220012 Accordion control doesn't keeps reference to child pane after it is removed https://bugs.openjdk.java.net/browse/JDK-8220012 https://github.com/javafxports/openjdk-jfx/issues/391 From wookey.dean at gmail.com Mon Mar 4 11:51:02 2019 From: wookey.dean at gmail.com (Dean Wookey) Date: Mon, 4 Mar 2019 13:51:02 +0200 Subject: RFR: JDK-8089986: Menu beeps when mnemonics used Message-ID: Hi, Please review the fix for JDK-8089986: Menu beeps when mnemonics is used https://bugs.openjdk.java.net/browse/JDK-8089986 https://github.com/javafxports/openjdk-jfx/pull/397 Dean From wookey.dean at gmail.com Tue Mar 5 08:35:34 2019 From: wookey.dean at gmail.com (Dean Wookey) Date: Tue, 5 Mar 2019 10:35:34 +0200 Subject: RFR: JDK-8088717: Win: UNDECORATED windows are not minimized with the taskbar button Message-ID: Hi, Please review the fix for JDK-8088717: Win: UNDECORATED windows are not minimized with the taskbar button https://bugs.openjdk.java.net/browse/JDK-8088717 https://bugs.openjdk.java.net/browse/JDK-8089296 https://github.com/javafxports/openjdk-jfx/pull/398 Dean From arunprasad.rajkumar at oracle.com Wed Mar 6 06:14:52 2019 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 6 Mar 2019 11:44:52 +0530 Subject: [RFR] JDK-8220147: Cherry pick GTK WebKit 2.22.7 changes Message-ID: <22A3CA79-0DA1-4BA0-912A-995FD8706DC8@oracle.com> Hi, Please review the following PR, https://github.com/javafxports/openjdk-jfx/pull/399 https://bugs.openjdk.java.net/browse/JDK-8220147 Thanks, Arun From David at Cesal.cz Wed Mar 6 09:07:12 2019 From: David at Cesal.cz (=?iso-8859-2?Q?David_=C8esal?=) Date: Wed, 6 Mar 2019 10:07:12 +0100 Subject: Multiple vertical touch events at once - OpenJDK 11.0.2 Message-ID: <007e01d4d3fb$fcc46b50$f64d41f0$@Cesal.cz> I would like to add, that I'm using this code to bind EventHandler: getScene().setOnTouchPressed(this); getScene().setOnTouchReleased(this); Then this method is called: @Override public void handle(InputEvent e) { handleEvent(e); } private void handleEvent(InputEvent e) {.} Touch point are iterated (for logging) this way: if (e instanceof TouchEvent) { TouchEvent te = ((TouchEvent) e); INPUT_EVENTS_LOGGER.debug("- touchEvent - setID = " + te.getEventSetId() + ", touchPoint count = " + te.getTouchCount() + ", point = [" + te.getTouchPoint().getScreenX() + ", " + te.getTouchPoint().getScreenY() + "]"); for (TouchPoint tp : te.getTouchPoints()) { INPUT_EVENTS_LOGGER.debug("--> point: [" + tp.getScreenX() + ", " + tp.getScreenY() + "], state = " + tp.getState().name()); } } Is it the right way how to bind Touch events listener? Is there any possibility how to detech touch point in "lower API"? Thanks David From: David ?esal Sent: Saturday, March 2, 2019 11:57 AM To: 'openjfx-dev at openjdk.java.net' Subject: Multiple vertical touch events at once - OpenJDK 11.0.2 Hello, several times a day I observe multiple touch events at once, whereas I touch only with one finger to one place. These touches are always vertical = almost the same X coordination, but the large area in Y coordination. I'm using resolution 1920x1080. I've tried 2 different touch monitors, but the same behaviour - both iiyama T2235MSC-B1. I've written C++ touch application to check my touch screen, but it's perfectly okay, no this behaviour in C++. Only in Java FX. I'm using OpenJDK 11.0.2 and Windows 10. Every time this happens only when I touch the screen. Is there any cache for touch events in JavaFX, which is not properly cleaned? Have you observed this as well? What can I do? This is a showstopper for my whole app in production. Problem starts at [DEBUG] 2019-03-01T12:03:38.740+01:00 [JavaFX Application Thread] (BaseScene.java:193) - TOUCH_PRESSED target button - ID fastB1, classes button keyboardBtn fastB1Style [DEBUG] 2019-03-01T12:03:38.740+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 1, touchPoint count = 1, point = [1163.0, 77.0] [DEBUG] 2019-03-01T12:03:38.740+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 77.0], state = PRESSED [DEBUG] 2019-03-01T12:03:38.741+01:00 [JavaFX Application Thread] (BaseScene.java:193) - TOUCH_PRESSED target button - ID fastB2, classes button keyboardBtn fastB2Style [DEBUG] 2019-03-01T12:03:38.741+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 2, touchPoint count = 2, point = [1153.0, 148.0] [DEBUG] 2019-03-01T12:03:38.741+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 77.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.741+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1153.0, 148.0], state = PRESSED . Many other events come one by one till approx 8 stationary events at one: [DEBUG] 2019-03-01T12:03:38.745+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 77.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.745+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1153.0, 148.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.745+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 239.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 314.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1159.0, 413.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 482.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1154.0, 539.0], state = PRESSED [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:193) - TOUCH_PRESSED target button - ID null, classes button keyboardBtn [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 8, touchPoint count = 8, point = [1150.0, 975.0] [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 77.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1153.0, 148.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.746+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 239.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.747+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 314.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.747+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1159.0, 413.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.747+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 482.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.747+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1154.0, 539.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.747+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1150.0, 975.0], state = PRESSED [DEBUG] 2019-03-01T12:03:38.806+01:00 [JavaFX Application Thread] (BaseScene.java:193) - TOUCH_RELEASED target button - ID fastB1, classes button keyboardBtn fastB1Style [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 18, touchPoint count = 8, point = [1163.0, 77.0] [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 77.0], state = RELEASED [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1153.0, 148.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1163.0, 239.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 314.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1159.0, 413.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 482.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1154.0, 539.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.807+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1150.0, 975.0], state = STATIONARY . and then decreasing one by one begins: [DEBUG] 2019-03-01T12:03:38.812+01:00 [JavaFX Application Thread] (BaseScene.java:197) - TOUCH_RELEASED No target/parent button/label - target is javafx.scene.control.TextField [DEBUG] 2019-03-01T12:03:38.812+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 23, touchPoint count = 3, point = [1160.0, 482.0] [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1160.0, 482.0], state = RELEASED [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1154.0, 539.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1150.0, 975.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:193) - TOUCH_RELEASED target button - ID null, classes button lightGreen2 keyboardBtn [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 24, touchPoint count = 2, point = [1154.0, 539.0] [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1154.0, 539.0], state = RELEASED [DEBUG] 2019-03-01T12:03:38.813+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1150.0, 975.0], state = STATIONARY [DEBUG] 2019-03-01T12:03:38.840+01:00 [JavaFX Application Thread] (BaseScene.java:193) - TOUCH_RELEASED target button - ID null, classes button keyboardBtn [DEBUG] 2019-03-01T12:03:38.841+01:00 [JavaFX Application Thread] (BaseScene.java:214) - - touchEvent - setID = 30, touchPoint count = 1, point = [1151.0, 975.0] [DEBUG] 2019-03-01T12:03:38.841+01:00 [JavaFX Application Thread] (BaseScene.java:216) - --> point: [1151.0, 975.0], state = RELEASED Thank you! David From diego.cirujano-cuesta at zeiss.com Fri Mar 8 08:20:40 2019 From: diego.cirujano-cuesta at zeiss.com (Cirujano Cuesta, Diego) Date: Fri, 8 Mar 2019 08:20:40 +0000 Subject: JDK-8220222: specify clearly gradle project dependencies Message-ID: Please review the following PR: https://github.com/javafxports/openjdk-jfx/pull/401 https://bugs.openjdk.java.net/browse/JDK-8220222 Best regards, Diego Cirujano Cuesta __________ Diego Cirujano Cuesta Central Software Munich Medical Technology Business Group ZEISS Expert Ladder - Staff Carl Zeiss Meditec AG ZEISS Gruppe Kistlerhofstr. 75 81379 Munich, Deutschland Phone: +4989909000203 Mobile: +4916099193532 diego.cirujano-cuesta at zeiss.com http://www.zeiss.com/med __________ Carl Zeiss Meditec AG Sitz der Gesellschaft: Jena, Deutschland Vorsitzender des Aufsichtsrats: Dr. Michael Kaschke Vorstand: Dr. Ludwin Monz (Vorsitzender), Dr. Christian M?ller (CFO) Amtsgericht Jena, HRB 205 623, USt-IdNr: DE 811 922 737 From mp at jugs.org Fri Mar 8 09:46:59 2019 From: mp at jugs.org (Michael Paus) Date: Fri, 8 Mar 2019 10:46:59 +0100 Subject: JDK-8220222: specify clearly gradle project dependencies In-Reply-To: References: Message-ID: <889dbb98-f6cf-1fef-c13c-2e3ce36bbdd6@jugs.org> Hi What is the status of Eclipse in this context? Michael Am 08.03.19 um 09:20 schrieb Cirujano Cuesta, Diego: > Please review the following PR: > > https://github.com/javafxports/openjdk-jfx/pull/401 > https://bugs.openjdk.java.net/browse/JDK-8220222 > > > Best regards, > > Diego Cirujano Cuesta > __________ > > Diego Cirujano Cuesta > Central Software Munich > Medical Technology Business Group > ZEISS Expert Ladder - Staff > > Carl Zeiss Meditec AG > ZEISS Gruppe > Kistlerhofstr. 75 > 81379 Munich, Deutschland > > Phone: +4989909000203 Mobile: +4916099193532 > diego.cirujano-cuesta at zeiss.com > http://www.zeiss.com/med > __________ > > Carl Zeiss Meditec AG > Sitz der Gesellschaft: Jena, Deutschland > Vorsitzender des Aufsichtsrats: Dr. Michael Kaschke > Vorstand: Dr. Ludwin Monz (Vorsitzender), Dr. Christian M?ller (CFO) > Amtsgericht Jena, HRB 205 623, USt-IdNr: DE 811 922 737 > From nlisker at gmail.com Fri Mar 8 14:53:45 2019 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 8 Mar 2019 16:53:45 +0200 Subject: JDK-8220222: specify clearly gradle project dependencies In-Reply-To: <889dbb98-f6cf-1fef-c13c-2e3ce36bbdd6@jugs.org> References: <889dbb98-f6cf-1fef-c13c-2e3ce36bbdd6@jugs.org> Message-ID: Hi, Eclipse requires special Gradle instructions. The instructions for working with Eclipse [1] should still be up to date. There are 2 options right now: 1. Use the Eclipse compiler/builder and do not involve Gradle (Buildship). The problem is that Gradle overwrites the custom-made .classpath files in the repository with wrong ones. 2. Use the Gradle compiler/builder by reverting the .classpath files changes Gradle made, but you will have constant conflicts with the repository due to changes in the .project files and the new .settings folders. They are resolvable with mercurial commands. There was some discussion about adding Gradle-specific Eclipse files to the repo when the Eclipse files in the repo were being updated [2]. A more ideal solution will be to instruct Gradle to build the correct files for the projects, but this is again an Eclipse-specific change, this time to build.gradle. An example of how to do this can be found in [3] or (for sub-projects) [4]. - Nir [1] https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse [2] https://bugs.openjdk.java.net/browse/JDK-8209015 [3] https://github.com/openjfx/samples/blob/master/IDE/Eclipse/Modular/Gradle/hellofx/build.gradle#L16 [4] https://github.com/FXyz/FXyz/pull/60/files#diff-c197962302397baf3a4cc36463dce5eaR54 On Fri, Mar 8, 2019 at 11:47 AM Michael Paus wrote: > Hi > What is the status of Eclipse in this context? > Michael > > Am 08.03.19 um 09:20 schrieb Cirujano Cuesta, Diego: > > Please review the following PR: > > > > https://github.com/javafxports/openjdk-jfx/pull/401 > > https://bugs.openjdk.java.net/browse/JDK-8220222 > > > > > > Best regards, > > > > Diego Cirujano Cuesta > > __________ > > > > Diego Cirujano Cuesta > > Central Software Munich > > Medical Technology Business Group > > ZEISS Expert Ladder - Staff > > > > Carl Zeiss Meditec AG > > ZEISS Gruppe > > Kistlerhofstr. 75 > > 81379 Munich, Deutschland > > > > Phone: +4989909000203 Mobile: +4916099193532 > > diego.cirujano-cuesta at zeiss.com > > http://www.zeiss.com/med > > __________ > > > > Carl Zeiss Meditec AG > > Sitz der Gesellschaft: Jena, Deutschland > > Vorsitzender des Aufsichtsrats: Dr. Michael Kaschke > > Vorstand: Dr. Ludwin Monz (Vorsitzender), Dr. Christian M?ller (CFO) > > Amtsgericht Jena, HRB 205 623, USt-IdNr: DE 811 922 737 > > > > From johan.vos at gluonhq.com Fri Mar 8 17:21:31 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 8 Mar 2019 18:21:31 +0100 Subject: RFR JDK 8220375 Message-ID: Please review PR#403 https://github.com/javafxports/openjdk-jfx/pull/403 which fixes the ios build and address https://bugs.openjdk.java.net/browse/JDK-8220375 - Johan From anton.tarasov at jetbrains.com Mon Mar 11 17:00:26 2019 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Mon, 11 Mar 2019 20:00:26 +0300 Subject: deadlock with swing Message-ID: <1ced588b-5c13-b761-a3f9-0a7cafb06cc2@jetbrains.com> Hello! Could you please take a look at the deadlock which we encounter with JFXPanel/WebView: "AWT-EventQueue-0" prio=0 tid=0x0 nid=0x0 waiting on condition ???? java.lang.Thread.State: WAITING ?on java.util.concurrent.FutureTask at 51c6338d ??? at java.base at 11.0.2/jdk.internal.misc.Unsafe.park(Native Method) ??? at java.base at 11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) ??? at java.base at 11.0.2/java.util.concurrent.FutureTask.awaitDone(FutureTask.java:447) ??? at java.base at 11.0.2/java.util.concurrent.FutureTask.get(FutureTask.java:190) ??? at platform/javafx.web at 11.0.2/com.sun.javafx.webkit.InputMethodClientImpl.getLocationOffset(InputMethodClientImpl.java:157) ??? at platform/javafx.graphics at 11.0.2/javafx.scene.Scene$InputMethodRequestsDelegate.getLocationOffset(Scene.java:4140) ??? at platform/javafx.swing at 11.0.2/javafx.embed.swing.InputMethodSupport$InputMethodRequestsAdapter.getLocationOffset(InputMethodSupport.java:67) ??? at java.desktop at 11.0.2/sun.awt.im.InputMethodContext.getLocationOffset(InputMethodContext.java:285) ??? at java.desktop at 11.0.2/sun.lwawt.macosx.CInputMethod$7.run(CInputMethod.java:779) ??? at java.desktop at 11.0.2/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) ??? at java.desktop at 11.0.2/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:776) ??? at java.desktop at 11.0.2/java.awt.EventQueue$4.run(EventQueue.java:727) ??? at java.desktop at 11.0.2/java.awt.EventQueue$4.run(EventQueue.java:721) ??? at java.base at 11.0.2/java.security.AccessController.doPrivileged(Native Method) ??? at java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) ??? at java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) ??? at java.desktop at 11.0.2/java.awt.EventQueue$5.run(EventQueue.java:751) ??? at java.desktop at 11.0.2/java.awt.EventQueue$5.run(EventQueue.java:749) ??? at java.base at 11.0.2/java.security.AccessController.doPrivileged(Native Method) ??? at java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) ??? at java.desktop at 11.0.2/java.awt.EventQueue.dispatchEvent(EventQueue.java:748) ??? at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:723) ??? at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:672) ??? at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:367) ??? at java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) ??? at java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) ??? at java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) ??? at java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) ??? at java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) ??? at java.desktop at 11.0.2/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) "JavaFX Application Thread" prio=0 tid=0x0 nid=0x0 runnable ???? java.lang.Thread.State: RUNNABLE ?(in native) ??? at java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.$$YJP$$doAWTRunLoopImpl(Native Method) ??? at java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) ??? at java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:1027) ??? at java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:827) ??? at java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:780) ??? at java.desktop at 11.0.2/sun.lwawt.macosx.CInputMethod.characterIndexForPoint(CInputMethod.java:777) It seems to be caused by this fix: https://hg.openjdk.java.net/openjfx/11/rt/rev/808d535c4e15 The "characterIndexForPoint" method performs "invokeAndWait" from JavaFX thread: ??????????? LWCToolkit.invokeAndWait(new Runnable() { ??????????????? public void run() { synchronized(offsetInfo) { ??????????????????? offsetInfo[0] = fIMContext.getLocationOffset(screenX, screenY); ??????????????????? insertPositionOffset[0] = fIMContext.getInsertPositionOffset(); ??????????????? }} ??????????? }, fAwtFocussedComponent); which is then on EDT delegates back to JavaFX thread and waits for async result. Is it a known issue? Unfortunately, I can't give you a simple case to reproduce it. Hope the problem looks clear from the description. With best regards, Anton. From kevin.rushforth at oracle.com Thu Mar 14 16:23:37 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Mar 2019 21:53:37 +0530 Subject: deadlock with swing In-Reply-To: <1ced588b-5c13-b761-a3f9-0a7cafb06cc2@jetbrains.com> References: <1ced588b-5c13-b761-a3f9-0a7cafb06cc2@jetbrains.com> Message-ID: <76064910-739c-c123-332f-56f14216d437@oracle.com> Hi Anton, Can you file a bug in JBS? We can take a look at it, although it might be difficult without a test case. -- Kevin On 3/11/19 10:30 PM, Anton Tarasov wrote: > Hello! > > Could you please take a look at the deadlock which we encounter with > JFXPanel/WebView: > > "AWT-EventQueue-0" prio=0 tid=0x0 nid=0x0 waiting on condition > ???? java.lang.Thread.State: WAITING > ?on java.util.concurrent.FutureTask at 51c6338d > ??? at java.base at 11.0.2/jdk.internal.misc.Unsafe.park(Native Method) > ??? at > java.base at 11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) > ??? at > java.base at 11.0.2/java.util.concurrent.FutureTask.awaitDone(FutureTask.java:447) > ??? at > java.base at 11.0.2/java.util.concurrent.FutureTask.get(FutureTask.java:190) > ??? at > platform/javafx.web at 11.0.2/com.sun.javafx.webkit.InputMethodClientImpl.getLocationOffset(InputMethodClientImpl.java:157) > ??? at > platform/javafx.graphics at 11.0.2/javafx.scene.Scene$InputMethodRequestsDelegate.getLocationOffset(Scene.java:4140) > ??? at > platform/javafx.swing at 11.0.2/javafx.embed.swing.InputMethodSupport$InputMethodRequestsAdapter.getLocationOffset(InputMethodSupport.java:67) > ??? at > java.desktop at 11.0.2/sun.awt.im.InputMethodContext.getLocationOffset(InputMethodContext.java:285) > ??? at > java.desktop at 11.0.2/sun.lwawt.macosx.CInputMethod$7.run(CInputMethod.java:779) > ??? at > java.desktop at 11.0.2/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) > ??? at > java.desktop at 11.0.2/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:776) > ??? at java.desktop at 11.0.2/java.awt.EventQueue$4.run(EventQueue.java:727) > ??? at java.desktop at 11.0.2/java.awt.EventQueue$4.run(EventQueue.java:721) > ??? at > java.base at 11.0.2/java.security.AccessController.doPrivileged(Native > Method) > ??? at > java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) > ??? at > java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) > ??? at java.desktop at 11.0.2/java.awt.EventQueue$5.run(EventQueue.java:751) > ??? at java.desktop at 11.0.2/java.awt.EventQueue$5.run(EventQueue.java:749) > ??? at > java.base at 11.0.2/java.security.AccessController.doPrivileged(Native > Method) > ??? at > java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) > ??? at > java.desktop at 11.0.2/java.awt.EventQueue.dispatchEvent(EventQueue.java:748) > ??? at > com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:723) > ??? at > com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:672) > ??? at > com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:367) > ??? at > java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) > ??? at > java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) > ??? at > java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) > ??? at > java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) > ??? at > java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > ??? at > java.desktop at 11.0.2/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) > > "JavaFX Application Thread" prio=0 tid=0x0 nid=0x0 runnable > ???? java.lang.Thread.State: RUNNABLE > ?(in native) > ??? at > java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.$$YJP$$doAWTRunLoopImpl(Native > Method) > ??? at > java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) > ??? at > java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:1027) > ??? at > java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:827) > ??? at > java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:780) > ??? at > java.desktop at 11.0.2/sun.lwawt.macosx.CInputMethod.characterIndexForPoint(CInputMethod.java:777) > > It seems to be caused by this fix: > https://hg.openjdk.java.net/openjfx/11/rt/rev/808d535c4e15 > > The "characterIndexForPoint" method performs "invokeAndWait" from > JavaFX thread: > > ??????????? LWCToolkit.invokeAndWait(new Runnable() { > ??????????????? public void run() { synchronized(offsetInfo) { > ??????????????????? offsetInfo[0] = > fIMContext.getLocationOffset(screenX, screenY); > ??????????????????? insertPositionOffset[0] = > fIMContext.getInsertPositionOffset(); > ??????????????? }} > ??????????? }, fAwtFocussedComponent); > > which is then on EDT delegates back to JavaFX thread and waits for > async result. > > Is it a known issue? Unfortunately, I can't give you a simple case to > reproduce it. Hope the problem looks clear from the description. > > With best regards, > Anton. From nakajima.akira at nttcom.co.jp Fri Mar 15 07:14:12 2019 From: nakajima.akira at nttcom.co.jp (Nakajima Akira) Date: Fri, 15 Mar 2019 16:14:12 +0900 Subject: [RFR] JDK-8208173 bug is U+11FF return false in isComplexCharCode() Message-ID: <839cd035-2188-377c-6cfe-81766a1e0b02@nttcom.co.jp> Hi, Please review following Github PR, https://github.com/javafxports/openjdk-jfx/pull/407 JBS: https://bugs.openjdk.java.net/browse/JDK-8208173 Regards, Nakajima Akira From johan.vos at gluonhq.com Tue Mar 19 13:21:52 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 19 Mar 2019 14:21:52 +0100 Subject: Accelerator in System MenuBar Message-ID: Related to https://github.com/javafxports/openjdk-jfx/issues/370: The issue appears on Mac, with a system menubar. When the scene contains e.g. a TextField (which has a CMD-V keymapping), and a menuitem has been assigned a CMD-V accelerator, the latter should not be invoked when the action is performed on the TextField. When the menuitem is in a normal JavaFX MenuBar, this works fine as the event handling marks the event as consumed when the TextField processes it, hence it won't continue to the accelerators. However, when the menuitem is in a system menubar, the native performKeyEquivalent function first calls the the Java layer (View.notifyKey) and then unconditionally passes the event so that the system can process it. My thinking is that this can be avoided by having the View.notifyKey returning a boolean, which is true when the Java layer consumed the event, in which case the native performKeyEquivalent should return YES. Before I create a PR on this, I wonder if there are other ideas for doing this? - Johan From wookey.dean at gmail.com Tue Mar 19 13:38:30 2019 From: wookey.dean at gmail.com (Dean Wookey) Date: Tue, 19 Mar 2019 15:38:30 +0200 Subject: Accelerator in System MenuBar In-Reply-To: References: Message-ID: Returning a boolean in View.notifyKey may also be useful for the windows bug: https://bugs.openjdk.java.net/browse/JDK-8089986 where, regardless of whether the accelerator is missing or not, there is a beeping sound. Ideally there would be a beep only if the event isn't consumed. Dean On Tue, Mar 19, 2019 at 3:23 PM Johan Vos wrote: > Related to https://github.com/javafxports/openjdk-jfx/issues/370: > > The issue appears on Mac, with a system menubar. When the scene contains > e.g. a TextField (which has a CMD-V keymapping), and a menuitem has been > assigned a CMD-V accelerator, the latter should not be invoked when the > action is performed on the TextField. > > When the menuitem is in a normal JavaFX MenuBar, this works fine as the > event handling marks the event as consumed when the TextField processes it, > hence it won't continue to the accelerators. > However, when the menuitem is in a system menubar, the native > performKeyEquivalent function first calls the the Java layer > (View.notifyKey) and then unconditionally passes the event so that the > system can process it. > My thinking is that this can be avoided by having the View.notifyKey > returning a boolean, which is true when the Java layer consumed the event, > in which case the native performKeyEquivalent should return YES. > > Before I create a PR on this, I wonder if there are other ideas for doing > this? > > - Johan > From kevin.rushforth at oracle.com Wed Mar 20 23:41:23 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 20 Mar 2019 16:41:23 -0700 Subject: Accelerator in System MenuBar In-Reply-To: References: Message-ID: <6e9d701d-3e86-32ea-ed66-00f8abf4ef39@oracle.com> This seems a reasonable approach to me. -- Kevin On 3/19/2019 6:38 AM, Dean Wookey wrote: > Returning a boolean in View.notifyKey may also be useful for the windows > bug: https://bugs.openjdk.java.net/browse/JDK-8089986 where, regardless of > whether the accelerator is missing or not, there is a beeping sound. > Ideally there would be a beep only if the event isn't consumed. > > Dean > > On Tue, Mar 19, 2019 at 3:23 PM Johan Vos wrote: > >> Related to https://github.com/javafxports/openjdk-jfx/issues/370: >> >> The issue appears on Mac, with a system menubar. When the scene contains >> e.g. a TextField (which has a CMD-V keymapping), and a menuitem has been >> assigned a CMD-V accelerator, the latter should not be invoked when the >> action is performed on the TextField. >> >> When the menuitem is in a normal JavaFX MenuBar, this works fine as the >> event handling marks the event as consumed when the TextField processes it, >> hence it won't continue to the accelerators. >> However, when the menuitem is in a system menubar, the native >> performKeyEquivalent function first calls the the Java layer >> (View.notifyKey) and then unconditionally passes the event so that the >> system can process it. >> My thinking is that this can be avoided by having the View.notifyKey >> returning a boolean, which is true when the Java layer consumed the event, >> in which case the native performKeyEquivalent should return YES. >> >> Before I create a PR on this, I wonder if there are other ideas for doing >> this? >> >> - Johan >> From anton.tarasov at jetbrains.com Thu Mar 21 15:16:06 2019 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Thu, 21 Mar 2019 18:16:06 +0300 Subject: deadlock with swing In-Reply-To: <76064910-739c-c123-332f-56f14216d437@oracle.com> References: <1ced588b-5c13-b761-a3f9-0a7cafb06cc2@jetbrains.com> <76064910-739c-c123-332f-56f14216d437@oracle.com> Message-ID: <171dbad1-4314-29a7-5050-3fafb2f50a05@jetbrains.com> Hi Kevin, Please find it here: https://bugs.openjdk.java.net/browse/JDK-8221261 Regards, Anton. On 3/14/2019 7:23 PM, Kevin Rushforth wrote: > Hi Anton, > > Can you file a bug in JBS? We can take a look at it, although it might > be difficult without a test case. > > -- Kevin > > > On 3/11/19 10:30 PM, Anton Tarasov wrote: >> Hello! >> >> Could you please take a look at the deadlock which we encounter with >> JFXPanel/WebView: >> >> "AWT-EventQueue-0" prio=0 tid=0x0 nid=0x0 waiting on condition >> ???? java.lang.Thread.State: WAITING >> ?on java.util.concurrent.FutureTask at 51c6338d >> ??? at java.base at 11.0.2/jdk.internal.misc.Unsafe.park(Native Method) >> ??? at >> java.base at 11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) >> ??? at >> java.base at 11.0.2/java.util.concurrent.FutureTask.awaitDone(FutureTask.java:447) >> ??? at >> java.base at 11.0.2/java.util.concurrent.FutureTask.get(FutureTask.java:190) >> ??? at >> platform/javafx.web at 11.0.2/com.sun.javafx.webkit.InputMethodClientImpl.getLocationOffset(InputMethodClientImpl.java:157) >> ??? at >> platform/javafx.graphics at 11.0.2/javafx.scene.Scene$InputMethodRequestsDelegate.getLocationOffset(Scene.java:4140) >> ??? at >> platform/javafx.swing at 11.0.2/javafx.embed.swing.InputMethodSupport$InputMethodRequestsAdapter.getLocationOffset(InputMethodSupport.java:67) >> ??? at >> java.desktop at 11.0.2/sun.awt.im.InputMethodContext.getLocationOffset(InputMethodContext.java:285) >> ??? at >> java.desktop at 11.0.2/sun.lwawt.macosx.CInputMethod$7.run(CInputMethod.java:779) >> ??? at >> java.desktop at 11.0.2/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) >> ??? at >> java.desktop at 11.0.2/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:776) >> ??? at >> java.desktop at 11.0.2/java.awt.EventQueue$4.run(EventQueue.java:727) >> ??? at >> java.desktop at 11.0.2/java.awt.EventQueue$4.run(EventQueue.java:721) >> ??? at >> java.base at 11.0.2/java.security.AccessController.doPrivileged(Native >> Method) >> ??? at >> java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) >> ??? at >> java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) >> ??? at >> java.desktop at 11.0.2/java.awt.EventQueue$5.run(EventQueue.java:751) >> ??? at >> java.desktop at 11.0.2/java.awt.EventQueue$5.run(EventQueue.java:749) >> ??? at >> java.base at 11.0.2/java.security.AccessController.doPrivileged(Native >> Method) >> ??? at >> java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) >> ??? at >> java.desktop at 11.0.2/java.awt.EventQueue.dispatchEvent(EventQueue.java:748) >> ??? at >> com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:723) >> ??? at >> com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:672) >> ??? at >> com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:367) >> ??? at >> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) >> ??? at >> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) >> ??? at >> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) >> ??? at >> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) >> ??? at >> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >> ??? at >> java.desktop at 11.0.2/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) >> >> "JavaFX Application Thread" prio=0 tid=0x0 nid=0x0 runnable >> ???? java.lang.Thread.State: RUNNABLE >> ?(in native) >> ??? at >> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.$$YJP$$doAWTRunLoopImpl(Native >> Method) >> ??? at >> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) >> ??? at >> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:1027) >> ??? at >> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:827) >> ??? at >> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:780) >> ??? at >> java.desktop at 11.0.2/sun.lwawt.macosx.CInputMethod.characterIndexForPoint(CInputMethod.java:777) >> >> It seems to be caused by this fix: >> https://hg.openjdk.java.net/openjfx/11/rt/rev/808d535c4e15 >> >> The "characterIndexForPoint" method performs "invokeAndWait" from >> JavaFX thread: >> >> ??????????? LWCToolkit.invokeAndWait(new Runnable() { >> ??????????????? public void run() { synchronized(offsetInfo) { >> ??????????????????? offsetInfo[0] = >> fIMContext.getLocationOffset(screenX, screenY); >> ??????????????????? insertPositionOffset[0] = >> fIMContext.getInsertPositionOffset(); >> ??????????????? }} >> ??????????? }, fAwtFocussedComponent); >> >> which is then on EDT delegates back to JavaFX thread and waits for >> async result. >> >> Is it a known issue? Unfortunately, I can't give you a simple case to >> reproduce it. Hope the problem looks clear from the description. >> >> With best regards, >> Anton. > From kevin.rushforth at oracle.com Thu Mar 21 15:23:12 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 21 Mar 2019 08:23:12 -0700 Subject: deadlock with swing In-Reply-To: <171dbad1-4314-29a7-5050-3fafb2f50a05@jetbrains.com> References: <1ced588b-5c13-b761-a3f9-0a7cafb06cc2@jetbrains.com> <76064910-739c-c123-332f-56f14216d437@oracle.com> <171dbad1-4314-29a7-5050-3fafb2f50a05@jetbrains.com> Message-ID: <74a8626c-99aa-db4a-1671-1295d1b0ec43@oracle.com> Thanks. I took a quick look at it the other day and I think I know what the problem is. -- Kevin On 3/21/2019 8:16 AM, Anton Tarasov wrote: > Hi Kevin, > > Please find it here: https://bugs.openjdk.java.net/browse/JDK-8221261 > > Regards, > Anton. > > On 3/14/2019 7:23 PM, Kevin Rushforth wrote: >> Hi Anton, >> >> Can you file a bug in JBS? We can take a look at it, although it >> might be difficult without a test case. >> >> -- Kevin >> >> >> On 3/11/19 10:30 PM, Anton Tarasov wrote: >>> Hello! >>> >>> Could you please take a look at the deadlock which we encounter with >>> JFXPanel/WebView: >>> >>> "AWT-EventQueue-0" prio=0 tid=0x0 nid=0x0 waiting on condition >>> ???? java.lang.Thread.State: WAITING >>> ?on java.util.concurrent.FutureTask at 51c6338d >>> ??? at java.base at 11.0.2/jdk.internal.misc.Unsafe.park(Native Method) >>> ??? at >>> java.base at 11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) >>> ??? at >>> java.base at 11.0.2/java.util.concurrent.FutureTask.awaitDone(FutureTask.java:447) >>> ??? at >>> java.base at 11.0.2/java.util.concurrent.FutureTask.get(FutureTask.java:190) >>> ??? at >>> platform/javafx.web at 11.0.2/com.sun.javafx.webkit.InputMethodClientImpl.getLocationOffset(InputMethodClientImpl.java:157) >>> ??? at >>> platform/javafx.graphics at 11.0.2/javafx.scene.Scene$InputMethodRequestsDelegate.getLocationOffset(Scene.java:4140) >>> ??? at >>> platform/javafx.swing at 11.0.2/javafx.embed.swing.InputMethodSupport$InputMethodRequestsAdapter.getLocationOffset(InputMethodSupport.java:67) >>> ??? at >>> java.desktop at 11.0.2/sun.awt.im.InputMethodContext.getLocationOffset(InputMethodContext.java:285) >>> ??? at >>> java.desktop at 11.0.2/sun.lwawt.macosx.CInputMethod$7.run(CInputMethod.java:779) >>> ??? at >>> java.desktop at 11.0.2/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) >>> ??? at >>> java.desktop at 11.0.2/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:776) >>> ??? at >>> java.desktop at 11.0.2/java.awt.EventQueue$4.run(EventQueue.java:727) >>> ??? at >>> java.desktop at 11.0.2/java.awt.EventQueue$4.run(EventQueue.java:721) >>> ??? at >>> java.base at 11.0.2/java.security.AccessController.doPrivileged(Native >>> Method) >>> ??? at >>> java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) >>> ??? at >>> java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) >>> ??? at >>> java.desktop at 11.0.2/java.awt.EventQueue$5.run(EventQueue.java:751) >>> ??? at >>> java.desktop at 11.0.2/java.awt.EventQueue$5.run(EventQueue.java:749) >>> ??? at >>> java.base at 11.0.2/java.security.AccessController.doPrivileged(Native >>> Method) >>> ??? at >>> java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) >>> ??? at >>> java.desktop at 11.0.2/java.awt.EventQueue.dispatchEvent(EventQueue.java:748) >>> ??? at >>> com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:723) >>> ??? at >>> com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:672) >>> ??? at >>> com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:367) >>> ??? at >>> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) >>> ??? at >>> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) >>> ??? at >>> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) >>> ??? at >>> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) >>> ??? at >>> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >>> ??? at >>> java.desktop at 11.0.2/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) >>> >>> "JavaFX Application Thread" prio=0 tid=0x0 nid=0x0 runnable >>> ???? java.lang.Thread.State: RUNNABLE >>> ?(in native) >>> ??? at >>> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.$$YJP$$doAWTRunLoopImpl(Native >>> Method) >>> ??? at >>> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) >>> ??? at >>> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:1027) >>> ??? at >>> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:827) >>> ??? at >>> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:780) >>> ??? at >>> java.desktop at 11.0.2/sun.lwawt.macosx.CInputMethod.characterIndexForPoint(CInputMethod.java:777) >>> >>> It seems to be caused by this fix: >>> https://hg.openjdk.java.net/openjfx/11/rt/rev/808d535c4e15 >>> >>> The "characterIndexForPoint" method performs "invokeAndWait" from >>> JavaFX thread: >>> >>> ??????????? LWCToolkit.invokeAndWait(new Runnable() { >>> ??????????????? public void run() { synchronized(offsetInfo) { >>> ??????????????????? offsetInfo[0] = >>> fIMContext.getLocationOffset(screenX, screenY); >>> ??????????????????? insertPositionOffset[0] = >>> fIMContext.getInsertPositionOffset(); >>> ??????????????? }} >>> ??????????? }, fAwtFocussedComponent); >>> >>> which is then on EDT delegates back to JavaFX thread and waits for >>> async result. >>> >>> Is it a known issue? Unfortunately, I can't give you a simple case >>> to reproduce it. Hope the problem looks clear from the description. >>> >>> With best regards, >>> Anton. >> From arunprasad.rajkumar at oracle.com Fri Mar 22 09:02:32 2019 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Fri, 22 Mar 2019 14:32:32 +0530 Subject: [RFR] JDK-8217942: Upgrade to libxslt 1.1.33 Message-ID: <47F2BF7C-6340-4743-9787-D9F26A130783@oracle.com> Hi Kevin, Johan, Please review the following PR which updates libxslt to 1.1.33. https://github.com/javafxports/openjdk-jfx/pull/416 Thanks, Arun From anton.tarasov at jetbrains.com Fri Mar 22 10:58:49 2019 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Fri, 22 Mar 2019 13:58:49 +0300 Subject: deadlock with swing In-Reply-To: <74a8626c-99aa-db4a-1671-1295d1b0ec43@oracle.com> References: <1ced588b-5c13-b761-a3f9-0a7cafb06cc2@jetbrains.com> <76064910-739c-c123-332f-56f14216d437@oracle.com> <171dbad1-4314-29a7-5050-3fafb2f50a05@jetbrains.com> <74a8626c-99aa-db4a-1671-1295d1b0ec43@oracle.com> Message-ID: <75db0239-ec7d-680c-cf72-c5274dd7c079@jetbrains.com> Great! Thank you. Regards, Anton. On 3/21/2019 6:23 PM, Kevin Rushforth wrote: > Thanks. I took a quick look at it the other day and I think I know > what the problem is. > > -- Kevin > > > On 3/21/2019 8:16 AM, Anton Tarasov wrote: >> Hi Kevin, >> >> Please find it here: https://bugs.openjdk.java.net/browse/JDK-8221261 >> >> Regards, >> Anton. >> >> On 3/14/2019 7:23 PM, Kevin Rushforth wrote: >>> Hi Anton, >>> >>> Can you file a bug in JBS? We can take a look at it, although it >>> might be difficult without a test case. >>> >>> -- Kevin >>> >>> >>> On 3/11/19 10:30 PM, Anton Tarasov wrote: >>>> Hello! >>>> >>>> Could you please take a look at the deadlock which we encounter >>>> with JFXPanel/WebView: >>>> >>>> "AWT-EventQueue-0" prio=0 tid=0x0 nid=0x0 waiting on condition >>>> ???? java.lang.Thread.State: WAITING >>>> ?on java.util.concurrent.FutureTask at 51c6338d >>>> ??? at java.base at 11.0.2/jdk.internal.misc.Unsafe.park(Native Method) >>>> ??? at >>>> java.base at 11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) >>>> ??? at >>>> java.base at 11.0.2/java.util.concurrent.FutureTask.awaitDone(FutureTask.java:447) >>>> ??? at >>>> java.base at 11.0.2/java.util.concurrent.FutureTask.get(FutureTask.java:190) >>>> ??? at >>>> platform/javafx.web at 11.0.2/com.sun.javafx.webkit.InputMethodClientImpl.getLocationOffset(InputMethodClientImpl.java:157) >>>> ??? at >>>> platform/javafx.graphics at 11.0.2/javafx.scene.Scene$InputMethodRequestsDelegate.getLocationOffset(Scene.java:4140) >>>> ??? at >>>> platform/javafx.swing at 11.0.2/javafx.embed.swing.InputMethodSupport$InputMethodRequestsAdapter.getLocationOffset(InputMethodSupport.java:67) >>>> ??? at >>>> java.desktop at 11.0.2/sun.awt.im.InputMethodContext.getLocationOffset(InputMethodContext.java:285) >>>> ??? at >>>> java.desktop at 11.0.2/sun.lwawt.macosx.CInputMethod$7.run(CInputMethod.java:779) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:776) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.EventQueue$4.run(EventQueue.java:727) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.EventQueue$4.run(EventQueue.java:721) >>>> ??? at >>>> java.base at 11.0.2/java.security.AccessController.doPrivileged(Native >>>> Method) >>>> ??? at >>>> java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) >>>> ??? at >>>> java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.EventQueue$5.run(EventQueue.java:751) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.EventQueue$5.run(EventQueue.java:749) >>>> ??? at >>>> java.base at 11.0.2/java.security.AccessController.doPrivileged(Native >>>> Method) >>>> ??? at >>>> java.base at 11.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.EventQueue.dispatchEvent(EventQueue.java:748) >>>> ??? at >>>> com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:723) >>>> ??? at >>>> com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:672) >>>> ??? at >>>> com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:367) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >>>> ??? at >>>> java.desktop at 11.0.2/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) >>>> >>>> "JavaFX Application Thread" prio=0 tid=0x0 nid=0x0 runnable >>>> ???? java.lang.Thread.State: RUNNABLE >>>> ?(in native) >>>> ??? at >>>> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.$$YJP$$doAWTRunLoopImpl(Native >>>> Method) >>>> ??? at >>>> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) >>>> ??? at >>>> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:1027) >>>> ??? at >>>> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:827) >>>> ??? at >>>> java.desktop at 11.0.2/sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:780) >>>> ??? at >>>> java.desktop at 11.0.2/sun.lwawt.macosx.CInputMethod.characterIndexForPoint(CInputMethod.java:777) >>>> >>>> It seems to be caused by this fix: >>>> https://hg.openjdk.java.net/openjfx/11/rt/rev/808d535c4e15 >>>> >>>> The "characterIndexForPoint" method performs "invokeAndWait" from >>>> JavaFX thread: >>>> >>>> ??????????? LWCToolkit.invokeAndWait(new Runnable() { >>>> ??????????????? public void run() { synchronized(offsetInfo) { >>>> ??????????????????? offsetInfo[0] = >>>> fIMContext.getLocationOffset(screenX, screenY); >>>> ??????????????????? insertPositionOffset[0] = >>>> fIMContext.getInsertPositionOffset(); >>>> ??????????????? }} >>>> ??????????? }, fAwtFocussedComponent); >>>> >>>> which is then on EDT delegates back to JavaFX thread and waits for >>>> async result. >>>> >>>> Is it a known issue? Unfortunately, I can't give you a simple case >>>> to reproduce it. Hope the problem looks clear from the description. >>>> >>>> With best regards, >>>> Anton. >>> > From kevin.rushforth at oracle.com Fri Mar 22 19:54:42 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 22 Mar 2019 12:54:42 -0700 Subject: HEADS-UP: bumping the boot JDK to JDK 12 for JavaFX 13 Message-ID: Now that JDK 12 has been released, I propose to bump the boot JDK used to build JavaFX 13 in production builds, and by the CI builds on GitHub, to JDK 12. This will *not* change the minimum JDK required to build or run JavaFX 13. However, there will be a couple of limitations when using JDK 11 to build or run. Also note, that while this isn't a formal RFR, since no changeset will go into the HG repo, there is a GitHub PR #410 [1] under review for the Travis and Appveyor CI test builds (which exclusively touches GitHub-only files) if anyone wants to review it. The production setup is handled outside of the repo. See JDK-8221097 [2] for more details on this. -- Kevin [1] https://github.com/javafxports/openjdk-jfx/pull/410 [2] https://bugs.openjdk.java.net/browse/JDK-8221097 From razvan.rotaru at gmail.com Sun Mar 24 14:16:29 2019 From: razvan.rotaru at gmail.com (=?UTF-8?Q?R=C4=83zvan_Rotaru?=) Date: Sun, 24 Mar 2019 16:16:29 +0200 Subject: static initialisation of javafx.stage.Screen causing problems with clojure In-Reply-To: References: Message-ID: Hi, I am trying to use OpenJFX 11.0.2 (for Linux) with Clojure and https://github.com/fn-fx/fn-fx, and stumbled upon a problem for which I would like to ask for advice here. The Problem occurs during compilation of some clojure code, which triggers class loading for javafx.stage.Screen, which fails with following stack trace (only the relevant part): java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = main at com.sun.glass.ui.Application.checkEventThread(Application.java:441) at com.sun.glass.ui.Screen.setEventHandler(Screen.java:369) at com.sun.javafx.tk.quantum.QuantumToolkit.setScreenConfigurationListener(QuantumToolkit.java:684) at javafx.stage.Screen.(Screen.java:74) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:398) at clojure.lang.RT.classForName(RT.java:2207) at clojure.lang.RT.classForName(RT.java:2216) at clojure.lang.Compiler.resolveIn(Compiler.java:7394) at clojure.lang.Compiler.resolve(Compiler.java:7357) at clojure.lang.Compiler.analyzeSymbol(Compiler.java:7318) at clojure.lang.Compiler.analyze(Compiler.java:6768) at clojure.lang.Compiler.analyze(Compiler.java:6745) at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3888) Being only compilation, there should be no Toolkit initialisation, hence no event thread. Looking at the code it seems that the Screen class can only be loaded from the event thread. Is this a bug or the intended behaviour? Is there a way around this for my use case? How does OpenJFX ensure that Screen is always loaded on the correct thread? Related bug in fn-fx: https://github.com/fn-fx/fn-fx/issues/25 Cheers, R?zvan > From peter.levart at gmail.com Mon Mar 25 15:41:23 2019 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 25 Mar 2019 16:41:23 +0100 Subject: static initialisation of javafx.stage.Screen causing problems with clojure In-Reply-To: References: Message-ID: Hi Razvan, I don't know Clojure but if this happens during compilation of Clojure source(s) (in clojure.lang.Compile), then the question is: Does Clojure compiler really need to execute static initializers of classes it is "resolving"? It seems it needs to load the classes (presumably because it is using Java reflection to introspect them), but does it really need to initialize the classes? If it only needs to introspect the classes (but not execute constructors or methods in them or access fields), then it should be using the 3-arg Class.forName() method: ???? public static Class forName(String name, boolean initialize, ClassLoader loader) ...passing 'false' as the 2nd argument. That way the "resolved" classes would be loaded but not initialized. Clojure compiler could still introspect them, but no code in classes would be executed. This would be much safer. Regards, Peter On 3/24/19 3:16 PM, R?zvan Rotaru wrote: > Hi, > > I am trying to use OpenJFX 11.0.2 (for Linux) with Clojure and > https://github.com/fn-fx/fn-fx, and stumbled upon a problem for which I > would like to ask for advice here. The Problem occurs during compilation of > some clojure code, which triggers class loading for javafx.stage.Screen, > which fails with following stack trace (only the relevant part): > > java.lang.IllegalStateException: This operation is permitted on the event > thread only; currentThread = main > at com.sun.glass.ui.Application.checkEventThread(Application.java:441) > at com.sun.glass.ui.Screen.setEventHandler(Screen.java:369) > at > com.sun.javafx.tk.quantum.QuantumToolkit.setScreenConfigurationListener(QuantumToolkit.java:684) > at javafx.stage.Screen.(Screen.java:74) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:398) > at clojure.lang.RT.classForName(RT.java:2207) > at clojure.lang.RT.classForName(RT.java:2216) > at clojure.lang.Compiler.resolveIn(Compiler.java:7394) > at clojure.lang.Compiler.resolve(Compiler.java:7357) > at clojure.lang.Compiler.analyzeSymbol(Compiler.java:7318) > at clojure.lang.Compiler.analyze(Compiler.java:6768) > at clojure.lang.Compiler.analyze(Compiler.java:6745) > at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3888) > > Being only compilation, there should be no Toolkit initialisation, hence no > event thread. Looking at the code it seems that the Screen class can only > be loaded from the event thread. Is this a bug or the intended behaviour? > Is there a way around this for my use case? How does OpenJFX ensure that > Screen is always loaded on the correct thread? > > Related bug in fn-fx: https://github.com/fn-fx/fn-fx/issues/25 > > > Cheers, > R?zvan > From kevin.rushforth at oracle.com Mon Mar 25 17:50:02 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 25 Mar 2019 10:50:02 -0700 Subject: [13] RFR: JDK-8215686: FX build fails using gradle 5 Message-ID: <653bb5fa-7626-12a6-00f6-6bf68d9321bb@oracle.com> Please review the following to fix issues in gradle that are needed to allow building with gradle 5, in addition to continuing to allow building with gradle 4. https://bugs.openjdk.java.net/browse/JDK-8215686 https://github.com/javafxports/openjdk-jfx/pull/414 Details are in the GitHub PR. -- Kevin From kevin.rushforth at oracle.com Mon Mar 25 20:36:32 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 25 Mar 2019 13:36:32 -0700 Subject: [13] RFR: JDK-8210508: Update JDK_DOCS property to point to JDK 12 docs Message-ID: <92df73ff-ba29-2d21-0d9b-240345dac00d@oracle.com> Please review the following simple fix to point to the JDK 12 API docs when generating links from the JavaFX 13 docs: https://bugs.openjdk.java.net/browse/JDK-8210508 https://github.com/javafxports/openjdk-jfx/pull/420 -- Kevin From wookey.dean at gmail.com Tue Mar 26 08:30:02 2019 From: wookey.dean at gmail.com (Dean Wookey) Date: Tue, 26 Mar 2019 10:30:02 +0200 Subject: EM Font Size Performance In-Reply-To: References: <6197cbbe-5152-6e1d-d3d0-a38f3556dc8d@oracle.com> <6bc18460-15a8-74d7-3cff-082c87aee1c4@oracle.com> <41f76892-849a-36a5-bceb-f1c97275e355@oracle.com> Message-ID: I've made what I've believe to be a cleaner fix here: https://github.com/DeanWookey/openjdk-jfx/commit/295a3e136c59eb661021de7b4c7ead8bd36a749a I'm not sure exactly how to proceed from here. I submitted a bug report several weeks ago so that I could submit a pull request against it, but I've heard nothing back. Should I create a bug report myself since I have author status now? Should I just create a pull request on github to discuss the implementation there, and link the bug report later? Dean On Fri, Jan 18, 2019 at 10:28 AM Dean Wookey wrote: > I've only tested with our application that includes all those things. We > set a font size on the root node and everything is done in em. The user can > change the font size of the root node, which filters down to things like > tooltips, context menus, tables etc. > > Do you know if there are tests specifically for these things? > > Otherwise, I'm not 100% happy with this fix because I feel it makes things > more confusing. In my opinion the lookupFont should cache itself, or there > should be a cachedLookupFont which does this. I don't really understand the > special cases of SKIP and null however, so I replicated the steps used to > cache the result elsewhere. I think it would be better if someone else made > a more comprehensive fix which made things a little clearer. > > Dean > > On Thu, Jan 17, 2019 at 6:41 PM David Grieve > wrote: > >> I think the change looks reasonable. Has it been tested against things >> like changing -fx-font in some parent, or setting the font property in some >> parent? What about popups? If I have a tooltip on a Label, for example, >> does the tooltip properly pick up font from the Label's style or font >> property? >> On 1/17/19 11:10 AM, Dean Wookey wrote: >> >> This is almost a year old, but I think I've found a partial solution >> (David's suggestions on a top down approach still make sense, but that's a >> bigger issue). Caching an uncached call to lookupFont definitely improves >> performance. >> >> >> https://github.com/DeanWookey/openjdk-jfx/commit/e12f00fb6c2fc690c0a7fb089f7b0c81d6930fa9 >> >> >> Using a stack of 50 stackpanes instead of 20, I now get the following: >> >> Before modification: >> >> With setting font size: 10675ms >> Without setting font size: 49243ms >> >> After modification: >> >> With setting font size: 10852ms >> Without setting font size: 20357ms >> >> Dean >> >> On Thu, Apr 19, 2018 at 9:51 PM David Grieve >> wrote: >> >>> I was thinking about https://bugs.openjdk.java.net/browse/JDK-8177635 >>> and https://bugs.openjdk.java.net/browse/JDK-8090462 >>> >>> There is also https://bugs.openjdk.java.net/browse/JDK-8187955 >>> >>> On 4/19/18 3:02 PM, Nir Lisker wrote: >>> >>> I think this is the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8088615. There's also >>> https://bugs.openjdk.java.net/browse/JDK-8193445. >>> >>> - Nir >>> >>> On Thu, Apr 19, 2018 at 1:42 PM, David Grieve >>> wrote: >>> >>>> Resolving the relative size involves a lot of lookup. You have to go up >>>> the scene-graph from the child to find a font style. If you get to the root >>>> and haven't found a font style, then use the default font. Performance in >>>> this area could be vastly improved by passing the size from either a font >>>> style or the default font down the scene-graph as styles are evaluated. >>>> There are other style lookups that could benefit from this as well, >>>> resolving looked-up colors for example. I believe I created a bug for this >>>> a long time ago. >>>> >>>> >>>> >>>> On 4/19/18 5:57 AM, Dean Wookey wrote: >>>> >>>>> Hi All, >>>>> >>>>> In our application we add and remove a lot of nodes to the scene graph >>>>> regularly, and also make use of em font sizes to scale certain parts >>>>> of our >>>>> application. We've noticed performance issues when adding nodes to the >>>>> scene, and it seems to be related to em sizes in our css. >>>>> >>>>> As a test we added a chain of 20 stackpanes to a root stackpane. On the >>>>> root, we set a font size of 8pt via inline css. We then added and >>>>> removed a >>>>> new tableview from the deepest stackpane 500 times, waiting for the >>>>> node to >>>>> render after each add and remove. >>>>> >>>>> In each of the experiments, we compared adding tableviews without css >>>>> and >>>>> adding tableviews with an inline css font size of 8pt. We then tried >>>>> setting different font sizes in the stackpane chain. >>>>> >>>>> I've attached sample code for these experiments. >>>>> >>>>> The results (on jdk 9.0.4 - jdk 10 was similar) are as follows: >>>>> >>>>> Setting a 1em font size on all stackpanes except the root. >>>>> With font on tableview: 14707ms >>>>> Without font on tableview: 27725ms >>>>> >>>>> Setting a 1em font size on the first child of the root only. >>>>> With font on tableview: 14221ms >>>>> Without font on tableview: 19187ms >>>>> >>>>> Using the original setup with no additional fonts. >>>>> With font on tableview: 13990ms >>>>> Without font on tableview: 13847ms >>>>> >>>>> It looks like using a relative font size has a large effect performance >>>>> wise on descendant nodes. I would expect some amount of font size >>>>> caching >>>>> in the chain of stackpanes since I'm reusing the same chain and >>>>> adding/removing nodes from that chain repeatedly. >>>>> >>>>> I'm not sure how valid my test is, or how much of an issue this really >>>>> is >>>>> in practice? >>>>> >>>>> Dean >>>>> >>>> >>>> >>> >>> From finn at thebuilders.de Tue Mar 26 08:40:16 2019 From: finn at thebuilders.de (Finn Herpich) Date: Tue, 26 Mar 2019 09:40:16 +0100 Subject: Custom InputControl w/o char->string conversion Message-ID: <4a5558d1-feac-3bad-4014-72f5eaeb2b6b@thebuilders.de> Hi everyone, I'll hope this is the right place to ask. I'm currently evaluating multiple ways to write a cross platform application with the requirement to be able to clear certain inputs from memory rather quickly and not wait for the GCs mercy. I've tracked the JavaFx TextInputControls back to the point where the character from the input event is transformed into a string. Which happens roughly in com.sun.javafx.tk.quantum.GlassViewEventHandler. My questions results in, if it would be possible to write a custom control (or some other way) which would leave at least no traces in the string pool? Right now I've not enough knowledge about JavaFX internals, but it seems like this event handling is implemented way down the rabbit hole and it looks like a major afford to avoid the char->string conversion? I would be happy about any pointers where to look/start, or if a project like this would be doomed from the start =). Cheers, Finn -- Alice and the Builders GmbH Grantham-Allee 2-8, 53757 Sankt Augustin Amtsgericht ? Registergericht ? Siegburg HRB 13552, Sitz Siegburg Gesch?ftsf?hrer: Michael Sczepanski, Martin Hensel, Finn Herpich From nicolas.therrien at motorolasolutions.com Tue Mar 26 11:49:53 2019 From: nicolas.therrien at motorolasolutions.com (Nicolas Therrien) Date: Tue, 26 Mar 2019 07:49:53 -0400 Subject: Custom InputControl w/o char->string conversion In-Reply-To: <4a5558d1-feac-3bad-4014-72f5eaeb2b6b@thebuilders.de> References: <4a5558d1-feac-3bad-4014-72f5eaeb2b6b@thebuilders.de> Message-ID: Hi Finn, I assume you are coming from a C# background and looking for a SecureString equivalent in Java. Check out this: https://github.com/OWASP/passfault/blob/master/core/src/main/java/org/owasp/passfault/impl/SecureString.java You could write your own javafx component with OWASP SecureString and achieve the same result as in C#. Hopefully this answers your question. That being said, what you said about being faster than garbage collection and again assuming you had SecureString in mind, makes me think you might not really understand the purpose of SecureString in C#. It does NOT guarantee that an attacker would not be able to see the string if they had access to the application's runtime memory. Think about it: if you can TYPE your password, there was a byte array containing your clear text password before it was put in the SecureString. And then if you can USE that password (during a database connection), there was a byte array containing your clear text password when you sent it to the driver. A simple breakpoint in the right spot and a heap dump would reveal your password, always. The reason is simple: your application does need to know the password! The purpose of SecureString is not to protect from being able to capture the password in memory or from heap dumps. The purpose is to avoid the password from leaking in log files, console output or in application messaging. By creating a separate String class extension for it, the developers made sure that inadvertently calling "toString()" (as a logger would do) would return some encrypted garbage. SecureString is a simply a Safeguard against leaking sensitive strings in logs, console output and application messaging. If you are still concerned about someone inspecting the heap and look for the short lived byte arrays containing what you typed, you can always call .fill(0) on that byte array when you're done with it to make it harder for the attacker. The OWASP class i shared with you does that in the constructor. But again, if the attacker has access to your process, all he has to do is set a breakpoint to the SecureString constructor and voila, he can read the byte buffer before its encrypted. Wiping only makes sure that the original byte array could not inadvertently be the source of a leak later (ie someone uses the byte array instead of the string)..That's the real reason why the OWASP class is wiping the array. Best regards, *Nicolas Therrien* Senior Software Developer *[image: https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]* *o*: +1.819.931.2053 On Tue, Mar 26, 2019 at 4:42 AM Finn Herpich wrote: > Hi everyone, > > I'll hope this is the right place to ask. I'm currently evaluating > multiple ways to write a cross platform application with the requirement > to be able to clear certain inputs from memory rather quickly and not > wait for the GCs mercy. > > I've tracked the JavaFx TextInputControls back to the point where the > character from the input event is transformed into a string. Which > happens roughly in com.sun.javafx.tk.quantum.GlassViewEventHandler. > > My questions results in, if it would be possible to write a custom > control (or some other way) which would leave at least no traces in the > string pool? Right now I've not enough knowledge about JavaFX internals, > but it seems like this event handling is implemented way down the rabbit > hole and it looks like a major afford to avoid the char->string conversion? > > I would be happy about any pointers where to look/start, or if a project > like this would be doomed from the start =). > > Cheers, > Finn > > -- > Alice and the Builders GmbH > Grantham-Allee 2-8, 53757 Sankt Augustin > Amtsgericht ? Registergericht ? Siegburg > HRB 13552, Sitz Siegburg > Gesch?ftsf?hrer: Michael Sczepanski, Martin Hensel, Finn Herpich > > From razvan.rotaru at gmail.com Tue Mar 26 12:18:02 2019 From: razvan.rotaru at gmail.com (=?UTF-8?Q?R=C4=83zvan_Rotaru?=) Date: Tue, 26 Mar 2019 14:18:02 +0200 Subject: static initialisation of javafx.stage.Screen causing problems with clojure In-Reply-To: References: Message-ID: Thank you. I don't know whether the clojure compiler needs initialized classes or not, but I suspect it does. Clojure has macros, which are executed at compile time, which means some classes are instantiated. I will ask the clojure developers. If that's the case though it means clojure will not be able to compile Java FX. This is actually half bad, since this is only needed when one uses something called ahead of time compilation (AOT), so one can use Java FX in clojure but not with AOT (i.e. compilation will occur at runtime). But apart from that, I think it's rather strange that class loading/initalisation depends on the thread it happens. How do you make sure that javafx.stage.Screen is not loaded from the wrong thread? Regards, R?zvan On Mon, 25 Mar 2019 at 17:41, Peter Levart wrote: > Hi Razvan, > > I don't know Clojure but if this happens during compilation of Clojure > source(s) (in clojure.lang.Compile), then the question is: Does Clojure > compiler really need to execute static initializers of classes it is > "resolving"? It seems it needs to load the classes (presumably because > it is using Java reflection to introspect them), but does it really need > to initialize the classes? > > If it only needs to introspect the classes (but not execute constructors > or methods in them or access fields), then it should be using the 3-arg > Class.forName() method: > > public static Class forName(String name, boolean initialize, > ClassLoader loader) > > ...passing 'false' as the 2nd argument. That way the "resolved" classes > would be loaded but not initialized. Clojure compiler could still > introspect them, but no code in classes would be executed. This would be > much safer. > > Regards, Peter > > > On 3/24/19 3:16 PM, R?zvan Rotaru wrote: > > Hi, > > > > I am trying to use OpenJFX 11.0.2 (for Linux) with Clojure and > > https://github.com/fn-fx/fn-fx, and stumbled upon a problem for which I > > would like to ask for advice here. The Problem occurs during compilation > of > > some clojure code, which triggers class loading for javafx.stage.Screen, > > which fails with following stack trace (only the relevant part): > > > > java.lang.IllegalStateException: This operation is permitted on the event > > thread only; currentThread = main > > at > com.sun.glass.ui.Application.checkEventThread(Application.java:441) > > at com.sun.glass.ui.Screen.setEventHandler(Screen.java:369) > > at > > > com.sun.javafx.tk.quantum.QuantumToolkit.setScreenConfigurationListener(QuantumToolkit.java:684) > > at javafx.stage.Screen.(Screen.java:74) > > at java.base/java.lang.Class.forName0(Native Method) > > at java.base/java.lang.Class.forName(Class.java:398) > > at clojure.lang.RT.classForName(RT.java:2207) > > at clojure.lang.RT.classForName(RT.java:2216) > > at clojure.lang.Compiler.resolveIn(Compiler.java:7394) > > at clojure.lang.Compiler.resolve(Compiler.java:7357) > > at clojure.lang.Compiler.analyzeSymbol(Compiler.java:7318) > > at clojure.lang.Compiler.analyze(Compiler.java:6768) > > at clojure.lang.Compiler.analyze(Compiler.java:6745) > > at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3888) > > > > Being only compilation, there should be no Toolkit initialisation, hence > no > > event thread. Looking at the code it seems that the Screen class can only > > be loaded from the event thread. Is this a bug or the intended behaviour? > > Is there a way around this for my use case? How does OpenJFX ensure that > > Screen is always loaded on the correct thread? > > > > Related bug in fn-fx: https://github.com/fn-fx/fn-fx/issues/25 > > > > > > Cheers, > > R?zvan > > > > From finn at thebuilders.de Tue Mar 26 13:07:24 2019 From: finn at thebuilders.de (Finn Herpich) Date: Tue, 26 Mar 2019 14:07:24 +0100 Subject: Custom InputControl w/o char->string conversion In-Reply-To: References: <4a5558d1-feac-3bad-4014-72f5eaeb2b6b@thebuilders.de> Message-ID: <26d5fd09-4ea4-d739-2d4f-2d8ee2f594f0@thebuilders.de> Hi Nicolas, thanks for the long write up. I'm indeed working with a lot of C# in the last year, but that is a pure accident, to reproduce the SecureString-class was not my intention. I'm totally aware of the problems you are listing, but sadly I've to handle sensitive information which force me to reduce the attack surface to a bare minimum for certain values. If an attacker has full access to my process, as you said, it is game over; However I'm trying to reduce the points in time where a value could get leaked to a pagefile or whatever you can think of to be recovered later by memory forensics and such. I know that I'm limit to how the OS handles memory, memory access rights within the system, etc. and I've talked to multiple penetration testers/security analysts in the past few weeks. So coming from that requirement I did some tests with char arrays in java which I at least could overwrite quickly enough to minimize the points in time where it could be read and wasn't able to find any traces left in memory (as you also mentioned with the .fill method). However using OpenJFX controls I found my inputs multiple times in memory afterwards, which lead me to the com.sun.javafx.tk.quantum.GlassViewEventHandler class where the input event is converted into a string and I somehow have the impression that it would be some major work to get this out of the event flow for a specialized control. In the worst case I've to go back to C++, where it is hard to write secure code, or Rust/Go which don't have such a wonderful and easy deployable cross platform GUI like Java does with openjfx. Cheers, Finn On 26.03.19 12:49, Nicolas Therrien wrote: > Hi Finn, > > I assume you are coming from a C# background and looking for a > SecureString equivalent in Java.? ?Check out this: > https://github.com/OWASP/passfault/blob/master/core/src/main/java/org/owasp/passfault/impl/SecureString.java > > You could write your own javafx component with OWASP SecureString and > achieve the same result as in C#. > > Hopefully this answers your question. > > That being said, what you said about being faster than garbage > collection and again assuming you had SecureString in mind, makes me > think you might not really understand the purpose of SecureString in > C#.? It does NOT guarantee that an attacker would not be able to see the > string if they had access to the application's runtime memory. Think > about it: if you can TYPE your password, there was a byte array > containing your clear text password before it was put in the > SecureString. And then if you can USE that password (during a database > connection), there was a byte array containing your clear text password > when you sent it to the driver. A simple breakpoint in the right spot > and a heap dump would reveal your password, always. The reason is > simple: your application does need to know the password! > > The purpose of SecureString is not to protect from being able to capture > the password in memory or from heap dumps. The purpose is to avoid the > password from leaking in log files, console output or in application > messaging. By creating a separate String class extension for it, the > developers made sure that inadvertently calling "toString()" (as a > logger would do) would return some encrypted garbage. > > SecureString is a simply a Safeguard against leaking sensitive strings > in logs, console output and application messaging. > > If you are still concerned about someone inspecting the heap and look > for the short lived byte arrays containing what you typed, you can > always call .fill(0) on that byte array when you're done with it to make > it harder for the attacker. The OWASP class i shared with you does that > in the constructor. But again, if the attacker has access to your > process, all he has to do is set a breakpoint to the SecureString > constructor and voila, he can read the byte buffer before its > encrypted.? Wiping only makes sure that the original byte array could > not inadvertently be the source of a leak later (ie someone uses the > byte array instead of the string)..That's the real reason why the OWASP > class is wiping the array. > > Best regards, > > *Nicolas Therrien* > > Senior Software Developer > > /https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png/ > > *o*: +1.819.931.2053 > > > > On Tue, Mar 26, 2019 at 4:42 AM Finn Herpich > wrote: > > Hi everyone, > > I'll hope this is the right place to ask. I'm currently evaluating > multiple ways to write a cross platform application with the > requirement > to be able to clear certain inputs from memory rather quickly and not > wait for the GCs mercy. > > I've tracked the JavaFx TextInputControls back to the point where the > character from the input event is transformed into a string. Which > happens roughly in com.sun.javafx.tk.quantum.GlassViewEventHandler. > > My questions results in, if it would be possible to write a custom > control (or some other way) which would leave at least no traces in the > string pool? Right now I've not enough knowledge about JavaFX > internals, > but it seems like this event handling is implemented way down the > rabbit > hole and it looks like a major afford to avoid the char->string > conversion? > > I would be happy about any pointers where to look/start, or if a > project > like this would be doomed from the start =). > > Cheers, > Finn > > -- > Alice and the Builders GmbH > Grantham-Allee 2-8, 53757 Sankt Augustin > Amtsgericht ? Registergericht ? Siegburg > HRB 13552, Sitz Siegburg > Gesch?ftsf?hrer: Michael Sczepanski, Martin Hensel, Finn Herpich > -- Alice and the Builders GmbH Grantham-Allee 2-8, 53757 Sankt Augustin Amtsgericht ? Registergericht ? Siegburg HRB 13552, Sitz Siegburg Gesch?ftsf?hrer: Michael Sczepanski, Martin Hensel, Finn Herpich From david.grieve at oracle.com Tue Mar 26 13:35:08 2019 From: david.grieve at oracle.com (David Grieve) Date: Tue, 26 Mar 2019 09:35:08 -0400 Subject: Custom InputControl w/o char->string conversion In-Reply-To: <26d5fd09-4ea4-d739-2d4f-2d8ee2f594f0@thebuilders.de> References: <4a5558d1-feac-3bad-4014-72f5eaeb2b6b@thebuilders.de> <26d5fd09-4ea4-d739-2d4f-2d8ee2f594f0@thebuilders.de> Message-ID: <6f6c60ed-61a0-1b93-9806-f961a557c312@oracle.com> Have you looked at javax.security.auth.Destroyable? On 3/26/19 9:07 AM, Finn Herpich wrote: > Hi Nicolas, > > thanks for the long write up. I'm indeed working with a lot of C# in > the last year, but that is a pure accident, to reproduce the > SecureString-class was not my intention. > I'm totally aware of the problems you are listing, but sadly I've to > handle sensitive information which force me to reduce the attack > surface to a bare minimum for certain values. If an attacker has full > access to my process, as you said, it is game over; However I'm trying > to reduce the points in time where a value could get leaked to a > pagefile or whatever you can think of to be recovered later by memory > forensics and such. I know that I'm limit to how the OS handles > memory, memory access rights within the system, etc. and I've talked > to multiple penetration testers/security analysts in the past few weeks. > > So coming from that requirement I did some tests with char arrays in > java which I at least could overwrite quickly enough to minimize the > points in time where it could be read and wasn't able to find any > traces left in memory (as you also mentioned with the .fill method). > However using OpenJFX controls I found my inputs multiple times in > memory afterwards, which lead me to the > com.sun.javafx.tk.quantum.GlassViewEventHandler class where the input > event is converted into a string and I somehow have the impression > that it would be some major work to get this out of the event flow for > a specialized control. > > In the worst case I've to go back to C++, where it is hard to write > secure code, or Rust/Go which don't have such a wonderful and easy > deployable cross platform GUI like Java does with openjfx. > > Cheers, > Finn > > On 26.03.19 12:49, Nicolas Therrien wrote: >> Hi Finn, >> >> I assume you are coming from a C# background and looking for a >> SecureString equivalent in Java.? ?Check out this: >> https://github.com/OWASP/passfault/blob/master/core/src/main/java/org/owasp/passfault/impl/SecureString.java >> >> >> You could write your own javafx component with OWASP SecureString and >> achieve the same result as in C#. >> >> Hopefully this answers your question. >> >> That being said, what you said about being faster than garbage >> collection and again assuming you had SecureString in mind, makes me >> think you might not really understand the purpose of SecureString in >> C#.? It does NOT guarantee that an attacker would not be able to see >> the string if they had access to the application's runtime memory. >> Think about it: if you can TYPE your password, there was a byte array >> containing your clear text password before it was put in the >> SecureString. And then if you can USE that password (during a >> database connection), there was a byte array containing your clear >> text password when you sent it to the driver. A simple breakpoint in >> the right spot and a heap dump would reveal your password, always. >> The reason is simple: your application does need to know the password! >> >> The purpose of SecureString is not to protect from being able to >> capture the password in memory or from heap dumps. The purpose is to >> avoid the password from leaking in log files, console output or in >> application messaging. By creating a separate String class extension >> for it, the developers made sure that inadvertently calling >> "toString()" (as a logger would do) would return some encrypted garbage. >> >> SecureString is a simply a Safeguard against leaking sensitive >> strings in logs, console output and application messaging. >> >> If you are still concerned about someone inspecting the heap and look >> for the short lived byte arrays containing what you typed, you can >> always call .fill(0) on that byte array when you're done with it to >> make it harder for the attacker. The OWASP class i shared with you >> does that in the constructor. But again, if the attacker has access >> to your process, all he has to do is set a breakpoint to the >> SecureString constructor and voila, he can read the byte buffer >> before its encrypted.? Wiping only makes sure that the original byte >> array could not inadvertently be the source of a leak later (ie >> someone uses the byte array instead of the string)..That's the real >> reason why the OWASP class is wiping the array. >> >> Best regards, >> >> *Nicolas Therrien* >> >> Senior Software Developer >> >> /https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png/ >> >> >> *o*: +1.819.931.2053 >> >> >> >> On Tue, Mar 26, 2019 at 4:42 AM Finn Herpich > > wrote: >> >> ??? Hi everyone, >> >> ??? I'll hope this is the right place to ask. I'm currently evaluating >> ??? multiple ways to write a cross platform application with the >> ??? requirement >> ??? to be able to clear certain inputs from memory rather quickly and >> not >> ??? wait for the GCs mercy. >> >> ??? I've tracked the JavaFx TextInputControls back to the point where >> the >> ??? character from the input event is transformed into a string. Which >> ??? happens roughly in com.sun.javafx.tk.quantum.GlassViewEventHandler. >> >> ??? My questions results in, if it would be possible to write a custom >> ??? control (or some other way) which would leave at least no traces >> in the >> ??? string pool? Right now I've not enough knowledge about JavaFX >> ??? internals, >> ??? but it seems like this event handling is implemented way down the >> ??? rabbit >> ??? hole and it looks like a major afford to avoid the char->string >> ??? conversion? >> >> ??? I would be happy about any pointers where to look/start, or if a >> ??? project >> ??? like this would be doomed from the start =). >> >> ??? Cheers, >> ??? Finn >> >> ??? -- ??? Alice and the Builders GmbH >> ??? Grantham-Allee 2-8, 53757 Sankt Augustin >> ??? Amtsgericht ? Registergericht ? Siegburg >> ??? HRB 13552, Sitz Siegburg >> ??? Gesch?ftsf?hrer: Michael Sczepanski, Martin Hensel, Finn Herpich >> > > From pruteanu at gmail.com Tue Mar 26 20:53:19 2019 From: pruteanu at gmail.com (dprutean) Date: Tue, 26 Mar 2019 21:53:19 +0100 Subject: Drag & Drop errors on Linux/Ubuntu Message-ID: Hi, JavaFx 12 got issues with drag&drop on Ubuntu. (java:3346): GLib-GObject-WARNING **: 13:50:41.198: ../../../../gobject/gsignal.c:2523: signal 'expose-event' is invalid for instance '0x7f43343c6520' of type 'GtkWindow' Is this something known ? Thank you, Dragos From kevin.rushforth at oracle.com Wed Mar 27 12:16:17 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 27 Mar 2019 05:16:17 -0700 Subject: [13] RFR: JDK-8218172: Upgrade gradle to version 5.3 Message-ID: Please review the following request to update our builds to use gradle 5.3: https://bugs.openjdk.java.net/browse/JDK-8218172 https://github.com/javafxports/openjdk-jfx/pull/421 Note that this will not change the minimum version needed to build JavaFX, which remains at gradle 4.3 (for now). -- Kevin From peter.levart at gmail.com Wed Mar 27 14:08:45 2019 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 27 Mar 2019 15:08:45 +0100 Subject: static initialisation of javafx.stage.Screen causing problems with clojure In-Reply-To: References: Message-ID: On 3/26/19 1:18 PM, R?zvan Rotaru wrote: > Thank you. I don't know whether the clojure compiler needs initialized > classes or not, but I suspect it does. Clojure has macros, which are > executed at compile time, which means some classes are instantiated. I will > ask the clojure developers. If that's the case though it means clojure will > not be able to compile Java FX. This is actually half bad, since this is > only needed when one uses something called ahead of time compilation (AOT), > so one can use Java FX in clojure but not with AOT (i.e. compilation will > occur at runtime). > > But apart from that, I think it's rather strange that class > loading/initalisation depends on the thread it happens. How do you make > sure that javafx.stage.Screen is not loaded from the wrong thread? Java (JVM) loads and initializes classes lazily, when 1st needed. So if javafx.stage.Screen API is specified to be invoked in special JavaFX Application thread only, then this is where the static initializer will get executed too. It seems that this has not been a problem for normal (Java-side) use. Regards, Peter > > Regards, > R?zvan > > > On Mon, 25 Mar 2019 at 17:41, Peter Levart wrote: > >> Hi Razvan, >> >> I don't know Clojure but if this happens during compilation of Clojure >> source(s) (in clojure.lang.Compile), then the question is: Does Clojure >> compiler really need to execute static initializers of classes it is >> "resolving"? It seems it needs to load the classes (presumably because >> it is using Java reflection to introspect them), but does it really need >> to initialize the classes? >> >> If it only needs to introspect the classes (but not execute constructors >> or methods in them or access fields), then it should be using the 3-arg >> Class.forName() method: >> >> public static Class forName(String name, boolean initialize, >> ClassLoader loader) >> >> ...passing 'false' as the 2nd argument. That way the "resolved" classes >> would be loaded but not initialized. Clojure compiler could still >> introspect them, but no code in classes would be executed. This would be >> much safer. >> >> Regards, Peter >> >> >> On 3/24/19 3:16 PM, R?zvan Rotaru wrote: >>> Hi, >>> >>> I am trying to use OpenJFX 11.0.2 (for Linux) with Clojure and >>> https://github.com/fn-fx/fn-fx, and stumbled upon a problem for which I >>> would like to ask for advice here. The Problem occurs during compilation >> of >>> some clojure code, which triggers class loading for javafx.stage.Screen, >>> which fails with following stack trace (only the relevant part): >>> >>> java.lang.IllegalStateException: This operation is permitted on the event >>> thread only; currentThread = main >>> at >> com.sun.glass.ui.Application.checkEventThread(Application.java:441) >>> at com.sun.glass.ui.Screen.setEventHandler(Screen.java:369) >>> at >>> >> com.sun.javafx.tk.quantum.QuantumToolkit.setScreenConfigurationListener(QuantumToolkit.java:684) >>> at javafx.stage.Screen.(Screen.java:74) >>> at java.base/java.lang.Class.forName0(Native Method) >>> at java.base/java.lang.Class.forName(Class.java:398) >>> at clojure.lang.RT.classForName(RT.java:2207) >>> at clojure.lang.RT.classForName(RT.java:2216) >>> at clojure.lang.Compiler.resolveIn(Compiler.java:7394) >>> at clojure.lang.Compiler.resolve(Compiler.java:7357) >>> at clojure.lang.Compiler.analyzeSymbol(Compiler.java:7318) >>> at clojure.lang.Compiler.analyze(Compiler.java:6768) >>> at clojure.lang.Compiler.analyze(Compiler.java:6745) >>> at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3888) >>> >>> Being only compilation, there should be no Toolkit initialisation, hence >> no >>> event thread. Looking at the code it seems that the Screen class can only >>> be loaded from the event thread. Is this a bug or the intended behaviour? >>> Is there a way around this for my use case? How does OpenJFX ensure that >>> Screen is always loaded on the correct thread? >>> >>> Related bug in fn-fx: https://github.com/fn-fx/fn-fx/issues/25 >>> >>> >>> Cheers, >>> R?zvan >>> >> From andrew at nmedia.net Wed Mar 27 18:29:00 2019 From: andrew at nmedia.net (Andrew Munn) Date: Wed, 27 Mar 2019 11:29:00 -0700 (PDT) Subject: EventHandler not working in 11.0.2 Message-ID: How do I listen for mouse events in 11.0.2? IntelliJ's code completion suggests this: textField.addEventHandler(MouseEvent.MOUSE_ENTERED, (EventHandler) t -> { // do something }); but it fails to compile with error: cannot find symbol T Thanks From thomas.manz+JFX at gmail.com Wed Mar 27 19:36:45 2019 From: thomas.manz+JFX at gmail.com (Thomas Manz) Date: Wed, 27 Mar 2019 20:36:45 +0100 Subject: Fwd: JavaFX 11 on Raspberry Pi In-Reply-To: <003f01d4cba5$8e5d0450$ab170cf0$@gmail.com> References: <003f01d4cba5$8e5d0450$ab170cf0$@gmail.com> Message-ID: Hello, in the last months I started to do some tests with Java 11 and JavaFX 11 on a Raspberry Pi 3. I followed this manual (http://docs.gluonhq.com/embedded/) but unfortunately I realized that so far Gluon?s EA build of JavaFX 11-ea-25 for armv6hf does not support audio for javafx.media ( https://stackoverflow.com/questions/53906096/play-mp3-with-javafx-11-on-raspberry-pi-3 ). Last week I repeated this with the meanwhile published non-EA build of JavaFX 11.0.2 for armv6hf but the problem still exists. In order to get a better feeling for the situation about JavaFX on the Raspberry Pi I would be interested in some details: 1. The comment on StackOverflow says there is something missing in Gluon?s release - is this correct or did I make a mistake? 2. In case the problem is in Gluon?s package: a) do you know about plans to fix this in the near future? Maybe with JavaFX 12? b) are you aware of other sources for ARM builds of JavaFX 11 (that might support audio)? 3. Is there some kind of documentation accessible that shows what functionalities are included / not included in JavaFX 11 for ARM or any future releases? Thank you very much for your help! Best regards, Thomas Manz From alexander.matveev at oracle.com Thu Mar 28 02:13:33 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 27 Mar 2019 19:13:33 -0700 Subject: [13] RFR: JDK-8211900: javafx.media classes directly reference platform classes that are excluded Message-ID: Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8211900 ?- Fixed by loading platform specific classes via reflection. Thanks, Alexander From siddheshrane at disroot.org Thu Mar 28 04:43:26 2019 From: siddheshrane at disroot.org (Siddhesh Rane) Date: Thu, 28 Mar 2019 10:13:26 +0530 Subject: EventHandler not working in 11.0.2 In-Reply-To: Message-ID: <2ccc33df-04fd-4c87-b121-7ab85d3b2bef@email.android.com> From pankaj.b.bansal at oracle.com Thu Mar 28 07:18:35 2019 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Thu, 28 Mar 2019 00:18:35 -0700 (PDT) Subject: Drag & Drop errors on Linux/Ubuntu In-Reply-To: References: Message-ID: Hello Dragos, There are some known issues with Drag & Drop on Ubuntu from JavaFX11 as gtk3 has been made default. There is a bug filled for the same in JBS JDK-8211302. Drag & Drop does not work, but I don?t get the error you are getting. Can you please create a small reproducer to look at. For time being, you can use gtk2 by using -Djdk.gtk.version=2. -Pankaj -----Original Message----- From: dprutean [mailto:pruteanu at gmail.com] Sent: Wednesday, March 27, 2019 2:23 AM To: openjfx-dev at openjdk.java.net Subject: Drag & Drop errors on Linux/Ubuntu Hi, JavaFx 12 got issues with drag&drop on Ubuntu. (java:3346): GLib-GObject-WARNING **: 13:50:41.198: ../../../../gobject/gsignal.c:2523: signal 'expose-event' is invalid for instance '0x7f43343c6520' of type 'GtkWindow' Is this something known ? Thank you, Dragos From mp at jugs.org Thu Mar 28 07:38:30 2019 From: mp at jugs.org (Michael Paus) Date: Thu, 28 Mar 2019 08:38:30 +0100 Subject: Fwd: JavaFX 11 on Raspberry Pi In-Reply-To: References: <003f01d4cba5$8e5d0450$ab170cf0$@gmail.com> Message-ID: You might want to have a look at https://bell-sw.com/pages/java-12/ I don't know whether the audio works but I think it should be worth a try. Liberica already contains JavaFX, so you do not need the bits from Gluon. Michael Am 27.03.19 um 20:36 schrieb Thomas Manz: > Hello, > > in the last months I started to do some tests with Java 11 and JavaFX 11 on > a Raspberry Pi 3. I followed this manual (http://docs.gluonhq.com/embedded/) > but unfortunately I realized that so far Gluon?s EA build of JavaFX > 11-ea-25 for armv6hf does not support audio for javafx.media ( > https://stackoverflow.com/questions/53906096/play-mp3-with-javafx-11-on-raspberry-pi-3 > ). > > Last week I repeated this with the meanwhile published non-EA build of > JavaFX 11.0.2 for armv6hf but the problem still exists. > > In order to get a better feeling for the situation about JavaFX on the > Raspberry Pi I would be interested in some details: > 1. The comment on StackOverflow says there is something missing in Gluon?s > release - is this correct or did I make a mistake? > 2. In case the problem is in Gluon?s package: > a) do you know about plans to fix this in the near future? Maybe with > JavaFX 12? > b) are you aware of other sources for ARM builds of JavaFX 11 (that > might support audio)? > 3. Is there some kind of documentation accessible that shows what > functionalities are included / not included in JavaFX 11 for ARM or any > future releases? > > Thank you very much for your help! > > Best regards, > Thomas Manz From nlisker at gmail.com Fri Mar 29 16:28:00 2019 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 29 Mar 2019 19:28:00 +0300 Subject: Update openjfx.io to JavFX12? Message-ID: Hi, The main page at https://openjfx.io still shows JavaFX11 even though 12 is released. Is it because Gluon offers LTS for 11 and not 12? Shouldn't the main page show the latest version regardless? - Nir From johnvalrose at gmail.com Fri Mar 29 16:49:06 2019 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 30 Mar 2019 03:49:06 +1100 Subject: Update openjfx.io to JavFX12? In-Reply-To: References: Message-ID: <7FF9CEDE-8A54-49BC-84E8-AB407DA00ED7@gmail.com> +1 > On 30 Mar 2019, at 03:28, Nir Lisker wrote: > > Hi, > > The main page at https://openjfx.io still shows JavaFX11 even though 12 is > released. Is it because Gluon offers LTS for 11 and not 12? Shouldn't the > main page show the latest version regardless? > > - Nir From johan.vos at gluonhq.com Fri Mar 29 17:10:31 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 29 Mar 2019 18:10:31 +0100 Subject: Update openjfx.io to JavFX12? In-Reply-To: References: Message-ID: Yes, this should be 12 indeed. It's on our todo-list, but if you or anyone else want to update it, you can create a PR at https://github.com/openjfx/openjfx.github.io While this site is initiated by Gluon, I want to stress that openjfx.io really is a community website, hence I highly encourage participation. - Johan On Fri, Mar 29, 2019 at 5:40 PM Nir Lisker wrote: > Hi, > > The main page at https://openjfx.io still shows JavaFX11 even though 12 is > released. Is it because Gluon offers LTS for 11 and not 12? Shouldn't the > main page show the latest version regardless? > > - Nir > From nlisker at gmail.com Fri Mar 29 17:17:43 2019 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 29 Mar 2019 20:17:43 +0300 Subject: Update openjfx.io to JavFX12? In-Reply-To: References: Message-ID: Thanks Johan, I was actually not aware of this repo, I guess I missed it when it was brought up. Will take a look. On Fri, Mar 29, 2019 at 8:10 PM Johan Vos wrote: > Yes, this should be 12 indeed. It's on our todo-list, but if you or anyone > else want to update it, you can create a PR at > https://github.com/openjfx/openjfx.github.io > > While this site is initiated by Gluon, I want to stress that openjfx.io > really is a community website, hence I highly encourage participation. > > - Johan > > On Fri, Mar 29, 2019 at 5:40 PM Nir Lisker wrote: > >> Hi, >> >> The main page at https://openjfx.io still shows JavaFX11 even though 12 >> is >> released. Is it because Gluon offers LTS for 11 and not 12? Shouldn't the >> main page show the latest version regardless? >> >> - Nir >> > From johnvalrose at gmail.com Fri Mar 29 17:55:01 2019 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 30 Mar 2019 04:55:01 +1100 Subject: Update openjfx.io to JavFX12? In-Reply-To: References: Message-ID: Thanks Johan. Your contributions certainly do not go unnoticed, nor unappreciated, > On 30 Mar 2019, at 04:17, Nir Lisker wrote: > > Thanks Johan, I was actually not aware of this repo, I guess I missed it > when it was brought up. Will take a look. > >> On Fri, Mar 29, 2019 at 8:10 PM Johan Vos wrote: >> >> Yes, this should be 12 indeed. It's on our todo-list, but if you or anyone >> else want to update it, you can create a PR at >> https://github.com/openjfx/openjfx.github.io >> >> While this site is initiated by Gluon, I want to stress that openjfx.io >> really is a community website, hence I highly encourage participation. >> >> - Johan >> >>> On Fri, Mar 29, 2019 at 5:40 PM Nir Lisker wrote: >>> >>> Hi, >>> >>> The main page at https://openjfx.io still shows JavaFX11 even though 12 >>> is >>> released. Is it because Gluon offers LTS for 11 and not 12? Shouldn't the >>> main page show the latest version regardless? >>> >>> - Nir >>> >> From rachel at merus.eu Sat Mar 30 12:01:03 2019 From: rachel at merus.eu (Rachel Greenham) Date: Sat, 30 Mar 2019 12:01:03 +0000 Subject: EventHandler not working in 11.0.2 In-Reply-To: References: Message-ID: IntelliJ's code completion looks to be wrong then. Just delete the "(EventHandler)" On 27/03/2019 18:29, Andrew Munn wrote: > How do I listen for mouse events in 11.0.2? IntelliJ's code completion > suggests this: > > textField.addEventHandler(MouseEvent.MOUSE_ENTERED, (EventHandler) t -> { > // do something > }); > > but it fails to compile with error: cannot find symbol T > > Thanks From nlisker at gmail.com Sat Mar 30 13:28:39 2019 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 30 Mar 2019 16:28:39 +0300 Subject: Review Request: JDK-8221708: Update Eclipse project files for non-modular projects Message-ID: Hi, Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8221708 http://cr.openjdk.java.net/~nlisker/8221708/webrev.00/ Users of Eclipse are encourage to comment. Thanks, Nir From mik3hall at gmail.com Sat Mar 30 14:37:16 2019 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 30 Mar 2019 09:37:16 -0500 Subject: EventHandler not working in 11.0.2 In-Reply-To: References: Message-ID: <1E6FF073-9A8F-4AF3-8E87-C5B3D742B919@gmail.com> > On Mar 27, 2019, at 1:29 PM, Andrew Munn wrote: > > How do I listen for mouse events in 11.0.2? IntelliJ's code completion > suggests this: > > textField.addEventHandler(MouseEvent.MOUSE_ENTERED, (EventHandler) t -> { > // do something > }); > > but it fails to compile with error: cannot find symbol T > > Thanks Isn?t that just generic notation saying it takes an event handler where you indicate the specific type. e.g. this https://docs.oracle.com/javafx/2/events/handlers.htm includes node.addEventHandler(DragEvent.DRAG_ENTERED, new EventHandler() { public void handle(DragEvent) { ... }; }); showing that this handler is for DragEvent?s, specifically the DRAG_ENTERED event in this case. So you need to pass your own handler as that parameter. From kevin.rushforth at oracle.com Sat Mar 30 16:40:44 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 30 Mar 2019 09:40:44 -0700 Subject: Proposed schedule for JavaFX 13 Message-ID: <7fd7add2-96de-a3d3-6542-056070f79422@oracle.com> Here is the proposed schedule for JavaFX 13. RDP1: Jul 8, 2019 (aka ?feature freeze?) RDP2: Aug 5, 2019 Freeze: Aug 26, 2019 GA: September 10, 2019 We plan to fork a 13-dev stabilization repo at RDP1. The GA date is one week ahead of JDK 13, matching what we did for 12. Please let Johan or me know if you have any questions. -- Kevin