From mike.ennen at gmail.com Fri Jun 1 06:01:19 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Thu, 31 May 2018 23:01:19 -0700 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> Message-ID: Re-familiarizing myself with what javapackager offers, it seems the following JavaFX related features are present: 1.) The conversion of CSS to binary CSS 2.) The ability to specify a preloader 3.) the ability to specify the JavaFX Application class The first one seems like a bit of feature-creep and could be replaced by some other build tool if third party developers really need that feature. They could probably even use something like maven-exec-plugin to manually call such a converter. Let's set this one aside, then. The second and third one are important for correctly launching a JavaFX application. I would think that in order for these to be easily accomplished flags would need to be present in "jpackager" for specifying them (namely, the preloader and Application class). Otherwise jpackager would need to do some "reflection" to try and determine whether or not JavaFX is being used (maybe by checking for its presence on the module path?) and then, if so, get the appropriate preloader and application class. I only mention this because the JEP proposal specifically states "JavaFX-specific features" under "Non-Goals" but this might make things more complicated than they need to be in those two areas I mentioned above. Other then that, this looks good to me and I think having a replacement for javapackager is a good idea. Thanks, Michael Ennen On Thu, May 31, 2018 at 1:56 PM, Kevin Rushforth wrote: > The existing javapackager doesn't really know much about JavaFX as it is, > now that applet and Web Start are gone. I am not aware of anything that > would preclude packaging up a JavaFX application. We will certainly test > the ability to package up a JavaFX application. > > As for the schedule, I agree it isn't ideal, but it's too late for JDK 11. > > -- Kevin > > > > On 5/31/2018 1:25 PM, Michael Paus wrote: > >> Hi, >> >> is it possible to get a clear statement on whether it will be possible to >> package a JavaFX application with the new packager in a similar way as it >> is possible right now with the old packager? The texts are a little bit >> vague there. I just don't know whether it is possible to create a packager >> which does not know anything about the GUI framework which has been used by >> an application. >> >> I would also like to express my concerns about the schedule. The next >> Java release (11) will be an LTS release and that means that there will not >> be any packager for all those people who will have to stick with this >> release for a long time. This is a huge step backward for Java because >> there is then no good deployment technology anymore for a long time. >> >> Michael >> >> Am 31.05.18 um 02:11 schrieb Kevin Rushforth: >> >>> I just sent an email to the core-libs-dev alias [1] proposing a new >>> Packaging Tool as a replacement for javapackager. If you are interested in >>> this JEP, you can follow and participate in the discussion there. >>> >>> -- Kevin >>> >>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-Ma >>> y/053503.html >>> >>> >> > From tom.schindl at bestsolution.at Fri Jun 1 09:01:27 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 1 Jun 2018 11:01:27 +0200 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> Message-ID: <4617b3c8-27da-5707-c070-11422e698f9d@bestsolution.at> On 01.06.18 08:01, Michael Ennen wrote: > Re-familiarizing myself with what javapackager offers, it seems the > following JavaFX related > features are present: > > 1.) The conversion of CSS to binary CSS > 2.) The ability to specify a preloader > 3.) the ability to specify the JavaFX Application class > > The first one seems like a bit of feature-creep and could be replaced by > some other build > tool if third party developers really need that feature. They could > probably even use something > like maven-exec-plugin to manually call such a converter. Let's set this > one aside, then. > > The second and third one are important for correctly launching a JavaFX > application. I would on 2.: What is a preloader good for if you launch a local application? IMHO it only really made sense for Webstart on 3. Why? All you need to do is to provide a main-method and you are good to go. Tom From johan.vos at gluonhq.com Fri Jun 1 09:06:45 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 1 Jun 2018 11:06:45 +0200 Subject: OpenJFX code review policies, etc. In-Reply-To: <39b9b81e-4aab-37ec-6b48-b7fa202446b9@oracle.com> References: <39b9b81e-4aab-37ec-6b48-b7fa202446b9@oracle.com> Message-ID: On Thu, May 31, 2018 at 11:25 PM Kevin Rushforth wrote: > > > On 5/24/2018 9:31 AM, Nir Lisker wrote: > > Thanks for the detailed plan Kevin, > > > > ... > > > > Can you give the guidelines by which a lead reviews / approves one of > > the above? > > Ultimately it will be a judgment call. I can't speak for Johan, but what > I usually do is see whether the proposed feature is a good fit for the > API, doesn't raise any compatibility concerns, is supportable, testable, > etc., and then get to the more detailed review of the spec and API > additions themselves. > I agree. New features should be consistent with existing features, and we have to make sure OpenJFX is not just a bucket of some cool but isolated features. What I would like to add is feasibility. When something is planned, we should have a good feeling that it can and will be done. Expectations and reality should not diverge. Which does not mean we should not be ambitious of course. - Johan From swpalmer at gmail.com Fri Jun 1 15:46:07 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 1 Jun 2018 11:46:07 -0400 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: <4617b3c8-27da-5707-c070-11422e698f9d@bestsolution.at> References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> <4617b3c8-27da-5707-c070-11422e698f9d@bestsolution.at> Message-ID: > On Jun 1, 2018, at 5:01 AM, Tom Schindl wrote: > > On 01.06.18 08:01, Michael Ennen wrote: >> Re-familiarizing myself with what javapackager offers, it seems the >> following JavaFX related >> features are present: >> >> 1.) The conversion of CSS to binary CSS >> 2.) The ability to specify a preloader >> 3.) the ability to specify the JavaFX Application class >> >> The first one seems like a bit of feature-creep and could be replaced by >> some other build >> tool if third party developers really need that feature. They could >> probably even use something >> like maven-exec-plugin to manually call such a converter. Let's set this >> one aside, then. >> >> The second and third one are important for correctly launching a JavaFX >> application. I would > > on 2.: What is a preloader good for if you launch a local application? > IMHO it only really made sense for Webstart > > on 3. Why? All you need to do is to provide a main-method and you are > good to go. +1, I have only used a main method that simply calls launch(args). I never understood why there was a need for special launching of JavaFX apps. At one point I thought of using a preloaded for a splash screen because sometimes I have an application that needs to initialize a lot of plugins, so there is a significant startup time, but it isn?t worth it. The main method launches fast enough. Scott From johan.vos at gluonhq.com Fri Jun 1 17:42:51 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 1 Jun 2018 19:42:51 +0200 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> <4617b3c8-27da-5707-c070-11422e698f9d@bestsolution.at> Message-ID: I'm not saying a preloader is really a requirement, but I know of a few applications that are using it and benefiting from it. The preloader functionality is more than just a splash screen, and I see this valuable for instance when static initializers of classes that are used in the main class may take a lot of time. - Johan On Fri, Jun 1, 2018 at 5:56 PM Scott Palmer wrote: > > > > On Jun 1, 2018, at 5:01 AM, Tom Schindl > wrote: > > > > On 01.06.18 08:01, Michael Ennen wrote: > >> Re-familiarizing myself with what javapackager offers, it seems the > >> following JavaFX related > >> features are present: > >> > >> 1.) The conversion of CSS to binary CSS > >> 2.) The ability to specify a preloader > >> 3.) the ability to specify the JavaFX Application class > >> > >> The first one seems like a bit of feature-creep and could be replaced by > >> some other build > >> tool if third party developers really need that feature. They could > >> probably even use something > >> like maven-exec-plugin to manually call such a converter. Let's set this > >> one aside, then. > >> > >> The second and third one are important for correctly launching a JavaFX > >> application. I would > > > > on 2.: What is a preloader good for if you launch a local application? > > IMHO it only really made sense for Webstart > > > > on 3. Why? All you need to do is to provide a main-method and you are > > good to go. > > +1, I have only used a main method that simply calls launch(args). I > never understood why there was a need for special launching of JavaFX apps. > > At one point I thought of using a preloaded for a splash screen because > sometimes I have an application that needs to initialize a lot of plugins, > so there is a significant startup time, but it isn?t worth it. The main > method launches fast enough. > > > Scott From j.tosovsky at email.cz Fri Jun 1 17:52:01 2018 From: j.tosovsky at email.cz (Jan Tosovsky) Date: Fri, 1 Jun 2018 19:52:01 +0200 Subject: JavaFX app for non-techie users Message-ID: <006001d3f9d1$3f434290$bdc9c7b0$@email.cz> Dear All, I made a small JavaFX app for small non-techie team working on Windows (rewritten from Swing few years ago). Everyone had Java JRE installed so it was enough to distribute small jar file (50 kB), which could be executed on double click. Lucky man. I am quite confused by recent JavaFX announcements about decoupling JavaFX from JDK. It makes my life harder :-) Does it mean every user with JDK11+ (no JRE any more) will have to install additional JavaFX stuff to be able to run my app? Will it be provided as MSI installer for Windows platform? Will download links be available in a same place as standard Oracle Java JDK stuff downloads (ensuring credibility)? Will it have some kind of auto-update mechanism? I am aware of the trend of distributing Java apps as monolith with bundled JDK modules, but not sure it makes sense for small utilities. (I expect the size 50+ MB) Would it be technically possible to provide JavaFX as maven artifacts so I could easily add those JavaFX 'jars' (for single platform) as my app dependencies? I do not need WebView so the final size could still keep reasonable size. Am I missing something? Now I am slightly inclined to switching this app back to Swing to make it as simple as possible to the end-users. Thanks, Jan From johan.vos at gluonhq.com Fri Jun 1 18:11:33 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 1 Jun 2018 20:11:33 +0200 Subject: JavaFX app for non-techie users In-Reply-To: <006001d3f9d1$3f434290$bdc9c7b0$@email.cz> References: <006001d3f9d1$3f434290$bdc9c7b0$@email.cz> Message-ID: Hi Jan, The goal is indeed to provide the JavaFX components as maven artifacts (e.g. see https://github.com/javafxports/openjdk-jfx/issues/52). Would that fix your issue? - Johan On Fri, Jun 1, 2018 at 8:02 PM Jan Tosovsky wrote: > Dear All, > > I made a small JavaFX app for small non-techie team working on Windows > (rewritten from Swing few years ago). Everyone had Java JRE installed so it > was enough to distribute small jar file (50 kB), which could be executed on > double click. Lucky man. > > I am quite confused by recent JavaFX announcements about decoupling JavaFX > from JDK. It makes my life harder :-) > > Does it mean every user with JDK11+ (no JRE any more) will have to install > additional JavaFX stuff to be able to run my app? Will it be provided as > MSI > installer for Windows platform? Will download links be available in a same > place as standard Oracle Java JDK stuff downloads (ensuring credibility)? > Will it have some kind of auto-update mechanism? > > I am aware of the trend of distributing Java apps as monolith with bundled > JDK modules, but not sure it makes sense for small utilities. (I expect the > size 50+ MB) > > Would it be technically possible to provide JavaFX as maven artifacts so I > could easily add those JavaFX 'jars' (for single platform) as my app > dependencies? I do not need WebView so the final size could still keep > reasonable size. > > Am I missing something? > > Now I am slightly inclined to switching this app back to Swing to make it > as > simple as possible to the end-users. > > Thanks, > > Jan > > > > > From j.tosovsky at email.cz Sat Jun 2 17:50:12 2018 From: j.tosovsky at email.cz (Jan Tosovsky) Date: Sat, 2 Jun 2018 19:50:12 +0200 Subject: JavaFX app for non-techie users In-Reply-To: References: <006001d3f9d1$3f434290$bdc9c7b0$@email.cz> Message-ID: <002c01d3fa9a$2cb20c50$861624f0$@email.cz> Hi Johan, thanks for the link. This would fix my issue. I am glad that implementation of this has already started. I would be grateful if such app could be executed even on older Oracle JREs with bundled JavaFX. Jan From: Johan Vos Sent: Friday, June 1, 2018 8:12 PM To: Jan Tosovsky Cc: openjfx-dev at openjdk.java.net Subject: Re: JavaFX app for non-techie users Hi Jan, The goal is indeed to provide the JavaFX components as maven artifacts (e.g. see https://github.com/javafxports/openjdk-jfx/issues/52). Would that fix your issue? - Johan On Fri, Jun 1, 2018 at 8:02 PM Jan Tosovsky > wrote: Dear All, I made a small JavaFX app for small non-techie team working on Windows (rewritten from Swing few years ago). Everyone had Java JRE installed so it was enough to distribute small jar file (50 kB), which could be executed on double click. Lucky man. I am quite confused by recent JavaFX announcements about decoupling JavaFX from JDK. It makes my life harder :-) Does it mean every user with JDK11+ (no JRE any more) will have to install additional JavaFX stuff to be able to run my app? Will it be provided as MSI installer for Windows platform? Will download links be available in a same place as standard Oracle Java JDK stuff downloads (ensuring credibility)? Will it have some kind of auto-update mechanism? I am aware of the trend of distributing Java apps as monolith with bundled JDK modules, but not sure it makes sense for small utilities. (I expect the size 50+ MB) Would it be technically possible to provide JavaFX as maven artifacts so I could easily add those JavaFX 'jars' (for single platform) as my app dependencies? I do not need WebView so the final size could still keep reasonable size. Am I missing something? Now I am slightly inclined to switching this app back to Swing to make it as simple as possible to the end-users. Thanks, Jan From tom.schindl at bestsolution.at Sun Jun 3 07:57:48 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sun, 3 Jun 2018 09:57:48 +0200 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> <4617b3c8-27da-5707-c070-11422e698f9d@bestsolution.at> Message-ID: On 01.06.18 19:42, Johan Vos wrote: > I'm not saying a preloader is really a requirement, but I know of a few > applications that are using it and benefiting from it. > > The preloader functionality is more than just a splash screen, and I see > this valuable for instance when static initializers of classes that are > used in the main class may take a lot of time. Then I'd argue that you can easily refactor your main-class ;-) Tom From mario at datenwort.at Sun Jun 3 08:11:43 2018 From: mario at datenwort.at (Mario Ivankovits) Date: Sun, 3 Jun 2018 08:11:43 +0000 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> <4617b3c8-27da-5707-c070-11422e698f9d@bestsolution.at> Message-ID: <47C37D5F-15D0-4FA8-9A1F-173E832FB50E@datenwort.at> A preloader/splash-screen will/should also hide the JVM startup time. Best regards, Mario > Am 03.06.2018 um 09:57 schrieb Tom Schindl : > > On 01.06.18 19:42, Johan Vos wrote: >> I'm not saying a preloader is really a requirement, but I know of a few >> applications that are using it and benefiting from it. >> >> The preloader functionality is more than just a splash screen, and I see >> this valuable for instance when static initializers of classes that are >> used in the main class may take a lot of time. > > Then I'd argue that you can easily refactor your main-class ;-) > > Tom From tom.schindl at bestsolution.at Sun Jun 3 08:22:31 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sun, 3 Jun 2018 10:22:31 +0200 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: <47C37D5F-15D0-4FA8-9A1F-173E832FB50E@datenwort.at> References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> <4617b3c8-27da-5707-c070-11422e698f9d@bestsolution.at> <47C37D5F-15D0-4FA8-9A1F-173E832FB50E@datenwort.at> Message-ID: That's why I requested that since a long time from the packager because a splash has to be part of the native launcher created. The Eclipse-RCP-Launcher does exactly the right thing: * Show a static image (IIRC they use bmp) * Once the VM and UI-Toolkit is up replace that image with a window (SWT calls it Shell) so that you can go interactive showing videos, a progressbar, ... Tom On 03.06.18 10:11, Mario Ivankovits wrote: > A preloader/splash-screen will/should also hide the JVM startup time. > > Best regards, > Mario > > >> Am 03.06.2018 um 09:57 schrieb Tom Schindl : >> >> On 01.06.18 19:42, Johan Vos wrote: >>> I'm not saying a preloader is really a requirement, but I know of a few >>> applications that are using it and benefiting from it. >>> >>> The preloader functionality is more than just a splash screen, and I see >>> this valuable for instance when static initializers of classes that are >>> used in the main class may take a lot of time. >> >> Then I'd argue that you can easily refactor your main-class ;-) >> >> Tom > From swpalmer at gmail.com Sun Jun 3 23:06:46 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 3 Jun 2018 19:06:46 -0400 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> <4617b3c8-27da-5707-c070-11422e698f9d@bestsolution.at> <47C37D5F-15D0-4FA8-9A1F-173E832FB50E@datenwort.at> Message-ID: Has anyone actually timed how long it takes to get a Java window on screen? I don?t think the delay is long enough to bother with a splash screen these days. Scott > On Jun 3, 2018, at 4:22 AM, Tom Schindl wrote: > > That's why I requested that since a long time from the packager because > a splash has to be part of the native launcher created. > > The Eclipse-RCP-Launcher does exactly the right thing: > * Show a static image (IIRC they use bmp) > * Once the VM and UI-Toolkit is up replace that image with a window (SWT > calls it Shell) so that you can go interactive showing videos, > a progressbar, ... > > Tom > >> On 03.06.18 10:11, Mario Ivankovits wrote: >> A preloader/splash-screen will/should also hide the JVM startup time. >> >> Best regards, >> Mario >> >> >>> Am 03.06.2018 um 09:57 schrieb Tom Schindl : >>> >>> On 01.06.18 19:42, Johan Vos wrote: >>>> I'm not saying a preloader is really a requirement, but I know of a few >>>> applications that are using it and benefiting from it. >>>> >>>> The preloader functionality is more than just a splash screen, and I see >>>> this valuable for instance when static initializers of classes that are >>>> used in the main class may take a lot of time. >>> >>> Then I'd argue that you can easily refactor your main-class ;-) >>> >>> Tom >> From johan.vos at gluonhq.com Mon Jun 4 07:50:17 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 4 Jun 2018 09:50:17 +0200 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> <4617b3c8-27da-5707-c070-11422e698f9d@bestsolution.at> Message-ID: Well yes, that is actually a very important point. While one can do that easily, that does not mean everyone will do it. I typically counter the "JavaFX is slow" bashing with "JavaFX allows you to create high-performance applications, but it also allows you to create very slow ones". It is actually much easier to create an application that starts up slower. In most cases, that can be fixed by refactoring, but at the very least developers should then have a clue on what to refactor. A splash screen is not a generic solution for performance problems, but it can be an easy fix in case much time is spent in methods. - Johan On Sun, Jun 3, 2018 at 10:08 AM Tom Schindl wrote: > On 01.06.18 19:42, Johan Vos wrote: > > I'm not saying a preloader is really a requirement, but I know of a few > > applications that are using it and benefiting from it. > > > > The preloader functionality is more than just a splash screen, and I see > > this valuable for instance when static initializers of classes that are > > used in the main class may take a lot of time. > > Then I'd argue that you can easily refactor your main-class ;-) > > Tom > From tom.schindl at bestsolution.at Mon Jun 4 09:13:37 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 4 Jun 2018 11:13:37 +0200 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> <4617b3c8-27da-5707-c070-11422e698f9d@bestsolution.at> <47C37D5F-15D0-4FA8-9A1F-173E832FB50E@datenwort.at> Message-ID: <5203b303-ce75-8e80-0fb8-c68ebb986e6e@bestsolution.at> A splash screen has to be that instant that it IMHO makes no sense to time how long it takes to get the JVM and JavaFX up and running because it can never be as instant as a splash has to show up. Tom On 04.06.18 01:06, Scott Palmer wrote: > Has anyone actually timed how long it takes to get a Java window on screen? I don?t think the delay is long enough to bother with a splash screen these days. > > Scott > >> On Jun 3, 2018, at 4:22 AM, Tom Schindl wrote: >> >> That's why I requested that since a long time from the packager because >> a splash has to be part of the native launcher created. >> >> The Eclipse-RCP-Launcher does exactly the right thing: >> * Show a static image (IIRC they use bmp) >> * Once the VM and UI-Toolkit is up replace that image with a window (SWT >> calls it Shell) so that you can go interactive showing videos, >> a progressbar, ... >> >> Tom >> >>> On 03.06.18 10:11, Mario Ivankovits wrote: >>> A preloader/splash-screen will/should also hide the JVM startup time. >>> >>> Best regards, >>> Mario >>> >>> >>>> Am 03.06.2018 um 09:57 schrieb Tom Schindl : >>>> >>>> On 01.06.18 19:42, Johan Vos wrote: >>>>> I'm not saying a preloader is really a requirement, but I know of a few >>>>> applications that are using it and benefiting from it. >>>>> >>>>> The preloader functionality is more than just a splash screen, and I see >>>>> this valuable for instance when static initializers of classes that are >>>>> used in the main class may take a lot of time. >>>> >>>> Then I'd argue that you can easily refactor your main-class ;-) >>>> >>>> Tom >>> From swpalmer at gmail.com Mon Jun 4 10:43:03 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 4 Jun 2018 06:43:03 -0400 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: <5203b303-ce75-8e80-0fb8-c68ebb986e6e@bestsolution.at> References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> <4617b3c8-27da-5707-c070-11422e698f9d@bestsolution.at> <47C37D5F-15D0-4FA8-9A1F-173E832FB50E@datenwort.at> <5203b303-ce75-8e80-0fb8-c68ebb986e6e@bestsolution.at> Message-ID: <4E733F52-D007-4CCF-96E5-024BD0174EA7@gmail.com> If a Java window appears in less than half a second there is no point in adding the complexity of a native splash screen. Scott > On Jun 4, 2018, at 5:13 AM, Tom Schindl wrote: > > A splash screen has to be that instant that it IMHO makes no sense to > time how long it takes to get the JVM and JavaFX up and running because > it can never be as instant as a splash has to show up. > > Tom > >> On 04.06.18 01:06, Scott Palmer wrote: >> Has anyone actually timed how long it takes to get a Java window on screen? I don?t think the delay is long enough to bother with a splash screen these days. >> >> Scott >> >>> On Jun 3, 2018, at 4:22 AM, Tom Schindl wrote: >>> >>> That's why I requested that since a long time from the packager because >>> a splash has to be part of the native launcher created. >>> >>> The Eclipse-RCP-Launcher does exactly the right thing: >>> * Show a static image (IIRC they use bmp) >>> * Once the VM and UI-Toolkit is up replace that image with a window (SWT >>> calls it Shell) so that you can go interactive showing videos, >>> a progressbar, ... >>> >>> Tom >>> >>>> On 03.06.18 10:11, Mario Ivankovits wrote: >>>> A preloader/splash-screen will/should also hide the JVM startup time. >>>> >>>> Best regards, >>>> Mario >>>> >>>> >>>>> Am 03.06.2018 um 09:57 schrieb Tom Schindl : >>>>> >>>>> On 01.06.18 19:42, Johan Vos wrote: >>>>>> I'm not saying a preloader is really a requirement, but I know of a few >>>>>> applications that are using it and benefiting from it. >>>>>> >>>>>> The preloader functionality is more than just a splash screen, and I see >>>>>> this valuable for instance when static initializers of classes that are >>>>>> used in the main class may take a lot of time. >>>>> >>>>> Then I'd argue that you can easily refactor your main-class ;-) >>>>> >>>>> Tom >>>> From johan.vos at gluonhq.com Mon Jun 4 10:58:11 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 4 Jun 2018 12:58:11 +0200 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: <4E733F52-D007-4CCF-96E5-024BD0174EA7@gmail.com> References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> <4617b3c8-27da-5707-c070-11422e698f9d@bestsolution.at> <47C37D5F-15D0-4FA8-9A1F-173E832FB50E@datenwort.at> <5203b303-ce75-8e80-0fb8-c68ebb986e6e@bestsolution.at> <4E733F52-D007-4CCF-96E5-024BD0174EA7@gmail.com> Message-ID: The problem is not the Java window, but the dependencies. If that window is created by a class that requires resolving other classes and somehow one of these classes take a long time to initialize, it will be slow. - Johan On Mon, Jun 4, 2018 at 12:53 PM Scott Palmer wrote: > If a Java window appears in less than half a second there is no point in > adding the complexity of a native splash screen. > > Scott > > > On Jun 4, 2018, at 5:13 AM, Tom Schindl > wrote: > > > > A splash screen has to be that instant that it IMHO makes no sense to > > time how long it takes to get the JVM and JavaFX up and running because > > it can never be as instant as a splash has to show up. > > > > Tom > > > >> On 04.06.18 01:06, Scott Palmer wrote: > >> Has anyone actually timed how long it takes to get a Java window on > screen? I don?t think the delay is long enough to bother with a splash > screen these days. > >> > >> Scott > >> > >>> On Jun 3, 2018, at 4:22 AM, Tom Schindl > wrote: > >>> > >>> That's why I requested that since a long time from the packager because > >>> a splash has to be part of the native launcher created. > >>> > >>> The Eclipse-RCP-Launcher does exactly the right thing: > >>> * Show a static image (IIRC they use bmp) > >>> * Once the VM and UI-Toolkit is up replace that image with a window > (SWT > >>> calls it Shell) so that you can go interactive showing videos, > >>> a progressbar, ... > >>> > >>> Tom > >>> > >>>> On 03.06.18 10:11, Mario Ivankovits wrote: > >>>> A preloader/splash-screen will/should also hide the JVM startup time. > >>>> > >>>> Best regards, > >>>> Mario > >>>> > >>>> > >>>>> Am 03.06.2018 um 09:57 schrieb Tom Schindl < > tom.schindl at bestsolution.at>: > >>>>> > >>>>> On 01.06.18 19:42, Johan Vos wrote: > >>>>>> I'm not saying a preloader is really a requirement, but I know of a > few > >>>>>> applications that are using it and benefiting from it. > >>>>>> > >>>>>> The preloader functionality is more than just a splash screen, and > I see > >>>>>> this valuable for instance when static initializers of classes that > are > >>>>>> used in the main class may take a lot of time. > >>>>> > >>>>> Then I'd argue that you can easily refactor your main-class ;-) > >>>>> > >>>>> Tom > >>>> > From pedro.duquevieira at gmail.com Mon Jun 4 14:44:55 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 4 Jun 2018 15:44:55 +0100 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) Message-ID: Hi, I agree with Johan and others, a splash screen is valuable and needed. Microsoft applications that run on Windows itself (think Word, Excel, etc), they have a splash screen, Intelllij has a splash screen (it's swing based AFAIK), etc.. If a Microsoft application running on its own operating system needs a splash screen then chances are pretty high that there will be Java apps that'll need a splash screen. Cheers, -- Pedro Duque Vieira From swpalmer at gmail.com Mon Jun 4 16:22:18 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 4 Jun 2018 12:22:18 -0400 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: Message-ID: <536BF700-3F7B-42D2-9CD9-21EF9385C0D1@gmail.com> Nobody is arguing against splash screens. I?m simply suggesting that the JVM startup is not slow enough that we need special handling of this in native code. If Java can get a window displayed in under half a second there is no need for the added complexity to support a native splash screen in the launcher. The idea that cinit code *can* be slow is not really the issue here unless it isn?t possible to get a window displayed quickly even when there is no significant initialization other than to get that window= shown. Don?t put heavy initialization in the main class when you want a splash screen. Use a pre-main class that shows the splash screen and calls the ?real? main class. It makes sense to understand if we have this problem before making a complex solution. Scott > On Jun 4, 2018, at 10:44 AM, Pedro Duque Vieira wrote: > > Hi, > > I agree with Johan and others, a splash screen is valuable and needed. > > Microsoft applications that run on Windows itself (think Word, Excel, etc), > they have a splash screen, Intelllij has a splash screen (it's swing based > AFAIK), etc.. If a Microsoft application running on its own operating > system needs a splash screen then chances are pretty high that there will > be Java apps that'll need a splash screen. > > Cheers, > > > -- > Pedro Duque Vieira From mp at jugs.org Mon Jun 4 16:35:15 2018 From: mp at jugs.org (Michael Paus) Date: Mon, 4 Jun 2018 18:35:15 +0200 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: Message-ID: <99ace730-ad9b-f8ba-dd35-c2cf56b993a6@jugs.org> Maybe I misunderstood the question but to my opinion the real question is whether the new java packager has to provide the support for a splash screen or not. This has nothing to do with the question whether applications should have a splash screen or not because if we find that todays Java is fast enough to display a simple window in less than a second or so, then the Java GUI (Swing or JavaFX) could provide a splash screen itself. There is then no need for an additional mechanism provided my the packager. Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira: > Hi, > > I agree with Johan and others, a splash screen is valuable and needed. > > Microsoft applications that run on Windows itself (think Word, Excel, etc), > they have a splash screen, Intelllij has a splash screen (it's swing based > AFAIK), etc.. If a Microsoft application running on its own operating > system needs a splash screen then chances are pretty high that there will > be Java apps that'll need a splash screen. > > Cheers, > > From mario at datenwort.at Mon Jun 4 16:43:06 2018 From: mario at datenwort.at (Mario Ivankovits) Date: Mon, 4 Jun 2018 16:43:06 +0000 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: <536BF700-3F7B-42D2-9CD9-21EF9385C0D1@gmail.com> References: <536BF700-3F7B-42D2-9CD9-21EF9385C0D1@gmail.com> Message-ID: <624B18B0-7D00-45B3-8A1A-51213BDFF700@datenwort.at> Hi! I?ve just test with this very small JavaFX Application: public class TstFx extends Application { @Override public void start(Stage primaryStage) throws Exception { Label root = new Label("test"); Scene scene = new Scene(root, 800, 600); primaryStage.setOnShown(evt -> System.exit(1)); primaryStage.setScene(scene); primaryStage.show(); } public static void main(String[] args) { launch(args); } } As you can see, the program forcibly exits once the stage is shown. So, using ?time? I can simply measure the time required until the stage should be visible on screen. Starting this with an incredible huge classpath (the one we have to use in production) I get this times: real 0m1.885s user 0m3.372s sys 0m0.433s Using a really small classpath I can come down to: real 0m1.639s user 0m2.208s sys 0m0.297s MacBook late 2016. The ?user" difference seems to be just because of the classpath scanning. No static initialization happening, because this TstFx does not reference any other class. Best regards, Mario Am 04.06.2018 um 18:22 schrieb Scott Palmer >: Nobody is arguing against splash screens. I?m simply suggesting that the JVM startup is not slow enough that we need special handling of this in native code. If Java can get a window displayed in under half a second there is no need for the added complexity to support a native splash screen in the launcher. The idea that cinit code *can* be slow is not really the issue here unless it isn?t possible to get a window displayed quickly even when there is no significant initialization other than to get that window= shown. Don?t put heavy initialization in the main class when you want a splash screen. Use a pre-main class that shows the splash screen and calls the ?real? main class. It makes sense to understand if we have this problem before making a complex solution. Scott On Jun 4, 2018, at 10:44 AM, Pedro Duque Vieira > wrote: Hi, I agree with Johan and others, a splash screen is valuable and needed. Microsoft applications that run on Windows itself (think Word, Excel, etc), they have a splash screen, Intelllij has a splash screen (it's swing based AFAIK), etc.. If a Microsoft application running on its own operating system needs a splash screen then chances are pretty high that there will be Java apps that'll need a splash screen. Cheers, -- Pedro Duque Vieira From tom.schindl at bestsolution.at Mon Jun 4 20:51:56 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 4 Jun 2018 22:51:56 +0200 Subject: OpenGL deprecated in OS-X Message-ID: Hi, I don?t know what the Apple guys are smoking but they just deprecated OpenGL. The question is what does this mean for JavaFX. See https://developer.apple.com/macos/whats-new/ Tom Von meinem iPhone gesendet From sverre.moe at gmail.com Mon Jun 4 22:01:54 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Tue, 5 Jun 2018 00:01:54 +0200 Subject: Removal of apps/scenebuilder from OpenJFX repo In-Reply-To: References: <5A9985EF.5000701@oracle.com> <4846435.J8drcGo0IV@andor> <5AA6FE44.5000609@oracle.com> <5AA83E89.5060908@oracle.com> Message-ID: Looks like Gluon has moved SceneBuilder from Bitbucket for GitHub. https://github.com/gluonhq/scenebuilder I like this move. GitHub is much better to work with. Den fre. 27. apr. 2018 kl. 13:31 skrev Sverre Moe : > > I would like to hear from Gluon about their work on SceneBuilder. > Do they have any plans for improve on SceneBuilder, both bug fixed and > new features? > > I guess Gluon only work on their own fork of SceneBuilder, but do they > send changes back to the OpenJFX repository? > > We have migrated our application from Swing to JavaFX and have thus > begun to use SceneBuilder. I therefor hope it will be actively > maintained further. > > How can we the community contribute to the continued development of > SceneBuilder. > Should we work against the OpenJFX SceneBuilder or the Gluon SceneBuilder? > https://bitbucket.org/gluon-oss/scenebuilder > https://github.com/javafxports/openjdk-jfx/tree/develop/apps/scenebuilder > > /Sverre > > > 2018-03-13 22:11 GMT+01:00 Kevin Rushforth : > > That will be a question for Gluon. > > > > -- Kevin > > > > > > > > Michael Paus wrote: > >> > >> How will these changes then be synchronized with the work Gluon is doing > >> for the version > >> distributed by them? Do they work on the same repo? > >> > >> Am 12.03.18 um 23:25 schrieb Kevin Rushforth: > >>> > >>> Hi Florian, > >>> > >>> By way of update, after thinking about this for a week (and getting some > >>> offline feedback), I no longer propose doing this -- at least not for the > >>> short-mid term. I've retargeted this RFE to tbd_major and lowered the > >>> priority to P4. > >>> > >>> Having said that, we don't have any plans to modify SceneBuilder, but > >>> will happily accept contributions. > >>> > >>> -- Kevin > >>> > >>> > >>> Florian Brunner wrote: > >>>> > >>>> OK, this still comes a bit as a surprise as the source code has been > >>>> kept in the repo and was not just provided as a ZIP file. > >>>> > >>>> I'm currently working on a tool based on the SceneBuilder Kit. I needed > >>>> to work on the code a bit and was planning to donate the code back to > >>>> OpenJFX once released, as I was under the impression OpenJFX would serve as > >>>> the master / upstream-repo for all SceneBuilder forks. I was also under the > >>>> impression that OpenJFX at least would make sure the code works with any new > >>>> JDK / JavaFX version and hoped it would get support for new controls, if any > >>>> were added to JavaFX. > >>>> > >>>> -Florian > >>>> > >>>> Am Freitag, 2. M?rz 2018, 09:12:15 CET schrieb Kevin Rushforth: > >>>>> > >>>>> I filed the following JBS isuse to remova the SceneBuilder sources from > >>>>> the OpenJFX repo. > >>>>> > >>>>> https://bugs.openjdk.java.net/browse/JDK-8198961 > >>>>> > >>>>> As mentioned in the Description of that issue, the OpenJFX repo > >>>>> contains the source code for a no-longer-maintained version of the > >>>>> SceneBuilder tool. Active development on SceneBuilder in the OpenJFX repo > >>>>> was stopped over three years ago. Since that time, the only changes have > >>>>> been either jigsaw-related changes to keep it buildable and runnable, or > >>>>> global changes that happened to touch some of the files in > >>>>> apps/scenebuilder. > >>>>> > >>>>> A fork of SceneBuilder is maintained by Gluon, so anyone wanting to get > >>>>> the latest SceneBuilder should go there. > >>>>> > >>>>> Before I proceed, I wanted to poll the list to see whether anyone has a > >>>>> concern with this. I don't plan to take any action for at least a week. > >>>>> > >>>>> -- Kevin > >>>>> > >>>>> > >>>> > >>>> > >> > > From kevin.rushforth at oracle.com Mon Jun 4 22:22:03 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 4 Jun 2018 15:22:03 -0700 Subject: OpenGL deprecated in OS-X In-Reply-To: References: Message-ID: Apple has been making noises about this for a while. I wouldn't expect them to drop OpenGL in the very near future, but it would seem that investigating a Metal pipeline for FX is timely. -- Kevin On 6/4/2018 1:51 PM, Tom Schindl wrote: > Hi, > > I don?t know what the Apple guys are smoking but they just deprecated OpenGL. The question is what does this mean for JavaFX. > > See https://developer.apple.com/macos/whats-new/ > > Tom > > Von meinem iPhone gesendet From johnvalrose at gmail.com Mon Jun 4 22:25:05 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Tue, 5 Jun 2018 08:25:05 +1000 Subject: OpenGL deprecated in OS-X In-Reply-To: References: Message-ID: Unfortunately Apple is doing exactly what Microsoft did during the ?Great API Wars?. During this time, MS decided to go with its own exclusive graphics API namely Direct 3D as part of their whole DirectX technology instead of the obvious approach of supporting OpenGL fully. These days, GPU drivers for DirectX work much better on Windows than those for OpenGL. The same will now apply for Metal drivers versus OpenGL drivers on MacOS. This is all about ?vendor lock-in? and can be seen with other technologies like WebKit and Blink for example. Of course this is bad news for the developers but devs are not the core market for Windows, Apple or Google/Android hardware. The bright light on the horizon is Vulkan from Khronos which started out life as OpenGL 5 but is now being pushed as the ultimate cross platform graphics API. Even Microsoft have jumped on board and Vulkan driver support on Windows is good. We will have to wait and see but having a situation where OpenGL, DirectX, Metal and Vulkan are all important graphics APIs simultaneously is clearly not tenable. > On 5 Jun 2018, at 06:51, Tom Schindl wrote: > > Hi, > > I don?t know what the Apple guys are smoking but they just deprecated OpenGL. The question is what does this mean for JavaFX. > > See https://developer.apple.com/macos/whats-new/ > > Tom > > Von meinem iPhone gesendet From johan.vos at gluonhq.com Tue Jun 5 07:18:32 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 5 Jun 2018 09:18:32 +0200 Subject: OpenGL deprecated in OS-X In-Reply-To: References: Message-ID: Ever since Apple deprecated the developer-oriented Apple ][ , I failed to appreciate their decisions. But so be it. The good thing is that the structure of the OpenJFX project allows for different rendering pipelines without much impact on other code. Therefore, I think it would be a nice sandbox experiment to have a Metal and a Vulkan pipeline. But I agree with Kevin, we don't need a replacement for OpenGL in the Java 11 timeframe :) - Johan On Tue, Jun 5, 2018 at 12:35 AM John-Val Rose wrote: > Unfortunately Apple is doing exactly what Microsoft did during the ?Great > API Wars?. During this time, MS decided to go with its own exclusive > graphics API namely Direct 3D as part of their whole DirectX technology > instead of the obvious approach of supporting OpenGL fully. > > These days, GPU drivers for DirectX work much better on Windows than those > for OpenGL. > > The same will now apply for Metal drivers versus OpenGL drivers on MacOS. > > This is all about ?vendor lock-in? and can be seen with other technologies > like WebKit and Blink for example. > > Of course this is bad news for the developers but devs are not the core > market for Windows, Apple or Google/Android hardware. > > The bright light on the horizon is Vulkan from Khronos which started out > life as OpenGL 5 but is now being pushed as the ultimate cross platform > graphics API. > > Even Microsoft have jumped on board and Vulkan driver support on Windows > is good. > > We will have to wait and see but having a situation where OpenGL, DirectX, > Metal and Vulkan are all important graphics APIs simultaneously is clearly > not tenable. > > > On 5 Jun 2018, at 06:51, Tom Schindl > wrote: > > > > Hi, > > > > I don?t know what the Apple guys are smoking but they just deprecated > OpenGL. The question is what does this mean for JavaFX. > > > > See https://developer.apple.com/macos/whats-new/ > > > > Tom > > > > Von meinem iPhone gesendet > From paulrussell70 at gmail.com Tue Jun 5 07:51:01 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Tue, 5 Jun 2018 08:51:01 +0100 Subject: OpenGL deprecated in OS-X Message-ID: Tom's right. Major news. Presumably prism would need to cater for a third renderer, Metal. What would be the time scales for this? Is this an opportunity to update the way javafx renderer works? Perhaps a tie in to Lwjgl is better? They have Vulcan bindings and no doubt will wrap Metal. But I would advocate avoiding a naive object wrapper that privatises all wrapped calls. Imo. The problem is, currently, if a dev needs lower level access it's all shielded. On Mon, 4 Jun 2018, 23:02 , wrote: > Send openjfx-dev mailing list submissions to > openjfx-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-request at openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > > 1. Re: Draft JEP for new Packaging Tool (replacement for > javapackager) (Pedro Duque Vieira) > 2. Re: Draft JEP for new Packaging Tool (replacement for > javapackager) (Scott Palmer) > 3. Re: Draft JEP for new Packaging Tool (replacement for > javapackager) (Michael Paus) > 4. Re: Draft JEP for new Packaging Tool (replacement for > javapackager) (Mario Ivankovits) > 5. OpenGL deprecated in OS-X (Tom Schindl) > 6. Re: Removal of apps/scenebuilder from OpenJFX repo (Sverre Moe) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 4 Jun 2018 15:44:55 +0100 > From: Pedro Duque Vieira > To: OpenJFX Mailing List > Subject: Re: Draft JEP for new Packaging Tool (replacement for > javapackager) > Message-ID: > < > CAAEud6ZA5JLNgbSVsaw0D-MLWnREq2Y6MMtqyrvXuvsUoeXC3A at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi, > > I agree with Johan and others, a splash screen is valuable and needed. > > Microsoft applications that run on Windows itself (think Word, Excel, etc), > they have a splash screen, Intelllij has a splash screen (it's swing based > AFAIK), etc.. If a Microsoft application running on its own operating > system needs a splash screen then chances are pretty high that there will > be Java apps that'll need a splash screen. > > Cheers, > > > -- > Pedro Duque Vieira > > > ------------------------------ > > Message: 2 > Date: Mon, 4 Jun 2018 12:22:18 -0400 > From: Scott Palmer > To: OpenJFX Mailing List > Subject: Re: Draft JEP for new Packaging Tool (replacement for > javapackager) > Message-ID: <536BF700-3F7B-42D2-9CD9-21EF9385C0D1 at gmail.com> > Content-Type: text/plain; charset=utf-8 > > Nobody is arguing against splash screens. I?m simply suggesting that the > JVM startup is not slow enough that we need special handling of this in > native code. > > If Java can get a window displayed in under half a second there is no need > for the added complexity to support a native splash screen in the launcher. > > The idea that cinit code *can* be slow is not really the issue here unless > it isn?t possible to get a window displayed quickly even when there is no > significant initialization other than to get that window= shown. Don?t put > heavy initialization in the main class when you want a splash screen. Use > a pre-main class that shows the splash screen and calls the ?real? main > class. > > It makes sense to understand if we have this problem before making a > complex solution. > > Scott > > > > On Jun 4, 2018, at 10:44 AM, Pedro Duque Vieira < > pedro.duquevieira at gmail.com> wrote: > > > > Hi, > > > > I agree with Johan and others, a splash screen is valuable and needed. > > > > Microsoft applications that run on Windows itself (think Word, Excel, > etc), > > they have a splash screen, Intelllij has a splash screen (it's swing > based > > AFAIK), etc.. If a Microsoft application running on its own operating > > system needs a splash screen then chances are pretty high that there will > > be Java apps that'll need a splash screen. > > > > Cheers, > > > > > > -- > > Pedro Duque Vieira > > > > ------------------------------ > > Message: 3 > Date: Mon, 4 Jun 2018 18:35:15 +0200 > From: Michael Paus > To: OpenJFX > Subject: Re: Draft JEP for new Packaging Tool (replacement for > javapackager) > Message-ID: <99ace730-ad9b-f8ba-dd35-c2cf56b993a6 at jugs.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > Maybe I misunderstood the question but to my opinion the real question is > whether the new java packager has to provide the support for a splash > screen > or not. This has nothing to do with the question whether applications > should > have a splash screen or not because if we find that todays Java is fast > enough > to display a simple window in less than a second or so, then the Java GUI > (Swing or JavaFX) could provide a splash screen itself. There is then no > need > for an additional mechanism provided my the packager. > > Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira: > > Hi, > > > > I agree with Johan and others, a splash screen is valuable and needed. > > > > Microsoft applications that run on Windows itself (think Word, Excel, > etc), > > they have a splash screen, Intelllij has a splash screen (it's swing > based > > AFAIK), etc.. If a Microsoft application running on its own operating > > system needs a splash screen then chances are pretty high that there will > > be Java apps that'll need a splash screen. > > > > Cheers, > > > > > > > > ------------------------------ > > Message: 4 > Date: Mon, 4 Jun 2018 16:43:06 +0000 > From: Mario Ivankovits > To: Scott Palmer > Cc: OpenJFX Mailing List > Subject: Re: Draft JEP for new Packaging Tool (replacement for > javapackager) > Message-ID: <624B18B0-7D00-45B3-8A1A-51213BDFF700 at datenwort.at> > Content-Type: text/plain; charset="utf-8" > > Hi! > > I?ve just test with this very small JavaFX Application: > > public class TstFx extends Application > { > @Override > public void start(Stage primaryStage) throws Exception > { > Label root = new Label("test"); > Scene scene = new Scene(root, 800, 600); > primaryStage.setOnShown(evt -> System.exit(1)); > > primaryStage.setScene(scene); > primaryStage.show(); > } > > public static void main(String[] args) > { > launch(args); > } > } > > As you can see, the program forcibly exits once the stage is shown. So, > using ?time? I can simply measure the time required until the stage should > be visible on screen. > > Starting this with an incredible huge classpath (the one we have to use in > production) I get this times: > real 0m1.885s > user 0m3.372s > sys 0m0.433s > > Using a really small classpath I can come down to: > real 0m1.639s > user 0m2.208s > sys 0m0.297s > > > MacBook late 2016. > > The ?user" difference seems to be just because of the classpath scanning. > No static initialization happening, because this TstFx does not reference > any other class. > > Best regards, > Mario > > > Am 04.06.2018 um 18:22 schrieb Scott Palmer swpalmer at gmail.com>>: > > Nobody is arguing against splash screens. I?m simply suggesting that the > JVM startup is not slow enough that we need special handling of this in > native code. > > If Java can get a window displayed in under half a second there is no need > for the added complexity to support a native splash screen in the launcher. > > The idea that cinit code *can* be slow is not really the issue here unless > it isn?t possible to get a window displayed quickly even when there is no > significant initialization other than to get that window= shown. Don?t put > heavy initialization in the main class when you want a splash screen. Use > a pre-main class that shows the splash screen and calls the ?real? main > class. > > It makes sense to understand if we have this problem before making a > complex solution. > > Scott > > > On Jun 4, 2018, at 10:44 AM, Pedro Duque Vieira < > pedro.duquevieira at gmail.com> wrote: > > Hi, > > I agree with Johan and others, a splash screen is valuable and needed. > > Microsoft applications that run on Windows itself (think Word, Excel, etc), > they have a splash screen, Intelllij has a splash screen (it's swing based > AFAIK), etc.. If a Microsoft application running on its own operating > system needs a splash screen then chances are pretty high that there will > be Java apps that'll need a splash screen. > > Cheers, > > > -- > Pedro Duque Vieira > > > > ------------------------------ > > Message: 5 > Date: Mon, 4 Jun 2018 22:51:56 +0200 > From: Tom Schindl > To: openjfx-dev at openjdk.java.net > Subject: OpenGL deprecated in OS-X > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Hi, > > I don?t know what the Apple guys are smoking but they just deprecated > OpenGL. The question is what does this mean for JavaFX. > > See https://developer.apple.com/macos/whats-new/ > > Tom > > Von meinem iPhone gesendet > > ------------------------------ > > Message: 6 > Date: Tue, 5 Jun 2018 00:01:54 +0200 > From: Sverre Moe > To: openjfx-dev at openjdk.java.net > Subject: Re: Removal of apps/scenebuilder from OpenJFX repo > Message-ID: > CPf+uxba3j+x0o1kMeej0Sq7cS0S-j4-3pfPotg at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Looks like Gluon has moved SceneBuilder from Bitbucket for GitHub. > https://github.com/gluonhq/scenebuilder > I like this move. GitHub is much better to work with. > > > Den fre. 27. apr. 2018 kl. 13:31 skrev Sverre Moe : > > > > I would like to hear from Gluon about their work on SceneBuilder. > > Do they have any plans for improve on SceneBuilder, both bug fixed and > > new features? > > > > I guess Gluon only work on their own fork of SceneBuilder, but do they > > send changes back to the OpenJFX repository? > > > > We have migrated our application from Swing to JavaFX and have thus > > begun to use SceneBuilder. I therefor hope it will be actively > > maintained further. > > > > How can we the community contribute to the continued development of > > SceneBuilder. > > Should we work against the OpenJFX SceneBuilder or the Gluon > SceneBuilder? > > https://bitbucket.org/gluon-oss/scenebuilder > > > https://github.com/javafxports/openjdk-jfx/tree/develop/apps/scenebuilder > > > > /Sverre > > > > > > 2018-03-13 22:11 GMT+01:00 Kevin Rushforth : > > > That will be a question for Gluon. > > > > > > -- Kevin > > > > > > > > > > > > Michael Paus wrote: > > >> > > >> How will these changes then be synchronized with the work Gluon is > doing > > >> for the version > > >> distributed by them? Do they work on the same repo? > > >> > > >> Am 12.03.18 um 23:25 schrieb Kevin Rushforth: > > >>> > > >>> Hi Florian, > > >>> > > >>> By way of update, after thinking about this for a week (and getting > some > > >>> offline feedback), I no longer propose doing this -- at least not > for the > > >>> short-mid term. I've retargeted this RFE to tbd_major and lowered the > > >>> priority to P4. > > >>> > > >>> Having said that, we don't have any plans to modify SceneBuilder, but > > >>> will happily accept contributions. > > >>> > > >>> -- Kevin > > >>> > > >>> > > >>> Florian Brunner wrote: > > >>>> > > >>>> OK, this still comes a bit as a surprise as the source code has been > > >>>> kept in the repo and was not just provided as a ZIP file. > > >>>> > > >>>> I'm currently working on a tool based on the SceneBuilder Kit. I > needed > > >>>> to work on the code a bit and was planning to donate the code back > to > > >>>> OpenJFX once released, as I was under the impression OpenJFX would > serve as > > >>>> the master / upstream-repo for all SceneBuilder forks. I was also > under the > > >>>> impression that OpenJFX at least would make sure the code works > with any new > > >>>> JDK / JavaFX version and hoped it would get support for new > controls, if any > > >>>> were added to JavaFX. > > >>>> > > >>>> -Florian > > >>>> > > >>>> Am Freitag, 2. M?rz 2018, 09:12:15 CET schrieb Kevin Rushforth: > > >>>>> > > >>>>> I filed the following JBS isuse to remova the SceneBuilder sources > from > > >>>>> the OpenJFX repo. > > >>>>> > > >>>>> https://bugs.openjdk.java.net/browse/JDK-8198961 > > >>>>> > > >>>>> As mentioned in the Description of that issue, the OpenJFX repo > > >>>>> contains the source code for a no-longer-maintained version of the > > >>>>> SceneBuilder tool. Active development on SceneBuilder in the > OpenJFX repo > > >>>>> was stopped over three years ago. Since that time, the only > changes have > > >>>>> been either jigsaw-related changes to keep it buildable and > runnable, or > > >>>>> global changes that happened to touch some of the files in > > >>>>> apps/scenebuilder. > > >>>>> > > >>>>> A fork of SceneBuilder is maintained by Gluon, so anyone wanting > to get > > >>>>> the latest SceneBuilder should go there. > > >>>>> > > >>>>> Before I proceed, I wanted to poll the list to see whether anyone > has a > > >>>>> concern with this. I don't plan to take any action for at least a > week. > > >>>>> > > >>>>> -- Kevin > > >>>>> > > >>>>> > > >>>> > > >>>> > > >> > > > > > > End of openjfx-dev Digest, Vol 79, Issue 6 > ****************************************** > From johnvalrose at gmail.com Tue Jun 5 07:52:42 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Tue, 5 Jun 2018 17:52:42 +1000 Subject: OpenGL deprecated in OS-X In-Reply-To: References: Message-ID: I?m doing some work with Vulkan at the moment so maybe I?ll be able to help out with Vk support for JavaFX. John-Val > On 5 Jun 2018, at 17:18, Johan Vos wrote: > > Ever since Apple deprecated the developer-oriented Apple ][ , I failed to appreciate their decisions. But so be it. > > The good thing is that the structure of the OpenJFX project allows for different rendering pipelines without much impact on other code. > Therefore, I think it would be a nice sandbox experiment to have a Metal and a Vulkan pipeline. > > But I agree with Kevin, we don't need a replacement for OpenGL in the Java 11 timeframe :) > > - Johan > > >> On Tue, Jun 5, 2018 at 12:35 AM John-Val Rose wrote: >> Unfortunately Apple is doing exactly what Microsoft did during the ?Great API Wars?. During this time, MS decided to go with its own exclusive graphics API namely Direct 3D as part of their whole DirectX technology instead of the obvious approach of supporting OpenGL fully. >> >> These days, GPU drivers for DirectX work much better on Windows than those for OpenGL. >> >> The same will now apply for Metal drivers versus OpenGL drivers on MacOS. >> >> This is all about ?vendor lock-in? and can be seen with other technologies like WebKit and Blink for example. >> >> Of course this is bad news for the developers but devs are not the core market for Windows, Apple or Google/Android hardware. >> >> The bright light on the horizon is Vulkan from Khronos which started out life as OpenGL 5 but is now being pushed as the ultimate cross platform graphics API. >> >> Even Microsoft have jumped on board and Vulkan driver support on Windows is good. >> >> We will have to wait and see but having a situation where OpenGL, DirectX, Metal and Vulkan are all important graphics APIs simultaneously is clearly not tenable. >> >> > On 5 Jun 2018, at 06:51, Tom Schindl wrote: >> > >> > Hi, >> > >> > I don?t know what the Apple guys are smoking but they just deprecated OpenGL. The question is what does this mean for JavaFX. >> > >> > See https://developer.apple.com/macos/whats-new/ >> > >> > Tom >> > >> > Von meinem iPhone gesendet From johan.vos at gluonhq.com Tue Jun 5 07:56:47 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 5 Jun 2018 09:56:47 +0200 Subject: Removal of apps/scenebuilder from OpenJFX repo In-Reply-To: References: <5A9985EF.5000701@oracle.com> <4846435.J8drcGo0IV@andor> <5AA6FE44.5000609@oracle.com> Message-ID: Sorry, I missed this question. We incorporated the changes that were in OpenJFX 9 into the butbucket repo and they are part of the Gluon Scene Builder 9 release. - Johan On Tue, Mar 13, 2018 at 10:17 PM Michael Paus wrote: > How will these changes then be synchronized with the work Gluon is doing > for the version > distributed by them? Do they work on the same repo? > > Am 12.03.18 um 23:25 schrieb Kevin Rushforth: > > Hi Florian, > > > > By way of update, after thinking about this for a week (and getting > > some offline feedback), I no longer propose doing this -- at least not > > for the short-mid term. I've retargeted this RFE to tbd_major and > > lowered the priority to P4. > > > > Having said that, we don't have any plans to modify SceneBuilder, but > > will happily accept contributions. > > > > -- Kevin > > > > > > Florian Brunner wrote: > >> OK, this still comes a bit as a surprise as the source code has been > >> kept in the repo and was not just provided as a ZIP file. > >> > >> I'm currently working on a tool based on the SceneBuilder Kit. I > >> needed to work on the code a bit and was planning to donate the code > >> back to OpenJFX once released, as I was under the impression OpenJFX > >> would serve as the master / upstream-repo for all SceneBuilder forks. > >> I was also under the impression that OpenJFX at least would make sure > >> the code works with any new JDK / JavaFX version and hoped it would > >> get support for new controls, if any were added to JavaFX. > >> > >> -Florian > >> > >> Am Freitag, 2. M?rz 2018, 09:12:15 CET schrieb Kevin Rushforth: > >>> I filed the following JBS isuse to remova the SceneBuilder sources > >>> from the OpenJFX repo. > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8198961 > >>> > >>> As mentioned in the Description of that issue, the OpenJFX repo > >>> contains the source code for a no-longer-maintained version of the > >>> SceneBuilder tool. Active development on SceneBuilder in the OpenJFX > >>> repo was stopped over three years ago. Since that time, the only > >>> changes have been either jigsaw-related changes to keep it buildable > >>> and runnable, or global changes that happened to touch some of the > >>> files in apps/scenebuilder. > >>> > >>> A fork of SceneBuilder is maintained by Gluon, so anyone wanting to > >>> get the latest SceneBuilder should go there. > >>> > >>> Before I proceed, I wanted to poll the list to see whether anyone > >>> has a concern with this. I don't plan to take any action for at > >>> least a week. > >>> > >>> -- Kevin > >>> > >>> > >> > >> > > From mp at jugs.org Tue Jun 5 08:00:52 2018 From: mp at jugs.org (Michael Paus) Date: Tue, 5 Jun 2018 10:00:52 +0200 Subject: OpenGL deprecated in OS-X In-Reply-To: References: Message-ID: <808dcba4-9f88-65ce-d124-4b8061369112@jugs.org> Hi, in the light of this announcement it might be a good idea to consider ANGLE again as a unified rendering platform for JavaFX. Do not try to reinvent the wheel again. The JavaFX community is much too small to always do its own thing. Relying on a rendering technology which is used by giants like Google and Mozilla is probably a better idea than once again cooking our own soup. Using ANGLE should also make it possible to finally support WebGL in WebView. Michael Am 04.06.18 um 22:51 schrieb Tom Schindl: > Hi, > > I don?t know what the Apple guys are smoking but they just deprecated OpenGL. The question is what does this mean for JavaFX. > > See https://developer.apple.com/macos/whats-new/ > > Tom > > Von meinem iPhone gesendet From johan.vos at gluonhq.com Tue Jun 5 08:05:16 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 5 Jun 2018 10:05:16 +0200 Subject: Removal of apps/scenebuilder from OpenJFX repo In-Reply-To: References: <5A9985EF.5000701@oracle.com> <4846435.J8drcGo0IV@andor> <5AA6FE44.5000609@oracle.com> <5AA83E89.5060908@oracle.com> Message-ID: Hi Sverre, That is true, we are moving Scene Builder to GitHub. It was a labour intensive process as we looked into PR's and issues and history etc, but it's almost done now. While the process doesn't change, we understood most developers prefer to work with github for these kinds of open-source projects, so we hope to increase contributions and feedback. We are about to release Scene Builder 10 and then the focus is of course on Scene Builder 11. - Johan On Tue, Jun 5, 2018 at 12:12 AM Sverre Moe wrote: > Looks like Gluon has moved SceneBuilder from Bitbucket for GitHub. > https://github.com/gluonhq/scenebuilder > I like this move. GitHub is much better to work with. > > > Den fre. 27. apr. 2018 kl. 13:31 skrev Sverre Moe : > > > > I would like to hear from Gluon about their work on SceneBuilder. > > Do they have any plans for improve on SceneBuilder, both bug fixed and > > new features? > > > > I guess Gluon only work on their own fork of SceneBuilder, but do they > > send changes back to the OpenJFX repository? > > > > We have migrated our application from Swing to JavaFX and have thus > > begun to use SceneBuilder. I therefor hope it will be actively > > maintained further. > > > > How can we the community contribute to the continued development of > > SceneBuilder. > > Should we work against the OpenJFX SceneBuilder or the Gluon > SceneBuilder? > > https://bitbucket.org/gluon-oss/scenebuilder > > > https://github.com/javafxports/openjdk-jfx/tree/develop/apps/scenebuilder > > > > /Sverre > > > > > > 2018-03-13 22:11 GMT+01:00 Kevin Rushforth : > > > That will be a question for Gluon. > > > > > > -- Kevin > > > > > > > > > > > > Michael Paus wrote: > > >> > > >> How will these changes then be synchronized with the work Gluon is > doing > > >> for the version > > >> distributed by them? Do they work on the same repo? > > >> > > >> Am 12.03.18 um 23:25 schrieb Kevin Rushforth: > > >>> > > >>> Hi Florian, > > >>> > > >>> By way of update, after thinking about this for a week (and getting > some > > >>> offline feedback), I no longer propose doing this -- at least not > for the > > >>> short-mid term. I've retargeted this RFE to tbd_major and lowered the > > >>> priority to P4. > > >>> > > >>> Having said that, we don't have any plans to modify SceneBuilder, but > > >>> will happily accept contributions. > > >>> > > >>> -- Kevin > > >>> > > >>> > > >>> Florian Brunner wrote: > > >>>> > > >>>> OK, this still comes a bit as a surprise as the source code has been > > >>>> kept in the repo and was not just provided as a ZIP file. > > >>>> > > >>>> I'm currently working on a tool based on the SceneBuilder Kit. I > needed > > >>>> to work on the code a bit and was planning to donate the code back > to > > >>>> OpenJFX once released, as I was under the impression OpenJFX would > serve as > > >>>> the master / upstream-repo for all SceneBuilder forks. I was also > under the > > >>>> impression that OpenJFX at least would make sure the code works > with any new > > >>>> JDK / JavaFX version and hoped it would get support for new > controls, if any > > >>>> were added to JavaFX. > > >>>> > > >>>> -Florian > > >>>> > > >>>> Am Freitag, 2. M?rz 2018, 09:12:15 CET schrieb Kevin Rushforth: > > >>>>> > > >>>>> I filed the following JBS isuse to remova the SceneBuilder sources > from > > >>>>> the OpenJFX repo. > > >>>>> > > >>>>> https://bugs.openjdk.java.net/browse/JDK-8198961 > > >>>>> > > >>>>> As mentioned in the Description of that issue, the OpenJFX repo > > >>>>> contains the source code for a no-longer-maintained version of the > > >>>>> SceneBuilder tool. Active development on SceneBuilder in the > OpenJFX repo > > >>>>> was stopped over three years ago. Since that time, the only > changes have > > >>>>> been either jigsaw-related changes to keep it buildable and > runnable, or > > >>>>> global changes that happened to touch some of the files in > > >>>>> apps/scenebuilder. > > >>>>> > > >>>>> A fork of SceneBuilder is maintained by Gluon, so anyone wanting > to get > > >>>>> the latest SceneBuilder should go there. > > >>>>> > > >>>>> Before I proceed, I wanted to poll the list to see whether anyone > has a > > >>>>> concern with this. I don't plan to take any action for at least a > week. > > >>>>> > > >>>>> -- Kevin > > >>>>> > > >>>>> > > >>>> > > >>>> > > >> > > > > From johan.vos at gluonhq.com Tue Jun 5 08:19:24 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 5 Jun 2018 10:19:24 +0200 Subject: Removal of apps/scenebuilder from OpenJFX repo In-Reply-To: References: <5A9985EF.5000701@oracle.com> <4846435.J8drcGo0IV@andor> <5AA6FE44.5000609@oracle.com> Message-ID: I wasn't entirely correct. There are 2 changesets that are not in SB9 but that will be part of SB 10: https://github.com/gluonhq/scenebuilder/commit/88f89eb674110ba62d26aec9e6683fc5577bc1ce https://github.com/gluonhq/scenebuilder/commit/a051b9e52a65b918a8711071c9afc8c08f7a3c30 - Johan On Tue, Jun 5, 2018 at 9:56 AM Johan Vos wrote: > Sorry, I missed this question. > We incorporated the changes that were in OpenJFX 9 into the butbucket repo > and they are part of the Gluon Scene Builder 9 release. > > - Johan > > On Tue, Mar 13, 2018 at 10:17 PM Michael Paus wrote: > >> How will these changes then be synchronized with the work Gluon is doing >> for the version >> distributed by them? Do they work on the same repo? >> >> Am 12.03.18 um 23:25 schrieb Kevin Rushforth: >> > Hi Florian, >> > >> > By way of update, after thinking about this for a week (and getting >> > some offline feedback), I no longer propose doing this -- at least not >> > for the short-mid term. I've retargeted this RFE to tbd_major and >> > lowered the priority to P4. >> > >> > Having said that, we don't have any plans to modify SceneBuilder, but >> > will happily accept contributions. >> > >> > -- Kevin >> > >> > >> > Florian Brunner wrote: >> >> OK, this still comes a bit as a surprise as the source code has been >> >> kept in the repo and was not just provided as a ZIP file. >> >> >> >> I'm currently working on a tool based on the SceneBuilder Kit. I >> >> needed to work on the code a bit and was planning to donate the code >> >> back to OpenJFX once released, as I was under the impression OpenJFX >> >> would serve as the master / upstream-repo for all SceneBuilder forks. >> >> I was also under the impression that OpenJFX at least would make sure >> >> the code works with any new JDK / JavaFX version and hoped it would >> >> get support for new controls, if any were added to JavaFX. >> >> >> >> -Florian >> >> >> >> Am Freitag, 2. M?rz 2018, 09:12:15 CET schrieb Kevin Rushforth: >> >>> I filed the following JBS isuse to remova the SceneBuilder sources >> >>> from the OpenJFX repo. >> >>> >> >>> https://bugs.openjdk.java.net/browse/JDK-8198961 >> >>> >> >>> As mentioned in the Description of that issue, the OpenJFX repo >> >>> contains the source code for a no-longer-maintained version of the >> >>> SceneBuilder tool. Active development on SceneBuilder in the OpenJFX >> >>> repo was stopped over three years ago. Since that time, the only >> >>> changes have been either jigsaw-related changes to keep it buildable >> >>> and runnable, or global changes that happened to touch some of the >> >>> files in apps/scenebuilder. >> >>> >> >>> A fork of SceneBuilder is maintained by Gluon, so anyone wanting to >> >>> get the latest SceneBuilder should go there. >> >>> >> >>> Before I proceed, I wanted to poll the list to see whether anyone >> >>> has a concern with this. I don't plan to take any action for at >> >>> least a week. >> >>> >> >>> -- Kevin >> >>> >> >>> >> >> >> >> >> >> From pedro.duquevieira at gmail.com Tue Jun 5 12:20:54 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 5 Jun 2018 13:20:54 +0100 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: <15b07de8-f94e-33c9-4d22-9db3cc7b54ec@jugs.org> References: <15b07de8-f94e-33c9-4d22-9db3cc7b54ec@jugs.org> Message-ID: Sorry, perhaps it was I who misunderstood the debate.. On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus wrote: > Maybe I misunderstood the question but to my opinion the real question is > whether the new java packager has to provide the support for a splash > screen > or not. This has nothing to do with the question whether applications > should > have a splash screen or not because if we find that todays Java is fast > enough > to display a simple window in less than a second or so, then the Java GUI > (Swing or JavaFX) could provide a splash screen itself. There is then no > need > for an additional mechanism provided my the packager. > > Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira: > > Hi, >> >> I agree with Johan and others, a splash screen is valuable and needed. >> >> Microsoft applications that run on Windows itself (think Word, Excel, >> etc), >> they have a splash screen, Intelllij has a splash screen (it's swing based >> AFAIK), etc.. If a Microsoft application running on its own operating >> system needs a splash screen then chances are pretty high that there will >> be Java apps that'll need a splash screen. >> >> Cheers, >> >> >> > -- Pedro Duque Vieira From johan.vos at gluonhq.com Tue Jun 5 13:40:09 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 5 Jun 2018 15:40:09 +0200 Subject: launching JavaFX in 11 Message-ID: Hi, I'm a bit confused on the different options for launching JavaFX applications with the latest Java 11 code. When running an app from maven, it worked fine. Maven uses the classpath and not the module path, so I assumed that running the same app using java -cp all-javafx-jars Main would work too. But it doesn't. The error I got is this: Error: JavaFX runtime components are missing, and are required to run this application This error comes from sun.launcher.LauncherHelper in the java.base module. The reason for this is that the Main app extends Application and has a main method. If that is the case, the LauncherHelper will check for the javafx.graphics module to be present as a named module: Optional om = ModuleLayer.boot().findModule(JAVAFX_GRAPHICS_MODULE_NAME); If that module is not present, the launch is aborted. Hence, having the JavaFX libraries as jars on the classpath is not allowed in this case. Fair, but that doesn't explain why it works via maven. The reason is that maven doesn't start a new VM process, hence the main class is in this case org.codehaus.plexus.classworlds.launcher.Launcher which does not extend Application, hence it doesn't do the check on javafx.graphics module to be present as a named module, and when the required jars (including native code) are on the classpath, it works fine. I thought the check on the main class extending javafx.application.Application was removed from the core JDK, but it is still there, so I understand why it works using maven and fails using a standalone java invocation. While I fully agree the goal is to have the JavaFX modules as named modules on the module path, I think this will create confusion. A simple workaround is to have a separate main class that doesn't extend Application, but that seems a real dirty solution. But maybe I'm missing something? - Johan From swpalmer at gmail.com Tue Jun 5 15:46:47 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 5 Jun 2018 11:46:47 -0400 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: <15b07de8-f94e-33c9-4d22-9db3cc7b54ec@jugs.org> Message-ID: Yes, my only comment was that if we can get a window up using standard Java GUI frameworks fast enough, then the complexity of adding splashscreen support to the launcher isn't justified. Mario's example shows that is it 1-2 seconds to get a window up. That is a bit high. If it was under 1s then I would suggest not bothering, it isn't, so keep it on the list of desired features. Scott On Tue, Jun 5, 2018 at 8:21 AM Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > Sorry, perhaps it was I who misunderstood the debate.. > > On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus wrote: > > > Maybe I misunderstood the question but to my opinion the real question is > > whether the new java packager has to provide the support for a splash > > screen > > or not. This has nothing to do with the question whether applications > > should > > have a splash screen or not because if we find that todays Java is fast > > enough > > to display a simple window in less than a second or so, then the Java GUI > > (Swing or JavaFX) could provide a splash screen itself. There is then no > > need > > for an additional mechanism provided my the packager. > > > > Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira: > > > > Hi, > >> > >> I agree with Johan and others, a splash screen is valuable and needed. > >> > >> Microsoft applications that run on Windows itself (think Word, Excel, > >> etc), > >> they have a splash screen, Intelllij has a splash screen (it's swing > based > >> AFAIK), etc.. If a Microsoft application running on its own operating > >> system needs a splash screen then chances are pretty high that there > will > >> be Java apps that'll need a splash screen. > >> > >> Cheers, > >> > >> > >> > > > > > -- > Pedro Duque Vieira > From weiqigao at gmail.com Tue Jun 5 17:04:08 2018 From: weiqigao at gmail.com (Weiqi Gao) Date: Tue, 5 Jun 2018 12:04:08 -0500 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: <15b07de8-f94e-33c9-4d22-9db3cc7b54ec@jugs.org> Message-ID: Here's a more accurate (but still rough) timing application: import javafx.application.Application; import javafx.stage.Stage; import javafx.scene.Scene; import javafx.scene.control.*; import javafx.scene.layout.*; public class Main extends Application { private static long t1; private static long t2; private static long t3; private static long t4; public void start(Stage stage) { t2 = System.currentTimeMillis(); Label l1 = new Label("main: " + t1); Label l2 = new Label("start: " + (t2 - t1)); Label l3 = new Label(""); Label l4 = new Label(""); VBox vbox = new VBox(l1, l2, l3, l4); Scene scene = new Scene(vbox); stage.setScene(scene); stage.setTitle("Timing Demo"); stage.setOnShowing(e -> { t3 = System.currentTimeMillis(); l3.setText("showing: " + (t3 - t2) + ", " + (t3 - t1)); }); stage.setOnShown(e -> { t4 = System.currentTimeMillis(); l4.setText("shown: " + (t4 - t3) + ", " + (t4 - t1)); }); stage.show(); } public static void main(String[] args) { t1 = System.currentTimeMillis(); launch(args); } } The result of running it on my Dell laptop with Intel Core i7-6820HQ @2.70GHz,CPU and NVIDIA Quadro M1000M display adapter is attached: Essentially, it took less than half a second for a dead simple JavaFX Stage to be visible. Here's the timing number for 10 consecutive runs: 422, 440, 426, 442, 418, 441, 432, 444, 470, 453 -- Weiqi Gao weiqigao at gmail.com On Tue, Jun 5, 2018 at 10:46 AM, Scott Palmer wrote: > Yes, my only comment was that if we can get a window up using standard Java > GUI frameworks fast enough, then the complexity of adding splashscreen > support to the launcher isn't justified. > Mario's example shows that is it 1-2 seconds to get a window up. That is a > bit high. If it was under 1s then I would suggest not bothering, it isn't, > so keep it on the list of desired features. > > Scott > > On Tue, Jun 5, 2018 at 8:21 AM Pedro Duque Vieira < > pedro.duquevieira at gmail.com> wrote: > > > Sorry, perhaps it was I who misunderstood the debate.. > > > > On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus wrote: > > > > > Maybe I misunderstood the question but to my opinion the real question > is > > > whether the new java packager has to provide the support for a splash > > > screen > > > or not. This has nothing to do with the question whether applications > > > should > > > have a splash screen or not because if we find that todays Java is fast > > > enough > > > to display a simple window in less than a second or so, then the Java > GUI > > > (Swing or JavaFX) could provide a splash screen itself. There is then > no > > > need > > > for an additional mechanism provided my the packager. > > > > > > Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira: > > > > > > Hi, > > >> > > >> I agree with Johan and others, a splash screen is valuable and needed. > > >> > > >> Microsoft applications that run on Windows itself (think Word, Excel, > > >> etc), > > >> they have a splash screen, Intelllij has a splash screen (it's swing > > based > > >> AFAIK), etc.. If a Microsoft application running on its own operating > > >> system needs a splash screen then chances are pretty high that there > > will > > >> be Java apps that'll need a splash screen. > > >> > > >> Cheers, > > >> > > >> > > >> > > > > > > > > > -- > > Pedro Duque Vieira > > > -- Weiqi Gao (???) weiqigao at gmail.com http://weiqigao.blogspot.com/ From kevin.rushforth at oracle.com Tue Jun 5 17:16:21 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 5 Jun 2018 10:16:21 -0700 Subject: launching JavaFX in 11 In-Reply-To: References: Message-ID: Hi Johan, The intention is to launch using --module-path ??? java --module-path path-to-sdk/javafx-sdk-11/lib ... For non-modular applications you also need to add the modules to the module graph, for example: ??? java --module-path path-to-sdk/javafx-sdk-11/lib --add-modules javafx.fxml,javafx.controls ... You say that running an app from maven works fine. Have you verified that the jar files you publish to Maven include a module-info.class file in each modular jar? I suspect that many things could be made to work with javafx modules on the classpath instead of the module path, but I don't really recommend that. I suspect there will be a few things that won't work without some modifications. I think effort would be better spent getting everything to work with javafx.* modules as proper named modules. -- Kevin On 6/5/2018 6:40 AM, Johan Vos wrote: > Hi, > > I'm a bit confused on the different options for launching JavaFX > applications with the latest Java 11 code. > When running an app from maven, it worked fine. Maven uses the classpath > and not the module path, so I assumed that running the same app using > > java -cp all-javafx-jars Main > > would work too. But it doesn't. The error I got is this: > > Error: JavaFX runtime components are missing, and are required to run this > application > > This error comes from sun.launcher.LauncherHelper in the java.base module. > The reason for this is that the Main app extends Application and has a main > method. If that is the case, the LauncherHelper will check for the > javafx.graphics module to be present as a named module: > > Optional om = > ModuleLayer.boot().findModule(JAVAFX_GRAPHICS_MODULE_NAME); > > If that module is not present, the launch is aborted. > Hence, having the JavaFX libraries as jars on the classpath is not allowed > in this case. > > Fair, but that doesn't explain why it works via maven. The reason is that > maven doesn't start a new VM process, hence the main class is in this > case org.codehaus.plexus.classworlds.launcher.Launcher which does not > extend Application, hence it doesn't do the check on javafx.graphics module > to be present as a named module, and when the required jars (including > native code) are on the classpath, it works fine. > > I thought the check on the main class extending > javafx.application.Application was removed from the core JDK, but it is > still there, so I understand why it works using maven and fails using a > standalone java invocation. > > While I fully agree the goal is to have the JavaFX modules as named modules > on the module path, I think this will create confusion. A simple workaround > is to have a separate main class that doesn't extend Application, but that > seems a real dirty solution. > > But maybe I'm missing something? > > - Johan From mario at datenwort.at Tue Jun 5 17:53:36 2018 From: mario at datenwort.at (Mario Ivankovits) Date: Tue, 5 Jun 2018 17:53:36 +0000 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: References: <15b07de8-f94e-33c9-4d22-9db3cc7b54ec@jugs.org> Message-ID: <3E36B76B-81DE-4FB8-868F-B1EEC0DAF82A@datenwort.at> Hi! Just for the records: My test included the JVM startup time. Yours start counting in main() where the JVM is already up - and probably some of the classpath scanning already took place because of the inheritance from ?javafx.application.Application? . Your test shows ?showing: 298 shown: 468? on my machine. A ?native? splash screen usually should start up at the very first, before the JVM starts. Best regards, Mario > Am 05.06.2018 um 19:04 schrieb Weiqi Gao : > > Here's a more accurate (but still rough) timing application: > > import javafx.application.Application; > import javafx.stage.Stage; > import javafx.scene.Scene; > import javafx.scene.control.*; > import javafx.scene.layout.*; > > public class Main extends Application { > private static long t1; > private static long t2; > private static long t3; > private static long t4; > > public void start(Stage stage) { > t2 = System.currentTimeMillis(); > Label l1 = new Label("main: " + t1); > Label l2 = new Label("start: " + (t2 - t1)); > Label l3 = new Label(""); > Label l4 = new Label(""); > VBox vbox = new VBox(l1, l2, l3, l4); > Scene scene = new Scene(vbox); > stage.setScene(scene); > stage.setTitle("Timing Demo"); > stage.setOnShowing(e -> { > t3 = System.currentTimeMillis(); > l3.setText("showing: " + (t3 - t2) + ", " + (t3 - t1)); > }); > stage.setOnShown(e -> { > t4 = System.currentTimeMillis(); > l4.setText("shown: " + (t4 - t3) + ", " + (t4 - t1)); > }); > stage.show(); > } > > public static void main(String[] args) { > t1 = System.currentTimeMillis(); > launch(args); > } > } > > The result of running it on my Dell laptop with Intel Core i7-6820HQ > @2.70GHz,CPU and NVIDIA Quadro M1000M display adapter is attached: > > Essentially, it took less than half a second for a dead simple JavaFX Stage > to be visible. > > Here's the timing number for 10 consecutive runs: 422, 440, 426, 442, 418, > 441, 432, 444, 470, 453 > > -- > Weiqi Gao > weiqigao at gmail.com > > On Tue, Jun 5, 2018 at 10:46 AM, Scott Palmer wrote: > >> Yes, my only comment was that if we can get a window up using standard Java >> GUI frameworks fast enough, then the complexity of adding splashscreen >> support to the launcher isn't justified. >> Mario's example shows that is it 1-2 seconds to get a window up. That is a >> bit high. If it was under 1s then I would suggest not bothering, it isn't, >> so keep it on the list of desired features. >> >> Scott >> >> On Tue, Jun 5, 2018 at 8:21 AM Pedro Duque Vieira < >> pedro.duquevieira at gmail.com> wrote: >> >>> Sorry, perhaps it was I who misunderstood the debate.. >>> >>> On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus wrote: >>> >>>> Maybe I misunderstood the question but to my opinion the real question >> is >>>> whether the new java packager has to provide the support for a splash >>>> screen >>>> or not. This has nothing to do with the question whether applications >>>> should >>>> have a splash screen or not because if we find that todays Java is fast >>>> enough >>>> to display a simple window in less than a second or so, then the Java >> GUI >>>> (Swing or JavaFX) could provide a splash screen itself. There is then >> no >>>> need >>>> for an additional mechanism provided my the packager. >>>> >>>> Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira: >>>> >>>> Hi, >>>>> >>>>> I agree with Johan and others, a splash screen is valuable and needed. >>>>> >>>>> Microsoft applications that run on Windows itself (think Word, Excel, >>>>> etc), >>>>> they have a splash screen, Intelllij has a splash screen (it's swing >>> based >>>>> AFAIK), etc.. If a Microsoft application running on its own operating >>>>> system needs a splash screen then chances are pretty high that there >>> will >>>>> be Java apps that'll need a splash screen. >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Pedro Duque Vieira >>> >> > > > > -- > Weiqi Gao (???) > weiqigao at gmail.com > http://weiqigao.blogspot.com/ From weiqigao at gmail.com Tue Jun 5 19:17:46 2018 From: weiqigao at gmail.com (Weiqi Gao) Date: Tue, 5 Jun 2018 14:17:46 -0500 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: <3E36B76B-81DE-4FB8-868F-B1EEC0DAF82A@datenwort.at> References: <15b07de8-f94e-33c9-4d22-9db3cc7b54ec@jugs.org> <3E36B76B-81DE-4FB8-868F-B1EEC0DAF82A@datenwort.at> Message-ID: You are right. Here's an updated version of the app that take into account the time before Main::main() is invoked. import javafx.application.Application; import javafx.stage.Stage; import javafx.scene.Scene; import javafx.scene.control.*; import javafx.scene.layout.*; public class Main extends Application { private static long t0; private static long t1; private static long t2; private static long t3; private static long t4; public void start(Stage stage) { t2 = System.currentTimeMillis(); Label l0 = new Label("java: " + t0); Label l1 = new Label("main: " + (t1 - t0)); Label l2 = new Label("start: " + (t2 - t1) + ", " + (t2 - t0)); Label l3 = new Label(""); Label l4 = new Label(""); VBox vbox = new VBox(l0, l1, l2, l3, l4); Scene scene = new Scene(vbox); stage.setScene(scene); stage.setTitle("Timing Demo"); stage.setOnShowing(e -> { t3 = System.currentTimeMillis(); l3.setText("showing: " + (t3 - t2) + ", " + (t3 - t0)); }); stage.setOnShown(e -> { t4 = System.currentTimeMillis(); l4.setText("shown: " + (t4 - t3) + ", " + (t4 - t0)); }); stage.show(); } public static void main(String[] args) { t0 = Long.parseLong(args[0])/1000000; t1 = System.currentTimeMillis(); launch(args); } } Invoke it with the command line java Main `date +%s%N` This seems to add 500 milliseconds to the time. A screenshot is attached. If I go really minimalist and not do all the Labels, and print the numbers to the console instead, the number goes down to 750-800: 787, 782, 778, 790, 748, 747, 777, 775, 763, 785. Here's one of those invocations: $ java Main1 `date +%s%N` 1528225502595 494 519 658 785 Beat Regards, -- Weiqi Gao weiqigao at gmail.com On Tue, Jun 5, 2018 at 12:53 PM, Mario Ivankovits wrote: > Hi! > > Just for the records: My test included the JVM startup time. Yours start > counting in main() where the JVM is already up - and probably some of the > classpath scanning already took place because of the inheritance from > ?javafx.application.Application? . > Your test shows ?showing: 298 shown: 468? on my machine. > > A ?native? splash screen usually should start up at the very first, before > the JVM starts. > > > Best regards, > Mario > > > > Am 05.06.2018 um 19:04 schrieb Weiqi Gao : > > > > Here's a more accurate (but still rough) timing application: > > > > import javafx.application.Application; > > import javafx.stage.Stage; > > import javafx.scene.Scene; > > import javafx.scene.control.*; > > import javafx.scene.layout.*; > > > > public class Main extends Application { > > private static long t1; > > private static long t2; > > private static long t3; > > private static long t4; > > > > public void start(Stage stage) { > > t2 = System.currentTimeMillis(); > > Label l1 = new Label("main: " + t1); > > Label l2 = new Label("start: " + (t2 - t1)); > > Label l3 = new Label(""); > > Label l4 = new Label(""); > > VBox vbox = new VBox(l1, l2, l3, l4); > > Scene scene = new Scene(vbox); > > stage.setScene(scene); > > stage.setTitle("Timing Demo"); > > stage.setOnShowing(e -> { > > t3 = System.currentTimeMillis(); > > l3.setText("showing: " + (t3 - t2) + ", " + (t3 - t1)); > > }); > > stage.setOnShown(e -> { > > t4 = System.currentTimeMillis(); > > l4.setText("shown: " + (t4 - t3) + ", " + (t4 - t1)); > > }); > > stage.show(); > > } > > > > public static void main(String[] args) { > > t1 = System.currentTimeMillis(); > > launch(args); > > } > > } > > > > The result of running it on my Dell laptop with Intel Core i7-6820HQ > > @2.70GHz,CPU and NVIDIA Quadro M1000M display adapter is attached: > > > > Essentially, it took less than half a second for a dead simple JavaFX > Stage > > to be visible. > > > > Here's the timing number for 10 consecutive runs: 422, 440, 426, 442, > 418, > > 441, 432, 444, 470, 453 > > > > -- > > Weiqi Gao > > weiqigao at gmail.com > > > > On Tue, Jun 5, 2018 at 10:46 AM, Scott Palmer > wrote: > > > >> Yes, my only comment was that if we can get a window up using standard > Java > >> GUI frameworks fast enough, then the complexity of adding splashscreen > >> support to the launcher isn't justified. > >> Mario's example shows that is it 1-2 seconds to get a window up. That > is a > >> bit high. If it was under 1s then I would suggest not bothering, it > isn't, > >> so keep it on the list of desired features. > >> > >> Scott > >> > >> On Tue, Jun 5, 2018 at 8:21 AM Pedro Duque Vieira < > >> pedro.duquevieira at gmail.com> wrote: > >> > >>> Sorry, perhaps it was I who misunderstood the debate.. > >>> > >>> On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus wrote: > >>> > >>>> Maybe I misunderstood the question but to my opinion the real question > >> is > >>>> whether the new java packager has to provide the support for a splash > >>>> screen > >>>> or not. This has nothing to do with the question whether applications > >>>> should > >>>> have a splash screen or not because if we find that todays Java is > fast > >>>> enough > >>>> to display a simple window in less than a second or so, then the Java > >> GUI > >>>> (Swing or JavaFX) could provide a splash screen itself. There is then > >> no > >>>> need > >>>> for an additional mechanism provided my the packager. > >>>> > >>>> Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira: > >>>> > >>>> Hi, > >>>>> > >>>>> I agree with Johan and others, a splash screen is valuable and > needed. > >>>>> > >>>>> Microsoft applications that run on Windows itself (think Word, Excel, > >>>>> etc), > >>>>> they have a splash screen, Intelllij has a splash screen (it's swing > >>> based > >>>>> AFAIK), etc.. If a Microsoft application running on its own operating > >>>>> system needs a splash screen then chances are pretty high that there > >>> will > >>>>> be Java apps that'll need a splash screen. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> -- > >>> Pedro Duque Vieira > >>> > >> > > > > > > > > -- > > Weiqi Gao (???) > > weiqigao at gmail.com > > http://weiqigao.blogspot.com/ > > -- Weiqi Gao (???) weiqigao at gmail.com http://weiqigao.blogspot.com/ From johan.vos at gluonhq.com Wed Jun 6 06:57:34 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 6 Jun 2018 08:57:34 +0200 Subject: launching JavaFX in 11 In-Reply-To: References: Message-ID: I fully agree with you the way forward is using named modules. The reason I ran into this issue was that I wanted to create a regression test: it should not work if the modules are not on the module-path. And surprisingly, it did work. The current check in the Launcher is hiding potential issues. It will only check for a valid javafx.graphics module in case the supplied main class extends javafx.application.Application. This is something maven circumvents by default by using its own main class when starting the VM (rather then spawning a new process). As maven is probably the most commonly used tool for application development, this means by default the check in the Launcher won't work. I'm not worried about getting the named modules published, but my main worry is that tools like maven (I still have to check gradle 4.8) by default don't leverage modules. However, this might be more relevant on the jigsaw list? - Johan On Tue, Jun 5, 2018 at 7:26 PM Kevin Rushforth wrote: > Hi Johan, > > The intention is to launch using --module-path > > java --module-path path-to-sdk/javafx-sdk-11/lib ... > > For non-modular applications you also need to add the modules to the > module graph, for example: > > java --module-path path-to-sdk/javafx-sdk-11/lib --add-modules > javafx.fxml,javafx.controls ... > > You say that running an app from maven works fine. Have you verified > that the jar files you publish to Maven include a module-info.class file > in each modular jar? > > I suspect that many things could be made to work with javafx modules on > the classpath instead of the module path, but I don't really recommend > that. I suspect there will be a few things that won't work without some > modifications. I think effort would be better spent getting everything > to work with javafx.* modules as proper named modules. > > -- Kevin > > > On 6/5/2018 6:40 AM, Johan Vos wrote: > > Hi, > > > > I'm a bit confused on the different options for launching JavaFX > > applications with the latest Java 11 code. > > When running an app from maven, it worked fine. Maven uses the classpath > > and not the module path, so I assumed that running the same app using > > > > java -cp all-javafx-jars Main > > > > would work too. But it doesn't. The error I got is this: > > > > Error: JavaFX runtime components are missing, and are required to run > this > > application > > > > This error comes from sun.launcher.LauncherHelper in the java.base > module. > > The reason for this is that the Main app extends Application and has a > main > > method. If that is the case, the LauncherHelper will check for the > > javafx.graphics module to be present as a named module: > > > > Optional om = > > ModuleLayer.boot().findModule(JAVAFX_GRAPHICS_MODULE_NAME); > > > > If that module is not present, the launch is aborted. > > Hence, having the JavaFX libraries as jars on the classpath is not > allowed > > in this case. > > > > Fair, but that doesn't explain why it works via maven. The reason is that > > maven doesn't start a new VM process, hence the main class is in this > > case org.codehaus.plexus.classworlds.launcher.Launcher which does not > > extend Application, hence it doesn't do the check on javafx.graphics > module > > to be present as a named module, and when the required jars (including > > native code) are on the classpath, it works fine. > > > > I thought the check on the main class extending > > javafx.application.Application was removed from the core JDK, but it is > > still there, so I understand why it works using maven and fails using a > > standalone java invocation. > > > > While I fully agree the goal is to have the JavaFX modules as named > modules > > on the module path, I think this will create confusion. A simple > workaround > > is to have a separate main class that doesn't extend Application, but > that > > seems a real dirty solution. > > > > But maybe I'm missing something? > > > > - Johan > > From tom.schindl at bestsolution.at Wed Jun 6 08:20:34 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 6 Jun 2018 10:20:34 +0200 Subject: Chance of Backporting Gtk3 Support to JavaFX 8 Message-ID: <57e7b661-9171-da25-613a-9de9d7b46f12@bestsolution.at> Hi, Eclipse SWT developers are about to remove Gtk2-SWT port once they start developing towards support for Gtk4. This means there's no SWT-FX-Integration layer anymore for JavaFX8 because it is linked to Gtk2. I know JavaFX-8 is not the new and shining thing because everyone wants to use modules and Java 11 but there are many applications who can not easily to Java 9+. Is there any chance the Gtk3 changes from JavaFX-9 get backported to JavaFX-8? Tom From Thorsten_Fischer at gmx.de Wed Jun 6 09:03:51 2018 From: Thorsten_Fischer at gmx.de (Thorsten Fischer) Date: Wed, 6 Jun 2018 11:03:51 +0200 Subject: Aw: Chance of Backporting Gtk3 Support to JavaFX 8 In-Reply-To: <57e7b661-9171-da25-613a-9de9d7b46f12@bestsolution.at> References: <57e7b661-9171-da25-613a-9de9d7b46f12@bestsolution.at> Message-ID: From tom.schindl at bestsolution.at Wed Jun 6 09:12:17 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 6 Jun 2018 11:12:17 +0200 Subject: Aw: Chance of Backporting Gtk3 Support to JavaFX 8 In-Reply-To: References: <57e7b661-9171-da25-613a-9de9d7b46f12@bestsolution.at> Message-ID: Hi, Yes. FXCanvas from JavaFX8 won't work anymore once SWT-Gtk2 is gone. The discussion on this currently happens at [platform-dev] mailing list - see https://dev.eclipse.org/mhonarc/lists/platform-dev/ - There's no timeframe mentionned yet by the SWT-Team but sooner or later that will happen. Tom On 06.06.18 11:03, Thorsten Fischer wrote: > Hello Tom, > ? > does that mean that FXCanvas won't work with upcoming Eclipse versions > and JavaFX8? > ? > Do you know in which timeframe/release that my occur? Is that issue > discussed in the eclipse bugtracker somewhere? I couldn't find it by > searching for "gtk4". > ? > Kind regards, > Thorsten > ? > *Gesendet:*?Mittwoch, 06. Juni 2018 um 10:20 Uhr > *Von:*?"Tom Schindl" > *An:*?"openjfx-dev at openjdk.java.net Mailing" > *Betreff:*?Chance of Backporting Gtk3 Support to JavaFX 8 > Hi, > > Eclipse SWT developers are about to remove Gtk2-SWT port once they start > developing towards support for Gtk4. > > This means there's no SWT-FX-Integration layer anymore for JavaFX8 > because it is linked to Gtk2. > > I know JavaFX-8 is not the new and shining thing because everyone wants > to use modules and Java 11 but there are many applications who can not > easily to Java 9+. > > Is there any chance the Gtk3 changes from JavaFX-9 get backported to > JavaFX-8? > > Tom From Thorsten_Fischer at gmx.de Wed Jun 6 09:13:18 2018 From: Thorsten_Fischer at gmx.de (Thorsten Fischer) Date: Wed, 6 Jun 2018 11:13:18 +0200 Subject: Chance of Backporting Gtk3 Support to JavaFX 8 In-Reply-To: <57e7b661-9171-da25-613a-9de9d7b46f12@bestsolution.at> References: <57e7b661-9171-da25-613a-9de9d7b46f12@bestsolution.at> Message-ID: From kevin.rushforth at oracle.com Wed Jun 6 11:53:57 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 6 Jun 2018 04:53:57 -0700 Subject: Chance of Backporting Gtk3 Support to JavaFX 8 In-Reply-To: <57e7b661-9171-da25-613a-9de9d7b46f12@bestsolution.at> References: <57e7b661-9171-da25-613a-9de9d7b46f12@bestsolution.at> Message-ID: Hi Tom, Yes, changes such as this, which are needed for platform support, are good candidates for backporting. Not sure about the time frame, but we are looking into it with our sustaining team. -- Kevin On 6/6/2018 1:20 AM, Tom Schindl wrote: > Hi, > > Eclipse SWT developers are about to remove Gtk2-SWT port once they start > developing towards support for Gtk4. > > This means there's no SWT-FX-Integration layer anymore for JavaFX8 > because it is linked to Gtk2. > > I know JavaFX-8 is not the new and shining thing because everyone wants > to use modules and Java 11 but there are many applications who can not > easily to Java 9+. > > Is there any chance the Gtk3 changes from JavaFX-9 get backported to > JavaFX-8? > > Tom From johan.vos at gluonhq.com Wed Jun 6 15:23:00 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 6 Jun 2018 17:23:00 +0200 Subject: Chance of Backporting Gtk3 Support to JavaFX 8 In-Reply-To: <57e7b661-9171-da25-613a-9de9d7b46f12@bestsolution.at> References: <57e7b661-9171-da25-613a-9de9d7b46f12@bestsolution.at> Message-ID: That sounds very reasonable to me. [disclaimer: I had to build JavaFX with GTK3 already as I ran into issues on a new system ;) ] - Johan On Wed, Jun 6, 2018 at 10:31 AM Tom Schindl wrote: > Hi, > > Eclipse SWT developers are about to remove Gtk2-SWT port once they start > developing towards support for Gtk4. > > This means there's no SWT-FX-Integration layer anymore for JavaFX8 > because it is linked to Gtk2. > > I know JavaFX-8 is not the new and shining thing because everyone wants > to use modules and Java 11 but there are many applications who can not > easily to Java 9+. > > Is there any chance the Gtk3 changes from JavaFX-9 get backported to > JavaFX-8? > > Tom > From kevin.rushforth at oracle.com Wed Jun 6 18:00:07 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 6 Jun 2018 11:00:07 -0700 Subject: GitHub review for JDK-8201553: Update FX build to use gradle 4.8 Message-ID: Hi Phil & Johan, I have initiated a pull request on GitHub as a review for: JBS: https://bugs.openjdk.java.net/browse/JDK-8201553 PR: https://github.com/javafxports/openjdk-jfx/pull/92 It is now ready to be reviewed, and once the review is done, merged into the develop branch of the GitHub sandbox. I'm doing it there first to ensure that the CI builds pass with gradle 4.8 (which they do, as can be seen from the PR). -- Kevin From kevin.rushforth at oracle.com Thu Jun 7 13:43:59 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 7 Jun 2018 06:43:59 -0700 Subject: GitHub review for JDK-8201553: Update FX build to use gradle 4.8 In-Reply-To: References: Message-ID: <597a0e4e-8463-97a9-fb8c-153556282aa9@oracle.com> This PR has been merged into the develop branch on GitHub. Since it has been reviewed by Phil and Johan, I plan to push it to jfx-dev/rt later today. I made a webrev for completeness. JBS: https://bugs.openjdk.java.net/browse/JDK-8201553 Webrev: http://cr.openjdk.java.net/~kcr/8201553/webrev/ GitHub commit: https://github.com/javafxports/openjdk-jfx/commit/04dc51b698347ce53420777abff4b2c472e45d32 -- Kevin On 6/6/2018 11:00 AM, Kevin Rushforth wrote: > Hi Phil & Johan, > > I have initiated a pull request on GitHub as a review for: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8201553 > PR: https://github.com/javafxports/openjdk-jfx/pull/92 > > It is now ready to be reviewed, and once the review is done, merged > into the develop branch of the GitHub sandbox. I'm doing it there > first to ensure that the CI builds pass with gradle 4.8 (which they > do, as can be seen from the PR). > > -- Kevin > From pankaj.b.bansal at oracle.com Thu Jun 7 19:57:28 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Thu, 7 Jun 2018 12:57:28 -0700 (PDT) Subject: [11] JDK-8196031: FX Robot mouseMove fails on Windows 10 1709 with HiDPI Message-ID: <78e02cf0-cf99-443b-ab6b-e38b0879f95b@default> Hi Kevin & Murali, Please review this fix, Webrev: http://cr.openjdk.java.net/~pbansal/8196031/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8196031 Regards, Pankaj From alexander.matveev at oracle.com Thu Jun 7 23:49:39 2018 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 7 Jun 2018 16:49:39 -0700 Subject: [11] Review request for 8202393: App Transport Security blocks http media on macOS with JDK build using new compilers Message-ID: <0d1d4359-b24a-ce50-efa8-184e123611e0@oracle.com> Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8202393 Added exception to allow HTTP protocol in AVFoundation when building with SDK 10.11. Thanks, Alexander From bourges.laurent at gmail.com Fri Jun 8 14:28:57 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 8 Jun 2018 16:28:57 +0200 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 Message-ID: Hi, Please review this large patch to upgrade MarlinFX to 0.9.2 in OpenJFX11: JBS: https://bugs.openjdk.java.net/browse/JDK-8198885 webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.0/ PR: https://github.com/javafxports/openjdk-jfx/pull/96 (CI OK) This patch is almost identical to Marlin(2D) patch, see: https://bugs.openjdk.java.net/browse/JDK-8198885 I added the ClipShapeTest (ported to jfx) that compares shape clipping (within threshold) and it works (within large timeouts): gradle -PFULL_TEST=true :system:test --tests test.com.sun.marlin.ClipShapeTest Regards, Laurent From kevin.rushforth at oracle.com Fri Jun 8 19:45:21 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 8 Jun 2018 12:45:21 -0700 Subject: [11] JDK-8196031: FX Robot mouseMove fails on Windows 10 1709 with HiDPI In-Reply-To: <78e02cf0-cf99-443b-ab6b-e38b0879f95b@default> References: <78e02cf0-cf99-443b-ab6b-e38b0879f95b@default> Message-ID: The fix works for me, but I have a couple comment on the implementation and a couple more on the test: 1. You borrowed the following from the Java2D fix: ??? + signum((int)fx); ??? + signum((int)fy); This effectively does a rounding in the normalized absolute coordinate space use by the Windows mouse move request. Given that we already round the values in the unscaled (FX) space before the conversion, I don't think this is necessary or desirable. I recommend removing it (and you can remove the function entirely, since it was added just for this). 2. One other difference between this and the 2D fix is that the FX fix uses 65535 (which was in my initial prototype), whereas the 2D fix uses 65536. The latter is probably more accurate, so you might want to change it to 65536. Test comments: 3. I recommend using Util.runAndWait rather than runLater with your own latch everywhere. That method also propagates exceptions so you can do an assertEquals right in that block rather than saving a "mismatch" flag. You will get a better error message that way since you will see the actual and expected values in the assertions rather than having to look at the log (or run with --info) to see them. 4. Since you are using a for loop with increment by 1 in cross and edge, it might be better to use "int"s for those params after all (sorry for leading you astray on this one earlier). 5. Minor: we usually use 20 seconds for test timeouts, and this is a short-running test, so maybe switch to that? (it's up to you) -- Kevin On 6/7/2018 12:57 PM, Pankaj Bansal wrote: > Hi Kevin & Murali, > > > > Please review this fix, > > Webrev: http://cr.openjdk.java.net/~pbansal/8196031/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8196031 > > > > > > Regards, > > Pankaj > > From kevin.rushforth at oracle.com Fri Jun 8 20:33:55 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 8 Jun 2018 13:33:55 -0700 Subject: [11] Review request: 8203801: Missing Classpath exception in PrismLoaderGlue.stg file Message-ID: <9a072f46-7a30-9e39-618a-391c34aa2dbf@oracle.com> Phil, Please review the following to fix up the copyright header: https://bugs.openjdk.java.net/browse/JDK-8203801 http://cr.openjdk.java.net/~kcr/8203801/webrev/ -- Kevin From guy.abossolo.foh at scientificware.com Sat Jun 9 06:55:10 2018 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Sat, 09 Jun 2018 08:55:10 +0200 Subject: JDK-8147476 Rendering issues with MathML token elements (Message for Murali Billa) Message-ID: Hi, May be you are working to change webkit version. I finally found what's wrong with MathML lines overlapping. In fact MathML needs platformBoundsForGlyph implementation in FontJava.cpp. https://github.com/javafxports/openjdk-jfx/issues/71 With patchs describe in this and previous message, fraction numerator and denominator like matrix lines are in there right positions. But that's not solve all problems, but it's a great progress. The remaining problem seems to be a ascent and descent Glyph, I'm still working on it. Yours faithfully. ----------------------------------------------------------------------- Hello, Thanks a lot for your answer. "If you are interested in seeing that this bug get fixed sooner, then I might suggest that you consider contributing a fix for this bug youself." I already contributed to openjdk specific bugs for the same reasons you give me. An issue in the swing/text package. My patch was posted in 2012 and accepted in 2017 for JDK9. It hasn't been a great experience for me. I'm working on Math notation support in swing/text package. And the day that I also try to work with JavaFx ... the MathML support is broken ! I'm really interested in seeing this bug fixed. That's why, I first contacted F. Wang from Igalia who worked on MathML integration in WebKit because I thought that it was a WebKit issue. But he answered me that it's probably a bug in OpenJFX because in others WebKit based applications, all works fine. He suggested me to post a bug report. Thus I made a look to the bug database and discovered that it's an old issue. This issue doesn't disappear with the new WebKit version in JavaFX. And now, I'm trying to contact Murali to know what I can expect in the future releases. I would be happy and proud to fix this issue but there is no documentation about WebKit integration in OpenJFX. I hope Murali will add a coment about he plans to look at this. Yours faithfully. ----------------------------------------------------------------------- Le 2017-12-09 15:10, Kevin Rushforth a ?crit : Hi, A fix version of 'tbd_major' means the bug is in our backlog and is not yet targeted for a specific release. There is no need to file another bug report, and doing so will not get it looked at any sooner. Murali can comment as to whether he plans to look at this in the near term or not. If you are interested in seeing that this bug get fixed sooner, then I might suggest that you consider contributing a fix for this bug youself [1]. -- Kevin [1] http://openjdk.java.net/contribute/ Abossolo Foh Guy wrote: Hello, Could you inform me about the resolution of the (JDK-8147476) rendering issues with MathML token elements. I don't understand what means the marker value "for a to-be-determined major release". In other words, what is the process to determine this major release with the new release plan ? Do I need to post another bug report or are you still working on it ? Best regards. --------------------------------------------------------------------------- Hello, About the comment in JDK-8147476 : * First, I tested webkit with Safari on OSX and IOS last versions in an Apple Store and with my Ipod. The screen captures confirm F. Wang (igalia) conclusion about the status of WebKit (Removed for the list). The display is pretty good. I tested these applications with Mozilla MathML Torture Test (https://developer.mozilla.org/fr/docs/Mozilla/MathML_Project/MathML_Torture_Test) and the link posted in the bug report . * Secondly : About Chrome, MathML support in Chrome is in progress : May 2017 : https://twitter.com/regocas/status/869871891628126209 Novembre 2017 : https://mathml.igalia.com/ It seems that Google and Igalia had reached an agreement. * Thirdly : Who knows that JavaFX support MathML since 2015. No reference in your documentation and in the MathML w3c website (Software section). Best regards. From guy.abossolo.foh at scientificware.com Sat Jun 9 11:51:03 2018 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Sat, 09 Jun 2018 13:51:03 +0200 Subject: JDK-8147476 Rendering issues with MathML token elements (Message for Murali Billa) Message-ID: <443438aa518ee5c15854f38c41418e2c@scientificware.com> Hi, Improvements : - MathML rows are no more truncated. - Cursor display to his right size, I can select and edit . - Fraction display is pretty good. - Matrix element positions display is pretty good (except delimiters). https://github.com/javafxports/openjdk-jfx/issues/71 Modified files : - FontJava.cpp - WCFontImpl.java - WCFont.java - FontJava.cpp - WCFontPerfLogger.java Is it possible that you can include such modifications to the next webkit version ? I know all problems are not solved but the rendering is far better than the present implementation. May be you have acces to previous implementation of these classes, before JavaFX was opensourced and compare changes I suggest with previous implementations. Any suggestions are welcome. Best regards. ------------------------------------------------------------------------ Hi, May be you are working to change webkit version. I finally found what's wrong with MathML lines overlapping. In fact MathML needs platformBoundsForGlyph implementation in FontJava.cpp. https://github.com/javafxports/openjdk-jfx/issues/71 With patchs describe in this and previous message, fraction numerator and denominator like matrix lines are in there right positions. But that's not solve all problems, but it's a great progress. The remaining problem seems to be a ascent and descent Glyph, I'm still working on it. Yours faithfully. ----------------------------------------------------------------------- Hello, Thanks a lot for your answer. "If you are interested in seeing that this bug get fixed sooner, then I might suggest that you consider contributing a fix for this bug youself." I already contributed to openjdk specific bugs for the same reasons you give me. An issue in the swing/text package. My patch was posted in 2012 and accepted in 2017 for JDK9. It hasn't been a great experience for me. I'm working on Math notation support in swing/text package. And the day that I also try to work with JavaFx ... the MathML support is broken ! I'm really interested in seeing this bug fixed. That's why, I first contacted F. Wang from Igalia who worked on MathML integration in WebKit because I thought that it was a WebKit issue. But he answered me that it's probably a bug in OpenJFX because in others WebKit based applications, all works fine. He suggested me to post a bug report. Thus I made a look to the bug database and discovered that it's an old issue. This issue doesn't disappear with the new WebKit version in JavaFX. And now, I'm trying to contact Murali to know what I can expect in the future releases. I would be happy and proud to fix this issue but there is no documentation about WebKit integration in OpenJFX. I hope Murali will add a coment about he plans to look at this. Yours faithfully. ----------------------------------------------------------------------- Le 2017-12-09 15:10, Kevin Rushforth a ?crit : Hi, A fix version of 'tbd_major' means the bug is in our backlog and is not yet targeted for a specific release. There is no need to file another bug report, and doing so will not get it looked at any sooner. Murali can comment as to whether he plans to look at this in the near term or not. If you are interested in seeing that this bug get fixed sooner, then I might suggest that you consider contributing a fix for this bug youself [1]. -- Kevin [1] http://openjdk.java.net/contribute/ Abossolo Foh Guy wrote: Hello, Could you inform me about the resolution of the (JDK-8147476) rendering issues with MathML token elements. I don't understand what means the marker value "for a to-be-determined major release". In other words, what is the process to determine this major release with the new release plan ? Do I need to post another bug report or are you still working on it ? Best regards. --------------------------------------------------------------------------- Hello, About the comment in JDK-8147476 : * First, I tested webkit with Safari on OSX and IOS last versions in an Apple Store and with my Ipod. The screen captures confirm F. Wang (igalia) conclusion about the status of WebKit (Removed for the list). The display is pretty good. I tested these applications with Mozilla MathML Torture Test (https://developer.mozilla.org/fr/docs/Mozilla/MathML_Project/MathML_Torture_Test) and the link posted in the bug report . * Secondly : About Chrome, MathML support in Chrome is in progress : May 2017 : https://twitter.com/regocas/status/869871891628126209 Novembre 2017 : https://mathml.igalia.com/ It seems that Google and Igalia had reached an agreement. * Thirdly : Who knows that JavaFX support MathML since 2015. No reference in your documentation and in the MathML w3c website (Software section). Best regards. From pankaj.b.bansal at oracle.com Mon Jun 11 08:48:57 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 11 Jun 2018 01:48:57 -0700 (PDT) Subject: [11] JDK-8196031: FX Robot mouseMove fails on Windows 10 1709 with HiDPI In-Reply-To: References: <78e02cf0-cf99-443b-ab6b-e38b0879f95b@default> Message-ID: <170b3ea8-a0bf-4811-9626-a2589be40195@default> Hello Kevin, Thanks for the review. I have incorporated all the review comments. Please have a look. webrev: http://cr.openjdk.java.net/~pbansal/8196031/webrev.01/ Regards, Pankaj Bansal -----Original Message----- From: Kevin Rushforth Sent: Saturday, June 9, 2018 1:15 AM To: Pankaj Bansal; openjfx-dev at openjdk.java.net Subject: Re: [11] JDK-8196031: FX Robot mouseMove fails on Windows 10 1709 with HiDPI The fix works for me, but I have a couple comment on the implementation and a couple more on the test: 1. You borrowed the following from the Java2D fix: ??? + signum((int)fx); ??? + signum((int)fy); This effectively does a rounding in the normalized absolute coordinate space use by the Windows mouse move request. Given that we already round the values in the unscaled (FX) space before the conversion, I don't think this is necessary or desirable. I recommend removing it (and you can remove the function entirely, since it was added just for this). 2. One other difference between this and the 2D fix is that the FX fix uses 65535 (which was in my initial prototype), whereas the 2D fix uses 65536. The latter is probably more accurate, so you might want to change it to 65536. Test comments: 3. I recommend using Util.runAndWait rather than runLater with your own latch everywhere. That method also propagates exceptions so you can do an assertEquals right in that block rather than saving a "mismatch" flag. You will get a better error message that way since you will see the actual and expected values in the assertions rather than having to look at the log (or run with --info) to see them. 4. Since you are using a for loop with increment by 1 in cross and edge, it might be better to use "int"s for those params after all (sorry for leading you astray on this one earlier). 5. Minor: we usually use 20 seconds for test timeouts, and this is a short-running test, so maybe switch to that? (it's up to you) -- Kevin On 6/7/2018 12:57 PM, Pankaj Bansal wrote: > Hi Kevin & Murali, > > > > Please review this fix, > > Webrev: > http://cr.openjdk.java.net/~pbansal/8196031/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8196031 > > > > > > Regards, > > Pankaj > > From Rony.Flatscher at wu.ac.at Mon Jun 11 16:23:40 2018 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 11 Jun 2018 18:23:40 +0200 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> Message-ID: <4d6f9586-8372-f1f7-ca62-56eea9808e03@wu.ac.at> On 31.05.2018 02:11, Kevin Rushforth wrote: > I just sent an email to the core-libs-dev alias [1] proposing a new Packaging Tool as a > replacement for javapackager. If you are interested in this JEP, you can follow and participate in > the discussion there. > > -- Kevin > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html > One feature that might not be on the radar for pure Java solution providers is having an option to start up a JavaFX application from any javax.script (aka JSR-223) scripting language. In this case it should be possible to supply the script's file name. ---rony From kevin.rushforth at oracle.com Mon Jun 11 23:26:46 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 11 Jun 2018 16:26:46 -0700 Subject: [11] JDK-8196031: FX Robot mouseMove fails on Windows 10 1709 with HiDPI In-Reply-To: <170b3ea8-a0bf-4811-9626-a2589be40195@default> References: <78e02cf0-cf99-443b-ab6b-e38b0879f95b@default> <170b3ea8-a0bf-4811-9626-a2589be40195@default> Message-ID: Looks good. +1 -- Kevin On 6/11/2018 1:48 AM, Pankaj Bansal wrote: > Hello Kevin, > > Thanks for the review. > > I have incorporated all the review comments. Please have a look. > webrev: http://cr.openjdk.java.net/~pbansal/8196031/webrev.01/ > > Regards, > Pankaj Bansal > > -----Original Message----- > From: Kevin Rushforth > Sent: Saturday, June 9, 2018 1:15 AM > To: Pankaj Bansal; openjfx-dev at openjdk.java.net > Subject: Re: [11] JDK-8196031: FX Robot mouseMove fails on Windows 10 1709 with HiDPI > > The fix works for me, but I have a couple comment on the implementation and a couple more on the test: > > 1. You borrowed the following from the Java2D fix: > > ??? + signum((int)fx); > ??? + signum((int)fy); > > This effectively does a rounding in the normalized absolute coordinate space use by the Windows mouse move request. Given that we already round the values in the unscaled (FX) space before the conversion, I don't think this is necessary or desirable. I recommend removing it (and you can remove the function entirely, since it was added just for this). > > 2. One other difference between this and the 2D fix is that the FX fix uses 65535 (which was in my initial prototype), whereas the 2D fix uses 65536. The latter is probably more accurate, so you might want to change it to 65536. > > Test comments: > > 3. I recommend using Util.runAndWait rather than runLater with your own latch everywhere. That method also propagates exceptions so you can do an assertEquals right in that block rather than saving a "mismatch" > flag. You will get a better error message that way since you will see the actual and expected values in the assertions rather than having to look at the log (or run with --info) to see them. > > 4. Since you are using a for loop with increment by 1 in cross and edge, it might be better to use "int"s for those params after all (sorry for leading you astray on this one earlier). > > 5. Minor: we usually use 20 seconds for test timeouts, and this is a short-running test, so maybe switch to that? (it's up to you) > > -- Kevin > > > On 6/7/2018 12:57 PM, Pankaj Bansal wrote: >> Hi Kevin & Murali, >> >> >> >> Please review this fix, >> >> Webrev: >> http://cr.openjdk.java.net/~pbansal/8196031/webrev.00/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8196031 >> >> >> >> >> >> Regards, >> >> Pankaj >> >> From philip.race at oracle.com Tue Jun 12 20:55:09 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Jun 2018 13:55:09 -0700 Subject: OpenJFX code review policies, etc. In-Reply-To: <8ff76719-31ad-e515-d3c0-691085103a28@oracle.com> References: <8ff76719-31ad-e515-d3c0-691085103a28@oracle.com> Message-ID: <81d8cfcd-42aa-e2c2-5db3-8e6029717369@oracle.com> One other point .. something I mentioned off line to Kevin but he did not so far bring up here, is that when counting the number of reviewers on a fix, we must require at least one Reviewer, with a capital "R", but to make up the total of 2 reviewers, it is sufficient to have one other person who only has committer status .. or even author status (maybe), be the second reviewer. We've used this policy on the JDK AWT/2D/Swing stack for a long time. It not only frees up the scarce "R"eviewers, but it helps train new ones :-), whilst still ensuring at least two sets of eye balls were on it. -phil. On 05/24/2018 10:36 AM, Kevin Rushforth wrote: > Phil pointed out one glaring typo in the summary and also a couple > things in the details that could be clarified. > >> The short version of the proposal is: >> ... >> 2. Revised code review policies for different types of changes: >> simple, low-impact fixes (1 Reviewer); higher-impact fixes (2 >> Reviewers + allow time for others to chime in); Features / API >> changes (CSR approval, including approval by a "lead", plus 3 >> Reviewers for the code) >> > > That last been should be: CSR approval, including approval by a > "lead", plus *2* Reviewers for the code. I had it right in the > details, but made a typo in the short version. While some reviews > might have more than 2, it was certainly not my intent to mandate it. > >> A. Low-impact bug fixes. ... >> One reviewer is sufficient to accept such changes. As a courtesy, and >> to avoid changes which later might need to be backed out, if you >> think there might be some concern or objection to the change, please >> give sufficient time for folks who might be in other time zones the >> chance to take a look. This should be left up to the judgment of the >> reviewer who approves it as well as the contributor. > > To clarify, the intent is to avoid pushing changes that might be > controversial, and not to mandate unnecessary delay for truly simple > fixes (e.g., fixing a build break). Reviewers and Committers are > expected to use their best judgment here. > >> C. New features / API additions. This includes behavioral changes, >> additions to the fxml or css spec, etc. >> >> ... a New Feature, API addition, or behavioral change must be >> reviewed / approved by a "lead". Currently this is either myself or >> Johan Vos as indicated above. >> >> I also propose that we continue to use the CSR process [3] to track >> such changes. The CSR chair has indicated that he is willing to track >> JavaFX compatibility changes even though FX is no longer a part of >> the JDK. > > The "approval by lead" means approving the API / feature change via > the CSR. A "lead" often will be one of the code reviewers as well, but > need not be as long as they approve the API change itself via the CSR. > > -- Kevin > > > On 5/23/2018 3:16 PM, Kevin Rushforth wrote: >> To: OpenJFX Developers >> >> As I mentioned in a message last week [1] I would like to restart the >> discussion we started a few months ago [2] around making it easier to >> contribute code to OpenJFX. To this end, I like to make some concrete >> proposals around code review / API review policies. >> >> Before getting to the details, I would like to acknowledge Gluon's >> contributions to the OpenJFX project, specifically those of Johan >> Vos. I am pleased to announce an expanded role for Johan Vos in the >> OpenJFX project. I would like to announce that starting now, Johan is >> effectively a co-lead for the purposes of setting direction, and >> approving new features for the Project. >> >> The short version of the proposal is: >> >> 1. Formalize the concept of Reviewers with an initial list of >> Reviewers and a defined criteria for adding additional Reviewers. >> >> 2. Revised code review policies for different types of changes: >> simple, low-impact fixes (1 Reviewer); higher-impact fixes (2 >> Reviewers + allow time for others to chime in); Features / API >> changes (CSR approval, including approval by a "lead", plus 3 >> Reviewers for the code) >> >> 3. Streamlining reviews of changes developed in the GitHub sandbox: >> provided that the review policy is followed to before a PR is merged >> into the develop branch in GitHub, a fast-track review can happen >> pointing to the changeset that was merged and the PR, which has >> review comments. >> >> Details follow. >> >> Quoting from my earlier message: >> >>> "Code reviews are important to maintain high-quality contributions, >>> but we recognize that not every type of change needs the same level >>> of review. Without lowering our standards of quality, we want to >>> make it easier to get low-impact changes (simple bug fixes) accepted." >> >> To that end, I propose the following policies. Many of these will >> involve judgment calls, especially when it comes to deciding whether >> a fix is low impact vs. high-impact. I think that's OK. It doesn't >> have to be perfect. >> >> Recommendations >> >> 1. I recommend that we formalize the concept of Reviewers, using the >> OpenJDK Reviewer role for the OpenJFX Project. >> >> A. I will provide an initial list of reviewers to the registrar based >> on past contributions, and also recognizing Committers who have >> become experts in their area. This is the only time we will have such >> latitude as the OpenJDK Bylaws specify the policy we need to follow >> for nominating and voting upon additional Reviewers. >> >> B. We need to set formal guidelines for becoming a Reviewer. The JDK >> uses a threshold of 32 significant contributions. While we don't want >> to relax it too much, one thing I have been discussing informally >> with a few people is that a Committer with, say, 24 commits, who >> regularly participates in reviews, offering good feedback, might be >> just a good a reviewer (maybe even better) than someone with 32 >> commits who rarely, if ever, provides feedback on proposed bug fixes. >> I'm open for suggestions here. >> >> One thing I'd like to add is that we expect Reviewers to feel >> responsible not just for their piece, but for the quality of the >> JavaFX library as a whole. I might work with some folks at Gluon and >> here at Oracle to draft a set of expectations for reviewers. >> >> >> 2. Code review policies >> >> All code reviews must be posted on the openjfx-dev mailing list -- >> even simple fixes. I propose that we have the following code review >> policies for different types of changes. I also note that if there is >> disagreement as to whether a fix is low-impact or high-impact, then >> it is considered high-impact. In other words we will always err on >> the side of quality by "rounding up" to the next higher category. The >> contributor can say whether they think something is low-impact or >> high-impact, but It is up to a Reviewer to initially decide this. >> >> A. Low-impact bug fixes. These are typically isolated bug fixes with >> little or no impact beyond fixing the bug in question; included in >> this category are test fixes (including new tests), doc fixes, and >> fixes to sample applications (including new samples). >> >> One reviewer is sufficient to accept such changes. As a courtesy, and >> to avoid changes which later might need to be backed out, if you >> think there might be some concern or objection to the change, please >> give sufficient time for folks who might be in other time zones the >> chance to take a look. This should be left up to the judgment of the >> reviewer who approves it as well as the contributor. >> >> B. Higher impact bug fixes or RFEs. These include changes to the >> implementation that potentially have a performance or behavioral >> impact, or are otherwise broad in scope. Some larger bug fixes will >> fall into this category, as will fixes in high-risk areas (e.g., CSS). >> >> Two reviewers must approve to accept such changes. Additionally, the >> review should allow sufficient time for folks who might be in other >> time zones the chance to review if they have concerns. >> >> C. New features / API additions. This includes behavioral changes, >> additions to the fxml or css spec, etc. >> >> Feature requests come with a responsibility beyond just saying "here >> is the code for this cool new feature, please take it". There are >> many factors to consider for even small features. Larger features >> will need a significant contribution in terms of API design, coding, >> testing, maintainability, etc. >> >> To ensure that new features are consistent with the rest of the API >> and the desired direction of the Project, I propose that a New >> Feature, API addition, or behavioral change must be reviewed / >> approved by a "lead". Currently this is either myself or Johan Vos as >> indicated above. >> >> I also propose that we continue to use the CSR process [3] to track >> such changes. The CSR chair has indicated that he is willing to track >> JavaFX compatibility changes even though FX is no longer a part of >> the JDK. >> >> For the review of the implementation, I propose that we use the same >> "two reviewer" standard for the code changes as category B. >> >> >> 3. Streamlining the review process for changes developed on GitHub >> >> A fix that was developed as pull-requests (PRs) on GitHub is eligible >> for a fast-track review, if: >> >> A. The PR was squashed / merged into the develop branch as a single >> changeset >> B. No follow-on changesets were merged into develop as part of that >> same fix >> C. The changeset is "whitespace clean" -- meaning that you have run >> 'tools/scripts/checkWhiteSpace' on the final changeset (we might want >> to add this to the CI build). >> and >> D. All code review policies outlined above in #2 were followed prior >> to the PR being approved and merged into the develop branch on >> GitHub. This includes sending email to openjfx-dev when you first >> make a PR that you intend to have merged into the develop branch to >> give other reviewers who may not be watching all PRs a chance to >> comment before it is merged. >> >> A "fast-track" review is a quick sanity check before the change is >> committed and pushed to the jfx-dev repo on hg.openjdk.java.net. This >> fast track review just needs to point to the GitHub changeset that >> was merged and to the PR, which will have any review comments. If >> there are no compelling reasons why the PR can't be pushed to >> jfx-dev, then it can be pushed. >> >> >> Please let me know your thoughts on the above proposals. >> >> Thank you all for being a part of this community. >> >> -- Kevin Rushforth, OpenJFX Project Lead >> >> [1] >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021867.html >> >> [2] >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021335.html >> >> [3] https://wiki.openjdk.java.net/display/csr/Main >> > From kevin.rushforth at oracle.com Tue Jun 12 21:10:11 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 12 Jun 2018 14:10:11 -0700 Subject: OpenJFX code review policies, etc. In-Reply-To: <81d8cfcd-42aa-e2c2-5db3-8e6029717369@oracle.com> References: <8ff76719-31ad-e515-d3c0-691085103a28@oracle.com> <81d8cfcd-42aa-e2c2-5db3-8e6029717369@oracle.com> Message-ID: Yes, that is an important clarification of the new policy. Thanks. -- Kevin On 6/12/2018 1:55 PM, Phil Race wrote: > One other point .. something I mentioned off line to Kevin but he did > not so far bring up here, > is that when counting the number of reviewers on a fix, we must > require at least one Reviewer, > with a capital "R", but to make up the total of 2 reviewers, it is > sufficient to have one other person > who only has committer status .. or even author status (maybe), be the > second reviewer. > We've used this policy on the JDK AWT/2D/Swing stack for a long time. > It not only frees up the > scarce "R"eviewers, but it helps train new ones :-), whilst still > ensuring at least two sets of eye balls > were on it. > > -phil. > > On 05/24/2018 10:36 AM, Kevin Rushforth wrote: >> Phil pointed out one glaring typo in the summary and also a couple >> things in the details that could be clarified. >> >>> The short version of the proposal is: >>> ... >>> 2. Revised code review policies for different types of changes: >>> simple, low-impact fixes (1 Reviewer); higher-impact fixes (2 >>> Reviewers + allow time for others to chime in); Features / API >>> changes (CSR approval, including approval by a "lead", plus 3 >>> Reviewers for the code) >>> >> >> That last been should be: CSR approval, including approval by a >> "lead", plus *2* Reviewers for the code. I had it right in the >> details, but made a typo in the short version. While some reviews >> might have more than 2, it was certainly not my intent to mandate it. >> >>> A. Low-impact bug fixes. ... >>> One reviewer is sufficient to accept such changes. As a courtesy, >>> and to avoid changes which later might need to be backed out, if you >>> think there might be some concern or objection to the change, please >>> give sufficient time for folks who might be in other time zones the >>> chance to take a look. This should be left up to the judgment of the >>> reviewer who approves it as well as the contributor. >> >> To clarify, the intent is to avoid pushing changes that might be >> controversial, and not to mandate unnecessary delay for truly simple >> fixes (e.g., fixing a build break). Reviewers and Committers are >> expected to use their best judgment here. >> >>> C. New features / API additions. This includes behavioral changes, >>> additions to the fxml or css spec, etc. >>> >>> ... a New Feature, API addition, or behavioral change must be >>> reviewed / approved by a "lead". Currently this is either myself or >>> Johan Vos as indicated above. >>> >>> I also propose that we continue to use the CSR process [3] to track >>> such changes. The CSR chair has indicated that he is willing to >>> track JavaFX compatibility changes even though FX is no longer a >>> part of the JDK. >> >> The "approval by lead" means approving the API / feature change via >> the CSR. A "lead" often will be one of the code reviewers as well, >> but need not be as long as they approve the API change itself via the >> CSR. >> >> -- Kevin >> >> >> On 5/23/2018 3:16 PM, Kevin Rushforth wrote: >>> To: OpenJFX Developers >>> >>> As I mentioned in a message last week [1] I would like to restart >>> the discussion we started a few months ago [2] around making it >>> easier to contribute code to OpenJFX. To this end, I like to make >>> some concrete proposals around code review / API review policies. >>> >>> Before getting to the details, I would like to acknowledge Gluon's >>> contributions to the OpenJFX project, specifically those of Johan >>> Vos. I am pleased to announce an expanded role for Johan Vos in the >>> OpenJFX project. I would like to announce that starting now, Johan >>> is effectively a co-lead for the purposes of setting direction, and >>> approving new features for the Project. >>> >>> The short version of the proposal is: >>> >>> 1. Formalize the concept of Reviewers with an initial list of >>> Reviewers and a defined criteria for adding additional Reviewers. >>> >>> 2. Revised code review policies for different types of changes: >>> simple, low-impact fixes (1 Reviewer); higher-impact fixes (2 >>> Reviewers + allow time for others to chime in); Features / API >>> changes (CSR approval, including approval by a "lead", plus 3 >>> Reviewers for the code) >>> >>> 3. Streamlining reviews of changes developed in the GitHub sandbox: >>> provided that the review policy is followed to before a PR is merged >>> into the develop branch in GitHub, a fast-track review can happen >>> pointing to the changeset that was merged and the PR, which has >>> review comments. >>> >>> Details follow. >>> >>> Quoting from my earlier message: >>> >>>> "Code reviews are important to maintain high-quality contributions, >>>> but we recognize that not every type of change needs the same level >>>> of review. Without lowering our standards of quality, we want to >>>> make it easier to get low-impact changes (simple bug fixes) accepted." >>> >>> To that end, I propose the following policies. Many of these will >>> involve judgment calls, especially when it comes to deciding whether >>> a fix is low impact vs. high-impact. I think that's OK. It doesn't >>> have to be perfect. >>> >>> Recommendations >>> >>> 1. I recommend that we formalize the concept of Reviewers, using the >>> OpenJDK Reviewer role for the OpenJFX Project. >>> >>> A. I will provide an initial list of reviewers to the registrar >>> based on past contributions, and also recognizing Committers who >>> have become experts in their area. This is the only time we will >>> have such latitude as the OpenJDK Bylaws specify the policy we need >>> to follow for nominating and voting upon additional Reviewers. >>> >>> B. We need to set formal guidelines for becoming a Reviewer. The JDK >>> uses a threshold of 32 significant contributions. While we don't >>> want to relax it too much, one thing I have been discussing >>> informally with a few people is that a Committer with, say, 24 >>> commits, who regularly participates in reviews, offering good >>> feedback, might be just a good a reviewer (maybe even better) than >>> someone with 32 commits who rarely, if ever, provides feedback on >>> proposed bug fixes. I'm open for suggestions here. >>> >>> One thing I'd like to add is that we expect Reviewers to feel >>> responsible not just for their piece, but for the quality of the >>> JavaFX library as a whole. I might work with some folks at Gluon and >>> here at Oracle to draft a set of expectations for reviewers. >>> >>> >>> 2. Code review policies >>> >>> All code reviews must be posted on the openjfx-dev mailing list -- >>> even simple fixes. I propose that we have the following code review >>> policies for different types of changes. I also note that if there >>> is disagreement as to whether a fix is low-impact or high-impact, >>> then it is considered high-impact. In other words we will always err >>> on the side of quality by "rounding up" to the next higher category. >>> The contributor can say whether they think something is low-impact >>> or high-impact, but It is up to a Reviewer to initially decide this. >>> >>> A. Low-impact bug fixes. These are typically isolated bug fixes with >>> little or no impact beyond fixing the bug in question; included in >>> this category are test fixes (including new tests), doc fixes, and >>> fixes to sample applications (including new samples). >>> >>> One reviewer is sufficient to accept such changes. As a courtesy, >>> and to avoid changes which later might need to be backed out, if you >>> think there might be some concern or objection to the change, please >>> give sufficient time for folks who might be in other time zones the >>> chance to take a look. This should be left up to the judgment of the >>> reviewer who approves it as well as the contributor. >>> >>> B. Higher impact bug fixes or RFEs. These include changes to the >>> implementation that potentially have a performance or behavioral >>> impact, or are otherwise broad in scope. Some larger bug fixes will >>> fall into this category, as will fixes in high-risk areas (e.g., CSS). >>> >>> Two reviewers must approve to accept such changes. Additionally, the >>> review should allow sufficient time for folks who might be in other >>> time zones the chance to review if they have concerns. >>> >>> C. New features / API additions. This includes behavioral changes, >>> additions to the fxml or css spec, etc. >>> >>> Feature requests come with a responsibility beyond just saying "here >>> is the code for this cool new feature, please take it". There are >>> many factors to consider for even small features. Larger features >>> will need a significant contribution in terms of API design, coding, >>> testing, maintainability, etc. >>> >>> To ensure that new features are consistent with the rest of the API >>> and the desired direction of the Project, I propose that a New >>> Feature, API addition, or behavioral change must be reviewed / >>> approved by a "lead". Currently this is either myself or Johan Vos >>> as indicated above. >>> >>> I also propose that we continue to use the CSR process [3] to track >>> such changes. The CSR chair has indicated that he is willing to >>> track JavaFX compatibility changes even though FX is no longer a >>> part of the JDK. >>> >>> For the review of the implementation, I propose that we use the same >>> "two reviewer" standard for the code changes as category B. >>> >>> >>> 3. Streamlining the review process for changes developed on GitHub >>> >>> A fix that was developed as pull-requests (PRs) on GitHub is >>> eligible for a fast-track review, if: >>> >>> A. The PR was squashed / merged into the develop branch as a single >>> changeset >>> B. No follow-on changesets were merged into develop as part of that >>> same fix >>> C. The changeset is "whitespace clean" -- meaning that you have run >>> 'tools/scripts/checkWhiteSpace' on the final changeset (we might >>> want to add this to the CI build). >>> and >>> D. All code review policies outlined above in #2 were followed prior >>> to the PR being approved and merged into the develop branch on >>> GitHub. This includes sending email to openjfx-dev when you first >>> make a PR that you intend to have merged into the develop branch to >>> give other reviewers who may not be watching all PRs a chance to >>> comment before it is merged. >>> >>> A "fast-track" review is a quick sanity check before the change is >>> committed and pushed to the jfx-dev repo on hg.openjdk.java.net. >>> This fast track review just needs to point to the GitHub changeset >>> that was merged and to the PR, which will have any review comments. >>> If there are no compelling reasons why the PR can't be pushed to >>> jfx-dev, then it can be pushed. >>> >>> >>> Please let me know your thoughts on the above proposals. >>> >>> Thank you all for being a part of this community. >>> >>> -- Kevin Rushforth, OpenJFX Project Lead >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021867.html >>> >>> [2] >>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021335.html >>> >>> [3] https://wiki.openjdk.java.net/display/csr/Main >>> >> > From kevin.rushforth at oracle.com Tue Jun 12 22:18:00 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 12 Jun 2018 15:18:00 -0700 Subject: Milestone dates for OpenJFX 11 release Message-ID: We are getting close to the start of rampdown for JDK 11 [1]. Now that FX is no longer bundled we don't need to follow exactly the same schedule of milestones, although we do want to release this first unbundled FX 11 release at the same time JDK 11 ships (or slightly sooner). Here is the proposed rampdown schedule for FX 11. The main differences between the JDK schedule and the FX schedule is that we don't need as long a back end as a full JDK feature release 2018-07-09 : RDP1 (aka feature freeze) 2018-08-06 : RDP2 2018-08-27 : freeze for GAC build 2018-09-18 : GA I am proposing a shorter time after RDP2 than the JDK because I don't think we need the long back end of a full JDK feature release (not as many moving parts or stakeholders). I will send out the proposed ramp-down policies, but as a starting point I imagine we want something similar to what the JDK uses with a couple modifications: 1. Since this is our first unbundled release and there are likely to be plenty of bugs that need fixing during RDP1, so I propose to postpone forking the repo until RDP1. This means a 4 week downtime where there is no place to push new features / enhancements unless they are critical to openjfx 11 (in which case they will be an exception). I think this is a reasonable trade-off for this release 2. I don't plan to propose any restrictions on P4 bugs before RDP2. The focus should be on more serious bugs, and we likely won't fix many P4s, but if a safe P4 bug fix is proposed, reviewed, and tested, then I see no reason not to take it between RDP1 and RDP2. -- Kevin [1] http://openjdk.java.net/projects/jdk/11/ From nakajima.akira at nttcom.co.jp Wed Jun 13 07:40:35 2018 From: nakajima.akira at nttcom.co.jp (Nakajima Akira) Date: Wed, 13 Jun 2018 16:40:35 +0900 Subject: JDK-8187100 [PATCH][JavaFX] To make display Variation Selector(IVS/SVS/FVS) Message-ID: I happened to create similar patch without knowing the report below. https://bugs.openjdk.java.net/browse/JDK-8187100 ====================================================== Difference with following SWING patch and my JavaFX patch. http://cr.openjdk.java.net/~srl/8187100/webrev.00/ 1. For Acceleration and Memory saving, load only partial glyphs table. javafx.graphics/src/main/java/com/sun/javafx/font/CMap.java + if (numMappings[i] > 0 && (uniStart[i] == null || glyphID[i] == null)) { + try { + initNonDef(i); 2. Mongolian support javafx.graphics/src/main/java/com/sun/javafx/text/ScriptMapper.java + else if (code <= 0x18af) { // 1800 - 18AF Mongolian (including FVS) + return true; + } 3. Fix 2 bugs on Windows (See below bugs) ====================================================== This JavaFX patch fixes following 4 bugs. 1. To make display IVS/SVS Sample is kami.java and kami2.java javafx.graphics/src/main/java/com/sun/javafx/font/CMap.java javafx.graphics/src/main/java/com/sun/javafx/font/CharToGlyphMapper.java javafx.graphics/src/main/java/com/sun/javafx/font/CompositeGlyphMapper.java javafx.graphics/src/main/java/com/sun/javafx/font/OpenTypeGlyphMapper.java 2. To make dislpay Mongolian and FVS Sample is mongol.java javafx.graphics/src/main/java/com/sun/javafx/text/ScriptMapper.java 3. Fix bug to handle minus value glyph_id on Windows (You run NG.java, then Java aborted) Sample is NG.java javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java 4. Fix bug to display INVISIBLE_GLYPH on Windows (Now display square box. No need to display.) javafx.graphics/src/main/java/com/sun/prism/sw/SWGraphics.java ====================================================== I checked this patch on CentOS 7.5 and Windows7 x64. ==================== PATCH ==================== diff -r 284d06bb1364 modules/javafx.graphics/src/main/java/com/sun/javafx/font/CMap.java --- a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/CMap.java Tue Jun 12 14:40:17 2018 +0530 +++ b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/CMap.java Wed Jun 13 14:52:07 2018 +0900 @@ -42,12 +42,13 @@ abstract class CMap { static final char noSuchChar = (char)0xfffd; + static final int BYTEMASK = 0x000000ff; static final int SHORTMASK = 0x0000ffff; static final int INTMASK = 0xffffffff; private static final int MAX_CODE_POINTS = 0x10ffff; - static CMap initialize(PrismFontFile font) { + static CMap initialize(PrismFontFile font, int[] offset_format, int create_cmap) { CMap cmap = null; @@ -59,6 +60,11 @@ Buffer cmapBuffer = font.readTable(FontConstants.cmapTag); short numberSubTables = cmapBuffer.getShort(2); + /* create CMap14 */ + if (create_cmap == 14 && offset_format[0] != 0) { + return createCMap(cmapBuffer, offset_format[0]); + } + /* Locate the offsets of supported 3,* Microsoft platform encodings, * and any 0,* Unicode platform encoding. The latter is used by * all current OS X fonts that don't have a Microsoft cmap. @@ -76,6 +82,9 @@ zeroStar = true; encodingID = cmapBuffer.getShort(); zeroStarOffset = cmapBuffer.getInt(); + if (encodingID == 5) { + offset_format[0] = zeroStarOffset; + } } else if (platformID == 3) { threeStar = true; @@ -133,6 +142,7 @@ case 8: return new CMapFormat8(buffer, offset); case 10: return new CMapFormat10(buffer, offset); case 12: return new CMapFormat12(buffer, offset); + case 14: return new CMapFormat14(buffer, offset); default: throw new RuntimeException("Cmap format unimplemented: " + (int)buffer.getChar(offset)); } @@ -140,6 +150,13 @@ abstract char getGlyph(int charCode); + char getGlyph(int charCode, int vs) { + return getGlyph(charCode); + } + + void setDefCMap(CMap defCmap) { + } + /* Format 4 Header is * ushort format (off=0) * ushort length (off=2) @@ -207,6 +224,7 @@ char ctmp = buffer.getChar(); idRangeOffset[i] = (char)((ctmp>>1)&0xffff); } + /* Can calculate the number of glyph IDs by subtracting * "pos" from the length of the cmap */ @@ -591,6 +609,191 @@ } + // Format 14: Table for Variation Selector (SVS and IVS) + static class CMapFormat14 extends CMap { + + Buffer buffer; + int offset; + + int numSelector; + int[] varSelector; + + /* default glyphs */ + int[] defaultOff, numRanges; + int[][] defUniStart; + short[][] additionalCnt; + + /* non default glyphs */ + int[] nonDefOff, numMappings; + int[][] uniStart, glyphID; + /* e.g. + * uniStart[numSelector-1] = U+e0100 + * uniStart[numSelector-1][numMappings-1] = U+795e + * glyphID[numSelector-1][numMappings-1] = 12345 + */ + + CMap defCmap; + void setDefCMap(CMap cmap) { + this.defCmap = cmap; + } + + CMapFormat14(Buffer buffer, int offset) { + this.buffer = buffer; + this.offset = offset; + + buffer.position(offset+6); + /* get count of Variation Selector */ + numSelector = buffer.getInt(); + + varSelector = new int[numSelector]; // e.g. {0xfe00, 0xe0100, 0xe0101} + defaultOff = new int[numSelector]; + nonDefOff = new int[numSelector]; + + /* get Variation Selector and Table offset */ + for (int i=0; i 0) { + int min = 0, max, mid; + max = numMappings[i]; + while (min < max) { + mid = (min+max) >> 1; + if (charCode < uniStart[i][mid]) { + max = mid; + } else if (charCode > uniStart[i][mid]) { + min = mid + 1; + } else { + return mid; + } + } + } + return -1; + } + + final int findRangeNumber_Def(int charCode, int i) { + if (numRanges[i] > 0) { + int min = 0, max, mid; + max = numRanges[i]; + while (min < max) { + mid = (min+max) >> 1; + if (charCode < defUniStart[i][mid]) { + max = mid; + } else if (charCode > defUniStart[i][mid] + additionalCnt[i][mid]) { + min = mid + 1; + } else { + return mid; + } + } + } + return -1; + } + + char getGlyph(int charCode) { + return getGlyph(charCode, 0); + } + + char getGlyph(int charCode, int vs) { + if (vs == 0) return 0; + + int j; + for (int i=0; i vs) break; + if (varSelector[i] != vs) continue; + + /* non default glyphs table */ + if (numMappings[i] > 0 && (uniStart[i] == null || glyphID[i] == null)) { + try { + initNonDef(i); + } catch (Exception e) { + return 0; + } + } + + /* search non default glyphs table */ + j = findMapNumber_NonDef(charCode, i); + if (j != -1) { + return (char)glyphID[i][j]; + } + + /* default glyphs table */ + if (defCmap == null) break; // can't get glyphID by default glyphs table + if (numRanges[i] > 0 && (defUniStart[i] == null || additionalCnt[i] == null)) { + try { + initDef(i); + } catch (Exception e) { + return 0; + } + } + + /* search default glyphs table */ + if (defCmap == null) break; + j = findRangeNumber_Def(charCode, i); + if (j != -1) { + return defCmap.getGlyph(charCode); + } + } + + return 0; + } + } + /* Used to substitute for bad Cmaps. */ static class NullCMapClass extends CMap { diff -r 284d06bb1364 modules/javafx.graphics/src/main/java/com/sun/javafx/font/CharToGlyphMapper.java --- a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/CharToGlyphMapper.java Tue Jun 12 14:40:17 2018 +0530 +++ b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/CharToGlyphMapper.java Wed Jun 13 14:52:07 2018 +0900 @@ -42,8 +42,66 @@ public static final int MISSING_GLYPH = 0; public static final int INVISIBLE_GLYPH_ID = 0xffff; + public static final int SVS_START = 0xFE00; // VS1 + public static final int SVS_END = 0xFE0F; // VS16 + public static final int IVS_START = 0xE0100; // VS17 + public static final int IVS_END = 0xE01EF; // VS256 + public static final int FVS_START = 0x180B; // FVS1 + public static final int FVS_END = 0x180D; // FVS3 + protected int missingGlyph = MISSING_GLYPH; + /* http://www.unicode.org/versions/Unicode10.0.0/ch18.pdf */ + public static boolean isCJK(int code) { + if (code >= 0x4E00 && code <= 0x9FFF) // Unified Ideographs + return true; + if (code >= 0x3400 && code <= 0x4DBF) // Extension A + return true; + if (code >= 0x20000 && code <= 0x2A6DF) // Extension B + return true; + if (code >= 0x2A700 && code <= 0x2B73F) // Extension C + return true; + if (code >= 0x2B740 && code <= 0x2B81F) // Extension D + return true; + if (code >= 0x2B820 && code <= 0x2CEAF) // Extension E + return true; + if (code >= 0x2CEB0 && code <= 0x2EBE0) // Extension F + return true; + if (code >= 0xF900 && code <= 0xFAFF) // Compatibility Ideographs + return true; + if (code >= 0x2F800 && code <= 0x2FA1F) // Compatibility Ideographs Supplement + return true; + return false; + } + + public static boolean isVS(int code) { + if (isIVS(code)) + return true; + if (isSVS(code)) + return true; +// if (isFVS(code)) +// return true; + return false; + } + + public static boolean isSVS(int code) { + if (code >= SVS_START && code <= SVS_END) + return true; + return false; + } + + public static boolean isIVS(int code) { + if (code >= IVS_START && code <= IVS_END) + return true; + return false; + } + +// public static boolean isFVS(int code) { +// if (code >= FVS_START && code <= FVS_END) +// return true; +// return false; +// } + public boolean canDisplay(char cp) { int glyph = charToGlyph(cp); return glyph != missingGlyph; @@ -53,18 +111,28 @@ return missingGlyph; } - public abstract int getGlyphCode(int charCode); + public abstract int getGlyphCode(int charCode, int vs); public int charToGlyph(char unicode) { - return getGlyphCode(unicode); + return getGlyphCode(unicode, (char)0); + } + + public int charToGlyph(char unicode, char vs) { + return getGlyphCode(unicode, vs); } public int charToGlyph(int unicode) { - return getGlyphCode(unicode); + return getGlyphCode(unicode, 0); + } + + public int charToGlyph(int unicode, int vs) { + return getGlyphCode(unicode, vs); } public void charsToGlyphs(int start, int count, char[] unicodes, int[] glyphs, int glyphStart) { + + int codeWasSurrogate = 0; // store surrogate pair to handle surrogate pair+VS for (int i=0; i= HI_SURROGATE_START && @@ -75,13 +143,67 @@ low <= LO_SURROGATE_END) { code = ((code - HI_SURROGATE_START) << HI_SURROGATE_SHIFT) + low - LO_SURROGATE_START + SURROGATES_START; - glyphs[glyphStart + i] = getGlyphCode(code); + + if (isIVS(code) && i > 0 && + ((codeWasSurrogate == 0 && isCJK((int)unicodes[start + i -1])) || + codeWasSurrogate != 0)) { + int glyph; + if (codeWasSurrogate == 0) { + glyph = getGlyphCode((int)unicodes[start + i -1], code); // IVS + } else { + glyph = getGlyphCode(codeWasSurrogate, code); // surrogate pair+IVS + } + if (glyph == missingGlyph) { + glyphs[glyphStart + i] = missingGlyph; + } else { + if (codeWasSurrogate == 0) { + glyphs[glyphStart + i - 1] = glyph; + glyphs[glyphStart + i] = INVISIBLE_GLYPH_ID; + } else { + glyphs[glyphStart + i - 2] = glyph; + glyphs[glyphStart + i - 1] = INVISIBLE_GLYPH_ID; + glyphs[glyphStart + i] = INVISIBLE_GLYPH_ID; + } + } + codeWasSurrogate = 0; + } else { // surrogate pair + glyphs[glyphStart + i] = getGlyphCode(code, 0); + if (isIVS(code) == false) { + codeWasSurrogate = code; // store surrogate pair + } + } + i += 1; // Empty glyph slot after surrogate glyphs[glyphStart + i] = INVISIBLE_GLYPH_ID; continue; } + } else if (isSVS(code) && i > 0 && + ((codeWasSurrogate == 0 && isCJK((int)unicodes[start + i -1])) || + codeWasSurrogate != 0)) { + int glyph; + if (codeWasSurrogate == 0) { + glyph = getGlyphCode((int)unicodes[start + i -1], code); // SVS + } else { + glyph = getGlyphCode(codeWasSurrogate, code); // surrogate pair+SVS + } + if (glyph == missingGlyph) { + glyphs[glyphStart + i] = missingGlyph; + } else { + if (codeWasSurrogate == 0) { + glyphs[glyphStart + i - 1] = glyph; + glyphs[glyphStart + i] = INVISIBLE_GLYPH_ID; + } else { + glyphs[glyphStart + i - 2] = glyph; + glyphs[glyphStart + i - 1] = INVISIBLE_GLYPH_ID; + glyphs[glyphStart + i] = INVISIBLE_GLYPH_ID; + } + } + codeWasSurrogate = 0; + continue; } - glyphs[glyphStart + i] = getGlyphCode(code); + + glyphs[glyphStart + i] = getGlyphCode(code, 0); + codeWasSurrogate = 0; } } diff -r 284d06bb1364 modules/javafx.graphics/src/main/java/com/sun/javafx/font/CompositeGlyphMapper.java --- a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/CompositeGlyphMapper.java Tue Jun 12 14:40:17 2018 +0530 +++ b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/CompositeGlyphMapper.java Wed Jun 13 14:52:07 2018 +0900 @@ -31,6 +31,7 @@ public static final int SLOTMASK = 0xff000000; public static final int GLYPHMASK = 0x00ffffff; + public static final long LONGMASK = 0x00000000ffffffffL; public static final int NBLOCKS = 216; public static final int BLOCKSZ = 256; @@ -54,11 +55,17 @@ * the caching ? So a variety of strategies are possible. */ HashMap glyphMap; + HashMap glyphMapVS; // HashMap for Variation Selector + + public static long shiftVS_for_HashMap(int code) { + return (long)code << 32; + } public CompositeGlyphMapper(CompositeFontResource compFont) { font = compFont; missingGlyph = 0; // TrueType font standard, avoids lookup. glyphMap = new HashMap(); + glyphMapVS = new HashMap(); slotMappers = new CharToGlyphMapper[compFont.getNumSlots()]; asciiCacheOK = true; } @@ -90,17 +97,35 @@ return ((slot) << 24 | (glyphCode & GLYPHMASK)); } - private final int convertToGlyph(int unicode) { + public static final int compGlyphToSlot(int compGlyphCode) { + return (compGlyphCode >> 24); + } + + public static final int compGlyphToGlyph(int compGlyphCode) { + return (compGlyphCode & GLYPHMASK); + } + + private final int convertToGlyph(int unicode, int vs) { for (int slot = 0; slot < font.getNumSlots(); slot++) { CharToGlyphMapper mapper = getSlotMapper(slot); - int glyphCode = mapper.charToGlyph(unicode); + int glyphCode = mapper.charToGlyph(unicode, vs); + if (glyphCode != mapper.getMissingGlyphCode()) { glyphCode = compositeGlyphCode(slot, glyphCode); - glyphMap.put(unicode, glyphCode); + if (vs == 0 || CharToGlyphMapper.isVS(vs) == false) { + glyphMap.put(unicode, glyphCode); + } else { + glyphMapVS.put(shiftVS_for_HashMap(vs) | (unicode & LONGMASK), glyphCode); + } return glyphCode; } } - glyphMap.put(unicode, missingGlyph); + if (vs == 0 || CharToGlyphMapper.isVS(vs) == false) { + glyphMap.put(unicode, missingGlyph); + } else { + glyphMapVS.put(shiftVS_for_HashMap(vs) | (unicode & LONGMASK), missingGlyph); + } + return missingGlyph; } @@ -137,18 +162,22 @@ return charToGlyph[index]; } - public int getGlyphCode(int charCode) { + public int getGlyphCode(int charCode, int vs) { // If ASCII then array lookup, else use glyphMap int retVal = getAsciiGlyphCode(charCode); if (retVal >= 0) { return retVal; } - - Integer codeInt = glyphMap.get(charCode); + Integer codeInt; + if (vs == 0 || CharToGlyphMapper.isVS(vs) == false) { + codeInt = glyphMap.get(charCode); + } else { + codeInt = glyphMapVS.get(shiftVS_for_HashMap(vs) | (charCode & LONGMASK)); + } if (codeInt != null) { return codeInt.intValue(); } else { - return convertToGlyph(charCode); + return convertToGlyph(charCode, vs); } } } diff -r 284d06bb1364 modules/javafx.graphics/src/main/java/com/sun/javafx/font/OpenTypeGlyphMapper.java --- a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/OpenTypeGlyphMapper.java Tue Jun 12 14:40:17 2018 +0530 +++ b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/OpenTypeGlyphMapper.java Wed Jun 13 14:52:07 2018 +0900 @@ -29,11 +29,14 @@ PrismFontFile font; CMap cmap; + int offset_format[] = {0}; // offset of format14 + CMap cmap14; public OpenTypeGlyphMapper(PrismFontFile font) { this.font = font; + offset_format[0] = 0; try { - cmap = CMap.initialize(font); + cmap = CMap.initialize(font, offset_format, -1); } catch (Exception e) { cmap = null; } @@ -43,13 +46,38 @@ missingGlyph = 0; /* standard for TrueType fonts */ } - public int getGlyphCode(int charCode) { - try { - return cmap.getGlyph(charCode); - } catch(Exception e) { - handleBadCMAP(); - return missingGlyph; + public CMap createCMap14() { + if (cmap14 == null && offset_format[0] != 0) { + try { + cmap14 = CMap.initialize(font, offset_format, 14); + } catch (Exception e) { + cmap14 = null; + } + if (cmap14 != null) { + cmap14.setDefCMap(this.cmap); + } + offset_format[0] = 0; } + return cmap14; + } + + public int getGlyphCode(int charCode, int vs) { + if (vs == 0) { + try { + return cmap.getGlyph(charCode); + } catch(Exception e) { + handleBadCMAP(); + return missingGlyph; + } + } else if (createCMap14() != null) { + try { + return cmap14.getGlyph(charCode, vs); + } catch(Exception e) { + handleBadCMAP14(); + return missingGlyph; + } + } + return missingGlyph; } private void handleBadCMAP() { @@ -57,6 +85,10 @@ cmap = CMap.theNullCmap; } + private void handleBadCMAP14() { + cmap14 = CMap.theNullCmap; + } + /* A pretty good heuristic is that the cmap we are using * supports 32 bit character codes. */ diff -r 284d06bb1364 modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java --- a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java Tue Jun 12 14:40:17 2018 +0530 +++ b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java Wed Jun 13 14:52:07 2018 +0900 @@ -52,6 +52,7 @@ private static D2D1_COLOR_F WHITE = new D2D1_COLOR_F(1f, 1f, 1f, 1f); private static D2D1_MATRIX_3X2_F D2D2_MATRIX_IDENTITY = new D2D1_MATRIX_3X2_F(1,0, 0,1, 0,0); + static final int intMask = 0x0000ffff; DWGlyph(DWFontStrike strike, int glyphCode, boolean drawShapes) { this.strike = strike; @@ -303,12 +304,12 @@ @Override public int getGlyphCode() { - return run.glyphIndices; + return ((int)run.glyphIndices & intMask); } @Override public RectBounds getBBox() { - return strike.getBBox(run.glyphIndices); + return strike.getBBox((int)run.glyphIndices & intMask); } @Override @@ -321,7 +322,7 @@ @Override public Shape getShape() { - return strike.createGlyphOutline(run.glyphIndices); + return strike.createGlyphOutline((int)run.glyphIndices & intMask); } @Override diff -r 284d06bb1364 modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java --- a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java Tue Jun 12 14:40:17 2018 +0530 +++ b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java Wed Jun 13 14:52:07 2018 +0900 @@ -138,6 +138,7 @@ int i, j; int[] iglyphs = new int[glyphCount]; int slotMask = slot << 24; + final int intMask = 0x0000ffff; boolean missingGlyph = false; i = 0; j = rtl ? glyphCount - 1 : 0; while (i < glyphCount) { @@ -145,7 +146,7 @@ missingGlyph = true; if (composite) break; } - iglyphs[i] = glyphs[j] | slotMask; + iglyphs[i] = ((int)glyphs[j] & intMask) | slotMask; i++; j+=step; } diff -r 284d06bb1364 modules/javafx.graphics/src/main/java/com/sun/javafx/text/ScriptMapper.java --- a/modules/javafx.graphics/src/main/java/com/sun/javafx/text/ScriptMapper.java Tue Jun 12 14:40:17 2018 +0530 +++ b/modules/javafx.graphics/src/main/java/com/sun/javafx/text/ScriptMapper.java Wed Jun 13 14:52:07 2018 +0900 @@ -154,6 +154,9 @@ else if (code <= 0x17ff) { // 1780 - 17FF Khmer return true; } + else if (code <= 0x18af) { // 1800 - 18AF Mongolian (including FVS) + return true; + } else if (code < 0x200c) { return false; } diff -r 284d06bb1364 modules/javafx.graphics/src/main/java/com/sun/prism/sw/SWGraphics.java --- a/modules/javafx.graphics/src/main/java/com/sun/prism/sw/SWGraphics.java Tue Jun 12 14:40:17 2018 +0530 +++ b/modules/javafx.graphics/src/main/java/com/sun/prism/sw/SWGraphics.java Wed Jun 13 14:52:07 2018 +0900 @@ -62,6 +62,8 @@ import com.sun.prism.paint.ImagePattern; import com.sun.prism.paint.Paint; +import com.sun.javafx.font.CharToGlyphMapper; + final class SWGraphics implements ReadbackGraphics { private static final BasicStroke DEFAULT_STROKE = @@ -630,6 +632,9 @@ final Glyph g = strike.getGlyph(gl.getGlyphCode(idx)); if (drawAsMasks) { + if (g.getGlyphCode() == CharToGlyphMapper.INVISIBLE_GLYPH_ID) { + return; + } final Point2D pt = new Point2D((float)(x + tx.getMxt() + gl.getPosX(idx)), (float)(y + tx.getMyt() + gl.getPosY(idx))); int subPixel = strike.getQuantizedPosition(pt); ==================== Sample (kami.java) ==================== import javafx.application.Application; import static javafx.application.Application.launch; import javafx.scene.Group; import javafx.scene.Scene; import javafx.scene.paint.Color; import javafx.scene.text.Font; import javafx.scene.text.Text; import javafx.scene.text.TextFlow; import javafx.stage.Stage; public class kami extends Application { @Override public void start(Stage stage) throws Exception { // You need to install ipamjm font String family = "IPAmjMincho"; // for Linux // String family = "IPAmj??"; // for Windows Text text[] = new Text[3]; text[0] = new Text("\u795E+VS1 --> \u795E\uFE00\n"); // FVS text[1] = new Text("\u795E+VS20 --> \u795E\uDB40\uDD03\n"); // IVS text[2] = new Text("\uD87A\uDF79+VS17 --> \uD87A\uDF79\uDB40\uDD01\n"); // Surrogate Pair+IVS for (int i=0; i<3; i++) { text[i].setFill(Color.BLACK); text[i].setFont(Font.font(family, 48)); } TextFlow textFlow = new TextFlow(text[0], text[1], text[2]); textFlow.setLayoutX(60); textFlow.setLayoutY(60); Group group = new Group(textFlow); Scene scene = new Scene(group, 450, 250, Color.WHITE); stage.setScene(scene); stage.show(); } } ==================== Sample (kami2.java) ==================== import javafx.application.Application; import javafx.geometry.Insets; import javafx.scene.Group; import javafx.scene.Scene; import javafx.scene.control.Label; import javafx.scene.control.TextArea; import javafx.scene.layout.GridPane; import javafx.stage.Stage; import javafx.scene.text.Text; import javafx.scene.text.Font; public class kami2 extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage stage) { // You need to install ipamjm font String family = "IPAmjMincho"; // for Linux // String family = "IPAmj??"; // for Windows Scene scene = new Scene(new Group(), 650, 300); String str[] = new String[3]; str[0] = new String("\u795E+VS1 --> \u795E\uFE00\n"); // FVS str[1] = new String("\u795E+VS20 --> \u795E\uDB40\uDD03\n"); // IVS str[2] = new String("\uD87A\uDF79+VS17 --> \uD87A\uDF79\uDB40\uDD01\n"); // Surrogate Pair+IVS String str_for_area = new String(""); for (int i=0; i<3; i++) { str_for_area += str[i].toString(); } TextArea area = new TextArea(str_for_area); area.setFont(Font.font(family, 48)); area.setPrefWidth(600); area.setPrefHeight(250); area.setPrefColumnCount(3); GridPane grid = new GridPane(); grid.setVgap(4); grid.setHgap(10); grid.setPadding(new Insets(5, 5, 5, 5)); grid.add(area, 1, 0); Group root = (Group) scene.getRoot(); root.getChildren().add(grid); stage.setScene(scene); stage.show(); } } ==================== Sample (mongol.java) ==================== import javafx.application.Application; import static javafx.application.Application.launch; import javafx.scene.Group; import javafx.scene.Scene; import javafx.scene.paint.Color; import javafx.scene.text.Font; import javafx.scene.text.Text; import javafx.scene.text.TextFlow; import javafx.stage.Stage; public class mongol extends Application { @Override public void start(Stage stage) throws Exception { // http://www.mongolfont.com/en/font/mnglartotf.html String family = "Mongolian Art"; double size = 48; // Correct mongolian form // http://www.unicode.org/versions/Unicode10.0.0/ch13.pdf#G27803 Text text[] = new Text[9]; text[0] = new Text("? ? ? ? --> ???? (urtu)\n"); text[1] = new Text("? ? ? ? --> ???? (ordu)\n"); text[2] = new Text("? ? ? ? --> ???? (ende)\n"); text[3] = new Text("? ? ? --> ??? (ada)\n"); text[4] = new Text("? ? ? --> ??? (abu)\n"); text[5] = new Text("? ? ? --> ??? (odo)\n"); text[6] = new Text("? ? ? --> ??? (ene)\n"); text[7] = new Text("? ? --> ?? (gal)\n"); text[8] = new Text("?? ? --> ??? (gal+U+180B)\n"); for (int i=0; i<9; i++) { text[i].setFill(Color.BLACK); text[i].setFont(Font.font(family, size)); } TextFlow textFlow = new TextFlow(text[0], text[1], text[2], text[3], text[4], text[5], text[6], text[7], text[8]); textFlow.setLayoutX(60); textFlow.setLayoutY(60); Group group = new Group(textFlow); Scene scene = new Scene(group, 600, 650, Color.WHITE); stage.setScene(scene); stage.show(); } } ==================== Sample (NG.java) ==================== import javafx.application.Application; import static javafx.application.Application.launch; import javafx.scene.Group; import javafx.scene.Scene; import javafx.scene.paint.Color; import javafx.scene.text.Font; import javafx.scene.text.Text; import javafx.scene.text.TextFlow; import javafx.stage.Stage; // Run on Windows, then Java abort because of bug. public class NG extends Application { @Override public void start(Stage stage) throws Exception { String family = "Arial Unicode MS"; double size = 36; TextFlow textFlow = new TextFlow(); textFlow.setLayoutX(60); textFlow.setLayoutY(60); // Unicode(GlyphID) Text text = new Text("??"); // U+2F9D4(49496) + U+0E3F(1262) /* Inside JavaFX, 49496(Uint16) is handled as -16040(short). * By ScriptMapper.isComplexCharCode(), U+0E3F is handled as complex. * When in condition with minus glyphID value and complex * , JavaFX is forcibly terminated. * (java.lang.ArrayIndexOutOfBoundsException) */ text.setFill(Color.GREEN); text.setFont(Font.font(family, size)); textFlow.getChildren().addAll(text); Group group = new Group(textFlow); Scene scene = new Scene(group, 1200, 300, Color.WHITE); stage.setScene(scene); stage.show(); } } -------------------------------------- Name: Akira Nakajima E-Mail: nakajima.akira at nttcom.co.jp -------------------------------------- From prasanta.sadhukhan at oracle.com Wed Jun 13 07:48:57 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 13 Jun 2018 13:18:57 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <5B0DD789.8000809@oracle.com> References: <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> Message-ID: <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> Hi Phil, All Please find modified webrev taking care of streamlining SwingInteropUtils class and handling of native window handle in LightweightFrameWrapper class by using JNI call in FX http://cr.openjdk.java.net/~psadhukhan/fxswing.14/ Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 Regards Prasanta On 5/30/2018 4:13 AM, Philip Race wrote: > Some follow up comments. > > On 5/10/18, 5:49 PM, Philip Race wrote: >> I've looked over the Swing code. No time to actually try it out so I >> can only comment on what I see. >> >> I am not sure what I think about class docs like "This class wraps >> .." >> I know no javadoc is generated but this module is exported and >> probably should say something >> less specific. >> >> In general I really have to hold my nose when looking at this whole >> module and I >> find it distasteful to endorse it. >> >> I really don't like all the things SwingInterOpUtils.java does. >> > Specific things we should look at in this file > - getDefaultScaleX/Y .. JDK 9 will set a transform on the graphics that > is passed to JComponent.paintComponent() .. so I wonder if we really > need this internal API. I doubt any other code is updating the transform > in a way that would make it a problem so the information you get > should be valid. > > The code to get the data array for the raster and associated information > can be extracted via standard API like this : > > DataBuffer? db = BufferedImage.getRaster().getDataBuffer(); > if (db instanceof DataBufferInt) { > ?data = (DataBufferInt)db.getData(); > } > > So all of those can be fixed. > > The code that accepts a native window handle maybe should require it > is accessed via JNI ... > It could still be unsupported, but it would be package private or similar. > If you have a native ID, then you are already using native code. > This sidesteps any questions about the stability of such an API which > accepts a native resource. > > The code that finds a component by location is probably harmless ... > > I'm less sure about the event posting and focus grabbing support. > I'd like to have Sergey comment on those. > > the DnD code is too much for me to examine in detail. >> I worry we are creating something we'll come to regret here. >> The "unsupportedness" needs to be backed up by deprecated-for-removal >> being included >> today so we can get rid of it the next release if we want to. > > I've looked at jdk.unsupported and they don't seem to have deprecation > tags so > maybe that isn't an issue. > > -phil >> >> No @since tags anywhere.... >> >> -phil. >> >> On 5/10/18, 8:32 AM, Kevin Rushforth wrote: >>> I confirm that this fixes the issue. The interface change to make >>> the two static methods e instance methods is a good change in any case. >>> >>> I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me. >>> >>> -- Kevin >>> >>> >>> On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote: >>>> >>>> Hi Kevin,All, >>>> >>>> Please find the modified webrev fixing this #1 issue >>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.13/ >>>> via change in >>>> jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext >>>> and FXDnD.java#postDropTargetEvent >>>> >>>> For me, #2 works, #3 doesn't work even now due to JDK-8141391 >>>> and #4 works for me. >>>> >>>> Regards >>>> Prasanta >>>> On 5/9/2018 11:29 PM, Kevin Rushforth wrote: >>>>> Hi Prasanta, >>>>> >>>>> The API looks good now. >>>>> >>>>> All of our automated tests work (except for the ones with a >>>>> security manager due to JDK-8202451 >>>>> ). >>>>> >>>>> The only functional problem that I see is that Drag and Drop onto >>>>> a SwingNode doesn't work. We need to make sure that we test the >>>>> following four cases: >>>>> >>>>> 1. Drag / drop onto a Swing component in a SwingNode >>>>> 2. Drag / drop from a Swing component in a SwingNode >>>>> 3. Drag / drop onto a JavaFX control in a JFXPanel >>>>> 4. Drag / drop from a JavaFX control in a JFXPanel >>>>> >>>>> So far I only tried the first one; the others still need to be >>>>> validated. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote: >>>>>> Modified webrev to cater to this >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.12/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 5/9/2018 5:58 PM, Kevin Rushforth wrote: >>>>>>> The following can also be abstract: >>>>>>> >>>>>>> LightweightContentWrapper: >>>>>>> ? getComponent, createDragGestureRecognizer, >>>>>>> createDragSourceContextPeer >>>>>>> >>>>>>> DropTargetContextWrapper: >>>>>>> ? getTargetActions, getDropTarget, getTransferDataFlavors, >>>>>>> getTransferable, isTransferableJVMLocal >>>>>>> >>>>>>> DispatcherWrapper: >>>>>>> ? isDispatchThread, createSecondaryLoop >>>>>>> >>>>>>> The rest looks good to me (although I still see two public >>>>>>> methods with "Peer" in the name, so Phil may want those renamed). >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: >>>>>>>> Modified webrev to cater to these 3 observations >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> >>>>>>>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >>>>>>>>> The module definition for jdk.unsupported.desktop and the >>>>>>>>> changes to java.desktop look fine. >>>>>>>>> >>>>>>>>> In reviewing the jdk.swing.interop API, I have the following >>>>>>>>> suggestions / observations: >>>>>>>>> >>>>>>>>> 1. DispatcherWrapper, DragSourceContextWrapper, >>>>>>>>> DropTargetContextWrapper, and LightweightContentWrapper can >>>>>>>>> all be abstract, along with most of the methods (rather than >>>>>>>>> having an empty body return value that is never used). >>>>>>>>> >>>>>>>>> 2. The addNotify method in LightweightFrameWrapper is unused. >>>>>>>>> Should be used somewhere? If not, then it can be removed. >>>>>>>>> >>>>>>>>> The implementation of the new wrapper classes looks OK to me >>>>>>>>> with one observation that might or might not matter: >>>>>>>>> >>>>>>>>> 3. The behavior of getDefaultScaleX/Y (which is now in >>>>>>>>> SwingInteropUtils) has changed in the case where the Graphics >>>>>>>>> is not an instance of SunGraphics2D. The former behavior was >>>>>>>>> to leave the instance variables X and Y unchanged. The new >>>>>>>>> behavior will set them back to 1.0. Maybe this can't happen in >>>>>>>>> practice, but it is something to consider. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>>>>>>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>>>>>>>>> Modified webrev to rename to InteropProviderImpl >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>>>>>>>>> This looks okay to me. >>>>>>>>>> >>>>>>>>>> -Alan >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> From haenel at ultramixer.com Wed Jun 13 07:55:08 2018 From: haenel at ultramixer.com (=?utf-8?Q?Matthias_H=C3=A4nel?=) Date: Wed, 13 Jun 2018 09:55:08 +0200 Subject: negative line spacing in Text Message-ID: Hey guys, since Java 8 all javafx multiline text controls (Label, TextArea, TextFlow) support linespacing via the css -fx-line-spacing attribute and Properties (on TextArea on Text-Node of Skin accessible via lookup). However none of them seem to support negative value which would be necessary to achieve a linespacing smaller then the default, since default value is 0. If a negative value is used, e.g. for a Labels line spacing, it will simply not wrap or line feed(\n). Is there a way to achieve a line spacing smaller than the default with these components? Thank you in advance Matthias -- Matthias H?nel haenel at onexip.com onexip GmbH Am Waldschloesschen 2 | D-01099 Dresden | Germany http://www.ultramixer.com http://www.onexip.com From pankaj.b.bansal at oracle.com Wed Jun 13 09:44:44 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Wed, 13 Jun 2018 02:44:44 -0700 (PDT) Subject: [11] JDK-8204635: [Linux] getMouseX, getMouseY in gtk GlassRobot.cpp ignore the HiDPI scale Message-ID: <0806809b-b89e-4c15-b08e-8d922e4e3ce7@default> Hi Kevin & Murali, Please review this fix, Webrev: http://cr.openjdk.java.net/~pbansal/8204635/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8204635 Regards, Pankaj From philip.race at oracle.com Wed Jun 13 18:17:39 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 13 Jun 2018 11:17:39 -0700 Subject: JDK-8187100 [PATCH][JavaFX] To make display Variation Selector(IVS/SVS/FVS) In-Reply-To: References: Message-ID: <1b91f973-825e-58b9-217e-b8a034cf4ba2@oracle.com> Hi, As I said in response to your email on the 2D list, you need to sign the OCA before we can consider any of this. -phil. On 06/13/2018 12:40 AM, Nakajima Akira wrote: > I happened to create similar patch without knowing the report below. > https://bugs.openjdk.java.net/browse/JDK-8187100 > > ====================================================== > Difference with following SWING patch and my JavaFX patch. > http://cr.openjdk.java.net/~srl/8187100/webrev.00/ > > 1. For Acceleration and Memory saving, load only partial glyphs table. > javafx.graphics/src/main/java/com/sun/javafx/font/CMap.java > > + if (numMappings[i] > 0 && (uniStart[i] == null || > glyphID[i] == null)) { > + try { > + initNonDef(i); > > > 2. Mongolian support > javafx.graphics/src/main/java/com/sun/javafx/text/ScriptMapper.java > > + else if (code <= 0x18af) { // 1800 - 18AF Mongolian > (including FVS) > + return true; > + } > > > 3. Fix 2 bugs on Windows (See below bugs) > > > ====================================================== > This JavaFX patch fixes following 4 bugs. > > 1. To make display IVS/SVS > Sample is kami.java and kami2.java > > javafx.graphics/src/main/java/com/sun/javafx/font/CMap.java > javafx.graphics/src/main/java/com/sun/javafx/font/CharToGlyphMapper.java > javafx.graphics/src/main/java/com/sun/javafx/font/CompositeGlyphMapper.java > > javafx.graphics/src/main/java/com/sun/javafx/font/OpenTypeGlyphMapper.java > > > > > 2. To make dislpay Mongolian and FVS > Sample is mongol.java > > javafx.graphics/src/main/java/com/sun/javafx/text/ScriptMapper.java > > > > 3. Fix bug to handle minus value glyph_id on Windows > (You run NG.java, then Java aborted) > Sample is NG.java > > javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > > javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > > > > > 4. Fix bug to display INVISIBLE_GLYPH on Windows (Now display square > box. No need to display.) > > javafx.graphics/src/main/java/com/sun/prism/sw/SWGraphics.java > > > ====================================================== > I checked this patch on CentOS 7.5 and Windows7 x64. > > > ==================== > PATCH > ==================== > diff -r 284d06bb1364 > modules/javafx.graphics/src/main/java/com/sun/javafx/font/CMap.java > --- > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/CMap.java > Tue Jun 12 14:40:17 2018 +0530 > +++ > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/CMap.java > Wed Jun 13 14:52:07 2018 +0900 > @@ -42,12 +42,13 @@ > abstract class CMap { > > static final char noSuchChar = (char)0xfffd; > + static final int BYTEMASK = 0x000000ff; > static final int SHORTMASK = 0x0000ffff; > static final int INTMASK = 0xffffffff; > > private static final int MAX_CODE_POINTS = 0x10ffff; > > - static CMap initialize(PrismFontFile font) { > + static CMap initialize(PrismFontFile font, int[] offset_format, > int create_cmap) { > > CMap cmap = null; > > @@ -59,6 +60,11 @@ > Buffer cmapBuffer = font.readTable(FontConstants.cmapTag); > short numberSubTables = cmapBuffer.getShort(2); > > + /* create CMap14 */ > + if (create_cmap == 14 && offset_format[0] != 0) { > + return createCMap(cmapBuffer, offset_format[0]); > + } > + > /* Locate the offsets of supported 3,* Microsoft platform > encodings, > * and any 0,* Unicode platform encoding. The latter is used by > * all current OS X fonts that don't have a Microsoft cmap. > @@ -76,6 +82,9 @@ > zeroStar = true; > encodingID = cmapBuffer.getShort(); > zeroStarOffset = cmapBuffer.getInt(); > + if (encodingID == 5) { > + offset_format[0] = zeroStarOffset; > + } > } > else if (platformID == 3) { > threeStar = true; > @@ -133,6 +142,7 @@ > case 8: return new CMapFormat8(buffer, offset); > case 10: return new CMapFormat10(buffer, offset); > case 12: return new CMapFormat12(buffer, offset); > + case 14: return new CMapFormat14(buffer, offset); > default: throw new RuntimeException("Cmap format > unimplemented: " + > (int)buffer.getChar(offset)); > } > @@ -140,6 +150,13 @@ > > abstract char getGlyph(int charCode); > > + char getGlyph(int charCode, int vs) { > + return getGlyph(charCode); > + } > + > + void setDefCMap(CMap defCmap) { > + } > + > /* Format 4 Header is > * ushort format (off=0) > * ushort length (off=2) > @@ -207,6 +224,7 @@ > char ctmp = buffer.getChar(); > idRangeOffset[i] = (char)((ctmp>>1)&0xffff); > } > + > /* Can calculate the number of glyph IDs by subtracting > * "pos" from the length of the cmap > */ > @@ -591,6 +609,191 @@ > > } > > + // Format 14: Table for Variation Selector (SVS and IVS) > + static class CMapFormat14 extends CMap { > + > + Buffer buffer; > + int offset; > + > + int numSelector; > + int[] varSelector; > + > + /* default glyphs */ > + int[] defaultOff, numRanges; > + int[][] defUniStart; > + short[][] additionalCnt; > + > + /* non default glyphs */ > + int[] nonDefOff, numMappings; > + int[][] uniStart, glyphID; > + /* e.g. > + * uniStart[numSelector-1] = U+e0100 > + * uniStart[numSelector-1][numMappings-1] = U+795e > + * glyphID[numSelector-1][numMappings-1] = 12345 > + */ > + > + CMap defCmap; > + void setDefCMap(CMap cmap) { > + this.defCmap = cmap; > + } > + > + CMapFormat14(Buffer buffer, int offset) { > + this.buffer = buffer; > + this.offset = offset; > + > + buffer.position(offset+6); > + /* get count of Variation Selector */ > + numSelector = buffer.getInt(); > + > + varSelector = new int[numSelector]; // e.g. {0xfe00, > 0xe0100, 0xe0101} > + defaultOff = new int[numSelector]; > + nonDefOff = new int[numSelector]; > + > + /* get Variation Selector and Table offset */ > + for (int i=0; i + varSelector[i] = ((buffer.getShort() & SHORTMASK)<<8) > | (buffer.get() & BYTEMASK); > + defaultOff[i] = buffer.getInt(); > + nonDefOff[i] = buffer.getInt(); > + } > + > + numMappings = new int[numSelector]; > + uniStart = new int[numSelector][]; > + glyphID = new int[numSelector][]; > + > + /* nonDefault glyphs table, get Unicode and glyphID */ > + for (int i=0; i + if (nonDefOff[i] == 0) { > + numMappings[i] = 0; > + continue; > + } > + buffer.position(offset+nonDefOff[i]); > + numMappings[i] = buffer.getInt(); > + } > + > + numRanges = new int[numSelector]; > + defUniStart = new int[numSelector][]; > + additionalCnt = new short[numSelector][]; > + > + /* Default glyphs table, get Unicode and count */ > + for (int i=0; i + if (defaultOff[i] == 0) { > + numRanges[i] = 0; > + continue; > + } > + buffer.position(offset+defaultOff[i]); > + numRanges[i] = buffer.getInt(); > + } > + } > + > + /* init Non Default Glyphs Table of pointed VS(e.g. fe00, > e0100.) */ > + void initNonDef(int i) { > + /* nonDefault glyphs table, get Unicode and glyphID */ > + buffer.position(offset+nonDefOff[i]+4); // +4 = skip > numMappings > + uniStart[i] = new int[numMappings[i]]; > + glyphID[i] = new int[numMappings[i]]; > + > + for (int j=0; j + uniStart[i][j] = ((buffer.getShort() & SHORTMASK)<<8) > | (buffer.get() & BYTEMASK); > + glyphID[i][j] = buffer.getShort() & SHORTMASK; > + } > + } > + > + void initDef(int i) { > + buffer.position(offset+defaultOff[i]+4); // +4 = skip > numRanges > + defUniStart[i] = new int[numRanges[i]]; > + additionalCnt[i] = new short[numRanges[i]]; > + > + for (int j=0; j + defUniStart[i][j] = ((buffer.getShort() & > SHORTMASK)<<8) | (buffer.get() & BYTEMASK); > + additionalCnt[i][j] = (short)(buffer.get() & BYTEMASK); > + } > + } > + > + final int findMapNumber_NonDef(int charCode, int i) { > + if (numMappings[i] > 0) { > + int min = 0, max, mid; > + max = numMappings[i]; > + while (min < max) { > + mid = (min+max) >> 1; > + if (charCode < uniStart[i][mid]) { > + max = mid; > + } else if (charCode > uniStart[i][mid]) { > + min = mid + 1; > + } else { > + return mid; > + } > + } > + } > + return -1; > + } > + > + final int findRangeNumber_Def(int charCode, int i) { > + if (numRanges[i] > 0) { > + int min = 0, max, mid; > + max = numRanges[i]; > + while (min < max) { > + mid = (min+max) >> 1; > + if (charCode < defUniStart[i][mid]) { > + max = mid; > + } else if (charCode > defUniStart[i][mid] + > additionalCnt[i][mid]) { > + min = mid + 1; > + } else { > + return mid; > + } > + } > + } > + return -1; > + } > + > + char getGlyph(int charCode) { > + return getGlyph(charCode, 0); > + } > + > + char getGlyph(int charCode, int vs) { > + if (vs == 0) return 0; > + > + int j; > + for (int i=0; i + if (varSelector[i] > vs) break; > + if (varSelector[i] != vs) continue; > + > + /* non default glyphs table */ > + if (numMappings[i] > 0 && (uniStart[i] == null || > glyphID[i] == null)) { > + try { > + initNonDef(i); > + } catch (Exception e) { > + return 0; > + } > + } > + > + /* search non default glyphs table */ > + j = findMapNumber_NonDef(charCode, i); > + if (j != -1) { > + return (char)glyphID[i][j]; > + } > + > + /* default glyphs table */ > + if (defCmap == null) break; // can't get glyphID by > default glyphs table > + if (numRanges[i] > 0 && (defUniStart[i] == null || > additionalCnt[i] == null)) { > + try { > + initDef(i); > + } catch (Exception e) { > + return 0; > + } > + } > + > + /* search default glyphs table */ > + if (defCmap == null) break; > + j = findRangeNumber_Def(charCode, i); > + if (j != -1) { > + return defCmap.getGlyph(charCode); > + } > + } > + > + return 0; > + } > + } > + > /* Used to substitute for bad Cmaps. */ > static class NullCMapClass extends CMap { > > diff -r 284d06bb1364 > modules/javafx.graphics/src/main/java/com/sun/javafx/font/CharToGlyphMapper.java > --- > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/CharToGlyphMapper.java > Tue Jun 12 14:40:17 2018 +0530 > +++ > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/CharToGlyphMapper.java > Wed Jun 13 14:52:07 2018 +0900 > @@ -42,8 +42,66 @@ > public static final int MISSING_GLYPH = 0; > public static final int INVISIBLE_GLYPH_ID = 0xffff; > > + public static final int SVS_START = 0xFE00; // VS1 > + public static final int SVS_END = 0xFE0F; // VS16 > + public static final int IVS_START = 0xE0100; // VS17 > + public static final int IVS_END = 0xE01EF; // VS256 > + public static final int FVS_START = 0x180B; // FVS1 > + public static final int FVS_END = 0x180D; // FVS3 > + > protected int missingGlyph = MISSING_GLYPH; > > + /* http://www.unicode.org/versions/Unicode10.0.0/ch18.pdf */ > + public static boolean isCJK(int code) { > + if (code >= 0x4E00 && code <= 0x9FFF) // Unified Ideographs > + return true; > + if (code >= 0x3400 && code <= 0x4DBF) // Extension A > + return true; > + if (code >= 0x20000 && code <= 0x2A6DF) // Extension B > + return true; > + if (code >= 0x2A700 && code <= 0x2B73F) // Extension C > + return true; > + if (code >= 0x2B740 && code <= 0x2B81F) // Extension D > + return true; > + if (code >= 0x2B820 && code <= 0x2CEAF) // Extension E > + return true; > + if (code >= 0x2CEB0 && code <= 0x2EBE0) // Extension F > + return true; > + if (code >= 0xF900 && code <= 0xFAFF) // Compatibility > Ideographs > + return true; > + if (code >= 0x2F800 && code <= 0x2FA1F) // Compatibility > Ideographs Supplement > + return true; > + return false; > + } > + > + public static boolean isVS(int code) { > + if (isIVS(code)) > + return true; > + if (isSVS(code)) > + return true; > +// if (isFVS(code)) > +// return true; > + return false; > + } > + > + public static boolean isSVS(int code) { > + if (code >= SVS_START && code <= SVS_END) > + return true; > + return false; > + } > + > + public static boolean isIVS(int code) { > + if (code >= IVS_START && code <= IVS_END) > + return true; > + return false; > + } > + > +// public static boolean isFVS(int code) { > +// if (code >= FVS_START && code <= FVS_END) > +// return true; > +// return false; > +// } > + > public boolean canDisplay(char cp) { > int glyph = charToGlyph(cp); > return glyph != missingGlyph; > @@ -53,18 +111,28 @@ > return missingGlyph; > } > > - public abstract int getGlyphCode(int charCode); > + public abstract int getGlyphCode(int charCode, int vs); > > public int charToGlyph(char unicode) { > - return getGlyphCode(unicode); > + return getGlyphCode(unicode, (char)0); > + } > + > + public int charToGlyph(char unicode, char vs) { > + return getGlyphCode(unicode, vs); > } > > public int charToGlyph(int unicode) { > - return getGlyphCode(unicode); > + return getGlyphCode(unicode, 0); > + } > + > + public int charToGlyph(int unicode, int vs) { > + return getGlyphCode(unicode, vs); > } > > public void charsToGlyphs(int start, int count, char[] unicodes, > int[] glyphs, int glyphStart) { > + > + int codeWasSurrogate = 0; // store surrogate pair to handle > surrogate pair+VS > for (int i=0; i int code = unicodes[start + i]; // char is unsigned. > if (code >= HI_SURROGATE_START && > @@ -75,13 +143,67 @@ > low <= LO_SURROGATE_END) { > code = ((code - HI_SURROGATE_START) << > HI_SURROGATE_SHIFT) + > low - LO_SURROGATE_START + SURROGATES_START; > - glyphs[glyphStart + i] = getGlyphCode(code); > + > + if (isIVS(code) && i > 0 && > + ((codeWasSurrogate == 0 && > isCJK((int)unicodes[start + i -1])) || > + codeWasSurrogate != 0)) { > + int glyph; > + if (codeWasSurrogate == 0) { > + glyph = getGlyphCode((int)unicodes[start > + i -1], code); // IVS > + } else { > + glyph = getGlyphCode(codeWasSurrogate, > code); // surrogate pair+IVS > + } > + if (glyph == missingGlyph) { > + glyphs[glyphStart + i] = missingGlyph; > + } else { > + if (codeWasSurrogate == 0) { > + glyphs[glyphStart + i - 1] = glyph; > + glyphs[glyphStart + i] = > INVISIBLE_GLYPH_ID; > + } else { > + glyphs[glyphStart + i - 2] = glyph; > + glyphs[glyphStart + i - 1] = > INVISIBLE_GLYPH_ID; > + glyphs[glyphStart + i] = > INVISIBLE_GLYPH_ID; > + } > + } > + codeWasSurrogate = 0; > + } else { // surrogate pair > + glyphs[glyphStart + i] = getGlyphCode(code, 0); > + if (isIVS(code) == false) { > + codeWasSurrogate = code; // store > surrogate pair > + } > + } > + > i += 1; // Empty glyph slot after surrogate > glyphs[glyphStart + i] = INVISIBLE_GLYPH_ID; > continue; > } > + } else if (isSVS(code) && i > 0 && > + ((codeWasSurrogate == 0 && > isCJK((int)unicodes[start + i -1])) || > + codeWasSurrogate != 0)) { > + int glyph; > + if (codeWasSurrogate == 0) { > + glyph = getGlyphCode((int)unicodes[start + i -1], > code); // SVS > + } else { > + glyph = getGlyphCode(codeWasSurrogate, code); // > surrogate pair+SVS > + } > + if (glyph == missingGlyph) { > + glyphs[glyphStart + i] = missingGlyph; > + } else { > + if (codeWasSurrogate == 0) { > + glyphs[glyphStart + i - 1] = glyph; > + glyphs[glyphStart + i] = INVISIBLE_GLYPH_ID; > + } else { > + glyphs[glyphStart + i - 2] = glyph; > + glyphs[glyphStart + i - 1] = INVISIBLE_GLYPH_ID; > + glyphs[glyphStart + i] = INVISIBLE_GLYPH_ID; > + } > + } > + codeWasSurrogate = 0; > + continue; > } > - glyphs[glyphStart + i] = getGlyphCode(code); > + > + glyphs[glyphStart + i] = getGlyphCode(code, 0); > + codeWasSurrogate = 0; > } > } > > diff -r 284d06bb1364 > modules/javafx.graphics/src/main/java/com/sun/javafx/font/CompositeGlyphMapper.java > --- > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/CompositeGlyphMapper.java > Tue Jun 12 14:40:17 2018 +0530 > +++ > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/CompositeGlyphMapper.java > Wed Jun 13 14:52:07 2018 +0900 > @@ -31,6 +31,7 @@ > > public static final int SLOTMASK = 0xff000000; > public static final int GLYPHMASK = 0x00ffffff; > + public static final long LONGMASK = 0x00000000ffffffffL; > > public static final int NBLOCKS = 216; > public static final int BLOCKSZ = 256; > @@ -54,11 +55,17 @@ > * the caching ? So a variety of strategies are possible. > */ > HashMap glyphMap; > + HashMap glyphMapVS; // HashMap for Variation Selector > + > + public static long shiftVS_for_HashMap(int code) { > + return (long)code << 32; > + } > > public CompositeGlyphMapper(CompositeFontResource compFont) { > font = compFont; > missingGlyph = 0; // TrueType font standard, avoids lookup. > glyphMap = new HashMap(); > + glyphMapVS = new HashMap(); > slotMappers = new CharToGlyphMapper[compFont.getNumSlots()]; > asciiCacheOK = true; > } > @@ -90,17 +97,35 @@ > return ((slot) << 24 | (glyphCode & GLYPHMASK)); > } > > - private final int convertToGlyph(int unicode) { > + public static final int compGlyphToSlot(int compGlyphCode) { > + return (compGlyphCode >> 24); > + } > + > + public static final int compGlyphToGlyph(int compGlyphCode) { > + return (compGlyphCode & GLYPHMASK); > + } > + > + private final int convertToGlyph(int unicode, int vs) { > for (int slot = 0; slot < font.getNumSlots(); slot++) { > CharToGlyphMapper mapper = getSlotMapper(slot); > - int glyphCode = mapper.charToGlyph(unicode); > + int glyphCode = mapper.charToGlyph(unicode, vs); > + > if (glyphCode != mapper.getMissingGlyphCode()) { > glyphCode = compositeGlyphCode(slot, glyphCode); > - glyphMap.put(unicode, glyphCode); > + if (vs == 0 || CharToGlyphMapper.isVS(vs) == false) { > + glyphMap.put(unicode, glyphCode); > + } else { > + glyphMapVS.put(shiftVS_for_HashMap(vs) | (unicode > & LONGMASK), glyphCode); > + } > return glyphCode; > } > } > - glyphMap.put(unicode, missingGlyph); > + if (vs == 0 || CharToGlyphMapper.isVS(vs) == false) { > + glyphMap.put(unicode, missingGlyph); > + } else { > + glyphMapVS.put(shiftVS_for_HashMap(vs) | (unicode & > LONGMASK), missingGlyph); > + } > + > return missingGlyph; > } > > @@ -137,18 +162,22 @@ > return charToGlyph[index]; > } > > - public int getGlyphCode(int charCode) { > + public int getGlyphCode(int charCode, int vs) { > // If ASCII then array lookup, else use glyphMap > int retVal = getAsciiGlyphCode(charCode); > if (retVal >= 0) { > return retVal; > } > - > - Integer codeInt = glyphMap.get(charCode); > + Integer codeInt; > + if (vs == 0 || CharToGlyphMapper.isVS(vs) == false) { > + codeInt = glyphMap.get(charCode); > + } else { > + codeInt = glyphMapVS.get(shiftVS_for_HashMap(vs) | > (charCode & LONGMASK)); > + } > if (codeInt != null) { > return codeInt.intValue(); > } else { > - return convertToGlyph(charCode); > + return convertToGlyph(charCode, vs); > } > } > } > diff -r 284d06bb1364 > modules/javafx.graphics/src/main/java/com/sun/javafx/font/OpenTypeGlyphMapper.java > --- > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/OpenTypeGlyphMapper.java > Tue Jun 12 14:40:17 2018 +0530 > +++ > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/OpenTypeGlyphMapper.java > Wed Jun 13 14:52:07 2018 +0900 > @@ -29,11 +29,14 @@ > > PrismFontFile font; > CMap cmap; > + int offset_format[] = {0}; // offset of format14 > + CMap cmap14; > > public OpenTypeGlyphMapper(PrismFontFile font) { > this.font = font; > + offset_format[0] = 0; > try { > - cmap = CMap.initialize(font); > + cmap = CMap.initialize(font, offset_format, -1); > } catch (Exception e) { > cmap = null; > } > @@ -43,13 +46,38 @@ > missingGlyph = 0; /* standard for TrueType fonts */ > } > > - public int getGlyphCode(int charCode) { > - try { > - return cmap.getGlyph(charCode); > - } catch(Exception e) { > - handleBadCMAP(); > - return missingGlyph; > + public CMap createCMap14() { > + if (cmap14 == null && offset_format[0] != 0) { > + try { > + cmap14 = CMap.initialize(font, offset_format, 14); > + } catch (Exception e) { > + cmap14 = null; > + } > + if (cmap14 != null) { > + cmap14.setDefCMap(this.cmap); > + } > + offset_format[0] = 0; > } > + return cmap14; > + } > + > + public int getGlyphCode(int charCode, int vs) { > + if (vs == 0) { > + try { > + return cmap.getGlyph(charCode); > + } catch(Exception e) { > + handleBadCMAP(); > + return missingGlyph; > + } > + } else if (createCMap14() != null) { > + try { > + return cmap14.getGlyph(charCode, vs); > + } catch(Exception e) { > + handleBadCMAP14(); > + return missingGlyph; > + } > + } > + return missingGlyph; > } > > private void handleBadCMAP() { > @@ -57,6 +85,10 @@ > cmap = CMap.theNullCmap; > } > > + private void handleBadCMAP14() { > + cmap14 = CMap.theNullCmap; > + } > + > /* A pretty good heuristic is that the cmap we are using > * supports 32 bit character codes. > */ > diff -r 284d06bb1364 > modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > --- > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > Tue Jun 12 14:40:17 2018 +0530 > +++ > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > Wed Jun 13 14:52:07 2018 +0900 > @@ -52,6 +52,7 @@ > private static D2D1_COLOR_F WHITE = new D2D1_COLOR_F(1f, 1f, 1f, > 1f); > private static D2D1_MATRIX_3X2_F D2D2_MATRIX_IDENTITY = new > D2D1_MATRIX_3X2_F(1,0, 0,1, 0,0); > > + static final int intMask = 0x0000ffff; > > DWGlyph(DWFontStrike strike, int glyphCode, boolean drawShapes) { > this.strike = strike; > @@ -303,12 +304,12 @@ > > @Override > public int getGlyphCode() { > - return run.glyphIndices; > + return ((int)run.glyphIndices & intMask); > } > > @Override > public RectBounds getBBox() { > - return strike.getBBox(run.glyphIndices); > + return strike.getBBox((int)run.glyphIndices & intMask); > } > > @Override > @@ -321,7 +322,7 @@ > > @Override > public Shape getShape() { > - return strike.createGlyphOutline(run.glyphIndices); > + return strike.createGlyphOutline((int)run.glyphIndices & > intMask); > } > > @Override > diff -r 284d06bb1364 > modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > --- > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > Tue Jun 12 14:40:17 2018 +0530 > +++ > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > Wed Jun 13 14:52:07 2018 +0900 > @@ -138,6 +138,7 @@ > int i, j; > int[] iglyphs = new int[glyphCount]; > int slotMask = slot << 24; > + final int intMask = 0x0000ffff; > boolean missingGlyph = false; > i = 0; j = rtl ? glyphCount - 1 : 0; > while (i < glyphCount) { > @@ -145,7 +146,7 @@ > missingGlyph = true; > if (composite) break; > } > - iglyphs[i] = glyphs[j] | slotMask; > + iglyphs[i] = ((int)glyphs[j] & intMask) | slotMask; > i++; > j+=step; > } > diff -r 284d06bb1364 > modules/javafx.graphics/src/main/java/com/sun/javafx/text/ScriptMapper.java > --- > a/modules/javafx.graphics/src/main/java/com/sun/javafx/text/ScriptMapper.java > Tue Jun 12 14:40:17 2018 +0530 > +++ > b/modules/javafx.graphics/src/main/java/com/sun/javafx/text/ScriptMapper.java > Wed Jun 13 14:52:07 2018 +0900 > @@ -154,6 +154,9 @@ > else if (code <= 0x17ff) { // 1780 - 17FF Khmer > return true; > } > + else if (code <= 0x18af) { // 1800 - 18AF Mongolian > (including FVS) > + return true; > + } > else if (code < 0x200c) { > return false; > } > diff -r 284d06bb1364 > modules/javafx.graphics/src/main/java/com/sun/prism/sw/SWGraphics.java > --- > a/modules/javafx.graphics/src/main/java/com/sun/prism/sw/SWGraphics.java > Tue Jun 12 14:40:17 2018 +0530 > +++ > b/modules/javafx.graphics/src/main/java/com/sun/prism/sw/SWGraphics.java > Wed Jun 13 14:52:07 2018 +0900 > @@ -62,6 +62,8 @@ > import com.sun.prism.paint.ImagePattern; > import com.sun.prism.paint.Paint; > > +import com.sun.javafx.font.CharToGlyphMapper; > + > final class SWGraphics implements ReadbackGraphics { > > private static final BasicStroke DEFAULT_STROKE = > @@ -630,6 +632,9 @@ > > final Glyph g = strike.getGlyph(gl.getGlyphCode(idx)); > if (drawAsMasks) { > + if (g.getGlyphCode() == > CharToGlyphMapper.INVISIBLE_GLYPH_ID) { > + return; > + } > final Point2D pt = new Point2D((float)(x + tx.getMxt() + > gl.getPosX(idx)), > (float)(y + tx.getMyt() + > gl.getPosY(idx))); > int subPixel = strike.getQuantizedPosition(pt); > > > > > > > ==================== > Sample (kami.java) > ==================== > import javafx.application.Application; > import static javafx.application.Application.launch; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.paint.Color; > import javafx.scene.text.Font; > import javafx.scene.text.Text; > import javafx.scene.text.TextFlow; > import javafx.stage.Stage; > > public class kami extends Application { > > @Override > public void start(Stage stage) throws Exception { > > // You need to install ipamjm font > String family = "IPAmjMincho"; // for Linux > // String family = "IPAmj??"; // for Windows > > Text text[] = new Text[3]; > text[0] = new Text("\u795E+VS1 --> \u795E\uFE00\n"); // FVS > text[1] = new Text("\u795E+VS20 --> \u795E\uDB40\uDD03\n"); // IVS > text[2] = new Text("\uD87A\uDF79+VS17 --> > \uD87A\uDF79\uDB40\uDD01\n"); // Surrogate Pair+IVS > > for (int i=0; i<3; i++) { > text[i].setFill(Color.BLACK); > text[i].setFont(Font.font(family, 48)); > } > TextFlow textFlow = new TextFlow(text[0], text[1], text[2]); > textFlow.setLayoutX(60); > textFlow.setLayoutY(60); > > Group group = new Group(textFlow); > Scene scene = new Scene(group, 450, 250, Color.WHITE); > stage.setScene(scene); > stage.show(); > } > } > > > > > > ==================== > Sample (kami2.java) > ==================== > import javafx.application.Application; > import javafx.geometry.Insets; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.control.Label; > import javafx.scene.control.TextArea; > import javafx.scene.layout.GridPane; > import javafx.stage.Stage; > import javafx.scene.text.Text; > import javafx.scene.text.Font; > > public class kami2 extends Application { > public static void main(String[] args) { > launch(args); > } > @Override > public void start(Stage stage) { > // You need to install ipamjm font > String family = "IPAmjMincho"; // for Linux > // String family = "IPAmj??"; // for Windows > > Scene scene = new Scene(new Group(), 650, 300); > > String str[] = new String[3]; > str[0] = new String("\u795E+VS1 --> \u795E\uFE00\n"); // FVS > str[1] = new String("\u795E+VS20 --> \u795E\uDB40\uDD03\n"); // IVS > str[2] = new String("\uD87A\uDF79+VS17 --> > \uD87A\uDF79\uDB40\uDD01\n"); // Surrogate Pair+IVS > > String str_for_area = new String(""); > for (int i=0; i<3; i++) { > str_for_area += str[i].toString(); > } > > TextArea area = new TextArea(str_for_area); > area.setFont(Font.font(family, 48)); > area.setPrefWidth(600); > area.setPrefHeight(250); > area.setPrefColumnCount(3); > > GridPane grid = new GridPane(); > grid.setVgap(4); > grid.setHgap(10); > grid.setPadding(new Insets(5, 5, 5, 5)); > grid.add(area, 1, 0); > > Group root = (Group) scene.getRoot(); > root.getChildren().add(grid); > stage.setScene(scene); > stage.show(); > } > } > > > > ==================== > Sample (mongol.java) > ==================== > import javafx.application.Application; > import static javafx.application.Application.launch; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.paint.Color; > import javafx.scene.text.Font; > import javafx.scene.text.Text; > import javafx.scene.text.TextFlow; > import javafx.stage.Stage; > > public class mongol extends Application { > > @Override > public void start(Stage stage) throws Exception { > > // http://www.mongolfont.com/en/font/mnglartotf.html > String family = "Mongolian Art"; > double size = 48; > > // Correct mongolian form > // http://www.unicode.org/versions/Unicode10.0.0/ch13.pdf#G27803 > Text text[] = new Text[9]; > text[0] = new Text("? ? ? ? --> ???? (urtu)\n"); > text[1] = new Text("? ? ? ? --> ???? (ordu)\n"); > text[2] = new Text("? ? ? ? --> ???? (ende)\n"); > text[3] = new Text("? ? ? --> ??? (ada)\n"); > text[4] = new Text("? ? ? --> ??? (abu)\n"); > text[5] = new Text("? ? ? --> ??? (odo)\n"); > text[6] = new Text("? ? ? --> ??? (ene)\n"); > text[7] = new Text("? ? --> ?? (gal)\n"); > text[8] = new Text("?? ? --> ??? (gal+U+180B)\n"); > > for (int i=0; i<9; i++) { > text[i].setFill(Color.BLACK); > text[i].setFont(Font.font(family, size)); > } > TextFlow textFlow = new TextFlow(text[0], text[1], text[2], > text[3], text[4], text[5], text[6], text[7], text[8]); > textFlow.setLayoutX(60); > textFlow.setLayoutY(60); > > Group group = new Group(textFlow); > Scene scene = new Scene(group, 600, 650, Color.WHITE); > stage.setScene(scene); > stage.show(); > } > } > > > > > ==================== > Sample (NG.java) > ==================== > import javafx.application.Application; > import static javafx.application.Application.launch; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.paint.Color; > import javafx.scene.text.Font; > import javafx.scene.text.Text; > import javafx.scene.text.TextFlow; > import javafx.stage.Stage; > > // Run on Windows, then Java abort because of bug. > public class NG extends Application { > @Override > public void start(Stage stage) throws Exception { > > String family = "Arial Unicode MS"; > double size = 36; > > TextFlow textFlow = new TextFlow(); > textFlow.setLayoutX(60); > textFlow.setLayoutY(60); > > // Unicode(GlyphID) > Text text = new Text("??"); // U+2F9D4(49496) + U+0E3F(1262) > /* Inside JavaFX, 49496(Uint16) is handled as -16040(short). > * By ScriptMapper.isComplexCharCode(), U+0E3F is handled as complex. > * When in condition with minus glyphID value and complex > * , JavaFX is forcibly terminated. > * (java.lang.ArrayIndexOutOfBoundsException) > */ > > text.setFill(Color.GREEN); > text.setFont(Font.font(family, size)); > textFlow.getChildren().addAll(text); > > Group group = new Group(textFlow); > Scene scene = new Scene(group, 1200, 300, Color.WHITE); > stage.setScene(scene); > stage.show(); > } > } > > > > > -------------------------------------- > Name: Akira Nakajima > E-Mail: nakajima.akira at nttcom.co.jp > -------------------------------------- > From philip.race at oracle.com Wed Jun 13 22:49:45 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 13 Jun 2018 15:49:45 -0700 Subject: negative line spacing in Text In-Reply-To: References: Message-ID: I looked at the source and it is a double property that is just added to the default line height So I don't see why it would just cause line wrap to fail such that text was all on the same line, which is how I am interpreting what you are saying. Perhaps if you are using too large a negative value something I'm overlooking is clamping it .. FWIW line-spacing is not a W3C CSS property so far as I can tell, so it is just FX CSS There is line-height in the W3C spec but it is specified differently. -phil. On 06/13/2018 12:55 AM, Matthias H?nel wrote: > Hey guys, > > since Java 8 all javafx multiline text controls (Label, TextArea, TextFlow) support linespacing via the css -fx-line-spacing attribute and Properties (on TextArea on Text-Node of Skin accessible via lookup). > However none of them seem to support negative value which would be necessary to achieve a linespacing smaller then the default, since default value is 0. > If a negative value is used, e.g. for a Labels line spacing, it will simply not wrap or line feed(\n). > Is there a way to achieve a line spacing smaller than the default with these components? > > Thank you in advance > Matthias > -- > Matthias H?nel > haenel at onexip.com > > onexip GmbH > Am Waldschloesschen 2 | D-01099 Dresden | Germany > > http://www.ultramixer.com > http://www.onexip.com > > > > From kevin.rushforth at oracle.com Thu Jun 14 01:04:51 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 13 Jun 2018 18:04:51 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> References: <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> Message-ID: The JDK changes look good to me, and as far as I have tested them, it works for me. I haven't tried Drag and Drop yet with the latest interface changes. To repeat something I've mentioned before, just so there is no confusion, the FX side of the changes are intended to be a proof of concept to test the JDK side at this point. They will need refactoring before they can go in, so that FX will still be buildable and runnable with JDK 10. -- Kevin On 6/13/2018 12:48 AM, Prasanta Sadhukhan wrote: > > Hi Phil, All > > Please find modified webrev taking care of streamlining > SwingInteropUtils class and handling of native window handle in > LightweightFrameWrapper class by using JNI call in FX > http://cr.openjdk.java.net/~psadhukhan/fxswing.14/ > > Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 > > Regards > Prasanta > On 5/30/2018 4:13 AM, Philip Race wrote: >> Some follow up comments. >> >> On 5/10/18, 5:49 PM, Philip Race wrote: >>> I've looked over the Swing code. No time to actually try it out so I >>> can only comment on what I see. >>> >>> I am not sure what I think about class docs like "This class wraps >>> .." >>> I know no javadoc is generated but this module is exported and >>> probably should say something >>> less specific. >>> >>> In general I really have to hold my nose when looking at this whole >>> module and I >>> find it distasteful to endorse it. >>> >>> I really don't like all the things SwingInterOpUtils.java does. >>> >> Specific things we should look at in this file >> - getDefaultScaleX/Y .. JDK 9 will set a transform on the graphics that >> is passed to JComponent.paintComponent() .. so I wonder if we really >> need this internal API. I doubt any other code is updating the transform >> in a way that would make it a problem so the information you get >> should be valid. >> >> The code to get the data array for the raster and associated information >> can be extracted via standard API like this : >> >> DataBuffer? db = BufferedImage.getRaster().getDataBuffer(); >> if (db instanceof DataBufferInt) { >> ?data = (DataBufferInt)db.getData(); >> } >> >> So all of those can be fixed. >> >> The code that accepts a native window handle maybe should require it >> is accessed via JNI ... >> It could still be unsupported, but it would be package private or >> similar. >> If you have a native ID, then you are already using native code. >> This sidesteps any questions about the stability of such an API which >> accepts a native resource. >> >> The code that finds a component by location is probably harmless ... >> >> I'm less sure about the event posting and focus grabbing support. >> I'd like to have Sergey comment on those. >> >> the DnD code is too much for me to examine in detail. >>> I worry we are creating something we'll come to regret here. >>> The "unsupportedness" needs to be backed up by >>> deprecated-for-removal being included >>> today so we can get rid of it the next release if we want to. >> >> I've looked at jdk.unsupported and they don't seem to have >> deprecation tags so >> maybe that isn't an issue. >> >> -phil >>> >>> No @since tags anywhere.... >>> >>> -phil. >>> >>> On 5/10/18, 8:32 AM, Kevin Rushforth wrote: >>>> I confirm that this fixes the issue. The interface change to make >>>> the two static methods e instance methods is a good change in any case. >>>> >>>> I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me. >>>> >>>> -- Kevin >>>> >>>> >>>> On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote: >>>>> >>>>> Hi Kevin,All, >>>>> >>>>> Please find the modified webrev fixing this #1 issue >>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.13/ >>>>> via change in >>>>> jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext >>>>> and FXDnD.java#postDropTargetEvent >>>>> >>>>> For me, #2 works, #3 doesn't work even now due to JDK-8141391 >>>>> and #4 works >>>>> for me. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 5/9/2018 11:29 PM, Kevin Rushforth wrote: >>>>>> Hi Prasanta, >>>>>> >>>>>> The API looks good now. >>>>>> >>>>>> All of our automated tests work (except for the ones with a >>>>>> security manager due to JDK-8202451 >>>>>> ). >>>>>> >>>>>> The only functional problem that I see is that Drag and Drop onto >>>>>> a SwingNode doesn't work. We need to make sure that we test the >>>>>> following four cases: >>>>>> >>>>>> 1. Drag / drop onto a Swing component in a SwingNode >>>>>> 2. Drag / drop from a Swing component in a SwingNode >>>>>> 3. Drag / drop onto a JavaFX control in a JFXPanel >>>>>> 4. Drag / drop from a JavaFX control in a JFXPanel >>>>>> >>>>>> So far I only tried the first one; the others still need to be >>>>>> validated. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote: >>>>>>> Modified webrev to cater to this >>>>>>> >>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.12/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 5/9/2018 5:58 PM, Kevin Rushforth wrote: >>>>>>>> The following can also be abstract: >>>>>>>> >>>>>>>> LightweightContentWrapper: >>>>>>>> ? getComponent, createDragGestureRecognizer, >>>>>>>> createDragSourceContextPeer >>>>>>>> >>>>>>>> DropTargetContextWrapper: >>>>>>>> ? getTargetActions, getDropTarget, getTransferDataFlavors, >>>>>>>> getTransferable, isTransferableJVMLocal >>>>>>>> >>>>>>>> DispatcherWrapper: >>>>>>>> ? isDispatchThread, createSecondaryLoop >>>>>>>> >>>>>>>> The rest looks good to me (although I still see two public >>>>>>>> methods with "Peer" in the name, so Phil may want those renamed). >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: >>>>>>>>> Modified webrev to cater to these 3 observations >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> >>>>>>>>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >>>>>>>>>> The module definition for jdk.unsupported.desktop and the >>>>>>>>>> changes to java.desktop look fine. >>>>>>>>>> >>>>>>>>>> In reviewing the jdk.swing.interop API, I have the following >>>>>>>>>> suggestions / observations: >>>>>>>>>> >>>>>>>>>> 1. DispatcherWrapper, DragSourceContextWrapper, >>>>>>>>>> DropTargetContextWrapper, and LightweightContentWrapper can >>>>>>>>>> all be abstract, along with most of the methods (rather than >>>>>>>>>> having an empty body return value that is never used). >>>>>>>>>> >>>>>>>>>> 2. The addNotify method in LightweightFrameWrapper is unused. >>>>>>>>>> Should be used somewhere? If not, then it can be removed. >>>>>>>>>> >>>>>>>>>> The implementation of the new wrapper classes looks OK to me >>>>>>>>>> with one observation that might or might not matter: >>>>>>>>>> >>>>>>>>>> 3. The behavior of getDefaultScaleX/Y (which is now in >>>>>>>>>> SwingInteropUtils) has changed in the case where the Graphics >>>>>>>>>> is not an instance of SunGraphics2D. The former behavior was >>>>>>>>>> to leave the instance variables X and Y unchanged. The new >>>>>>>>>> behavior will set them back to 1.0. Maybe this can't happen >>>>>>>>>> in practice, but it is something to consider. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>>>>>>>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>>>>>>>>>> Modified webrev to rename to InteropProviderImpl >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>>>>>>>>>> This looks okay to me. >>>>>>>>>>> >>>>>>>>>>> -Alan >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> > From pedro.duquevieira at gmail.com Thu Jun 14 12:50:06 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 14 Jun 2018 13:50:06 +0100 Subject: negative line spacing in Text Message-ID: I'm all in favor of following W3C CSS, but you can't specify negative values in W3C CSS line-height property either. The minimum value is 0 which just collapses everything into the same line, so negative values wouldn't make sense since it would layout the paragraph upside down. Cheers, I looked at the source and it is a double property that is just added to > the default line height > So I don't see why it would just cause line wrap to fail such that text > was all on the same line, > which is how I am interpreting what you are saying. > Perhaps if you are using too large a negative value something I'm > overlooking is clamping it .. > FWIW line-spacing is not a W3C CSS property so far as I can tell, so it > is just FX CSS > There is line-height in the W3C spec but it is specified differently. > -phil. -- Pedro Duque Vieira From ambarish.rapte at oracle.com Thu Jun 14 13:22:52 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Thu, 14 Jun 2018 06:22:52 -0700 (PDT) Subject: [11] RFR JDK-8204956 : Cleanup whitespace after fix for JDK-8200285 Message-ID: <134ad389-b254-46ab-a9dc-5f454ca0e3fe@default> Hi Kevin, Please review this correction fix : Bug: https://bugs.openjdk.java.net/browse/JDK-8204956 Webrev: http://cr.openjdk.java.net/~arapte/fx/8204956/webrev.00/ Regards, Ambarish From kevin.rushforth at oracle.com Thu Jun 14 13:33:09 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Jun 2018 06:33:09 -0700 Subject: [11] Review request: 8200446: Update minimum boot JDK to 10 Message-ID: Please review the following to bump the minimum boot JDK required for JavaFX builds to JDK 10. Note that the review will be done on github, but it is OK to reply to this thread with comments if you don't have a github account. https://bugs.openjdk.java.net/browse/JDK-8200446 https://github.com/javafxports/openjdk-jfx/pull/61 This also bumps the class file format to that of JDK 10. I note that we have been using JDK 10 to build the openjfx-11 builds for several months, and now that we've upgraded to gradle 4.8 we are ready to make JDK 10 the minimum. Once this is done, we can start using JDK 10 features, such as 'var' for local variables (although please don't take this as a license to use 'var' gratuitously). Thanks. -- Kevin From nlisker at gmail.com Thu Jun 14 13:37:18 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 14 Jun 2018 16:37:18 +0300 Subject: [11] Review request: 8200446: Update minimum boot JDK to 10 In-Reply-To: References: Message-ID: > > Once this is done, we can start using JDK 10 features, such as 'var' for > local variables (although please don't take this as a license to use 'var' > gratuitously). I'll remind that there's a style guide at http://openjdk.java.net/projects/amber/LVTIstyle.html. - Nir On Thu, Jun 14, 2018 at 4:33 PM, Kevin Rushforth wrote: > Please review the following to bump the minimum boot JDK required for > JavaFX builds to JDK 10. Note that the review will be done on github, but > it is OK to reply to this thread with comments if you don't have a github > account. > > https://bugs.openjdk.java.net/browse/JDK-8200446 > https://github.com/javafxports/openjdk-jfx/pull/61 > > This also bumps the class file format to that of JDK 10. I note that we > have been using JDK 10 to build the openjfx-11 builds for several months, > and now that we've upgraded to gradle 4.8 we are ready to make JDK 10 the > minimum. > > Once this is done, we can start using JDK 10 features, such as 'var' for > local variables (although please don't take this as a license to use 'var' > gratuitously). > > Thanks. > > -- Kevin > > From kevin.rushforth at oracle.com Thu Jun 14 14:25:54 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Jun 2018 07:25:54 -0700 Subject: [11] Review request: 8200446: Update minimum boot JDK to 10 In-Reply-To: References: Message-ID: <9dbe7169-bf1a-f351-346f-a0a03d4f636a@oracle.com> Thanks for the reminder. This is good advice that we should all strive to follow. -- Kevin On 6/14/2018 6:37 AM, Nir Lisker wrote: > > Once this is done, we can start using JDK 10 features, such as > 'var' for local variables (although please don't take this as a > license to use 'var' gratuitously). > > > I'll remind that there's a style guide at > http://openjdk.java.net/projects/amber/LVTIstyle.html. > > - Nir > > On Thu, Jun 14, 2018 at 4:33 PM, Kevin Rushforth > > wrote: > > Please review the following to bump the minimum boot JDK required > for JavaFX builds to JDK 10. Note that the review will be done on > github, but it is OK to reply to this thread with comments if you > don't have a github account. > > https://bugs.openjdk.java.net/browse/JDK-8200446 > > https://github.com/javafxports/openjdk-jfx/pull/61 > > > This also bumps the class file format to that of JDK 10. I note > that we have been using JDK 10 to build the openjfx-11 builds for > several months, and now that we've upgraded to gradle 4.8 we are > ready to make JDK 10 the minimum. > > Once this is done, we can start using JDK 10 features, such as > 'var' for local variables (although please don't take this as a > license to use 'var' gratuitously). > > Thanks. > > -- Kevin > > From prasanta.sadhukhan at oracle.com Thu Jun 14 15:47:02 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 14 Jun 2018 21:17:02 +0530 Subject: [11] RFR JDK-8202277:WebView image capture fails with standalone FX due to dependency on javafx.swing Message-ID: <489eefd2-4483-9523-fd7e-e7965858598f@oracle.com> Hi Kevin, All Please review the fix to remove the dependancy on javafx.swing module from javafx.web Bug: https://bugs.openjdk.java.net/browse/JDK-8202277 webrev: http://cr.openjdk.java.net/~psadhukhan/fx/8202277/webrev/ Regards Prasanta From philip.race at oracle.com Thu Jun 14 20:13:40 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 14 Jun 2018 13:13:40 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> Message-ID: <7474446d-1829-c163-4c9c-fbadd863cbaf@oracle.com> +1 from me for the JDK changes. -phil. On 06/13/2018 06:04 PM, Kevin Rushforth wrote: > The JDK changes look good to me, and as far as I have tested them, it > works for me. I haven't tried Drag and Drop yet with the latest > interface changes. > > To repeat something I've mentioned before, just so there is no > confusion, the FX side of the changes are intended to be a proof of > concept to test the JDK side at this point. They will need refactoring > before they can go in, so that FX will still be buildable and runnable > with JDK 10. > > -- Kevin > > > On 6/13/2018 12:48 AM, Prasanta Sadhukhan wrote: >> >> Hi Phil, All >> >> Please find modified webrev taking care of streamlining >> SwingInteropUtils class and handling of native window handle in >> LightweightFrameWrapper class by using JNI call in FX >> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/ >> >> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >> >> Regards >> Prasanta >> On 5/30/2018 4:13 AM, Philip Race wrote: >>> Some follow up comments. >>> >>> On 5/10/18, 5:49 PM, Philip Race wrote: >>>> I've looked over the Swing code. No time to actually try it out so >>>> I can only comment on what I see. >>>> >>>> I am not sure what I think about class docs like "This class wraps >>>> .." >>>> I know no javadoc is generated but this module is exported and >>>> probably should say something >>>> less specific. >>>> >>>> In general I really have to hold my nose when looking at this whole >>>> module and I >>>> find it distasteful to endorse it. >>>> >>>> I really don't like all the things SwingInterOpUtils.java does. >>>> >>> Specific things we should look at in this file >>> - getDefaultScaleX/Y .. JDK 9 will set a transform on the graphics that >>> is passed to JComponent.paintComponent() .. so I wonder if we really >>> need this internal API. I doubt any other code is updating the transform >>> in a way that would make it a problem so the information you get >>> should be valid. >>> >>> The code to get the data array for the raster and associated information >>> can be extracted via standard API like this : >>> >>> DataBuffer db = BufferedImage.getRaster().getDataBuffer(); >>> if (db instanceof DataBufferInt) { >>> data = (DataBufferInt)db.getData(); >>> } >>> >>> So all of those can be fixed. >>> >>> The code that accepts a native window handle maybe should require it >>> is accessed via JNI ... >>> It could still be unsupported, but it would be package private or >>> similar. >>> If you have a native ID, then you are already using native code. >>> This sidesteps any questions about the stability of such an API which >>> accepts a native resource. >>> >>> The code that finds a component by location is probably harmless ... >>> >>> I'm less sure about the event posting and focus grabbing support. >>> I'd like to have Sergey comment on those. >>> >>> the DnD code is too much for me to examine in detail. >>>> I worry we are creating something we'll come to regret here. >>>> The "unsupportedness" needs to be backed up by >>>> deprecated-for-removal being included >>>> today so we can get rid of it the next release if we want to. >>> >>> I've looked at jdk.unsupported and they don't seem to have >>> deprecation tags so >>> maybe that isn't an issue. >>> >>> -phil >>>> >>>> No @since tags anywhere.... >>>> >>>> -phil. >>>> >>>> On 5/10/18, 8:32 AM, Kevin Rushforth wrote: >>>>> I confirm that this fixes the issue. The interface change to make >>>>> the two static methods e instance methods is a good change in any >>>>> case. >>>>> >>>>> I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Hi Kevin,All, >>>>>> >>>>>> Please find the modified webrev fixing this #1 issue >>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.13/ >>>>>> via change in >>>>>> jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext >>>>>> and FXDnD.java#postDropTargetEvent >>>>>> >>>>>> For me, #2 works, #3 doesn't work even now due to JDK-8141391 >>>>>> and #4 works >>>>>> for me. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 5/9/2018 11:29 PM, Kevin Rushforth wrote: >>>>>>> Hi Prasanta, >>>>>>> >>>>>>> The API looks good now. >>>>>>> >>>>>>> All of our automated tests work (except for the ones with a >>>>>>> security manager due to JDK-8202451 >>>>>>> ). >>>>>>> >>>>>>> The only functional problem that I see is that Drag and Drop >>>>>>> onto a SwingNode doesn't work. We need to make sure that we test >>>>>>> the following four cases: >>>>>>> >>>>>>> 1. Drag / drop onto a Swing component in a SwingNode >>>>>>> 2. Drag / drop from a Swing component in a SwingNode >>>>>>> 3. Drag / drop onto a JavaFX control in a JFXPanel >>>>>>> 4. Drag / drop from a JavaFX control in a JFXPanel >>>>>>> >>>>>>> So far I only tried the first one; the others still need to be >>>>>>> validated. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote: >>>>>>>> Modified webrev to cater to this >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.12/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 5/9/2018 5:58 PM, Kevin Rushforth wrote: >>>>>>>>> The following can also be abstract: >>>>>>>>> >>>>>>>>> LightweightContentWrapper: >>>>>>>>> getComponent, createDragGestureRecognizer, >>>>>>>>> createDragSourceContextPeer >>>>>>>>> >>>>>>>>> DropTargetContextWrapper: >>>>>>>>> getTargetActions, getDropTarget, getTransferDataFlavors, >>>>>>>>> getTransferable, isTransferableJVMLocal >>>>>>>>> >>>>>>>>> DispatcherWrapper: >>>>>>>>> isDispatchThread, createSecondaryLoop >>>>>>>>> >>>>>>>>> The rest looks good to me (although I still see two public >>>>>>>>> methods with "Peer" in the name, so Phil may want those renamed). >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote: >>>>>>>>>> Modified webrev to cater to these 3 observations >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/ >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> >>>>>>>>>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote: >>>>>>>>>>> The module definition for jdk.unsupported.desktop and the >>>>>>>>>>> changes to java.desktop look fine. >>>>>>>>>>> >>>>>>>>>>> In reviewing the jdk.swing.interop API, I have the following >>>>>>>>>>> suggestions / observations: >>>>>>>>>>> >>>>>>>>>>> 1. DispatcherWrapper, DragSourceContextWrapper, >>>>>>>>>>> DropTargetContextWrapper, and LightweightContentWrapper can >>>>>>>>>>> all be abstract, along with most of the methods (rather than >>>>>>>>>>> having an empty body return value that is never used). >>>>>>>>>>> >>>>>>>>>>> 2. The addNotify method in LightweightFrameWrapper is >>>>>>>>>>> unused. Should be used somewhere? If not, then it can be >>>>>>>>>>> removed. >>>>>>>>>>> >>>>>>>>>>> The implementation of the new wrapper classes looks OK to me >>>>>>>>>>> with one observation that might or might not matter: >>>>>>>>>>> >>>>>>>>>>> 3. The behavior of getDefaultScaleX/Y (which is now in >>>>>>>>>>> SwingInteropUtils) has changed in the case where the >>>>>>>>>>> Graphics is not an instance of SunGraphics2D. The former >>>>>>>>>>> behavior was to leave the instance variables X and Y >>>>>>>>>>> unchanged. The new behavior will set them back to 1.0. Maybe >>>>>>>>>>> this can't happen in practice, but it is something to consider. >>>>>>>>>>> >>>>>>>>>>> -- Kevin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 5/8/2018 3:31 AM, Alan Bateman wrote: >>>>>>>>>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote: >>>>>>>>>>>>> Modified webrev to rename to InteropProviderImpl >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >>>>>>>>>>>> This looks okay to me. >>>>>>>>>>>> >>>>>>>>>>>> -Alan >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >> > From mandy.chung at oracle.com Thu Jun 14 20:26:19 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 14 Jun 2018 13:26:19 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> References: <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> Message-ID: I reviewed the module-info.java change. @since 12 is missing in jdk.unsupported.desktop module-info.java Otherwise it's fine. Does the docs build exclude jdk.unsupported.desktop? You might have confirmed that that I missed. Mandy On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote: > Hi Phil, All > > Please find modified webrev taking care of streamlining > SwingInteropUtils class and handling of native window handle in > LightweightFrameWrapper class by using JNI call in FX > http://cr.openjdk.java.net/~psadhukhan/fxswing.14/ > > Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 > > Regards > Prasanta From philip.race at oracle.com Thu Jun 14 20:29:38 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 14 Jun 2018 13:29:38 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> Message-ID: <66942fce-ef3a-c970-a69e-00b28f686d18@oracle.com> you surely mean @since 11 I believe it has been verified that it is excluded from the docs build .. right Prasanta ? -phil On 06/14/2018 01:26 PM, mandy chung wrote: > I reviewed the module-info.java change. @since 12 is missing in > jdk.unsupported.desktop module-info.java > > Otherwise it's fine. > > Does the docs build exclude jdk.unsupported.desktop? You might have > confirmed that that I missed. > > Mandy > > On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote: >> Hi Phil, All >> >> Please find modified webrev taking care of streamlining >> SwingInteropUtils class and handling of native window handle in >> LightweightFrameWrapper class by using JNI call in FX >> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/ >> >> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >> >> Regards >> Prasanta From mandy.chung at oracle.com Thu Jun 14 20:45:35 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 14 Jun 2018 13:45:35 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <66942fce-ef3a-c970-a69e-00b28f686d18@oracle.com> References: <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> <66942fce-ef3a-c970-a69e-00b28f686d18@oracle.com> Message-ID: <0cf7246f-feae-3ef6-6923-8feb391b3b7f@oracle.com> On 6/14/18 1:29 PM, Phil Race wrote: > you surely mean > @since 11 Oops typo. Yes @since 11 Mandy From kevin.rushforth at oracle.com Thu Jun 14 22:53:04 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Jun 2018 15:53:04 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <66942fce-ef3a-c970-a69e-00b28f686d18@oracle.com> References: <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> <66942fce-ef3a-c970-a69e-00b28f686d18@oracle.com> Message-ID: I verified on an earlier version of the patch that it wasn't in the docs, but it would be good for Prasanta to double-check. -- Kevin On 6/14/2018 1:29 PM, Phil Race wrote: > you surely mean > @since 11 > > I believe it has been verified that it is excluded from the docs build > .. right Prasanta ? > > -phil > > On 06/14/2018 01:26 PM, mandy chung wrote: >> I reviewed the module-info.java change. @since 12 is missing in >> jdk.unsupported.desktop module-info.java >> >> Otherwise it's fine. >> >> Does the docs build exclude jdk.unsupported.desktop?? You might have >> confirmed that that I missed. >> >> Mandy >> >> On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote: >>> Hi Phil, All >>> >>> Please find modified webrev taking care of streamlining >>> SwingInteropUtils class and handling of native window handle in >>> LightweightFrameWrapper class by using JNI call in FX >>> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/ >>> >>> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >>> >>> Regards >>> Prasanta > From mandy.chung at oracle.com Thu Jun 14 23:40:16 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 14 Jun 2018 16:40:16 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> <66942fce-ef3a-c970-a69e-00b28f686d18@oracle.com> Message-ID: <362c8d68-30b8-5e0d-ae4d-6b8eafb8c29f@oracle.com> Thanks for confirming that. Mandy On 6/14/18 3:53 PM, Kevin Rushforth wrote: > I verified on an earlier version of the patch that it wasn't in the > docs, but it would be good for Prasanta to double-check. > > -- Kevin > > > On 6/14/2018 1:29 PM, Phil Race wrote: >> you surely mean >> @since 11 >> >> I believe it has been verified that it is excluded from the docs build >> .. right Prasanta ? >> >> -phil >> >> On 06/14/2018 01:26 PM, mandy chung wrote: >>> I reviewed the module-info.java change. @since 12 is missing in >>> jdk.unsupported.desktop module-info.java >>> >>> Otherwise it's fine. >>> >>> Does the docs build exclude jdk.unsupported.desktop?? You might have >>> confirmed that that I missed. >>> >>> Mandy >>> >>> On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote: >>>> Hi Phil, All >>>> >>>> Please find modified webrev taking care of streamlining >>>> SwingInteropUtils class and handling of native window handle in >>>> LightweightFrameWrapper class by using JNI call in FX >>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/ >>>> >>>> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >>>> >>>> Regards >>>> Prasanta >> > From prasanta.sadhukhan at oracle.com Fri Jun 15 07:31:17 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 15 Jun 2018 13:01:17 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> Message-ID: Webrev to add @since 11 to jdk.swing.interop classes (only difference from .14) http://cr.openjdk.java.net/~psadhukhan/fxswing.15/ I also tried submitting mach5 job from linux but it is failing to download jib (although I candownload from browser and ping java.se.oracle.com) ~/Downloads/mach5-1.0.1865-distribution/bin/mach5 --remote-build --email prasanta.sadhukhan at oracle.com Mach 5 Health State: green Creating job description... done Creating build ID... 2018-06-15-0626444.prasanta.sadhukhan.open Publishing source using JIB... [2018-06-15T06:26:42,870Z][INFO][main][c.o.j.s.c.SparkyClient] Downloading JIB bootstrap script Failed to download https://java.se.oracle.com/artifactory/jdk-virtual/com/oracle/java/jib/jib/3.0-SNAPSHOT/jib-3.0-SNAPSHOT.jib.sh.gz I am trying from windows but Phil told windows build does not probably built docs. Are there any easier alternative to verify the doc build? Regards Prasanta On 6/15/2018 1:56 AM, mandy chung wrote: > I reviewed the module-info.java change.? @since 12 is missing in > jdk.unsupported.desktop module-info.java > > Otherwise it's fine. > > Does the docs build exclude jdk.unsupported.desktop?? You might have > confirmed that that I missed. > > Mandy > > On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote: >> Hi Phil, All >> >> Please find modified webrev taking care of streamlining >> SwingInteropUtils class and handling of native window handle in >> LightweightFrameWrapper class by using JNI call in FX >> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/ >> >> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >> >> Regards >> Prasanta From prasanta.sadhukhan at oracle.com Fri Jun 15 12:42:29 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 15 Jun 2018 18:12:29 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> Message-ID: <18ab9791-480a-7c48-6d0e-fc3a471f2197@oracle.com> On 6/15/2018 1:01 PM, Prasanta Sadhukhan wrote: > Webrev to add @since 11 to jdk.swing.interop classes (only difference > from .14) > > http://cr.openjdk.java.net/~psadhukhan/fxswing.15/ > > I also tried submitting mach5 job from linux but it is failing to > download jib (although I candownload from browser and ping > java.se.oracle.com) > ~/Downloads/mach5-1.0.1865-distribution/bin/mach5 --remote-build > --email prasanta.sadhukhan at oracle.com > Mach 5 Health State: green > > Creating job description... done > Creating build ID... 2018-06-15-0626444.prasanta.sadhukhan.open > Publishing source using JIB... > [2018-06-15T06:26:42,870Z][INFO][main][c.o.j.s.c.SparkyClient] > Downloading JIB bootstrap script > > > I am trying from windows but Phil told windows build does not probably > built docs. > Are there any easier alternative to verify the doc build? > I confirm jdk.unsupported.desktop is not present in doc build. Regards Prasanta > Regards > Prasanta > On 6/15/2018 1:56 AM, mandy chung wrote: >> I reviewed the module-info.java change. @since 12 is missing in >> jdk.unsupported.desktop module-info.java >> >> Otherwise it's fine. >> >> Does the docs build exclude jdk.unsupported.desktop?? You might have >> confirmed that that I missed. >> >> Mandy >> >> On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote: >>> Hi Phil, All >>> >>> Please find modified webrev taking care of streamlining >>> SwingInteropUtils class and handling of native window handle in >>> LightweightFrameWrapper class by using JNI call in FX >>> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/ >>> >>> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >>> >>> Regards >>> Prasanta > From mandy.chung at oracle.com Fri Jun 15 13:56:38 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 15 Jun 2018 06:56:38 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <18ab9791-480a-7c48-6d0e-fc3a471f2197@oracle.com> References: <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> <18ab9791-480a-7c48-6d0e-fc3a471f2197@oracle.com> Message-ID: <9aa7d562-e51b-0061-895d-d0b7df7a4fa6@oracle.com> Great! Thanks Prasanta. Mandy On 6/15/18 5:42 AM, Prasanta Sadhukhan wrote: > I confirm jdk.unsupported.desktop is not present in doc build. > > Regards > Prasanta From ambarish.rapte at oracle.com Fri Jun 15 14:19:38 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Fri, 15 Jun 2018 07:19:38 -0700 (PDT) Subject: [11] RFR : JDK-8205008 : GeneralTransform3D transform function with single Vec3d argument wrong results Message-ID: <383c81ef-dde8-4756-b84c-1493ba51329e@default> Hi Kevin & All, Please review this small corrective fix, Webrev: http://cr.openjdk.java.net/~arapte/fx/8205008/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8205008 Regards, Ambarish From it at kwinan.de Fri Jun 15 14:40:55 2018 From: it at kwinan.de (Michael Tischer) Date: Fri, 15 Jun 2018 16:40:55 +0200 Subject: Build OpenJFX -> ':graphics:compileDecoraNativeShadersLinux' fails Message-ID: <1529073655.22645.15.camel@kwinan.de> Hi All, first sorry for my bad englisch. I have tried to build OpenJFX according to the instructions in the wiki. (https://wiki.openjdk.java.n et/display/OpenJFX/Building+OpenJFX)My OS is Linux Mint 18.3. The first thing is that the wiki says that I need gradle 4.3. ("We currently use Gradle 4.3 for jfx-dev (IMPORTANT: Only this version is regularly tested)." But when I use gradle 4.3 the build says: ***************************************************************** Unsupported gradle version 4.3.1 in use. Only version 4.8 is supported. Use this version at your own risk ***************************************************************** It seems to me that the wiki in this point is no more actually. Okay, so I changed the grade version to 4.8. ANT-Version is 1.8.2. JDK is 10.0.1 Unfortunally, "gradle sdk" doesn't work. The build fails with this output: > Task :graphics:compileDecoraNativeShadersLinux FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':graphics:compileDecoraNativeShadersLinux'. > java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: Process 'command 'gcc'' finished with non-zero exit value 1 Can you please help me get the build up and running? Regards Michael From kevin.rushforth at oracle.com Fri Jun 15 15:03:47 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Jun 2018 08:03:47 -0700 Subject: Build OpenJFX -> ':graphics:compileDecoraNativeShadersLinux' fails In-Reply-To: <1529073655.22645.15.camel@kwinan.de> References: <1529073655.22645.15.camel@kwinan.de> Message-ID: <87650989-596f-473c-a113-4e8ee848c3d9@oracle.com> We just upgraded to gradle 4.8 last week, but haven't yet updated the Wiki. One thing to try is to manually remove the build directory, run gradle clean, and then try it again with the --info option: $ rm -rf build $ gradle clean $ gradle --info sdk If it still doesn't work, make sure you have all of the required tools installed. -- Kevin On 6/15/2018 7:40 AM, Michael Tischer wrote: > Hi All, > > first sorry for my bad englisch. I have tried to build OpenJFX > according to the instructions in the wiki. (https://wiki.openjdk.java.n > et/display/OpenJFX/Building+OpenJFX)My OS is Linux Mint 18.3. > > The first thing is that the wiki says that I need gradle 4.3. ("We > currently use Gradle 4.3 for jfx-dev (IMPORTANT: Only this version is > regularly tested)." But when I use gradle 4.3 the build says: > > ***************************************************************** > Unsupported gradle version 4.3.1 in use. > Only version 4.8 is supported. Use this version at your own risk > ***************************************************************** > > It seems to me that the wiki in this point is no more actually. > > Okay, so I changed the grade version to 4.8. ANT-Version is 1.8.2. JDK > is 10.0.1 > > Unfortunally, "gradle sdk" doesn't work. The build fails with this > output: > > >> Task :graphics:compileDecoraNativeShadersLinux FAILED > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':graphics:compileDecoraNativeShadersLinux'. >> java.util.concurrent.ExecutionException: > org.gradle.process.internal.ExecException: Process 'command 'gcc'' > finished with non-zero exit value 1 > > > > Can you please help me get the build up and running? > > > > Regards > Michael > From it at kwinan.de Fri Jun 15 16:24:17 2018 From: it at kwinan.de (Michael Tischer) Date: Fri, 15 Jun 2018 18:24:17 +0200 Subject: Build OpenJFX -> ':graphics:compileDecoraNativeShadersLinux' fails In-Reply-To: <87650989-596f-473c-a113-4e8ee848c3d9@oracle.com> References: <1529073655.22645.15.camel@kwinan.de> <87650989-596f-473c-a113-4e8ee848c3d9@oracle.com> Message-ID: <1529079857.22645.19.camel@kwinan.de> Hi Kevin, the build works now. I'm not familar with C++, but some of the output contained the "cc1plus" word. After a short Google search I've found the reason. G++ was simply not installed. It seems that G++ is not installed per default on some linux distributions. In the wiki, G++ is listed only for the Windows build, not for the Linux build. Maybe this should be adjusted in the wiki. -- Michael Am Freitag, den 15.06.2018, 08:03 -0700 schrieb Kevin Rushforth: > We just upgraded to gradle 4.8 last week, but haven't yet updated the > Wiki. > > One thing to try is to manually remove the build directory, run > gradle? > clean, and then try it again with the --info option: > > $ rm -rf build > $ gradle clean > $ gradle --info sdk > > If it still doesn't work, make sure you have all of the required > tools? > installed. > > -- Kevin > > On 6/15/2018 7:40 AM, Michael Tischer wrote: > > > > Hi All, > > > > first sorry for my bad englisch. I have tried to build OpenJFX > > according to the instructions in the wiki. (https://wiki.openjdk.ja > > va.n > > et/display/OpenJFX/Building+OpenJFX)My OS is Linux Mint 18.3. > > > > The first thing is that the wiki says that I need gradle 4.3. ("We > > currently use Gradle 4.3 for jfx-dev (IMPORTANT: Only this version > > is > > regularly tested)." But when I use gradle 4.3 the build says: > > > > ***************************************************************** > > Unsupported gradle version 4.3.1 in use. > > Only version 4.8 is supported. Use this version at your own risk > > ***************************************************************** > > > > It seems to me that the wiki in this point is no more actually. > > > > Okay, so I changed the grade version to 4.8. ANT-Version is 1.8.2. > > JDK > > is 10.0.1 > > > > Unfortunally, "gradle sdk" doesn't work. The build fails with this > > output: > > > > > > > > > > Task :graphics:compileDecoraNativeShadersLinux FAILED > > FAILURE: Build failed with an exception. > > > > * What went wrong: > > Execution failed for task > > ':graphics:compileDecoraNativeShadersLinux'. > > > > > > java.util.concurrent.ExecutionException: > > org.gradle.process.internal.ExecException: Process 'command 'gcc'' > > finished with non-zero exit value 1 > > > > > > > > Can you please help me get the build up and running? > > > > > > > > Regards > > Michael > > From philip.race at oracle.com Fri Jun 15 17:26:33 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 15 Jun 2018 10:26:33 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> Message-ID: +1 -phil. On 06/15/2018 12:31 AM, Prasanta Sadhukhan wrote: > Webrev to add @since 11 to jdk.swing.interop classes (only difference > from .14) > > http://cr.openjdk.java.net/~psadhukhan/fxswing.15/ > > I also tried submitting mach5 job from linux but it is failing to > download jib (although I candownload from browser and ping > java.se.oracle.com) > ~/Downloads/mach5-1.0.1865-distribution/bin/mach5 --remote-build > --email prasanta.sadhukhan at oracle.com > Mach 5 Health State: green > > Creating job description... done > Creating build ID... 2018-06-15-0626444.prasanta.sadhukhan.open > Publishing source using JIB... > [2018-06-15T06:26:42,870Z][INFO][main][c.o.j.s.c.SparkyClient] > Downloading JIB bootstrap script > Failed to download > https://java.se.oracle.com/artifactory/jdk-virtual/com/oracle/java/jib/jib/3.0-SNAPSHOT/jib-3.0-SNAPSHOT.jib.sh.gz > > I am trying from windows but Phil told windows build does not probably > built docs. > Are there any easier alternative to verify the doc build? > > Regards > Prasanta > On 6/15/2018 1:56 AM, mandy chung wrote: >> I reviewed the module-info.java change. @since 12 is missing in >> jdk.unsupported.desktop module-info.java >> >> Otherwise it's fine. >> >> Does the docs build exclude jdk.unsupported.desktop? You might have >> confirmed that that I missed. >> >> Mandy >> >> On 6/13/18 12:48 AM, Prasanta Sadhukhan wrote: >>> Hi Phil, All >>> >>> Please find modified webrev taking care of streamlining >>> SwingInteropUtils class and handling of native window handle in >>> LightweightFrameWrapper class by using JNI call in FX >>> http://cr.openjdk.java.net/~psadhukhan/fxswing.14/ >>> >>> Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >>> >>> Regards >>> Prasanta > From mandy.chung at oracle.com Fri Jun 15 17:44:09 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 15 Jun 2018 10:44:09 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> <5AF4E8AF.60202@oracle.com> <5B0DD789.8000809@oracle.com> <502b95f6-6fc4-39ce-3ca5-b4ec5aab02aa@oracle.com> Message-ID: <784b42d4-549d-c512-8a51-8ff0ec17f2bb@oracle.com> On 6/15/18 12:31 AM, Prasanta Sadhukhan wrote: > Webrev to add @since 11 to jdk.swing.interop classes (only difference > from .14) > > http://cr.openjdk.java.net/~psadhukhan/fxswing.15/ +1 Mandy From kevin.rushforth at oracle.com Fri Jun 15 22:56:40 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Jun 2018 15:56:40 -0700 Subject: New version of the FX-aware jcheck Message-ID: <3a3f8d26-4924-1d2d-1f6a-69818b7f42c4@oracle.com> For those using the modified jcheck as indicated on the OpenJFX Wiki [1] be aware that the latest promoted build tags, which were just synced into the jfx-dev/rt repo, will require you to download a new version of the modified jcheck tool [2] to handle the new tag format. -- Kevin [1] https://wiki.openjdk.java.net/display/OpenJFX/Using+jcheck [2] http://cr.openjdk.java.net/~kcr/jcheck/bin/jcheck.py From kevin.rushforth at oracle.com Fri Jun 15 23:47:16 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Jun 2018 16:47:16 -0700 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: References: Message-ID: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> I tested this on all three platforms and the updated rasterizer looks good. I spot checked the code changes, but didn't get time to do a complete review yet. I was mostly looking for diffs between the Java2D version which was already reviewed, and this one. I do have a couple comments on the new ClipShapeTest (which looks like a nice accuracy test, btw). 1. The test runs for way too long (about 20x too long) to include in our normal test runs. By default the entire class file (all three tests) needs to take < 5 minutes and 2 minutes would be better. I measured the time on 4 machines that I have and found that if you cut the number of iterations down from 5000 to 250 it will be just about the right run time. Then you can set the timeout to 120 seconds (the slowest test on the slowest of my machines took about 48 seconds, so a 2 minute timeout should be plenty). 2. Can you explain the reason for setting the following? ?206???????? // disable static clipping setting: ?207???????? System.setProperty("prism.marlin.clip", "false"); ?208???????? System.setProperty("prism.marlin.clip.runtime.enable", "true"); ?209 ?210???????? // enable subdivider: ?211???????? System.setProperty("prism.marlin.clip.subdivider", "true"); ?212 ?213???????? // disable min length check: always subdivide curves at clip edges ?214 System.setProperty("prism.marlin.clip.subdivider.minLength", "-1"); ?215 ?216???????? // If any curve, increase curve accuracy: ?217???????? // curve length max error: ?218???????? System.setProperty("prism.marlin.curve_len_err", "1e-4"); ?219 ?220???????? // cubic min/max error: ?221???????? System.setProperty("prism.marlin.cubic_dec_d2", "1e-3"); ?222???????? System.setProperty("prism.marlin.cubic_inc_d1", "1e-4"); // or disabled ~ 1e-6 ?223 ?224???????? // quad max error: ?225???????? System.setProperty("prism.marlin.quad_dec_d2", "5e-4"); It seems better to test with the default parameters (i.e., it makes a better regression test that way). 3. Related to that, I think you should eliminate the following (I don't recommend running functional tests with this set), although since you don't do any animation, it probably doesn't matter. ?227???????? System.setProperty("javafx.animation.fullspeed", "true"); // full speed -- Kevin On 6/8/2018 7:28 AM, Laurent Bourg?s wrote: > Hi, > > Please review this large patch to upgrade MarlinFX to 0.9.2 in OpenJFX11: > JBS: https://bugs.openjdk.java.net/browse/JDK-8198885 > webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.0/ > > PR: https://github.com/javafxports/openjdk-jfx/pull/96 (CI OK) > > This patch is almost identical to Marlin(2D) patch, see: > https://bugs.openjdk.java.net/browse/JDK-8198885 > > I added the ClipShapeTest (ported to jfx) that compares shape clipping > (within threshold) and it works (within large timeouts): > gradle -PFULL_TEST=true :system:test --tests > test.com.sun.marlin.ClipShapeTest > > Regards, > Laurent From omniprof at gmail.com Tue Jun 19 15:51:50 2018 From: omniprof at gmail.com (omniprof at gmail.com) Date: Tue, 19 Jun 2018 11:51:50 -0400 Subject: Table Input Message-ID: <004001d407e5$70342dc0$509c8940$@gmail.com> A minor issue in the Table component existed in previous versions of JavaFX when editing in a cell was turned on. Only if the Return key was pressed was the data entered into the backing bean. Leaving the cell with Tab or by mouse did not register the change. I thought just when a cell looses focus it should trigger updating the bean. I have not looked at the recent builds but I thought I'd ask if it has come up on anyone's radar. I noticed it when I moved from teaching Swing to FX. Ken Fogel From youngty1997 at gmail.com Tue Jun 19 18:53:18 2018 From: youngty1997 at gmail.com (Ty Young) Date: Tue, 19 Jun 2018 13:53:18 -0500 Subject: Table Input In-Reply-To: <004001d407e5$70342dc0$509c8940$@gmail.com> References: <004001d407e5$70342dc0$509c8940$@gmail.com> Message-ID: <8f06b6f5-aab1-f8da-4718-541a5fa57360@gmail.com> On 06/19/2018 10:51 AM, omniprof at gmail.com wrote: > A minor issue in the Table component existed in previous versions of JavaFX > when editing in a cell was turned on. Only if the Return key was pressed was > the data entered into the backing bean. Leaving the cell with Tab or by > mouse did not register the change. I thought just when a cell looses focus > it should trigger updating the bean. I have not looked at the recent builds > but I thought I'd ask if it has come up on anyone's radar. I noticed it when > I moved from teaching Swing to FX. > > > > Ken Fogel > > > > > IIRC, this isn't specific to Table. A spinner with editing enabled also does this and it breaks events(onKeyTyped does nothing). From tbee at tbee.org Tue Jun 19 20:15:20 2018 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 19 Jun 2018 22:15:20 +0200 Subject: Table Input In-Reply-To: <8f06b6f5-aab1-f8da-4718-541a5fa57360@gmail.com> References: <004001d407e5$70342dc0$509c8940$@gmail.com> <8f06b6f5-aab1-f8da-4718-541a5fa57360@gmail.com> Message-ID: This is a well known and already deeply discussed issue. I'm still not sure where we are with it, but Jonathan knows I believe. On 19-6-2018 20:53, Ty Young wrote: > On 06/19/2018 10:51 AM, omniprof at gmail.com wrote: > >> A minor issue in the Table component existed in previous versions of JavaFX >> when editing in a cell was turned on. Only if the Return key was pressed was >> the data entered into the backing bean. Leaving the cell with Tab or by >> mouse did not register the change. I thought just when a cell looses focus >> it should trigger updating the bean. I have not looked at the recent builds >> but I thought I'd ask if it has come up on anyone's radar. I noticed it when >> I moved from teaching Swing to FX. >> >> >> Ken Fogel >> >> >> > > IIRC, this isn't specific to Table. A spinner with editing enabled also does this and it breaks events(onKeyTyped does nothing). From tom.schindl at bestsolution.at Wed Jun 20 08:07:50 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 20 Jun 2018 10:07:50 +0200 Subject: Review-Request for JDK-8191661 Message-ID: Hi, I'd like to request a review for the fix of JDK-8191661. The change is at https://github.com/javafxports/openjdk-jfx/pull/100 Tom From fastegal at swingempire.de Wed Jun 20 08:24:35 2018 From: fastegal at swingempire.de (fastegal at swingempire.de) Date: Wed, 20 Jun 2018 10:24:35 +0200 Subject: Table Input In-Reply-To: References: <004001d407e5$70342dc0$509c8940$@gmail.com> <8f06b6f5-aab1-f8da-4718-541a5fa57360@gmail.com> Message-ID: <20180620102435.Horde.xN1SEJsx9IWuagjkZd_frQ1@webmail.df.eu> Zitat von Tom Eugelink : > This is a well known and already deeply discussed issue. I'm still > not sure where we are with it, but Jonathan knows I believe. > > https://bugs.openjdk.java.net/browse/JDK-8089514 tbd_major ... since nearly 7 years :(( actually, it took 4 years to get the necessity accepted, then another 2 years playing with incomplete suggested fixes and then ... It's a complex problem, requires a) additional commit/cancel api on the virtual controls to allow collaborators to cleanly terminate ongoing edits - this part has still been debated b) a major cleanup of cell implementations - this part was under way (and evolving into the good direction) until Jonathan left CU, Jeanette > On 19-6-2018 20:53, Ty Young wrote: >> On 06/19/2018 10:51 AM, omniprof at gmail.com wrote: >> >>> A minor issue in the Table component existed in previous versions of JavaFX >>> when editing in a cell was turned on. Only if the Return key was >>> pressed was >>> the data entered into the backing bean. Leaving the cell with Tab or by >>> mouse did not register the change. I thought just when a cell looses focus >>> it should trigger updating the bean. I have not looked at the recent builds >>> but I thought I'd ask if it has come up on anyone's radar. I >>> noticed it when >>> I moved from teaching Swing to FX. >>> >>> >>> Ken Fogel >>> >>> >>> >> >> IIRC, this isn't specific to Table. A spinner with editing enabled >> also does this and it breaks events(onKeyTyped does nothing). From jonathan at jonathangiles.net Wed Jun 20 08:28:23 2018 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Wed, 20 Jun 2018 10:28:23 +0200 Subject: Table Input In-Reply-To: <20180620102435.Horde.xN1SEJsx9IWuagjkZd_frQ1@webmail.df.eu> References: <004001d407e5$70342dc0$509c8940$@gmail.com> <8f06b6f5-aab1-f8da-4718-541a5fa57360@gmail.com> <20180620102435.Horde.xN1SEJsx9IWuagjkZd_frQ1@webmail.df.eu> Message-ID: Yup, A great regret. I wish it were supported, but it isn't due to historical legacy. There are some small ways you can make some progress, e.g. add focus listeners on the editor node, but they are half solutions at best. -- Jonathan (Tapped on a touch device) On Wed, 20 Jun 2018, 10:25 AM , wrote: > > Zitat von Tom Eugelink : > > > This is a well known and already deeply discussed issue. I'm still > > not sure where we are with it, but Jonathan knows I believe. > > > > > > https://bugs.openjdk.java.net/browse/JDK-8089514 > > tbd_major ... since nearly 7 years :(( actually, it took 4 years to > get the necessity accepted, then another 2 years playing with > incomplete suggested fixes and then ... > > It's a complex problem, requires > > a) additional commit/cancel api on the virtual controls to allow > collaborators to cleanly terminate ongoing edits - this part has still > been debated > b) a major cleanup of cell implementations - this part was under way > (and evolving into the good direction) until Jonathan left > > > CU, Jeanette > > > On 19-6-2018 20:53, Ty Young wrote: > >> On 06/19/2018 10:51 AM, omniprof at gmail.com wrote: > >> > >>> A minor issue in the Table component existed in previous versions of > JavaFX > >>> when editing in a cell was turned on. Only if the Return key was > >>> pressed was > >>> the data entered into the backing bean. Leaving the cell with Tab or by > >>> mouse did not register the change. I thought just when a cell looses > focus > >>> it should trigger updating the bean. I have not looked at the recent > builds > >>> but I thought I'd ask if it has come up on anyone's radar. I > >>> noticed it when > >>> I moved from teaching Swing to FX. > >>> > >>> > >>> Ken Fogel > >>> > >>> > >>> > >> > >> IIRC, this isn't specific to Table. A spinner with editing enabled > >> also does this and it breaks events(onKeyTyped does nothing). > > > > From daniel.peintner at gmail.com Wed Jun 20 13:33:55 2018 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Wed, 20 Jun 2018 15:33:55 +0200 Subject: Table Input In-Reply-To: References: <004001d407e5$70342dc0$509c8940$@gmail.com> <8f06b6f5-aab1-f8da-4718-541a5fa57360@gmail.com> <20180620102435.Horde.xN1SEJsx9IWuagjkZd_frQ1@webmail.df.eu> Message-ID: Hi, I believe the last time I looked at the TableView2 contribution at ControlsFX (which can be used as a TableView replacement), commit on focus lost was implemented/supported. -- Daniel Jonathan Giles schrieb am Mi., 20. Juni 2018, 10:28: > Yup, > > A great regret. I wish it were supported, but it isn't due to historical > legacy. There are some small ways you can make some progress, e.g. add > focus listeners on the editor node, but they are half solutions at best. > > -- Jonathan > (Tapped on a touch device) > > On Wed, 20 Jun 2018, 10:25 AM , wrote: > > > > > Zitat von Tom Eugelink : > > > > > This is a well known and already deeply discussed issue. I'm still > > > not sure where we are with it, but Jonathan knows I believe. > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8089514 > > > > tbd_major ... since nearly 7 years :(( actually, it took 4 years to > > get the necessity accepted, then another 2 years playing with > > incomplete suggested fixes and then ... > > > > It's a complex problem, requires > > > > a) additional commit/cancel api on the virtual controls to allow > > collaborators to cleanly terminate ongoing edits - this part has still > > been debated > > b) a major cleanup of cell implementations - this part was under way > > (and evolving into the good direction) until Jonathan left > > > > > > CU, Jeanette > > > > > On 19-6-2018 20:53, Ty Young wrote: > > >> On 06/19/2018 10:51 AM, omniprof at gmail.com wrote: > > >> > > >>> A minor issue in the Table component existed in previous versions of > > JavaFX > > >>> when editing in a cell was turned on. Only if the Return key was > > >>> pressed was > > >>> the data entered into the backing bean. Leaving the cell with Tab or > by > > >>> mouse did not register the change. I thought just when a cell looses > > focus > > >>> it should trigger updating the bean. I have not looked at the recent > > builds > > >>> but I thought I'd ask if it has come up on anyone's radar. I > > >>> noticed it when > > >>> I moved from teaching Swing to FX. > > >>> > > >>> > > >>> Ken Fogel > > >>> > > >>> > > >>> > > >> > > >> IIRC, this isn't specific to Table. A spinner with editing enabled > > >> also does this and it breaks events(onKeyTyped does nothing). > > > > > > > > > From Rony.Flatscher at wu.ac.at Wed Jun 20 14:21:19 2018 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Wed, 20 Jun 2018 16:21:19 +0200 Subject: Table Input In-Reply-To: References: <004001d407e5$70342dc0$509c8940$@gmail.com> <8f06b6f5-aab1-f8da-4718-541a5fa57360@gmail.com> <20180620102435.Horde.xN1SEJsx9IWuagjkZd_frQ1@webmail.df.eu> Message-ID: On 20.06.2018 15:33, Daniel Peintner wrote: > I believe the last time I looked at the TableView2 contribution at > ControlsFX (which can be used as a TableView replacement), commit on focus > lost was implemented/supported. Do you have a link? seems to not have it. ---rony > Jonathan Giles schrieb am Mi., 20. Juni 2018, > 10:28: > >> Yup, >> >> A great regret. I wish it were supported, but it isn't due to historical >> legacy. There are some small ways you can make some progress, e.g. add >> focus listeners on the editor node, but they are half solutions at best. >> >> -- Jonathan >> (Tapped on a touch device) >> >> On Wed, 20 Jun 2018, 10:25 AM , wrote: >> >>> Zitat von Tom Eugelink : >>> >>>> This is a well known and already deeply discussed issue. I'm still >>>> not sure where we are with it, but Jonathan knows I believe. >>>> >>>> >>> https://bugs.openjdk.java.net/browse/JDK-8089514 >>> >>> tbd_major ... since nearly 7 years :(( actually, it took 4 years to >>> get the necessity accepted, then another 2 years playing with >>> incomplete suggested fixes and then ... >>> >>> It's a complex problem, requires >>> >>> a) additional commit/cancel api on the virtual controls to allow >>> collaborators to cleanly terminate ongoing edits - this part has still >>> been debated >>> b) a major cleanup of cell implementations - this part was under way >>> (and evolving into the good direction) until Jonathan left >>> >>> >>> CU, Jeanette >>> >>>> On 19-6-2018 20:53, Ty Young wrote: >>>>> On 06/19/2018 10:51 AM, omniprof at gmail.com wrote: >>>>> >>>>>> A minor issue in the Table component existed in previous versions of >>> JavaFX >>>>>> when editing in a cell was turned on. Only if the Return key was >>>>>> pressed was >>>>>> the data entered into the backing bean. Leaving the cell with Tab or >> by >>>>>> mouse did not register the change. I thought just when a cell looses >>> focus >>>>>> it should trigger updating the bean. I have not looked at the recent >>> builds >>>>>> but I thought I'd ask if it has come up on anyone's radar. I >>>>>> noticed it when >>>>>> I moved from teaching Swing to FX. >>>>>> >>>>>> >>>>>> Ken Fogel >>>>>> >>>>>> >>>>>> >>>>> IIRC, this isn't specific to Table. A spinner with editing enabled >>>>> also does this and it breaks events(onKeyTyped does nothing). From daniel.peintner at gmail.com Wed Jun 20 17:06:20 2018 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Wed, 20 Jun 2018 19:06:20 +0200 Subject: Table Input In-Reply-To: References: <004001d407e5$70342dc0$509c8940$@gmail.com> <8f06b6f5-aab1-f8da-4718-541a5fa57360@gmail.com> <20180620102435.Horde.xN1SEJsx9IWuagjkZd_frQ1@webmail.df.eu> Message-ID: Hi, > I believe the last time I looked at the TableView2 contribution at > > ControlsFX (which can be used as a TableView replacement), commit on > focus > > lost was implemented/supported. > Do you have a link? > The PR has been merged but the contribution is not yet available as ControlsFX release. Note: I think the credits go to Jose Pereda (Gluon?) The easist way to test it is using jpro demo [1] where you can find a TableView2 section. Having said that, I don't actually know how it is implemented. I just noticed commit on focus lost support while playing with this demo. -- Daniel [1] https://demos.jpro.one/controlsfx.html > seems to not have it. > > ---rony > > > Jonathan Giles schrieb am Mi., 20. Juni > 2018, > > 10:28: > > > >> Yup, > >> > >> A great regret. I wish it were supported, but it isn't due to historical > >> legacy. There are some small ways you can make some progress, e.g. add > >> focus listeners on the editor node, but they are half solutions at best. > >> > >> -- Jonathan > >> (Tapped on a touch device) > >> > >> On Wed, 20 Jun 2018, 10:25 AM , wrote: > >> > >>> Zitat von Tom Eugelink : > >>> > >>>> This is a well known and already deeply discussed issue. I'm still > >>>> not sure where we are with it, but Jonathan knows I believe. > >>>> > >>>> > >>> https://bugs.openjdk.java.net/browse/JDK-8089514 > >>> > >>> tbd_major ... since nearly 7 years :(( actually, it took 4 years to > >>> get the necessity accepted, then another 2 years playing with > >>> incomplete suggested fixes and then ... > >>> > >>> It's a complex problem, requires > >>> > >>> a) additional commit/cancel api on the virtual controls to allow > >>> collaborators to cleanly terminate ongoing edits - this part has still > >>> been debated > >>> b) a major cleanup of cell implementations - this part was under way > >>> (and evolving into the good direction) until Jonathan left > >>> > >>> > >>> CU, Jeanette > >>> > >>>> On 19-6-2018 20:53, Ty Young wrote: > >>>>> On 06/19/2018 10:51 AM, omniprof at gmail.com wrote: > >>>>> > >>>>>> A minor issue in the Table component existed in previous versions of > >>> JavaFX > >>>>>> when editing in a cell was turned on. Only if the Return key was > >>>>>> pressed was > >>>>>> the data entered into the backing bean. Leaving the cell with Tab or > >> by > >>>>>> mouse did not register the change. I thought just when a cell looses > >>> focus > >>>>>> it should trigger updating the bean. I have not looked at the recent > >>> builds > >>>>>> but I thought I'd ask if it has come up on anyone's radar. I > >>>>>> noticed it when > >>>>>> I moved from teaching Swing to FX. > >>>>>> > >>>>>> > >>>>>> Ken Fogel > >>>>>> > >>>>>> > >>>>>> > >>>>> IIRC, this isn't specific to Table. A spinner with editing enabled > >>>>> also does this and it breaks events(onKeyTyped does nothing). > > From jose.pereda at gluonhq.com Wed Jun 20 17:45:39 2018 From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=) Date: Wed, 20 Jun 2018 19:45:39 +0200 Subject: Table Input In-Reply-To: References: <004001d407e5$70342dc0$509c8940$@gmail.com> <8f06b6f5-aab1-f8da-4718-541a5fa57360@gmail.com> <20180620102435.Horde.xN1SEJsx9IWuagjkZd_frQ1@webmail.df.eu> Message-ID: As Daniel points out, the TableView2 control is a Gluon contribution that has been merged recently to ControlsFX, but it hasn't been released yet. Actually there is a pending PR to rename the new control to FixableTableView. Regarding commit on focus, it has been implemented in two new table cell factories, for TextField and ComboBox cells [2]. You can use the snapshot to test it, and of course, you can clone the repository, there are two samples [1] available. Jose [1] https://bitbucket.org/controlsfx/controlsfx/src/default/controlsfx-samples/src/main/java/org/controlsfx/samples/tableview2 [2] https://bitbucket.org/controlsfx/controlsfx/src/default/controlsfx/src/main/java/org/controlsfx/control/tableview2/cell/TextField2TableCell.java On Wed, Jun 20, 2018 at 7:06 PM, Daniel Peintner wrote: > Hi, > > > I believe the last time I looked at the TableView2 contribution at > > > ControlsFX (which can be used as a TableView replacement), commit on > > focus > > > lost was implemented/supported. > > Do you have a link? > > > > The PR has been merged but the contribution is not yet available as > ControlsFX release. > Note: I think the credits go to Jose Pereda (Gluon?) > > The easist way to test it is using jpro demo [1] where you can find a > TableView2 section. > > Having said that, I don't actually know how it is implemented. I just > noticed commit on focus lost support while playing with this demo. > > -- Daniel > > [1] https://demos.jpro.one/controlsfx.html > > > > > seems to not have it. > > > > ---rony > > > > > Jonathan Giles schrieb am Mi., 20. Juni > > 2018, > > > 10:28: > > > > > >> Yup, > > >> > > >> A great regret. I wish it were supported, but it isn't due to > historical > > >> legacy. There are some small ways you can make some progress, e.g. add > > >> focus listeners on the editor node, but they are half solutions at > best. > > >> > > >> -- Jonathan > > >> (Tapped on a touch device) > > >> > > >> On Wed, 20 Jun 2018, 10:25 AM , wrote: > > >> > > >>> Zitat von Tom Eugelink : > > >>> > > >>>> This is a well known and already deeply discussed issue. I'm still > > >>>> not sure where we are with it, but Jonathan knows I believe. > > >>>> > > >>>> > > >>> https://bugs.openjdk.java.net/browse/JDK-8089514 > > >>> > > >>> tbd_major ... since nearly 7 years :(( actually, it took 4 years to > > >>> get the necessity accepted, then another 2 years playing with > > >>> incomplete suggested fixes and then ... > > >>> > > >>> It's a complex problem, requires > > >>> > > >>> a) additional commit/cancel api on the virtual controls to allow > > >>> collaborators to cleanly terminate ongoing edits - this part has > still > > >>> been debated > > >>> b) a major cleanup of cell implementations - this part was under way > > >>> (and evolving into the good direction) until Jonathan left > > >>> > > >>> > > >>> CU, Jeanette > > >>> > > >>>> On 19-6-2018 20:53, Ty Young wrote: > > >>>>> On 06/19/2018 10:51 AM, omniprof at gmail.com wrote: > > >>>>> > > >>>>>> A minor issue in the Table component existed in previous versions > of > > >>> JavaFX > > >>>>>> when editing in a cell was turned on. Only if the Return key was > > >>>>>> pressed was > > >>>>>> the data entered into the backing bean. Leaving the cell with Tab > or > > >> by > > >>>>>> mouse did not register the change. I thought just when a cell > looses > > >>> focus > > >>>>>> it should trigger updating the bean. I have not looked at the > recent > > >>> builds > > >>>>>> but I thought I'd ask if it has come up on anyone's radar. I > > >>>>>> noticed it when > > >>>>>> I moved from teaching Swing to FX. > > >>>>>> > > >>>>>> > > >>>>>> Ken Fogel > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>> IIRC, this isn't specific to Table. A spinner with editing enabled > > >>>>> also does this and it breaks events(onKeyTyped does nothing). > > > > > -- From sverre.moe at gmail.com Wed Jun 20 19:21:54 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 20 Jun 2018 21:21:54 +0200 Subject: JavaFX and it use of GTK3 Message-ID: Pardon me for asking this on the dev mailing list, but I wanted to get this directly from the source. I was glad to read that Java had gotten support for GTK3. Prior to this I was oblivious with JavaFX relationship with GTK, apart from the various Gtk-WARNING when starting applications. Then I began to ponder, what does GTK do for JavaFX. What does GTK have to say for JavaFX (disregard any AWT/Swing and SWT) ? The JEP for GTK3 support mentioned the motivation for it: * Active development is on GTK3 and GTK2 may not be available on Linux in the future lifetime of JDK 9/10/11. * Mixing of packages using different GTK versions causes application failures. They mention this problem affects applications when using Eclipse which are SWT-based. I tried running Eclipse with GTK3 enabled without problem. Other than that: Does it provide better graphics with GTK3 Does it provide different visual graphics with GTK3 Does it provide better performance with GTK3 Does it mean JavaFX supports GTK3 themes? If one have selected a desktop GTK theme could it be used in the JavaFX application for styling? Has Qt ever been a consideration for JavaFX instead of GTK? From philip.race at oracle.com Wed Jun 20 19:39:03 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 20 Jun 2018 12:39:03 -0700 Subject: JavaFX and it use of GTK3 In-Reply-To: References: Message-ID: <6b67bb6d-5890-972d-ca85-49fceaec03b3@oracle.com> J On 06/20/2018 12:21 PM, Sverre Moe wrote: > Pardon me for asking this on the dev mailing list, but I wanted to get > this directly from the source. > > I was glad to read that Java had gotten support for GTK3. Prior to > this I was oblivious with JavaFX relationship with GTK, apart from the > various Gtk-WARNING when starting applications. Then I began to > ponder, what does GTK do for JavaFX. > > What does GTK have to say for JavaFX (disregard any AWT/Swing and SWT) ? FX is not a GTK app from a rendering perspective. It is used for all needed interaction with the Windowing System and FX needs to co-exist with other libraries (eg SWT) using GTK3. > > The JEP for GTK3 support mentioned the motivation for it: > * Active development is on GTK3 and GTK2 may not be available on Linux > in the future lifetime of JDK 9/10/11. > * Mixing of packages using different GTK versions causes application > failures. They mention this problem affects applications when using > Eclipse which are SWT-based. I tried running Eclipse with GTK3 enabled > without problem. > > Other than that: > Does it provide better graphics with GTK3 No. > Does it provide different visual graphics with GTK3 No > Does it provide better performance with GTK3 Unlikely > Does it mean JavaFX supports GTK3 themes? If one have selected a > desktop GTK theme could it be used in the JavaFX application for > styling? No .. and no. > > Has Qt ever been a consideration for JavaFX instead of GTK? No. -phil. From sverre.moe at gmail.com Wed Jun 20 20:16:17 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 20 Jun 2018 22:16:17 +0200 Subject: JavaFX and it use of GTK3 In-Reply-To: <6b67bb6d-5890-972d-ca85-49fceaec03b3@oracle.com> References: <6b67bb6d-5890-972d-ca85-49fceaec03b3@oracle.com> Message-ID: > > What does GTK have to say for JavaFX (disregard any AWT/Swing and SWT) ? > > FX is not a GTK app from a rendering perspective. > It is used for all needed interaction with the Windowing System Makes sense. For GUI components such as the FileChooser. The FileChooser in JavaFX is using the system GTK theme, regardless of Modena or any other configured styling. > > Does it mean JavaFX supports GTK3 themes? If one have selected a > > desktop GTK theme could it be used in the JavaFX application for > > styling? > No .. and no. I was wondering because I know Eclipse have been effected in the past by my installed GTK themes. To be able to utilize the GTK theme would have helped to keep theme consistent. Since dialogs such as FileChooser are using the GTK theme. > > Has Qt ever been a consideration for JavaFX instead of GTK? > > No. Why not? Would it be difficult to implement an Qt alternative for GTK in Java? If it is even feasible. In effect it means JavaFX will not work on systems that doesn't have GTK installed, though OpenJDK have no install requirement on GTK. I am running KDE which uses Qt, and apart from a very few applications I have very little reliance on GTK. From Rony.Flatscher at wu.ac.at Thu Jun 21 09:31:26 2018 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 21 Jun 2018 11:31:26 +0200 Subject: Table Input In-Reply-To: References: <004001d407e5$70342dc0$509c8940$@gmail.com> <8f06b6f5-aab1-f8da-4718-541a5fa57360@gmail.com> <20180620102435.Horde.xN1SEJsx9IWuagjkZd_frQ1@webmail.df.eu> Message-ID: Jos? & Daniel, thank you very much for the information and links! ---rony On 20.06.2018 19:45, Jos? Pereda wrote: > As Daniel points out, the TableView2 control is a Gluon contribution that has been merged recently > to ControlsFX, but it hasn't been released yet. Actually there is a pending PR to rename the new > control to FixableTableView. > > Regarding commit on focus, it has been implemented in two new table cell factories, for TextField > and ComboBox cells [2]. > > You can use the snapshot to test it, and of course, you can clone the repository, there are two > samples [1] available. > > Jose > > > [1] > https://bitbucket.org/controlsfx/controlsfx/src/default/controlsfx-samples/src/main/java/org/controlsfx/samples/tableview2 > [2]?https://bitbucket.org/controlsfx/controlsfx/src/default/controlsfx/src/main/java/org/controlsfx/control/tableview2/cell/TextField2TableCell.java > > > On Wed, Jun 20, 2018 at 7:06 PM, Daniel Peintner > wrote: > > Hi, > > > I believe the last time I looked at the TableView2 contribution at > > > ControlsFX (which can be used as a TableView replacement), commit on > > focus > > > lost was implemented/supported. > > Do you have a link? > > > > The PR has been merged but the contribution is not yet available as > ControlsFX release. > Note: I think the credits go to Jose Pereda (Gluon?) > > The easist way to test it is using jpro demo [1] where you can find a > TableView2 section. > > Having said that, I don't actually know how it is implemented. I just > noticed commit on focus lost support while playing with this demo. > > -- Daniel > > [1] https://demos.jpro.one/controlsfx.html > > > > > > seems to not > have it. > > > > ---rony > > > > > Jonathan Giles > schrieb am > Mi., 20. Juni > > 2018, > > > 10:28: > > > > > >> Yup, > > >> > > >> A great regret. I wish it were supported, but it isn't due to historical > > >> legacy. There are some small ways you can make some progress, e.g. add > > >> focus listeners on the editor node, but they are half solutions at best. > > >> > > >> -- Jonathan > > >> (Tapped on a touch device) > > >> > > >> On Wed, 20 Jun 2018, 10:25 AM , > wrote: > > >> > > >>> Zitat von Tom Eugelink >: > > >>> > > >>>> This is a well known and already deeply discussed issue. I'm still > > >>>> not sure where we are with it, but Jonathan knows I believe. > > >>>> > > >>>> > > >>> https://bugs.openjdk.java.net/browse/JDK-8089514 > > > >>> > > >>> tbd_major ... since nearly 7 years :(( actually, it took 4 years to > > >>> get the necessity accepted, then another 2 years playing with > > >>> incomplete suggested fixes and then ... > > >>> > > >>> It's a complex problem, requires > > >>> > > >>> a) additional commit/cancel api on the virtual controls to allow > > >>> collaborators to cleanly terminate ongoing edits - this part has still > > >>> been debated > > >>> b) a major cleanup of cell implementations - this part was under way > > >>> (and evolving into the good direction) until Jonathan left > > >>> > > >>> > > >>> CU, Jeanette > > >>> > > >>>> On 19-6-2018 20:53, Ty Young wrote: > > >>>>> On 06/19/2018 10:51 AM, omniprof at gmail.com wrote: > > >>>>> > > >>>>>> A minor issue in the Table component existed in previous versions of > > >>> JavaFX > > >>>>>> when editing in a cell was turned on. Only if the Return key was > > >>>>>> pressed was > > >>>>>> the data entered into the backing bean. Leaving the cell with Tab or > > >> by > > >>>>>> mouse did not register the change. I thought just when a cell looses > > >>> focus > > >>>>>> it should trigger updating the bean. I have not looked at the recent > > >>> builds > > >>>>>> but I thought I'd ask if it has come up on anyone's radar. I > > >>>>>> noticed it when > > >>>>>> I moved from teaching Swing to FX. > > >>>>>> > > >>>>>> > > >>>>>> Ken Fogel > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>> IIRC, this isn't specific to Table. A spinner with editing enabled > > >>>>> also does this and it breaks events(onKeyTyped does nothing). > > > > > > > > > -- > From mp at jugs.org Thu Jun 21 10:25:51 2018 From: mp at jugs.org (Michael Paus) Date: Thu, 21 Jun 2018 12:25:51 +0200 Subject: Table Input In-Reply-To: References: <004001d407e5$70342dc0$509c8940$@gmail.com> <8f06b6f5-aab1-f8da-4718-541a5fa57360@gmail.com> <20180620102435.Horde.xN1SEJsx9IWuagjkZd_frQ1@webmail.df.eu> Message-ID: But this does not seem to be available for people who already dare to use Java9++ :-( or did I miss something? Am 20.06.18 um 19:45 schrieb Jos? Pereda: > As Daniel points out, the TableView2 control is a Gluon contribution that > has been merged recently to ControlsFX, but it hasn't been released yet. > Actually there is a pending PR to rename the new control to > FixableTableView. > > Regarding commit on focus, it has been implemented in two new table cell > factories, for TextField and ComboBox cells [2]. > > You can use the snapshot to test it, and of course, you can clone the > repository, there are two samples [1] available. > > Jose > > > [1] > https://bitbucket.org/controlsfx/controlsfx/src/default/controlsfx-samples/src/main/java/org/controlsfx/samples/tableview2 > [2] > https://bitbucket.org/controlsfx/controlsfx/src/default/controlsfx/src/main/java/org/controlsfx/control/tableview2/cell/TextField2TableCell.java > > > On Wed, Jun 20, 2018 at 7:06 PM, Daniel Peintner > wrote: > >> Hi, >> >>> I believe the last time I looked at the TableView2 contribution at >>>> ControlsFX (which can be used as a TableView replacement), commit on >>> focus >>>> lost was implemented/supported. >>> Do you have a link? >>> >> The PR has been merged but the contribution is not yet available as >> ControlsFX release. >> Note: I think the credits go to Jose Pereda (Gluon?) >> >> The easist way to test it is using jpro demo [1] where you can find a >> TableView2 section. >> >> Having said that, I don't actually know how it is implemented. I just >> noticed commit on focus lost support while playing with this demo. >> >> -- Daniel >> >> [1] https://demos.jpro.one/controlsfx.html >> >> >> >>> seems to not have it. >>> >>> ---rony >>> >>>> Jonathan Giles schrieb am Mi., 20. Juni >>> 2018, >>>> 10:28: >>>> >>>>> Yup, >>>>> >>>>> A great regret. I wish it were supported, but it isn't due to >> historical >>>>> legacy. There are some small ways you can make some progress, e.g. add >>>>> focus listeners on the editor node, but they are half solutions at >> best. >>>>> -- Jonathan >>>>> (Tapped on a touch device) >>>>> >>>>> On Wed, 20 Jun 2018, 10:25 AM , wrote: >>>>> >>>>>> Zitat von Tom Eugelink : >>>>>> >>>>>>> This is a well known and already deeply discussed issue. I'm still >>>>>>> not sure where we are with it, but Jonathan knows I believe. >>>>>>> >>>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8089514 >>>>>> >>>>>> tbd_major ... since nearly 7 years :(( actually, it took 4 years to >>>>>> get the necessity accepted, then another 2 years playing with >>>>>> incomplete suggested fixes and then ... >>>>>> >>>>>> It's a complex problem, requires >>>>>> >>>>>> a) additional commit/cancel api on the virtual controls to allow >>>>>> collaborators to cleanly terminate ongoing edits - this part has >> still >>>>>> been debated >>>>>> b) a major cleanup of cell implementations - this part was under way >>>>>> (and evolving into the good direction) until Jonathan left >>>>>> >>>>>> >>>>>> CU, Jeanette >>>>>> >>>>>>> On 19-6-2018 20:53, Ty Young wrote: >>>>>>>> On 06/19/2018 10:51 AM, omniprof at gmail.com wrote: >>>>>>>> >>>>>>>>> A minor issue in the Table component existed in previous versions >> of >>>>>> JavaFX >>>>>>>>> when editing in a cell was turned on. Only if the Return key was >>>>>>>>> pressed was >>>>>>>>> the data entered into the backing bean. Leaving the cell with Tab >> or >>>>> by >>>>>>>>> mouse did not register the change. I thought just when a cell >> looses >>>>>> focus >>>>>>>>> it should trigger updating the bean. I have not looked at the >> recent >>>>>> builds >>>>>>>>> but I thought I'd ask if it has come up on anyone's radar. I >>>>>>>>> noticed it when >>>>>>>>> I moved from teaching Swing to FX. >>>>>>>>> >>>>>>>>> >>>>>>>>> Ken Fogel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> IIRC, this isn't specific to Table. A spinner with editing enabled >>>>>>>> also does this and it breaks events(onKeyTyped does nothing). >>> > > > -- From paulrussell70 at gmail.com Thu Jun 21 12:26:01 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Thu, 21 Jun 2018 13:26:01 +0100 Subject: com.sun.javafx.perf.PerformanceTracker In-Reply-To: References: Message-ID: 1. I have a game which I'm trying to performance tune: I can obviously monitor how often I'm calling draw (draw rate), but I can't monitor how often the GPU is actually rendering (FPS) since the PerformanceTracker was removed from the JDK. I'm running FX at full speed (-Djavafx.animation.fullspeed=true), and experimentation (using GPU vendor FPS monitors) shows that if I lower my "draw rate" to match the actual GPU FPS, I get marginally smoother rendering. I've never managed to work out why this would be the case, I get no errors in with Prism running in verbose mode, but if I call draw a faster rate than the GPU renders, I get tiny stutters in my game. These would appear to be missed frames. I can try to video the problem if necessary, but I can't easily make a simple SSCE. In short, I'd really like to see a new version of the PerformanceTracker in the public API. Is this difficult to achieve? 2. The other thing I'd love to see would be some way to set the native screen resolution in JavaFX: my question: https://stackoverflow.com/questions/50545263/setting-native-resolution-in-javafx All games offer this functionality in their graphics settings. 3. As, I last point: since I'm writing. It seems sad that Haxe Kha offers transcompilation into Java, but all they can compile into is AWT, which offers no shaders: hence there can be no Kha graphics4 in Java. Again, nods to some modernising of the renderer in JavaFX to enable pipeline support would be great. Best, Paul From thiago.sayao at clamed.com.br Thu Jun 21 16:04:42 2018 From: thiago.sayao at clamed.com.br (Thiago Milczarek =?ISO-8859-1?Q?Say=E3o?=) Date: Thu, 21 Jun 2018 13:04:42 -0300 Subject: How to use OpenJFX Early-Access Builds? Message-ID: Hi, I am trying to use the openjfx early-access builds with openjdk as described in http://jdk.java.net/openjfx/ (the page says to give feedback here). openjdk version "10.0.1" 2018-04-17 OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1) OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode) I have downloaded the openjfx file and unzipped it to: /home/tsayao/javafx-sdk-11 I am running my jfx application with: -Djava.library.path=/home/tsayao/javafx-sdk-11/lib -classpath /home/tsayao/javafx-sdk-11/lib But i get: Error: JavaFX runtime components are missing, and are required to run this application This is probably known, but I only found answers to old java 8 jfx. Help is appreciated. From mp at jugs.org Thu Jun 21 16:28:16 2018 From: mp at jugs.org (Michael Paus) Date: Thu, 21 Jun 2018 18:28:16 +0200 Subject: How to use OpenJFX Early-Access Builds? In-Reply-To: References: Message-ID: <244419fd-bda0-4ff4-db18-e481e9721a64@jugs.org> How to run an application with the new separate JFX SDK was discussed in this thread: http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021819.html Am 21.06.18 um 18:04 schrieb Thiago Milczarek Say?o: > Hi, > > I am trying to use the openjfx early-access builds with openjdk as > described in http://jdk.java.net/openjfx/ (the page says to give > feedback here). > > openjdk version "10.0.1" 2018-04-17 > OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1) > OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode) > > I have downloaded the openjfx file and unzipped it to: > > /home/tsayao/javafx-sdk-11 > > I am running my jfx application with: > > -Djava.library.path=/home/tsayao/javafx-sdk-11/lib -classpath > /home/tsayao/javafx-sdk-11/lib > > > But i get: > > Error: JavaFX runtime components are missing, and are required to run > this application > > This is probably known, but I only found answers to old java 8 jfx. > > Help is appreciated. From philip.race at oracle.com Thu Jun 21 19:02:31 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 21 Jun 2018 12:02:31 -0700 Subject: JavaFX and it use of GTK3 In-Reply-To: References: <6b67bb6d-5890-972d-ca85-49fceaec03b3@oracle.com> Message-ID: <408f7b5b-5ebf-43a1-dfcb-182d1a9ae4a9@oracle.com> If you are dependent on Qt, you won't run on systems that don't have Qt either. All software has dependencies .. GTK is what core JDK uses, Swing has a GTK L&F, we generally have used platforms which use GTK as our core platforms, for build, test, and support. -phil. On 06/20/2018 01:16 PM, Sverre Moe wrote: >>> What does GTK have to say for JavaFX (disregard any AWT/Swing and SWT) ? >> FX is not a GTK app from a rendering perspective. >> It is used for all needed interaction with the Windowing System > Makes sense. For GUI components such as the FileChooser. > The FileChooser in JavaFX is using the system GTK theme, regardless of > Modena or any other configured styling. > >>> Does it mean JavaFX supports GTK3 themes? If one have selected a >>> desktop GTK theme could it be used in the JavaFX application for >>> styling? >> No .. and no. > I was wondering because I know Eclipse have been effected in the past > by my installed GTK themes. > To be able to utilize the GTK theme would have helped to keep theme > consistent. Since dialogs such as FileChooser are using the GTK theme. > >>> Has Qt ever been a consideration for JavaFX instead of GTK? >> No. > Why not? Would it be difficult to implement an Qt alternative for GTK > in Java? If it is even feasible. > > In effect it means JavaFX will not work on systems that doesn't have > GTK installed, though OpenJDK have no install requirement on GTK. > I am running KDE which uses Qt, and apart from a very few applications > I have very little reliance on GTK. From Joerg.Buchberger at pruftechnik.com Fri Jun 22 11:29:34 2018 From: Joerg.Buchberger at pruftechnik.com (Buchberger, Joerg) Date: Fri, 22 Jun 2018 11:29:34 +0000 Subject: javapackager usage Message-ID: <23b5aba3c3be405fa4d8f22a61a3c68a@DEISMMXS02.pt.local> Hi everyone Is this the right mailing list for all questions about javapackager? I tried to use javapackager for my spring-boot web application on Windows. So, naturally, it runs headless. Although, creating native image and running that exe was successful, there are some caveats I could not solve yet: * how to prevent second such process from starting * is that what -singleton flag is for? it gets rejected as unsupported option * running it as a service * is that what -daemon flag or WinServiceBundler is for? no idea how either works * and I failed to get such exe to work with sc and nssm - each fails to start for different reason * as the exe produced with javapackager immediately returns, I don't get how to stop my process * only way to stop seems sending the kill to the task - is there a better way? Thanks for your attention. Cheers J?rg p.s. here the command and options I used with Java 9 JDK: javapackager -deploy -nosign -native image -daemon -allpermissions -v -outdir build/dist -outfile vron -name vron -appclass org.springframework.boot.loader.JarLauncher -v -srcdir .\build\libs From sverre.moe at gmail.com Sun Jun 24 14:49:00 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Sun, 24 Jun 2018 16:49:00 +0200 Subject: Support additional video codec and container format In-Reply-To: References: Message-ID: I wanted to revive this discussion when I saw Java 9 has gotten upgraded GStreamer in JEP-257. Also Java 11 has an upgrade to GStreamer 1.14 https://bugs.openjdk.java.net/browse/JDK-8199527 The formats supported are very few: https://docs.oracle.com/javase/10/docs/api/javafx/scene/media/package-summary.html What does it take to implement support for these Video formats? It cannot be a license problem because Java 10 already has x264 as the Only supported video format. Is there any work scheduled to improve on this in JavaFX? Den s?n. 10. sep. 2017 kl. 20:49 skrev Sverre Moe : > > Some very old issues for this kind of change > https://bugs.openjdk.java.net/browse/JDK-8091063 > https://bugs.openjdk.java.net/browse/JDK-8091656 > > One new comment on the latter issue suggesting to add new formats like > "Ogg/{Vorbis,Theora}, flac, matroska (MKV), Opus, VP8, 3GPP, GSM" > > This would be great to have on JavaFX. I seriously hope they would add it for Java 10 at least, or a later Java 9 update. > > >> >> Date: Fri, 8 Sep 2017 20:51:06 +1000 >> From: John-Val Rose >> To: Sverre Moe >> Cc: openjfx-dev at openjdk.java.net >> Subject: Re: Support additional video codec and container format >> Message-ID: <51D7CA89-1D83-4E0F-A9F8-EF59A00B6A74 at gmail.com> >> Content-Type: text/plain; charset=us-ascii >> >> +1 >> >> > On 8 Sep 2017, at 19:05, Sverre Moe wrote: >> > >> > Why is JavaFX not supporting open video container and codec? >> > From Java 9 VP6 is deprecated. >> > >> > The only relevant supported coded for JavaFX is H.264/AVC. The only other >> > alternative is VP6 which has been deprecated in Java 9. >> > >> > We cannot use H.264 without paying lisence fee for a commercial application. >> > >> > Support for Ogg Theroa/Vorbis should be considered, at least VP8 and/or VP9 >> > in place for the deprecated VP6. The MediaPlayer for Java 10 has not gotten >> > any changes either. I reckon it is too late for Java 9 to get new formats. > > From johan.vos at gluonhq.com Sun Jun 24 18:41:37 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 24 Jun 2018 20:41:37 +0200 Subject: maven artifacts Message-ID: As discussed before, there will be at least 2 ways developers can work with JavaFX 11 and beyond: 1. use the standalone SDK, with platform-specifc distributions 2. use artifacts on (remote) repositories For the second option, we have to distinguish between build systems (e.g. maven/gradle) and repositories (e.g. maven central). When we put artifacts on remote repositories (e.g. maven central), the build systems will download them, analyse the dependencies, and transitively download other dependencies. Build systems at the very least allow developers to compile Java code, so they have the notion of classpath/modulepath. With the work done in PR#83 ( https://github.com/javafxports/openjdk-jfx/pull/83) we are ready to upload artifacts to remote repositories. While it is working with both maven and gradle, I'm not 100% happy yet, but I don't think there is a perfect solution. Maven and gradle rely on the concept of a pom file to define dependencies, while the Java Module System depends on a module-info file. While those 2 concepts target different aspects of the lifecycle, there is overlap. If we offer 2 options (standalone SDK and remote artifacts), the most important requirement is that developers can easily switch between these options without changing a single line of code in a .java file. As a consequence, the module-info.java need to work with standalone SDK's and remote artifacts. If an application declares a requirement on javafx.controls, that should be in its module-info.java. Next, when the javafx controls module is installed, its module-info.class should be independent on how it is installed (either available in the SDK or via a remote repository) As long as maven or gradle don't analyse module-info files inside jars, we have to use the pom dependencies to make sure maven/gradle understand that using javafx.controls implies using javafx.graphics. So far no problems, this can be automated (see https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1583) in our build.gradle. The pom files will have a dependency for every project dependency. The difficulty is in handling platform-specific installations in a standardized way, taking into account the existing reality. Some JavaFX modules require platform-dependent native libraries, and/or contain platform-specific class files (e.g. d3d files only make sense on windows). In the standalone SDK's, this is solved by having completely separate downloads for each platform. The way we did it in PR #83 is more or less similar: we have different artifacts for the different platforms. where we use a classifier for determining which platform is needed. This ensures that if you depend on e.g. javafx.controls for linux, the build system (maven/gradle) will also make sure to download javafx.graphics for linux. This information is in the pom.xml, as the module-info.java is platform-independent. We have a parent file called javafx.pom ( https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-767d20a82f9dd4b7e319feefc33b89e6) that sets the classifier to ${javafx.platform} which is initialized to ${ os.name}. That parameter is available on maven, so if you use maven and don't do a cross-platform build, not specifying a platform will download the artifacts for your specific platform. If you're using gradle, or want to do a cross-platform build. you have to specify the platform you want to use. It seems to me this system is most close to what developers currently are used to. - Johan From swpalmer at gmail.com Mon Jun 25 13:29:04 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 25 Jun 2018 09:29:04 -0400 Subject: Support additional video codec and container format In-Reply-To: References: Message-ID: I don't want Oracle to add any of those formats. I want them to make it so *anyone* can add a new codec. Then they don't have to worry so much about which codecs to support. The community can take care of that. If Oracle is going to officially support another codec the only one worth putting their effort into at this point is HEVC (H.265) Scott On Sun, Jun 24, 2018 at 10:49 AM Sverre Moe wrote: > I wanted to revive this discussion when I saw Java 9 has gotten > upgraded GStreamer in JEP-257. > Also Java 11 has an upgrade to GStreamer 1.14 > https://bugs.openjdk.java.net/browse/JDK-8199527 > > The formats supported are very few: > > https://docs.oracle.com/javase/10/docs/api/javafx/scene/media/package-summary.html > > What does it take to implement support for these Video formats? > It cannot be a license problem because Java 10 already has x264 as the > Only supported video format. > > Is there any work scheduled to improve on this in JavaFX? > > > > Den s?n. 10. sep. 2017 kl. 20:49 skrev Sverre Moe : > > > > Some very old issues for this kind of change > > https://bugs.openjdk.java.net/browse/JDK-8091063 > > https://bugs.openjdk.java.net/browse/JDK-8091656 > > > > One new comment on the latter issue suggesting to add new formats like > > "Ogg/{Vorbis,Theora}, flac, matroska (MKV), Opus, VP8, 3GPP, GSM" > > > > This would be great to have on JavaFX. I seriously hope they would add > it for Java 10 at least, or a later Java 9 update. > > > > > >> > >> Date: Fri, 8 Sep 2017 20:51:06 +1000 > >> From: John-Val Rose > >> To: Sverre Moe > >> Cc: openjfx-dev at openjdk.java.net > >> Subject: Re: Support additional video codec and container format > >> Message-ID: <51D7CA89-1D83-4E0F-A9F8-EF59A00B6A74 at gmail.com> > >> Content-Type: text/plain; charset=us-ascii > >> > >> +1 > >> > >> > On 8 Sep 2017, at 19:05, Sverre Moe wrote: > >> > > >> > Why is JavaFX not supporting open video container and codec? > >> > From Java 9 VP6 is deprecated. > >> > > >> > The only relevant supported coded for JavaFX is H.264/AVC. The only > other > >> > alternative is VP6 which has been deprecated in Java 9. > >> > > >> > We cannot use H.264 without paying lisence fee for a commercial > application. > >> > > >> > Support for Ogg Theroa/Vorbis should be considered, at least VP8 > and/or VP9 > >> > in place for the deprecated VP6. The MediaPlayer for Java 10 has not > gotten > >> > any changes either. I reckon it is too late for Java 9 to get new > formats. > > > > > From ambarish.rapte at oracle.com Mon Jun 25 15:53:09 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 25 Jun 2018 08:53:09 -0700 (PDT) Subject: [openjfx11] RFR : JDK-8197846 : ComboBox: becomes unclickable after removal and re-adding Message-ID: <321a6ffe-4db3-40eb-ba3f-ece2fcbd7983@default> Hi Kevin, Ajit, Request you to review this fix: Webrev: http://cr.openjdk.java.net/~arapte/fx/8197846/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8197846 Regards, Ambarish From bourges.laurent at gmail.com Mon Jun 25 16:01:10 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 25 Jun 2018 18:01:10 +0200 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> Message-ID: Kevin, Here are my comments below: 2018-06-16 1:47 GMT+02:00 Kevin Rushforth : > I tested this on all three platforms and the updated rasterizer looks good. > > I spot checked the code changes, but didn't get time to do a complete > review yet. I was mostly looking for diffs between the Java2D version which > was already reviewed, and this one. > > I do have a couple comments on the new ClipShapeTest (which looks like a > nice accuracy test, btw). > > 1. The test runs for way too long (about 20x too long) to include in our > normal test runs. By default the entire class file (all three tests) needs > to take < 5 minutes and 2 minutes would be better. I measured the time on 4 > machines that I have and found that if you cut the number of iterations > down from 5000 to 250 it will be just about the right run time. Then you > can set the timeout to 120 seconds (the slowest test on the slowest of my > machines took about 48 seconds, so a 2 minute timeout should be plenty). > I agree this test is very long but it is the only mean I found to test all possible stroke combinations and test enough shapes (5000) to detect bugs. I wondered if using mask directly (via ShapeUtils.getMaskData()) would become faster but it will never run below the 2 minutes threshold in total. Finally I think this test should be manually run only if Marlin renderer is modified. How to do that ? use @Ignore or specific tags ? > 2. Can you explain the reason for setting the following? > > 206 // disable static clipping setting: > 207 System.setProperty("prism.marlin.clip", "false"); > 208 System.setProperty("prism.marlin.clip.runtime.enable", > "true"); > 209 > 210 // enable subdivider: > 211 System.setProperty("prism.marlin.clip.subdivider", "true"); > 212 > 213 // disable min length check: always subdivide curves at clip > edges > 214 System.setProperty("prism.marlin.clip.subdivider.minLength", "-1"); > 215 > 216 // If any curve, increase curve accuracy: > 217 // curve length max error: > 218 System.setProperty("prism.marlin.curve_len_err", "1e-4"); > 219 > 220 // cubic min/max error: > 221 System.setProperty("prism.marlin.cubic_dec_d2", "1e-3"); > 222 System.setProperty("prism.marlin.cubic_inc_d1", "1e-4"); // > or disabled ~ 1e-6 > 223 > 224 // quad max error: > 225 System.setProperty("prism.marlin.quad_dec_d2", "5e-4"); > > It seems better to test with the default parameters (i.e., it makes a > better regression test that way). > I deliberately set all these Marlin clip (runtime + always subdivider) / curve quality settings (quads / cubics thresholds) to be sure of the concrete Marlin setup as quality thresholds are sensitive to such values. The ClipShapeTest is dedicated to test the clipper (+ subdivider) part of the Marlin renderer. > > > 3. Related to that, I think you should eliminate the following (I don't > recommend running functional tests with this set), although since you don't > do any animation, it probably doesn't matter. > > 227 System.setProperty("javafx.animation.fullspeed", "true"); // > full speed > I will remove it and see if the overall test is not slower. Is Platform.runLater() impacted by such setting (latency of FX thread -> Prism rendering thread ?) ? Laurent > > On 6/8/2018 7:28 AM, Laurent Bourg?s wrote: > >> Hi, >> >> Please review this large patch to upgrade MarlinFX to 0.9.2 in OpenJFX11: >> JBS: https://bugs.openjdk.java.net/browse/JDK-8198885 >> webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.0/ < >> http://cr.openjdk.java.net/%7Elbourges/marlinFX/marlinFX-092.0/> >> PR: https://github.com/javafxports/openjdk-jfx/pull/96 (CI OK) >> >> This patch is almost identical to Marlin(2D) patch, see: >> https://bugs.openjdk.java.net/browse/JDK-8198885 >> >> I added the ClipShapeTest (ported to jfx) that compares shape clipping >> (within threshold) and it works (within large timeouts): >> gradle -PFULL_TEST=true :system:test --tests >> test.com.sun.marlin.ClipShapeTest >> >> Regards, >> Laurent >> > > From kevin.rushforth at oracle.com Mon Jun 25 17:50:09 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 25 Jun 2018 10:50:09 -0700 Subject: Review-Request for JDK-8191661 In-Reply-To: References: Message-ID: <13616fdb-aca8-1d89-c7ab-9800c1adf5b1@oracle.com> +1 -- Kevin On 6/20/2018 1:07 AM, Tom Schindl wrote: > Hi, > > I'd like to request a review for the fix of JDK-8191661. The change is > at https://github.com/javafxports/openjdk-jfx/pull/100 > > Tom From nlisker at gmail.com Mon Jun 25 23:27:13 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 26 Jun 2018 02:27:13 +0300 Subject: gradle javadoc commands are SKIPPED Message-ID: Hi, When I run gradle javadoc (or for a specific module), all the javadoc tasks are marked as SKIPPED. I don't remember this happening previously. > Task :javadoc > Task :base:javadoc SKIPPED > Task :controls:javadoc SKIPPED > Task :fxml:javadoc SKIPPED > Task :fxpackagerservices:compileJava SKIPPED > Task :fxpackagerservices:processResources SKIPPED > Task :fxpackagerservices:classes SKIPPED > Task :fxpackager:compileJava SKIPPED > Task :fxpackager:copyDTtoPackager SKIPPED > Task :fxpackager:copyRedistributableFiles SKIPPED > Task :fxpackager:man SKIPPED > Task :fxpackager:processResources SKIPPED > Task :fxpackager:classes SKIPPED > Task :fxpackager:javadoc SKIPPED > Task :fxpackagerservices:javadoc SKIPPED > Task :graphics:javadoc SKIPPED > Task :media:javadoc SKIPPED > Task :swing:javadoc SKIPPED > Task :swt:compileJava UP-TO-DATE > Task :swt:processResources NO-SOURCE > Task :swt:classes > Task :swt:javadoc SKIPPED > Task :systemTests:compileJava NO-SOURCE > Task :systemTests:processResources NO-SOURCE > Task :systemTests:classes UP-TO-DATE > Task :systemTests:javadoc SKIPPED > Task :web:javadoc SKIPPED What's causing this? - Nir From kevin.rushforth at oracle.com Tue Jun 26 03:14:51 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 25 Jun 2018 20:14:51 -0700 Subject: gradle javadoc commands are SKIPPED In-Reply-To: References: Message-ID: The individual per-project javadoc tasks have always been disabled, so this is not new. -- Kevin On 6/25/2018 4:27 PM, Nir Lisker wrote: > Hi, > > When I run gradle javadoc (or for a specific module), all the javadoc tasks > are marked as SKIPPED. I don't remember this happening previously. > >> Task :javadoc >> Task :base:javadoc SKIPPED >> Task :controls:javadoc SKIPPED >> Task :fxml:javadoc SKIPPED >> Task :fxpackagerservices:compileJava SKIPPED >> Task :fxpackagerservices:processResources SKIPPED >> Task :fxpackagerservices:classes SKIPPED >> Task :fxpackager:compileJava SKIPPED >> Task :fxpackager:copyDTtoPackager SKIPPED >> Task :fxpackager:copyRedistributableFiles SKIPPED >> Task :fxpackager:man SKIPPED >> Task :fxpackager:processResources SKIPPED >> Task :fxpackager:classes SKIPPED >> Task :fxpackager:javadoc SKIPPED >> Task :fxpackagerservices:javadoc SKIPPED >> Task :graphics:javadoc SKIPPED >> Task :media:javadoc SKIPPED >> Task :swing:javadoc SKIPPED >> Task :swt:compileJava UP-TO-DATE >> Task :swt:processResources NO-SOURCE >> Task :swt:classes >> Task :swt:javadoc SKIPPED >> Task :systemTests:compileJava NO-SOURCE >> Task :systemTests:processResources NO-SOURCE >> Task :systemTests:classes UP-TO-DATE >> Task :systemTests:javadoc SKIPPED >> Task :web:javadoc SKIPPED > What's causing this? > > - Nir From Joerg.Buchberger at pruftechnik.com Tue Jun 26 13:43:29 2018 From: Joerg.Buchberger at pruftechnik.com (Buchberger, Joerg) Date: Tue, 26 Jun 2018 13:43:29 +0000 Subject: javapackager usage In-Reply-To: <23b5aba3c3be405fa4d8f22a61a3c68a@DEISMMXS02.pt.local> References: <23b5aba3c3be405fa4d8f22a61a3c68a@DEISMMXS02.pt.local> Message-ID: <66d44a0c3ac14aba8dc958bc76201947@DEISMMXS02.pt.local> If this is the wrong mailing list for javapackager questions, I'd appreciate any hints regarding where to ask instead in case you happen to know. Thank you. -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Buchberger, Joerg Sent: Freitag, 22. Juni 2018 13:30 To: openjfx-dev at openjdk.java.net Subject: javapackager usage Hi everyone Is this the right mailing list for all questions about javapackager? I tried to use javapackager for my spring-boot web application on Windows. So, naturally, it runs headless. Although, creating native image and running that exe was successful, there are some caveats I could not solve yet: * how to prevent second such process from starting * is that what -singleton flag is for? it gets rejected as unsupported option * running it as a service * is that what -daemon flag or WinServiceBundler is for? no idea how either works * and I failed to get such exe to work with sc and nssm - each fails to start for different reason * as the exe produced with javapackager immediately returns, I don't get how to stop my process * only way to stop seems sending the kill to the task - is there a better way? Thanks for your attention. Cheers J?rg p.s. here the command and options I used with Java 9 JDK: javapackager -deploy -nosign -native image -daemon -allpermissions -v -outdir build/dist -outfile vron -name vron -appclass org.springframework.boot.loader.JarLauncher -v -srcdir .\build\libs From kevin.rushforth at oracle.com Tue Jun 26 13:54:05 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 26 Jun 2018 06:54:05 -0700 Subject: javapackager usage In-Reply-To: <66d44a0c3ac14aba8dc958bc76201947@DEISMMXS02.pt.local> References: <23b5aba3c3be405fa4d8f22a61a3c68a@DEISMMXS02.pt.local> <66d44a0c3ac14aba8dc958bc76201947@DEISMMXS02.pt.local> Message-ID: The javapackager tool, which was delivered as part of the Oracle JDK releases along with JavaFX in JDK 8 through JDK 10, has been removed from the JDK as of JDK 11. A JEP for a new packaging tool, jpackager, is being proposed and discussed on core-libs-dev [1]. -- Kevin [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html On 6/26/2018 6:43 AM, Buchberger, Joerg wrote: > If this is the wrong mailing list for javapackager questions, I'd appreciate any hints regarding where to ask instead in case you happen to know. > Thank you. > > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Buchberger, Joerg > Sent: Freitag, 22. Juni 2018 13:30 > To: openjfx-dev at openjdk.java.net > Subject: javapackager usage > > Hi everyone > > Is this the right mailing list for all questions about javapackager? > > I tried to use javapackager for my spring-boot web application on Windows. So, naturally, it runs headless. > Although, creating native image and running that exe was successful, there are some caveats I could not solve yet: > > * how to prevent second such process from starting > * is that what -singleton flag is for? it gets rejected as unsupported option > > * running it as a service > * is that what -daemon flag or WinServiceBundler is for? no idea how either works > * and I failed to get such exe to work with sc and nssm - each fails to start for different reason > > * as the exe produced with javapackager immediately returns, I don't get how to stop my process > * only way to stop seems sending the kill to the task - is there a better way? > > Thanks for your attention. > Cheers > J?rg > > > p.s. here the command and options I used with Java 9 JDK: > > javapackager -deploy -nosign -native image -daemon -allpermissions -v -outdir build/dist -outfile vron -name vron -appclass org.springframework.boot.loader.JarLauncher -v -srcdir .\build\libs > > From kevin.rushforth at oracle.com Tue Jun 26 17:19:06 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 26 Jun 2018 10:19:06 -0700 Subject: Support additional video codec and container format In-Reply-To: References: Message-ID: <893d8da6-ccd0-1ab0-4cb4-c027767d61db@oracle.com> We do not plan to add any more media codecs. I agree that supporting pluggable codecs would be better than adding any more specific codecs. I note that we aren't likely to spend resources on doing this, either. Perhaps someone in the community would be interested in working on it. -- Kevin On 6/25/2018 6:29 AM, Scott Palmer wrote: > I don't want Oracle to add any of those formats. I want them to make it so > *anyone* can add a new codec. Then they don't have to worry so much about > which codecs to support. The community can take care of that. > > If Oracle is going to officially support another codec the only one worth > putting their effort into at this point is HEVC (H.265) > > Scott > > On Sun, Jun 24, 2018 at 10:49 AM Sverre Moe wrote: > >> I wanted to revive this discussion when I saw Java 9 has gotten >> upgraded GStreamer in JEP-257. >> Also Java 11 has an upgrade to GStreamer 1.14 >> https://bugs.openjdk.java.net/browse/JDK-8199527 >> >> The formats supported are very few: >> >> https://docs.oracle.com/javase/10/docs/api/javafx/scene/media/package-summary.html >> >> What does it take to implement support for these Video formats? >> It cannot be a license problem because Java 10 already has x264 as the >> Only supported video format. >> >> Is there any work scheduled to improve on this in JavaFX? >> >> >> >> Den s?n. 10. sep. 2017 kl. 20:49 skrev Sverre Moe : >>> Some very old issues for this kind of change >>> https://bugs.openjdk.java.net/browse/JDK-8091063 >>> https://bugs.openjdk.java.net/browse/JDK-8091656 >>> >>> One new comment on the latter issue suggesting to add new formats like >>> "Ogg/{Vorbis,Theora}, flac, matroska (MKV), Opus, VP8, 3GPP, GSM" >>> >>> This would be great to have on JavaFX. I seriously hope they would add >> it for Java 10 at least, or a later Java 9 update. >>> >>>> Date: Fri, 8 Sep 2017 20:51:06 +1000 >>>> From: John-Val Rose >>>> To: Sverre Moe >>>> Cc: openjfx-dev at openjdk.java.net >>>> Subject: Re: Support additional video codec and container format >>>> Message-ID: <51D7CA89-1D83-4E0F-A9F8-EF59A00B6A74 at gmail.com> >>>> Content-Type: text/plain; charset=us-ascii >>>> >>>> +1 >>>> >>>>> On 8 Sep 2017, at 19:05, Sverre Moe wrote: >>>>> >>>>> Why is JavaFX not supporting open video container and codec? >>>>> From Java 9 VP6 is deprecated. >>>>> >>>>> The only relevant supported coded for JavaFX is H.264/AVC. The only >> other >>>>> alternative is VP6 which has been deprecated in Java 9. >>>>> >>>>> We cannot use H.264 without paying lisence fee for a commercial >> application. >>>>> Support for Ogg Theroa/Vorbis should be considered, at least VP8 >> and/or VP9 >>>>> in place for the deprecated VP6. The MediaPlayer for Java 10 has not >> gotten >>>>> any changes either. I reckon it is too late for Java 9 to get new >> formats. >>> From nakajima.akira at nttcom.co.jp Wed Jun 27 05:52:17 2018 From: nakajima.akira at nttcom.co.jp (Nakajima Akira) Date: Wed, 27 Jun 2018 14:52:17 +0900 Subject: [PATCH] Fix bug to handle minus value glyph_id on Windows Message-ID: <019bd585-5a3b-8cdc-8f15-f890e32055c5@nttcom.co.jp> # This patch is separated from http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/022005.html Java issue error of ArrayIndexOutOfBoundsException by run following Test program on Windows. This bug is that Java handles big glyph_id as minus value. For Example, Inside JavaFX, glyph_id 49496(Uint16) is now handled as -16040(short). ScreenShots of before/after applying this patch. Windows10 x64 (openjfx11 and Oracle JDK 10.0.1) https://drive.google.com/drive/folders/1UHPfCbQF4X_SSvjqgNGGKfEm-8GiNP80 # NOTICE Now Windows API provide glyphIndices as UINT16. Exsample) https://msdn.microsoft.com/en-us/library/windows/desktop/dd316625%28v=vs.85%29.aspx But originally, Windows API should provide as UINT32. Because CMAP Format 8,12,13 have UINT32. https://docs.microsoft.com/en-us/typography/opentype/spec/cmap https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6cmap.html I have not reported to Microsoft, since I guess Microsoft knows this problem. CMap.java provide char (UINT16). Freetype2 provide UINT32. Thanks. Akira Nakajima [PATCH] javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java ========================= PATCH ========================= diff --git a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java --- a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java +++ b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java @@ -52,6 +52,7 @@ private static D2D1_COLOR_F WHITE = new D2D1_COLOR_F(1f, 1f, 1f, 1f); private static D2D1_MATRIX_3X2_F D2D2_MATRIX_IDENTITY = new D2D1_MATRIX_3X2_F(1,0, 0,1, 0,0); + static final int intMask = 0x0000ffff; DWGlyph(DWFontStrike strike, int glyphCode, boolean drawShapes) { this.strike = strike; @@ -303,12 +304,12 @@ @Override public int getGlyphCode() { - return run.glyphIndices; + return ((int)run.glyphIndices & intMask); } @Override public RectBounds getBBox() { - return strike.getBBox(run.glyphIndices); + return strike.getBBox((int)run.glyphIndices & intMask); } @Override @@ -321,7 +322,7 @@ @Override public Shape getShape() { - return strike.createGlyphOutline(run.glyphIndices); + return strike.createGlyphOutline((int)run.glyphIndices & intMask); } @Override diff --git a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java --- a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java +++ b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java @@ -138,6 +138,7 @@ int i, j; int[] iglyphs = new int[glyphCount]; int slotMask = slot << 24; + final int intMask = 0x0000ffff; boolean missingGlyph = false; i = 0; j = rtl ? glyphCount - 1 : 0; while (i < glyphCount) { @@ -145,7 +146,7 @@ missingGlyph = true; if (composite) break; } - iglyphs[i] = glyphs[j] | slotMask; + iglyphs[i] = ((int)glyphs[j] & intMask) | slotMask; i++; j+=step; } ========================= Test for Win10 ========================= import javafx.application.Application; import static javafx.application.Application.launch; import javafx.scene.Group; import javafx.scene.Scene; import javafx.scene.paint.Color; import javafx.scene.text.Font; import javafx.scene.text.Text; import javafx.scene.text.TextFlow; import javafx.stage.Stage; public class TestHandlingBigGlyphID_Win10 extends Application { @Override public void start(Stage stage) throws Exception { final String fontName = "ARIALUNI.TTF"; // Arial Unicode MS // download from https://www.wfonts.com/download/data/2015/05/16/arial-unicode-ms/ARIALUNI.TTF // and place in $(user.home)/fonts/ // e.g. C:/Users/username/fonts/arialuni.ttf Font ourFont = Font.loadFont("file://"+System.getProperty("user.home")+"/fonts/"+fontName.toString(), 48); TextFlow textFlow = new TextFlow(); // Unicode(GlyphID) Text text = new Text("\uD7A3\u0E3F"); // U+D7A3(49496) + U+0E3F(1262) /* Inside JavaFX, 49496(Uint16) is handled as -16040(short). * By ScriptMapper.isComplexCharCode(), U+0E3F is handled as complex. * When in condition with minus glyphID value and complex * , JavaFX is forcibly terminated. * (java.lang.ArrayIndexOutOfBoundsException) */ text.setFill(Color.GREEN); text.setFont(ourFont); textFlow.getChildren().addAll(text); Group group = new Group(textFlow); Scene scene = new Scene(group, 100, 60, Color.WHITE); stage.setScene(scene); stage.show(); } } ========================= Test for Win7 and Win10 ========================= import javafx.application.Application; import static javafx.application.Application.launch; import javafx.scene.Group; import javafx.scene.Scene; import javafx.scene.paint.Color; import javafx.scene.text.Font; import javafx.scene.text.Text; import javafx.scene.text.TextFlow; import javafx.stage.Stage; public class TestHandlingBigGlyphID_Win7_and_Win10 extends Application { @Override public void start(Stage stage) throws Exception { final String family = "Arial Unicode MS"; // ARIALUNI.TTF // download from https://www.wfonts.com/download/data/2015/05/16/arial-unicode-ms/ARIALUNI.TTF // and You NEED install font. Font ourFont = Font.font(family, 48); TextFlow textFlow = new TextFlow(); // Unicode(GlyphID) Text text = new Text("\uD7A3\u0E3F"); // U+D7A3(49496) + U+0E3F(1262) /* Inside JavaFX, 49496(Uint16) is handled as -16040(short). * By ScriptMapper.isComplexCharCode(), U+0E3F is handled as complex. * When in condition with minus glyphID value and complex * , JavaFX is forcibly terminated. * (java.lang.ArrayIndexOutOfBoundsException) */ text.setFill(Color.GREEN); text.setFont(ourFont); textFlow.getChildren().addAll(text); Group group = new Group(textFlow); Scene scene = new Scene(group, 100, 60, Color.WHITE); stage.setScene(scene); stage.show(); } } -------------------------------------- Company: NTT Comware Corporation Name: Akira Nakajima E-Mail: nakajima.akira at nttcom.co.jp -------------------------------------- From nakajima.akira at nttcom.co.jp Wed Jun 27 06:02:48 2018 From: nakajima.akira at nttcom.co.jp (Nakajima Akira) Date: Wed, 27 Jun 2018 15:02:48 +0900 Subject: [PATCH] Fix bug to handle minus value glyph_id on Windows In-Reply-To: <019bd585-5a3b-8cdc-8f15-f890e32055c5@nttcom.co.jp> References: <019bd585-5a3b-8cdc-8f15-f890e32055c5@nttcom.co.jp> Message-ID: This bug is happened on Windows. Sorry, I should use SHORTMASK instead of intMask. I re-send patch. Difference is name only. intMask -> SHORTMASK diff --git a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java --- a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java +++ b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java @@ -52,6 +52,7 @@ private static D2D1_COLOR_F WHITE = new D2D1_COLOR_F(1f, 1f, 1f, 1f); private static D2D1_MATRIX_3X2_F D2D2_MATRIX_IDENTITY = new D2D1_MATRIX_3X2_F(1,0, 0,1, 0,0); + static final int SHORTMASK = 0x0000ffff; DWGlyph(DWFontStrike strike, int glyphCode, boolean drawShapes) { this.strike = strike; @@ -303,12 +304,12 @@ @Override public int getGlyphCode() { - return run.glyphIndices; + return ((int)run.glyphIndices & SHORTMASK); } @Override public RectBounds getBBox() { - return strike.getBBox(run.glyphIndices); + return strike.getBBox((int)run.glyphIndices & SHORTMASK); } @Override @@ -321,7 +322,7 @@ @Override public Shape getShape() { - return strike.createGlyphOutline(run.glyphIndices); + return strike.createGlyphOutline((int)run.glyphIndices & SHORTMASK); } @Override diff --git a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java --- a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java +++ b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java @@ -138,6 +138,7 @@ int i, j; int[] iglyphs = new int[glyphCount]; int slotMask = slot << 24; + final int SHORTMASK = 0x0000ffff; boolean missingGlyph = false; i = 0; j = rtl ? glyphCount - 1 : 0; while (i < glyphCount) { @@ -145,7 +146,7 @@ missingGlyph = true; if (composite) break; } - iglyphs[i] = glyphs[j] | slotMask; + iglyphs[i] = ((int)glyphs[j] & SHORTMASK) | slotMask; i++; j+=step; } Thanks. Akira Nakajima On 2018/06/27 14:52, Nakajima Akira wrote: > # This patch is separated from > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/022005.html > > > Java issue error of ArrayIndexOutOfBoundsException by run following Test > program on Windows. > This bug is that Java handles big glyph_id as minus value. > For Example, > Inside JavaFX, glyph_id 49496(Uint16) is now handled as -16040(short). > > > ScreenShots of before/after applying this patch. > Windows10 x64 (openjfx11 and Oracle JDK 10.0.1) > https://drive.google.com/drive/folders/1UHPfCbQF4X_SSvjqgNGGKfEm-8GiNP80 > > > > # NOTICE > Now Windows API provide glyphIndices as UINT16. > Exsample) > https://msdn.microsoft.com/en-us/library/windows/desktop/dd316625%28v=vs.85%29.aspx > > > But originally, Windows API should provide as UINT32. > Because CMAP Format 8,12,13 have UINT32. > https://docs.microsoft.com/en-us/typography/opentype/spec/cmap > https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6cmap.html > > > I have not reported to Microsoft, since I guess Microsoft knows this > problem. > > CMap.java provide char (UINT16). > Freetype2 provide UINT32. > > > > Thanks. > Akira Nakajima > > > [PATCH] > javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > > > ========================= > PATCH > ========================= > diff --git > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > > --- > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > > +++ > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java > > @@ -52,6 +52,7 @@ > private static D2D1_COLOR_F WHITE = new D2D1_COLOR_F(1f, 1f, 1f, 1f); > private static D2D1_MATRIX_3X2_F D2D2_MATRIX_IDENTITY = new > D2D1_MATRIX_3X2_F(1,0, 0,1, 0,0); > > + static final int intMask = 0x0000ffff; > > DWGlyph(DWFontStrike strike, int glyphCode, boolean drawShapes) { > this.strike = strike; > @@ -303,12 +304,12 @@ > > @Override > public int getGlyphCode() { > - return run.glyphIndices; > + return ((int)run.glyphIndices & intMask); > } > > @Override > public RectBounds getBBox() { > - return strike.getBBox(run.glyphIndices); > + return strike.getBBox((int)run.glyphIndices & intMask); > } > > @Override > @@ -321,7 +322,7 @@ > > @Override > public Shape getShape() { > - return strike.createGlyphOutline(run.glyphIndices); > + return strike.createGlyphOutline((int)run.glyphIndices & intMask); > } > > @Override > diff --git > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > > --- > a/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > > +++ > b/modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java > > @@ -138,6 +138,7 @@ > int i, j; > int[] iglyphs = new int[glyphCount]; > int slotMask = slot << 24; > + final int intMask = 0x0000ffff; > boolean missingGlyph = false; > i = 0; j = rtl ? glyphCount - 1 : 0; > while (i < glyphCount) { > @@ -145,7 +146,7 @@ > missingGlyph = true; > if (composite) break; > } > - iglyphs[i] = glyphs[j] | slotMask; > + iglyphs[i] = ((int)glyphs[j] & intMask) | slotMask; > i++; > j+=step; > } > > > > ========================= > Test for Win10 > ========================= > import javafx.application.Application; > import static javafx.application.Application.launch; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.paint.Color; > import javafx.scene.text.Font; > import javafx.scene.text.Text; > import javafx.scene.text.TextFlow; > import javafx.stage.Stage; > > public class TestHandlingBigGlyphID_Win10 extends Application { > @Override > public void start(Stage stage) throws Exception { > final String fontName = "ARIALUNI.TTF"; // Arial Unicode MS > // download from > https://www.wfonts.com/download/data/2015/05/16/arial-unicode-ms/ARIALUNI.TTF > > // and place in $(user.home)/fonts/ > // e.g. C:/Users/username/fonts/arialuni.ttf > > Font ourFont = > Font.loadFont("file://"+System.getProperty("user.home")+"/fonts/"+fontName.toString(), > 48); > TextFlow textFlow = new TextFlow(); > // Unicode(GlyphID) > Text text = new Text("\uD7A3\u0E3F"); // U+D7A3(49496) + > U+0E3F(1262) > /* Inside JavaFX, 49496(Uint16) is handled as -16040(short). > * By ScriptMapper.isComplexCharCode(), U+0E3F is handled as > complex. > * When in condition with minus glyphID value and complex > * , JavaFX is forcibly terminated. > * (java.lang.ArrayIndexOutOfBoundsException) > */ > > text.setFill(Color.GREEN); > text.setFont(ourFont); > textFlow.getChildren().addAll(text); > > Group group = new Group(textFlow); > Scene scene = new Scene(group, 100, 60, Color.WHITE); > stage.setScene(scene); > stage.show(); > } > } > > ========================= > Test for Win7 and Win10 > ========================= > import javafx.application.Application; > import static javafx.application.Application.launch; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.paint.Color; > import javafx.scene.text.Font; > import javafx.scene.text.Text; > import javafx.scene.text.TextFlow; > import javafx.stage.Stage; > > public class TestHandlingBigGlyphID_Win7_and_Win10 extends Application { > @Override > public void start(Stage stage) throws Exception { > final String family = "Arial Unicode MS"; // ARIALUNI.TTF > // download from > https://www.wfonts.com/download/data/2015/05/16/arial-unicode-ms/ARIALUNI.TTF > > // and You NEED install font. > > Font ourFont = Font.font(family, 48); > TextFlow textFlow = new TextFlow(); > // Unicode(GlyphID) > Text text = new Text("\uD7A3\u0E3F"); // U+D7A3(49496) + > U+0E3F(1262) > /* Inside JavaFX, 49496(Uint16) is handled as -16040(short). > * By ScriptMapper.isComplexCharCode(), U+0E3F is handled as > complex. > * When in condition with minus glyphID value and complex > * , JavaFX is forcibly terminated. > * (java.lang.ArrayIndexOutOfBoundsException) > */ > > text.setFill(Color.GREEN); > text.setFont(ourFont); > textFlow.getChildren().addAll(text); > > Group group = new Group(textFlow); > Scene scene = new Scene(group, 100, 60, Color.WHITE); > stage.setScene(scene); > stage.show(); > } > } > > > -------------------------------------- > Company: NTT Comware Corporation > Name: Akira Nakajima > E-Mail: nakajima.akira at nttcom.co.jp > -------------------------------------- From arunprasad.rajkumar at oracle.com Wed Jun 27 11:21:18 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 27 Jun 2018 16:51:18 +0530 Subject: [openjfx11] Review request for 8204856: WebEngine document becomes null after PAGE_REPLACED event Message-ID: Hi, Please review the following fix: patch: http://cr.openjdk.java.net/~arajkumar/8204856/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8204856 Root cause: When ever location changes due WebHistory API calls, we propagate it to WebEngine to update the `location` property. However the private method{WebEngine.updateLocation} which we used to update `location` also invalidates the `document` property of WebEngine, which is undesirable. Solution: Directly update the `location` property when WebEngine gets PAGE_REPLACED event. Don?t use {WebEngine.updateLocation}. Testing: Unit tests are added to cover both history.pushState and history.replaceState., Use the following command to run the newly added unit test, ``` gradle :web:cleanTest :web:test --tests test.javafx.scene.web.HistoryStateTest ``` (Note: No _need_ to compile the web module in order to test this fix, all changes are done only in Java binding files) Regards, Arun From arunprasad.rajkumar at oracle.com Wed Jun 27 15:57:21 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 27 Jun 2018 21:27:21 +0530 Subject: [11] Review request: 8199474: Update to 606.1 version of WebKit Message-ID: <19EECE1C-A46B-4161-A75B-F171336F9B62@oracle.com> Hello All, Following patchset contains changes to upgrade to newer WebKit which is based on GTK WebKit 2.20 [1] http://cr.openjdk.java.net/~arajkumar/8199474/webrev Above link has a webrev and a changeset file, 1. rt-non-native-webkit ? Contains changes other than "modules/javafx.web/src/main/native", it will be useful _only_ for review. 2. rt.changeset.gz ? Actual changeset file in compressed format which contains all the changes from ?rt? directory, uncompress before using it(gunzip rt.changeset.gz) and do the following steps., $ hg clone http://hg.openjdk.java.net/openjfx/jfx-dev/rt $ cd rt $ hg import --no-commit rt.changeset #(from rt.changset.gz) (Note: Changeset is marginally bigger than usual because it removes all unused WebCore files from the repo) [1] https://trac.webkit.org/wiki/WebKitGTK/2.20.x Thanks, Arun From kevin.rushforth at oracle.com Fri Jun 29 17:23:08 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 29 Jun 2018 10:23:08 -0700 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> Message-ID: I'll plan to review the code today if possible. This will need one more reviewer, so maybe Phil can also review it, since he reviewed the Java2D patch? As for my comments on the test: > Finally I think this test should be manually run only if Marlin > renderer is modified. > How to do that ? use @Ignore or specific tags ? As a slight variation of this: How about running a small number (say, 200 or 250) by default, but adding a flag to run more? Alternatively, you could use a flag to enable it, but since you would need to do something extra (provide a flag or modify the test) to run it, we might as well get at least some testing all the time. Unless you really think there is no value in doing this. > I deliberately set all these Marlin clip (runtime + always subdivider) > / curve quality settings (quads / cubics thresholds) to be sure of the > concrete Marlin setup as quality thresholds are sensitive to such values. As a best practice, tests should generally be run using the same settings as are used in production. Other than to verify how it behaves when you change these settings, I don't see the value in testing the system running in a mode that no application will ever see. I may be missing some point here. -- Kevin On 6/25/2018 9:01 AM, Laurent Bourg?s wrote: > Kevin, > > Here are my comments below: > > 2018-06-16 1:47 GMT+02:00 Kevin Rushforth >: > > I tested this on all three platforms and the updated rasterizer > looks good. > > I spot checked the code changes, but didn't get time to do a > complete review yet. I was mostly looking for diffs between the > Java2D version which was already reviewed, and this one. > > I do have a couple comments on the new ClipShapeTest (which looks > like a nice accuracy test, btw). > > 1. The test runs for way too long (about 20x too long) to include > in our normal test runs. By default the entire class file (all > three tests) needs to take < 5 minutes and 2 minutes would be > better. I measured the time on 4 machines that I have and found > that if you cut the number of iterations down from 5000 to 250 it > will be just about the right run time. Then you can set the > timeout to 120 seconds (the slowest test on the slowest of my > machines took about 48 seconds, so a 2 minute timeout should be > plenty). > > > I agree this test is very long but it is the only mean I found to test > all possible stroke combinations and test enough shapes (5000) to > detect bugs. > I wondered if using mask directly (via ShapeUtils.getMaskData()) would > become faster but it will never run below the 2 minutes threshold in > total. > > Finally I think this test should be manually run only if Marlin > renderer is modified. > How to do that ? use @Ignore or specific tags ? > > > 2. Can you explain the reason for setting the following? > > ?206???????? // disable static clipping setting: > ?207???????? System.setProperty("prism.marlin.clip", "false"); > ?208???????? > System.setProperty("prism.marlin.clip.runtime.enable", "true"); > ?209 > ?210???????? // enable subdivider: > ?211???????? System.setProperty("prism.marlin.clip.subdivider", > "true"); > ?212 > ?213???????? // disable min length check: always subdivide curves > at clip edges > ?214 System.setProperty("prism.marlin.clip.subdivider.minLength", > "-1"); > ?215 > ?216???????? // If any curve, increase curve accuracy: > ?217???????? // curve length max error: > ?218???????? System.setProperty("prism.marlin.curve_len_err", "1e-4"); > ?219 > ?220???????? // cubic min/max error: > ?221???????? System.setProperty("prism.marlin.cubic_dec_d2", "1e-3"); > ?222???????? System.setProperty("prism.marlin.cubic_inc_d1", > "1e-4"); // or disabled ~ 1e-6 > ?223 > ?224???????? // quad max error: > ?225???????? System.setProperty("prism.marlin.quad_dec_d2", "5e-4"); > > It seems better to test with the default parameters (i.e., it > makes a better regression test that way). > > > I deliberately set all these Marlin clip (runtime + always subdivider) > / curve quality settings (quads / cubics thresholds) to be sure of the > concrete Marlin setup as quality thresholds are sensitive to such values. > > The ClipShapeTest is dedicated to test the clipper (+ subdivider) part > of the Marlin renderer. > > > > 3. Related to that, I think you should eliminate the following (I > don't recommend running functional tests with this set), although > since you don't do any animation, it probably doesn't matter. > > ?227???????? System.setProperty("javafx.animation.fullspeed", > "true"); // full speed > > > I will remove it and see if the overall test is not slower. > Is Platform.runLater() impacted by such setting (latency of FX thread > -> Prism rendering thread ?) ? > > Laurent > > > > On 6/8/2018 7:28 AM, Laurent Bourg?s wrote: > > Hi, > > Please review this large patch to upgrade MarlinFX to 0.9.2 in > OpenJFX11: > JBS: https://bugs.openjdk.java.net/browse/JDK-8198885 > > webrev: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.0/ > > > > PR: https://github.com/javafxports/openjdk-jfx/pull/96 > (CI OK) > > This patch is almost identical to Marlin(2D) patch, see: > https://bugs.openjdk.java.net/browse/JDK-8198885 > > > I added the ClipShapeTest (ported to jfx) that compares shape > clipping (within threshold) and it works (within large timeouts): > gradle -PFULL_TEST=true :system:test --tests > test.com.sun.marlin.ClipShapeTest > > Regards, > Laurent > > > From kevin.rushforth at oracle.com Fri Jun 29 18:25:40 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 29 Jun 2018 11:25:40 -0700 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> Message-ID: <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> One more thing about the test. All of the OpenJFX unit tests should have GPL v2 + Classpath Exception (this differs from the JDK). -- Kevin On 6/29/2018 10:23 AM, Kevin Rushforth wrote: > > I'll plan to review the code today if possible. This will need one > more reviewer, so maybe Phil can also review it, since he reviewed the > Java2D patch? > > As for my comments on the test: > >> Finally I think this test should be manually run only if Marlin >> renderer is modified. >> How to do that ? use @Ignore or specific tags ? > > As a slight variation of this: How about running a small number (say, > 200 or 250) by default, but adding a flag to run more? Alternatively, > you could use a flag to enable it, but since you would need to do > something extra (provide a flag or modify the test) to run it, we > might as well get at least some testing all the time. Unless you > really think there is no value in doing this. > >> I deliberately set all these Marlin clip (runtime + always >> subdivider) / curve quality settings (quads / cubics thresholds) to >> be sure of the concrete Marlin setup as quality thresholds are >> sensitive to such values. > > As a best practice, tests should generally be run using the same > settings as are used in production. Other than to verify how it > behaves when you change these settings, I don't see the value in > testing the system running in a mode that no application will ever > see. I may be missing some point here. > > -- Kevin > > > On 6/25/2018 9:01 AM, Laurent Bourg?s wrote: >> Kevin, >> >> Here are my comments below: >> >> 2018-06-16 1:47 GMT+02:00 Kevin Rushforth > >: >> >> ??? I tested this on all three platforms and the updated rasterizer >> ??? looks good. >> >> ??? I spot checked the code changes, but didn't get time to do a >> ??? complete review yet. I was mostly looking for diffs between the >> ??? Java2D version which was already reviewed, and this one. >> >> ??? I do have a couple comments on the new ClipShapeTest (which looks >> ??? like a nice accuracy test, btw). >> >> ??? 1. The test runs for way too long (about 20x too long) to include >> ??? in our normal test runs. By default the entire class file (all >> ??? three tests) needs to take < 5 minutes and 2 minutes would be >> ??? better. I measured the time on 4 machines that I have and found >> ??? that if you cut the number of iterations down from 5000 to 250 it >> ??? will be just about the right run time. Then you can set the >> ??? timeout to 120 seconds (the slowest test on the slowest of my >> ??? machines took about 48 seconds, so a 2 minute timeout should be >> ??? plenty). >> >> >> I agree this test is very long but it is the only mean I found to >> test all possible stroke combinations and test enough shapes (5000) >> to detect bugs. >> I wondered if using mask directly (via ShapeUtils.getMaskData()) >> would become faster but it will never run below the 2 minutes >> threshold in total. >> >> Finally I think this test should be manually run only if Marlin >> renderer is modified. >> How to do that ? use @Ignore or specific tags ? >> >> >> ??? 2. Can you explain the reason for setting the following? >> >> ??? ?206???????? // disable static clipping setting: >> ??? ?207???????? System.setProperty("prism.marlin.clip", "false"); >> ??? ?208 >> ??? System.setProperty("prism.marlin.clip.runtime.enable", "true"); >> ??? ?209 >> ??? ?210???????? // enable subdivider: >> ??? ?211 System.setProperty("prism.marlin.clip.subdivider", >> ??? "true"); >> ??? ?212 >> ??? ?213???????? // disable min length check: always subdivide curves >> ??? at clip edges >> ??? ?214 System.setProperty("prism.marlin.clip.subdivider.minLength", >> ??? "-1"); >> ??? ?215 >> ??? ?216???????? // If any curve, increase curve accuracy: >> ??? ?217???????? // curve length max error: >> ??? ?218 System.setProperty("prism.marlin.curve_len_err", "1e-4"); >> ??? ?219 >> ??? ?220???????? // cubic min/max error: >> ??? ?221???????? System.setProperty("prism.marlin.cubic_dec_d2", >> "1e-3"); >> ??? ?222???????? System.setProperty("prism.marlin.cubic_inc_d1", >> ??? "1e-4"); // or disabled ~ 1e-6 >> ??? ?223 >> ??? ?224???????? // quad max error: >> ??? ?225???????? System.setProperty("prism.marlin.quad_dec_d2", "5e-4"); >> >> ??? It seems better to test with the default parameters (i.e., it >> ??? makes a better regression test that way). >> >> >> I deliberately set all these Marlin clip (runtime + always >> subdivider) / curve quality settings (quads / cubics thresholds) to >> be sure of the concrete Marlin setup as quality thresholds are >> sensitive to such values. >> >> The ClipShapeTest is dedicated to test the clipper (+ subdivider) >> part of the Marlin renderer. >> >> >> >> ??? 3. Related to that, I think you should eliminate the following (I >> ??? don't recommend running functional tests with this set), although >> ??? since you don't do any animation, it probably doesn't matter. >> >> ??? ?227 System.setProperty("javafx.animation.fullspeed", >> ??? "true"); // full speed >> >> >> I will remove it and see if the overall test is not slower. >> Is Platform.runLater() impacted by such setting (latency of FX thread >> -> Prism rendering thread ?) ? >> >> Laurent >> >> >> >> ??? On 6/8/2018 7:28 AM, Laurent Bourg?s wrote: >> >> ??????? Hi, >> >> ??????? Please review this large patch to upgrade MarlinFX to 0.9.2 in >> ??????? OpenJFX11: >> ??????? JBS: https://bugs.openjdk.java.net/browse/JDK-8198885 >> ??????? >> ??????? webrev: >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.0/ >> >> > > >> ??????? PR: https://github.com/javafxports/openjdk-jfx/pull/96 >> (CI OK) >> >> ??????? This patch is almost identical to Marlin(2D) patch, see: >> ??????? https://bugs.openjdk.java.net/browse/JDK-8198885 >> ??????? >> >> ??????? I added the ClipShapeTest (ported to jfx) that compares shape >> ??????? clipping (within threshold) and it works (within large >> timeouts): >> ??????? gradle -PFULL_TEST=true :system:test --tests >> ??????? test.com.sun.marlin.ClipShapeTest >> >> ??????? Regards, >> ??????? Laurent >> >> >> > From kevin.rushforth at oracle.com Fri Jun 29 20:52:07 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 29 Jun 2018 13:52:07 -0700 Subject: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2 In-Reply-To: <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> References: <61ca8296-fc1b-87ee-18aa-b24e80b39617@oracle.com> <5f1e8aa8-f050-bb86-61ca-a51bc91beff3@oracle.com> Message-ID: <646800cc-0ffd-3fe8-5cd0-67d6cc59eddb@oracle.com> I'm giving a +1 on the implementation changes. I scanned the webrev and didn't see anything out of place. I compared the diffs of the FX Marlin 0.9.2 with the Java2D 0.9.1 changeset, and there were a few more diffs than I might have expoected, but nothing jumped out of me as a problem. Also, I've tested it pretty well on all three platforms. The overall +1 is pending the fixes needed for the test: at least the copyright header and shortening or disabling the test. -- Kevin On 6/29/2018 11:25 AM, Kevin Rushforth wrote: > One more thing about the test. All of the OpenJFX unit tests should > have GPL v2 + Classpath Exception (this differs from the JDK). > > -- Kevin > > > On 6/29/2018 10:23 AM, Kevin Rushforth wrote: >> >> I'll plan to review the code today if possible. This will need one >> more reviewer, so maybe Phil can also review it, since he reviewed >> the Java2D patch? >> >> As for my comments on the test: >> >>> Finally I think this test should be manually run only if Marlin >>> renderer is modified. >>> How to do that ? use @Ignore or specific tags ? >> >> As a slight variation of this: How about running a small number (say, >> 200 or 250) by default, but adding a flag to run more? Alternatively, >> you could use a flag to enable it, but since you would need to do >> something extra (provide a flag or modify the test) to run it, we >> might as well get at least some testing all the time. Unless you >> really think there is no value in doing this. >> >>> I deliberately set all these Marlin clip (runtime + always >>> subdivider) / curve quality settings (quads / cubics thresholds) to >>> be sure of the concrete Marlin setup as quality thresholds are >>> sensitive to such values. >> >> As a best practice, tests should generally be run using the same >> settings as are used in production. Other than to verify how it >> behaves when you change these settings, I don't see the value in >> testing the system running in a mode that no application will ever >> see. I may be missing some point here. >> >> -- Kevin >> >> >> On 6/25/2018 9:01 AM, Laurent Bourg?s wrote: >>> Kevin, >>> >>> Here are my comments below: >>> >>> 2018-06-16 1:47 GMT+02:00 Kevin Rushforth >>> >: >>> >>> ??? I tested this on all three platforms and the updated rasterizer >>> ??? looks good. >>> >>> ??? I spot checked the code changes, but didn't get time to do a >>> ??? complete review yet. I was mostly looking for diffs between the >>> ??? Java2D version which was already reviewed, and this one. >>> >>> ??? I do have a couple comments on the new ClipShapeTest (which looks >>> ??? like a nice accuracy test, btw). >>> >>> ??? 1. The test runs for way too long (about 20x too long) to include >>> ??? in our normal test runs. By default the entire class file (all >>> ??? three tests) needs to take < 5 minutes and 2 minutes would be >>> ??? better. I measured the time on 4 machines that I have and found >>> ??? that if you cut the number of iterations down from 5000 to 250 it >>> ??? will be just about the right run time. Then you can set the >>> ??? timeout to 120 seconds (the slowest test on the slowest of my >>> ??? machines took about 48 seconds, so a 2 minute timeout should be >>> ??? plenty). >>> >>> >>> I agree this test is very long but it is the only mean I found to >>> test all possible stroke combinations and test enough shapes (5000) >>> to detect bugs. >>> I wondered if using mask directly (via ShapeUtils.getMaskData()) >>> would become faster but it will never run below the 2 minutes >>> threshold in total. >>> >>> Finally I think this test should be manually run only if Marlin >>> renderer is modified. >>> How to do that ? use @Ignore or specific tags ? >>> >>> >>> ??? 2. Can you explain the reason for setting the following? >>> >>> ??? ?206???????? // disable static clipping setting: >>> ??? ?207???????? System.setProperty("prism.marlin.clip", "false"); >>> ??? ?208 >>> ??? System.setProperty("prism.marlin.clip.runtime.enable", "true"); >>> ??? ?209 >>> ??? ?210???????? // enable subdivider: >>> ??? ?211 System.setProperty("prism.marlin.clip.subdivider", >>> ??? "true"); >>> ??? ?212 >>> ??? ?213???????? // disable min length check: always subdivide curves >>> ??? at clip edges >>> ??? ?214 System.setProperty("prism.marlin.clip.subdivider.minLength", >>> ??? "-1"); >>> ??? ?215 >>> ??? ?216???????? // If any curve, increase curve accuracy: >>> ??? ?217???????? // curve length max error: >>> ??? ?218 System.setProperty("prism.marlin.curve_len_err", "1e-4"); >>> ??? ?219 >>> ??? ?220???????? // cubic min/max error: >>> ??? ?221 System.setProperty("prism.marlin.cubic_dec_d2", "1e-3"); >>> ??? ?222 System.setProperty("prism.marlin.cubic_inc_d1", >>> ??? "1e-4"); // or disabled ~ 1e-6 >>> ??? ?223 >>> ??? ?224???????? // quad max error: >>> ??? ?225 System.setProperty("prism.marlin.quad_dec_d2", "5e-4"); >>> >>> ??? It seems better to test with the default parameters (i.e., it >>> ??? makes a better regression test that way). >>> >>> >>> I deliberately set all these Marlin clip (runtime + always >>> subdivider) / curve quality settings (quads / cubics thresholds) to >>> be sure of the concrete Marlin setup as quality thresholds are >>> sensitive to such values. >>> >>> The ClipShapeTest is dedicated to test the clipper (+ subdivider) >>> part of the Marlin renderer. >>> >>> >>> >>> ??? 3. Related to that, I think you should eliminate the following (I >>> ??? don't recommend running functional tests with this set), although >>> ??? since you don't do any animation, it probably doesn't matter. >>> >>> ??? ?227 System.setProperty("javafx.animation.fullspeed", >>> ??? "true"); // full speed >>> >>> >>> I will remove it and see if the overall test is not slower. >>> Is Platform.runLater() impacted by such setting (latency of FX >>> thread -> Prism rendering thread ?) ? >>> >>> Laurent >>> >>> >>> >>> ??? On 6/8/2018 7:28 AM, Laurent Bourg?s wrote: >>> >>> ??????? Hi, >>> >>> ??????? Please review this large patch to upgrade MarlinFX to 0.9.2 in >>> ??????? OpenJFX11: >>> ??????? JBS: https://bugs.openjdk.java.net/browse/JDK-8198885 >>> >>> ??????? webrev: >>> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.0/ >>> >>> >> > >>> ??????? PR: https://github.com/javafxports/openjdk-jfx/pull/96 >>> (CI OK) >>> >>> ??????? This patch is almost identical to Marlin(2D) patch, see: >>> ??????? https://bugs.openjdk.java.net/browse/JDK-8198885 >>> >>> >>> ??????? I added the ClipShapeTest (ported to jfx) that compares shape >>> ??????? clipping (within threshold) and it works (within large >>> timeouts): >>> ??????? gradle -PFULL_TEST=true :system:test --tests >>> ??????? test.com.sun.marlin.ClipShapeTest >>> >>> ??????? Regards, >>> ??????? Laurent >>> >>> >>> >> > From nlisker at gmail.com Fri Jun 29 22:02:25 2018 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 30 Jun 2018 01:02:25 +0300 Subject: Change of default behavior of When Message-ID: Hi all, The class javafx.beans.binding.When is using eager evaluation of its arguments [1]. Kevin and I discussed the idea of changing this default behavior to the more intuitive lazy evaluation as done in a simple ternary expression. This is a potentially breaking change for current code that (for some reason) relies on both values being evaluated regardless of the condition's value. This behavior is not documented. If anyone has any reservations, please voice them over the next few days. Thanks, Nir [1] https://bugs.openjdk.java.net/browse/JDK-8089579