From alexander.matveev at oracle.com Wed May 1 02:13:27 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 30 Apr 2019 19:13:27 -0700 Subject: [13] RFR: JDK-8223046: AudioClip sample does not work in Ensemble when run via web-start Message-ID: <5ce1409d-911f-4496-7d87-ac3cb58eb78d@oracle.com> Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8223046 http://cr.openjdk.java.net/~almatvee/8223046/webrev.00/ - Added HTTPS protocol to JDK-8177428 workaround. Thanks, Alexander From kevin.rushforth at oracle.com Wed May 1 12:23:47 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 1 May 2019 05:23:47 -0700 Subject: [13] RFR: JDK-8222883: Ensemble: Update version of Lucene to 7.7.1 Message-ID: <1a4891ee-a675-ae19-3b91-45c19c253512@oracle.com> Please review the following fix to update the version of Lucene used by Ensemble to 7.7.1: https://bugs.openjdk.java.net/browse/JDK-8222883 https://github.com/javafxports/openjdk-jfx/pull/459 -- Kevin From thiago.sayao at clamed.com.br Thu May 2 11:23:47 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Thu, 2 May 2019 11:23:47 +0000 Subject: RFR: JDK-8197536: TableView, ListView: unexpected scrolling behaviour on up/down keys Message-ID: https://bugs.openjdk.java.net/browse/JDK-8197536 https://github.com/javafxports/openjdk-jfx/pull/460 From ooo_saturn7 at mail.ru Fri May 3 13:09:58 2019 From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=) Date: Fri, 03 May 2019 16:09:58 +0300 Subject: =?UTF-8?B?V2h5IGRvZXMgU2tpbiBoYXZlIGdldE5vZGUgbWV0aG9kIGluc3RlYWQgb2Yg?= =?UTF-8?B?Z2V0Q29udHJvbD8=?= Message-ID: <1556888998.471363214@f121.i.mail.ru> Hi all, In my previous message I asked why GridPane, HBox, BorderPane, VBox, StackPane don't have Skins. I was told that it is odd for them to have Skins ( Kevin Rushforth ) and only controls can have skins. I pointed, that every Node can have a Skin, but got no answer. Now I am reading Skin API and see there the following method: Node???? getNode()????? Gets the Node which represents this Skin. The Skinnable interface is implemented by the Control class, and therefore is implemented by all Control implementations. So, could anyone explain why in Skin we have `Node getNode()` but not `Control getControl()`. -- Alex Sviridov From nlisker at gmail.com Sat May 4 04:00:03 2019 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 4 May 2019 07:00:03 +0300 Subject: Review Request: JDK-8222258: Add exclusion scope for LightBase Message-ID: Hi Kevin / Ambarish, Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8222258 http://cr.openjdk.java.net/~nlisker/8222258/webrev.01/ Details are in the JBS issue. Thanks, Nir From kevin.rushforth at oracle.com Sat May 4 13:13:51 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 4 May 2019 06:13:51 -0700 Subject: Review Request: JDK-8222258: Add exclusion scope for LightBase In-Reply-To: References: Message-ID: I'll put it on my review queue. This will need a CSR. The proposed docs from the patch can be used as a starting point; they may need some minor updates, but are close enough to get started. -- Kevin On 5/3/2019 9:00 PM, Nir Lisker wrote: > Hi Kevin / Ambarish, > > Please review the fix for: > > https://bugs.openjdk.java.net/browse/JDK-8222258 > http://cr.openjdk.java.net/~nlisker/8222258/webrev.01/ > > Details are in the JBS issue. > > Thanks, > Nir From nlisker at gmail.com Sat May 4 15:51:31 2019 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 4 May 2019 18:51:31 +0300 Subject: Review Request: JDK-8222258: Add exclusion scope for LightBase In-Reply-To: References: Message-ID: Added a CSR. On Sat, May 4, 2019 at 4:14 PM Kevin Rushforth wrote: > I'll put it on my review queue. > > This will need a CSR. The proposed docs from the patch can be used as a > starting point; they may need some minor updates, but are close enough > to get started. > > -- Kevin > > > On 5/3/2019 9:00 PM, Nir Lisker wrote: > > Hi Kevin / Ambarish, > > > > Please review the fix for: > > > > https://bugs.openjdk.java.net/browse/JDK-8222258 > > http://cr.openjdk.java.net/~nlisker/8222258/webrev.01/ > > > > Details are in the JBS issue. > > > > Thanks, > > Nir > > From pruteanu at gmail.com Wed May 8 19:44:34 2019 From: pruteanu at gmail.com (dprutean) Date: Wed, 8 May 2019 21:44:34 +0200 Subject: Question regarding WebView Message-ID: Hi, I tried to get an answer on this on StackOverflow, but without success. I am looking to intercept WebView HttpRequests and list the POST, PUT or GET parameters for all outgoing requests. I know about Firebug, but I want more: to get this data from the Java code. I was thinking on solutions using: 1. Shared objects between WebView and JavaFx using: final JSObject jsWindowObject = (JSObject) webView.getEngine().executeScript("window"); jsWindowObject.setMember("cssProperty", cssProperty); and then execute some JavaScript which would register a listener for fetch events. I didn't find the right code. 2. Write a kind of proxy. Do you know how this can be achived ? Thank you, Dragos https://stackoverflow.com/questions/55994963/how-to-debug-javafx-webview-outgoing-requests?noredirect=1#comment98674890_55994963 From simon.zhang at msn.com Thu May 9 00:33:44 2019 From: simon.zhang at msn.com (Zhang Simon) Date: Thu, 9 May 2019 00:33:44 +0000 Subject: JavaFX how to snaps to device pixels Message-ID: Hi, I need you help ! I am Chong Qing China company, use JavaFX Canvas GraphicsContext2D development application. We need shapes line snaps to device pixels. Please tell me how? Other links https://docs.microsoft.com/en-us/previous-versions/aa970908(v=vs.100) Simon(??) TEL:+86 13883833982 FAX:023-67388119 From neacsu.cristianstefan at gmail.com Fri May 10 08:39:21 2019 From: neacsu.cristianstefan at gmail.com (Neacsu Cristian) Date: Fri, 10 May 2019 11:39:21 +0300 Subject: set Destination attribute in printReqAttrSet Message-ID: For windows print through "Microsoft Print to PDF", there is no way right now to pre-define a path programmatically. There is no way to set inside the printReqAttrSet (J2DPrinterJob), an attribute of type Destination, to solve this issue. Before jdk 9, I was bypassing it through reflection like this: java.lang.reflect.Field field = job.getClass().getDeclaredField("jobImpl"); field.setAccessible(true); PrinterJobImpl jobImpl = (PrinterJobImpl) field.get(job); field.setAccessible(false); field = jobImpl.getClass().getDeclaredField("printReqAttrSet"); field.setAccessible(true); PrintRequestAttributeSet printReqAttrSet = (PrintRequestAttributeSet) field.get(jobImpl); field.setAccessible(false); printReqAttrSet.add(new Destination(new File(filePath).toURI())); Now, the module is closed, so I cannot access it through reflection. Is there a way to obtain this behavior again? From philip.race at oracle.com Fri May 10 17:14:57 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 10 May 2019 10:14:57 -0700 Subject: set Destination attribute in printReqAttrSet In-Reply-To: References: Message-ID: <5CD5B191.7070705@oracle.com> Everything you are touching there pre-supposes knowledge of today's implementation of the JavaFX printing API, so I don't think we can endorse that. The right thing to do (maybe years ago!) is to file an RFE to request that something like the Destination attribute be supported in the FX printing API. I've reviewed the open bug list and I don't see that anyone else has asked for this. I just submitted : https://bugs.openjdk.java.net/browse/JDK-8223717 JFYI, I reviewed some old notes and it was originally planned to be supported in the API but during design discussion it was removed as a result of a combination of getting it right, not being sure how many people would need it (you may be the first) and some perhaps over-stated concerns about security. -phil. On 5/10/19, 1:39 AM, Neacsu Cristian wrote: > For windows print through "Microsoft Print to PDF", there is no way right > now to pre-define a path programmatically. There is no way to set inside > the printReqAttrSet (J2DPrinterJob), an attribute of type Destination, to > solve this issue. > > Before jdk 9, I was bypassing it through reflection like this: > > java.lang.reflect.Field field = job.getClass().getDeclaredField("jobImpl"); > field.setAccessible(true); > PrinterJobImpl jobImpl = (PrinterJobImpl) field.get(job); > field.setAccessible(false); > field = jobImpl.getClass().getDeclaredField("printReqAttrSet"); > field.setAccessible(true); > PrintRequestAttributeSet printReqAttrSet = (PrintRequestAttributeSet) > field.get(jobImpl); > field.setAccessible(false); > printReqAttrSet.add(new Destination(new File(filePath).toURI())); > > Now, the module is closed, so I cannot access it through reflection. Is > there a way to obtain this behavior again? From kevin.rushforth at oracle.com Fri May 10 17:56:56 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 10 May 2019 10:56:56 -0700 Subject: [13] RFR: JDK-8223719: Add .gitignore to repo Message-ID: <0d6490aa-2cda-397f-0519-d75e59dc8ae9@oracle.com> Simple fix to add a .gitignore file to the upstream HG openjfx/jfx-dev/rt directory. This file currently exists as a "javafxports-only" file in the javafxports/openjdk-jfx sandbox on GitHub. https://bugs.openjdk.java.net/browse/JDK-8223719 http://cr.openjdk.java.net/~kcr/8223719/webrev.00/ This reduces the number of files that are unique to the javafxports/openjdk-jfx GitHub sandbox, and also allows it to show up on the jfx-dev/rt mirror that Project Skara has created [1] -- Kevin [1] https://github.com/openjdk/jfx From mblaesing at doppel-helix.eu Fri May 10 20:23:05 2019 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Fri, 10 May 2019 22:23:05 +0200 Subject: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points Message-ID: <54df38b8986ec59276b58daa299d1c626bcef4ce.camel@doppel-helix.eu> Hello, as the normal submission process did not yield an update for the above mentioned issue and this is a crasher, I try to get the information submitted here. As reference the JDK issue: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8223377 Summary: I experimented with OpenJFX once again and noticed, that even simple programms crashed for me. I saw the crashes being introduced in maven release: org.openjfx javafx-controls 12-ea+7 org.openjfx javafx-web 12-ea+7 Until that version this stack trace is generated: java.lang.ArrayIndexOutOfBoundsException: Index -17 out of bounds for length 32 at com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$10.doPaint(WCGraphicsPrismContext.java:939) at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite.paint(WCGraphicsPrismContext.java:1524) at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite.paint(WCGraphicsPrismContext.java:1509) at com.sun.javafx.webkit.prism.WCGraphicsPrismContext.drawString(WCGraphicsPrismContext.java:951) at com.sun.webkit.graphics.GraphicsDecoder.decode(GraphicsDecoder.java:301) at com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java:92) at com.sun.webkit.WebPage.paint2GC(WebPage.java:736) at com.sun.webkit.WebPage.paint(WebPage.java:703) at com.sun.javafx.sg.prism.web.NGWebView.renderContent(NGWebView.java:95) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.base/java.lang.Thread.run(Thread.java:834) I tried to corner the problem and noticed, that the crash is _not_ reproducible with the java binary from jdk.java.net. The crash is also not reproducible with a Ubuntu Live CD with only the default-jre installed. Then I tried to align the live environment (does not crash) with my desktop system (OpenJFX crashes). And finally I found the problem. 1. Get the Xubuntu 19.04 live CD: http://torrent.ubuntu.com/xubuntu/releases/disco/release/desktop/xubuntu-19.04-desktop-amd64.iso.torrent 2. Start the Image (Try Xubuntu) in VirtualBox 3. Install the default JDK (that will be 11.0.3) and maven: sudo apt install default-jdk maven git 4. Clone the reproducer repository: git clone https://github.com/matthiasblaesing/reproduce-openjfx-crash.git 5. Build it: cd reproduce-openjfx-crash mvn package 6. Run with: java -jar target/reproduce-openjfx-crash.jar => Window with the title "Hello World!", the text "Test" and japanese/sudanese punctuation symbols are shown => In the console, you see, that the native libraries are loaded from resource 7. Close windows 8. Install openjfx JNI libraries: apt install libopenjfx-jni 9. Run again with: java -jar target/reproduce-openjfx-crash.jar => Window is briefly displayed => On the console a SEGFAULS is logged (and hs_err_pid... is written) => You can read, that the native libraries were loaded via System#loadLibrary -------------------------------------------------------------------- This result also explains why the problem is not visible with the binaries from jdk.java.net: The java executables use different java.library.paths: Ubuntu: java.library.path = /usr/java/packages/lib /usr/lib/x86_64-linux-gnu/jni /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu /usr/lib/jni /lib /usr/lib OpenJDK: java.library.path = /usr/java/packages/lib /usr/lib64 /lib64 /lib /usr/lib As contents of the libopenjfx-jni package is installed to /usr/lib/x86_64-linux-gnu/jni/, only the Ubuntu java launcher finds the binaries. -------------------------------------------------------------------- It is not too surprising, that the native libraries and the java implementations are tightly coupled. For the JNA project we are faced with the same situation. However, there are differences: - the JNA project checks, that the native libraries are of a compatible version - there is a system property, that lets the user choose whether system libraries should be used or the bundled native libraries be extracted - the system property was changed to default to use the bundled native libraries I had a quick look at the NativeLibraryLoader and don't see a similar mechanism. The only work around I found was overriding the java.library.path, but that requires changes to the launch sequence of the VM. For a managed language, I don't think a segfault is a valid result for loading HTML and thus should not be just a P4. It is not uncommon to have the distribution libraries installed, so I expect the problem to be present on more systems. Thank you Matthias From kevin.rushforth at oracle.com Fri May 10 20:50:30 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 10 May 2019 13:50:30 -0700 Subject: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points In-Reply-To: <54df38b8986ec59276b58daa299d1c626bcef4ce.camel@doppel-helix.eu> References: <54df38b8986ec59276b58daa299d1c626bcef4ce.camel@doppel-helix.eu> Message-ID: The normal submission process yielded a bug report to be evaluated, and it's still in the queue to be looked at. Since you provided some additional information, we can add it to the bug report as a comment. Btw, the direct URL for the bug in JBS is: https://bugs.openjdk.java.net/browse/JDK-8223377 From your aditional comments, it sounds as if this is some sort of system configuration issue. Unless there are JavaFX classes or .so files in your JDK (which is not supported with OpenJFX 11 or greater), I don't know how you would see the mismatch between the javafx.web class files and the jfxwebkit.so native library. -- Kevin On 5/10/2019 1:23 PM, Matthias Bl?sing wrote: > Hello, > > as the normal submission process did not yield an update for the above > mentioned issue and this is a crasher, I try to get the information > submitted here. > > As reference the JDK issue: > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8223377 > > Summary: > > I experimented with OpenJFX once again and noticed, that even simple > programms crashed for me. I saw the crashes being introduced in maven > release: > > > org.openjfx > javafx-controls > 12-ea+7 > > > org.openjfx > javafx-web > 12-ea+7 > > > Until that version this stack trace is generated: > > java.lang.ArrayIndexOutOfBoundsException: Index -17 out of bounds for length 32 > at com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) > at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) > at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) > at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$10.doPaint(WCGraphicsPrismContext.java:939) > at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite.paint(WCGraphicsPrismContext.java:1524) > at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite.paint(WCGraphicsPrismContext.java:1509) > at com.sun.javafx.webkit.prism.WCGraphicsPrismContext.drawString(WCGraphicsPrismContext.java:951) > at com.sun.webkit.graphics.GraphicsDecoder.decode(GraphicsDecoder.java:301) > at com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java:92) > at com.sun.webkit.WebPage.paint2GC(WebPage.java:736) > at com.sun.webkit.WebPage.paint(WebPage.java:703) > at com.sun.javafx.sg.prism.web.NGWebView.renderContent(NGWebView.java:95) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) > at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) > at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) > at java.base/java.lang.Thread.run(Thread.java:834) > > I tried to corner the problem and noticed, that the crash is _not_ > reproducible with the java binary from jdk.java.net. The crash is also > not reproducible with a Ubuntu Live CD with only the default-jre > installed. > > Then I tried to align the live environment (does not crash) with my > desktop system (OpenJFX crashes). And finally I found the problem. > > 1. Get the Xubuntu 19.04 live CD: > http://torrent.ubuntu.com/xubuntu/releases/disco/release/desktop/xubuntu-19.04-desktop-amd64.iso.torrent > 2. Start the Image (Try Xubuntu) in VirtualBox > 3. Install the default JDK (that will be 11.0.3) and maven: > sudo apt install default-jdk maven git > 4. Clone the reproducer repository: > git clone https://github.com/matthiasblaesing/reproduce-openjfx-crash.git > 5. Build it: > cd reproduce-openjfx-crash > mvn package > 6. Run with: > java -jar target/reproduce-openjfx-crash.jar > > => Window with the title "Hello World!", the text "Test" and japanese/sudanese punctuation symbols are shown > => In the console, you see, that the native libraries are loaded from resource > > 7. Close windows > 8. Install openjfx JNI libraries: > apt install libopenjfx-jni > 9. Run again with: > java -jar target/reproduce-openjfx-crash.jar > > => Window is briefly displayed > => On the console a SEGFAULS is logged (and hs_err_pid... is written) > => You can read, that the native libraries were loaded via System#loadLibrary > > -------------------------------------------------------------------- > > This result also explains why the problem is not visible with the > binaries from jdk.java.net: The java executables use different > java.library.paths: > > Ubuntu: > > java.library.path = /usr/java/packages/lib > /usr/lib/x86_64-linux-gnu/jni > /lib/x86_64-linux-gnu > /usr/lib/x86_64-linux-gnu > /usr/lib/jni > /lib > /usr/lib > > OpenJDK: > > java.library.path = /usr/java/packages/lib > /usr/lib64 > /lib64 > /lib > /usr/lib > > As contents of the libopenjfx-jni package is installed to > /usr/lib/x86_64-linux-gnu/jni/, only the Ubuntu java launcher finds the > binaries. > > -------------------------------------------------------------------- > > It is not too surprising, that the native libraries and the java > implementations are tightly coupled. For the JNA project we are faced > with the same situation. However, there are differences: > > - the JNA project checks, that the native libraries are > of a compatible version > - there is a system property, that lets the user choose whether > system libraries should be used or the bundled native libraries be > extracted > - the system property was changed to default to use the bundled native > libraries > > I had a quick look at the NativeLibraryLoader and don't see a similar > mechanism. The only work around I found was overriding the > java.library.path, but that requires changes to the launch sequence of > the VM. > > > For a managed language, I don't think a segfault is a valid result for > loading HTML and thus should not be just a P4. It is not uncommon to > have the distribution libraries installed, so I expect the problem to > be present on more systems. > > > Thank you > > Matthias > From neacsu.cristianstefan at gmail.com Fri May 10 23:36:07 2019 From: neacsu.cristianstefan at gmail.com (Neacsu Cristian) Date: Sat, 11 May 2019 02:36:07 +0300 Subject: set Destination attribute in printReqAttrSet In-Reply-To: <5CD5B191.7070705@oracle.com> References: <5CD5B191.7070705@oracle.com> Message-ID: Damn ... Thank you for your reply and for the ticket submitted. I created an invoice application for my own company, and imagine that java 9+ would kill me :) All the invoices are generated automatically through pdf printer (I tried few free pdf libraries as an alternative, but for what I need they have poor results). I actually posted my ugly solution as well here some time ago: https://stackoverflow.com/questions/52684422/javafx-set-programmatically-the-destination-path-to-print-directly-a-node-to-p/52687798#52687798 I know it is not much, but 89 hits might mean something. People might fight with it later, when they are going to migrate for new java versions. Thank you so much, and looking forward if you guys have time to take care of it. Cristian-Stefan On Fri, May 10, 2019 at 8:15 PM Philip Race wrote: > Everything you are touching there pre-supposes knowledge > of today's implementation of the JavaFX printing API, so > I don't think we can endorse that. > The right thing to do (maybe years ago!) is to file > an RFE to request that something like the Destination attribute > be supported in the FX printing API. I've reviewed the open > bug list and I don't see that anyone else has asked for this. > > I just submitted : https://bugs.openjdk.java.net/browse/JDK-8223717 > > JFYI, I reviewed some old notes and it was originally planned to be > supported in the API but during design discussion it was removed > as a result of a combination of getting it right, not being sure how > many people would need it (you may be the first) and some perhaps > over-stated concerns about security. > > -phil. > > On 5/10/19, 1:39 AM, Neacsu Cristian wrote: > > For windows print through "Microsoft Print to PDF", there is no way right > > now to pre-define a path programmatically. There is no way to set inside > > the printReqAttrSet (J2DPrinterJob), an attribute of type Destination, to > > solve this issue. > > > > Before jdk 9, I was bypassing it through reflection like this: > > > > java.lang.reflect.Field field = > job.getClass().getDeclaredField("jobImpl"); > > field.setAccessible(true); > > PrinterJobImpl jobImpl = (PrinterJobImpl) field.get(job); > > field.setAccessible(false); > > field = jobImpl.getClass().getDeclaredField("printReqAttrSet"); > > field.setAccessible(true); > > PrintRequestAttributeSet printReqAttrSet = (PrintRequestAttributeSet) > > field.get(jobImpl); > > field.setAccessible(false); > > printReqAttrSet.add(new Destination(new File(filePath).toURI())); > > > > Now, the module is closed, so I cannot access it through reflection. Is > > there a way to obtain this behavior again? > From guoge1 at huawei.com Sat May 11 07:13:49 2019 From: guoge1 at huawei.com (guoge (A)) Date: Sat, 11 May 2019 07:13:49 +0000 Subject: Will there be update of openjfx-8u? Message-ID: <9D8EABB130A7294DAD4857FC861F5FBF4ADE824D@dggemm509-mbx.china.huawei.com> Hi, JFX team I noticed there is no 8u211/8u212 released for openjfx-8u yet, is openjfx-8u port still actively maintained? And I noticed the components of openjfx-8u are too old with vulnerabilities, like libicu, gstreamer and sqlite, which need to be updated. We have backported some update patches from openjfx11, will there be an update vesion of openjfx-8u to merge the patches? Thanks, Guo Ge From kevin.rushforth at oracle.com Sat May 11 12:47:34 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 11 May 2019 05:47:34 -0700 Subject: Will there be update of openjfx-8u? In-Reply-To: <9D8EABB130A7294DAD4857FC861F5FBF4ADE824D@dggemm509-mbx.china.huawei.com> References: <9D8EABB130A7294DAD4857FC861F5FBF4ADE824D@dggemm509-mbx.china.huawei.com> Message-ID: <1e2186d0-4013-1ee5-4ed9-9cf02477343f@oracle.com> No, there is no maintainer for the openjfx/8u code line. [1] -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-January/023039.html On 5/11/2019 12:13 AM, guoge (A) wrote: > Hi, JFX team > > I noticed there is no 8u211/8u212 released for openjfx-8u yet, > is openjfx-8u port still actively maintained? > > And I noticed the components of openjfx-8u are too old with > vulnerabilities, like libicu, gstreamer and sqlite, which need to be > updated. We have backported some update patches from > openjfx11, will there be an update vesion of openjfx-8u to > merge the patches? > > Thanks, > Guo Ge From mblaesing at doppel-helix.eu Sat May 11 13:32:30 2019 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Sat, 11 May 2019 15:32:30 +0200 Subject: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points In-Reply-To: References: <54df38b8986ec59276b58daa299d1c626bcef4ce.camel@doppel-helix.eu> Message-ID: [Resend to Mailinglist, I'm subscribed and did not see, that it was directly send to me] Hi Kevin, the problem on Ubuntu is this: When you install a package, that requires OpenJFX (for example mediathekview), the package libopenjfx-jni is installed as a dependency. The package libopenjfx-jni installs the OpenJFX native libraries into the folder /usr/lib/x86_64-linux-gnu/jni. This is all good if you are only using distribution libraries, but when using a third-party application, that requires JavaFX, it breaks. In my case this is Apache NetBeans, that can't even bundle a JVM (ASF requirement), so using the system VM is the logical choice. The problem is in com.sun.glass.utils.NativeLibLoader#loadLibraryInternal. The native libraries are loaded: - from filesstem in the same folder as the jar - via System#loadLibrary - extracted from the resources of the jar The options are tried in that order and the first successful wins. In my case instead of loading the working native libraries from the maven jars, the system ones are picked up via System#loadLibrary. This means, I get the OpenJFX native libraries for 11.0.2 with the OpenJFX java classes of 13-ea+7 (for the newest variant). This is obvisually a bad idea (the crash shows that clearly). For JNA two thinks are done: The native libraries are versioned independently from the java classes and after loading the library the java part checks if a compatible native library was loaded (same major, same or higher minor version). The java classes embedd the version of the native library they expect and the native library embeds its real version, so mismatches can be detected before the JVM blows. Another difference: Today JNA prefers its bundled native library if not requested differently via system property. For desktop systems JNA now tries to load the library first from the JAR and only falls back to system libraries, if that fails. Does this clear up the situation a bit? Greetings Matthias Am Freitag, den 10.05.2019, 13:50 -0700 schrieb Kevin Rushforth: > The normal submission process yielded a bug report to be evaluated, and > it's still in the queue to be looked at. Since you provided some > additional information, we can add it to the bug report as a comment. > Btw, the direct URL for the bug in JBS is: > > https://bugs.openjdk.java.net/browse/JDK-8223377 > > From your aditional comments, it sounds as if this is some sort of > system configuration issue. Unless there are JavaFX classes or .so files > in your JDK (which is not supported with OpenJFX 11 or greater), I don't > know how you would see the mismatch between the javafx.web class files > and the jfxwebkit.so native library. > > -- Kevin > > > On 5/10/2019 1:23 PM, Matthias Bl?sing wrote: > > Hello, > > > > as the normal submission process did not yield an update for the > > above > > mentioned issue and this is a crasher, I try to get the information > > submitted here. > > > > As reference the JDK issue: > > > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8223377 > > > > Summary: > > > > I experimented with OpenJFX once again and noticed, that even > > simple > > programms crashed for me. I saw the crashes being introduced in > > maven > > release: > > > > > > org.openjfx > > javafx-controls > > 12-ea+7 > > > > > > org.openjfx > > javafx-web > > 12-ea+7 > > > > > > Until that version this stack trace is generated: > > > > java.lang.ArrayIndexOutOfBoundsException: Index -17 out of bounds for length 32 > > at com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) > > at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) > > at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) > > at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$10.doPaint(WCGraphicsPrismContext.java:939) > > at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite.paint(WCGraphicsPrismContext.java:1524) > > at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite.paint(WCGraphicsPrismContext.java:1509) > > at com.sun.javafx.webkit.prism.WCGraphicsPrismContext.drawString(WCGraphicsPrismContext.java:951) > > at com.sun.webkit.graphics.GraphicsDecoder.decode(GraphicsDecoder.java:301) > > at com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java:92) > > at com.sun.webkit.WebPage.paint2GC(WebPage.java:736) > > at com.sun.webkit.WebPage.paint(WebPage.java:703) > > at com.sun.javafx.sg.prism.web.NGWebView.renderContent(NGWebView.java:95) > > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > > at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) > > at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) > > at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > > at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > > at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > > at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) > > at java.base/java.lang.Thread.run(Thread.java:834) > > > > I tried to corner the problem and noticed, that the crash is _not_ > > reproducible with the java binary from jdk.java.net. The crash is also > > not reproducible with a Ubuntu Live CD with only the default-jre > > installed. > > > > Then I tried to align the live environment (does not crash) with my > > desktop system (OpenJFX crashes). And finally I found the problem. > > > > 1. Get the Xubuntu 19.04 live CD: > > http://torrent.ubuntu.com/xubuntu/releases/disco/release/desktop/xubuntu-19.04-desktop-amd64.iso.torrent > > 2. Start the Image (Try Xubuntu) in VirtualBox > > 3. Install the default JDK (that will be 11.0.3) and maven: > > sudo apt install default-jdk maven git > > 4. Clone the reproducer repository: > > git clone https://github.com/matthiasblaesing/reproduce-openjfx-crash.git > > 5. Build it: > > cd reproduce-openjfx-crash > > mvn package > > 6. Run with: > > java -jar target/reproduce-openjfx-crash.jar > > > > => Window with the title "Hello World!", the text "Test" and japanese/sudanese punctuation symbols are shown > > => In the console, you see, that the native libraries are loaded from resource > > > > 7. Close windows > > 8. Install openjfx JNI libraries: > > apt install libopenjfx-jni > > 9. Run again with: > > java -jar target/reproduce-openjfx-crash.jar > > > > => Window is briefly displayed > > => On the console a SEGFAULS is logged (and hs_err_pid... is written) > > => You can read, that the native libraries were loaded via System#loadLibrary > > > > -------------------------------------------------------------------- > > > > This result also explains why the problem is not visible with the > > binaries from jdk.java.net: The java executables use different > > java.library.paths: > > > > Ubuntu: > > > > java.library.path = /usr/java/packages/lib > > /usr/lib/x86_64-linux-gnu/jni > > /lib/x86_64-linux-gnu > > /usr/lib/x86_64-linux-gnu > > /usr/lib/jni > > /lib > > /usr/lib > > > > OpenJDK: > > > > java.library.path = /usr/java/packages/lib > > /usr/lib64 > > /lib64 > > /lib > > /usr/lib > > > > As contents of the libopenjfx-jni package is installed to > > /usr/lib/x86_64-linux-gnu/jni/, only the Ubuntu java launcher finds the > > binaries. > > > > -------------------------------------------------------------------- > > > > It is not too surprising, that the native libraries and the java > > implementations are tightly coupled. For the JNA project we are faced > > with the same situation. However, there are differences: > > > > - the JNA project checks, that the native libraries are > > of a compatible version > > - there is a system property, that lets the user choose whether > > system libraries should be used or the bundled native libraries be > > extracted > > - the system property was changed to default to use the bundled native > > libraries > > > > I had a quick look at the NativeLibraryLoader and don't see a similar > > mechanism. The only work around I found was overriding the > > java.library.path, but that requires changes to the launch sequence of > > the VM. > > > > > > For a managed language, I don't think a segfault is a valid result for > > loading HTML and thus should not be just a P4. It is not uncommon to > > have the distribution libraries installed, so I expect the problem to > > be present on more systems. > > > > > > Thank you > > > > Matthias > > From kevin.rushforth at oracle.com Sat May 11 14:15:12 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 11 May 2019 07:15:12 -0700 Subject: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points In-Reply-To: References: <54df38b8986ec59276b58daa299d1c626bcef4ce.camel@doppel-helix.eu> Message-ID: <63c9c907-609f-70ea-fb33-f2b95e1e156d@oracle.com> Hi Matthias, I was not aware that Ubuntu distributed a standalone JavaFX library, so yes that explains the problem. I will file an RFE to add the native / class file versioning checks that you mentioned, but that's likely to be a bit of work, since I think it would be worth doing only if done as part of the initial load library in such a way that when it fails, it considers it a failed load (and moves on to the next method of finding the libraries (although there is still some value in early detection and a thrown exception with a reasonable error message versus the crash that happens today). I think the best short-term solution is your suggestion of changing the order of precedence such that System.loadLibrary is last, which is more in keeping with what we do when running the SDK: the libraries associated with the class files should be used in preference to the system libraries. -- Kevin On 5/11/2019 6:32 AM, Matthias Bl?sing wrote: > [Resend to Mailinglist, I'm subscribed and did not see, that it was > directly send to me] > > Hi Kevin, > > the problem on Ubuntu is this: When you install a package, that > requires OpenJFX (for example mediathekview), the package > libopenjfx-jni is installed as a dependency. > > The package libopenjfx-jni installs the OpenJFX native libraries into > the folder /usr/lib/x86_64-linux-gnu/jni. This is all good if you are > only using distribution libraries, but when using a third-party > application, that requires JavaFX, it breaks. In my case this is Apache > NetBeans, that can't even bundle a JVM (ASF requirement), so using the > system VM is the logical choice. > > The problem is in com.sun.glass.utils.NativeLibLoader#loadLibraryInternal. > The native libraries are loaded: > > - from filesstem in the same folder as the jar > - via System#loadLibrary > - extracted from the resources of the jar > > The options are tried in that order and the first successful wins. > > In my case instead of loading the working native libraries from the maven > jars, the system ones are picked up via System#loadLibrary. This means, > I get the OpenJFX native libraries for 11.0.2 with the OpenJFX java > classes of 13-ea+7 (for the newest variant). This is obvisually a bad > idea (the crash shows that clearly). > > For JNA two thinks are done: The native libraries are versioned independently > from the java classes and after loading the library the java part checks if > a compatible native library was loaded (same major, same or higher minor > version). The java classes embedd the version of the native library they > expect and the native library embeds its real version, so mismatches can be > detected before the JVM blows. > > Another difference: Today JNA prefers its bundled native library if not > requested differently via system property. For desktop systems JNA now tries > to load the library first from the JAR and only falls back to system libraries, > if that fails. > > > Does this clear up the situation a bit? > > > Greetings > > Matthias > > > Am Freitag, den 10.05.2019, 13:50 -0700 schrieb Kevin Rushforth: >> The normal submission process yielded a bug report to be evaluated, and >> it's still in the queue to be looked at. Since you provided some >> additional information, we can add it to the bug report as a comment. >> Btw, the direct URL for the bug in JBS is: >> >> https://bugs.openjdk.java.net/browse/JDK-8223377 >> >> From your aditional comments, it sounds as if this is some sort of >> system configuration issue. Unless there are JavaFX classes or .so files >> in your JDK (which is not supported with OpenJFX 11 or greater), I don't >> know how you would see the mismatch between the javafx.web class files >> and the jfxwebkit.so native library. >> >> -- Kevin >> >> >> On 5/10/2019 1:23 PM, Matthias Bl?sing wrote: >>> Hello, >>> >>> as the normal submission process did not yield an update for the >>> above >>> mentioned issue and this is a crasher, I try to get the information >>> submitted here. >>> >>> As reference the JDK issue: >>> >>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8223377 >>> >>> Summary: >>> >>> I experimented with OpenJFX once again and noticed, that even >>> simple >>> programms crashed for me. I saw the crashes being introduced in >>> maven >>> release: >>> >>> >>> org.openjfx >>> javafx-controls >>> 12-ea+7 >>> >>> >>> org.openjfx >>> javafx-web >>> 12-ea+7 >>> >>> >>> Until that version this stack trace is generated: >>> >>> java.lang.ArrayIndexOutOfBoundsException: Index -17 out of bounds for length 32 >>> at com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) >>> at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) >>> at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) >>> at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$10.doPaint(WCGraphicsPrismContext.java:939) >>> at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite.paint(WCGraphicsPrismContext.java:1524) >>> at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite.paint(WCGraphicsPrismContext.java:1509) >>> at com.sun.javafx.webkit.prism.WCGraphicsPrismContext.drawString(WCGraphicsPrismContext.java:951) >>> at com.sun.webkit.graphics.GraphicsDecoder.decode(GraphicsDecoder.java:301) >>> at com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java:92) >>> at com.sun.webkit.WebPage.paint2GC(WebPage.java:736) >>> at com.sun.webkit.WebPage.paint(WebPage.java:703) >>> at com.sun.javafx.sg.prism.web.NGWebView.renderContent(NGWebView.java:95) >>> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >>> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >>> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>> at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) >>> at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) >>> at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) >>> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>> at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>> at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>> at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>> at java.base/java.lang.Thread.run(Thread.java:834) >>> >>> I tried to corner the problem and noticed, that the crash is _not_ >>> reproducible with the java binary from jdk.java.net. The crash is also >>> not reproducible with a Ubuntu Live CD with only the default-jre >>> installed. >>> >>> Then I tried to align the live environment (does not crash) with my >>> desktop system (OpenJFX crashes). And finally I found the problem. >>> >>> 1. Get the Xubuntu 19.04 live CD: >>> http://torrent.ubuntu.com/xubuntu/releases/disco/release/desktop/xubuntu-19.04-desktop-amd64.iso.torrent >>> 2. Start the Image (Try Xubuntu) in VirtualBox >>> 3. Install the default JDK (that will be 11.0.3) and maven: >>> sudo apt install default-jdk maven git >>> 4. Clone the reproducer repository: >>> git clone https://github.com/matthiasblaesing/reproduce-openjfx-crash.git >>> 5. Build it: >>> cd reproduce-openjfx-crash >>> mvn package >>> 6. Run with: >>> java -jar target/reproduce-openjfx-crash.jar >>> >>> => Window with the title "Hello World!", the text "Test" and japanese/sudanese punctuation symbols are shown >>> => In the console, you see, that the native libraries are loaded from resource >>> >>> 7. Close windows >>> 8. Install openjfx JNI libraries: >>> apt install libopenjfx-jni >>> 9. Run again with: >>> java -jar target/reproduce-openjfx-crash.jar >>> >>> => Window is briefly displayed >>> => On the console a SEGFAULS is logged (and hs_err_pid... is written) >>> => You can read, that the native libraries were loaded via System#loadLibrary >>> >>> -------------------------------------------------------------------- >>> >>> This result also explains why the problem is not visible with the >>> binaries from jdk.java.net: The java executables use different >>> java.library.paths: >>> >>> Ubuntu: >>> >>> java.library.path = /usr/java/packages/lib >>> /usr/lib/x86_64-linux-gnu/jni >>> /lib/x86_64-linux-gnu >>> /usr/lib/x86_64-linux-gnu >>> /usr/lib/jni >>> /lib >>> /usr/lib >>> >>> OpenJDK: >>> >>> java.library.path = /usr/java/packages/lib >>> /usr/lib64 >>> /lib64 >>> /lib >>> /usr/lib >>> >>> As contents of the libopenjfx-jni package is installed to >>> /usr/lib/x86_64-linux-gnu/jni/, only the Ubuntu java launcher finds the >>> binaries. >>> >>> -------------------------------------------------------------------- >>> >>> It is not too surprising, that the native libraries and the java >>> implementations are tightly coupled. For the JNA project we are faced >>> with the same situation. However, there are differences: >>> >>> - the JNA project checks, that the native libraries are >>> of a compatible version >>> - there is a system property, that lets the user choose whether >>> system libraries should be used or the bundled native libraries be >>> extracted >>> - the system property was changed to default to use the bundled native >>> libraries >>> >>> I had a quick look at the NativeLibraryLoader and don't see a similar >>> mechanism. The only work around I found was overriding the >>> java.library.path, but that requires changes to the launch sequence of >>> the VM. >>> >>> >>> For a managed language, I don't think a segfault is a valid result for >>> loading HTML and thus should not be just a P4. It is not uncommon to >>> have the distribution libraries installed, so I expect the problem to >>> be present on more systems. >>> >>> >>> Thank you >>> >>> Matthias >>> From kevin.rushforth at oracle.com Sat May 11 15:45:39 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 11 May 2019 08:45:39 -0700 Subject: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points In-Reply-To: <63c9c907-609f-70ea-fb33-f2b95e1e156d@oracle.com> References: <54df38b8986ec59276b58daa299d1c626bcef4ce.camel@doppel-helix.eu> <63c9c907-609f-70ea-fb33-f2b95e1e156d@oracle.com> Message-ID: <904e26ee-f969-c50c-7cca-8b4007cae4c1@oracle.com> Based on the additional info I raised the priority of JDK-8223377 [1] to P3 and targeted it to openjfx13. I filed JDK-8223746 [2] to track the request to check the version the native libraries (not targeted to a particular release). -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8223377 [2] https://bugs.openjdk.java.net/browse/JDK-8223746 On 5/11/2019 7:15 AM, Kevin Rushforth wrote: > Hi Matthias, > > I was not aware that Ubuntu distributed a standalone JavaFX library, > so yes that explains the problem. > > I will file an RFE to add the native / class file versioning checks > that you mentioned, but that's likely to be a bit of work, since I > think it would be worth doing only if done as part of the initial load > library in such a way that when it fails, it considers it a failed > load (and moves on to the next method of finding the libraries > (although there is still some value in early detection and a thrown > exception with a reasonable error message versus the crash that > happens today). > > I think the best short-term solution is your suggestion of changing > the order of precedence such that System.loadLibrary is last, which is > more in keeping with what we do when running the SDK: the libraries > associated with the class files should be used in preference to the > system libraries. > > -- Kevin > > > On 5/11/2019 6:32 AM, Matthias Bl?sing wrote: >> [Resend to Mailinglist, I'm subscribed and did not see, that it was >> directly send to me] >> >> Hi Kevin, >> >> the problem on Ubuntu is this: When you install a package, that >> requires OpenJFX (for example mediathekview), the package >> libopenjfx-jni is installed as a dependency. >> >> The package libopenjfx-jni installs the OpenJFX native libraries into >> the folder /usr/lib/x86_64-linux-gnu/jni. This is all good if you are >> only using distribution libraries, but when using a third-party >> application, that requires JavaFX, it breaks. In my case this is Apache >> NetBeans, that can't even bundle a JVM (ASF requirement), so using the >> system VM is the logical choice. >> >> The problem is in >> com.sun.glass.utils.NativeLibLoader#loadLibraryInternal. >> The native libraries are loaded: >> >> - from filesstem in the same folder as the jar >> - via System#loadLibrary >> - extracted from the resources of the jar >> >> The options are tried in that order and the first successful wins. >> >> In my case instead of loading the working native libraries from the >> maven >> jars, the system ones are picked up via System#loadLibrary. This means, >> I get the OpenJFX native libraries for 11.0.2 with the OpenJFX java >> classes of 13-ea+7 (for the newest variant). This is obvisually a bad >> idea (the crash shows that clearly). >> >> For JNA two thinks are done: The native libraries are versioned >> independently >> from the java classes and after loading the library the java part >> checks if >> a compatible native library was loaded (same major, same or higher minor >> version). The java classes embedd the version of the native library they >> expect and the native library embeds its real version, so mismatches >> can be >> detected before the JVM blows. >> >> Another difference: Today JNA prefers its bundled native library if not >> requested differently via system property. For desktop systems JNA >> now tries >> to load the library first from the JAR and only falls back to system >> libraries, >> if that fails. >> >> >> Does this clear up the situation a bit? >> >> >> Greetings >> >> Matthias >> >> >> Am Freitag, den 10.05.2019, 13:50 -0700 schrieb Kevin Rushforth: >>> The normal submission process yielded a bug report to be evaluated, and >>> it's still in the queue to be looked at. Since you provided some >>> additional information, we can add it to the bug report as a comment. >>> Btw, the direct URL for the bug in JBS is: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8223377 >>> >>> ? From your aditional comments, it sounds as if this is some sort of >>> system configuration issue. Unless there are JavaFX classes or .so >>> files >>> in your JDK (which is not supported with OpenJFX 11 or greater), I >>> don't >>> know how you would see the mismatch between the javafx.web class files >>> and the jfxwebkit.so native library. >>> >>> -- Kevin >>> >>> >>> On 5/10/2019 1:23 PM, Matthias Bl?sing wrote: >>>> Hello, >>>> >>>> as the normal submission process did not yield an update for the >>>> above >>>> mentioned issue and this is a crasher, I try to get the information >>>> submitted here. >>>> >>>> As reference the JDK issue: >>>> >>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8223377 >>>> >>>> Summary: >>>> >>>> I experimented with OpenJFX once again and noticed, that even >>>> simple >>>> programms crashed for me. I saw the crashes being introduced in >>>> maven >>>> release: >>>> >>>> ????????? >>>> ????????????? org.openjfx >>>> javafx-controls >>>> ????????????? 12-ea+7 >>>> ????????? >>>> ????????? >>>> ????????????? org.openjfx >>>> javafx-web >>>> ????????????? 12-ea+7 >>>> ????????? >>>> >>>> Until that version this stack trace is generated: >>>> >>>> java.lang.ArrayIndexOutOfBoundsException: Index -17 out of bounds >>>> for length 32 >>>> ????at >>>> com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) >>>> ????at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) >>>> ????at >>>> com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) >>>> ????at >>>> com.sun.javafx.webkit.prism.WCGraphicsPrismContext$10.doPaint(WCGraphicsPrismContext.java:939) >>>> ????at >>>> com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite.paint(WCGraphicsPrismContext.java:1524) >>>> ????at >>>> com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite.paint(WCGraphicsPrismContext.java:1509) >>>> ????at >>>> com.sun.javafx.webkit.prism.WCGraphicsPrismContext.drawString(WCGraphicsPrismContext.java:951) >>>> ????at >>>> com.sun.webkit.graphics.GraphicsDecoder.decode(GraphicsDecoder.java:301) >>>> >>>> ????at >>>> com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java:92) >>>> ????at com.sun.webkit.WebPage.paint2GC(WebPage.java:736) >>>> ????at com.sun.webkit.WebPage.paint(WebPage.java:703) >>>> ????at >>>> com.sun.javafx.sg.prism.web.NGWebView.renderContent(NGWebView.java:95) >>>> ????at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>>> ????at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>>> ????at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >>>> ????at >>>> com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >>>> ????at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >>>> ????at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >>>> ????at >>>> com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) >>>> ????at >>>> com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) >>>> ????at >>>> com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) >>>> ????at >>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >>>> ????at >>>> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >>>> ????at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>>> ????at >>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >>>> ????at >>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >>>> ????at >>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>>> ????at java.base/java.lang.Thread.run(Thread.java:834) >>>> >>>> I tried to corner the problem and noticed, that the crash is _not_ >>>> reproducible with the java binary from jdk.java.net. The crash is also >>>> not reproducible with a Ubuntu Live CD with only the default-jre >>>> installed. >>>> >>>> Then I tried to align the live environment (does not crash) with my >>>> desktop system (OpenJFX crashes). And finally I found the problem. >>>> >>>> 1. Get the Xubuntu 19.04 live CD: >>>> http://torrent.ubuntu.com/xubuntu/releases/disco/release/desktop/xubuntu-19.04-desktop-amd64.iso.torrent >>>> 2. Start the Image (Try Xubuntu) in VirtualBox >>>> 3. Install the default JDK (that will be 11.0.3) and maven: >>>> ???? sudo apt install default-jdk maven git >>>> 4. Clone the reproducer repository: >>>> ???? git clone >>>> https://github.com/matthiasblaesing/reproduce-openjfx-crash.git >>>> 5. Build it: >>>> ???? cd reproduce-openjfx-crash >>>> ???? mvn package >>>> 6. Run with: >>>> ???? java -jar target/reproduce-openjfx-crash.jar >>>> >>>> => Window with the title "Hello World!", the text "Test" and >>>> japanese/sudanese punctuation symbols are shown >>>> => In the console, you see, that the native libraries are loaded >>>> from resource >>>> >>>> 7. Close windows >>>> 8. Install openjfx JNI libraries: >>>> ???? apt install libopenjfx-jni >>>> 9. Run again with: >>>> ???? java -jar target/reproduce-openjfx-crash.jar >>>> >>>> => Window is briefly displayed >>>> => On the console a SEGFAULS is logged (and hs_err_pid... is written) >>>> => You can read, that the native libraries were loaded via >>>> System#loadLibrary >>>> >>>> -------------------------------------------------------------------- >>>> >>>> This result also explains why the problem is not visible with the >>>> binaries from jdk.java.net: The java executables use different >>>> java.library.paths: >>>> >>>> Ubuntu: >>>> >>>> java.library.path = /usr/java/packages/lib >>>> ????????? /usr/lib/x86_64-linux-gnu/jni >>>> ????????? /lib/x86_64-linux-gnu >>>> ????????? /usr/lib/x86_64-linux-gnu >>>> ????????? /usr/lib/jni >>>> ????????? /lib >>>> ????????? /usr/lib >>>> >>>> OpenJDK: >>>> >>>> ????? java.library.path = /usr/java/packages/lib >>>> ????????? /usr/lib64 >>>> ????????? /lib64 >>>> ????????? /lib >>>> ????????? /usr/lib >>>> >>>> As contents of the libopenjfx-jni package is installed to >>>> /usr/lib/x86_64-linux-gnu/jni/, only the Ubuntu java launcher finds >>>> the >>>> binaries. >>>> >>>> -------------------------------------------------------------------- >>>> >>>> It is not too surprising, that the native libraries and the java >>>> implementations are tightly coupled. For the JNA project we are faced >>>> with the same situation. However, there are differences: >>>> >>>> - the JNA project checks, that the native libraries are >>>> ??? of a compatible version >>>> - there is a system property, that lets the user choose whether >>>> ??? system libraries should be used or the bundled native libraries be >>>> ??? extracted >>>> - the system property was changed to default to use the bundled native >>>> ??? libraries >>>> >>>> I had a quick look at the NativeLibraryLoader and don't see a similar >>>> mechanism. The only work around I found was overriding the >>>> java.library.path, but that requires changes to the launch sequence of >>>> the VM. >>>> >>>> >>>> For a managed language, I don't think a segfault is a valid result for >>>> loading HTML and thus should not be just a P4. It is not uncommon to >>>> have the distribution libraries installed, so I expect the problem to >>>> be present on more systems. >>>> >>>> >>>> Thank you >>>> >>>> Matthias >>>> > From mblaesing at doppel-helix.eu Sun May 12 16:27:55 2019 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Sun, 12 May 2019 18:27:55 +0200 Subject: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points In-Reply-To: <904e26ee-f969-c50c-7cca-8b4007cae4c1@oracle.com> References: <54df38b8986ec59276b58daa299d1c626bcef4ce.camel@doppel-helix.eu> <63c9c907-609f-70ea-fb33-f2b95e1e156d@oracle.com> <904e26ee-f969-c50c-7cca-8b4007cae4c1@oracle.com> Message-ID: <42ef8fbb1985cfb3d4839b8cc2941627a83afa0c.camel@doppel-helix.eu> Hi Kevin, thank you for the update of the issue. I had a deeper look at the NativeLibLoader code and made an attempt to fix the issue. I'll send the required review request email shortly. Greetings Matthias Am Samstag, den 11.05.2019, 08:45 -0700 schrieb Kevin Rushforth: > Based on the additional info I raised the priority of JDK-8223377 [1] to > P3 and targeted it to openjfx13. I filed JDK-8223746 [2] to track the > request to check the version the native libraries (not targeted to a > particular release). > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8223377 > [2] https://bugs.openjdk.java.net/browse/JDK-8223746 > > > On 5/11/2019 7:15 AM, Kevin Rushforth wrote: > > Hi Matthias, > > > > I was not aware that Ubuntu distributed a standalone JavaFX > > library, > > so yes that explains the problem. > > > > I will file an RFE to add the native / class file versioning > > checks > > that you mentioned, but that's likely to be a bit of work, since I > > think it would be worth doing only if done as part of the initial > > load > > library in such a way that when it fails, it considers it a failed > > load (and moves on to the next method of finding the libraries > > (although there is still some value in early detection and a > > thrown > > exception with a reasonable error message versus the crash that > > happens today). > > > > I think the best short-term solution is your suggestion of > > changing > > the order of precedence such that System.loadLibrary is last, which > > is > > more in keeping with what we do when running the SDK: the > > libraries > > associated with the class files should be used in preference to > > the > > system libraries. > > > > -- Kevin > > > > > > On 5/11/2019 6:32 AM, Matthias Bl?sing wrote: > > > [Resend to Mailinglist, I'm subscribed and did not see, that it > > > was > > > directly send to me] > > > > > > Hi Kevin, > > > > > > the problem on Ubuntu is this: When you install a package, that > > > requires OpenJFX (for example mediathekview), the package > > > libopenjfx-jni is installed as a dependency. > > > > > > The package libopenjfx-jni installs the OpenJFX native libraries > > > into > > > the folder /usr/lib/x86_64-linux-gnu/jni. This is all good if you > > > are > > > only using distribution libraries, but when using a third-party > > > application, that requires JavaFX, it breaks. In my case this is > > > Apache > > > NetBeans, that can't even bundle a JVM (ASF requirement), so > > > using the > > > system VM is the logical choice. > > > > > > The problem is in > > > com.sun.glass.utils.NativeLibLoader#loadLibraryInternal. > > > The native libraries are loaded: > > > > > > - from filesstem in the same folder as the jar > > > - via System#loadLibrary > > > - extracted from the resources of the jar > > > > > > The options are tried in that order and the first successful > > > wins. > > > > > > In my case instead of loading the working native libraries from > > > the > > > maven > > > jars, the system ones are picked up via System#loadLibrary. This > > > means, > > > I get the OpenJFX native libraries for 11.0.2 with the OpenJFX > > > java > > > classes of 13-ea+7 (for the newest variant). This is obvisually a > > > bad > > > idea (the crash shows that clearly). > > > > > > For JNA two thinks are done: The native libraries are versioned > > > independently > > > from the java classes and after loading the library the java > > > part > > > checks if > > > a compatible native library was loaded (same major, same or > > > higher minor > > > version). The java classes embedd the version of the native > > > library they > > > expect and the native library embeds its real version, so > > > mismatches > > > can be > > > detected before the JVM blows. > > > > > > Another difference: Today JNA prefers its bundled native library > > > if not > > > requested differently via system property. For desktop systems > > > JNA > > > now tries > > > to load the library first from the JAR and only falls back to > > > system > > > libraries, > > > if that fails. > > > > > > > > > Does this clear up the situation a bit? > > > > > > > > > Greetings > > > > > > Matthias > > > > > > > > > Am Freitag, den 10.05.2019, 13:50 -0700 schrieb Kevin Rushforth: > > > > The normal submission process yielded a bug report to be > > > > evaluated, and > > > > it's still in the queue to be looked at. Since you provided > > > > some > > > > additional information, we can add it to the bug report as a > > > > comment. > > > > Btw, the direct URL for the bug in JBS is: > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8223377 > > > > > > > > From your aditional comments, it sounds as if this is some > > > > sort of > > > > system configuration issue. Unless there are JavaFX classes or > > > > .so > > > > files > > > > in your JDK (which is not supported with OpenJFX 11 or > > > > greater), I > > > > don't > > > > know how you would see the mismatch between the javafx.web > > > > class files > > > > and the jfxwebkit.so native library. > > > > > > > > -- Kevin > > > > > > > > > > > > On 5/10/2019 1:23 PM, Matthias Bl?sing wrote: > > > > > Hello, > > > > > > > > > > as the normal submission process did not yield an update for > > > > > the > > > > > above > > > > > mentioned issue and this is a crasher, I try to get the > > > > > information > > > > > submitted here. > > > > > > > > > > As reference the JDK issue: > > > > > > > > > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8223377 > > > > > > > > > > Summary: > > > > > > > > > > I experimented with OpenJFX once again and noticed, that even > > > > > simple > > > > > programms crashed for me. I saw the crashes being introduced > > > > > in > > > > > maven > > > > > release: > > > > > > > > > > > > > > > org.openjfx > > > > > javafx-controls > > > > > 12-ea+7 > > > > > > > > > > > > > > > org.openjfx > > > > > javafx-web > > > > > 12-ea+7 > > > > > > > > > > > > > > > Until that version this stack trace is generated: > > > > > > > > > > java.lang.ArrayIndexOutOfBoundsException: Index -17 out of > > > > > bounds > > > > > for length 32 > > > > > at > > > > > com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java: > > > > > 332) > > > > > at > > > > > com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) > > > > > at > > > > > com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShade > > > > > rGraphics.java:2101) > > > > > at > > > > > com.sun.javafx.webkit.prism.WCGraphicsPrismContext$10.doPaint > > > > > (WCGraphicsPrismContext.java:939) > > > > > at > > > > > com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite. > > > > > paint(WCGraphicsPrismContext.java:1524) > > > > > at > > > > > com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite. > > > > > paint(WCGraphicsPrismContext.java:1509) > > > > > at > > > > > com.sun.javafx.webkit.prism.WCGraphicsPrismContext.drawString > > > > > (WCGraphicsPrismContext.java:951) > > > > > at > > > > > com.sun.webkit.graphics.GraphicsDecoder.decode(GraphicsDecode > > > > > r.java:301) > > > > > > > > > > at > > > > > com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.ja > > > > > va:92) > > > > > at com.sun.webkit.WebPage.paint2GC(WebPage.java:736) > > > > > at com.sun.webkit.WebPage.paint(WebPage.java:703) > > > > > at > > > > > com.sun.javafx.sg.prism.web.NGWebView.renderContent(NGWebView > > > > > .java:95) > > > > > at > > > > > com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > > > > > at > > > > > com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > > > > > at > > > > > com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:27 > > > > > 0) > > > > > at > > > > > com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java: > > > > > 578) > > > > > at > > > > > com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > > > > > at > > > > > com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > > > > > at > > > > > com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.jav > > > > > a:479) > > > > > at > > > > > com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.j > > > > > ava:328) > > > > > at > > > > > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPai > > > > > nter.java:91) > > > > > at > > > > > java.base/java.util.concurrent.Executors$RunnableAdapter.call > > > > > (Executors.java:515) > > > > > at > > > > > java.base/java.util.concurrent.FutureTask.runAndReset(FutureT > > > > > ask.java:305) > > > > > at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > > > > > at > > > > > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(T > > > > > hreadPoolExecutor.java:1128) > > > > > at > > > > > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run( > > > > > ThreadPoolExecutor.java:628) > > > > > at > > > > > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.ru > > > > > n(QuantumRenderer.java:125) > > > > > at java.base/java.lang.Thread.run(Thread.java:834) > > > > > > > > > > I tried to corner the problem and noticed, that the crash is > > > > > _not_ > > > > > reproducible with the java binary from jdk.java.net. The > > > > > crash is also > > > > > not reproducible with a Ubuntu Live CD with only the default- > > > > > jre > > > > > installed. > > > > > > > > > > Then I tried to align the live environment (does not crash) > > > > > with my > > > > > desktop system (OpenJFX crashes). And finally I found the > > > > > problem. > > > > > > > > > > 1. Get the Xubuntu 19.04 live CD: > > > > > http://torrent.ubuntu.com/xubuntu/releases/disco/release/desktop/xubuntu-19.04-desktop-amd64.iso.torrent > > > > > 2. Start the Image (Try Xubuntu) in VirtualBox > > > > > 3. Install the default JDK (that will be 11.0.3) and maven: > > > > > sudo apt install default-jdk maven git > > > > > 4. Clone the reproducer repository: > > > > > git clone > > > > > https://github.com/matthiasblaesing/reproduce-openjfx-crash.git > > > > > 5. Build it: > > > > > cd reproduce-openjfx-crash > > > > > mvn package > > > > > 6. Run with: > > > > > java -jar target/reproduce-openjfx-crash.jar > > > > > > > > > > => Window with the title "Hello World!", the text "Test" and > > > > > japanese/sudanese punctuation symbols are shown > > > > > => In the console, you see, that the native libraries are > > > > > loaded > > > > > from resource > > > > > > > > > > 7. Close windows > > > > > 8. Install openjfx JNI libraries: > > > > > apt install libopenjfx-jni > > > > > 9. Run again with: > > > > > java -jar target/reproduce-openjfx-crash.jar > > > > > > > > > > => Window is briefly displayed > > > > > => On the console a SEGFAULS is logged (and hs_err_pid... is > > > > > written) > > > > > => You can read, that the native libraries were loaded via > > > > > System#loadLibrary > > > > > > > > > > ----------------------------------------------------------- > > > > > --------- > > > > > > > > > > This result also explains why the problem is not visible with > > > > > the > > > > > binaries from jdk.java.net: The java executables use > > > > > different > > > > > java.library.paths: > > > > > > > > > > Ubuntu: > > > > > > > > > > java.library.path = /usr/java/packages/lib > > > > > /usr/lib/x86_64-linux-gnu/jni > > > > > /lib/x86_64-linux-gnu > > > > > /usr/lib/x86_64-linux-gnu > > > > > /usr/lib/jni > > > > > /lib > > > > > /usr/lib > > > > > > > > > > OpenJDK: > > > > > > > > > > java.library.path = /usr/java/packages/lib > > > > > /usr/lib64 > > > > > /lib64 > > > > > /lib > > > > > /usr/lib > > > > > > > > > > As contents of the libopenjfx-jni package is installed to > > > > > /usr/lib/x86_64-linux-gnu/jni/, only the Ubuntu java launcher > > > > > finds > > > > > the > > > > > binaries. > > > > > > > > > > ----------------------------------------------------------- > > > > > --------- > > > > > > > > > > It is not too surprising, that the native libraries and the > > > > > java > > > > > implementations are tightly coupled. For the JNA project we > > > > > are faced > > > > > with the same situation. However, there are differences: > > > > > > > > > > - the JNA project checks, that the native libraries are > > > > > of a compatible version > > > > > - there is a system property, that lets the user choose > > > > > whether > > > > > system libraries should be used or the bundled native > > > > > libraries be > > > > > extracted > > > > > - the system property was changed to default to use the > > > > > bundled native > > > > > libraries > > > > > > > > > > I had a quick look at the NativeLibraryLoader and don't see a > > > > > similar > > > > > mechanism. The only work around I found was overriding the > > > > > java.library.path, but that requires changes to the launch > > > > > sequence of > > > > > the VM. > > > > > > > > > > > > > > > For a managed language, I don't think a segfault is a valid > > > > > result for > > > > > loading HTML and thus should not be just a P4. It is not > > > > > uncommon to > > > > > have the distribution libraries installed, so I expect the > > > > > problem to > > > > > be present on more systems. > > > > > > > > > > > > > > > Thank you > > > > > > > > > > Matthias > > > > > From mblaesing at doppel-helix.eu Sun May 12 16:33:45 2019 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Sun, 12 May 2019 18:33:45 +0200 Subject: RFR: JDK-8223377: JavaFX can crash due to loading the wrong native libraries if system libraries are installed Message-ID: <30a6612577bc19928b76d8f5061da14880698072.camel@doppel-helix.eu> Please review the following fix to prevent crashes in JavaFX if the wrong native libraries are loaded from system locations instead of the bundled native library. https://bugs.openjdk.java.net/browse/JDK-8223377 https://github.com/javafxports/openjdk-jfx/pull/468 Thank you Matthias From thiago.sayao at clamed.com.br Mon May 13 13:29:04 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Mon, 13 May 2019 13:29:04 +0000 Subject: Findings on JDK-8211302 Message-ID: Hello, I have been looking into JDK-8211302. https://bugs.openjdk.java.net/browse/JDK-8211302 Did not find a solution, but the problem is because gdk_drag_context_get_selected_action(event->context) is returning ZERO. That's also why the cursor does not update on the drop location. Subsequent events do not get fired to complete the drop, because it falls on the abort code below: static void process_dnd_source_mouse_release(GdkWindow *window, GdkEventButton *event) { (void)window; (void)event; glass_gdk_master_pointer_ungrab(); if (gdk_drag_context_get_selected_action(get_drag_context())) { gdk_drag_drop(get_drag_context(), GDK_CURRENT_TIME); } else { gdk_drag_abort(get_drag_context(), GDK_CURRENT_TIME); /* let the gdk_drag_abort messages handled before finish */ gdk_threads_add_idle((GSourceFunc) dnd_finish_callback, NULL); } } I also suspect this will be needed, and it was introduced in GDK 3.20: gdk_drag_drop_done(get_drag_context(), TRUE) One solution is to check the version on build, other is to bundle the GTK lib (which makes it more safe to GDK changes). Cheers. From pankaj.b.bansal at oracle.com Mon May 13 13:38:37 2019 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 13 May 2019 06:38:37 -0700 (PDT) Subject: Findings on JDK-8211302 In-Reply-To: References: Message-ID: Hello Thiago, This solution was proposed by one of the engineers in Oracle sometime back and we have tested it. This does not seem to solve the issue. If you wish to try this, please take the patch [1], which is attached in the bug JDK-8211302. This patch neatly defines the function depending upon the gtk version. You can test this patch and let us know if you could make this work. [1] https://bugs.openjdk.java.net/secure/attachment/82098/8211302-drag-drop-done.patch -Pankaj -----Original Message----- From: Thiago Milczarek Sayao [mailto:thiago.sayao at clamed.com.br] Sent: Monday, May 13, 2019 6:59 PM To: openjfx-dev at openjdk.java.net Subject: Findings on JDK-8211302 Hello, I have been looking into JDK-8211302. https://bugs.openjdk.java.net/browse/JDK-8211302 Did not find a solution, but the problem is because gdk_drag_context_get_selected_action(event->context) is returning ZERO. That's also why the cursor does not update on the drop location. Subsequent events do not get fired to complete the drop, because it falls on the abort code below: static void process_dnd_source_mouse_release(GdkWindow *window, GdkEventButton *event) { (void)window; (void)event; glass_gdk_master_pointer_ungrab(); if (gdk_drag_context_get_selected_action(get_drag_context())) { gdk_drag_drop(get_drag_context(), GDK_CURRENT_TIME); } else { gdk_drag_abort(get_drag_context(), GDK_CURRENT_TIME); /* let the gdk_drag_abort messages handled before finish */ gdk_threads_add_idle((GSourceFunc) dnd_finish_callback, NULL); } } I also suspect this will be needed, and it was introduced in GDK 3.20: gdk_drag_drop_done(get_drag_context(), TRUE) One solution is to check the version on build, other is to bundle the GTK lib (which makes it more safe to GDK changes). Cheers. From thiago.sayao at clamed.com.br Mon May 13 13:47:28 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Mon, 13 May 2019 13:47:28 +0000 Subject: Findings on JDK-8211302 In-Reply-To: References: , Message-ID: It does not work because the problem happens before. But I suspect when the gdk_drag_context_get_selected_action(event->context) returning ZERO problem is fixed, the need of gdk_drag_drop_done() will be the problem. Cheers. ________________________________ De: Pankaj Bansal Enviado: segunda-feira, 13 de maio de 2019 10:38 Para: Thiago Milczarek Sayao; openjfx-dev at openjdk.java.net Assunto: RE: Findings on JDK-8211302 Hello Thiago, This solution was proposed by one of the engineers in Oracle sometime back and we have tested it. This does not seem to solve the issue. If you wish to try this, please take the patch [1], which is attached in the bug JDK-8211302. This patch neatly defines the function depending upon the gtk version. You can test this patch and let us know if you could make this work. [1] https://bugs.openjdk.java.net/secure/attachment/82098/8211302-drag-drop-done.patch -Pankaj -----Original Message----- From: Thiago Milczarek Sayao [mailto:thiago.sayao at clamed.com.br] Sent: Monday, May 13, 2019 6:59 PM To: openjfx-dev at openjdk.java.net Subject: Findings on JDK-8211302 Hello, I have been looking into JDK-8211302. https://bugs.openjdk.java.net/browse/JDK-8211302 Did not find a solution, but the problem is because gdk_drag_context_get_selected_action(event->context) is returning ZERO. That's also why the cursor does not update on the drop location. Subsequent events do not get fired to complete the drop, because it falls on the abort code below: static void process_dnd_source_mouse_release(GdkWindow *window, GdkEventButton *event) { (void)window; (void)event; glass_gdk_master_pointer_ungrab(); if (gdk_drag_context_get_selected_action(get_drag_context())) { gdk_drag_drop(get_drag_context(), GDK_CURRENT_TIME); } else { gdk_drag_abort(get_drag_context(), GDK_CURRENT_TIME); /* let the gdk_drag_abort messages handled before finish */ gdk_threads_add_idle((GSourceFunc) dnd_finish_callback, NULL); } } I also suspect this will be needed, and it was introduced in GDK 3.20: gdk_drag_drop_done(get_drag_context(), TRUE) One solution is to check the version on build, other is to bundle the GTK lib (which makes it more safe to GDK changes). Cheers. From m4gw4s at gmail.com Mon May 13 13:53:13 2019 From: m4gw4s at gmail.com (=?UTF-8?B?TWFnb3PDoW55aSDDgXJww6Fk?=) Date: Mon, 13 May 2019 14:53:13 +0100 Subject: Findings on JDK-8211302 In-Reply-To: References: Message-ID: Could this be related? https://stackoverflow.com/questions/56003372/javafx-11-fires-events-randomly On 5/13/19 2:29 PM, Thiago Milczarek Sayao wrote: > Hello, > > I have been looking into JDK-8211302. > > https://bugs.openjdk.java.net/browse/JDK-8211302 > > Did not find a solution, but the problem is because gdk_drag_context_get_selected_action(event->context) is returning ZERO. That's also why the cursor does not update on the drop location. Subsequent events do not get fired to complete the drop, because it falls on the abort code below: > > static void process_dnd_source_mouse_release(GdkWindow *window, GdkEventButton *event) { > (void)window; > (void)event; > > glass_gdk_master_pointer_ungrab(); > > if (gdk_drag_context_get_selected_action(get_drag_context())) { > gdk_drag_drop(get_drag_context(), GDK_CURRENT_TIME); > } else { > gdk_drag_abort(get_drag_context(), GDK_CURRENT_TIME); > /* let the gdk_drag_abort messages handled before finish */ > gdk_threads_add_idle((GSourceFunc) dnd_finish_callback, NULL); > } > } > > > I also suspect this will be needed, and it was introduced in GDK 3.20: > > gdk_drag_drop_done(get_drag_context(), TRUE) > > One solution is to check the version on build, other is to bundle the GTK lib (which makes it more safe to GDK changes). > > Cheers. From pankaj.b.bansal at oracle.com Mon May 13 13:59:57 2019 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 13 May 2019 06:59:57 -0700 (PDT) Subject: Findings on JDK-8211302 In-Reply-To: References: > Message-ID: I think problem starts even before this as process_dnd_source_mouse_release is called when we release the mouse after drag and drop. But there we are not even able to initiate the dnd. If gdk_drag_context_get_selected_action(event->context) returning ZERO was the main issue, we should be able to start the drag and drop successfully. What do you think? -Pankaj -----Original Message----- From: Thiago Milczarek Sayao [mailto:thiago.sayao at clamed.com.br] Sent: Monday, May 13, 2019 7:17 PM To: openjfx-dev at openjdk.java.net Subject: RE: Findings on JDK-8211302 It does not work because the problem happens before. But I suspect when the gdk_drag_context_get_selected_action(event->context) returning ZERO problem is fixed, the need of gdk_drag_drop_done() will be the problem. Cheers. ________________________________ De: Pankaj Bansal Enviado: segunda-feira, 13 de maio de 2019 10:38 Para: Thiago Milczarek Sayao; openjfx-dev at openjdk.java.net Assunto: RE: Findings on JDK-8211302 Hello Thiago, This solution was proposed by one of the engineers in Oracle sometime back and we have tested it. This does not seem to solve the issue. If you wish to try this, please take the patch [1], which is attached in the bug JDK-8211302. This patch neatly defines the function depending upon the gtk version. You can test this patch and let us know if you could make this work. [1] https://bugs.openjdk.java.net/secure/attachment/82098/8211302-drag-drop-done.patch -Pankaj -----Original Message----- From: Thiago Milczarek Sayao [mailto:thiago.sayao at clamed.com.br] Sent: Monday, May 13, 2019 6:59 PM To: openjfx-dev at openjdk.java.net Subject: Findings on JDK-8211302 Hello, I have been looking into JDK-8211302. https://bugs.openjdk.java.net/browse/JDK-8211302 Did not find a solution, but the problem is because gdk_drag_context_get_selected_action(event->context) is returning ZERO. That's also why the cursor does not update on the drop location. Subsequent events do not get fired to complete the drop, because it falls on the abort code below: static void process_dnd_source_mouse_release(GdkWindow *window, GdkEventButton *event) { (void)window; (void)event; glass_gdk_master_pointer_ungrab(); if (gdk_drag_context_get_selected_action(get_drag_context())) { gdk_drag_drop(get_drag_context(), GDK_CURRENT_TIME); } else { gdk_drag_abort(get_drag_context(), GDK_CURRENT_TIME); /* let the gdk_drag_abort messages handled before finish */ gdk_threads_add_idle((GSourceFunc) dnd_finish_callback, NULL); } } I also suspect this will be needed, and it was introduced in GDK 3.20: gdk_drag_drop_done(get_drag_context(), TRUE) One solution is to check the version on build, other is to bundle the GTK lib (which makes it more safe to GDK changes). Cheers. From curtis.ruck at gmail.com Mon May 13 18:30:30 2019 From: curtis.ruck at gmail.com (Curtis Ruck) Date: Mon, 13 May 2019 14:30:30 -0400 Subject: GStreamer Message-ID: I'm investigating a new application that would need tighter integration with gstreamer. Is there a way to add additional gstreamer plugins and media types without having to maintain a fork of javafx-media? Ideally, if i did end up needing a fork, i was thinking it would make sense to split gstreamer-lite out of javafx-media into it's own project so I could easily swap in a full gstreamer dependency with 3rd project for the additional media types. Background: ideally looking to pull in udpsource and some additional pipeline plugins (GPU decoding and some subtitle related plugins). Thoughts? -- Curtis Ruck From thiago.sayao at clamed.com.br Tue May 14 01:28:29 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Tue, 14 May 2019 01:28:29 +0000 Subject: Findings on JDK-8211302 In-Reply-To: References: > , Message-ID: Did further investigation... I think the problem lies on Gdk mouse motion events not being fired. On gdk2 the GDK_DRAG_STATUS and GDK_MOTION_NOTIFY events fires many times, including when the drag operation leaves the root window. On gdk3 it fires a few times and does not keep firing when the cursor leaves the root window. It's on GlassApplication.cpp -> around line 419 static void process_events(GdkEvent* event, gpointer data) on gdk2 this keeps firing: if (is_in_drag()) { process_dnd_source(window, event); } on gdk3 it does not. Cheers. ________________________________ De: Pankaj Bansal Enviado: segunda-feira, 13 de maio de 2019 10:59 Para: Thiago Milczarek Sayao; openjfx-dev at openjdk.java.net Assunto: RE: Findings on JDK-8211302 I think problem starts even before this as process_dnd_source_mouse_release is called when we release the mouse after drag and drop. But there we are not even able to initiate the dnd. If gdk_drag_context_get_selected_action(event->context) returning ZERO was the main issue, we should be able to start the drag and drop successfully. What do you think? -Pankaj -----Original Message----- From: Thiago Milczarek Sayao [mailto:thiago.sayao at clamed.com.br] Sent: Monday, May 13, 2019 7:17 PM To: openjfx-dev at openjdk.java.net Subject: RE: Findings on JDK-8211302 It does not work because the problem happens before. But I suspect when the gdk_drag_context_get_selected_action(event->context) returning ZERO problem is fixed, the need of gdk_drag_drop_done() will be the problem. Cheers. ________________________________ De: Pankaj Bansal Enviado: segunda-feira, 13 de maio de 2019 10:38 Para: Thiago Milczarek Sayao; openjfx-dev at openjdk.java.net Assunto: RE: Findings on JDK-8211302 Hello Thiago, This solution was proposed by one of the engineers in Oracle sometime back and we have tested it. This does not seem to solve the issue. If you wish to try this, please take the patch [1], which is attached in the bug JDK-8211302. This patch neatly defines the function depending upon the gtk version. You can test this patch and let us know if you could make this work. [1] https://bugs.openjdk.java.net/secure/attachment/82098/8211302-drag-drop-done.patch -Pankaj -----Original Message----- From: Thiago Milczarek Sayao [mailto:thiago.sayao at clamed.com.br] Sent: Monday, May 13, 2019 6:59 PM To: openjfx-dev at openjdk.java.net Subject: Findings on JDK-8211302 Hello, I have been looking into JDK-8211302. https://bugs.openjdk.java.net/browse/JDK-8211302 Did not find a solution, but the problem is because gdk_drag_context_get_selected_action(event->context) is returning ZERO. That's also why the cursor does not update on the drop location. Subsequent events do not get fired to complete the drop, because it falls on the abort code below: static void process_dnd_source_mouse_release(GdkWindow *window, GdkEventButton *event) { (void)window; (void)event; glass_gdk_master_pointer_ungrab(); if (gdk_drag_context_get_selected_action(get_drag_context())) { gdk_drag_drop(get_drag_context(), GDK_CURRENT_TIME); } else { gdk_drag_abort(get_drag_context(), GDK_CURRENT_TIME); /* let the gdk_drag_abort messages handled before finish */ gdk_threads_add_idle((GSourceFunc) dnd_finish_callback, NULL); } } I also suspect this will be needed, and it was introduced in GDK 3.20: gdk_drag_drop_done(get_drag_context(), TRUE) One solution is to check the version on build, other is to bundle the GTK lib (which makes it more safe to GDK changes). Cheers. From thiago.sayao at clamed.com.br Tue May 14 01:29:41 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Tue, 14 May 2019 01:29:41 +0000 Subject: Findings on JDK-8211302 In-Reply-To: References: , Message-ID: Run it with -Djdk.gtk.version=2 If the problem stops, it's related. ________________________________ De: Magos?nyi ?rp?d Enviado: segunda-feira, 13 de maio de 2019 10:53 Para: Thiago Milczarek Sayao; openjfx-dev at openjdk.java.net Assunto: Re: Findings on JDK-8211302 Could this be related? https://stackoverflow.com/questions/56003372/javafx-11-fires-events-randomly On 5/13/19 2:29 PM, Thiago Milczarek Sayao wrote: > Hello, > > I have been looking into JDK-8211302. > > https://bugs.openjdk.java.net/browse/JDK-8211302 > > Did not find a solution, but the problem is because gdk_drag_context_get_selected_action(event->context) is returning ZERO. That's also why the cursor does not update on the drop location. Subsequent events do not get fired to complete the drop, because it falls on the abort code below: > > static void process_dnd_source_mouse_release(GdkWindow *window, GdkEventButton *event) { > (void)window; > (void)event; > > glass_gdk_master_pointer_ungrab(); > > if (gdk_drag_context_get_selected_action(get_drag_context())) { > gdk_drag_drop(get_drag_context(), GDK_CURRENT_TIME); > } else { > gdk_drag_abort(get_drag_context(), GDK_CURRENT_TIME); > /* let the gdk_drag_abort messages handled before finish */ > gdk_threads_add_idle((GSourceFunc) dnd_finish_callback, NULL); > } > } > > > I also suspect this will be needed, and it was introduced in GDK 3.20: > > gdk_drag_drop_done(get_drag_context(), TRUE) > > One solution is to check the version on build, other is to bundle the GTK lib (which makes it more safe to GDK changes). > > Cheers. From thiago.sayao at clamed.com.br Tue May 14 16:25:07 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Tue, 14 May 2019 16:25:07 +0000 Subject: Findings on JDK-8211302 In-Reply-To: References: > , , Message-ID: Found the problem! Managed to get it partially working, will do a proper fix when I get time. The problem lies on glass_general.cpp. To properly get the device and keep receiving mouse move events (required while dragging) gdk_event_get_device(event) must be used. For that, GdkEvent must be in the function arguments. Partially fixed: void glass_gdk_master_pointer_grab(GdkEvent *event, GdkWindow *window, GdkCursor *cursor) { if (disableGrab) { gdk_window_set_cursor(window, cursor); return; } #ifdef GLASS_GTK3 gdk_device_grab(gdk_event_get_device(event), window, GDK_OWNERSHIP_NONE, FALSE, GDK_ALL_EVENTS_MASK, cursor, GDK_CURRENT_TIME); #else gdk_pointer_grab(window, FALSE, (GdkEventMask) (GDK_POINTER_MOTION_MASK | GDK_BUTTON_MOTION_MASK | GDK_BUTTON1_MOTION_MASK | GDK_BUTTON2_MOTION_MASK | GDK_BUTTON3_MOTION_MASK | GDK_BUTTON_RELEASE_MASK), NULL, cursor, GDK_CURRENT_TIME); #endif } Original: void glass_gdk_master_pointer_grab(GdkWindow *window, GdkCursor *cursor) { if (disableGrab) { gdk_window_set_cursor(window, cursor); return; } #ifdef GLASS_GTK3 gdk_device_grab(gdk_device_manager_get_client_pointer( gdk_display_get_device_manager( gdk_display_get_default())), window, GDK_OWNERSHIP_NONE, FALSE, GDK_ALL_EVENTS_MASK, cursor, GDK_CURRENT_TIME); #else gdk_pointer_grab(window, FALSE, (GdkEventMask) (GDK_POINTER_MOTION_MASK | GDK_BUTTON_MOTION_MASK | GDK_BUTTON1_MOTION_MASK | GDK_BUTTON2_MOTION_MASK | GDK_BUTTON3_MOTION_MASK | GDK_BUTTON_RELEASE_MASK), NULL, cursor, GDK_CURRENT_TIME); #endif } ________________________________ De: openjfx-dev em nome de Thiago Milczarek Sayao Enviado: segunda-feira, 13 de maio de 2019 22:28 Para: Pankaj Bansal; openjfx-dev at openjdk.java.net Assunto: RE: Findings on JDK-8211302 Did further investigation... I think the problem lies on Gdk mouse motion events not being fired. On gdk2 the GDK_DRAG_STATUS and GDK_MOTION_NOTIFY events fires many times, including when the drag operation leaves the root window. On gdk3 it fires a few times and does not keep firing when the cursor leaves the root window. It's on GlassApplication.cpp -> around line 419 static void process_events(GdkEvent* event, gpointer data) on gdk2 this keeps firing: if (is_in_drag()) { process_dnd_source(window, event); } on gdk3 it does not. Cheers. ________________________________ De: Pankaj Bansal Enviado: segunda-feira, 13 de maio de 2019 10:59 Para: Thiago Milczarek Sayao; openjfx-dev at openjdk.java.net Assunto: RE: Findings on JDK-8211302 I think problem starts even before this as process_dnd_source_mouse_release is called when we release the mouse after drag and drop. But there we are not even able to initiate the dnd. If gdk_drag_context_get_selected_action(event->context) returning ZERO was the main issue, we should be able to start the drag and drop successfully. What do you think? -Pankaj -----Original Message----- From: Thiago Milczarek Sayao [mailto:thiago.sayao at clamed.com.br] Sent: Monday, May 13, 2019 7:17 PM To: openjfx-dev at openjdk.java.net Subject: RE: Findings on JDK-8211302 It does not work because the problem happens before. But I suspect when the gdk_drag_context_get_selected_action(event->context) returning ZERO problem is fixed, the need of gdk_drag_drop_done() will be the problem. Cheers. ________________________________ De: Pankaj Bansal Enviado: segunda-feira, 13 de maio de 2019 10:38 Para: Thiago Milczarek Sayao; openjfx-dev at openjdk.java.net Assunto: RE: Findings on JDK-8211302 Hello Thiago, This solution was proposed by one of the engineers in Oracle sometime back and we have tested it. This does not seem to solve the issue. If you wish to try this, please take the patch [1], which is attached in the bug JDK-8211302. This patch neatly defines the function depending upon the gtk version. You can test this patch and let us know if you could make this work. [1] https://bugs.openjdk.java.net/secure/attachment/82098/8211302-drag-drop-done.patch -Pankaj -----Original Message----- From: Thiago Milczarek Sayao [mailto:thiago.sayao at clamed.com.br] Sent: Monday, May 13, 2019 6:59 PM To: openjfx-dev at openjdk.java.net Subject: Findings on JDK-8211302 Hello, I have been looking into JDK-8211302. https://bugs.openjdk.java.net/browse/JDK-8211302 Did not find a solution, but the problem is because gdk_drag_context_get_selected_action(event->context) is returning ZERO. That's also why the cursor does not update on the drop location. Subsequent events do not get fired to complete the drop, because it falls on the abort code below: static void process_dnd_source_mouse_release(GdkWindow *window, GdkEventButton *event) { (void)window; (void)event; glass_gdk_master_pointer_ungrab(); if (gdk_drag_context_get_selected_action(get_drag_context())) { gdk_drag_drop(get_drag_context(), GDK_CURRENT_TIME); } else { gdk_drag_abort(get_drag_context(), GDK_CURRENT_TIME); /* let the gdk_drag_abort messages handled before finish */ gdk_threads_add_idle((GSourceFunc) dnd_finish_callback, NULL); } } I also suspect this will be needed, and it was introduced in GDK 3.20: gdk_drag_drop_done(get_drag_context(), TRUE) One solution is to check the version on build, other is to bundle the GTK lib (which makes it more safe to GDK changes). Cheers. From kevin.rushforth at oracle.com Tue May 14 23:55:04 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 May 2019 16:55:04 -0700 Subject: GStreamer In-Reply-To: References: Message-ID: <4f92da15-0fd4-cea9-a609-c1053601a48b@oracle.com> We don't currently plan to add support for pluggable codecs, but that might be something that the community could do, although it would be a large effort. As for splitting gstreamer-lite out of javafx.media, we are not likely to consider that. -- Kevin On 5/13/2019 11:30 AM, Curtis Ruck wrote: > I'm investigating a new application that would need tighter integration > with gstreamer. Is there a way to add additional gstreamer plugins and > media types without having to maintain a fork of javafx-media? > > Ideally, if i did end up needing a fork, i was thinking it would make sense > to split gstreamer-lite out of javafx-media into it's own project so I > could easily swap in a full gstreamer dependency with 3rd project for the > additional media types. > > Background: ideally looking to pull in udpsource and some additional > pipeline plugins (GPU decoding and some subtitle related plugins). > > Thoughts? > > -- > Curtis Ruck From curtis.ruck at gmail.com Wed May 15 00:04:06 2019 From: curtis.ruck at gmail.com (Curtis Ruck) Date: Tue, 14 May 2019 20:04:06 -0400 Subject: GStreamer In-Reply-To: <4f92da15-0fd4-cea9-a609-c1053601a48b@oracle.com> References: <4f92da15-0fd4-cea9-a609-c1053601a48b@oracle.com> Message-ID: Why is splitting gstreamer-lite out not on the table, curiosity? It feels a little silly to end up with two gstreamer libraries getting used by a single application. The gstreamer-javafx examples are horrible compared to the existing javafx-media API. On Tue, May 14, 2019, 19:55 Kevin Rushforth wrote: > We don't currently plan to add support for pluggable codecs, but that > might be something that the community could do, although it would be a > large effort. As for splitting gstreamer-lite out of javafx.media, we > are not likely to consider that. > > -- Kevin > > > On 5/13/2019 11:30 AM, Curtis Ruck wrote: > > I'm investigating a new application that would need tighter integration > > with gstreamer. Is there a way to add additional gstreamer plugins and > > media types without having to maintain a fork of javafx-media? > > > > Ideally, if i did end up needing a fork, i was thinking it would make > sense > > to split gstreamer-lite out of javafx-media into it's own project so I > > could easily swap in a full gstreamer dependency with 3rd project for the > > additional media types. > > > > Background: ideally looking to pull in udpsource and some additional > > pipeline plugins (GPU decoding and some subtitle related plugins). > > > > Thoughts? > > > > -- > > Curtis Ruck > > From kevin.rushforth at oracle.com Wed May 15 00:14:03 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 May 2019 17:14:03 -0700 Subject: GStreamer In-Reply-To: References: <4f92da15-0fd4-cea9-a609-c1053601a48b@oracle.com> Message-ID: <269920e0-84a7-aec9-dba4-02a586602c2b@oracle.com> When you say "gstreamer-javafx" I don't know quite what you mean. The gstreamer-lite library is an internal component of JavaFX and it not something meant to be used by itself. Refactoring the native code in the javafx.media module just so it could be used independently from JavaFX doesn't seem like something that would benefit JavaFX or make it easier to maintain. Rather it could create defacto interfaces that could easily break when we upgrade gstreamer (which we do from time to time to keep up with bug fixes, etc). It's the same reason we don't support accessing Prism or Glass directly. -- Kevin On 5/14/2019 5:04 PM, Curtis Ruck wrote: > Why is splitting gstreamer-lite out not on the table, curiosity? > > It feels a little silly to end up with two gstreamer libraries getting > used by a single application.? The gstreamer-javafx examples are > horrible compared to the existing javafx-media API. > > > > On Tue, May 14, 2019, 19:55 Kevin Rushforth > > wrote: > > We don't currently plan to add support for pluggable codecs, but that > might be something that the community could do, although it would > be a > large effort. As for splitting gstreamer-lite out of javafx.media, we > are not likely to consider that. > > -- Kevin > > > On 5/13/2019 11:30 AM, Curtis Ruck wrote: > > I'm investigating a new application that would need tighter > integration > > with gstreamer.? Is there a way to add additional gstreamer > plugins and > > media types without having to maintain a fork of javafx-media? > > > > Ideally, if i did end up needing a fork, i was thinking it would > make sense > > to split gstreamer-lite out of javafx-media into it's own > project so I > > could easily swap in a full gstreamer dependency with 3rd > project for the > > additional media types. > > > > Background: ideally looking to pull in udpsource and some additional > > pipeline plugins (GPU decoding and some subtitle related plugins). > > > > Thoughts? > > > > -- > > Curtis Ruck > From curtis.ruck at gmail.com Wed May 15 00:27:51 2019 From: curtis.ruck at gmail.com (Curtis Ruck) Date: Tue, 14 May 2019 20:27:51 -0400 Subject: GStreamer In-Reply-To: <269920e0-84a7-aec9-dba4-02a586602c2b@oracle.com> References: <4f92da15-0fd4-cea9-a609-c1053601a48b@oracle.com> <269920e0-84a7-aec9-dba4-02a586602c2b@oracle.com> Message-ID: Gstreamer-javafx examples: https://github.com/gstreamer-java/gst1-javafx-examples I admire how javafx is wrapping gstreamer compared to the above example. I'd like to expand the support for more Media types and some method to access alternative stream data like closed captioning. I don't want to reinvent the wheel, I just prefer javafx as a modern, portable framework over alternatives. Java has always had poor compatibility with media frameworks in the past, I look at the ideal way for me to accomplish my goals above as easily as possible (if I we're King for a little bit) would be to create a bolt-on javafx-media-extras library that pulled in additional gstreamer plugins. I definitely don't want to break downstream interfaces or expose additional non-public APIs, I just want graceful API expansion that allows javafx to compete against just about every other UI toolkit. On Tue, May 14, 2019, 20:14 Kevin Rushforth wrote: > When you say "gstreamer-javafx" I don't know quite what you mean. The > gstreamer-lite library is an internal component of JavaFX and it not > something meant to be used by itself. Refactoring the native code in the > javafx.media module just so it could be used independently from JavaFX > doesn't seem like something that would benefit JavaFX or make it easier to > maintain. Rather it could create defacto interfaces that could easily break > when we upgrade gstreamer (which we do from time to time to keep up with > bug fixes, etc). It's the same reason we don't support accessing Prism or > Glass directly. > > -- Kevin > > > On 5/14/2019 5:04 PM, Curtis Ruck wrote: > > Why is splitting gstreamer-lite out not on the table, curiosity? > > It feels a little silly to end up with two gstreamer libraries getting > used by a single application. The gstreamer-javafx examples are horrible > compared to the existing javafx-media API. > > > > On Tue, May 14, 2019, 19:55 Kevin Rushforth > wrote: > >> We don't currently plan to add support for pluggable codecs, but that >> might be something that the community could do, although it would be a >> large effort. As for splitting gstreamer-lite out of javafx.media, we >> are not likely to consider that. >> >> -- Kevin >> >> >> On 5/13/2019 11:30 AM, Curtis Ruck wrote: >> > I'm investigating a new application that would need tighter integration >> > with gstreamer. Is there a way to add additional gstreamer plugins and >> > media types without having to maintain a fork of javafx-media? >> > >> > Ideally, if i did end up needing a fork, i was thinking it would make >> sense >> > to split gstreamer-lite out of javafx-media into it's own project so I >> > could easily swap in a full gstreamer dependency with 3rd project for >> the >> > additional media types. >> > >> > Background: ideally looking to pull in udpsource and some additional >> > pipeline plugins (GPU decoding and some subtitle related plugins). >> > >> > Thoughts? >> > >> > -- >> > Curtis Ruck >> >> > From thiago.sayao at clamed.com.br Wed May 15 01:38:34 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Wed, 15 May 2019 01:38:34 +0000 Subject: Findings on JDK-8211302 In-Reply-To: References: > , , , Message-ID: Fix in progress: https://github.com/tsayao/openjdk-jfx/pull/5 ________________________________ De: openjfx-dev em nome de Thiago Milczarek Sayao Enviado: ter?a-feira, 14 de maio de 2019 13:25 Para: openjfx-dev at openjdk.java.net Assunto: RE: Findings on JDK-8211302 Found the problem! Managed to get it partially working, will do a proper fix when I get time. The problem lies on glass_general.cpp. To properly get the device and keep receiving mouse move events (required while dragging) gdk_event_get_device(event) must be used. For that, GdkEvent must be in the function arguments. Partially fixed: void glass_gdk_master_pointer_grab(GdkEvent *event, GdkWindow *window, GdkCursor *cursor) { if (disableGrab) { gdk_window_set_cursor(window, cursor); return; } #ifdef GLASS_GTK3 gdk_device_grab(gdk_event_get_device(event), window, GDK_OWNERSHIP_NONE, FALSE, GDK_ALL_EVENTS_MASK, cursor, GDK_CURRENT_TIME); #else gdk_pointer_grab(window, FALSE, (GdkEventMask) (GDK_POINTER_MOTION_MASK | GDK_BUTTON_MOTION_MASK | GDK_BUTTON1_MOTION_MASK | GDK_BUTTON2_MOTION_MASK | GDK_BUTTON3_MOTION_MASK | GDK_BUTTON_RELEASE_MASK), NULL, cursor, GDK_CURRENT_TIME); #endif } Original: void glass_gdk_master_pointer_grab(GdkWindow *window, GdkCursor *cursor) { if (disableGrab) { gdk_window_set_cursor(window, cursor); return; } #ifdef GLASS_GTK3 gdk_device_grab(gdk_device_manager_get_client_pointer( gdk_display_get_device_manager( gdk_display_get_default())), window, GDK_OWNERSHIP_NONE, FALSE, GDK_ALL_EVENTS_MASK, cursor, GDK_CURRENT_TIME); #else gdk_pointer_grab(window, FALSE, (GdkEventMask) (GDK_POINTER_MOTION_MASK | GDK_BUTTON_MOTION_MASK | GDK_BUTTON1_MOTION_MASK | GDK_BUTTON2_MOTION_MASK | GDK_BUTTON3_MOTION_MASK | GDK_BUTTON_RELEASE_MASK), NULL, cursor, GDK_CURRENT_TIME); #endif } ________________________________ De: openjfx-dev em nome de Thiago Milczarek Sayao Enviado: segunda-feira, 13 de maio de 2019 22:28 Para: Pankaj Bansal; openjfx-dev at openjdk.java.net Assunto: RE: Findings on JDK-8211302 Did further investigation... I think the problem lies on Gdk mouse motion events not being fired. On gdk2 the GDK_DRAG_STATUS and GDK_MOTION_NOTIFY events fires many times, including when the drag operation leaves the root window. On gdk3 it fires a few times and does not keep firing when the cursor leaves the root window. It's on GlassApplication.cpp -> around line 419 static void process_events(GdkEvent* event, gpointer data) on gdk2 this keeps firing: if (is_in_drag()) { process_dnd_source(window, event); } on gdk3 it does not. Cheers. ________________________________ De: Pankaj Bansal Enviado: segunda-feira, 13 de maio de 2019 10:59 Para: Thiago Milczarek Sayao; openjfx-dev at openjdk.java.net Assunto: RE: Findings on JDK-8211302 I think problem starts even before this as process_dnd_source_mouse_release is called when we release the mouse after drag and drop. But there we are not even able to initiate the dnd. If gdk_drag_context_get_selected_action(event->context) returning ZERO was the main issue, we should be able to start the drag and drop successfully. What do you think? -Pankaj -----Original Message----- From: Thiago Milczarek Sayao [mailto:thiago.sayao at clamed.com.br] Sent: Monday, May 13, 2019 7:17 PM To: openjfx-dev at openjdk.java.net Subject: RE: Findings on JDK-8211302 It does not work because the problem happens before. But I suspect when the gdk_drag_context_get_selected_action(event->context) returning ZERO problem is fixed, the need of gdk_drag_drop_done() will be the problem. Cheers. ________________________________ De: Pankaj Bansal Enviado: segunda-feira, 13 de maio de 2019 10:38 Para: Thiago Milczarek Sayao; openjfx-dev at openjdk.java.net Assunto: RE: Findings on JDK-8211302 Hello Thiago, This solution was proposed by one of the engineers in Oracle sometime back and we have tested it. This does not seem to solve the issue. If you wish to try this, please take the patch [1], which is attached in the bug JDK-8211302. This patch neatly defines the function depending upon the gtk version. You can test this patch and let us know if you could make this work. [1] https://bugs.openjdk.java.net/secure/attachment/82098/8211302-drag-drop-done.patch -Pankaj -----Original Message----- From: Thiago Milczarek Sayao [mailto:thiago.sayao at clamed.com.br] Sent: Monday, May 13, 2019 6:59 PM To: openjfx-dev at openjdk.java.net Subject: Findings on JDK-8211302 Hello, I have been looking into JDK-8211302. https://bugs.openjdk.java.net/browse/JDK-8211302 Did not find a solution, but the problem is because gdk_drag_context_get_selected_action(event->context) is returning ZERO. That's also why the cursor does not update on the drop location. Subsequent events do not get fired to complete the drop, because it falls on the abort code below: static void process_dnd_source_mouse_release(GdkWindow *window, GdkEventButton *event) { (void)window; (void)event; glass_gdk_master_pointer_ungrab(); if (gdk_drag_context_get_selected_action(get_drag_context())) { gdk_drag_drop(get_drag_context(), GDK_CURRENT_TIME); } else { gdk_drag_abort(get_drag_context(), GDK_CURRENT_TIME); /* let the gdk_drag_abort messages handled before finish */ gdk_threads_add_idle((GSourceFunc) dnd_finish_callback, NULL); } } I also suspect this will be needed, and it was introduced in GDK 3.20: gdk_drag_drop_done(get_drag_context(), TRUE) One solution is to check the version on build, other is to bundle the GTK lib (which makes it more safe to GDK changes). Cheers. From thiago.sayao at clamed.com.br Thu May 16 11:10:28 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Thu, 16 May 2019 11:10:28 +0000 Subject: RFR: JDK-8211302: DND does not work on GTK3 Message-ID: Please, review the following: https://github.com/javafxports/openjdk-jfx/pull/473 https://bugs.openjdk.java.net/browse/JDK-8211302 From arunprasad.rajkumar at oracle.com Thu May 16 14:26:35 2019 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Thu, 16 May 2019 19:56:35 +0530 Subject: [RFR][openjfx13] JDK-8222788: javafx.web build fails on XCode 10.2 Message-ID: <016D44D1-07BD-4F66-B721-C2AE0DC1183B@oracle.com> Hi Kevin, Johan, Please review the following PR. It is just a cherry-pick from upstream WebKit repo to resolve build failure when using Xcode 10.2. https://github.com/javafxports/openjdk-jfx/pull/474 https://bugs.openjdk.java.net/browse/JDK-8222788 Thanks, Arun From Dell.Green at ideaworks.co.uk Fri May 17 08:29:52 2019 From: Dell.Green at ideaworks.co.uk (Dell Green) Date: Fri, 17 May 2019 08:29:52 +0000 Subject: JavaFx12 Armhf 50% cpu usage Message-ID: Hi Guys, I don't know if anyone has any ideas where to start with troubleshooting this one, but currently we have an embedded product running oracle java 8 with javafx. We are currently in the process of testing openjdk12+javaFx12. Everything has been running fine, however we have just noticed that when idle the cpu usage on the target device is 50% when running the hello world Javafx application from Netbeans. In our previous device with javaFX8 when idle the cpu usage is 0%. There is a lot more investigation to be done our end yet to try and narrow the issue and profile it to pinpoint the issue, but I was wondering if anyone else was seeing this on armhf, or have any ideas would could be the issue? I can see in the java bugs database that in the past there have been the odd similar issue with high constant cpu usage which got resolved in the past, however the helloworld app only has a hello world Button with eventhandler on the stage so not much going on there, which make we think the problem lies lower down in the rendering. I am getting hardware acceleration according to the prism.verbose output so cpu shouldn't be being used for rendering any thoughts greatly appreciated :) From swpalmer at gmail.com Sun May 19 16:36:59 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 19 May 2019 12:36:59 -0400 Subject: GStreamer In-Reply-To: References: <4f92da15-0fd4-cea9-a609-c1053601a48b@oracle.com> <269920e0-84a7-aec9-dba4-02a586602c2b@oracle.com> Message-ID: <4141556A-DF08-4A91-B60A-6AD164FB5074@gmail.com> It?s been 11 years? https://bugs.openjdk.java.net/browse/JDK-8091063 The gstreamer integration should have been a pluggable module into the media framework from the beginning. I would love to see that corrected. Refactoring towards a more usable media framework that has the necessary hooks to make it more than a very basic player with limited codec support gets a big plus one from me. I only wish I had the time to help more with actual code. Regards, Scott > On May 14, 2019, at 8:27 PM, Curtis Ruck wrote: > > Gstreamer-javafx examples: > https://github.com/gstreamer-java/gst1-javafx-examples > > I admire how javafx is wrapping gstreamer compared to the above example. > I'd like to expand the support for more Media types and some method to > access alternative stream data like closed captioning. I don't want to > reinvent the wheel, I just prefer javafx as a modern, portable framework > over alternatives. Java has always had poor compatibility with media > frameworks in the past, > > I look at the ideal way for me to accomplish my goals above as easily as > possible (if I we're King for a little bit) would be to create a bolt-on > javafx-media-extras library that pulled in additional gstreamer plugins. I > definitely don't want to break downstream interfaces or expose additional > non-public APIs, I just want graceful API expansion that allows javafx to > compete against just about every other UI toolkit. > > On Tue, May 14, 2019, 20:14 Kevin Rushforth > > wrote: > >> When you say "gstreamer-javafx" I don't know quite what you mean. The >> gstreamer-lite library is an internal component of JavaFX and it not >> something meant to be used by itself. Refactoring the native code in the >> javafx.media module just so it could be used independently from JavaFX >> doesn't seem like something that would benefit JavaFX or make it easier to >> maintain. Rather it could create defacto interfaces that could easily break >> when we upgrade gstreamer (which we do from time to time to keep up with >> bug fixes, etc). It's the same reason we don't support accessing Prism or >> Glass directly. >> >> -- Kevin >> >> >> On 5/14/2019 5:04 PM, Curtis Ruck wrote: >> >> Why is splitting gstreamer-lite out not on the table, curiosity? >> >> It feels a little silly to end up with two gstreamer libraries getting >> used by a single application. The gstreamer-javafx examples are horrible >> compared to the existing javafx-media API. >> >> >> >> On Tue, May 14, 2019, 19:55 Kevin Rushforth >> wrote: >> >>> We don't currently plan to add support for pluggable codecs, but that >>> might be something that the community could do, although it would be a >>> large effort. As for splitting gstreamer-lite out of javafx.media, we >>> are not likely to consider that. >>> >>> -- Kevin >>> >>> >>> On 5/13/2019 11:30 AM, Curtis Ruck wrote: >>>> I'm investigating a new application that would need tighter integration >>>> with gstreamer. Is there a way to add additional gstreamer plugins and >>>> media types without having to maintain a fork of javafx-media? >>>> >>>> Ideally, if i did end up needing a fork, i was thinking it would make >>> sense >>>> to split gstreamer-lite out of javafx-media into it's own project so I >>>> could easily swap in a full gstreamer dependency with 3rd project for >>> the >>>> additional media types. >>>> >>>> Background: ideally looking to pull in udpsource and some additional >>>> pipeline plugins (GPU decoding and some subtitle related plugins). >>>> >>>> Thoughts? >>>> >>>> -- >>>> Curtis Ruck From arunprasad.rajkumar at oracle.com Tue May 21 17:26:05 2019 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 21 May 2019 22:56:05 +0530 Subject: [RFR] [openjfx13] JDK-8224016: Intermittent test failure in SVGTest on Linux Message-ID: <8E223AA5-D4F5-4296-BBBE-7A706429AADA@oracle.com> Hi Kevin, Please review the following PR which fixes a test bug, https://github.com/javafxports/openjdk-jfx/pull/476 https://bugs.openjdk.java.net/browse/JDK-8224016 Thanks, Arun From ambarish.rapte at oracle.com Wed May 22 18:01:02 2019 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Wed, 22 May 2019 18:01:02 +0000 (UTC) Subject: [13] RFR : JDK-8213572 : InitialSizeTest::testInitialSize fails on Windows 10 1803 with 125% Hi-DPI Message-ID: <8961c6f7-98f9-40e1-9d50-8dd78623db3f@default> Hi All, Please take a look at this small fix, Webrev: http://cr.openjdk.java.net/~arapte/fx/8213572/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8213572 Regards, Ambarish From ambarish.rapte at oracle.com Wed May 22 18:06:16 2019 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Wed, 22 May 2019 18:06:16 +0000 (UTC) Subject: [13] RFR : JDK-8222183 : Remove commented out tests from javafx.base Message-ID: <4d5c783d-4e6c-4290-afe7-1917a9cc06a1@default> Hi, Please review this test cleanup change, Webrev: http://cr.openjdk.java.net/~arapte/fx/8222183/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8222183 Regards, Ambarish From anton.tarasov at jetbrains.com Thu May 23 15:38:06 2019 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Thu, 23 May 2019 18:38:06 +0300 Subject: oauth2 is broken Message-ID: <68aa89b7-0dac-a881-79ec-9c0ae634daa0@jetbrains.com> Hello, We've faced a problem with broken OAuth 2.0 in WebView. Started to appear since at least 8u202 (worked in 8u152) and is still broken in JavaFX 12. Simple reproducer is below. It should display a login page but displays nothing instead: public class Main extends Application { ??? @Override ??? public void start(Stage primaryStage) { ??????? WebView view = new WebView(); view.getEngine().load("https://login.microsoftonline.com/common/oauth2/authorize?resource=foo&client_id=bar&response_type=code&redirect_uri=https%3A//localhost"); ??????? primaryStage.setScene(new Scene(view, 800, 600)); ??????? primaryStage.show(); ??? } ??? public static void main(String[] args) { ??????? launch(args); ??? } } The problem originally came from MS User Agent lib (https://github.com/microsoft/oauth2-useragent) which uses JFX WebView to implement OAuth. The code below also shows nothing: import com.microsoft.alm.auth.oauth.OAuth2Authenticator; public class Main { ??? public static void main(String[] args) { ??????? OAuth2Authenticator build = new OAuth2Authenticator.OAuth2AuthenticatorBuilder() ??????????????? .withClientId("bar") .manage(OAuth2Authenticator.MANAGEMENT_CORE_RESOURCE) ??????????????? .redirectTo("http://localhost") ??????????????? .build(); ??????? build.getOAuth2TokenPair(); ??? } } Can you please comment, is it a known issue? Are there any solutions? With regards, Anton. From mblaesing at doppel-helix.eu Thu May 23 19:11:51 2019 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Thu, 23 May 2019 21:11:51 +0200 Subject: RFR: JDK-8224636: CSS "pointer-events" property "stroke" is not respected for SVG renderings Message-ID: <45def2260299a6c0485e7bd8c0ad7b2836b66115.camel@doppel-helix.eu> Please review the following fix to enable correct handling of mouse event when the CSS "pointer-events" property is set to "stroke". https://bugs.openjdk.java.net/browse/JDK-8224636 https://github.com/javafxports/openjdk-jfx/pull/479 Thank you Matthias From kgorcz at interia.pl Thu May 23 19:13:44 2019 From: kgorcz at interia.pl (Krzysztof Gorczowski) Date: Thu, 23 May 2019 21:13:44 +0200 Subject: Ideas for future development Message-ID: <7f42ad57-79b0-cd9e-d1ab-ee143d6a69d6@interia.pl> Hello everybody, Couple of word at the very beginning. I was interested in Javafx since 2011, however by more than six years I implemented software commercially in .NET.? I did a couple of things in Javafx in my leisure time and my experience I would like to share with all of you. I have some ideas for future development of javafx which in my opinion could push this library forward and on which I personaly want to take apart of. 1.The first idea which I have is implementation of some sort of control template. This control template could be use in every containers type of controls like ListView or TableView. It could be define directly in container control view but also in other file. SelectorTemplate will be a class which will select particular control. There will be also some kind of default Selector which will map particular control with element in collection define in controller.? 2. Implementation of real kind of tools which will supports modular JavaFX development. I was studying a lot that what was done by Adam Bien a couple years ago. It was really good direction in case of huge desktop enterprise client apps. I think there are also important to implement some kind of support tools like this for Prism in wpf. Choose of DI Container should be done in the moment of generation of new module. Technical details I will describe letter if there will be someone who want to support me :) Regards Krzysztof Gorczowski? From kevin.rushforth at oracle.com Thu May 23 20:24:45 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 23 May 2019 13:24:45 -0700 Subject: oauth2 is broken In-Reply-To: <68aa89b7-0dac-a881-79ec-9c0ae634daa0@jetbrains.com> References: <68aa89b7-0dac-a881-79ec-9c0ae634daa0@jetbrains.com> Message-ID: <248e2d79-9cd6-63a1-d3d3-5b808d406ebd@oracle.com> It runs fine for me on Windows using a local build of jfx-dev. This is likely the same issue as https://bugs.openjdk.java.net/browse/JDK-8219917 which is fixed in JavaFX 13 EA. -- Kevin On 5/23/2019 8:38 AM, Anton Tarasov wrote: > Hello, > > We've faced a problem with broken OAuth 2.0 in WebView. Started to > appear since at least 8u202 (worked in 8u152) and is still broken in > JavaFX 12. > > Simple reproducer is below. It should display a login page but > displays nothing instead: > > public class Main extends Application { > ??? @Override > ??? public void start(Stage primaryStage) { > ??????? WebView view = new WebView(); > view.getEngine().load("https://login.microsoftonline.com/common/oauth2/authorize?resource=foo&client_id=bar&response_type=code&redirect_uri=https%3A//localhost"); > > ??????? primaryStage.setScene(new Scene(view, 800, 600)); > ??????? primaryStage.show(); > ??? } > ??? public static void main(String[] args) { > ??????? launch(args); > ??? } > } > > The problem originally came from MS User Agent lib > (https://github.com/microsoft/oauth2-useragent) which uses JFX WebView > to implement OAuth. The code below also shows nothing: > > import com.microsoft.alm.auth.oauth.OAuth2Authenticator; > > public class Main { > ??? public static void main(String[] args) { > ??????? OAuth2Authenticator build = new > OAuth2Authenticator.OAuth2AuthenticatorBuilder() > ??????????????? .withClientId("bar") > .manage(OAuth2Authenticator.MANAGEMENT_CORE_RESOURCE) > ??????????????? .redirectTo("http://localhost") > ??????????????? .build(); > ??????? build.getOAuth2TokenPair(); > ??? } > } > > Can you please comment, is it a known issue? Are there any solutions? > > With regards, > Anton. > > From thiago.sayao at clamed.com.br Thu May 23 20:26:34 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Thu, 23 May 2019 20:26:34 +0000 Subject: Ideas for future development In-Reply-To: <7f42ad57-79b0-cd9e-d1ab-ee143d6a69d6@interia.pl> References: <7f42ad57-79b0-cd9e-d1ab-ee143d6a69d6@interia.pl> Message-ID: For 2 I use spring boot (together with javafx). On the "business logic" module I use other technologies such as JPA, Spring Boot JPA, ... ________________________________ De: openjfx-dev em nome de Krzysztof Gorczowski Enviado: quinta-feira, 23 de maio de 2019 16:13 Para: openjfx-dev at openjdk.java.net Assunto: Ideas for future development Hello everybody, Couple of word at the very beginning. I was interested in Javafx since 2011, however by more than six years I implemented software commercially in .NET. I did a couple of things in Javafx in my leisure time and my experience I would like to share with all of you. I have some ideas for future development of javafx which in my opinion could push this library forward and on which I personaly want to take apart of. 1.The first idea which I have is implementation of some sort of control template. This control template could be use in every containers type of controls like ListView or TableView. It could be define directly in container control view but also in other file. SelectorTemplate will be a class which will select particular control. There will be also some kind of default Selector which will map particular control with element in collection define in controller. 2. Implementation of real kind of tools which will supports modular JavaFX development. I was studying a lot that what was done by Adam Bien a couple years ago. It was really good direction in case of huge desktop enterprise client apps. I think there are also important to implement some kind of support tools like this for Prism in wpf. Choose of DI Container should be done in the moment of generation of new module. Technical details I will describe letter if there will be someone who want to support me :) Regards Krzysztof Gorczowski From kgorcz at interia.pl Fri May 24 04:34:10 2019 From: kgorcz at interia.pl (kgorcz at interia.pl) Date: Fri, 24 May 2019 06:34:10 +0200 Subject: ODP: Ideas for future development Message-ID: And spring DIC should be one of couple which user of this tool could use. I think this can be made as CLI. Next step will be support for IDE------ Oryginalna wiadomo??------Od: Thiago Milczarek SayaoData: Czw., 23 maj 2019 22:26Do: openjfx-dev at openjdk.java.net;DW: Temat:RE: Ideas for future developmentFor 2 I use spring boot (together with javafx). On the "business logic" module I use other technologies such as JPA, Spring Boot JPA, ... ________________________________ De: openjfx-dev em nome de Krzysztof Gorczowski Enviado: quinta-feira, 23 de maio de 2019 16:13 Para: openjfx-dev at openjdk.java.net Assunto: Ideas for future development Hello everybody, Couple of word at the very beginning. I was interested in Javafx since 2011, however by more than six years I implemented software commercially in .NET. I did a couple of things in Javafx in my leisure time and my experience I would like to share with all of you. I have some ideas for future development of javafx which in my opinion could push this library forward and on which I personaly want to take apart of. 1.The first idea which I have is implementation of some sort of control template. This control template could be use in every containers type of controls like ListView or TableView. It could be define directly in container control view but also in other file. SelectorTemplate will be a class which will select particular control. There will be also some kind of default Selector which will map particular control with element in collection define in controller. 2. Implementation of real kind of tools which will supports modular JavaFX development. I was studying a lot that what was done by Adam Bien a couple years ago. It was really good direction in case of huge desktop enterprise client apps. I think there are also important to implement some kind of support tools like this for Prism in wpf. Choose of DI Container should be done in the moment of generation of new module. Technical details I will describe letter if there will be someone who want to support me :) Regards Krzysztof Gorczowski From anton.tarasov at jetbrains.com Fri May 24 14:57:43 2019 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Fri, 24 May 2019 17:57:43 +0300 Subject: oauth2 is broken In-Reply-To: <248e2d79-9cd6-63a1-d3d3-5b808d406ebd@oracle.com> References: <68aa89b7-0dac-a881-79ec-9c0ae634daa0@jetbrains.com> <248e2d79-9cd6-63a1-d3d3-5b808d406ebd@oracle.com> Message-ID: I confirm it's fixed in JavaFX 13. Thank you! Anton. On 5/23/2019 11:24 PM, Kevin Rushforth wrote: > It runs fine for me on Windows using a local build of jfx-dev. This is > likely the same issue as > https://bugs.openjdk.java.net/browse/JDK-8219917 which is fixed in > JavaFX 13 EA. > > -- Kevin > > > On 5/23/2019 8:38 AM, Anton Tarasov wrote: >> Hello, >> >> We've faced a problem with broken OAuth 2.0 in WebView. Started to >> appear since at least 8u202 (worked in 8u152) and is still broken in >> JavaFX 12. >> >> Simple reproducer is below. It should display a login page but >> displays nothing instead: >> >> public class Main extends Application { >> ??? @Override >> ??? public void start(Stage primaryStage) { >> ??????? WebView view = new WebView(); >> view.getEngine().load("https://login.microsoftonline.com/common/oauth2/authorize?resource=foo&client_id=bar&response_type=code&redirect_uri=https%3A//localhost"); >> >> ??????? primaryStage.setScene(new Scene(view, 800, 600)); >> ??????? primaryStage.show(); >> ??? } >> ??? public static void main(String[] args) { >> ??????? launch(args); >> ??? } >> } >> >> The problem originally came from MS User Agent lib >> (https://github.com/microsoft/oauth2-useragent) which uses JFX >> WebView to implement OAuth. The code below also shows nothing: >> >> import com.microsoft.alm.auth.oauth.OAuth2Authenticator; >> >> public class Main { >> ??? public static void main(String[] args) { >> ??????? OAuth2Authenticator build = new >> OAuth2Authenticator.OAuth2AuthenticatorBuilder() >> ??????????????? .withClientId("bar") >> .manage(OAuth2Authenticator.MANAGEMENT_CORE_RESOURCE) >> ??????????????? .redirectTo("http://localhost") >> ??????????????? .build(); >> ??????? build.getOAuth2TokenPair(); >> ??? } >> } >> >> Can you please comment, is it a known issue? Are there any solutions? >> >> With regards, >> Anton. >> >> > From kevin.rushforth at oracle.com Fri May 24 14:58:59 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 24 May 2019 07:58:59 -0700 Subject: oauth2 is broken In-Reply-To: References: <68aa89b7-0dac-a881-79ec-9c0ae634daa0@jetbrains.com> <248e2d79-9cd6-63a1-d3d3-5b808d406ebd@oracle.com> Message-ID: Good to hear. Thanks for the confirmation. -- Kevin On 5/24/2019 7:57 AM, Anton Tarasov wrote: > I confirm it's fixed in JavaFX 13. Thank you! > > Anton. > > On 5/23/2019 11:24 PM, Kevin Rushforth wrote: >> It runs fine for me on Windows using a local build of jfx-dev. This >> is likely the same issue as >> https://bugs.openjdk.java.net/browse/JDK-8219917 which is fixed in >> JavaFX 13 EA. >> >> -- Kevin >> >> >> On 5/23/2019 8:38 AM, Anton Tarasov wrote: >>> Hello, >>> >>> We've faced a problem with broken OAuth 2.0 in WebView. Started to >>> appear since at least 8u202 (worked in 8u152) and is still broken in >>> JavaFX 12. >>> >>> Simple reproducer is below. It should display a login page but >>> displays nothing instead: >>> >>> public class Main extends Application { >>> ??? @Override >>> ??? public void start(Stage primaryStage) { >>> ??????? WebView view = new WebView(); >>> view.getEngine().load("https://login.microsoftonline.com/common/oauth2/authorize?resource=foo&client_id=bar&response_type=code&redirect_uri=https%3A//localhost"); >>> >>> ??????? primaryStage.setScene(new Scene(view, 800, 600)); >>> ??????? primaryStage.show(); >>> ??? } >>> ??? public static void main(String[] args) { >>> ??????? launch(args); >>> ??? } >>> } >>> >>> The problem originally came from MS User Agent lib >>> (https://github.com/microsoft/oauth2-useragent) which uses JFX >>> WebView to implement OAuth. The code below also shows nothing: >>> >>> import com.microsoft.alm.auth.oauth.OAuth2Authenticator; >>> >>> public class Main { >>> ??? public static void main(String[] args) { >>> ??????? OAuth2Authenticator build = new >>> OAuth2Authenticator.OAuth2AuthenticatorBuilder() >>> ??????????????? .withClientId("bar") >>> .manage(OAuth2Authenticator.MANAGEMENT_CORE_RESOURCE) >>> ??????????????? .redirectTo("http://localhost") >>> ??????????????? .build(); >>> ??????? build.getOAuth2TokenPair(); >>> ??? } >>> } >>> >>> Can you please comment, is it a known issue? Are there any solutions? >>> >>> With regards, >>> Anton. >>> >>> >> From Dell.Green at ideaworks.co.uk Fri May 31 14:29:01 2019 From: Dell.Green at ideaworks.co.uk (Dell Green) Date: Fri, 31 May 2019 14:29:01 +0000 Subject: Can Javafx cursor be disabled? Message-ID: <15370396-0384-8dc2-1773-55443331b859@ideaworks.co.uk> We have a touch/rotary device that doesn't use any mouse/cursor input. Is there a way to tell javafx to not initialize a cursor (MX6Cursor.java in my case) on startup as we are seeing /dev/fb1 being unblanked and a grey cursor artifact drawn onto the /dev/fb1, before any user specific javafx code is created. I have looked through the source code and there doesn't seem to be a configurable property to control this. I can remove /dev/fb1 and javafx prints an error/stack-trace but appears to work as normal, however I'm not sure what ongoing impact this has on javafx. any thoughts? From thiago.sayao at clamed.com.br Fri May 31 14:45:11 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Fri, 31 May 2019 14:45:11 +0000 Subject: Can Javafx cursor be disabled? In-Reply-To: <15370396-0384-8dc2-1773-55443331b859@ideaworks.co.uk> References: <15370396-0384-8dc2-1773-55443331b859@ideaworks.co.uk> Message-ID: If you are using X.org, the cursor is controlled by X, so I would look for a X configuration to disable cursor. https://unix.stackexchange.com/questions/346903/can-i-remove-the-mouse-pointer-entirely-from-x ________________________________ De: openjfx-dev em nome de Dell Green Enviado: sexta-feira, 31 de maio de 2019 11:29 Para: openjfx-dev at openjdk.java.net Assunto: Can Javafx cursor be disabled? We have a touch/rotary device that doesn't use any mouse/cursor input. Is there a way to tell javafx to not initialize a cursor (MX6Cursor.java in my case) on startup as we are seeing /dev/fb1 being unblanked and a grey cursor artifact drawn onto the /dev/fb1, before any user specific javafx code is created. I have looked through the source code and there doesn't seem to be a configurable property to control this. I can remove /dev/fb1 and javafx prints an error/stack-trace but appears to work as normal, however I'm not sure what ongoing impact this has on javafx. any thoughts?