From philip.race at oracle.com Tue May 1 05:27:34 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 30 Apr 2018 22:27:34 -0700 Subject: native libs in modules In-Reply-To: <5fe89af2-5f06-b0e8-e50e-1533e54ac864@oracle.com> References: <5fe89af2-5f06-b0e8-e50e-1533e54ac864@oracle.com> Message-ID: <8610BD4F-286F-4BD6-A133-DC4517C2BEA7@oracle.com> You are describing the situation today and making it into a contract. You need to be sure that it is policed and enforceable. Meaning there need to be tests to ensure it stays that way and that it is not an unreasonable constraint on changes in the platform. Also what if anything do the jigsaw team recommend ? -Phil. > On Apr 30, 2018, at 4:07 PM, Kevin Rushforth wrote: > > The native libraries are quite large -- especially jfxwebkit -- and it does seem better to have per-platform jar files, at least for the native libraries. The following modules could be platform-independent since they have no natives: > > javafx.base > javafx.controls > javafx.fxml > javafx.swing > > We would just need to test that the set of modular jar files for each platform are the same, and then pick one (Linux?) to use for generating the platform-independent jar files. > > The following modules have native libraries: > > javafx.graphics (*) > javafx.media (*) > javafx.web > > (*) - also has some differences in the set of class files that are included depending on the platform > > So per-platform versions of the above would be needed to accommodate the different native libraries. > > If it would help, the .class files could be always included for all platforms, but there would be some additional effort to make this work. Also, it might be just as easy to have the class files and the natives in one downloaded jar file per platform, since at least the natives need to be platform-independent. I'm far from a maven expert, though, so I don't really know for sure which path is easier. > > -- Kevin > > >> On 4/30/2018 9:44 AM, Paul Ray Russell wrote: >> >I'm not sure I understand the question about platform-specific jar files, >> >> Last time I worked on native specifics (which was to package up RXTX dlls >> for different OSs / in 64/32 bit) The easiest solution for pure Maven >> builds seemed to be, to package DLLs inside a jar. We then used a profile >> to control which DLL's were grabbed in different cases. And surely for this >> specific case, it would be better to split the native specifics into >> separate jars per OS to avoid a huge cross-OS download? > From johan.vos at gluonhq.com Tue May 1 12:34:20 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 01 May 2018 12:34:20 +0000 Subject: native libs in modules In-Reply-To: <8610BD4F-286F-4BD6-A133-DC4517C2BEA7@oracle.com> References: <5fe89af2-5f06-b0e8-e50e-1533e54ac864@oracle.com> <8610BD4F-286F-4BD6-A133-DC4517C2BEA7@oracle.com> Message-ID: I'd love to hear a general recommendation from the jigsaw team as well. Clearly, there are a number of solutions, and as a developer, I easily get confused if some frameworks do it with option A and others with option B. So what is the preferred approach in general? It seems (given the large size of the webkit native library) there is a growing consensus here for bundling native code inside platform-specific jars? - Johan On Tue, May 1, 2018 at 7:38 AM Phil Race wrote: > You are describing the situation today and making it into a contract. You > need to be sure that it is policed and enforceable. > Meaning there need to be tests to ensure it stays that way and that it is > not an unreasonable constraint on changes in the platform. > > Also what if anything do the jigsaw team recommend ? > > -Phil. > > > On Apr 30, 2018, at 4:07 PM, Kevin Rushforth > wrote: > > > > The native libraries are quite large -- especially jfxwebkit -- and it > does seem better to have per-platform jar files, at least for the native > libraries. The following modules could be platform-independent since they > have no natives: > > > > javafx.base > > javafx.controls > > javafx.fxml > > javafx.swing > > > > We would just need to test that the set of modular jar files for each > platform are the same, and then pick one (Linux?) to use for generating the > platform-independent jar files. > > > > The following modules have native libraries: > > > > javafx.graphics (*) > > javafx.media (*) > > javafx.web > > > > (*) - also has some differences in the set of class files that are > included depending on the platform > > > > So per-platform versions of the above would be needed to accommodate the > different native libraries. > > > > If it would help, the .class files could be always included for all > platforms, but there would be some additional effort to make this work. > Also, it might be just as easy to have the class files and the natives in > one downloaded jar file per platform, since at least the natives need to be > platform-independent. I'm far from a maven expert, though, so I don't > really know for sure which path is easier. > > > > -- Kevin > > > > > >> On 4/30/2018 9:44 AM, Paul Ray Russell wrote: > >> >I'm not sure I understand the question about platform-specific jar > files, > >> > >> Last time I worked on native specifics (which was to package up RXTX > dlls > >> for different OSs / in 64/32 bit) The easiest solution for pure Maven > >> builds seemed to be, to package DLLs inside a jar. We then used a > profile > >> to control which DLL's were grabbed in different cases. And surely for > this > >> specific case, it would be better to split the native specifics into > >> separate jars per OS to avoid a huge cross-OS download? > > > > From kevin.rushforth at oracle.com Tue May 1 15:36:05 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 1 May 2018 08:36:05 -0700 Subject: native libs in modules In-Reply-To: References: <5fe89af2-5f06-b0e8-e50e-1533e54ac864@oracle.com> <8610BD4F-286F-4BD6-A133-DC4517C2BEA7@oracle.com> Message-ID: [including Alan and Mandy] This came up briefly in a thread sent to jigsaw-dev [1], but with no real conclusion. I agree that it would be good to get a recommendation from the Jigsaw team. After thinking about it more, here are my preferences: * From the developer's point of view, they shouldn't have to know or care that some of our modules have platform-specific native code and others do not. Ideally, all an app developer should need is to declare a dependency on the needed module(s). Something like this: ??? 'javafx:javafx.controls:11' ??? 'javafx:javafx.graphics:11' ? (although controls will depend on graphics, so this should be optional) * For maven, the pom file should take care of downloading the jar file(s) for the specific platform; not sure if that is possible for gradle dependencies, but it would be ideal. * For each module, we can package up the natives in one of two ways: A) create a separate jar file per platform with the native code and the modular jar both in the same jar file. something like: javafx-graphics-win-x64.jar javafx-graphics-linux-x64.jar javafx-graphics-osx-x64.jar B) create one platform-independent modular jar file with all classes for all platforms, and also a separate jar per platform just for the native libraries: javafx-graphics.jar? (with classes for all platforms) javafx-graphics-natives-win-x64.jar javafx-graphics-natives-linux-x64.jar javafx-graphics-natives-osx-x64.jar For either option there will need to be code that unpacks the natives. I prefer option A if feasible, as I think it simplifies the build, hopefully without unduly complicating anything else. If it isn't feasible, then option B might be a good fallback. Comments? -- Kevin [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-April/013762.html On 5/1/2018 5:34 AM, Johan Vos wrote: > I'd love to hear a general recommendation from the jigsaw team as well. > Clearly, there are a number of solutions, and as a developer, I easily > get confused if some frameworks do it with option A and others with > option B. > So what is the preferred approach in general? > > It seems (given the large size of the webkit native library) there is > a growing consensus here for bundling native code inside > platform-specific jars? > > - Johan > > On Tue, May 1, 2018 at 7:38 AM Phil Race > wrote: > > You are describing the situation today and making it into a > contract. You need to be sure that it is policed and enforceable. > Meaning there need to be tests to ensure it stays that way and > that it is not an unreasonable constraint on changes in the platform. > > Also what if anything do the jigsaw team recommend ? > > -Phil. > > > On Apr 30, 2018, at 4:07 PM, Kevin Rushforth > > > wrote: > > > > The native libraries are quite large -- especially jfxwebkit -- > and it does seem better to have per-platform jar files, at least > for the native libraries. The following modules could be > platform-independent since they have no natives: > > > > javafx.base > > javafx.controls > > javafx.fxml > > javafx.swing > > > > We would just need to test that the set of modular jar files for > each platform are the same, and then pick one (Linux?) to use for > generating the platform-independent jar files. > > > > The following modules have native libraries: > > > > javafx.graphics (*) > > javafx.media (*) > > javafx.web > > > > (*) - also has some differences in the set of class files that > are included depending on the platform > > > > So per-platform versions of the above would be needed to > accommodate the different native libraries. > > > > If it would help, the .class files could be always included for > all platforms, but there would be some additional effort to make > this work. Also, it might be just as easy to have the class files > and the natives in one downloaded jar file per platform, since at > least the natives need to be platform-independent. I'm far from a > maven expert, though, so I don't really know for sure which path > is easier. > > > > -- Kevin > > > > > >> On 4/30/2018 9:44 AM, Paul Ray Russell wrote: > >>? >I'm not sure I understand the question about > platform-specific jar files, > >> > >> Last time I worked on native specifics (which was to package up > RXTX dlls > >> for different OSs / in 64/32 bit) The easiest solution for pure > Maven > >> builds seemed to be, to package DLLs inside a jar. We then used > a profile > >> to control which DLL's were grabbed in different cases. And > surely for this > >> specific case, it would be better to split the native specifics > into > >> separate jars per OS to avoid a huge cross-OS download? > > > From kevin.rushforth at oracle.com Tue May 1 15:50:43 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 1 May 2018 08:50:43 -0700 Subject: native libs in modules In-Reply-To: <6b90031c-3738-cda5-5195-a6e85d1f479f@jugs.org> References: <6ee8a8f8-0f15-8c05-ab9a-9f53625123c5@oracle.com> <6b90031c-3738-cda5-5195-a6e85d1f479f@jugs.org> Message-ID: On 4/30/2018 8:58 AM, Michael Paus wrote: > Am 30.04.18 um 17:29 schrieb Kevin Rushforth: >> One thing to note is that unlike the JDK build, all class files for >> Windows, Linux, and Mac are set up to be built (but not shipped) on >> all three platforms, so it might be possible to create a jar file >> that would be the same on all three platforms. I don't know how >> feasible it would be or whether that the right direction to take or not. > If possible, I would like to see a change in this policy to not ship > certain fragments of the build. Especially I would like to have the > possibility to use a JavaFX based on OpenGL on Windows too. This would > make Java truly cross-platform and might offer a lot of possibilities > for better integration of external graphics tools like for example > tools based on JOGL. It might also offer the possibility to support > WebGL in the WebView in the future so that this gap can be closed too. > Am I just dreaming? What do others think? This is somewhat tangential to the issue of how to ship the native libraries and platform-specific classes for each platform. While it is true that the prism_es2 classes and native libraries are compiled on Windows platforms, they aren't part of the build artifacts, and aren't ever run or tested at all. So it wouldn't be as simple as shipping something that is currently not shipped. Doing so would require a bit of work, not to mention a bug tail since OpenGL drivers for Windows tend to be buggy (especially for Intel HD). As for WebGL, it would probably make more sense to use ANGLE to translate to D3D on Windows than try to rely on OpenGL being available everywhere. -- Kevin > Michael From matthew.james.elliot at gmail.com Tue May 1 18:06:47 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Tue, 1 May 2018 20:06:47 +0200 Subject: Paint Phase Debugging / Performance Message-ID: Hi all, The last few days I was troubleshooting a new performance issue that showed up in our PROD application where customers had fallen back to the SW rendering pipeline. It severely affected the application where CPU frequency was under 3 GHz with hover lags of a few seconds in the worst cases. With thousands of potential HW/SW combinations in the wild it took quite a while to even identify it really was an issue in our application and not the usual noise of some silly set up. All this got me thinking... ... what was visible was long paint passes, and long waiting on previous render but narrowing this down to exactly what was going on took a lot of manual inspection of the rendering pipeline code / debugging and somewhat by chance I stumbled over the -Dprism.disableEffects flag which after much more pain helped me narrow down the issue. The root cause turned out to be an -fx-effect (blend, inner shadow) on an animated node that was set from the code by an unknowing developer. While there are tools like mission controller for visualising the pulse and phases it can be difficult to identify for example what is going wrong inside of the painting phase and it is difficult to control that nothing bad happens when many developers can make changes to the code and reviews will never catch everything... I'm therefore thinking about ways to run rendering tests in continuous integration that would fail fast if the SW rendering pipeline would get overloaded. I had a look at PulseListener where I could see pulse times but I'd like to go more detailed and actually like the information tracked in the internals of PulseLogger (PulseData) without doing any nasty tricks. I thought maybe somebody has already thought about this problem before and maybe there is even some tooling around this beyond the logging? I could even imagine using the same technique to monitor the rendering pipeline in real time and alerting us (maybe even the user) if things are going a bit sideways. Maybe more generically, how do you even start to debug delays in the paint phase? Timed breakpoints and IDE assisted debug logging aside. :) Matt. PS: It might even be nice to tell the Painter to give up after N ms (prism setting?). Sometimes better to break than to not be useable because of paint phases taking 200-300 ms and JavaFX Application Thread thread getting almost starved completely. From johan.vos at gluonhq.com Tue May 1 18:48:03 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 01 May 2018 18:48:03 +0000 Subject: Paint Phase Debugging / Performance In-Reply-To: References: Message-ID: Hi Matthew, I agree this is a very important question. I don't like it when people say that "JavaFX is slow" because if everything is done right, JavaFX can be extremely fast. But I also realise that it is very easy to make things very slow in JavaFX, and in case "performance" is slow, it is important to pinpoint the problem as easy as possible. And that is often not trivial, so the easier it becomes to detect problems, the more developers will like JavaFX. I typically start with setting prism.verbose and javafx.pulseLogger to true, as you first need to know in which phase the problem is (e.g. layout or render phase). If you see the problem is in the render phase, you have to look at completely different things. Note that in most cases I've seen with bad performance, the problem was not in the rendering, but simply due to too much happening on the JavaFX application thread, preventing it to start doing the rendering. Those things are typically easily detected by generating thread dumps or using simple profilers to find out what the JavaFX thread is typically doing. If you see bad performance but in 90% of the thread dump there is no trace of rendering, you know where to look. When things are slow in the paint phase, the information about how many Nodes are visited and rendered, and how many are cached is very useful. I have a local debug version where I keep track of how many times a Node is rendered from cache versus how often the cache is invalid and needs to be recomputed (which is extremely expensive). It this was somehow automated, it could improve performance. It is similar to what hotspot C1/C2 is doing for code: it is expensive to compile all code at runtime, but when it turns out methods are often used, they are compiled. Similar, if the rendering pipeline detects that a node would remain cache-valid for most of the time, it might automatically set that node.setCache(true). But that's not a trivial thing to implement. The options in PrismSettings.java (e.g. prism.trace, prism.printrendergraph, prism.showdirty) and in QuantumToolit (quantum.debug) can be helpful as well. When there are no clear indications (e.g. not too many nodes, no invalid caches), I go for profiling, working bottom-up. I have the JavaFX source code always at hand when doing this, in order to see what exactly is happening. There are some patterns, e.g. on Android I know that lots of time spent in System.arraycopy is an indication about lots of slow CSS processing (Bitset operations, if you follow the profiling information bottom-up) It would be great to have tools that auto-detect this. Detecting slow render phases is already done, but linking to the root cause is of course much harder. I don't think that interrupting the paint phase is a good thing. If that takes 200-300 ms, it is very likely it will take 200-300ms in the next cycle. It might be an option though to dynamically throttle the pulse frequency (which can now only be changed at startup with javafx.animation.pulse) in case slow rendering is detected. - Johan On Tue, May 1, 2018 at 8:17 PM Matthew Elliot < matthew.james.elliot at gmail.com> wrote: > Hi all, > > The last few days I was troubleshooting a new performance issue that showed > up in our PROD application where customers had fallen back to the SW > rendering pipeline. It severely affected the application where CPU > frequency was under 3 GHz with hover lags of a few seconds in the worst > cases. With thousands of potential HW/SW combinations in the wild it took > quite a while to even identify it really was an issue in our application > and not the usual noise of some silly set up. All this got me thinking... > > ... what was visible was long paint passes, and long waiting on previous > render but narrowing this down to exactly what was going on took a lot of > manual inspection of the rendering pipeline code / debugging and somewhat > by chance I stumbled over the -Dprism.disableEffects flag which after much > more pain helped me narrow down the issue. > > The root cause turned out to be an -fx-effect (blend, inner shadow) on an > animated node that was set from the code by an unknowing developer. > > While there are tools like mission controller for visualising the pulse and > phases it can be difficult to identify for example what is going wrong > inside of the painting phase and it is difficult to control that nothing > bad happens when many developers can make changes to the code and reviews > will never catch everything... I'm therefore thinking about ways to run > rendering tests in continuous integration that would fail fast if the SW > rendering pipeline would get overloaded. > I had a look at PulseListener where I could see pulse times but I'd like to > go more detailed and actually like the information tracked in the internals > of PulseLogger (PulseData) without doing any nasty tricks. > > I thought maybe somebody has already thought about this problem before and > maybe there is even some tooling around this beyond the logging? I could > even imagine using the same technique to monitor the rendering pipeline in > real time and alerting us (maybe even the user) if things are going a bit > sideways. > > Maybe more generically, how do you even start to debug delays in the paint > phase? Timed breakpoints and IDE assisted debug logging aside. :) > > Matt. > > PS: It might even be nice to tell the Painter to give up after N ms (prism > setting?). Sometimes better to break than to not be useable because of > paint phases taking 200-300 ms and JavaFX Application Thread thread getting > almost starved completely. > From matthew.james.elliot at gmail.com Tue May 1 20:55:46 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Tue, 1 May 2018 22:55:46 +0200 Subject: Paint Phase Debugging / Performance In-Reply-To: References: Message-ID: Hey Johan, thanks for the detailed answer. Perhaps a bit more context as well... from our experience it seems about 10-12% of the setups we hit fall back to Software because of various issues or predominantly or 'sadly' virtualisation like Citrix so we have to be sure in SW mode things run optimally. It isn't necessarily a bad thing to optimise for the lowest common denominator if you want a fast application everywhere. Given this learning I'm now looking to how ensure we somehow 'box' what a minimum performance looks like and ensure with every change we don't really get away from that + communicate costs clearly with the UX team. That way when our developers step on land mines we detect the missing limbs the same day. That's the direction I'm currently thinking about and of course I can't be the only one (hence the post). I don't like it when people say that "JavaFX is slow" because if everything is done right, JavaFX can be extremely fast. But I also realise that it is very easy to make things very slow in JavaFX, and in case "performance" is slow, it is important to pinpoint the problem as easy as possible. And that is often not trivial, so the easier it becomes to detect problems, the more developers will like JavaFX. >>> Agree that JavaFX can be fast and given we have to support thousands of setups that we have no control over I'm quite content with how JavaFX is performing in the wild. It definitely has a few performance traps that aren't so easy notice from the high level API, css, effects, etc. And while blocking the JavaFX thread happens the most frequent it also is simple to explain to any reasonable developer and easy to troubleshoot as it is something you influence directly, whereas css pass, layout or paint are much more indirect and tricky. An effect on top on an animation for example was very tricky to find. In this case the framework should even perhaps refuse to do it in software mode... :) To a few other points: The options in PrismSettings.java (e.g. prism.trace, prism.printrendergraph, prism.showdirty) and in QuantumToolit (quantum.debug) can be helpful as well. >>> Are you aware of any write up on the internet about understanding the output? I mean I had to read the code and use breakpoints for the prism logger for 'slow background path for null' to understand but it would be nice if someone has already written about these topics? There is also no book on JavaFX perf right? On the other side and regarding analysing issues I think there is also a wealth of tooling / logging that is useful but it took me a while to work my way into the performance investigation as the information is scattered and or incomplete (at least with my googlefu). It would be great to have tools that auto-detect this. Detecting slow render phases is already done, but linking to the root cause is of course much harder. I don't think that interrupting the paint phase is a good thing. If that takes 200-300 ms, it is very likely it will take 200-300ms in the next cycle. >>> Auto-detection is a hard science, hence why as a developer I wouldn't mind setting explicitly for my CI perf builds, break if condition A happens so I can review what changed recently. >>> At 200-300 ms the application became unusable essentially in our case as every scheduled pulse was either waiting or painting. I will create something to also detect this going forward to avoid a repeat (question just is what). >>> Of course now I will redirect stdErr and parse it on the fly and/or go in via reflection but it would be nice if prism would allow to set short cuts or at least spit additional ERROR or WARNs. It might be an option though to dynamically throttle the pulse frequency (which can now only be changed at startup with javafx.animation.pulse) in case slow rendering is detected. >>> Does this matter much as the pulses anyway just get skipped, or? In this case the fact that the animation is still trying to run when the pulse is almost stalled doesn't make sense and circuit-breaking it would be perhaps 'intelligent' framework behaviour. When things are slow in the paint phase, the information about how many Nodes are visited and rendered, and how many are cached is very useful. I have a local debug version where I keep track of how many times a Node is rendered from cache versus how often the cache is invalid and needs to be recomputed (which is extremely expensive). It this was somehow automated, it could improve performance. It is similar to what hotspot C1/C2 is doing for code: it is expensive to compile all code at runtime, but when it turns out methods are often used, they are compiled. Similar, if the rendering pipeline detects that a node would remain cache-valid for most of the time, it might automatically set that node.setCache(true). But that's not a trivial thing to implement. >>> I still can't 100% work out what exactly one should cache from what I've googled. I mean, I only need to cache it if it will be redrawn right, but generally I'm not redrawing it unless I change it. This seems a bit counterintuitive? (okay maybe a window move or something but that is seldom) >>> Hotspot is also great fun! ;) especially if you ever completely fill up the code cache - which I don't recommend! On that side are Gluon at documenting (maybe on an internal wiki) or somewhere publicly the strange cases that you hit? I guess you've seen most of them by now! My favourite recently was a * { } css selected that sent our memory throughput crazy as CSSPseudoState was allocated / collected at insane rates! Thanks, Matt On 1 May 2018 at 20:48, Johan Vos wrote: > Hi Matthew, > > I agree this is a very important question. > > I don't like it when people say that "JavaFX is slow" because if > everything is done right, JavaFX can be extremely fast. > But I also realise that it is very easy to make things very slow in > JavaFX, and in case "performance" is slow, it is important to pinpoint the > problem as easy as possible. And that is often not trivial, so the easier > it becomes to detect problems, the more developers will like JavaFX. > > I typically start with setting prism.verbose and javafx.pulseLogger to > true, as you first need to know in which phase the problem is (e.g. layout > or render phase). If you see the problem is in the render phase, you have > to look at completely different things. > Note that in most cases I've seen with bad performance, the problem was > not in the rendering, but simply due to too much happening on the JavaFX > application thread, preventing it to start doing the rendering. > Those things are typically easily detected by generating thread dumps or > using simple profilers to find out what the JavaFX thread is typically > doing. If you see bad performance but in 90% of the thread dump there is no > trace of rendering, you know where to look. > > When things are slow in the paint phase, the information about how many > Nodes are visited and rendered, and how many are cached is very useful. I > have a local debug version where I keep track of how many times a Node is > rendered from cache versus how often the cache is invalid and needs to be > recomputed (which is extremely expensive). It this was somehow automated, > it could improve performance. It is similar to what hotspot C1/C2 is doing > for code: it is expensive to compile all code at runtime, but when it turns > out methods are often used, they are compiled. Similar, if the rendering > pipeline detects that a node would remain cache-valid for most of the time, > it might automatically set that node.setCache(true). But that's not a > trivial thing to implement. > > The options in PrismSettings.java (e.g. prism.trace, > prism.printrendergraph, prism.showdirty) and in QuantumToolit > (quantum.debug) can be helpful as well. > > When there are no clear indications (e.g. not too many nodes, no invalid > caches), I go for profiling, working bottom-up. I have the JavaFX source > code always at hand when doing this, in order to see what exactly is > happening. > There are some patterns, e.g. on Android I know that lots of time spent in > System.arraycopy is an indication about lots of slow CSS processing (Bitset > operations, if you follow the profiling information bottom-up) > > It would be great to have tools that auto-detect this. Detecting slow > render phases is already done, but linking to the root cause is of course > much harder. > > I don't think that interrupting the paint phase is a good thing. If that > takes 200-300 ms, it is very likely it will take 200-300ms in the next > cycle. > > It might be an option though to dynamically throttle the pulse frequency > (which can now only be changed at startup with javafx.animation.pulse) in > case slow rendering is detected. > > - Johan > > > On Tue, May 1, 2018 at 8:17 PM Matthew Elliot com> wrote: > >> Hi all, >> >> The last few days I was troubleshooting a new performance issue that >> showed >> up in our PROD application where customers had fallen back to the SW >> rendering pipeline. It severely affected the application where CPU >> frequency was under 3 GHz with hover lags of a few seconds in the worst >> cases. With thousands of potential HW/SW combinations in the wild it took >> quite a while to even identify it really was an issue in our application >> and not the usual noise of some silly set up. All this got me thinking... >> >> ... what was visible was long paint passes, and long waiting on previous >> render but narrowing this down to exactly what was going on took a lot of >> manual inspection of the rendering pipeline code / debugging and somewhat >> by chance I stumbled over the -Dprism.disableEffects flag which after much >> more pain helped me narrow down the issue. >> >> The root cause turned out to be an -fx-effect (blend, inner shadow) on an >> animated node that was set from the code by an unknowing developer. >> >> While there are tools like mission controller for visualising the pulse >> and >> phases it can be difficult to identify for example what is going wrong >> inside of the painting phase and it is difficult to control that nothing >> bad happens when many developers can make changes to the code and reviews >> will never catch everything... I'm therefore thinking about ways to run >> rendering tests in continuous integration that would fail fast if the SW >> rendering pipeline would get overloaded. >> I had a look at PulseListener where I could see pulse times but I'd like >> to >> go more detailed and actually like the information tracked in the >> internals >> of PulseLogger (PulseData) without doing any nasty tricks. >> >> I thought maybe somebody has already thought about this problem before and >> maybe there is even some tooling around this beyond the logging? I could >> even imagine using the same technique to monitor the rendering pipeline in >> real time and alerting us (maybe even the user) if things are going a bit >> sideways. >> >> Maybe more generically, how do you even start to debug delays in the paint >> phase? Timed breakpoints and IDE assisted debug logging aside. :) >> >> Matt. >> >> PS: It might even be nice to tell the Painter to give up after N ms (prism >> setting?). Sometimes better to break than to not be useable because of >> paint phases taking 200-300 ms and JavaFX Application Thread thread >> getting >> almost starved completely. >> > From sverre.moe at gmail.com Wed May 2 08:04:59 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 2 May 2018 10:04:59 +0200 Subject: Bug in SceneBuilder 9 Message-ID: I think I have found a bug in SceneBuilder 9. I cannot find an existing bug report for this: https://www.oracle.com/search/results/_/N-8d?Ntt=SceneBuilder%20TitledPane&Dy=1&Nty=1&cat=bugs&Nr=106&Ntk=S3 When adding a TitledPane, its default styling is not applied. Within SceneBuilder the TitledPane lacks the border and title styles(background, collapsible arrow). An empty TitledPane shows only the title and nothing more. It looks just like a Label or Text. Running the FXML with an Java 9 application shows the TitledPane as it should be. Where should I submit this bug report? bugreport.java.com, GitHub mirror or with Gluon? /Sverre From johan.vos at gluonhq.com Wed May 2 08:22:31 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 02 May 2018 08:22:31 +0000 Subject: Bug in SceneBuilder 9 In-Reply-To: References: Message-ID: Hi Sverre, I think the best place to submit this issue is here: https://bitbucket.org/gluon-oss/scenebuilder/issues?status=new&status=open - Johan On Wed, May 2, 2018 at 10:15 AM Sverre Moe wrote: > I think I have found a bug in SceneBuilder 9. > > I cannot find an existing bug report for this: > > https://www.oracle.com/search/results/_/N-8d?Ntt=SceneBuilder%20TitledPane&Dy=1&Nty=1&cat=bugs&Nr=106&Ntk=S3 > > When adding a TitledPane, its default styling is not applied. > Within SceneBuilder the TitledPane lacks the border and title > styles(background, collapsible arrow). An empty TitledPane shows only > the title and nothing more. It looks just like a Label or Text. > Running the FXML with an Java 9 application shows the TitledPane as it > should be. > > Where should I submit this bug report? > bugreport.java.com, GitHub mirror or with Gluon? > > /Sverre > From johan.vos at gluonhq.com Wed May 2 12:05:51 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 02 May 2018 12:05:51 +0000 Subject: native libs in modules In-Reply-To: References: <6ee8a8f8-0f15-8c05-ab9a-9f53625123c5@oracle.com> <6b90031c-3738-cda5-5195-a6e85d1f479f@jugs.org> Message-ID: FYI, the native-libs-in-mods issue is being discussed on the panama-dev list as well: http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001543.html - Johan On Tue, May 1, 2018 at 6:01 PM Kevin Rushforth wrote: > > > On 4/30/2018 8:58 AM, Michael Paus wrote: > > Am 30.04.18 um 17:29 schrieb Kevin Rushforth: > >> One thing to note is that unlike the JDK build, all class files for > >> Windows, Linux, and Mac are set up to be built (but not shipped) on > >> all three platforms, so it might be possible to create a jar file > >> that would be the same on all three platforms. I don't know how > >> feasible it would be or whether that the right direction to take or not. > > If possible, I would like to see a change in this policy to not ship > > certain fragments of the build. Especially I would like to have the > > possibility to use a JavaFX based on OpenGL on Windows too. This would > > make Java truly cross-platform and might offer a lot of possibilities > > for better integration of external graphics tools like for example > > tools based on JOGL. It might also offer the possibility to support > > WebGL in the WebView in the future so that this gap can be closed too. > > Am I just dreaming? What do others think? > > This is somewhat tangential to the issue of how to ship the native > libraries and platform-specific classes for each platform. While it is > true that the prism_es2 classes and native libraries are compiled on > Windows platforms, they aren't part of the build artifacts, and aren't > ever run or tested at all. So it wouldn't be as simple as shipping > something that is currently not shipped. Doing so would require a bit of > work, not to mention a bug tail since OpenGL drivers for Windows tend to > be buggy (especially for Intel HD). As for WebGL, it would probably make > more sense to use ANGLE to translate to D3D on Windows than try to rely > on OpenGL being available everywhere. > > -- Kevin > > > Michael > > From murali.billa at oracle.com Wed May 2 20:21:56 2018 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 2 May 2018 13:21:56 -0700 (PDT) Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger In-Reply-To: References: Message-ID: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> Hi Nir, ? 1)????? Regarding ?verbose? flag usage:? ????????? Currently verbose flag is used to show log Levels (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl. ?I feel it is not desirable to remove this flag as all these logs will start appearing now by default. ????????? We can try 2 options: a)?????? 1st Option: We can change all INFO log messages to FINE ?under verbose flag (by leaving all log messages that use Level other than INFO unchanged) and verbose flag can be removed. b)????? If 1st option results in too much noise for WARNING log messages, then we can keep the verbose flag and introduce a System Property (for ex: javafx.web.verbose) to enable the flag. I won?t suggest reading level value from log/config file. ? 2)????? Regarding ??com.sun.javafx.webkit.drt.DumpRenderTree?,? I need to check few more things (since we use ?addHandler? in drt) and will get back to you. ? Please let me know, if you have any queries for 1. Thanks, Murali From: Nir Lisker Sent: Saturday, April 28, 2018 1:06 AM To: Murali Billa Cc: openjfx-dev at openjdk.java.net Mailing Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger ? Hi Murali, ? Can you have a look at?https://bugs.openjdk.java.net/browse/JDK-8195974 please? ? There are some usages of j.u.l in the web module I'd like your opinion on. I'm not familiar with the intent of these pieces of code and would like to know what the options are for advancing with this issue on that front. ? Thanks, Nir From nlisker at gmail.com Wed May 2 23:52:54 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 3 May 2018 02:52:54 +0300 Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger In-Reply-To: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> References: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> Message-ID: Thanks Murali, I won?t suggest reading level value from log/config file. Is that file user facing? If so, wouldn't ignoring the level set in the file break current behavior? Would there need to be follow-up changes to this file to remove the level setting from it? About option (a), wouldn't removing the verbose flag (After changing INFO to FINE) cause all the log messages to appear by default, as you've stated in the first point, and we want to avoid that? We don't have a minimum log level setting. -Nir On Wed, May 2, 2018 at 11:21 PM, Murali Billa wrote: > Hi Nir, > > > > 1) Regarding ?verbose? flag usage: > > ? Currently verbose flag is used to show log Levels > (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl. I feel > it is not desirable to remove this flag as all these logs will start > appearing now by default. > > ? We can try 2 options: > > a) 1st Option: We can change all INFO log messages to FINE under > verbose flag (by leaving all log messages that use Level other than INFO > unchanged) and verbose flag can be removed. > > b) If 1st option results in too much noise for WARNING log messages, > then we can keep the verbose flag and introduce a System Property (for ex: > javafx.web.verbose) to enable the flag. I won?t suggest reading level value > from log/config file. > > > > 2) Regarding ?com.sun.javafx.webkit.drt.DumpRenderTree?, I need to > check few more things (since we use ?addHandler? in drt) and will get back > to you. > > > > Please let me know, if you have any queries for 1. > > Thanks, > > Murali > > *From:* Nir Lisker > *Sent:* Saturday, April 28, 2018 1:06 AM > *To:* Murali Billa > *Cc:* openjfx-dev at openjdk.java.net Mailing > *Subject:* JDK-8195974: Replace use of java.util.logging in javafx with > System logger > > > > Hi Murali, > > > > Can you have a look at https://bugs.openjdk.java.net/browse/JDK-8195974 > please? > > > > There are some usages of j.u.l in the web module I'd like your opinion on. > I'm not familiar with the intent of these pieces of code and would like to > know what the options are for advancing with this issue on that front. > > > > Thanks, > > Nir > From kevin.rushforth at oracle.com Thu May 3 00:31:44 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 2 May 2018 17:31:44 -0700 Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger In-Reply-To: References: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> Message-ID: inline On 5/2/2018 4:52 PM, Nir Lisker wrote: > Thanks Murali, > > I won?t suggest reading level value from log/config file. > > > Is that file user facing? If so, wouldn't ignoring the level set in the > file break current behavior? Would there need to be follow-up changes to > this file to remove the level setting from it? Not sure what you mean by "that file". The WCMediaPlayer file? No, it isn't user-facing. Or did you mean something else? > About option (a), wouldn't removing the verbose flag (After changing INFO > to FINE) cause all the log messages to appear by default, as you've stated > in the first point, and we want to avoid that? We don't have a minimum log > level setting. By default the log level for all loggers is set at INFO -- thus the suggestion to change all of the INFO messages to FINE, which will not be logged by default. If we still end up with a bunch of extra WARNING or SEVERE log messages from from ordinary situations, then that would be a problem. Given that the implementation of WCMediaPlayer produces "noisier than typical" INFO log messages, it wouldn't surprise me that some of the WARNING log messages are things that the user shouldn't necessarily be warned about. In any case, the second suggestion of keeping the verbose flag but putting it on a System property might be less intrusive. And like the current solution, puts the control in the hands of the user. -- Kevin > -Nir > > > On Wed, May 2, 2018 at 11:21 PM, Murali Billa > wrote: > >> Hi Nir, >> >> >> >> 1) Regarding ?verbose? flag usage: >> >> ? Currently verbose flag is used to show log Levels >> (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl. I feel >> it is not desirable to remove this flag as all these logs will start >> appearing now by default. >> >> ? We can try 2 options: >> >> a) 1st Option: We can change all INFO log messages to FINE under >> verbose flag (by leaving all log messages that use Level other than INFO >> unchanged) and verbose flag can be removed. >> >> b) If 1st option results in too much noise for WARNING log messages, >> then we can keep the verbose flag and introduce a System Property (for ex: >> javafx.web.verbose) to enable the flag. I won?t suggest reading level value >> from log/config file. >> >> >> >> 2) Regarding ?com.sun.javafx.webkit.drt.DumpRenderTree?, I need to >> check few more things (since we use ?addHandler? in drt) and will get back >> to you. >> >> >> >> Please let me know, if you have any queries for 1. >> >> Thanks, >> >> Murali >> >> *From:* Nir Lisker >> *Sent:* Saturday, April 28, 2018 1:06 AM >> *To:* Murali Billa >> *Cc:* openjfx-dev at openjdk.java.net Mailing >> *Subject:* JDK-8195974: Replace use of java.util.logging in javafx with >> System logger >> >> >> >> Hi Murali, >> >> >> >> Can you have a look at https://bugs.openjdk.java.net/browse/JDK-8195974 >> please? >> >> >> >> There are some usages of j.u.l in the web module I'd like your opinion on. >> I'm not familiar with the intent of these pieces of code and would like to >> know what the options are for advancing with this issue on that front. >> >> >> >> Thanks, >> >> Nir >> From nlisker at gmail.com Thu May 3 01:25:09 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 3 May 2018 04:25:09 +0300 Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger In-Reply-To: References: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> Message-ID: > > Not sure what you mean by "that file". Sorry, I meant the log/config file. keeping the verbose flag but putting it on a System property Then why not get a minimum level from a system property instead of a general on/off flag? Also, why is webkit.mediaplayer special in its usage of the logger (that it requires its own property)? - Nir On Thu, May 3, 2018 at 3:31 AM, Kevin Rushforth wrote: > inline > > > On 5/2/2018 4:52 PM, Nir Lisker wrote: > >> Thanks Murali, >> >> I won?t suggest reading level value from log/config file. >> >> >> Is that file user facing? If so, wouldn't ignoring the level set in the >> file break current behavior? Would there need to be follow-up changes to >> this file to remove the level setting from it? >> > > Not sure what you mean by "that file". The WCMediaPlayer file? No, it > isn't user-facing. Or did you mean something else? > > About option (a), wouldn't removing the verbose flag (After changing INFO >> to FINE) cause all the log messages to appear by default, as you've stated >> in the first point, and we want to avoid that? We don't have a minimum log >> level setting. >> > > By default the log level for all loggers is set at INFO -- thus the > suggestion to change all of the INFO messages to FINE, which will not be > logged by default. If we still end up with a bunch of extra WARNING or > SEVERE log messages from from ordinary situations, then that would be a > problem. Given that the implementation of WCMediaPlayer produces "noisier > than typical" INFO log messages, it wouldn't surprise me that some of the > WARNING log messages are things that the user shouldn't necessarily be > warned about. > > In any case, the second suggestion of keeping the verbose flag but putting > it on a System property might be less intrusive. And like the current > solution, puts the control in the hands of the user. > > -- Kevin > > > -Nir >> >> >> On Wed, May 2, 2018 at 11:21 PM, Murali Billa >> wrote: >> >> Hi Nir, >>> >>> >>> >>> 1) Regarding ?verbose? flag usage: >>> >>> ? Currently verbose flag is used to show log Levels >>> (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl. I feel >>> it is not desirable to remove this flag as all these logs will start >>> appearing now by default. >>> >>> ? We can try 2 options: >>> >>> a) 1st Option: We can change all INFO log messages to FINE under >>> verbose flag (by leaving all log messages that use Level other than INFO >>> unchanged) and verbose flag can be removed. >>> >>> b) If 1st option results in too much noise for WARNING log messages, >>> then we can keep the verbose flag and introduce a System Property (for >>> ex: >>> javafx.web.verbose) to enable the flag. I won?t suggest reading level >>> value >>> from log/config file. >>> >>> >>> >>> 2) Regarding ?com.sun.javafx.webkit.drt.DumpRenderTree?, I need >>> to >>> check few more things (since we use ?addHandler? in drt) and will get >>> back >>> to you. >>> >>> >>> >>> Please let me know, if you have any queries for 1. >>> >>> Thanks, >>> >>> Murali >>> >>> *From:* Nir Lisker >>> *Sent:* Saturday, April 28, 2018 1:06 AM >>> *To:* Murali Billa >>> *Cc:* openjfx-dev at openjdk.java.net Mailing >> > >>> *Subject:* JDK-8195974: Replace use of java.util.logging in javafx with >>> System logger >>> >>> >>> >>> Hi Murali, >>> >>> >>> >>> Can you have a look at https://bugs.openjdk.java.net/browse/JDK-8195974 >>> please? >>> >>> >>> >>> There are some usages of j.u.l in the web module I'd like your opinion >>> on. >>> I'm not familiar with the intent of these pieces of code and would like >>> to >>> know what the options are for advancing with this issue on that front. >>> >>> >>> >>> Thanks, >>> >>> Nir >>> >>> > From kevin.rushforth at oracle.com Thu May 3 11:42:18 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 3 May 2018 04:42:18 -0700 Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger In-Reply-To: References: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> Message-ID: On 5/2/2018 6:25 PM, Nir Lisker wrote: > > Not sure what you mean by "that file". > > > Sorry, I meant the log/config file. I see. This isn't something that a library like JavaFX should read. > keeping the verbose flag but putting it on a System property > > > Then why not get a minimum level from a system property instead of a > general on/off flag? Because that would be duplicating functionality that should be handled by the logger configuration itself (we can't set the logging level when using the PlatformLogger wrapper utility to System.Logger). > Also, why is webkit.mediaplayer special in its usage of the logger > (that it requires its own property)? That's the real question: are the needs of the WebView media component so special that it justifies its own mechanism / property. I doubt it, which is why removing the verbose flag altogether seems the better choice as long as it isn't too intrusive / noisy. -- Kevin > - Nir > > On Thu, May 3, 2018 at 3:31 AM, Kevin Rushforth > > wrote: > > inline > > > On 5/2/2018 4:52 PM, Nir Lisker wrote: > > Thanks Murali, > > I won?t suggest reading level value from log/config file. > > > Is that file user facing? If so, wouldn't ignoring the level > set in the > file break current behavior? Would there need to be follow-up > changes to > this file to remove the level setting from it? > > > Not sure what you mean by "that file". The WCMediaPlayer file? No, > it isn't user-facing. Or did you mean something else? > > About option (a), wouldn't removing the verbose flag (After > changing INFO > to FINE) cause all the log messages to appear by default, as > you've stated > in the first point, and we want to avoid that? We don't have a > minimum log > level setting. > > > By default the log level for all loggers is set at INFO -- thus > the suggestion to change all of the INFO messages to FINE, which > will not be logged by default. If we still end up with a bunch of > extra WARNING or SEVERE log messages from from ordinary > situations, then that would be a problem. Given that the > implementation of WCMediaPlayer produces "noisier than typical" > INFO log messages, it wouldn't surprise me that some of the > WARNING log messages are things that the user shouldn't > necessarily be warned about. > > In any case, the second suggestion of keeping the verbose flag but > putting it on a System property might be less intrusive. And like > the current solution, puts the control in the hands of the user. > > -- Kevin > > > -Nir > > > On Wed, May 2, 2018 at 11:21 PM, Murali Billa > > > wrote: > > Hi Nir, > > > > 1)? ? ? Regarding ?verbose? flag usage: > > ?? ? ? ? ?Currently verbose flag is used to show log Levels > (FINER/FINE/INFO/WARNING) in WCMediaPlayer & > WCMediaPlayerImpl.? I feel > it is not desirable to remove this flag as all these logs > will start > appearing now by default. > > ?? ? ? ? ?We can try 2 options: > > a)? ? ? ?1st Option: We can change all INFO log messages > to FINE? under > verbose flag (by leaving all log messages that use Level > other than INFO > unchanged) and verbose flag can be removed. > > b)? ? ? If 1st option results in too much noise for > WARNING log messages, > then we can keep the verbose flag and introduce a System > Property (for ex: > javafx.web.verbose) to enable the flag. I won?t suggest > reading level value > from log/config file. > > > > 2)? ? ? Regarding? > ?com.sun.javafx.webkit.drt.DumpRenderTree?, I need to > check few more things (since we use ?addHandler? in drt) > and will get back > to you. > > > > Please let me know, if you have any queries for 1. > > Thanks, > > Murali > > *From:* Nir Lisker > > *Sent:* Saturday, April 28, 2018 1:06 AM > *To:* Murali Billa > > *Cc:* openjfx-dev at openjdk.java.net > Mailing > > > *Subject:* JDK-8195974: Replace use of java.util.logging > in javafx with > System logger > > > > Hi Murali, > > > > Can you have a look at > https://bugs.openjdk.java.net/browse/JDK-8195974 > > please? > > > > There are some usages of j.u.l in the web module I'd like > your opinion on. > I'm not familiar with the intent of these pieces of code > and would like to > know what the options are for advancing with this issue on > that front. > > > > Thanks, > > Nir > > > From ajit.ghaisas at oracle.com Thu May 3 11:46:42 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 3 May 2018 04:46:42 -0700 (PDT) Subject: [11] Review request : JDK-8196827 : test.javafx.scene.control.ComboBoxTest - generates NullPointerException Message-ID: <2b47f24e-5749-4bc7-85d1-cc9652d06b04@default> Hi, Please review below fix. Bug : https://bugs.openjdk.java.net/browse/JDK-8196827 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8196827/webrev.0/ Regards, Ajit From tom.schindl at bestsolution.at Thu May 3 11:54:51 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 3 May 2018 13:54:51 +0200 Subject: OpenJFX 11 in OSGi Message-ID: <2ddccab0-0d42-fe94-7a23-1b78f1a6cd9b@bestsolution.at> Hi, Following up on the native-libs-in-modules I wonder how we deal with OSGi-Applications like Eclipse RCP. Do OpenJFX-Binaries run only on the module-path or can they run on the classpath as well. If they can run on the classpath, can they maybe loaded as OSGi-Bundles (if they contain the necessary OSGi-Meta-Data). Tom From kevin.rushforth at oracle.com Thu May 3 12:05:16 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 3 May 2018 05:05:16 -0700 Subject: OpenJFX 11 in OSGi In-Reply-To: <2ddccab0-0d42-fe94-7a23-1b78f1a6cd9b@bestsolution.at> References: <2ddccab0-0d42-fe94-7a23-1b78f1a6cd9b@bestsolution.at> Message-ID: <4f7584b3-5a00-437c-3e52-3c3ca7a8eb52@oracle.com> On 5/3/2018 4:54 AM, Tom Schindl wrote: > Hi, > > Following up on the native-libs-in-modules I wonder how we deal with > OSGi-Applications like Eclipse RCP. > > Do OpenJFX-Binaries run only on the module-path or can they run on the > classpath as well. If they can run on the classpath, can they maybe > loaded as OSGi-Bundles (if they contain the necessary OSGi-Meta-Data). Only on the module path. I think it would be a step backwards to rework them so they could also run on the classpath. -- Kevin > > Tom From tom.schindl at bestsolution.at Thu May 3 12:39:55 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 3 May 2018 14:39:55 +0200 Subject: OpenJFX 11 in OSGi In-Reply-To: <4f7584b3-5a00-437c-3e52-3c3ca7a8eb52@oracle.com> References: <2ddccab0-0d42-fe94-7a23-1b78f1a6cd9b@bestsolution.at> <4f7584b3-5a00-437c-3e52-3c3ca7a8eb52@oracle.com> Message-ID: <7929fcef-7d97-6874-a098-fdbba79a59d0@bestsolution.at> Hi, On 03.05.18 14:05, Kevin Rushforth wrote: > > > On 5/3/2018 4:54 AM, Tom Schindl wrote: >> Hi, >> >> Following up on the native-libs-in-modules I wonder how we deal with >> OSGi-Applications like Eclipse RCP. >> >> Do OpenJFX-Binaries run only on the module-path or can they run on the >> classpath as well. If they can run on the classpath, can they maybe >> loaded as OSGi-Bundles (if they contain the necessary OSGi-Meta-Data). > > Only on the module path. I think it would be a step backwards to rework > them so they could also run on the classpath. > Ok - that's what I somehow feared would be the case. I filed https://github.com/eclipse/efxclipse-rt/issues/217 but anyone who needs OpenFX running in OSGi is requested to chime in and maybe provide help to get this sorted out. Tom From nlisker at gmail.com Thu May 3 14:07:57 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 3 May 2018 17:07:57 +0300 Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger In-Reply-To: References: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> Message-ID: > > Also, why is webkit.mediaplayer special in its usage of the logger (that >> it requires its own property)? > > > That's the real question: are the needs of the WebView media component so > special that it justifies its own mechanism / property. I doubt it, which > is why removing the verbose flag altogether seems the better choice as long > as it isn't too intrusive / noisy. > Is the intrusiveness something that needs to be and can be tested? Can we remove the flag and if needed later reinstate it via a system property? it wouldn't surprise me that some of the WARNING log messages are things > that the user shouldn't necessarily be warned about. > >From my point of view, if the warning messages are of no interest to the user, maybe they shouldn't be warning level. - Nir On Thu, May 3, 2018 at 2:42 PM, Kevin Rushforth wrote: > > > On 5/2/2018 6:25 PM, Nir Lisker wrote: > > Not sure what you mean by "that file". > > > Sorry, I meant the log/config file. > > > I see. This isn't something that a library like JavaFX should read. > > keeping the verbose flag but putting it on a System property > > > Then why not get a minimum level from a system property instead of a > general on/off flag? > > > Because that would be duplicating functionality that should be handled by > the logger configuration itself (we can't set the logging level when using > the PlatformLogger wrapper utility to System.Logger). > > Also, why is webkit.mediaplayer special in its usage of the logger (that > it requires its own property)? > > > That's the real question: are the needs of the WebView media component so > special that it justifies its own mechanism / property. I doubt it, which > is why removing the verbose flag altogether seems the better choice as long > as it isn't too intrusive / noisy. > > -- Kevin > > > > - Nir > > On Thu, May 3, 2018 at 3:31 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> inline >> >> >> On 5/2/2018 4:52 PM, Nir Lisker wrote: >> >>> Thanks Murali, >>> >>> I won?t suggest reading level value from log/config file. >>> >>> >>> Is that file user facing? If so, wouldn't ignoring the level set in the >>> file break current behavior? Would there need to be follow-up changes to >>> this file to remove the level setting from it? >>> >> >> Not sure what you mean by "that file". The WCMediaPlayer file? No, it >> isn't user-facing. Or did you mean something else? >> >> About option (a), wouldn't removing the verbose flag (After changing INFO >>> to FINE) cause all the log messages to appear by default, as you've >>> stated >>> in the first point, and we want to avoid that? We don't have a minimum >>> log >>> level setting. >>> >> >> By default the log level for all loggers is set at INFO -- thus the >> suggestion to change all of the INFO messages to FINE, which will not be >> logged by default. If we still end up with a bunch of extra WARNING or >> SEVERE log messages from from ordinary situations, then that would be a >> problem. Given that the implementation of WCMediaPlayer produces "noisier >> than typical" INFO log messages, it wouldn't surprise me that some of the >> WARNING log messages are things that the user shouldn't necessarily be >> warned about. >> >> In any case, the second suggestion of keeping the verbose flag but >> putting it on a System property might be less intrusive. And like the >> current solution, puts the control in the hands of the user. >> >> -- Kevin >> >> >> -Nir >>> >>> >>> On Wed, May 2, 2018 at 11:21 PM, Murali Billa >>> wrote: >>> >>> Hi Nir, >>>> >>>> >>>> >>>> 1) Regarding ?verbose? flag usage: >>>> >>>> ? Currently verbose flag is used to show log Levels >>>> (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl. I feel >>>> it is not desirable to remove this flag as all these logs will start >>>> appearing now by default. >>>> >>>> ? We can try 2 options: >>>> >>>> a) 1st Option: We can change all INFO log messages to FINE under >>>> verbose flag (by leaving all log messages that use Level other than INFO >>>> unchanged) and verbose flag can be removed. >>>> >>>> b) If 1st option results in too much noise for WARNING log >>>> messages, >>>> then we can keep the verbose flag and introduce a System Property (for >>>> ex: >>>> javafx.web.verbose) to enable the flag. I won?t suggest reading level >>>> value >>>> from log/config file. >>>> >>>> >>>> >>>> 2) Regarding ?com.sun.javafx.webkit.drt.DumpRenderTree?, I need >>>> to >>>> check few more things (since we use ?addHandler? in drt) and will get >>>> back >>>> to you. >>>> >>>> >>>> >>>> Please let me know, if you have any queries for 1. >>>> >>>> Thanks, >>>> >>>> Murali >>>> >>>> *From:* Nir Lisker >>>> *Sent:* Saturday, April 28, 2018 1:06 AM >>>> *To:* Murali Billa >>>> *Cc:* openjfx-dev at openjdk.java.net Mailing < >>>> openjfx-dev at openjdk.java.net> >>>> *Subject:* JDK-8195974: Replace use of java.util.logging in javafx with >>>> System logger >>>> >>>> >>>> >>>> Hi Murali, >>>> >>>> >>>> >>>> Can you have a look at https://bugs.openjdk.java.net/browse/JDK-8195974 >>>> please? >>>> >>>> >>>> >>>> There are some usages of j.u.l in the web module I'd like your opinion >>>> on. >>>> I'm not familiar with the intent of these pieces of code and would like >>>> to >>>> know what the options are for advancing with this issue on that front. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Nir >>>> >>>> >> > > From kevin.rushforth at oracle.com Thu May 3 14:20:14 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 3 May 2018 07:20:14 -0700 Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger In-Reply-To: References: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> Message-ID: >> Also, why is webkit.mediaplayer special in its usage of the >> logger (that it requires its own property)? >> > > That's the real question: are the needs of the WebView media component > so special that it justifies its own mechanism / property. I doubt it, > which is why removing the verbose flag altogether seems the better > choice as long as it isn't too intrusive / noisy. > Is the intrusiveness something that needs to be and can be tested? Can > we remove the flag and if needed later reinstate it via a system property? Yes, this seems OK to me. > ?it wouldn't surprise me that some of the WARNING log messages are > things that the user shouldn't necessarily be warned about. > > > From my point of view, if the warning messages are of no interest to > the user, maybe they shouldn't be warning level. Agreed. Some testing will be needed to see whether that is the case. -- Kevin On 5/3/2018 7:07 AM, Nir Lisker wrote: > >> Also, why is webkit.mediaplayer special in its usage of the >> logger (that it requires its own property)? >> > > That's the real question: are the needs of the WebView media > component so special that it justifies its own mechanism / > property. I doubt it, which is why removing the verbose flag > altogether seems the better choice as long as it isn't too > intrusive / noisy. > > Is the intrusiveness something that needs to be and can be tested? Can > we remove the flag and if needed later reinstate it via a system property? > > ?it wouldn't surprise me that some of the WARNING log messages are > things that the user shouldn't necessarily be warned about. > > > From my point of view, if the warning messages are of no interest to > the user, maybe they shouldn't be warning level. > > - Nir > On Thu, May 3, 2018 at 2:42 PM, Kevin Rushforth > > wrote: > > > > On 5/2/2018 6:25 PM, Nir Lisker wrote: >> >> Not sure what you mean by "that file". >> >> >> Sorry, I meant the log/config file. > > I see. This isn't something that a library like JavaFX should read. > >> keeping the verbose flag but putting it on a System property >> >> >> Then why not get a minimum level from a system property instead >> of a general on/off flag? > > Because that would be duplicating functionality that should be > handled by the logger configuration itself (we can't set the > logging level when using the PlatformLogger wrapper utility to > System.Logger). > >> Also, why is webkit.mediaplayer special in its usage of the >> logger (that it requires its own property)? > > That's the real question: are the needs of the WebView media > component so special that it justifies its own mechanism / > property. I doubt it, which is why removing the verbose flag > altogether seems the better choice as long as it isn't too > intrusive / noisy. > > -- Kevin > > > >> - Nir >> >> On Thu, May 3, 2018 at 3:31 AM, Kevin Rushforth >> > >> wrote: >> >> inline >> >> >> On 5/2/2018 4:52 PM, Nir Lisker wrote: >> >> Thanks Murali, >> >> I won?t suggest reading level value from log/config file. >> >> >> Is that file user facing? If so, wouldn't ignoring the >> level set in the >> file break current behavior? Would there need to be >> follow-up changes to >> this file to remove the level setting from it? >> >> >> Not sure what you mean by "that file". The WCMediaPlayer >> file? No, it isn't user-facing. Or did you mean something else? >> >> About option (a), wouldn't removing the verbose flag >> (After changing INFO >> to FINE) cause all the log messages to appear by default, >> as you've stated >> in the first point, and we want to avoid that? We don't >> have a minimum log >> level setting. >> >> >> By default the log level for all loggers is set at INFO -- >> thus the suggestion to change all of the INFO messages to >> FINE, which will not be logged by default. If we still end up >> with a bunch of extra WARNING or SEVERE log messages from >> from ordinary situations, then that would be a problem. Given >> that the implementation of WCMediaPlayer produces "noisier >> than typical" INFO log messages, it wouldn't surprise me that >> some of the WARNING log messages are things that the user >> shouldn't necessarily be warned about. >> >> In any case, the second suggestion of keeping the verbose >> flag but putting it on a System property might be less >> intrusive. And like the current solution, puts the control in >> the hands of the user. >> >> -- Kevin >> >> >> -Nir >> >> >> On Wed, May 2, 2018 at 11:21 PM, Murali Billa >> > >> wrote: >> >> Hi Nir, >> >> >> >> 1) Regarding ?verbose? flag usage: >> >> ? ?Currently verbose flag is used to show log Levels >> (FINER/FINE/INFO/WARNING) in WCMediaPlayer & >> WCMediaPlayerImpl.? I feel >> it is not desirable to remove this flag as all these >> logs will start >> appearing now by default. >> >> ?? ? ? ? ?We can try 2 options: >> >> a)? ? ? ?1st Option: We can change all INFO log >> messages to FINE? under >> verbose flag (by leaving all log messages that use >> Level other than INFO >> unchanged) and verbose flag can be removed. >> >> b)? ? ? If 1st option results in too much noise for >> WARNING log messages, >> then we can keep the verbose flag and introduce a >> System Property (for ex: >> javafx.web.verbose) to enable the flag. I won?t >> suggest reading level value >> from log/config file. >> >> >> >> 2) Regarding >> ?com.sun.javafx.webkit.drt.DumpRenderTree?, I need to >> check few more things (since we use ?addHandler? in >> drt) and will get back >> to you. >> >> >> >> Please let me know, if you have any queries for 1. >> >> Thanks, >> >> Murali >> >> *From:* Nir Lisker > > >> *Sent:* Saturday, April 28, 2018 1:06 AM >> *To:* Murali Billa > > >> *Cc:* openjfx-dev at openjdk.java.net >> Mailing >> > > >> *Subject:* JDK-8195974: Replace use of >> java.util.logging in javafx with >> System logger >> >> >> >> Hi Murali, >> >> >> >> Can you have a look at >> https://bugs.openjdk.java.net/browse/JDK-8195974 >> >> please? >> >> >> >> There are some usages of j.u.l in the web module I'd >> like your opinion on. >> I'm not familiar with the intent of these pieces of >> code and would like to >> know what the options are for advancing with this >> issue on that front. >> >> >> >> Thanks, >> >> Nir >> >> >> > > From paulrussell70 at gmail.com Thu May 3 15:29:28 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Thu, 3 May 2018 16:29:28 +0100 Subject: native libs in modules Message-ID: >* I'm thinking about this issue now because I quite like JavaFX and its *>* future is clearly as a regular Java library, albeit a big one, distributed *>* either via (not ideal) an SDK or (better) a set of regular libraries *>* published to a Maven repository. *> +1 for this. (-1 for cross posting) The OP is right IMO, hacky jars containing native payloads seem common. From pedro.duquevieira at gmail.com Thu May 3 17:17:15 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 3 May 2018 18:17:15 +0100 Subject: Paint Phase Debugging / Performance Message-ID: Hi Matthew, On the topic of documents with indications for improving performance. Don't know if you already found it, but there is a draft here (to which I've made a small contribution): https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks A bit old though... And here: https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ideas -- Pedro Duque Vieira From johan.vos at gluonhq.com Thu May 3 20:18:04 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 03 May 2018 20:18:04 +0000 Subject: clinit and threads Message-ID: Hi, For a number of reasons, I'm looking into using SubstrateVM to bundle a JavaFX application into a native executable. The SubstrateVM relies on an AOT that's more aggressive than Gluon VM and it will precompile class initializers. I clearly see the (performance) benefits of this, but it has also consequences that have to be taken into account. One of those consequences is that threads that are somehow referenced via those class initialization code should not be in a started state. I tweaked a few initializers to avoid doing this, but the biggest impact this has so far is on Toolkit.getToolkit(). This will set the static TOOLKIT field of Toolkit to e.g. QuantumToolkit, and a whole bunch of objects become reachable including e.g. HashMap$Node hence ThreadPoolExecutor$Worker and a thread is started. As long as there is no single clinit call that uses Toolkit.getToolkit() this is not a problem, but clearly there are class initializers that use (indirectly) Toolkit.getToolkit() -- for example, AbstractMasterTimer.java has a few booleans that are statically initialized to Settings.getBoolean(), which triggers Settings.getInstance(), which uses Toolkit.getToolkit() While it is not impossible to modify those, it's probably some work and I wonder if there might be an easier solution? - Johan From kevin.rushforth at oracle.com Thu May 3 22:03:04 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 3 May 2018 15:03:04 -0700 Subject: clinit and threads In-Reply-To: References: Message-ID: Hi Johan, I don't know whether this work at all, and it might be even more work than what you are proposing, but a possible approach would be to create a variant of the getToolkit method with a boolean indicating whether to create/initialize the Toolkit instance, with a default of "false". Something like this: Toolkit: public static synchronized Toolkit getToolkit() { ??? getToolkit(false); } public static synchronized Toolkit getToolkit(boolean create) { ??? if (TOOLKIT != null) { ? ?? ?? return TOOLKIT; ??? } ??? if (!create) throw new IllegalStateException("Toolkit not created"); ??? // existing code goes here.... } The PlatformImpl startup code (and maybe a few other cases) would call getToolkit(true). Existing code that calls Toolkit.getToolkit would work only if the platform was already started, which is proably OK for many of the usages. This presumes that the FX runtime is always started before getting to the various places that call getToolkit(), which might or might not be a valid assumption. This should not be a problem with proper JavaFX applications that aren't trying to be overly clever and do anything before the Application is launched. If there are some code paths that call getToolkit without the platform being properly started up, they would get an ISE. It might be a problem for our test framework (e.g., the StubToolkit-based tests). It would need to be tested. A variation on the above: if most places can safely call the existing getToolkit() method, you could flip the default and call getToolkit(false) in the (hopefully few) places that you find are called from a static initializer. Anyway, that's all I could come with off the top of my head. -- Kevin On 5/3/2018 1:18 PM, Johan Vos wrote: > Hi, > > For a number of reasons, I'm looking into using SubstrateVM to bundle a > JavaFX application into a native executable. The SubstrateVM relies on an > AOT that's more aggressive than Gluon VM and it will precompile class > initializers. > I clearly see the (performance) benefits of this, but it has also > consequences that have to be taken into account. > > One of those consequences is that threads that are somehow referenced via > those class initialization code should not be in a started state. > > I tweaked a few initializers to avoid doing this, but the biggest impact > this has so far is on Toolkit.getToolkit(). > This will set the static TOOLKIT field of Toolkit to e.g. QuantumToolkit, > and a whole bunch of objects become reachable including e.g. HashMap$Node > hence ThreadPoolExecutor$Worker and a thread is started. > > As long as there is no single clinit call that uses Toolkit.getToolkit() > this is not a problem, but clearly there are class initializers that use > (indirectly) Toolkit.getToolkit() -- for example, AbstractMasterTimer.java > has a few booleans that are statically initialized to > Settings.getBoolean(), which triggers Settings.getInstance(), which uses > Toolkit.getToolkit() > > While it is not impossible to modify those, it's probably some work and I > wonder if there might be an easier solution? > > - Johan From tbee at tbee.org Fri May 4 04:28:12 2018 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 4 May 2018 06:28:12 +0200 Subject: clinit and threads In-Reply-To: References: Message-ID: Just in case you had not though of this (I expect you have), but you can have a kind of static gateway boolean preventing toolkit being created as long as it should not be. java -Djavafx.toolkit.noSingleton public static synchronized Toolkit getToolkit() { ??? if (TOOLKIT == null && System.getPropery("javafx.toolkit.noSingleton") != null) { ? ?? ?? return null; ??? } ??? // existing code goes here.... } And then when it is ok... System.clearProperty("javafx.toolkit.noSingleton") Or, if you have a good place to call a "setNoSingleton(true)" or the other way around, prior to the first getPlatform, use a static boolean (better performance). Of course the returning-null scenario's need to be handled on severfal places, or some kind of stub should be returned. On 4-5-2018 00:03, Kevin Rushforth wrote: > Hi Johan, > > I don't know whether this work at all, and it might be even more work than what you are proposing, but a possible approach would be to create a variant of the getToolkit method with a boolean indicating whether to create/initialize the Toolkit instance, with a default of "false". Something like this: > > Toolkit: > > public static synchronized Toolkit getToolkit() { > ??? getToolkit(false); > } > > public static synchronized Toolkit getToolkit(boolean create) { > ??? if (TOOLKIT != null) { > ? ?? ?? return TOOLKIT; > ??? } > ??? if (!create) throw new IllegalStateException("Toolkit not created"); > > ??? // existing code goes here.... > } > > The PlatformImpl startup code (and maybe a few other cases) would call getToolkit(true). Existing code that calls Toolkit.getToolkit would work only if the platform was already started, which is proably OK for many of the usages. > > This presumes that the FX runtime is always started before getting to the various places that call getToolkit(), which might or might not be a valid assumption. This should not be a problem with proper JavaFX applications that aren't trying to be overly clever and do anything before the Application is launched. If there are some code paths that call getToolkit without the platform being properly started up, they would get an ISE. It might be a problem for our test framework (e.g., the StubToolkit-based tests). It would need to be tested. > > A variation on the above: if most places can safely call the existing getToolkit() method, you could flip the default and call getToolkit(false) in the (hopefully few) places that you find are called from a static initializer. > > Anyway, that's all I could come with off the top of my head. > > -- Kevin > > > On 5/3/2018 1:18 PM, Johan Vos wrote: >> Hi, >> >> For a number of reasons, I'm looking into using SubstrateVM to bundle a >> JavaFX application into a native executable. The SubstrateVM relies on an >> AOT that's more aggressive than Gluon VM and it will precompile class >> initializers. >> I clearly see the (performance) benefits of this, but it has also >> consequences that have to be taken into account. >> >> One of those consequences is that threads that are somehow referenced via >> those class initialization code should not be in a started state. >> >> I tweaked a few initializers to avoid doing this, but the biggest impact >> this has so far is on Toolkit.getToolkit(). >> This will set the static TOOLKIT field of Toolkit to e.g. QuantumToolkit, >> and a whole bunch of objects become reachable including e.g. HashMap$Node >> hence ThreadPoolExecutor$Worker and a thread is started. >> >> As long as there is no single clinit call that uses Toolkit.getToolkit() >> this is not a problem, but clearly there are class initializers that use >> (indirectly) Toolkit.getToolkit() -- for example, AbstractMasterTimer.java >> has a few booleans that are statically initialized to >> Settings.getBoolean(), which triggers Settings.getInstance(), which uses >> Toolkit.getToolkit() >> >> While it is not impossible to modify those, it's probably some work and I >> wonder if there might be an easier solution? >> >> - Johan > From matthew.james.elliot at gmail.com Fri May 4 07:30:51 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Fri, 4 May 2018 09:30:51 +0200 Subject: Paint Phase Debugging / Performance In-Reply-To: References: Message-ID: Hi Pedro, The first link I have read through many times, it is very useful for ideas but doesn't really flesh out or go into much detail on each topic. It also comments a few times on the problems we've encountered, 'what costs what' is difficult to understand / measure. The second link I hadn't found my way to and is definitely interesting to understand more about how things are working internally - thanks. Regards, Matt On 3 May 2018 at 19:17, Pedro Duque Vieira wrote: > Hi Matthew, > > On the topic of documents with indications for improving performance. > > Don't know if you already found it, but there is a draft here (to which > I've made a small contribution): > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks > > A bit old though... > > And here: > > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ideas > > > -- > Pedro Duque Vieira > From prasanta.sadhukhan at oracle.com Fri May 4 12:00:20 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 4 May 2018 17:30:20 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop Message-ID: Hi All, Please review an enhancement to remove the tight coupling of JDK internal class from FX so that when javafx.* modules are removed from Openjdk build in jdk11, FX in general, and fx swing interop, in particular, can still build and function. Right now, FX uses 6 jdk internal packages sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and sun.java2d. However, the goal is not to use qualified exports of these internal packages once FX is removed to be built along with JDK, The solution will define a new "jdk.unsupported.desktop" module that exports public API that is intended to be used by the javafx.swing module (but it does so with public exports and not qualified exports). The idea is the same as jdk.unsupported, in that it is documented as being unsupported. Further, since it is only intended to be used by javafx.swing, it need not be in the default module graph. The module-info.java will look like this: |module jdk.unsupported.desktop { requires transitive java.desktop; exports jdk.swing.interop; } ||| Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, https://bugs.openjdk.java.net/browse/JDK-8195811 webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 Regards Prasanta || From kevin.rushforth at oracle.com Fri May 4 12:10:42 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 4 May 2018 05:10:42 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: Message-ID: <2178d15d-6a33-46bf-c4c6-1cdb9b71b6ca@oracle.com> Thanks, Prasanta. As an additional note to reviewers: The JDK portion of this change (JDK-8202199) is the subject for this review. The FX webrev is enough to be able to test the JDK side, but will need additional refactoring (to allow it to continue to build / run with JDK 10) before being ready for review. If you spot something of concern in the FX webrev, please feel free to bring it up, but don't spend time doing a thorough review just yet. -- Kevin On 5/4/2018 5:00 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review an enhancement to remove the tight coupling of JDK > internal class from FX so that > when javafx.* modules are removed from Openjdk build in jdk11, FX in > general, and fx swing interop, in particular, can still build and > function. > > Right now, FX uses 6 jdk internal packages > sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and > sun.java2d. > > However, the goal is not to use qualified exports of these internal > packages once FX is removed to be built along with JDK, > > The solution will define a new "jdk.unsupported.desktop" module that > exports public API > that is intended to be used by the javafx.swing module (but it does so > with public exports and not qualified exports). > The idea is the same as jdk.unsupported, in that it is documented as > being unsupported. > Further, since it is only intended to be used by javafx.swing, it need > not be in the default module graph. > > The module-info.java will look like this: > |module jdk.unsupported.desktop { requires transitive java.desktop; > exports jdk.swing.interop; } ||| > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, > https://bugs.openjdk.java.net/browse/JDK-8195811 > webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 > > Regards > Prasanta > || > From nlisker at gmail.com Fri May 4 14:40:17 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 4 May 2018 17:40:17 +0300 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <2178d15d-6a33-46bf-c4c6-1cdb9b71b6ca@oracle.com> References: <2178d15d-6a33-46bf-c4c6-1cdb9b71b6ca@oracle.com> Message-ID: Hi Prasanta, In SwingNode, lines 870 -883, is there a reason that only the first method uncommented @Override? I don't understand the comment that wants to skip @Override. Some minor code comments: * LightweightFrameWrapper#isCompEqual: you can skip the 'if' and just 'return c != lwFrame.getLightweightFrame();'. * Same with SwingInterOpUtils#isUngrabEvent. * LightweightFrameWrapper#createUngrabEvent: you can directly 'return new ...' (I wouldn't comment about this had you not done this to the other methods). * LightweightContentWrapper: there're no new lines between non-empty methods, especially in LightweightContentProxy. Is this an acceptable code style? * Same for DragSourceContextPeerWrapper and the proxy, DragTargetContextPeerWrapper. and DispatcherWrapper. * Extra empty line(s) at the end of DropTargetContextPeerWrapper. - Nir On Fri, May 4, 2018 at 3:10 PM, Kevin Rushforth wrote: > Thanks, Prasanta. > > As an additional note to reviewers: > > The JDK portion of this change (JDK-8202199) is the subject for this > review. > > The FX webrev is enough to be able to test the JDK side, but will need > additional refactoring (to allow it to continue to build / run with JDK 10) > before being ready for review. If you spot something of concern in the FX > webrev, please feel free to bring it up, but don't spend time doing a > thorough review just yet. > > -- Kevin > > > > On 5/4/2018 5:00 AM, Prasanta Sadhukhan wrote: > >> Hi All, >> >> Please review an enhancement to remove the tight coupling of JDK internal >> class from FX so that >> when javafx.* modules are removed from Openjdk build in jdk11, FX in >> general, and fx swing interop, in particular, can still build and function. >> >> Right now, FX uses 6 jdk internal packages >> sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and >> sun.java2d. >> >> However, the goal is not to use qualified exports of these internal >> packages once FX is removed to be built along with JDK, >> >> The solution will define a new "jdk.unsupported.desktop" module that >> exports public API >> that is intended to be used by the javafx.swing module (but it does so >> with public exports and not qualified exports). >> The idea is the same as jdk.unsupported, in that it is documented as >> being unsupported. >> Further, since it is only intended to be used by javafx.swing, it need >> not be in the default module graph. >> >> The module-info.java will look like this: >> |module jdk.unsupported.desktop { requires transitive java.desktop; >> exports jdk.swing.interop; } ||| >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, >> https://bugs.openjdk.java.net/browse/JDK-8195811 >> webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >> >> Regards >> Prasanta >> || >> >> > From philip.race at oracle.com Fri May 4 20:53:03 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 4 May 2018 13:53:03 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: Message-ID: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> Two quick comments. 1) I'd like "Peer" removed from all the exported API. 2) It is probably stable enough now that you can start to add some javadoc. -phil. On 05/04/2018 05:00 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review an enhancement to remove the tight coupling of JDK > internal class from FX so that > when javafx.* modules are removed from Openjdk build in jdk11, FX in > general, and fx swing interop, in particular, can still build and > function. > > Right now, FX uses 6 jdk internal packages > sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and > sun.java2d. > > However, the goal is not to use qualified exports of these internal > packages once FX is removed to be built along with JDK, > > The solution will define a new "jdk.unsupported.desktop" module that > exports public API > that is intended to be used by the javafx.swing module (but it does so > with public exports and not qualified exports). > The idea is the same as jdk.unsupported, in that it is documented as > being unsupported. > Further, since it is only intended to be used by javafx.swing, it need > not be in the default module graph. > > The module-info.java will look like this: > > |module jdk.unsupported.desktop { requires transitive java.desktop; > exports jdk.swing.interop; } ||| > > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, > https://bugs.openjdk.java.net/browse/JDK-8195811 > webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 > > Regards > Prasanta > > || > > From mandy.chung at oracle.com Fri May 4 21:08:33 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 4 May 2018 14:08:33 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: Message-ID: <554d7847-8c52-f5f0-9893-77443d718887@oracle.com> I skimmed through the sources.? It's good to see that this patch is straight forward.? A couple of comments: jdk.unsupported.desktop is defined to the application class loader which I think it's fine as FX modules are defined to the same class loader. I expect src/java.base/share/lib/security/default.security will need to be modified and grant permissions to jdk.unsupported.desktop. Kevin and I talked about potential issues with running with security manager enabled.? Maybe it is a separate task to follow up and it may reveal if any operation needs doPrivileged - that's fine with me. The docs build starts with a known set of root modules for javadoc generation.? I believe jdk.unsupported.desktop won't be included in the docs build which is intended (as it's unsupported).? Can you verify it? Nit: jdk.swing.interop.* source files it'd be good to keep import statements sorted by the names. Mandy On 5/4/18 5:00 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review an enhancement to remove the tight coupling of JDK > internal class from FX so that > when javafx.* modules are removed from Openjdk build in jdk11, FX in > general, and fx swing interop, in particular, can still build and > function. > > Right now, FX uses 6 jdk internal packages > sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and > sun.java2d. > > However, the goal is not to use qualified exports of these internal > packages once FX is removed to be built along with JDK, > > The solution will define a new "jdk.unsupported.desktop" module that > exports public API > that is intended to be used by the javafx.swing module (but it does so > with public exports and not qualified exports). > The idea is the same as jdk.unsupported, in that it is documented as > being unsupported. > Further, since it is only intended to be used by javafx.swing, it need > not be in the default module graph. > > The module-info.java will look like this: > |module jdk.unsupported.desktop { requires transitive java.desktop; > exports jdk.swing.interop; } ||| > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, > https://bugs.openjdk.java.net/browse/JDK-8195811 > webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 > > Regards > Prasanta > || > From kevin.rushforth at oracle.com Fri May 4 22:30:09 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 4 May 2018 15:30:09 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <554d7847-8c52-f5f0-9893-77443d718887@oracle.com> References: <554d7847-8c52-f5f0-9893-77443d718887@oracle.com> Message-ID: > jdk.unsupported.desktop is defined to the application class loader > which I think it's fine as FX modules are defined to the same class > loader. I noticed this, too, during my testing this morning. It still fails when the security manager is enabled. We already have a bug filed for this: https://bugs.openjdk.java.net/browse/JDK-8202451 I had hoped would be fixed along with the new unsupported API, but I agree that this could be fixed later. -- Kevin On 5/4/2018 2:08 PM, mandy chung wrote: > I skimmed through the sources.? It's good to see that this patch > is straight forward.? A couple of comments: > > jdk.unsupported.desktop is defined to the application class loader > which I think it's fine as FX modules are defined to the same class > loader. > > I expect src/java.base/share/lib/security/default.security will > need to be modified and grant permissions to jdk.unsupported.desktop. > Kevin and I talked about potential issues with running with security > manager enabled.? Maybe it is a separate task to follow up and it > may reveal if any operation needs doPrivileged - that's fine with me. > > The docs build starts with a known set of root modules for javadoc > generation.? I believe jdk.unsupported.desktop won't be included > in the docs build which is intended (as it's unsupported).? Can > you verify it? > > Nit: jdk.swing.interop.* source files > it'd be good to keep import statements sorted by the names. > > Mandy > > On 5/4/18 5:00 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review an enhancement to remove the tight coupling of JDK >> internal class from FX so that >> when javafx.* modules are removed from Openjdk build in jdk11, FX in >> general, and fx swing interop, in particular, can still build and >> function. >> >> Right now, FX uses 6 jdk internal packages >> sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and >> sun.java2d. >> >> However, the goal is not to use qualified exports of these internal >> packages once FX is removed to be built along with JDK, >> >> The solution will define a new "jdk.unsupported.desktop" module that >> exports public API >> that is intended to be used by the javafx.swing module (but it does >> so with public exports and not qualified exports). >> The idea is the same as jdk.unsupported, in that it is documented as >> being unsupported. >> Further, since it is only intended to be used by javafx.swing, it >> need not be in the default module graph. >> >> The module-info.java will look like this: >> |module jdk.unsupported.desktop { requires transitive java.desktop; >> exports jdk.swing.interop; } ||| >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, >> https://bugs.openjdk.java.net/browse/JDK-8195811 >> webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >> >> Regards >> Prasanta >> || >> > From kevin.rushforth at oracle.com Fri May 4 23:02:51 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 4 May 2018 16:02:51 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> Message-ID: <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> My quick comments: 1. The changes to java.desktop module-info.java won't compile when applied to jdk-client, since there is already a qualified export of the sun.swing package to another internal class. Can you update your patch to be based off of jdk-client? I note that it requires a small patch to be able to build FX with JDK 11 (it's a known gradle issue), but it's not hard to do. 2. As I mentioned in an off-line email, the final version of the javafx.swing patch will need to use 'requires static jdk.unsupported.desktop' in its module-info.java, so that it will still run on JDK 10 EA. This means that you will need to ensure that jdk.unsupported.desktop is loaded via a service loader as discussed. This will not affect the public API at all, so that can proceed in parallel, but this needs to be fixed. 3. As I mentioned in my earlier reply to Mandy's comment, Swing interop apps will fail if a security manager is installed, because the jdk.unsupported.desktop classes are loaded by the app class loader. This can be sorted out later as a follow-on bug, with permissions added to the default policy file, etc. 4. As Phil mentioned, some docs would be good. They don't need to be all that detailed, since it isn't intended for use by applications, and will not be included in the published API docs bundle (i.e., it should be excluded from "make docs"). I will do a more detailed review early next week. -- Kevin On 5/4/2018 1:53 PM, Phil Race wrote: > Two quick comments. > > 1) I'd like "Peer" removed from all the exported API. > 2) It is probably stable enough now that you can start to add some > javadoc. > > -phil. > > On 05/04/2018 05:00 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review an enhancement to remove the tight coupling of JDK >> internal class from FX so that >> when javafx.* modules are removed from Openjdk build in jdk11, FX in >> general, and fx swing interop, in particular, can still build and >> function. >> >> Right now, FX uses 6 jdk internal packages >> sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and >> sun.java2d. >> >> However, the goal is not to use qualified exports of these internal >> packages once FX is removed to be built along with JDK, >> >> The solution will define a new "jdk.unsupported.desktop" module that >> exports public API >> that is intended to be used by the javafx.swing module (but it does >> so with public exports and not qualified exports). >> The idea is the same as jdk.unsupported, in that it is documented as >> being unsupported. >> Further, since it is only intended to be used by javafx.swing, it >> need not be in the default module graph. >> >> The module-info.java will look like this: >> >> |module jdk.unsupported.desktop { requires transitive java.desktop; >> exports jdk.swing.interop; } ||| >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, >> https://bugs.openjdk.java.net/browse/JDK-8195811 >> webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >> >> Regards >> Prasanta >> >> || >> >> > From prasanta.sadhukhan at oracle.com Sat May 5 08:58:57 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 5 May 2018 14:28:57 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> Message-ID: <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> Hi All, I have tried to address all comments from Nir, Phil, Mandy and Kevin got so far in this webrev http://cr.openjdk.java.net/~psadhukhan/fxswing.7 >>In?SwingNode, lines 870 -883, is there a reason that only the first method uncommented @Override? I don't understand the comment that wants to skip @Override. If @override is not added, then it will cause recursion between LightweightContent.java:130 and LightweightContent.java:187 thereby causing StackOverflowError. I am also not sure about the comment of skipping @Override but I have removed it from this webrev. Regards Prasanta On 5/5/2018 4:32 AM, Kevin Rushforth wrote: > My quick comments: > > 1. The changes to java.desktop module-info.java won't compile when > applied to jdk-client, since there is already a qualified export of > the sun.swing package to another internal class. Can you update your > patch to be based off of jdk-client? I note that it requires a small > patch to be able to build FX with JDK 11 (it's a known gradle issue), > but it's not hard to do. > > 2. As I mentioned in an off-line email, the final version of the > javafx.swing patch will need to use 'requires static > jdk.unsupported.desktop' in its module-info.java, so that it will > still run on JDK 10 EA. This means that you will need to ensure that > jdk.unsupported.desktop is loaded via a service loader as discussed. > This will not affect the public API at all, so that can proceed in > parallel, but this needs to be fixed. > > 3. As I mentioned in my earlier reply to Mandy's comment, Swing > interop apps will fail if a security manager is installed, because the > jdk.unsupported.desktop classes are loaded by the app class loader. > This can be sorted out later as a follow-on bug, with permissions > added to the default policy file, etc. > > 4. As Phil mentioned, some docs would be good. They don't need to be > all that detailed, since it isn't intended for use by applications, > and will not be included in the published API docs bundle (i.e., it > should be excluded from "make docs"). > > I will do a more detailed review early next week. > > -- Kevin > > On 5/4/2018 1:53 PM, Phil Race wrote: >> Two quick comments. >> >> 1) I'd like "Peer" removed from all the exported API. >> 2) It is probably stable enough now that you can start to add some >> javadoc. >> >> -phil. >> >> On 05/04/2018 05:00 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review an enhancement to remove the tight coupling of JDK >>> internal class from FX so that >>> when javafx.* modules are removed from Openjdk build in jdk11, FX in >>> general, and fx swing interop, in particular, can still build and >>> function. >>> >>> Right now, FX uses 6 jdk internal packages >>> sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image >>> and sun.java2d. >>> >>> However, the goal is not to use qualified exports of these internal >>> packages once FX is removed to be built along with JDK, >>> >>> The solution will define a new "jdk.unsupported.desktop" module that >>> exports public API >>> that is intended to be used by the javafx.swing module (but it does >>> so with public exports and not qualified exports). >>> The idea is the same as jdk.unsupported, in that it is documented as >>> being unsupported. >>> Further, since it is only intended to be used by javafx.swing, it >>> need not be in the default module graph. >>> >>> The module-info.java will look like this: >>> >>> |module jdk.unsupported.desktop { requires transitive java.desktop; >>> exports jdk.swing.interop; } ||| >>> >>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, >>> https://bugs.openjdk.java.net/browse/JDK-8195811 >>> webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >>> >>> Regards >>> Prasanta >>> >>> || >>> >>> >> > From prasanta.sadhukhan at oracle.com Sat May 5 15:20:40 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 5 May 2018 20:50:40 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> Message-ID: Updated webrev to modify java.desktop module-info.java (only difference between webrev7 and this) to remove the duplicate exports of sun.awt so we will have now exports sun.awt to ??????? jdk.accessibility, ??????? jdk.unsupported.desktop; http://cr.openjdk.java.net/~psadhukhan/fxswing.8/ Regards Prasanta On 5/5/2018 2:28 PM, Prasanta Sadhukhan wrote: > Hi All, > > I have tried to address all comments from Nir, Phil, Mandy and Kevin > got so far in this webrev > http://cr.openjdk.java.net/~psadhukhan/fxswing.7 > > >>In?SwingNode, lines 870 -883, is there a reason that only the first > method uncommented @Override? I don't understand the comment that > wants to skip @Override. > If @override is not added, then it will cause recursion between > LightweightContent.java:130 and LightweightContent.java:187 thereby > causing StackOverflowError. I am also not sure about the comment of > skipping @Override but I have removed it from this webrev. > > Regards > Prasanta > On 5/5/2018 4:32 AM, Kevin Rushforth wrote: >> My quick comments: >> >> 1. The changes to java.desktop module-info.java won't compile when >> applied to jdk-client, since there is already a qualified export of >> the sun.swing package to another internal class. Can you update your >> patch to be based off of jdk-client? I note that it requires a small >> patch to be able to build FX with JDK 11 (it's a known gradle issue), >> but it's not hard to do. >> >> 2. As I mentioned in an off-line email, the final version of the >> javafx.swing patch will need to use 'requires static >> jdk.unsupported.desktop' in its module-info.java, so that it will >> still run on JDK 10 EA. This means that you will need to ensure that >> jdk.unsupported.desktop is loaded via a service loader as discussed. >> This will not affect the public API at all, so that can proceed in >> parallel, but this needs to be fixed. >> >> 3. As I mentioned in my earlier reply to Mandy's comment, Swing >> interop apps will fail if a security manager is installed, because >> the jdk.unsupported.desktop classes are loaded by the app class >> loader. This can be sorted out later as a follow-on bug, with >> permissions added to the default policy file, etc. >> >> 4. As Phil mentioned, some docs would be good. They don't need to be >> all that detailed, since it isn't intended for use by applications, >> and will not be included in the published API docs bundle (i.e., it >> should be excluded from "make docs"). >> >> I will do a more detailed review early next week. >> >> -- Kevin >> >> On 5/4/2018 1:53 PM, Phil Race wrote: >>> Two quick comments. >>> >>> 1) I'd like "Peer" removed from all the exported API. >>> 2) It is probably stable enough now that you can start to add some >>> javadoc. >>> >>> -phil. >>> >>> On 05/04/2018 05:00 AM, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review an enhancement to remove the tight coupling of JDK >>>> internal class from FX so that >>>> when javafx.* modules are removed from Openjdk build in jdk11, FX >>>> in general, and fx swing interop, in particular, can still build >>>> and function. >>>> >>>> Right now, FX uses 6 jdk internal packages >>>> sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image >>>> and sun.java2d. >>>> >>>> However, the goal is not to use qualified exports of these internal >>>> packages once FX is removed to be built along with JDK, >>>> >>>> The solution will define a new "jdk.unsupported.desktop" module >>>> that exports public API >>>> that is intended to be used by the javafx.swing module (but it does >>>> so with public exports and not qualified exports). >>>> The idea is the same as jdk.unsupported, in that it is documented >>>> as being unsupported. >>>> Further, since it is only intended to be used by javafx.swing, it >>>> need not be in the default module graph. >>>> >>>> The module-info.java will look like this: >>>> >>>> |module jdk.unsupported.desktop { requires transitive java.desktop; >>>> exports jdk.swing.interop; } ||| >>>> >>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, >>>> https://bugs.openjdk.java.net/browse/JDK-8195811 >>>> webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >>>> >>>> Regards >>>> Prasanta >>>> >>>> || >>>> >>>> >>> >> > From nlisker at gmail.com Sat May 5 16:34:50 2018 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 5 May 2018 19:34:50 +0300 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> Message-ID: Hi Prasanta, If @override is not added, then it will cause recursion between > LightweightContent.java:130 and LightweightContent.java:187 I don't understand how the existence or lack thereof of an @Override can cause or prevent recursion (bar reflection). Since all the methods of the interface are overriden in SwingNode (regardless of the annotation) their default implementation is not used, and SwingNode is recursion-free. What is more worrisome is that if the interface methods are not overriden in some other implementing class, there will be infinite recursion, but this a fault in the design of the interface (I'd say), and out of scope for this issue. On the up side, one of the methods in the interface is deprecated, so it didn't go completely under the radar. Personally, I force the use of @Override where applicable since it can only help and I only brought this up since you uncommented 1 of the annotations and left 2 others. Thanks, Nir On Sat, May 5, 2018 at 6:20 PM, Prasanta Sadhukhan < prasanta.sadhukhan at oracle.com> wrote: > Updated webrev to modify java.desktop module-info.java (only difference > between webrev7 and this) to remove the duplicate exports of sun.awt so we > will have now > > exports sun.awt to > jdk.accessibility, > jdk.unsupported.desktop; > > http://cr.openjdk.java.net/~psadhukhan/fxswing.8/ > > Regards > Prasanta > > On 5/5/2018 2:28 PM, Prasanta Sadhukhan wrote: > >> Hi All, >> >> I have tried to address all comments from Nir, Phil, Mandy and Kevin got >> so far in this webrev >> http://cr.openjdk.java.net/~psadhukhan/fxswing.7 >> >> >>In SwingNode, lines 870 -883, is there a reason that only the first >> method uncommented @Override? I don't understand the comment that wants to >> skip @Override. >> If @override is not added, then it will cause recursion between >> LightweightContent.java:130 and LightweightContent.java:187 thereby causing >> StackOverflowError. I am also not sure about the comment of skipping >> @Override but I have removed it from this webrev. >> >> Regards >> Prasanta >> On 5/5/2018 4:32 AM, Kevin Rushforth wrote: >> >>> My quick comments: >>> >>> 1. The changes to java.desktop module-info.java won't compile when >>> applied to jdk-client, since there is already a qualified export of the >>> sun.swing package to another internal class. Can you update your patch to >>> be based off of jdk-client? I note that it requires a small patch to be >>> able to build FX with JDK 11 (it's a known gradle issue), but it's not hard >>> to do. >>> >>> 2. As I mentioned in an off-line email, the final version of the >>> javafx.swing patch will need to use 'requires static >>> jdk.unsupported.desktop' in its module-info.java, so that it will still run >>> on JDK 10 EA. This means that you will need to ensure that >>> jdk.unsupported.desktop is loaded via a service loader as discussed. This >>> will not affect the public API at all, so that can proceed in parallel, but >>> this needs to be fixed. >>> >>> 3. As I mentioned in my earlier reply to Mandy's comment, Swing interop >>> apps will fail if a security manager is installed, because the >>> jdk.unsupported.desktop classes are loaded by the app class loader. This >>> can be sorted out later as a follow-on bug, with permissions added to the >>> default policy file, etc. >>> >>> 4. As Phil mentioned, some docs would be good. They don't need to be all >>> that detailed, since it isn't intended for use by applications, and will >>> not be included in the published API docs bundle (i.e., it should be >>> excluded from "make docs"). >>> >>> I will do a more detailed review early next week. >>> >>> -- Kevin >>> >>> On 5/4/2018 1:53 PM, Phil Race wrote: >>> >>>> Two quick comments. >>>> >>>> 1) I'd like "Peer" removed from all the exported API. >>>> 2) It is probably stable enough now that you can start to add some >>>> javadoc. >>>> >>>> -phil. >>>> >>>> On 05/04/2018 05:00 AM, Prasanta Sadhukhan wrote: >>>> >>>>> Hi All, >>>>> >>>>> Please review an enhancement to remove the tight coupling of JDK >>>>> internal class from FX so that >>>>> when javafx.* modules are removed from Openjdk build in jdk11, FX in >>>>> general, and fx swing interop, in particular, can still build and function. >>>>> >>>>> Right now, FX uses 6 jdk internal packages >>>>> sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and >>>>> sun.java2d. >>>>> >>>>> However, the goal is not to use qualified exports of these internal >>>>> packages once FX is removed to be built along with JDK, >>>>> >>>>> The solution will define a new "jdk.unsupported.desktop" module that >>>>> exports public API >>>>> that is intended to be used by the javafx.swing module (but it does so >>>>> with public exports and not qualified exports). >>>>> The idea is the same as jdk.unsupported, in that it is documented as >>>>> being unsupported. >>>>> Further, since it is only intended to be used by javafx.swing, it need >>>>> not be in the default module graph. >>>>> >>>>> The module-info.java will look like this: >>>>> >>>>> |module jdk.unsupported.desktop { requires transitive java.desktop; >>>>> exports jdk.swing.interop; } ||| >>>>> >>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199, >>>>> https://bugs.openjdk.java.net/browse/JDK-8195811 >>>>> webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/ >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8202175 >>>>> >>>>> Regards >>>>> Prasanta >>>>> >>>>> || >>>>> >>>>> >>>>> >>>> >>> >> > From Alan.Bateman at oracle.com Sun May 6 07:45:18 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 6 May 2018 08:45:18 +0100 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> Message-ID: <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> On 05/05/2018 16:20, Prasanta Sadhukhan wrote: > Updated webrev to modify java.desktop module-info.java (only > difference between webrev7 and this) to remove the duplicate exports > of sun.awt so we will have now > > exports sun.awt to > ??????? jdk.accessibility, > ??????? jdk.unsupported.desktop; > > http://cr.openjdk.java.net/~psadhukhan/fxswing.8/ At a high-level, the module declarations look good and using service binding to ensure that the jdk.unsupported.desktop module is resolved looks good. The only thing is the name of the service provider interface, it might be clearer if you use InteropProvider rather than InteropInterface. I assume dependencies/java.desktop/module-info.java.extra will be removed once the remaining dependency on sun.print goes away. -Alan From prasanta.sadhukhan at oracle.com Mon May 7 09:26:54 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 7 May 2018 14:56:54 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <574dca20-f932-8197-68e5-7c88cf59cbd5@oracle.com> <3e29c713-5c96-3c63-f7e0-40e030d873f5@oracle.com> <7522c34c-5c78-9d1c-044b-8e7ff5968f27@oracle.com> Message-ID: <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> On 5/6/2018 1:15 PM, Alan Bateman wrote: > On 05/05/2018 16:20, Prasanta Sadhukhan wrote: >> Updated webrev to modify java.desktop module-info.java (only >> difference between webrev7 and this) to remove the duplicate exports >> of sun.awt so we will have now >> >> exports sun.awt to >> ??????? jdk.accessibility, >> ??????? jdk.unsupported.desktop; >> >> http://cr.openjdk.java.net/~psadhukhan/fxswing.8/ > > At a high-level, the module declarations look good and using service > binding to ensure that the jdk.unsupported.desktop module is resolved > looks good. The only thing is the name of the service provider > interface, it might be clearer if you use InteropProvider rather than > InteropInterface. > Modified webrev to use InteropProvider http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ > I assume dependencies/java.desktop/module-info.java.extra will be > removed once the remaining dependency on sun.print goes away. > Yes, that's the plan. Regards Prasanta > -Alan From nlisker at gmail.com Mon May 7 12:36:34 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 7 May 2018 15:36:34 +0300 Subject: Paint Phase Debugging / Performance In-Reply-To: References: Message-ID: Hi, I'm having a performance issue myself. I'm using animations on 3D models (in a 3D subscene) and when there are "too many" models the QuantumRenderer thread is running 100% of the time and utilizing 20-25% of the CPU, though the OS reports that overall all cores are at ~40%. The application is using the d3d pipeline. A typical pulse is PULSE: 4078 [112ms:225ms] T15 (11 +0ms): CSS Pass T15 (11 +0ms): Layout Pass T15 (12 +0ms): Update bounds T15 (12 +95ms): Waiting for previous rendering T15 (108 +0ms): Copy state to render graph T12 (109 +115ms): Painting T12 (224 +0ms): Presenting Counters: Nodes rendered: 651 Nodes visited during render: 651 Thread dumps show that QuantumRenderer is busy with tasks inside at com.sun.prism.impl.BaseMesh.buildPTGeometry(javafx.graphics at 10-internal /BaseMesh.java:584) at com.sun.prism.impl.BaseMesh.buildGeometry(javafx.graphics at 10-internal /BaseMesh.java:516) at com.sun.javafx.sg.prism.NGTriangleMesh.validate(javafx.graphics at 10-internal /NGTriangleMesh.java:75) at com.sun.javafx.sg.prism.NGShape3D.renderMeshView(javafx.graphics at 10-internal /NGShape3D.java:84) at com.sun.javafx.sg.prism.NGShape3D.renderContent(javafx.graphics at 10-internal /NGShape3D.java:201) at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal /NGNode.java:2072) at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal /NGNode.java:1964) at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal /NGGroup.java:270) at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal /NGNode.java:2072) at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal /NGNode.java:1964) at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal /NGGroup.java:270) at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal /NGNode.java:2072) at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal /NGNode.java:1964) at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal /NGGroup.java:270) at com.sun.javafx.sg.prism.NGNode.renderCached(javafx.graphics at 10-internal /NGNode.java:2379) at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal /NGNode.java:2063) at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal /NGNode.java:1964) at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal /NGGroup.java:270) at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal /NGNode.java:2072) at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal /NGNode.java:1964) at com.sun.javafx.tk.quantum.ViewPainter.doPaint(javafx.graphics at 10-internal /ViewPainter.java:479) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(javafx.graphics at 10-internal /ViewPainter.java:328) at com.sun.javafx.tk.quantum.PresentingPainter.run(javafx.graphics at 10-internal /PresentingPainter.java:91) at java.util.concurrent.Executors$RunnableAdapter.call(java.base at 10-internal /Executors.java:514) at java.util.concurrent.FutureTask.runAndReset(java.base at 10-internal /FutureTask.java:305) at com.sun.javafx.tk.RenderJob.run(javafx.graphics at 10-internal /RenderJob.java:58) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 10-internal /ThreadPoolExecutor.java:1135) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 10-internal /ThreadPoolExecutor.java:635) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(javafx.graphics at 10-internal /QuantumRenderer.java:125) at java.lang.Thread.run(java.base at 10-internal/Thread.java:844) Does anyone have an idea on how to continue? Thanks, Nir On Fri, May 4, 2018 at 10:30 AM, Matthew Elliot < matthew.james.elliot at gmail.com> wrote: > Hi Pedro, > > The first link I have read through many times, it is very useful for ideas > but doesn't really flesh out or go into much detail on each topic. It also > comments a few times on the problems we've encountered, 'what costs what' > is difficult to understand / measure. > > The second link I hadn't found my way to and is definitely interesting to > understand more about how things are working internally - thanks. > > Regards, > Matt > > > On 3 May 2018 at 19:17, Pedro Duque Vieira > wrote: > > > Hi Matthew, > > > > On the topic of documents with indications for improving performance. > > > > Don't know if you already found it, but there is a draft here (to which > > I've made a small contribution): > > https://wiki.openjdk.java.net/display/OpenJFX/Performance+ > Tips+and+Tricks > > > > A bit old though... > > > > And here: > > > > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ideas > > > > > > -- > > Pedro Duque Vieira > > > From Alan.Bateman at oracle.com Mon May 7 14:57:09 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 May 2018 15:57:09 +0100 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> On 07/05/2018 10:26, Prasanta Sadhukhan wrote: > : > > Modified webrev to use InteropProvider > http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ This looks okay although for consistent then InteropImpl could be renamed too. -Alan From prasanta.sadhukhan at oracle.com Mon May 7 15:01:40 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 7 May 2018 20:31:40 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <7ffb5e6f-d013-a7f8-5e4b-49b7b3e9f66d@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> Would InteropProviderImpl sound good? Regards Prasanta On 5/7/2018 8:27 PM, Alan Bateman wrote: > > > On 07/05/2018 10:26, Prasanta Sadhukhan wrote: >> : >> >> Modified webrev to use InteropProvider >> http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ > This looks okay although for consistent then InteropImpl could be > renamed too. > > -Alan From kevin.rushforth at oracle.com Mon May 7 15:05:30 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 7 May 2018 08:05:30 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <16531321-7d15-00bf-0460-aee6290d626c@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> That name seems good to me. -- Kevin On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: > Would InteropProviderImpl sound good? > > Regards > Prasanta > On 5/7/2018 8:27 PM, Alan Bateman wrote: >> >> >> On 07/05/2018 10:26, Prasanta Sadhukhan wrote: >>> : >>> >>> Modified webrev to use InteropProvider >>> http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ >> This looks okay although for consistent then InteropImpl could be >> renamed too. >> >> -Alan > From mandy.chung at oracle.com Mon May 7 16:57:40 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 7 May 2018 09:57:40 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <7022dc1b-dee2-6b59-a40a-ac452bfc5c7f@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <0ab91959-1122-b3c4-e413-40eaeb0a9c04@oracle.com> On 5/7/18 2:26 AM, Prasanta Sadhukhan wrote: > Modified webrev to use InteropProvider > http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ This version looks good.?? InteropProviderImpl name is okay with me. Mandy From matthew.james.elliot at gmail.com Mon May 7 18:07:23 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Mon, 7 May 2018 20:07:23 +0200 Subject: Paint Phase Debugging / Performance In-Reply-To: References: Message-ID: Hey Nir, I?m not sure if I can offer much support as I haven?t been into the 3D world but just to clarify, is it one pulse after another with long wait, paint phases? From what I?ve seen personally if you have painting of 100+ milliseconds on every pulse you will be in big trouble / laggy as. On a one-off pulse like building a scene the first time I would say it is fine but regular paints that are longer are going to cause issues from my experience. Did you try profiling with mission controller to look at what garbage is being created / what hot methods there? Maybe it points you in a better direction / at least rule out your own code. With animations I guess you set cache hints already? Make sure you don?t have any effects on the animation as well, a Gaussian blur blend/drop shadow on an animation killed it for me. You can also try -Dprism.disableEffects= true to rule it out. You can also enable the prism option to show what is being painted on each pulse as an overlay. -Dprism.showdirty and there is another I forget to show how many times it was painted. (Not that your whole scene is painted when you expect a small part of it) Or some trial and error with the prism flags here to try narrow it down - Just open PrismSettings.java in your IDE or web browser. Code explains them better than most posts I?ve seen. Good luck. Matt Sent from my phone. > On 7/05/2018, at 2:36 PM, Nir Lisker wrote: > > Hi, > > I'm having a performance issue myself. I'm using animations on 3D models (in a 3D subscene) and when there are "too many" models the QuantumRenderer thread is running 100% of the time and utilizing 20-25% of the CPU, though the OS reports that overall all cores are at ~40%. The application is using the d3d pipeline. > > A typical pulse is > > PULSE: 4078 [112ms:225ms] > T15 (11 +0ms): CSS Pass > T15 (11 +0ms): Layout Pass > T15 (12 +0ms): Update bounds > T15 (12 +95ms): Waiting for previous rendering > T15 (108 +0ms): Copy state to render graph > T12 (109 +115ms): Painting > T12 (224 +0ms): Presenting > Counters: > Nodes rendered: 651 > Nodes visited during render: 651 > > Thread dumps show that QuantumRenderer is busy with tasks inside > > at com.sun.prism.impl.BaseMesh.buildPTGeometry(javafx.graphics at 10-internal/BaseMesh.java:584) > at com.sun.prism.impl.BaseMesh.buildGeometry(javafx.graphics at 10-internal/BaseMesh.java:516) > at com.sun.javafx.sg.prism.NGTriangleMesh.validate(javafx.graphics at 10-internal/NGTriangleMesh.java:75) > at com.sun.javafx.sg.prism.NGShape3D.renderMeshView(javafx.graphics at 10-internal/NGShape3D.java:84) > at com.sun.javafx.sg.prism.NGShape3D.renderContent(javafx.graphics at 10-internal/NGShape3D.java:201) > at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal/NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal/NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal/NGGroup.java:270) > at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal/NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal/NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal/NGGroup.java:270) > at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal/NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal/NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal/NGGroup.java:270) > at com.sun.javafx.sg.prism.NGNode.renderCached(javafx.graphics at 10-internal/NGNode.java:2379) > at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal/NGNode.java:2063) > at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal/NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal/NGGroup.java:270) > at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal/NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal/NGNode.java:1964) > at com.sun.javafx.tk.quantum.ViewPainter.doPaint(javafx.graphics at 10-internal/ViewPainter.java:479) > at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(javafx.graphics at 10-internal/ViewPainter.java:328) > at com.sun.javafx.tk.quantum.PresentingPainter.run(javafx.graphics at 10-internal/PresentingPainter.java:91) > at java.util.concurrent.Executors$RunnableAdapter.call(java.base at 10-internal/Executors.java:514) > at java.util.concurrent.FutureTask.runAndReset(java.base at 10-internal/FutureTask.java:305) > at com.sun.javafx.tk.RenderJob.run(javafx.graphics at 10-internal/RenderJob.java:58) > at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 10-internal/ThreadPoolExecutor.java:1135) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 10-internal/ThreadPoolExecutor.java:635) > at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(javafx.graphics at 10-internal/QuantumRenderer.java:125) > at java.lang.Thread.run(java.base at 10-internal/Thread.java:844) > > Does anyone have an idea on how to continue? > > Thanks, > Nir > > >> On Fri, May 4, 2018 at 10:30 AM, Matthew Elliot wrote: >> Hi Pedro, >> >> The first link I have read through many times, it is very useful for ideas >> but doesn't really flesh out or go into much detail on each topic. It also >> comments a few times on the problems we've encountered, 'what costs what' >> is difficult to understand / measure. >> >> The second link I hadn't found my way to and is definitely interesting to >> understand more about how things are working internally - thanks. >> >> Regards, >> Matt >> >> >> On 3 May 2018 at 19:17, Pedro Duque Vieira >> wrote: >> >> > Hi Matthew, >> > >> > On the topic of documents with indications for improving performance. >> > >> > Don't know if you already found it, but there is a draft here (to which >> > I've made a small contribution): >> > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks >> > >> > A bit old though... >> > >> > And here: >> > >> > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ideas >> > >> > >> > -- >> > Pedro Duque Vieira >> > > From kevin.rushforth at oracle.com Mon May 7 23:00:19 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 7 May 2018 16:00:19 -0700 Subject: Announcing EA builds of standalone JavaFX SDK Message-ID: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> I am pleased to announce the first Early Access build of a standalone JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an OpenJDK 11 EA build. If your application is in an unnamed module (i.e., your app is on the classpath), you can run your application as follows, after unzipping the SDK bundle for your platform. $ java --module-path $PATH_TO_FX/javafx-sdk-11 --add-modules=javafx.controls,javafx.fxml MyApp This assumes you don't need media or web. If you do, then add those modules, too. Note that since javafx.web "requires transitive javafx.controls", you can omit javafx.controls if you add javafx.web. If you are running a modular application, then you don't need the "--add-modules" option. Note that this is a stepping stone to javafx modules in a repository like Maven. Please test your applications with the SDK and give us feedback. Thanks. -- Kevin [1] http://jdk.java.net/openjfx/ From prasanta.sadhukhan at oracle.com Tue May 8 05:51:24 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 8 May 2018 11:21:24 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <364b6613-b886-6571-c0f9-1a1bf05dcb96@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: Modified webrev to rename to InteropProviderImpl http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ Regards Prasanta On 5/7/2018 8:35 PM, Kevin Rushforth wrote: > That name seems good to me. > > -- Kevin > > > On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: >> Would InteropProviderImpl sound good? >> >> Regards >> Prasanta >> On 5/7/2018 8:27 PM, Alan Bateman wrote: >>> >>> >>> On 07/05/2018 10:26, Prasanta Sadhukhan wrote: >>>> : >>>> >>>> Modified webrev to use InteropProvider >>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ >>> This looks okay although for consistent then InteropImpl could be >>> renamed too. >>> >>> -Alan >> > From ali.ebrahimi1781 at gmail.com Tue May 8 07:26:21 2018 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 8 May 2018 11:56:21 +0430 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: Hi, What about " jdk.desktop.unsupported" for new module name? On Tue, May 8, 2018 at 10:21 AM, Prasanta Sadhukhan < prasanta.sadhukhan at oracle.com> wrote: > Modified webrev to rename to InteropProviderImpl > > http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ > > Regards > Prasanta > > On 5/7/2018 8:35 PM, Kevin Rushforth wrote: > >> That name seems good to me. >> >> -- Kevin >> >> >> On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: >> >>> Would InteropProviderImpl sound good? >>> >>> Regards >>> Prasanta >>> On 5/7/2018 8:27 PM, Alan Bateman wrote: >>> >>>> >>>> >>>> On 07/05/2018 10:26, Prasanta Sadhukhan wrote: >>>> >>>>> : >>>>> >>>>> Modified webrev to use InteropProvider >>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ >>>>> >>>> This looks okay although for consistent then InteropImpl could be >>>> renamed too. >>>> >>>> -Alan >>>> >>> >>> >> > -- Best Regards, Ali Ebrahimi From johan.vos at gluonhq.com Tue May 8 07:43:22 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 08 May 2018 07:43:22 +0000 Subject: Announcing EA builds of standalone JavaFX SDK In-Reply-To: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> References: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> Message-ID: Hi Kevin, Excellent work. I confirm this is working for me. Java: openjdk 11-ea+12 for Linux App from https://github.com/gluonhq/projavafx9/tree/master/chapter1/HelloEarthRise/src/main/java/projavafx/helloearthrise/ui (on classpath) - Johan On Tue, May 8, 2018 at 1:11 AM Kevin Rushforth wrote: > I am pleased to announce the first Early Access build of a standalone > JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an > OpenJDK 11 EA build. > > If your application is in an unnamed module (i.e., your app is on the > classpath), you can run your application as follows, after unzipping the > SDK bundle for your platform. > > $ java --module-path $PATH_TO_FX/javafx-sdk-11 > --add-modules=javafx.controls,javafx.fxml MyApp > > This assumes you don't need media or web. If you do, then add those > modules, too. Note that since javafx.web "requires transitive > javafx.controls", you can omit javafx.controls if you add javafx.web. > > If you are running a modular application, then you don't need the > "--add-modules" option. > > Note that this is a stepping stone to javafx modules in a repository > like Maven. > > Please test your applications with the SDK and give us feedback. > > Thanks. > > -- Kevin > > [1] http://jdk.java.net/openjfx/ > > From prasanta.sadhukhan at oracle.com Tue May 8 07:53:26 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 8 May 2018 13:23:26 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <69499881-75db-6690-70a9-b485de821084@oracle.com> We have discussed this internally and we believe that "unsupportedness" is the critical property here so it justifies grouping them in the same "unsupported" namespace rather than desktop namespace. Regards Prasanta On 5/8/2018 12:56 PM, Ali Ebrahimi wrote: > Hi, > What about " jdk.desktop.unsupported" for new module name? > > On Tue, May 8, 2018 at 10:21 AM, Prasanta Sadhukhan > > > wrote: > > Modified webrev to rename to InteropProviderImpl > > http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ > > > Regards > Prasanta > > On 5/7/2018 8:35 PM, Kevin Rushforth wrote: > > That name seems good to me. > > -- Kevin > > > On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: > > Would InteropProviderImpl sound good? > > Regards > Prasanta > On 5/7/2018 8:27 PM, Alan Bateman wrote: > > > > On 07/05/2018 10:26, Prasanta Sadhukhan wrote: > > : > > Modified webrev to use InteropProvider > http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ > > > This looks okay although for consistent then > InteropImpl could be renamed too. > > -Alan > > > > > > > > -- > > Best Regards, > Ali Ebrahimi From Alan.Bateman at oracle.com Tue May 8 10:31:14 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 8 May 2018 11:31:14 +0100 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> 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 ambarish.rapte at oracle.com Tue May 8 10:59:17 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Tue, 8 May 2018 03:59:17 -0700 (PDT) Subject: [11] RFR JDK-8198602 : [TestBug] test.javafx.css.StylesheetTest logs IllegalArgumentException Message-ID: <6900fab5-ff10-4ffd-9b27-d0417155c0d8@default> Hi Kevin & Ajit, Please review this small fix, Bug: https://bugs.openjdk.java.net/browse/JDK-8198602 Webrev: http://cr.openjdk.java.net/~arapte/fx/8198602/webrev.00/ Regards, Ambarish From paulrussell70 at gmail.com Tue May 8 11:45:37 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Tue, 8 May 2018 12:45:37 +0100 Subject: Announcing EA builds of standalone JavaFX SDK Message-ID: Excellent! I'll try to get this working for our game later in the week. Best, Paul From johnvalrose at gmail.com Tue May 8 11:50:02 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Tue, 8 May 2018 21:50:02 +1000 Subject: Announcing EA builds of standalone JavaFX SDK In-Reply-To: References: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> Message-ID: <9C21CC0A-A14D-4300-85A9-32C95C3DB3CE@gmail.com> Thanks very much Kevin. This is a great step forward and will make all of our lives easier. Graciously, John-Val Rose > On 8 May 2018, at 17:43, Johan Vos wrote: > > Hi Kevin, > > Excellent work. > I confirm this is working for me. > > Java: openjdk 11-ea+12 for Linux > App from > https://github.com/gluonhq/projavafx9/tree/master/chapter1/HelloEarthRise/src/main/java/projavafx/helloearthrise/ui > (on > classpath) > > - Johan > > On Tue, May 8, 2018 at 1:11 AM Kevin Rushforth > wrote: > >> I am pleased to announce the first Early Access build of a standalone >> JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an >> OpenJDK 11 EA build. >> >> If your application is in an unnamed module (i.e., your app is on the >> classpath), you can run your application as follows, after unzipping the >> SDK bundle for your platform. >> >> $ java --module-path $PATH_TO_FX/javafx-sdk-11 >> --add-modules=javafx.controls,javafx.fxml MyApp >> >> This assumes you don't need media or web. If you do, then add those >> modules, too. Note that since javafx.web "requires transitive >> javafx.controls", you can omit javafx.controls if you add javafx.web. >> >> If you are running a modular application, then you don't need the >> "--add-modules" option. >> >> Note that this is a stepping stone to javafx modules in a repository >> like Maven. >> >> Please test your applications with the SDK and give us feedback. >> >> Thanks. >> >> -- Kevin >> >> [1] http://jdk.java.net/openjfx/ >> >> From mp at jugs.org Tue May 8 12:01:05 2018 From: mp at jugs.org (Michael Paus) Date: Tue, 8 May 2018 14:01:05 +0200 Subject: Announcing EA builds of standalone JavaFX SDK In-Reply-To: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> References: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> Message-ID: Hi Kevin, that's a great achievement. I have a few questions/remarks though: 1. On the announcement page I assume the license agreement should not read "These binaries are provided under the GNU General Public License ." but instead should read "These early-access, open-source builds are provided under the GNU General Public License, version?2, with the Classpath Exception ." With or without classpath exception makes a big difference. (The actual link is already the same anyway.) 2. I can confirm that a simple program from the command line works nicely on my MacBook Pro Retina but I had to add "/lib" to the module path to get it working. 3. How do you properly configure an Eclipse (the latest 4.7.3a) project to use this module path. Adding the OpenJDK was no problem but how do you add the module path for JavaFX? I failed on that. Michael Am 08.05.18 um 01:00 schrieb Kevin Rushforth: > I am pleased to announce the first Early Access build of a standalone > JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an > OpenJDK 11 EA build. > > If your application is in an unnamed module (i.e., your app is on the > classpath), you can run your application as follows, after unzipping > the SDK bundle for your platform. > > $ java --module-path $PATH_TO_FX/javafx-sdk-11 > --add-modules=javafx.controls,javafx.fxml MyApp > > This assumes you don't need media or web. If you do, then add those > modules, too. Note that since javafx.web "requires transitive > javafx.controls", you can omit javafx.controls if you add javafx.web. > > If you are running a modular application, then you don't need the > "--add-modules" option. > > Note that this is a stepping stone to javafx modules in a repository > like Maven. > > Please test your applications with the SDK and give us feedback. > > Thanks. > > -- Kevin > > [1] http://jdk.java.net/openjfx/ > From tom.schindl at bestsolution.at Tue May 8 12:27:05 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 8 May 2018 14:27:05 +0200 Subject: Announcing EA builds of standalone JavaFX SDK In-Reply-To: References: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> Message-ID: <8db06510-51a9-49c0-ebdc-843d1c939ab5@bestsolution.at> [...] > 3. How do you properly configure an Eclipse (the latest 4.7.3a) project > to use this module path. Adding the OpenJDK was no problem but how do > you add the module path for JavaFX? I failed on that. > You just open the Java Build Path-Properties-Page on the project and add the external jars, not? Tom From paulrussell70 at gmail.com Tue May 8 12:37:48 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Tue, 8 May 2018 13:37:48 +0100 Subject: Announcing EA builds of standalone JavaFX SDK Message-ID: V. pleased to say it's working for me. It builds using our current Maven build ( which is targeted in Maven at JDK 9) org.apache.maven.plugins maven-compiler-plugin 3.6.2 1.9 1.9 -Xlint:unchecked Trying to set a 1.11 release will give the Maven error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.6.2:compile (default-compile) on project KattRunOnTheTide: Fatal error compiling: error: invalid target release: 1.11 -> [Help 1] ----- Running under Win10 via a BAT file: I've made sure OpenJDK is the only JDK on the system path. I built using Maven then Shade into a single Jar. For the purposes of this test, I've made an explicit call to the VM from a batch file on Win 10 64 bit. "C:\Program Files\Java\jdk-11\bin\java" -Xms2500m -Xmx4500m -jar -Djavafx.animation.fullspeed=true runTime.jar pause (Normally I wrap this into an .EXE. using Launch4J after going through Proguard.) ================================================================ I cannot build the project under Intellij: I get a Jetbrains error: Error:Internal error: (java.net.MalformedURLException) unknown protocol: jrt java.net.MalformedURLException: unknown protocol: jrt at java.net.URL.(URL.java:421) at java.net.URL.(URL.java:310) at java.net.URL.(URL.java:333) at com.intellij.compiler.instrumentation.InstrumentationClassFinder.createJDKPlatformUrl(InstrumentationClassFinder.java:61) at org.jetbrains.jps.incremental.instrumentation.ClassProcessingBuilder.createInstrumentationClassFinder(ClassProcessingBuilder.java:125) at org.jetbrains.jps.incremental.instrumentation.ClassProcessingBuilder.build(ClassProcessingBuilder.java:93) at org.jetbrains.jps.incremental.IncProjectBuilder.runModuleLevelBuilders(IncProjectBuilder.java:1246) at org.jetbrains.jps.incremental.IncProjectBuilder.runBuildersForChunk(IncProjectBuilder.java:923) at org.jetbrains.jps.incremental.IncProjectBuilder.buildTargetsChunk(IncProjectBuilder.java:995) at org.jetbrains.jps.incremental.IncProjectBuilder.buildChunkIfAffected(IncProjectBuilder.java:886) at org.jetbrains.jps.incremental.IncProjectBuilder.buildChunks(IncProjectBuilder.java:719) at org.jetbrains.jps.incremental.IncProjectBuilder.runBuild(IncProjectBuilder.java:371) at org.jetbrains.jps.incremental.IncProjectBuilder.build(IncProjectBuilder.java:178) at org.jetbrains.jps.cmdline.BuildRunner.runBuild(BuildRunner.java:138) at org.jetbrains.jps.cmdline.BuildSession.runBuild(BuildSession.java:308) at org.jetbrains.jps.cmdline.BuildSession.run(BuildSession.java:138) at org.jetbrains.jps.cmdline.BuildMain$MyMessageHandler.lambda$channelRead0$0(BuildMain.java:235) at org.jetbrains.jps.service.impl.SharedThreadPoolImpl.lambda$executeOnPooledThread$0(SharedThreadPoolImpl.java:42) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Please perform full project rebuild (Build | Rebuild Project) ================================================================== I added a check in the code directly: the result in the log file: 2018-05-08 :13:16:28 : INFO : techtalix.app.StartGame start : JAVA VERSION 11-ea But running from the BAT file directly after building with Maven- I only had one error during game play: I don't get this error normally. In my code, I've just checking some game tiles, and in this case one is clearly null. Exception in thread "JavaFX Application Thread" java.lang.NullPointerException at com.techtalix.player.PlayerController.lambda$new$0(PlayerController.java:114) at javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218) at javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) at javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) at javafx.base/javafx.event.Event.fireEvent(Event.java:198) at javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3851) at javafx.graphics/javafx.scene.Scene$MouseHandler.access$1200(Scene.java:3579) at javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1849) at javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2588) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:397) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:295) at java.base/java.security.AccessController.doPrivileged(Native Method) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(GlassViewEventHandler.java:434) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:389) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:433) at javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:556) at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:942) at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:175) at java.base/java.lang.Thread.run(Thread.java:832) I hope this helps. Looking forwards to a pure Maven build. Best, Paul On 8 May 2018 at 11:30, 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. Announcing EA builds of standalone JavaFX SDK (Kevin Rushforth) > 2. Re: [11] RFR JDK-8202199 : Provide public, unsupported API > for FX Swing interop (Prasanta Sadhukhan) > 3. Re: [11] RFR JDK-8202199 : Provide public, unsupported API > for FX Swing interop (Ali Ebrahimi) > 4. Re: Announcing EA builds of standalone JavaFX SDK (Johan Vos) > 5. Re: [11] RFR JDK-8202199 : Provide public, unsupported API > for FX Swing interop (Prasanta Sadhukhan) > 6. Re: [11] RFR JDK-8202199 : Provide public, unsupported API > for FX Swing interop (Alan Bateman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 May 2018 16:00:19 -0700 > From: Kevin Rushforth > To: "openjfx-dev at openjdk.java.net" > Subject: Announcing EA builds of standalone JavaFX SDK > Message-ID: <8ae613b7-bac6-fa44-94e4-7490b07269ef at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > I am pleased to announce the first Early Access build of a standalone > JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an > OpenJDK 11 EA build. > > If your application is in an unnamed module (i.e., your app is on the > classpath), you can run your application as follows, after unzipping the > SDK bundle for your platform. > > $ java --module-path $PATH_TO_FX/javafx-sdk-11 > --add-modules=javafx.controls,javafx.fxml MyApp > > This assumes you don't need media or web. If you do, then add those > modules, too. Note that since javafx.web "requires transitive > javafx.controls", you can omit javafx.controls if you add javafx.web. > > If you are running a modular application, then you don't need the > "--add-modules" option. > > Note that this is a stepping stone to javafx modules in a repository > like Maven. > > Please test your applications with the SDK and give us feedback. > > Thanks. > > -- Kevin > > [1] http://jdk.java.net/openjfx/ > > > > ------------------------------ > > Message: 2 > Date: Tue, 8 May 2018 11:21:24 +0530 > From: Prasanta Sadhukhan > To: Kevin Rushforth , Alan Bateman > , Phil Race , > "swing-dev at openjdk.java.net" , > "openjfx-dev at openjdk.java.net Mailing" < > openjfx-dev at openjdk.java.net>, > mandy chung , alex.buckley at oracle.com > Subject: Re: [11] RFR JDK-8202199 : Provide public, unsupported API > for FX Swing interop > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > Modified webrev to rename to InteropProviderImpl > > http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ > > Regards > Prasanta > On 5/7/2018 8:35 PM, Kevin Rushforth wrote: > > That name seems good to me. > > > > -- Kevin > > > > > > On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: > >> Would InteropProviderImpl sound good? > >> > >> Regards > >> Prasanta > >> On 5/7/2018 8:27 PM, Alan Bateman wrote: > >>> > >>> > >>> On 07/05/2018 10:26, Prasanta Sadhukhan wrote: > >>>> : > >>>> > >>>> Modified webrev to use InteropProvider > >>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ > >>> This looks okay although for consistent then InteropImpl could be > >>> renamed too. > >>> > >>> -Alan > >> > > > > > > ------------------------------ > > Message: 3 > Date: Tue, 8 May 2018 11:56:21 +0430 > From: Ali Ebrahimi > To: Prasanta Sadhukhan > Cc: "openjfx-dev at openjdk.java.net Mailing" > , "swing-dev at openjdk.java.net" > > Subject: Re: [11] RFR JDK-8202199 : Provide public, unsupported API > for FX Swing interop > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi, > What about " jdk.desktop.unsupported" for new module name? > > On Tue, May 8, 2018 at 10:21 AM, Prasanta Sadhukhan < > prasanta.sadhukhan at oracle.com> wrote: > > > Modified webrev to rename to InteropProviderImpl > > > > http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ > > > > Regards > > Prasanta > > > > On 5/7/2018 8:35 PM, Kevin Rushforth wrote: > > > >> That name seems good to me. > >> > >> -- Kevin > >> > >> > >> On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: > >> > >>> Would InteropProviderImpl sound good? > >>> > >>> Regards > >>> Prasanta > >>> On 5/7/2018 8:27 PM, Alan Bateman wrote: > >>> > >>>> > >>>> > >>>> On 07/05/2018 10:26, Prasanta Sadhukhan wrote: > >>>> > >>>>> : > >>>>> > >>>>> Modified webrev to use InteropProvider > >>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ > >>>>> > >>>> This looks okay although for consistent then InteropImpl could be > >>>> renamed too. > >>>> > >>>> -Alan > >>>> > >>> > >>> > >> > > > > > -- > > Best Regards, > Ali Ebrahimi > > > ------------------------------ > > Message: 4 > Date: Tue, 08 May 2018 07:43:22 +0000 > From: Johan Vos > To: Kevin Rushforth > Cc: "openjfx-dev at openjdk.java.net" > Subject: Re: Announcing EA builds of standalone JavaFX SDK > Message-ID: > RxhKWJJPw at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Kevin, > > Excellent work. > I confirm this is working for me. > > Java: openjdk 11-ea+12 for Linux > App from > https://github.com/gluonhq/projavafx9/tree/master/ > chapter1/HelloEarthRise/src/main/java/projavafx/helloearthrise/ui > (on > classpath) > > - Johan > > On Tue, May 8, 2018 at 1:11 AM Kevin Rushforth > > wrote: > > > I am pleased to announce the first Early Access build of a standalone > > JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an > > OpenJDK 11 EA build. > > > > If your application is in an unnamed module (i.e., your app is on the > > classpath), you can run your application as follows, after unzipping the > > SDK bundle for your platform. > > > > $ java --module-path $PATH_TO_FX/javafx-sdk-11 > > --add-modules=javafx.controls,javafx.fxml MyApp > > > > This assumes you don't need media or web. If you do, then add those > > modules, too. Note that since javafx.web "requires transitive > > javafx.controls", you can omit javafx.controls if you add javafx.web. > > > > If you are running a modular application, then you don't need the > > "--add-modules" option. > > > > Note that this is a stepping stone to javafx modules in a repository > > like Maven. > > > > Please test your applications with the SDK and give us feedback. > > > > Thanks. > > > > -- Kevin > > > > [1] http://jdk.java.net/openjfx/ > > > > > > > ------------------------------ > > Message: 5 > Date: Tue, 8 May 2018 13:23:26 +0530 > From: Prasanta Sadhukhan > To: Ali Ebrahimi > Cc: "openjfx-dev at openjdk.java.net Mailing" > , "swing-dev at openjdk.java.net" > > Subject: Re: [11] RFR JDK-8202199 : Provide public, unsupported API > for FX Swing interop > Message-ID: <69499881-75db-6690-70a9-b485de821084 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > We have discussed this internally and we believe that "unsupportedness" > is the critical property here so it justifies grouping them in the same > "unsupported" namespace rather than desktop namespace. > > Regards > Prasanta > On 5/8/2018 12:56 PM, Ali Ebrahimi wrote: > > Hi, > > What about " jdk.desktop.unsupported" for new module name? > > > > On Tue, May 8, 2018 at 10:21 AM, Prasanta Sadhukhan > > > > > wrote: > > > > Modified webrev to rename to InteropProviderImpl > > > > http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ > > > > > > Regards > > Prasanta > > > > On 5/7/2018 8:35 PM, Kevin Rushforth wrote: > > > > That name seems good to me. > > > > -- Kevin > > > > > > On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: > > > > Would InteropProviderImpl sound good? > > > > Regards > > Prasanta > > On 5/7/2018 8:27 PM, Alan Bateman wrote: > > > > > > > > On 07/05/2018 10:26, Prasanta Sadhukhan wrote: > > > > : > > > > Modified webrev to use InteropProvider > > http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ > > > > > > > This looks okay although for consistent then > > InteropImpl could be renamed too. > > > > -Alan > > > > > > > > > > > > > > > > -- > > > > Best Regards, > > Ali Ebrahimi > > > > ------------------------------ > > Message: 6 > Date: Tue, 8 May 2018 11:31:14 +0100 > From: Alan Bateman > To: Prasanta Sadhukhan , Kevin > Rushforth , Phil Race > , "swing-dev at openjdk.java.net" > , "openjfx-dev at openjdk.java.net > Mailing" > , mandy chung < > mandy.chung at oracle.com>, > alex.buckley at oracle.com > Subject: Re: [11] RFR JDK-8202199 : Provide public, unsupported API > for FX Swing interop > Message-ID: <716b085e-23b0-0443-e34b-e0bc5c85ebf5 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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 > > > End of openjfx-dev Digest, Vol 78, Issue 13 > ******************************************* > From mp at jugs.org Tue May 8 12:39:11 2018 From: mp at jugs.org (Michael Paus) Date: Tue, 8 May 2018 14:39:11 +0200 Subject: Announcing EA builds of standalone JavaFX SDK In-Reply-To: <8db06510-51a9-49c0-ebdc-843d1c939ab5@bestsolution.at> References: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> <8db06510-51a9-49c0-ebdc-843d1c939ab5@bestsolution.at> Message-ID: <1254a47f-0812-be0d-e831-de31ded1b689@jugs.org> Am 08.05.18 um 14:27 schrieb Tom Schindl: > [...] > >> 3. How do you properly configure an Eclipse (the latest 4.7.3a) project >> to use this module path. Adding the OpenJDK was no problem but how do >> you add the module path for JavaFX? I failed on that. >> > You just open the Java Build Path-Properties-Page on the project and add > the external jars, not? > > Tom That's one of the ways I tried it but ... 1. is that the intended way of doing it? On the command line you just specify a single folder. 2. I did this and it resolved all dependencies at compile time but I got an exception at runtime Error occurred during initialization of boot layer java.lang.module.FindException: Module javafx.fxml not found although I also added --add-modules=javafx.fxml,javafx.controls,javafx.web,javafx.media as VM arguments. From ooo_saturn7 at mail.ru Tue May 8 12:40:35 2018 From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=) Date: Tue, 08 May 2018 15:40:35 +0300 Subject: =?UTF-8?B?VGV4dEFyZWEgZG9lc24ndCBzY3JvbGwgdG8gYm90dG9tIHdoZW4gdGV4dHMg?= =?UTF-8?B?YmVjb21lcyBsb25nIGFuZCB2ZXJ0aWNhbCBzY3JvbGxiYXIgYXBwZWFycyBK?= =?UTF-8?B?REstODE4OTczMg==?= Message-ID: <1525783235.131991667@f479.i.mail.ru> More then half a year ago I opened an issue https://bugs.openjdk.java.net/browse/JDK-8189732 ? that TextArea doesn't scroll to bottom when texts becomes long and vertical scrollbar appears. The issue is still not resolved and even fix version is not defined. Could anyone say the reason of this? It is very strange as such issues must be resolved very quickly. -- Alex Sviridov From mp at jugs.org Tue May 8 12:47:35 2018 From: mp at jugs.org (Michael Paus) Date: Tue, 8 May 2018 14:47:35 +0200 Subject: Announcing EA builds of standalone JavaFX SDK In-Reply-To: References: Message-ID: <3e56d38b-adb1-bb77-9cbf-a53e7f0b8d73@jugs.org> Am 08.05.18 um 14:37 schrieb Paul Ray Russell: > V. pleased to say it's working for me. It builds using our current Maven > build ( which is targeted in Maven at JDK 9) > > > org.apache.maven.plugins > maven-compiler-plugin > 3.6.2 > > 1.9 > 1.9 > > -Xlint:unchecked > > > > > Trying to set a 1.11 release will give the Maven error: > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.6.2:compile > (default-compile) on project KattRunOnTheTide: Fatal error compiling: > error: invalid target release: 1.11 -> [Help 1] Have you tried using the latest Maven compiler plugin 3.7.0 ? From kevin.rushforth at oracle.com Tue May 8 15:17:58 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 8 May 2018 08:17:58 -0700 Subject: Fwd: [11] RFR: 8202553: Update FXLauncherTest as part of removing JavaFX from JDK In-Reply-To: <1ec3d597-ad9b-ca6f-4277-b2e9e8f90f4b@oracle.com> References: <1ec3d597-ad9b-ca6f-4277-b2e9e8f90f4b@oracle.com> Message-ID: <7ca456a8-9b41-996b-fe53-822a04a741c0@oracle.com> FYI... -- Kevin -------- Forwarded Message -------- Subject: [11] RFR: 8202553: Update FXLauncherTest as part of removing JavaFX from JDK Date: Tue, 8 May 2018 08:15:48 -0700 From: Kevin Rushforth To: core-libs-dev at openjdk.java.net , Kumar Srinivasan Please review the following test fix: https://bugs.openjdk.java.net/browse/JDK-8202553 http://cr.openjdk.java.net/~kcr/8202553/webrev.00/ This modifies the existing FXLauncherTest as follows: 1. Reverse the check for the presence of the javafx.application.Application class and fail the test if present 2. Create a "mock" javafx.graphics module with a mocked up version of the few classes needed to validate the FX launcher functionality 3. Remove the "intermittent" and "headful" keywords, since neither apply any more 4. Remove the test from the problem list Thanks. -- Kevin From kevin.rushforth at oracle.com Tue May 8 15:19:45 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 8 May 2018 08:19:45 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <69499881-75db-6690-70a9-b485de821084@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> <69499881-75db-6690-70a9-b485de821084@oracle.com> Message-ID: <363e9216-5f1e-4ca2-4f47-b2b09d6d55ea@oracle.com> Exactly. The current naming was recommended by the jigsaw team, and I fully agree. -- Kevin On 5/8/2018 12:53 AM, Prasanta Sadhukhan wrote: > We have discussed this internally and we believe that > "unsupportedness" is the critical property here so it justifies > grouping them in the same "unsupported" namespace rather than desktop > namespace. > > Regards > Prasanta > On 5/8/2018 12:56 PM, Ali Ebrahimi wrote: >> Hi, >> What about " jdk.desktop.unsupported" for new module name? >> >> On Tue, May 8, 2018 at 10:21 AM, Prasanta Sadhukhan >> > > wrote: >> >> ??? Modified webrev to rename to InteropProviderImpl >> >> ??? http://cr.openjdk.java.net/~psadhukhan/fxswing.10/ >> ??? >> >> ??? Regards >> ??? Prasanta >> >> ??? On 5/7/2018 8:35 PM, Kevin Rushforth wrote: >> >> ??????? That name seems good to me. >> >> ??????? -- Kevin >> >> >> ??????? On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote: >> >> ??????????? Would InteropProviderImpl sound good? >> >> ??????????? Regards >> ??????????? Prasanta >> ??????????? On 5/7/2018 8:27 PM, Alan Bateman wrote: >> >> >> >> ??????????????? On 07/05/2018 10:26, Prasanta Sadhukhan wrote: >> >> ??????????????????? : >> >> ??????????????????? Modified webrev to use InteropProvider >> http://cr.openjdk.java.net/~psadhukhan/fxswing.9/ >> >> >> ??????????????? This looks okay although for consistent then >> ??????????????? InteropImpl could be renamed too. >> >> ??????????????? -Alan >> >> >> >> >> >> >> >> -- >> >> Best Regards, >> Ali Ebrahimi > From kevin.rushforth at oracle.com Tue May 8 15:23:35 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 8 May 2018 08:23:35 -0700 Subject: Announcing EA builds of standalone JavaFX SDK In-Reply-To: References: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> Message-ID: <18bf002c-da85-3018-56fa-10a4f8f2e10a@oracle.com> On 5/8/2018 5:01 AM, Michael Paus wrote: > Hi Kevin, > that's a great achievement. I have a few questions/remarks though: > > 1. On the announcement page I assume the license agreement should not > read > "These binaries are provided under the GNU General Public License > ." > but instead should read > "These early-access, open-source builds are provided under the GNU > General Public License, version?2, with the Classpath Exception > ." > With or without classpath exception makes a big difference. (The > actual link is already the same anyway.) I will get this fixed to match the JDK 11 EA text. > 2. I can confirm that a simple program from the command line works > nicely on my MacBook Pro Retina but I had to add "/lib" to the module > path to get it working. Yes, adding the javafx-sdk-11/lib to the module-path is a required step. Thanks. -- Kevin > > 3. How do you properly configure an Eclipse (the latest 4.7.3a) > project to use this module path. Adding the OpenJDK was no problem but > how do you add the module path for JavaFX? I failed on that. > > Michael > > Am 08.05.18 um 01:00 schrieb Kevin Rushforth: >> I am pleased to announce the first Early Access build of a standalone >> JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an >> OpenJDK 11 EA build. >> >> If your application is in an unnamed module (i.e., your app is on the >> classpath), you can run your application as follows, after unzipping >> the SDK bundle for your platform. >> >> $ java --module-path $PATH_TO_FX/javafx-sdk-11 >> --add-modules=javafx.controls,javafx.fxml MyApp >> >> This assumes you don't need media or web. If you do, then add those >> modules, too. Note that since javafx.web "requires transitive >> javafx.controls", you can omit javafx.controls if you add javafx.web. >> >> If you are running a modular application, then you don't need the >> "--add-modules" option. >> >> Note that this is a stepping stone to javafx modules in a repository >> like Maven. >> >> Please test your applications with the SDK and give us feedback. >> >> Thanks. >> >> -- Kevin >> >> [1] http://jdk.java.net/openjfx/ >> > From jonathan at jonathangiles.net Tue May 8 17:44:09 2018 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Tue, 08 May 2018 17:44:09 +0000 Subject: Announcing EA builds of standalone JavaFX SDK In-Reply-To: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> References: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> Message-ID: Congrats to Kevin and team on this milestone! -- Jonathan (Tapped on a touch device) On Mon, 7 May 2018, 4:01 PM Kevin Rushforth, wrote: > I am pleased to announce the first Early Access build of a standalone > JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an > OpenJDK 11 EA build. > > If your application is in an unnamed module (i.e., your app is on the > classpath), you can run your application as follows, after unzipping the > SDK bundle for your platform. > > $ java --module-path $PATH_TO_FX/javafx-sdk-11 > --add-modules=javafx.controls,javafx.fxml MyApp > > This assumes you don't need media or web. If you do, then add those > modules, too. Note that since javafx.web "requires transitive > javafx.controls", you can omit javafx.controls if you add javafx.web. > > If you are running a modular application, then you don't need the > "--add-modules" option. > > Note that this is a stepping stone to javafx modules in a repository > like Maven. > > Please test your applications with the SDK and give us feedback. > > Thanks. > > -- Kevin > > [1] http://jdk.java.net/openjfx/ > > From nlisker at gmail.com Tue May 8 21:55:22 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 9 May 2018 00:55:22 +0300 Subject: Announcing EA builds of standalone JavaFX SDK In-Reply-To: <1254a47f-0812-be0d-e831-de31ded1b689@jugs.org> References: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> <8db06510-51a9-49c0-ebdc-843d1c939ab5@bestsolution.at> <1254a47f-0812-be0d-e831-de31ded1b689@jugs.org> Message-ID: Thanks Kevin, that's good to hear. Michael, adding the external jars as single entries is the simplest and most granular way, but you can also define a library from those jars and then add that single library to any project: 1. Add Library... 2. User Library 3. User Libraries... 4. New... (give it a name) 5. Add External JARs... (add all the jars) 6. OK/Apply everything. This creates a single entry in the .classpath: This should be the parallel to specifying a single folder from the command line. As for the runtime issue, is it finding the other modules? - Nir On Tue, May 8, 2018 at 3:39 PM, Michael Paus wrote: > Am 08.05.18 um 14:27 schrieb Tom Schindl: > > [...] >> >> 3. How do you properly configure an Eclipse (the latest 4.7.3a) project >>> to use this module path. Adding the OpenJDK was no problem but how do >>> you add the module path for JavaFX? I failed on that. >>> >>> You just open the Java Build Path-Properties-Page on the project and add >> the external jars, not? >> >> Tom >> > > That's one of the ways I tried it but ... > > 1. is that the intended way of doing it? On the command line you just > specify a single folder. > > 2. I did this and it resolved all dependencies at compile time but I got > an exception at runtime > > Error occurred during initialization of boot layer > java.lang.module.FindException: Module javafx.fxml not found > > although I also added > > --add-modules=javafx.fxml,javafx.controls,javafx.web,javafx.media > > as VM arguments. > > From mp at jugs.org Tue May 8 22:35:32 2018 From: mp at jugs.org (Michael Paus) Date: Wed, 9 May 2018 00:35:32 +0200 Subject: Announcing EA builds of standalone JavaFX SDK In-Reply-To: References: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> <8db06510-51a9-49c0-ebdc-843d1c939ab5@bestsolution.at> <1254a47f-0812-be0d-e831-de31ded1b689@jugs.org> Message-ID: Am 08.05.18 um 23:55 schrieb Nir Lisker: > Thanks Kevin, that's good to hear. > > Michael, adding the external jars as single entries is the simplest > and most granular way, but you can also define a library from those > jars and then add that single library to any project: > > 1. Add Library... > 2. User Library > 3. User Libraries... > 4. New... (give it a name) > 5. Add External JARs... (add all the jars) > 6. OK/Apply everything. > > This creates a single entry in the .classpath: > > ? ? path="org.eclipse.jdt.USER_LIBRARY/library_name"> > > This should be the parallel to specifying a single folder from the > command line. I'll give that a try in the morning. > > As for the runtime issue, is it finding the other modules? No, if I do not specify javafx.fxml it complains about the next one. I also tried moving all jars to the classpath instead of the module path. Again this resolves the compile time dependencies but results in an error at runtime. Since Java 9 Eclipse has really become a mess. > > - Nir > > On Tue, May 8, 2018 at 3:39 PM, Michael Paus > wrote: > > Am 08.05.18 um 14:27 schrieb Tom Schindl: > > [...] > > 3. How do you properly configure an Eclipse (the latest > 4.7.3a) project > to use this module path. Adding the OpenJDK was no problem > but how do > you add the module path for JavaFX? I failed on that. > > You just open the Java Build Path-Properties-Page on the > project and add > the external jars, not? > > Tom > > > That's one of the ways I tried it but ... > > 1. is that the intended way of doing it? On the command line you > just specify a single folder. > > 2. I did this and it resolved all dependencies at compile time but > I got an exception at runtime > > Error occurred during initialization of boot layer > java.lang.module.FindException: Module javafx.fxml not found > > although I also added > > --add-modules=javafx.fxml,javafx.controls,javafx.web,javafx.media > > as VM arguments. > > From nlisker at gmail.com Tue May 8 23:15:13 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 9 May 2018 02:15:13 +0300 Subject: Paint Phase Debugging / Performance In-Reply-To: References: Message-ID: Hi Matthew, This is a typical pulse, which indeed cases the effect of low FPS, and that's what I'm trying to solve. * Cache hints are ignored for 3D (but I tried anyway). * -Dprism.showdirty and printrendergraph also don't work for 3D scenes (though I can get an approximation with a 2D scene). * There are no effects. I'm working with Mission Control already, most of the instances in the GC class histogram are related to animation classes: InterpolationInterval$TangentDoubleInterpolationInterval and NumberTangentInterpolator. Looks like all all the discussed difficulties with diagnostics are enhanced when it comes to 3D. Will have to dig deep on this one. Thanks, Nir On Mon, May 7, 2018 at 9:07 PM, Matthew Elliot < matthew.james.elliot at gmail.com> wrote: > Hey Nir, > > I?m not sure if I can offer much support as I haven?t been into the 3D > world but just to clarify, is it one pulse after another with long wait, > paint phases? From what I?ve seen personally if you have painting of 100+ > milliseconds on every pulse you will be in big trouble / laggy as. > > On a one-off pulse like building a scene the first time I would say it is > fine but regular paints that are longer are going to cause issues from my > experience. > > Did you try profiling with mission controller to look at what garbage is > being created / what hot methods there? Maybe it points you in a better > direction / at least rule out your own code. > > With animations I guess you set cache hints already? > > Make sure you don?t have any effects on the animation as well, a Gaussian > blur blend/drop shadow on an animation killed it for me. > You can also try -Dprism.disableEffects= true to rule it out. > You can also enable the prism option to show what is being painted on each > pulse as an overlay. -Dprism.showdirty and there is another I forget to > show how many times it was painted. (Not that your whole scene is painted > when you expect a small part of it) > > Or some trial and error with the prism flags here to try narrow it down - > Just open PrismSettings.java in your IDE or web browser. > > Code explains them better than most posts I?ve seen. > > Good luck. > Matt > > Sent from my phone. > > On 7/05/2018, at 2:36 PM, Nir Lisker wrote: > > Hi, > > I'm having a performance issue myself. I'm using animations on 3D models > (in a 3D subscene) and when there are "too many" models the QuantumRenderer > thread is running 100% of the time and utilizing 20-25% of the CPU, though > the OS reports that overall all cores are at ~40%. The application is using > the d3d pipeline. > > A typical pulse is > > PULSE: 4078 [112ms:225ms] > T15 (11 +0ms): CSS Pass > T15 (11 +0ms): Layout Pass > T15 (12 +0ms): Update bounds > T15 (12 +95ms): Waiting for previous rendering > T15 (108 +0ms): Copy state to render graph > T12 (109 +115ms): Painting > T12 (224 +0ms): Presenting > Counters: > Nodes rendered: 651 > Nodes visited during render: 651 > > Thread dumps show that QuantumRenderer is busy with tasks inside > > at com.sun.prism.impl.BaseMesh.buildPTGeometry(javafx. > graphics at 10-internal/BaseMesh.java:584) > at com.sun.prism.impl.BaseMesh.buildGeometry(javafx.graphics@ > 10-internal/BaseMesh.java:516) > at com.sun.javafx.sg.prism.NGTriangleMesh.validate( > javafx.graphics at 10-internal/NGTriangleMesh.java:75) > at com.sun.javafx.sg.prism.NGShape3D.renderMeshView( > javafx.graphics at 10-internal/NGShape3D.java:84) > at com.sun.javafx.sg.prism.NGShape3D.renderContent( > javafx.graphics at 10-internal/NGShape3D.java:201) > at com.sun.javafx.sg.prism.NGNode.doRender(javafx. > graphics at 10-internal/NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@ > 10-internal/NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx. > graphics at 10-internal/NGGroup.java:270) > at com.sun.javafx.sg.prism.NGNode.doRender(javafx. > graphics at 10-internal/NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@ > 10-internal/NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx. > graphics at 10-internal/NGGroup.java:270) > at com.sun.javafx.sg.prism.NGNode.doRender(javafx. > graphics at 10-internal/NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@ > 10-internal/NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx. > graphics at 10-internal/NGGroup.java:270) > at com.sun.javafx.sg.prism.NGNode.renderCached(javafx. > graphics at 10-internal/NGNode.java:2379) > at com.sun.javafx.sg.prism.NGNode.doRender(javafx. > graphics at 10-internal/NGNode.java:2063) > at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@ > 10-internal/NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx. > graphics at 10-internal/NGGroup.java:270) > at com.sun.javafx.sg.prism.NGNode.doRender(javafx. > graphics at 10-internal/NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@ > 10-internal/NGNode.java:1964) > at com.sun.javafx.tk.quantum.ViewPainter.doPaint(javafx. > graphics at 10-internal/ViewPainter.java:479) > at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(javafx. > graphics at 10-internal/ViewPainter.java:328) > at com.sun.javafx.tk.quantum.PresentingPainter.run(javafx. > graphics at 10-internal/PresentingPainter.java:91) > at java.util.concurrent.Executors$RunnableAdapter. > call(java.base at 10-internal/Executors.java:514) > at java.util.concurrent.FutureTask.runAndReset(java. > base at 10-internal/FutureTask.java:305) > at com.sun.javafx.tk.RenderJob.run(javafx.graphics at 10- > internal/RenderJob.java:58) > at java.util.concurrent.ThreadPoolExecutor.runWorker( > java.base at 10-internal/ThreadPoolExecutor.java:1135) > at java.util.concurrent.ThreadPoolExecutor$Worker.run( > java.base at 10-internal/ThreadPoolExecutor.java:635) > at com.sun.javafx.tk.quantum.QuantumRenderer$ > PipelineRunnable.run(javafx.graphics at 10-internal/QuantumRenderer.java:125) > at java.lang.Thread.run(java.base at 10-internal/Thread.java:844) > > Does anyone have an idea on how to continue? > > Thanks, > Nir > > > On Fri, May 4, 2018 at 10:30 AM, Matthew Elliot < > matthew.james.elliot at gmail.com> wrote: > >> Hi Pedro, >> >> The first link I have read through many times, it is very useful for ideas >> but doesn't really flesh out or go into much detail on each topic. It also >> comments a few times on the problems we've encountered, 'what costs what' >> is difficult to understand / measure. >> >> The second link I hadn't found my way to and is definitely interesting to >> understand more about how things are working internally - thanks. >> >> Regards, >> Matt >> >> >> On 3 May 2018 at 19:17, Pedro Duque Vieira >> wrote: >> >> > Hi Matthew, >> > >> > On the topic of documents with indications for improving performance. >> > >> > Don't know if you already found it, but there is a draft here (to which >> > I've made a small contribution): >> > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ti >> ps+and+Tricks >> > >> > A bit old though... >> > >> > And here: >> > >> > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ideas >> > >> > >> > -- >> > Pedro Duque Vieira >> > >> > > From kevin.rushforth at oracle.com Tue May 8 23:33:54 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 8 May 2018 16:33:54 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <716b085e-23b0-0443-e34b-e0bc5c85ebf5@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> 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 youngty1997 at gmail.com Wed May 9 05:36:05 2018 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 9 May 2018 00:36:05 -0500 Subject: Announcing EA builds of standalone JavaFX SDK Message-ID: <34520a7f-eb2b-e0c9-a04a-1f80faf9a066@gmail.com> This works just as well as a build of OpenJDK 11 with JavaFX prebuilt for me in Netbeans 9 Beta. The project tested on was a personal modular JavaFX application using OpenJDK 10 in Arch Linux. That said however, there seems to be a bug in the latest release of OpenJFX that is reproducible on my end in both this(standalone library release) as well my OpenJDK 11 OpenJFX build with TableView's setMouseTransparent method no longer working. Using Oracle JDK 10 works as expected. Is this a known issue with the latest release? From prasanta.sadhukhan at oracle.com Wed May 9 09:14:52 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 9 May 2018 14:44:52 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <80180aff-51b0-fdaa-f765-d074b499d9ac@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: 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 ambarish.rapte at oracle.com Wed May 9 10:46:39 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Wed, 9 May 2018 03:46:39 -0700 (PDT) Subject: [11] RFR : JDK-8196844 : [TestBug] IllegalArgumentException gets logged in some of test.javafx.scene.* tests Message-ID: <0574f22d-624e-47a2-8eeb-baa27c582db0@default> Hi Kevin & Ajit, Please review this test fix: Webrev: http://cr.openjdk.java.net/~arapte/fx/8196844/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8196844 Regards, Ambarish From mp at jugs.org Wed May 9 11:39:06 2018 From: mp at jugs.org (Michael Paus) Date: Wed, 9 May 2018 13:39:06 +0200 Subject: Announcing EA builds of standalone JavaFX SDK In-Reply-To: <1254a47f-0812-be0d-e831-de31ded1b689@jugs.org> References: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> <8db06510-51a9-49c0-ebdc-843d1c939ab5@bestsolution.at> <1254a47f-0812-be0d-e831-de31ded1b689@jugs.org> Message-ID: <1a1dfdc9-eb2a-4294-8830-dc63bc759390@jugs.org> Hi, I investigated the issue of using the standalone JavaFX SDK inside of an IDE (Eclipse and IntelliJ) a little bit further. For this purpose I used a simple single-class JavaFX program (actually the one which Johan used too). I started with Eclipse, created a simple Java project, added the JFX jars to the module path and added the --add-modules command to the runtime configuration. The result is: this works at compile time but not at runtime. Then I tried the same with IntelliJ. (I have to admit though that I have never seriously used IntelliJ before.) I created the project, added the dependencies and configured the runtime. The result is: the same error as in Eclipse. The advantage of IntelliJ though is that it directly shows you the command line which was created to launch the application. The problem seems to be that IntelliJ (in the same way as Eclipse) just puts the JavaFX dependencies on the classpath and not on the module path. The only way I found to fix this was to add a module-info.java to the project. module projavafx.helloearthrise.ui { ??? requires javafx.graphics; ??? requires javafx.controls; ??? exports projavafx.helloearthrise.ui; } After that you don't need the --add-modules command anymore. After adding this the setup immediately worked in IntelliJ. In Eclipse however the program could now be launched and there was no error or warning but the program just hangs and does not show anything on the screen. By looking at the generated command line via "ps -ef | grep java" I found that Eclipse is adding this option "-XstartOnFirstThread" which makes the program hang. There is a switch in the Eclipse runtime configuration dialog, which is selected by default, and which causes Eclipse to use this option when it thinks it is launched with SWT. This is caused by the fact that I have created a library (like Nir suggested) into which I put all jars of the JavaFX SDK, also the javafx-swt.jar one although it is not needed here. This has never been a problem before the split between JDK and JFX. This problem can be fixed by either switching off the startOnFirstThread option in the runtime configuration or by just not adding the javafx-swt.jar. So, my conclusion for the moment is that you can only use the split JDK/JFX in Eclipse/IntelliJ when your main project has a module-info.java. This may be a problem if you are not yet ready or willing to modularize your application. If somebody knows a trick to get around this limitation I'd be happy to here about it. Michael Am 08.05.18 um 14:39 schrieb Michael Paus: > Am 08.05.18 um 14:27 schrieb Tom Schindl: >> [...] >> >>> 3. How do you properly configure an Eclipse (the latest 4.7.3a) project >>> to use this module path. Adding the OpenJDK was no problem but how do >>> you add the module path for JavaFX? I failed on that. >>> >> You just open the Java Build Path-Properties-Page on the project and add >> the external jars, not? >> >> Tom > > That's one of the ways I tried it but ... > > 1. is that the intended way of doing it? On the command line you just > specify a single folder. > > 2. I did this and it resolved all dependencies at compile time but I > got an exception at runtime > > Error occurred during initialization of boot layer > java.lang.module.FindException: Module javafx.fxml not found > > although I also added > > --add-modules=javafx.fxml,javafx.controls,javafx.web,javafx.media > > as VM arguments. > From kevin.rushforth at oracle.com Wed May 9 12:28:49 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 9 May 2018 05:28:49 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: 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 prasanta.sadhukhan at oracle.com Wed May 9 14:14:47 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 9 May 2018 19:44:47 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> 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 philip.race at oracle.com Wed May 9 14:42:33 2018 From: philip.race at oracle.com (Philip Race) Date: Wed, 09 May 2018 07:42:33 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <5AF308D9.8080408@oracle.com> Yes, they (the methods mentioning Peer) should be renamed. Qn. to Mandy & Alan : it seems there is no need to mention this module in make/common/Modules.gmk in order to get it built, but is there any advantage in doing so ? I mean without it, there is no conscious listing of it as a module nor classification of it. Another thing that Kevin & I touched on in conversation is that it seems doclint fail on warning must be disabled by default .. and I suppose that is what we want here since documentation is minimal. -phil. On 5/9/18, 5:28 AM, 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 Alan.Bateman at oracle.com Wed May 9 14:48:50 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 9 May 2018 15:48:50 +0100 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <5AF308D9.8080408@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> <5AF308D9.8080408@oracle.com> Message-ID: On 09/05/2018 15:42, Philip Race wrote: > : > > Qn. to Mandy & Alan : it seems there is no need to mention this module > in make/common/Modules.gmk in order to get it built, but is there any > advantage in doing so ? I mean without it, there is no conscious > listing of > it as a module nor classification of it. Right, it's not necessary to list modules that are defined to the application class loader and are only in the JDK image. There's a comment at the top of the make file on this but it probably could be a bit clearer. -Alan From mandy.chung at oracle.com Wed May 9 15:55:51 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 9 May 2018 08:55:51 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> <5AF308D9.8080408@oracle.com> Message-ID: On 5/9/18 7:48 AM, Alan Bateman wrote: > On 09/05/2018 15:42, Philip Race wrote: >> : >> >> Qn. to Mandy & Alan : it seems there is no need to mention this module >> in make/common/Modules.gmk in order to get it built, but is there any >> advantage in doing so ? I mean without it, there is no conscious >> listing of >> it as a module nor classification of it. > Right, it's not necessary to list modules that are defined to the > application class loader and are only in the JDK image. There's a > comment at the top of the make file on this but it probably could be a > bit clearer. The build determines the modules to be compiled from the source directory per the modular source layout.? make/common/Modules.gmk serves a few purpose and the relevant one here is the module to class loader mapping.? It lists the modules defined to the boot loader and platform boot loader. Mandy From kevin.rushforth at oracle.com Wed May 9 17:10:37 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 9 May 2018 10:10:37 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <5AF308D9.8080408@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> <5AF308D9.8080408@oracle.com> Message-ID: I just checked, and it looks like the build doesn't generate docs for the jdk.unsupported.desktop module. So the issue of doclint warnings is probably a moot point. -- Kevin On 5/9/2018 7:42 AM, Philip Race wrote: > Yes, they (the methods mentioning Peer) should be renamed. > > Qn. to Mandy & Alan : it seems there is no need to mention this module > in make/common/Modules.gmk in order to get it built, but is there any > advantage in doing so ? I mean without it, there is no conscious > listing of > it as a module nor classification of it. > > Another thing that Kevin & I touched on in conversation is that it seems > doclint fail on warning must be disabled by default .. and I suppose that > is what we want here since documentation is minimal. > > -phil. > > On 5/9/18, 5:28 AM, 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 kevin.rushforth at oracle.com Wed May 9 17:59:32 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 9 May 2018 10:59:32 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <1b7653d1-9c9a-7ad8-8f56-674760136d22@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> 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 matthew.james.elliot at gmail.com Wed May 9 18:19:12 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Wed, 9 May 2018 20:19:12 +0200 Subject: Paint Phase Debugging / Performance In-Reply-To: References: Message-ID: <6843A789-00DF-476D-8FB3-4732364BB7FF@gmail.com> Hey Nir, In MissionControl the HotMethods section is very interest sometimes; not sure if that is where you?re already looking. It might point at the particular part of rendering pipeline that is executing too much. I assume you also captured the JavaFX events and visualised the FXApplicationThread and QuantumRenderer threads to see that QuantumRenderer is constantly busy. I also don?t know how many animations you have but we also introduced a single central animation which modified properties triggering other components to redraw. This meant we only had 1 animation instead of dozens or hundreds. Not sure if this makes such a big difference to painting. Maybe also worth trying is in the IDE (I.e. IntelliJ) to Instrument the code with the debugger by evaluate and logging timestamps in the code. If you look at breakpoint properties you can put inside ?Evaluate and log? block System.currentTimeMillis(). Not sure how much it?ll drag performance back but maybe on prism frames per second = 1 and many breakpoints in the painting pipeline you can at least find where it spends all the time. Beyond that I?d be out of ideas. Matt Sent from my phone. > On 9/05/2018, at 1:15 AM, Nir Lisker wrote: > > Hi Matthew, > > This is a typical pulse, which indeed cases the effect of low FPS, and that's what I'm trying to solve. > > * Cache hints are ignored for 3D (but I tried anyway). > * -Dprism.showdirty and printrendergraph also don't work for 3D scenes (though I can get an approximation with a 2D scene). > * There are no effects. > > I'm working with Mission Control already, most of the instances in the GC class histogram are related to animation classes: InterpolationInterval$TangentDoubleInterpolationInterval and NumberTangentInterpolator. > > Looks like all all the discussed difficulties with diagnostics are enhanced when it comes to 3D. Will have to dig deep on this one. > > Thanks, > Nir > >> On Mon, May 7, 2018 at 9:07 PM, Matthew Elliot wrote: >> Hey Nir, >> >> I?m not sure if I can offer much support as I haven?t been into the 3D world but just to clarify, is it one pulse after another with long wait, paint phases? From what I?ve seen personally if you have painting of 100+ milliseconds on every pulse you will be in big trouble / laggy as. >> >> On a one-off pulse like building a scene the first time I would say it is fine but regular paints that are longer are going to cause issues from my experience. >> >> Did you try profiling with mission controller to look at what garbage is being created / what hot methods there? Maybe it points you in a better direction / at least rule out your own code. >> >> With animations I guess you set cache hints already? >> >> Make sure you don?t have any effects on the animation as well, a Gaussian blur blend/drop shadow on an animation killed it for me. >> You can also try -Dprism.disableEffects= true to rule it out. >> You can also enable the prism option to show what is being painted on each pulse as an overlay. -Dprism.showdirty and there is another I forget to show how many times it was painted. (Not that your whole scene is painted when you expect a small part of it) >> >> Or some trial and error with the prism flags here to try narrow it down - Just open PrismSettings.java in your IDE or web browser. >> >> Code explains them better than most posts I?ve seen. >> >> Good luck. >> Matt >> >> Sent from my phone. >> >>> On 7/05/2018, at 2:36 PM, Nir Lisker wrote: >>> >>> Hi, >>> >>> I'm having a performance issue myself. I'm using animations on 3D models (in a 3D subscene) and when there are "too many" models the QuantumRenderer thread is running 100% of the time and utilizing 20-25% of the CPU, though the OS reports that overall all cores are at ~40%. The application is using the d3d pipeline. >>> >>> A typical pulse is >>> >>> PULSE: 4078 [112ms:225ms] >>> T15 (11 +0ms): CSS Pass >>> T15 (11 +0ms): Layout Pass >>> T15 (12 +0ms): Update bounds >>> T15 (12 +95ms): Waiting for previous rendering >>> T15 (108 +0ms): Copy state to render graph >>> T12 (109 +115ms): Painting >>> T12 (224 +0ms): Presenting >>> Counters: >>> Nodes rendered: 651 >>> Nodes visited during render: 651 >>> >>> Thread dumps show that QuantumRenderer is busy with tasks inside >>> >>> at com.sun.prism.impl.BaseMesh.buildPTGeometry(javafx.graphics at 10-internal/BaseMesh.java:584) >>> at com.sun.prism.impl.BaseMesh.buildGeometry(javafx.graphics at 10-internal/BaseMesh.java:516) >>> at com.sun.javafx.sg.prism.NGTriangleMesh.validate(javafx.graphics at 10-internal/NGTriangleMesh.java:75) >>> at com.sun.javafx.sg.prism.NGShape3D.renderMeshView(javafx.graphics at 10-internal/NGShape3D.java:84) >>> at com.sun.javafx.sg.prism.NGShape3D.renderContent(javafx.graphics at 10-internal/NGShape3D.java:201) >>> at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal/NGNode.java:2072) >>> at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal/NGNode.java:1964) >>> at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal/NGGroup.java:270) >>> at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal/NGNode.java:2072) >>> at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal/NGNode.java:1964) >>> at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal/NGGroup.java:270) >>> at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal/NGNode.java:2072) >>> at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal/NGNode.java:1964) >>> at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal/NGGroup.java:270) >>> at com.sun.javafx.sg.prism.NGNode.renderCached(javafx.graphics at 10-internal/NGNode.java:2379) >>> at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal/NGNode.java:2063) >>> at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal/NGNode.java:1964) >>> at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal/NGGroup.java:270) >>> at com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal/NGNode.java:2072) >>> at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal/NGNode.java:1964) >>> at com.sun.javafx.tk.quantum.ViewPainter.doPaint(javafx.graphics at 10-internal/ViewPainter.java:479) >>> at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(javafx.graphics at 10-internal/ViewPainter.java:328) >>> at com.sun.javafx.tk.quantum.PresentingPainter.run(javafx.graphics at 10-internal/PresentingPainter.java:91) >>> at java.util.concurrent.Executors$RunnableAdapter.call(java.base at 10-internal/Executors.java:514) >>> at java.util.concurrent.FutureTask.runAndReset(java.base at 10-internal/FutureTask.java:305) >>> at com.sun.javafx.tk.RenderJob.run(javafx.graphics at 10-internal/RenderJob.java:58) >>> at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 10-internal/ThreadPoolExecutor.java:1135) >>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 10-internal/ThreadPoolExecutor.java:635) >>> at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(javafx.graphics at 10-internal/QuantumRenderer.java:125) >>> at java.lang.Thread.run(java.base at 10-internal/Thread.java:844) >>> >>> Does anyone have an idea on how to continue? >>> >>> Thanks, >>> Nir >>> >>> >>>> On Fri, May 4, 2018 at 10:30 AM, Matthew Elliot wrote: >>>> Hi Pedro, >>>> >>>> The first link I have read through many times, it is very useful for ideas >>>> but doesn't really flesh out or go into much detail on each topic. It also >>>> comments a few times on the problems we've encountered, 'what costs what' >>>> is difficult to understand / measure. >>>> >>>> The second link I hadn't found my way to and is definitely interesting to >>>> understand more about how things are working internally - thanks. >>>> >>>> Regards, >>>> Matt >>>> >>>> >>>> On 3 May 2018 at 19:17, Pedro Duque Vieira >>>> wrote: >>>> >>>> > Hi Matthew, >>>> > >>>> > On the topic of documents with indications for improving performance. >>>> > >>>> > Don't know if you already found it, but there is a draft here (to which >>>> > I've made a small contribution): >>>> > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks >>>> > >>>> > A bit old though... >>>> > >>>> > And here: >>>> > >>>> > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ideas >>>> > >>>> > >>>> > -- >>>> > Pedro Duque Vieira >>>> > >>> > From prasanta.sadhukhan at oracle.com Thu May 10 15:20:56 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 10 May 2018 20:50:56 +0530 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <5b57623c-bd12-89af-17e0-1a740d72031c@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: 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 kevin.rushforth at oracle.com Thu May 10 15:32:29 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 10 May 2018 08:32:29 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: 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 kevin.rushforth at oracle.com Thu May 10 23:30:00 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 10 May 2018 16:30:00 -0700 Subject: [11] Review request: JDK-8202368: Create jmods for standalone javafx modules Message-ID: <65e417e0-300c-a75b-b3c7-00e624ee25b5@oracle.com> Please review the following build change to produce jmods for the standalone FX SDK: https://bugs.openjdk.java.net/browse/JDK-8202368 http://cr.openjdk.java.net/~kcr/8202368/webrev.00/ See the JBS issue for more details. My plan is to get this in on Monday so it can be part of next week's standalone (unbundled) openjfx-11+14 build. -- Kevin From philip.race at oracle.com Fri May 11 00:49:51 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 10 May 2018 17:49:51 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <5AF4E8AF.60202@oracle.com> 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. 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. 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 philip.race at oracle.com Fri May 11 01:29:32 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 10 May 2018 18:29:32 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <5AF4E8AF.60202@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <5AF4F1FC.2030802@oracle.com> PS .. there should be some tests on the JDK side that don't use FX Or at least a reasoned explanation as to why this isn't possible. -phil. 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. > > 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. > > 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 youngty1997 at gmail.com Sat May 12 23:29:38 2018 From: youngty1997 at gmail.com (Ty Young) Date: Sat, 12 May 2018 18:29:38 -0500 Subject: Building from source fails due to treat warnings as errors Message-ID: <9a610007-b282-146a-83c9-33502ff64409@gmail.com> Hi, I'm no longer able to build from any source(dev or 10 atleast) on Arch Linux due to the following warnings here: https://pastebin.com/rJqu7Nws The only two packages that have changed since my last successful source build was Gradle and Mercurial(distro package versions). I've tried downloading an older version of Gradle(version 4.3.1) but the warnings that prevent me from building still show up. Ant version is 1.9.7 but I've built using it before and it worked just fine before. Is there a way I can just ignore these warnings via Wno-error arg? Thanks. From mp at jugs.org Sun May 13 10:19:19 2018 From: mp at jugs.org (Michael Paus) Date: Sun, 13 May 2018 12:19:19 +0200 Subject: Announcing EA builds of standalone JavaFX SDK In-Reply-To: <1a1dfdc9-eb2a-4294-8830-dc63bc759390@jugs.org> References: <8ae613b7-bac6-fa44-94e4-7490b07269ef@oracle.com> <8db06510-51a9-49c0-ebdc-843d1c939ab5@bestsolution.at> <1254a47f-0812-be0d-e831-de31ded1b689@jugs.org> <1a1dfdc9-eb2a-4294-8830-dc63bc759390@jugs.org> Message-ID: Hi, a few days ago I was informed in a private e-mail from Bernhard Lutzmann how the problem with Eclipse described below can be solved without having to provide a module-info.java. The problem in Eclipse is that, although the JavaFX jars are explicitly put on the module path in the build configuration, this is not copied over to the runtime configuration. So each time when you create a new runtime configuration you have to go to the dependencies tab in the runtime configuration editor and manually remove the JavaFX jars form the classpath and then add them one by one to the module path again. I consider this annoying behaviour a bug and have thus filed a corresponding bug report. Michael Am 09.05.18 um 13:39 schrieb Michael Paus: > Hi, > I investigated the issue of using the standalone JavaFX SDK inside of > an IDE (Eclipse and IntelliJ) a little bit further. For this purpose I > used a simple single-class JavaFX program (actually the one which > Johan used too). > > I started with Eclipse, created a simple Java project, added the JFX > jars to the module path and added the --add-modules command to the > runtime configuration. The result is: this works at compile time but > not at runtime. > > Then I tried the same with IntelliJ. (I have to admit though that I > have never seriously used IntelliJ before.) I created the project, > added the dependencies and configured the runtime. The result is: the > same error as in Eclipse. > > The advantage of IntelliJ though is that it directly shows you the > command line which was created to launch the application. The problem > seems to be that IntelliJ (in the same way as Eclipse) just puts the > JavaFX dependencies on the classpath and not on the module path. The > only way I found to fix this was to add a module-info.java to the > project. > > module projavafx.helloearthrise.ui { > ??? requires javafx.graphics; > ??? requires javafx.controls; > ??? exports projavafx.helloearthrise.ui; > } > > After that you don't need the --add-modules command anymore. > > After adding this the setup immediately worked in IntelliJ. In Eclipse > however the program could now be launched and there was no error or > warning but the program just hangs and does not show anything on the > screen. By looking at the generated command line via "ps -ef | grep > java" I found that Eclipse is adding this option > "-XstartOnFirstThread" which makes the program hang. There is a switch > in the Eclipse runtime configuration dialog, which is selected by > default, and which causes Eclipse to use this option when it thinks it > is launched with SWT. This is caused by the fact that I have created a > library (like Nir suggested) into which I put all jars of the JavaFX > SDK, also the javafx-swt.jar one although it is not needed here. This > has never been a problem before the split between JDK and JFX. This > problem can be fixed by either switching off the startOnFirstThread > option in the runtime configuration or by just not adding the > javafx-swt.jar. > > So, my conclusion for the moment is that you can only use the split > JDK/JFX in Eclipse/IntelliJ when your main project has a > module-info.java. This may be a problem if you are not yet ready or > willing to modularize your application. > > If somebody knows a trick to get around this limitation I'd be happy > to here about it. > > Michael > > > Am 08.05.18 um 14:39 schrieb Michael Paus: >> Am 08.05.18 um 14:27 schrieb Tom Schindl: >>> [...] >>> >>>> 3. How do you properly configure an Eclipse (the latest 4.7.3a) >>>> project >>>> to use this module path. Adding the OpenJDK was no problem but how do >>>> you add the module path for JavaFX? I failed on that. >>>> >>> You just open the Java Build Path-Properties-Page on the project and >>> add >>> the external jars, not? >>> >>> Tom >> >> That's one of the ways I tried it but ... >> >> 1. is that the intended way of doing it? On the command line you just >> specify a single folder. >> >> 2. I did this and it resolved all dependencies at compile time but I >> got an exception at runtime >> >> Error occurred during initialization of boot layer >> java.lang.module.FindException: Module javafx.fxml not found >> >> although I also added >> >> --add-modules=javafx.fxml,javafx.controls,javafx.web,javafx.media >> >> as VM arguments. >> > From prem.balakrishnan at oracle.com Mon May 14 11:33:55 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Mon, 14 May 2018 04:33:55 -0700 (PDT) Subject: [11] Review Request:JDK-8186187 Modify return type of public API StyleConverter.getEnumConverter() Message-ID: <8260c2ca-26fd-4a7f-ab4a-f3cb02926e8e@default> Hi Kevin, Ajit Request you to review following fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8186187 Webrev: http://cr.openjdk.java.net/~pkbalakr/fx/8186187/webrev.00/ Regards, Prem From kevin.rushforth at oracle.com Mon May 14 22:11:05 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 14 May 2018 15:11:05 -0700 Subject: [11] Review request: 8201261: Ability to override the dependency repositories used by gradle Message-ID: <1ff1f740-3b49-7ad7-37bf-d4222e36cd2b@oracle.com> Phil, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8201261 http://cr.openjdk.java.net/~kcr/8201261/webrev.00/ This adds support for two new gradle properties, JFX_DEPS_URL and JDK_DOCS_LINK, replacing logic currently in the closed build. Details are in JBS. -- Kevin From ambarish.rapte at oracle.com Tue May 15 06:24:45 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 14 May 2018 23:24:45 -0700 (PDT) Subject: [11] JDK-8199344: [testbug] Illegal reflective access by NGTestBase Message-ID: <213a0d79-49f2-485f-b321-62feeee948fe@default> Hi Kevin & Ajit, Request you to review this fix, Webrev: http://cr.openjdk.java.net/~arapte/fx/8199344/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8199344 Regards, Ambarish From ambarish.rapte at oracle.com Tue May 15 06:26:20 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 14 May 2018 23:26:20 -0700 (PDT) Subject: [11] JDK-8202623 : Some launcher tests will hang if underlying process exits too early Message-ID: <05df186f-203b-466c-9ad4-5e0336a873b1@default> Hi Kevin & Ajit, Request you to review this fix. Webrev: http://cr.openjdk.java.net/~arapte/fx/8202623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8202623 Regards, Ambarish From pankaj.b.bansal at oracle.com Tue May 15 07:56:17 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 15 May 2018 00:56:17 -0700 (PDT) Subject: [11] JDK-8163795 : [Windows] Remove call to StretchBlt in native GetScreenCapture method Message-ID: Hi All, Request to review this fix. Webrev: http://cr.openjdk.java.net/~pbansal/8163795/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163795 Regards, Pankaj Bansal From kevin.rushforth at oracle.com Tue May 15 19:04:23 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 May 2018 12:04:23 -0700 Subject: [11] JDK-8163795 : [Windows] Remove call to StretchBlt in native GetScreenCapture method In-Reply-To: References: Message-ID: <1bbd9528-25a6-dc6a-1539-56b5bf6feb7c@oracle.com> Looks good. +1 -- Kevin On 5/15/2018 12:56 AM, Pankaj Bansal wrote: > Hi All, > > > > Request to review this fix. > > > > Webrev: http://cr.openjdk.java.net/~pbansal/8163795/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163795 > > > > Regards, > > Pankaj Bansal From kevin.rushforth at oracle.com Tue May 15 21:59:14 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 May 2018 14:59:14 -0700 Subject: OpenJFX status update Message-ID: I wanted to update you on the progress of the last couple weeks on the OpenJFX project: 1. As mentioned last week, we now have EA builds of OpenJFX 11 on java.net [1]. We intend to update this roughly weekly. Currently the build numbers match the corresponding JDK build number, but that will not necessarily be the case going forward, so don't assume that they are in sync. 2. Barring any build or staging issues, this week's OpenJFX 11 EA build will include the jmods as mentioned earlier [2] [3] 3. JavaFX has been removed from JDK 11 as of this week. Starting with jdk-11+14, early access builds of JDK 11 will not include JavaFX. 4. After jdk-11+14 is posted on java.net, and FX is no longer included in JDK 11, we will start using openjfx-11 as the fix version in JBS to distinguish it from JDK 11. We still expect to do a release of JavaFX 11 around the same time as JDK 11, but using a different release number will help track the actual content of JavaFX 11 separately from JDK 11. 5. Once this settles down, possibly later this week, I hope to restart the discussion about OpenJFX policies, etc. I also hope to be a bit more responsive over the coming days / weeks than I have been for the last 3-4 weeks. Getting the standalone OpenJFX working and removing JavaFX from the JDK was quite time consuming as you can probably imagine. If you have any general comments or questions about any of this, please reply to this thread. We may want to split out more detailed discussions into their own thread to make it easier to follow. -- Kevin [1] http://jdk.java.net/openjfx/ [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021856.html [3] https://bugs.openjdk.java.net/browse/JDK-8202368 From javalists at cbfiddle.com Tue May 15 22:16:46 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 15 May 2018 15:16:46 -0700 Subject: OpenJFX status update In-Reply-To: References: Message-ID: Where does java packager fit in this? > On May 15, 2018, at 2:59 PM, Kevin Rushforth wrote: > > I wanted to update you on the progress of the last couple weeks on the OpenJFX project: > > 1. As mentioned last week, we now have EA builds of OpenJFX 11 on java.net [1]. We intend to update this roughly weekly. Currently the build numbers match the corresponding JDK build number, but that will not necessarily be the case going forward, so don't assume that they are in sync. > > 2. Barring any build or staging issues, this week's OpenJFX 11 EA build will include the jmods as mentioned earlier [2] [3] > > 3. JavaFX has been removed from JDK 11 as of this week. Starting with jdk-11+14, early access builds of JDK 11 will not include JavaFX. > > 4. After jdk-11+14 is posted on java.net, and FX is no longer included in JDK 11, we will start using openjfx-11 as the fix version in JBS to distinguish it from JDK 11. We still expect to do a release of JavaFX 11 around the same time as JDK 11, but using a different release number will help track the actual content of JavaFX 11 separately from JDK 11. > > 5. Once this settles down, possibly later this week, I hope to restart the discussion about OpenJFX policies, etc. I also hope to be a bit more responsive over the coming days / weeks than I have been for the last 3-4 weeks. Getting the standalone OpenJFX working and removing JavaFX from the JDK was quite time consuming as you can probably imagine. > > If you have any general comments or questions about any of this, please reply to this thread. We may want to split out more detailed discussions into their own thread to make it easier to follow. > > -- Kevin > > [1] http://jdk.java.net/openjfx/ > > [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021856.html > [3] https://bugs.openjdk.java.net/browse/JDK-8202368 > From youngty1997 at gmail.com Wed May 16 06:57:26 2018 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 16 May 2018 01:57:26 -0500 Subject: OpenJFX status update In-Reply-To: References: Message-ID: > 3. JavaFX has been removed from JDK 11 as of this week. Starting with > jdk-11+14, early access builds of JDK 11 will not include JavaFX. > > 4. After jdk-11+14 is posted on java.net, and FX is no longer included > in JDK 11, we will start using openjfx-11 as the fix version in JBS to > distinguish it from JDK 11. We still expect to do a release of JavaFX > 11 around the same time as JDK 11, but using a different release > number will help track the actual content of JavaFX 11 separately from > JDK 11. > I'm not sure if it's intentional or perhaps a bug on my end, but I cannot compile JavaFX without Oracle JDK(9 or 10). Attempting to do so with a self compiled JDK with JavaFX support results in a build fail while doing it without JavaFX entirely results in a fail due to Observable classes being missing. Is Oracle JDK a requirement for building JavaFX currently or is this just some weird bug with my compiled JDK? And could the new standalone modules be integrated with the source code somehow so that a JDK without JavaFX support can be compiled? > 5. Once this settles down, possibly later this week, I hope to restart > the discussion about OpenJFX policies, etc. I also hope to be a bit > more responsive over the coming days / weeks than I have been for the > last 3-4 weeks. Getting the standalone OpenJFX working and removing > JavaFX from the JDK was quite time consuming as you can probably imagine. > > If you have any general comments or questions about any of this, > please reply to this thread. We may want to split out more detailed > discussions into their own thread to make it easier to follow. As I wrote before and am still having issues with, after a successful first compile, JavaFX no longer compiles in Arch Linux for me. Any attempt to do so results in a bunch of warning messages(see: https://pastebin.com/rJqu7Nws) which cause the build to fail due to warnings being treated as errors(Should they even be ignored?). In addition. I'm now getting a GCC warning about XIMProc returning an int when it should return void (*). I don't know C or the native APIs so right now I'm at a loss of what to do besides trying to compile on another distro - which is something I *really* would prefer not to have to do. From kevin.rushforth at oracle.com Wed May 16 15:42:27 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 May 2018 08:42:27 -0700 Subject: OpenJFX status update In-Reply-To: References: Message-ID: On 5/15/2018 11:57 PM, Ty Young wrote: > >> 3. JavaFX has been removed from JDK 11 as of this week. Starting with >> jdk-11+14, early access builds of JDK 11 will not include JavaFX. > I'm not sure if it's intentional or perhaps a bug on my end, but I > cannot compile JavaFX without Oracle JDK(9 or 10). Attempting to do so > with a self compiled JDK with JavaFX support results in a build fail > while doing it without JavaFX entirely results in a fail due to > Observable classes being missing. > > Is Oracle JDK a requirement for building JavaFX currently or is this > just some weird bug with my compiled JDK? This is likely something on your end, since we build the standalone JavaFX using OpenJDK 10. What repo are you building from? The correct repo is: http://hg.openjdk.java.net/openjfx/jfx-dev/rt > And could the new standalone modules be integrated with the source > code somehow so that a JDK without JavaFX support can be compiled? Not sure what you mean, but you can use an OpenJDK without modules + the JavaFX standalone modules to build and run your program. > As I wrote before and am still having issues with, after a successful > first compile, JavaFX no longer compiles in Arch Linux for me. Any > attempt to do so results in a bunch of warning messages(see: > https://pastebin.com/rJqu7Nws) which cause the build to fail due to > warnings being treated as errors(Should they even be ignored?). In > addition. I'm now getting a GCC warning about XIMProc returning an int > when it should return void (*). I don't know C or the native APIs so > right now I'm at a loss of what to do besides trying to compile on > another distro - which is something I *really* would prefer not to > have to do. What gcc version are you using? And what Linux distro? -- Kevin From kevin.rushforth at oracle.com Wed May 16 17:08:39 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 May 2018 10:08:39 -0700 Subject: OpenJFX status update In-Reply-To: References: Message-ID: The javapackager was removed from the Oracle JDK along with JavaFX (and has never been part of OpenJDK). It isn't included with the standalone JavaFX bundles, and doesn't really fit in a standalone FX release. We are looking at the possibility of providing a replacement packaging tool in OpenJDK. -- Kevin On 5/15/2018 3:16 PM, Alan Snyder wrote: > Where does java packager fit in this? > > >> On May 15, 2018, at 2:59 PM, Kevin Rushforth wrote: >> >> I wanted to update you on the progress of the last couple weeks on the OpenJFX project: >> >> 1. As mentioned last week, we now have EA builds of OpenJFX 11 on java.net [1]. We intend to update this roughly weekly. Currently the build numbers match the corresponding JDK build number, but that will not necessarily be the case going forward, so don't assume that they are in sync. >> >> 2. Barring any build or staging issues, this week's OpenJFX 11 EA build will include the jmods as mentioned earlier [2] [3] >> >> 3. JavaFX has been removed from JDK 11 as of this week. Starting with jdk-11+14, early access builds of JDK 11 will not include JavaFX. >> >> 4. After jdk-11+14 is posted on java.net, and FX is no longer included in JDK 11, we will start using openjfx-11 as the fix version in JBS to distinguish it from JDK 11. We still expect to do a release of JavaFX 11 around the same time as JDK 11, but using a different release number will help track the actual content of JavaFX 11 separately from JDK 11. >> >> 5. Once this settles down, possibly later this week, I hope to restart the discussion about OpenJFX policies, etc. I also hope to be a bit more responsive over the coming days / weeks than I have been for the last 3-4 weeks. Getting the standalone OpenJFX working and removing JavaFX from the JDK was quite time consuming as you can probably imagine. >> >> If you have any general comments or questions about any of this, please reply to this thread. We may want to split out more detailed discussions into their own thread to make it easier to follow. >> >> -- Kevin >> >> [1] http://jdk.java.net/openjfx/ >> >> [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021856.html >> [3] https://bugs.openjdk.java.net/browse/JDK-8202368 >> From youngty1997 at gmail.com Wed May 16 17:49:01 2018 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 16 May 2018 12:49:01 -0500 Subject: OpenJFX status update In-Reply-To: References: Message-ID: On 05/16/2018 10:42 AM, Kevin Rushforth wrote: > > > On 5/15/2018 11:57 PM, Ty Young wrote: >> >>> 3. JavaFX has been removed from JDK 11 as of this week. Starting >>> with jdk-11+14, early access builds of JDK 11 will not include JavaFX. > >> I'm not sure if it's intentional or perhaps a bug on my end, but I >> cannot compile JavaFX without Oracle JDK(9 or 10). Attempting to do >> so with a self compiled JDK with JavaFX support results in a build >> fail while doing it without JavaFX entirely results in a fail due to >> Observable classes being missing. >> >> Is Oracle JDK a requirement for building JavaFX currently or is this >> just some weird bug with my compiled JDK? > > This is likely something on your end, since we build the standalone > JavaFX using OpenJDK 10. What repo are you building from? The correct > repo is: > > http://hg.openjdk.java.net/openjfx/jfx-dev/rt That one, as mentioned in the wiki build guide. I get an immediate build fail(see: https://pastebin.com/geR4LLMm). The JDK works just fine: I can set it as the default JDK, run Netbeans, set the project source to 11, and my application builds just fine. > >> And could the new standalone modules be integrated with the source >> code somehow so that a JDK without JavaFX support can be compiled? > > Not sure what you mean, but you can use an OpenJDK without modules + > the JavaFX standalone modules to build and run your program. > > It's an option, sure. My problem with it is that it creates so much unnecessary disk usage because each bundled application requires it's own copy of JavaFX. If you had 10 standalone JavaFX applications it would be 1GB easily if they where all modular projects, which are around 106MB for me. Creating an app bundle using classpath is around 200MB(post JDK 8 was 250+ IIRC). >> As I wrote before and am still having issues with, after a successful >> first compile, JavaFX no longer compiles in Arch Linux for me. Any >> attempt to do so results in a bunch of warning messages(see: >> https://pastebin.com/rJqu7Nws) which cause the build to fail due to >> warnings being treated as errors(Should they even be ignored?). In >> addition. I'm now getting a GCC warning about XIMProc returning an >> int when it should return void (*). I don't know C or the native APIs >> so right now I'm at a loss of what to do besides trying to compile on >> another distro - which is something I *really* would prefer not to >> have to do. > > What gcc version are you using? And what Linux distro? > 8.1.0 and Arch Linux(Antergos which is basically Arch Linux). > -- Kevin > From javalists at cbfiddle.com Wed May 16 18:09:53 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 16 May 2018 11:09:53 -0700 Subject: OpenJFX status update In-Reply-To: References: Message-ID: <72E83419-8103-4276-9C22-B29229DB8FF6@cbfiddle.com> That sounds like a good idea. Alan > On May 16, 2018, at 10:08 AM, Kevin Rushforth wrote: > > The javapackager was removed from the Oracle JDK along with JavaFX (and has never been part of OpenJDK). It isn't included with the standalone JavaFX bundles, and doesn't really fit in a standalone FX release. > > We are looking at the possibility of providing a replacement packaging tool in OpenJDK. > > -- Kevin > > On 5/15/2018 3:16 PM, Alan Snyder wrote: >> Where does java packager fit in this? >> >> >>> On May 15, 2018, at 2:59 PM, Kevin Rushforth wrote: >>> >>> I wanted to update you on the progress of the last couple weeks on the OpenJFX project: >>> >>> 1. As mentioned last week, we now have EA builds of OpenJFX 11 on java.net [1]. We intend to update this roughly weekly. Currently the build numbers match the corresponding JDK build number, but that will not necessarily be the case going forward, so don't assume that they are in sync. >>> >>> 2. Barring any build or staging issues, this week's OpenJFX 11 EA build will include the jmods as mentioned earlier [2] [3] >>> >>> 3. JavaFX has been removed from JDK 11 as of this week. Starting with jdk-11+14, early access builds of JDK 11 will not include JavaFX. >>> >>> 4. After jdk-11+14 is posted on java.net, and FX is no longer included in JDK 11, we will start using openjfx-11 as the fix version in JBS to distinguish it from JDK 11. We still expect to do a release of JavaFX 11 around the same time as JDK 11, but using a different release number will help track the actual content of JavaFX 11 separately from JDK 11. >>> >>> 5. Once this settles down, possibly later this week, I hope to restart the discussion about OpenJFX policies, etc. I also hope to be a bit more responsive over the coming days / weeks than I have been for the last 3-4 weeks. Getting the standalone OpenJFX working and removing JavaFX from the JDK was quite time consuming as you can probably imagine. >>> >>> If you have any general comments or questions about any of this, please reply to this thread. We may want to split out more detailed discussions into their own thread to make it easier to follow. >>> >>> -- Kevin >>> >>> [1] http://jdk.java.net/openjfx/ >>> >>> [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021856.html >>> [3] https://bugs.openjdk.java.net/browse/JDK-8202368 >>> > From nlisker at gmail.com Wed May 16 18:54:01 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 16 May 2018 21:54:01 +0300 Subject: OpenJFX status update In-Reply-To: References: Message-ID: What will happen to the JavaDocs? Will they be removed from the EA docs and upon release from the release docs? - Nir On Wed, May 16, 2018 at 12:59 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > I wanted to update you on the progress of the last couple weeks on the > OpenJFX project: > > 1. As mentioned last week, we now have EA builds of OpenJFX 11 on java.net > [1]. We intend to update this roughly weekly. Currently the build numbers > match the corresponding JDK build number, but that will not necessarily be > the case going forward, so don't assume that they are in sync. > > 2. Barring any build or staging issues, this week's OpenJFX 11 EA build > will include the jmods as mentioned earlier [2] [3] > > 3. JavaFX has been removed from JDK 11 as of this week. Starting with > jdk-11+14, early access builds of JDK 11 will not include JavaFX. > > 4. After jdk-11+14 is posted on java.net, and FX is no longer included in > JDK 11, we will start using openjfx-11 as the fix version in JBS to > distinguish it from JDK 11. We still expect to do a release of JavaFX 11 > around the same time as JDK 11, but using a different release number will > help track the actual content of JavaFX 11 separately from JDK 11. > > 5. Once this settles down, possibly later this week, I hope to restart the > discussion about OpenJFX policies, etc. I also hope to be a bit more > responsive over the coming days / weeks than I have been for the last 3-4 > weeks. Getting the standalone OpenJFX working and removing JavaFX from the > JDK was quite time consuming as you can probably imagine. > > If you have any general comments or questions about any of this, please > reply to this thread. We may want to split out more detailed discussions > into their own thread to make it easier to follow. > > -- Kevin > > [1] http://jdk.java.net/openjfx/ > > [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/ > 021856.html > [3] https://bugs.openjdk.java.net/browse/JDK-8202368 > > From kevin.rushforth at oracle.com Wed May 16 19:04:27 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 May 2018 12:04:27 -0700 Subject: OpenJFX status update In-Reply-To: References: Message-ID: <27c67144-7b3d-311d-2479-f8a73d851dd5@oracle.com> On 5/16/2018 10:49 AM, Ty Young wrote: > That one, as mentioned in the wiki build guide. I get an immediate > build fail(see: https://pastebin.com/geR4LLMm). The JDK works just > fine: I can set it as the default JDK, run Netbeans, set the project > source to 11, and my application builds just fine. Ah, I see. You didn't say what version of gradle or JDK you were using, but this looks like a known problem in trying to run gradle with JDK 11. See: https://github.com/gradle/gradle/issues/4860 https://bugs.openjdk.java.net/browse/JDK-8199069 This is marked as fixed in gradle 4.8-rc1, but I haven't confirmed this. >>> And could the new standalone modules be integrated with the source >>> code somehow so that a JDK without JavaFX support can be compiled? >> >> Not sure what you mean, but you can use an OpenJDK without modules + >> the JavaFX standalone modules to build and run your program. >> >> > > It's an option, sure. My problem with it is that it creates so much > unnecessary disk usage because each bundled application requires it's > own copy of JavaFX. If you had 10 standalone JavaFX applications it > would be 1GB easily if they where all modular projects, which are > around 106MB for me. Creating an app bundle using classpath is around > 200MB(post JDK 8 was 250+ IIRC). One option for you would be to use jlink to create a jre image that includes the javafx modules. This week's openjfx-11-ea+14 build will have a jmods bundle that you can use for this purpose. >>> As I wrote before and am still having issues with, after a >>> successful first compile, JavaFX no longer compiles in Arch Linux >>> for me. Any attempt to do so results in a bunch of warning >>> messages(see: https://pastebin.com/rJqu7Nws) which cause the build >>> to fail due to warnings being treated as errors(Should they even be >>> ignored?). In addition. I'm now getting a GCC warning about XIMProc >>> returning an int when it should return void (*). I don't know C or >>> the native APIs so right now I'm at a loss of what to do besides >>> trying to compile on another distro - which is something I *really* >>> would prefer not to have to do. >> >> What gcc version are you using? And what Linux distro? >> > > 8.1.0 and Arch Linux(Antergos which is basically Arch Linux). That's not a distro I'm familiar with, but it may or may not be related to the issue you are seeing. The gcc errors may be related to compiling with a more-strict 8.1 compiler; we have tested with up to gcc 7.3, but nothing newer than that. A quick look suggests that we will need some way to suppress that warning. For now, you can modify buildSrc/linux.gradle and remove the "-Werror" flag from LINUX.glass.glassgtk2.ccFlags (ditto for gtk3). -- Kevin > > >> -- Kevin >> > From kevin.rushforth at oracle.com Wed May 16 19:06:40 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 May 2018 12:06:40 -0700 Subject: OpenJFX status update In-Reply-To: References: Message-ID: <82914c4a-2349-6251-4d8c-c0b92f8c1609@oracle.com> On 5/16/2018 11:54 AM, Nir Lisker wrote: > What will happen to the JavaDocs? Will they be removed from the EA > docs and upon release from the release docs? Correct. The JDK 11 docs will no longer include JavaFX modules and classes. We will need to host separate docs for JavaFX. -- Kevin From mike.ennen at gmail.com Wed May 16 20:05:04 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 16 May 2018 13:05:04 -0700 Subject: OpenJFX status update In-Reply-To: References: Message-ID: Is the source code for javapackager fully open source? Thanks. On Wed, May 16, 2018 at 10:08 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > The javapackager was removed from the Oracle JDK along with JavaFX (and > has never been part of OpenJDK). It isn't included with the standalone > JavaFX bundles, and doesn't really fit in a standalone FX release. > > We are looking at the possibility of providing a replacement packaging > tool in OpenJDK. > > -- Kevin > > > On 5/15/2018 3:16 PM, Alan Snyder wrote: > >> Where does java packager fit in this? >> >> >> On May 15, 2018, at 2:59 PM, Kevin Rushforth >>> wrote: >>> >>> I wanted to update you on the progress of the last couple weeks on the >>> OpenJFX project: >>> >>> 1. As mentioned last week, we now have EA builds of OpenJFX 11 on >>> java.net [1]. We intend to update this roughly weekly. Currently the >>> build numbers match the corresponding JDK build number, but that will not >>> necessarily be the case going forward, so don't assume that they are in >>> sync. >>> >>> 2. Barring any build or staging issues, this week's OpenJFX 11 EA build >>> will include the jmods as mentioned earlier [2] [3] >>> >>> 3. JavaFX has been removed from JDK 11 as of this week. Starting with >>> jdk-11+14, early access builds of JDK 11 will not include JavaFX. >>> >>> 4. After jdk-11+14 is posted on java.net, and FX is no longer included >>> in JDK 11, we will start using openjfx-11 as the fix version in JBS to >>> distinguish it from JDK 11. We still expect to do a release of JavaFX 11 >>> around the same time as JDK 11, but using a different release number will >>> help track the actual content of JavaFX 11 separately from JDK 11. >>> >>> 5. Once this settles down, possibly later this week, I hope to restart >>> the discussion about OpenJFX policies, etc. I also hope to be a bit more >>> responsive over the coming days / weeks than I have been for the last 3-4 >>> weeks. Getting the standalone OpenJFX working and removing JavaFX from the >>> JDK was quite time consuming as you can probably imagine. >>> >>> If you have any general comments or questions about any of this, please >>> reply to this thread. We may want to split out more detailed discussions >>> into their own thread to make it easier to follow. >>> >>> -- Kevin >>> >>> [1] http://jdk.java.net/openjfx/ >>> >>> [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/ >>> 021856.html >>> [3] https://bugs.openjdk.java.net/browse/JDK-8202368 >>> >>> > -- Michael Ennen From kevin.rushforth at oracle.com Wed May 16 20:08:44 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 May 2018 13:08:44 -0700 Subject: OpenJFX status update In-Reply-To: References: Message-ID: Yes, the source code for javapackager is fully open source. -- Kevin On 5/16/2018 1:05 PM, Michael Ennen wrote: > Is the source code for javapackager fully open source? > > Thanks. > > On Wed, May 16, 2018 at 10:08 AM, Kevin Rushforth > > wrote: > > The javapackager was removed from the Oracle JDK along with JavaFX > (and has never been part of OpenJDK). It isn't included with the > standalone JavaFX bundles, and doesn't really fit in a standalone > FX release. > > We are looking at the possibility of providing a replacement > packaging tool in OpenJDK. > > -- Kevin > > > On 5/15/2018 3:16 PM, Alan Snyder wrote: > > Where does java packager fit in this? > > > On May 15, 2018, at 2:59 PM, Kevin Rushforth > > wrote: > > I wanted to update you on the progress of the last couple > weeks on the OpenJFX project: > > 1. As mentioned last week, we now have EA builds of > OpenJFX 11 on java.net [1]. We intend to > update this roughly weekly. Currently the build numbers > match the corresponding JDK build number, but that will > not necessarily be the case going forward, so don't assume > that they are in sync. > > 2. Barring any build or staging issues, this week's > OpenJFX 11 EA build will include the jmods as mentioned > earlier [2] [3] > > 3. JavaFX has been removed from JDK 11 as of this week. > Starting with jdk-11+14, early access builds of JDK 11 > will not include JavaFX. > > 4. After jdk-11+14 is posted on java.net > , and FX is no longer included in JDK 11, > we will start using openjfx-11 as the fix version in JBS > to distinguish it from JDK 11. We still expect to do a > release of JavaFX 11 around the same time as JDK 11, but > using a different release number will help track the > actual content of JavaFX 11 separately from JDK 11. > > 5. Once this settles down, possibly later this week, I > hope to restart the discussion about OpenJFX policies, > etc. I also hope to be a bit more responsive over the > coming days / weeks than I have been for the last 3-4 > weeks. Getting the standalone OpenJFX working and removing > JavaFX from the JDK was quite time consuming as you can > probably imagine. > > If you have any general comments or questions about any of > this, please reply to this thread. We may want to split > out more detailed discussions into their own thread to > make it easier to follow. > > -- Kevin > > [1] http://jdk.java.net/openjfx/ > > [2] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021856.html > > [3] https://bugs.openjdk.java.net/browse/JDK-8202368 > > > > > > > -- > Michael Ennen From mike.ennen at gmail.com Wed May 16 20:11:20 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 16 May 2018 13:11:20 -0700 Subject: OpenJFX status update In-Reply-To: References: Message-ID: Alright great, no complaints from me then :). On Wed, May 16, 2018 at 1:08 PM, Kevin Rushforth wrote: > Yes, the source code for javapackager is fully open source. > > -- Kevin > > > > On 5/16/2018 1:05 PM, Michael Ennen wrote: > > Is the source code for javapackager fully open source? > > Thanks. > > On Wed, May 16, 2018 at 10:08 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> The javapackager was removed from the Oracle JDK along with JavaFX (and >> has never been part of OpenJDK). It isn't included with the standalone >> JavaFX bundles, and doesn't really fit in a standalone FX release. >> >> We are looking at the possibility of providing a replacement packaging >> tool in OpenJDK. >> >> -- Kevin >> >> >> On 5/15/2018 3:16 PM, Alan Snyder wrote: >> >>> Where does java packager fit in this? >>> >>> >>> On May 15, 2018, at 2:59 PM, Kevin Rushforth >>>> wrote: >>>> >>>> I wanted to update you on the progress of the last couple weeks on the >>>> OpenJFX project: >>>> >>>> 1. As mentioned last week, we now have EA builds of OpenJFX 11 on >>>> java.net [1]. We intend to update this roughly weekly. Currently the >>>> build numbers match the corresponding JDK build number, but that will not >>>> necessarily be the case going forward, so don't assume that they are in >>>> sync. >>>> >>>> 2. Barring any build or staging issues, this week's OpenJFX 11 EA build >>>> will include the jmods as mentioned earlier [2] [3] >>>> >>>> 3. JavaFX has been removed from JDK 11 as of this week. Starting with >>>> jdk-11+14, early access builds of JDK 11 will not include JavaFX. >>>> >>>> 4. After jdk-11+14 is posted on java.net, and FX is no longer included >>>> in JDK 11, we will start using openjfx-11 as the fix version in JBS to >>>> distinguish it from JDK 11. We still expect to do a release of JavaFX 11 >>>> around the same time as JDK 11, but using a different release number will >>>> help track the actual content of JavaFX 11 separately from JDK 11. >>>> >>>> 5. Once this settles down, possibly later this week, I hope to restart >>>> the discussion about OpenJFX policies, etc. I also hope to be a bit more >>>> responsive over the coming days / weeks than I have been for the last 3-4 >>>> weeks. Getting the standalone OpenJFX working and removing JavaFX from the >>>> JDK was quite time consuming as you can probably imagine. >>>> >>>> If you have any general comments or questions about any of this, please >>>> reply to this thread. We may want to split out more detailed discussions >>>> into their own thread to make it easier to follow. >>>> >>>> -- Kevin >>>> >>>> [1] http://jdk.java.net/openjfx/ >>>> >>>> [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/ >>>> 021856.html >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8202368 >>>> >>>> >> > > > -- > Michael Ennen > > > -- Michael Ennen From swpalmer at gmail.com Wed May 16 20:28:27 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 16 May 2018 16:28:27 -0400 Subject: OpenJFX status update In-Reply-To: References: Message-ID: <48780552-BE48-4EE8-9417-270712F9428D@gmail.com> It needs a lot of work. I?m reminded as a see all the issues I?ve reported against it are being reassigned today. Despite the issues, Javapackager was one of the best things to happen for Java deployment in many years. I?m kinda bummed that it didn?t make it to OpenJDK. jlink isn?t really usable for me, as it requires everything to be 100% modularized, and that is next to impossible to achieve if you have any external dependencies. There is an issue to have jlink create a native launcher though: https://bugs.openjdk.java.net/browse/JDK-8182555 (You would think the javapackager guy and the jlink guy would talk to each other at some point? if such people are still around.) Cheers, Scott > On May 16, 2018, at 4:11 PM, Michael Ennen wrote: > > Alright great, no complaints from me then :). > > On Wed, May 16, 2018 at 1:08 PM, Kevin Rushforth >> wrote: > >> Yes, the source code for javapackager is fully open source. >> >> -- Kevin >> >> >> >> On 5/16/2018 1:05 PM, Michael Ennen wrote: >> >> Is the source code for javapackager fully open source? >> >> Thanks. >> >> On Wed, May 16, 2018 at 10:08 AM, Kevin Rushforth < >> kevin.rushforth at oracle.com > wrote: >> >>> The javapackager was removed from the Oracle JDK along with JavaFX (and >>> has never been part of OpenJDK). It isn't included with the standalone >>> JavaFX bundles, and doesn't really fit in a standalone FX release. >>> >>> We are looking at the possibility of providing a replacement packaging >>> tool in OpenJDK. >>> >>> -- Kevin From paulrussell70 at gmail.com Thu May 17 07:40:30 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Thu, 17 May 2018 08:40:30 +0100 Subject: openjfx-dev Digest, Vol 78, Issue 28 In-Reply-To: References: Message-ID: >We are looking at the possibility of providing a replacement packaging tool in OpenJDK. +1 for this. Or something like a Maven Shade build with an exacting set of dependency exclusions, and Launch4J would accomplish something similar? Has the advantage that all the other plugins like resources, and obfuscation can run in one automated build. I currently use this method. On 16 May 2018 at 21:28, 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: OpenJFX status update (Kevin Rushforth) > 2. Re: OpenJFX status update (Michael Ennen) > 3. Re: OpenJFX status update (Kevin Rushforth) > 4. Re: OpenJFX status update (Michael Ennen) > 5. Re: OpenJFX status update (Scott Palmer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 16 May 2018 12:06:40 -0700 > From: Kevin Rushforth > To: Nir Lisker > Cc: "openjfx-dev at openjdk.java.net" > Subject: Re: OpenJFX status update > Message-ID: <82914c4a-2349-6251-4d8c-c0b92f8c1609 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > > On 5/16/2018 11:54 AM, Nir Lisker wrote: > > What will happen to the JavaDocs? Will they be removed from the EA > > docs and upon release from the release docs? > > Correct. The JDK 11 docs will no longer include JavaFX modules and > classes. We will need to host separate docs for JavaFX. > > -- Kevin > > > > ------------------------------ > > Message: 2 > Date: Wed, 16 May 2018 13:05:04 -0700 > From: Michael Ennen > To: Kevin Rushforth > Cc: Alan Snyder , > "openjfx-dev at openjdk.java.net" > Subject: Re: OpenJFX status update > Message-ID: > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Is the source code for javapackager fully open source? > > Thanks. > > On Wed, May 16, 2018 at 10:08 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > > > The javapackager was removed from the Oracle JDK along with JavaFX (and > > has never been part of OpenJDK). It isn't included with the standalone > > JavaFX bundles, and doesn't really fit in a standalone FX release. > > > > We are looking at the possibility of providing a replacement packaging > > tool in OpenJDK. > > > > -- Kevin > > > > > > On 5/15/2018 3:16 PM, Alan Snyder wrote: > > > >> Where does java packager fit in this? > >> > >> > >> On May 15, 2018, at 2:59 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> > >>> wrote: > >>> > >>> I wanted to update you on the progress of the last couple weeks on the > >>> OpenJFX project: > >>> > >>> 1. As mentioned last week, we now have EA builds of OpenJFX 11 on > >>> java.net [1]. We intend to update this roughly weekly. Currently the > >>> build numbers match the corresponding JDK build number, but that will > not > >>> necessarily be the case going forward, so don't assume that they are in > >>> sync. > >>> > >>> 2. Barring any build or staging issues, this week's OpenJFX 11 EA build > >>> will include the jmods as mentioned earlier [2] [3] > >>> > >>> 3. JavaFX has been removed from JDK 11 as of this week. Starting with > >>> jdk-11+14, early access builds of JDK 11 will not include JavaFX. > >>> > >>> 4. After jdk-11+14 is posted on java.net, and FX is no longer included > >>> in JDK 11, we will start using openjfx-11 as the fix version in JBS to > >>> distinguish it from JDK 11. We still expect to do a release of JavaFX > 11 > >>> around the same time as JDK 11, but using a different release number > will > >>> help track the actual content of JavaFX 11 separately from JDK 11. > >>> > >>> 5. Once this settles down, possibly later this week, I hope to restart > >>> the discussion about OpenJFX policies, etc. I also hope to be a bit > more > >>> responsive over the coming days / weeks than I have been for the last > 3-4 > >>> weeks. Getting the standalone OpenJFX working and removing JavaFX from > the > >>> JDK was quite time consuming as you can probably imagine. > >>> > >>> If you have any general comments or questions about any of this, please > >>> reply to this thread. We may want to split out more detailed > discussions > >>> into their own thread to make it easier to follow. > >>> > >>> -- Kevin > >>> > >>> [1] http://jdk.java.net/openjfx/ > >>> > >>> [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/ > >>> 021856.html > >>> [3] https://bugs.openjdk.java.net/browse/JDK-8202368 > >>> > >>> > > > > > -- > Michael Ennen > > > ------------------------------ > > Message: 3 > Date: Wed, 16 May 2018 13:08:44 -0700 > From: Kevin Rushforth > To: Michael Ennen > Cc: Alan Snyder , > "openjfx-dev at openjdk.java.net" > Subject: Re: OpenJFX status update > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > Yes, the source code for javapackager is fully open source. > > -- Kevin > > > On 5/16/2018 1:05 PM, Michael Ennen wrote: > > Is the source code for javapackager fully open source? > > > > Thanks. > > > > On Wed, May 16, 2018 at 10:08 AM, Kevin Rushforth > > > wrote: > > > > The javapackager was removed from the Oracle JDK along with JavaFX > > (and has never been part of OpenJDK). It isn't included with the > > standalone JavaFX bundles, and doesn't really fit in a standalone > > FX release. > > > > We are looking at the possibility of providing a replacement > > packaging tool in OpenJDK. > > > > -- Kevin > > > > > > On 5/15/2018 3:16 PM, Alan Snyder wrote: > > > > Where does java packager fit in this? > > > > > > On May 15, 2018, at 2:59 PM, Kevin Rushforth > > > > wrote: > > > > I wanted to update you on the progress of the last couple > > weeks on the OpenJFX project: > > > > 1. As mentioned last week, we now have EA builds of > > OpenJFX 11 on java.net [1]. We intend to > > update this roughly weekly. Currently the build numbers > > match the corresponding JDK build number, but that will > > not necessarily be the case going forward, so don't assume > > that they are in sync. > > > > 2. Barring any build or staging issues, this week's > > OpenJFX 11 EA build will include the jmods as mentioned > > earlier [2] [3] > > > > 3. JavaFX has been removed from JDK 11 as of this week. > > Starting with jdk-11+14, early access builds of JDK 11 > > will not include JavaFX. > > > > 4. After jdk-11+14 is posted on java.net > > , and FX is no longer included in JDK 11, > > we will start using openjfx-11 as the fix version in JBS > > to distinguish it from JDK 11. We still expect to do a > > release of JavaFX 11 around the same time as JDK 11, but > > using a different release number will help track the > > actual content of JavaFX 11 separately from JDK 11. > > > > 5. Once this settles down, possibly later this week, I > > hope to restart the discussion about OpenJFX policies, > > etc. I also hope to be a bit more responsive over the > > coming days / weeks than I have been for the last 3-4 > > weeks. Getting the standalone OpenJFX working and removing > > JavaFX from the JDK was quite time consuming as you can > > probably imagine. > > > > If you have any general comments or questions about any of > > this, please reply to this thread. We may want to split > > out more detailed discussions into their own thread to > > make it easier to follow. > > > > -- Kevin > > > > [1] http://jdk.java.net/openjfx/ > > > > [2] > > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018- > May/021856.html > > May/021856.html> > > [3] https://bugs.openjdk.java.net/browse/JDK-8202368 > > > > > > > > > > > > > > -- > > Michael Ennen > > > > ------------------------------ > > Message: 4 > Date: Wed, 16 May 2018 13:11:20 -0700 > From: Michael Ennen > To: Kevin Rushforth > Cc: Alan Snyder , > "openjfx-dev at openjdk.java.net" > Subject: Re: OpenJFX status update > Message-ID: > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Alright great, no complaints from me then :). > > On Wed, May 16, 2018 at 1:08 PM, Kevin Rushforth < > kevin.rushforth at oracle.com > > wrote: > > > Yes, the source code for javapackager is fully open source. > > > > -- Kevin > > > > > > > > On 5/16/2018 1:05 PM, Michael Ennen wrote: > > > > Is the source code for javapackager fully open source? > > > > Thanks. > > > > On Wed, May 16, 2018 at 10:08 AM, Kevin Rushforth < > > kevin.rushforth at oracle.com> wrote: > > > >> The javapackager was removed from the Oracle JDK along with JavaFX (and > >> has never been part of OpenJDK). It isn't included with the standalone > >> JavaFX bundles, and doesn't really fit in a standalone FX release. > >> > >> We are looking at the possibility of providing a replacement packaging > >> tool in OpenJDK. > >> > >> -- Kevin > >> > >> > >> On 5/15/2018 3:16 PM, Alan Snyder wrote: > >> > >>> Where does java packager fit in this? > >>> > >>> > >>> On May 15, 2018, at 2:59 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> > >>>> wrote: > >>>> > >>>> I wanted to update you on the progress of the last couple weeks on the > >>>> OpenJFX project: > >>>> > >>>> 1. As mentioned last week, we now have EA builds of OpenJFX 11 on > >>>> java.net [1]. We intend to update this roughly weekly. Currently the > >>>> build numbers match the corresponding JDK build number, but that will > not > >>>> necessarily be the case going forward, so don't assume that they are > in > >>>> sync. > >>>> > >>>> 2. Barring any build or staging issues, this week's OpenJFX 11 EA > build > >>>> will include the jmods as mentioned earlier [2] [3] > >>>> > >>>> 3. JavaFX has been removed from JDK 11 as of this week. Starting with > >>>> jdk-11+14, early access builds of JDK 11 will not include JavaFX. > >>>> > >>>> 4. After jdk-11+14 is posted on java.net, and FX is no longer > included > >>>> in JDK 11, we will start using openjfx-11 as the fix version in JBS to > >>>> distinguish it from JDK 11. We still expect to do a release of JavaFX > 11 > >>>> around the same time as JDK 11, but using a different release number > will > >>>> help track the actual content of JavaFX 11 separately from JDK 11. > >>>> > >>>> 5. Once this settles down, possibly later this week, I hope to restart > >>>> the discussion about OpenJFX policies, etc. I also hope to be a bit > more > >>>> responsive over the coming days / weeks than I have been for the last > 3-4 > >>>> weeks. Getting the standalone OpenJFX working and removing JavaFX > from the > >>>> JDK was quite time consuming as you can probably imagine. > >>>> > >>>> If you have any general comments or questions about any of this, > please > >>>> reply to this thread. We may want to split out more detailed > discussions > >>>> into their own thread to make it easier to follow. > >>>> > >>>> -- Kevin > >>>> > >>>> [1] http://jdk.java.net/openjfx/ > >>>> > >>>> [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/ > >>>> 021856.html > >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8202368 > >>>> > >>>> > >> > > > > > > -- > > Michael Ennen > > > > > > > > > -- > Michael Ennen > > > ------------------------------ > > Message: 5 > Date: Wed, 16 May 2018 16:28:27 -0400 > From: Scott Palmer > To: Michael Ennen > Cc: Alan Snyder , > "openjfx-dev at openjdk.java.net" > Subject: Re: OpenJFX status update > Message-ID: <48780552-BE48-4EE8-9417-270712F9428D at gmail.com> > Content-Type: text/plain; charset=utf-8 > > It needs a lot of work. I?m reminded as a see all the issues I?ve > reported against it are being reassigned today. > > Despite the issues, Javapackager was one of the best things to happen for > Java deployment in many years. I?m kinda bummed that it didn?t make it to > OpenJDK. > > jlink isn?t really usable for me, as it requires everything to be 100% > modularized, and that is next to impossible to achieve if you have any > external dependencies. > > There is an issue to have jlink create a native launcher though: > https://bugs.openjdk.java.net/browse/JDK-8182555 < > https://bugs.openjdk.java.net/browse/JDK-8182555> > > (You would think the javapackager guy and the jlink guy would talk to each > other at some point? if such people are still around.) > > Cheers, > > Scott > > > > On May 16, 2018, at 4:11 PM, Michael Ennen wrote: > > > > Alright great, no complaints from me then :). > > > > On Wed, May 16, 2018 at 1:08 PM, Kevin Rushforth < > kevin.rushforth at oracle.com > >> wrote: > > > >> Yes, the source code for javapackager is fully open source. > >> > >> -- Kevin > >> > >> > >> > >> On 5/16/2018 1:05 PM, Michael Ennen wrote: > >> > >> Is the source code for javapackager fully open source? > >> > >> Thanks. > >> > >> On Wed, May 16, 2018 at 10:08 AM, Kevin Rushforth < > >> kevin.rushforth at oracle.com > wrote: > >> > >>> The javapackager was removed from the Oracle JDK along with JavaFX (and > >>> has never been part of OpenJDK). It isn't included with the standalone > >>> JavaFX bundles, and doesn't really fit in a standalone FX release. > >>> > >>> We are looking at the possibility of providing a replacement packaging > >>> tool in OpenJDK. > >>> > >>> -- Kevin > > > End of openjfx-dev Digest, Vol 78, Issue 28 > ******************************************* > From youngty1997 at gmail.com Thu May 17 10:16:46 2018 From: youngty1997 at gmail.com (Ty Young) Date: Thu, 17 May 2018 05:16:46 -0500 Subject: OpenJFX status update In-Reply-To: <27c67144-7b3d-311d-2479-f8a73d851dd5@oracle.com> References: <27c67144-7b3d-311d-2479-f8a73d851dd5@oracle.com> Message-ID: <8762a0df-cde9-1e01-3000-7faa463fd2df@gmail.com> On 05/16/2018 02:04 PM, Kevin Rushforth wrote: > > > On 5/16/2018 10:49 AM, Ty Young wrote: > >> That one, as mentioned in the wiki build guide. I get an immediate >> build fail(see: https://pastebin.com/geR4LLMm). The JDK works just >> fine: I can set it as the default JDK, run Netbeans, set the project >> source to 11, and my application builds just fine. > > Ah, I see. You didn't say what version of gradle or JDK you were > using, but this looks like a known problem in trying to run gradle > with JDK 11. See: > > https://github.com/gradle/gradle/issues/4860 > https://bugs.openjdk.java.net/browse/JDK-8199069 > > This is marked as fixed in gradle 4.8-rc1, but I haven't confirmed this. > I have every Oracle JDK and OpenJDK version from 8 and above installed. I had assumed that Oracle JDK(s) were required because they were the only ones that would work as OpenJDK 9 and 10 builds in Arch Linux don't support JavaFX and using a self compiled JDK 11 isn't possible due to that bug. I'm using Gradle 4.7 and Oracle JDK 10 to build. >>>> And could the new standalone modules be integrated with the source >>>> code somehow so that a JDK without JavaFX support can be compiled? >>> >>> Not sure what you mean, but you can use an OpenJDK without modules + >>> the JavaFX standalone modules to build and run your program. >>> >>> >> >> It's an option, sure. My problem with it is that it creates so much >> unnecessary disk usage because each bundled application requires it's >> own copy of JavaFX. If you had 10 standalone JavaFX applications it >> would be 1GB easily if they where all modular projects, which are >> around 106MB for me. Creating an app bundle using classpath is around >> 200MB(post JDK 8 was 250+ IIRC). > > > One option for you would be to use jlink to create a jre image that > includes the javafx modules. This week's openjfx-11-ea+14 build will > have a jmods bundle that you can use for this purpose. > So like it was done with OpenJDK 8 overlay but just with modules instead, basically? > >>>> As I wrote before and am still having issues with, after a >>>> successful first compile, JavaFX no longer compiles in Arch Linux >>>> for me. Any attempt to do so results in a bunch of warning >>>> messages(see: https://pastebin.com/rJqu7Nws) which cause the build >>>> to fail due to warnings being treated as errors(Should they even be >>>> ignored?). In addition. I'm now getting a GCC warning about XIMProc >>>> returning an int when it should return void (*). I don't know C or >>>> the native APIs so right now I'm at a loss of what to do besides >>>> trying to compile on another distro - which is something I *really* >>>> would prefer not to have to do. >>> >>> What gcc version are you using? And what Linux distro? >>> >> >> 8.1.0 and Arch Linux(Antergos which is basically Arch Linux). > > > That's not a distro I'm familiar with, but it may or may not be > related to the issue you are seeing. The gcc errors may be related to > compiling with a more-strict 8.1 compiler; we have tested with up to > gcc 7.3, but nothing newer than that. A quick look suggests that we > will need some way to suppress that warning. For now, you can modify > buildSrc/linux.gradle and remove the "-Werror" flag from > LINUX.glass.glassgtk2.ccFlags (ditto for gtk3). > Arch Linux uses the rolling release update model, so it usually gets the newest software before any other Linux distro. Removing -Werror from those two lines got me a compile, though with many more warnings. However, attempting to compile an OpenJDK with JavaFX results in its own build fail due to jdk packager module being missing in the JavaFX build. See: https://pastebin.com/MzFLDxgK I tried copying the modular src files from a previous build and pasting them into the new one that doesn't have it and now I just get a build fail saying that JDK packager is marked for deprecation. I take it JDK Packager is in the process of being removed then? > -- Kevin > > >> >> >>> -- Kevin >>> >> > From matthew.james.elliot at gmail.com Thu May 17 14:04:09 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Thu, 17 May 2018 16:04:09 +0200 Subject: Matrox Graphics Cards Problems Message-ID: Hi all, we have some customers in the wild who use Matrox 9148LP (9100 series) graphics cards because they drive more than 2 monitors and JavaFX always reports an error initializing HW pipeline and forcing gpu results in system instability. I checked the bug reports but couldn't see anything about JavaFX and Matrox cards. Questions Is anyone aware of an existing issue? Is there a way to get more details on why JavaFx fails to enable the D3D pipeline? Is there a list of known problematic graphics cards or a black list of graphics cards where JavaFX falls back? Thanks in advance, Matt From nlisker at gmail.com Thu May 17 14:08:24 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 17 May 2018 17:08:24 +0300 Subject: Matrox Graphics Cards Problems In-Reply-To: References: Message-ID: Hi Matthew, Is there a way to get more details on why JavaFx fails to enable the D3D > pipeline? Add the VM argument -Dprism.verbose=true and post what it spits. - Nir On Thu, May 17, 2018 at 5:04 PM, Matthew Elliot < matthew.james.elliot at gmail.com> wrote: > Hi all, > > we have some customers in the wild who use Matrox 9148LP (9100 series) > graphics cards because they drive more than 2 monitors and JavaFX always > reports an error initializing HW pipeline and forcing gpu results in system > instability. > > I checked the bug reports but couldn't see anything about JavaFX and Matrox > cards. > > Questions > Is anyone aware of an existing issue? > Is there a way to get more details on why JavaFx fails to enable the D3D > pipeline? > Is there a list of known problematic graphics cards or a black list of > graphics cards where JavaFX falls back? > > Thanks in advance, > Matt > From powers.anirvan at gmail.com Thu May 17 15:15:03 2018 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Fri, 18 May 2018 00:15:03 +0900 Subject: Matrox Graphics Cards Problems In-Reply-To: References: Message-ID: Hi Matthew, Please see the below file for blaclisted hardware on D3D. http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/9e0e0e65e642/modules/javafx.graphics/src/main/native-prism-d3d/D3DBadHardware.h Regards, Anirvan On Thu, 17 May 2018 at 11:04 PM, Matthew Elliot < matthew.james.elliot at gmail.com> wrote: > Hi all, > > we have some customers in the wild who use Matrox 9148LP (9100 series) > graphics cards because they drive more than 2 monitors and JavaFX always > reports an error initializing HW pipeline and forcing gpu results in system > instability. > > I checked the bug reports but couldn't see anything about JavaFX and Matrox > cards. > > Questions > Is anyone aware of an existing issue? > Is there a way to get more details on why JavaFx fails to enable the D3D > pipeline? > Is there a list of known problematic graphics cards or a black list of > graphics cards where JavaFX falls back? > > Thanks in advance, > Matt > -- Sent from Gmail Mobile From murali.billa at oracle.com Thu May 17 17:49:31 2018 From: murali.billa at oracle.com (Murali Billa) Date: Thu, 17 May 2018 10:49:31 -0700 (PDT) Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger In-Reply-To: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> References: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> Message-ID: Hi Nir, ? Regarding ?com.sun.javafx.webkit.drt.DumpRenderTree?, you can comment out the below code in ?main? method from DumpRenderTree.java file. ? ??? if ( isDebug() ) { ??????????? log.setLevel(Level.FINEST); ??????????? FileHandler handler = new FileHandler("drt.log", true); ??????????? handler.setFormatter(new Formatter() { ??????????????? @Override ??????????????? public String format(LogRecord record) { ??????????????????? return formatMessage(record) + "\n"; ??????????????? } ??????????? }); ??????????? log.addHandler(handler); ??? } ? Thanks, MUrali From: Murali Billa Sent: Thursday, May 03, 2018 1:52 AM To: Nir Lisker Cc: openjfx-dev at openjdk.java.net Mailing Subject: RE: JDK-8195974: Replace use of java.util.logging in javafx with System logger ? Hi Nir, ? 1)????? Regarding ?verbose? flag usage:? ????????? Currently verbose flag is used to show log Levels (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl. ?I feel it is not desirable to remove this flag as all these logs will start appearing now by default. ????????? We can try 2 options: a)?????? 1st Option: We can change all INFO log messages to FINE ?under verbose flag (by leaving all log messages that use Level other than INFO unchanged) and verbose flag can be removed. b)????? If 1st option results in too much noise for WARNING log messages, then we can keep the verbose flag and introduce a System Property (for ex: javafx.web.verbose) to enable the flag. I won?t suggest reading level value from log/config file. ? 2)????? Regarding ??com.sun.javafx.webkit.drt.DumpRenderTree?,? I need to check few more things (since we use ?addHandler? in drt) and will get back to you. ? Please let me know, if you have any queries for 1. Thanks, Murali From: Nir Lisker Sent: Saturday, April 28, 2018 1:06 AM To: Murali Billa Cc: HYPERLINK "mailto:openjfx-dev at openjdk.java.net"openjfx-dev at openjdk.java.net Mailing Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger ? Hi Murali, ? Can you have a look at?https://bugs.openjdk.java.net/browse/JDK-8195974 please? ? There are some usages of j.u.l in the web module I'd like your opinion on. I'm not familiar with the intent of these pieces of code and would like to know what the options are for advancing with this issue on that front. ? Thanks, Nir From johan.vos at gluonhq.com Thu May 17 19:25:26 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 17 May 2018 21:25:26 +0200 Subject: bundling native libs in jars or modules Message-ID: Note: This is different from what is discussed in http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021762.html The following text is about bundling native code within a jar, and doesn't talk about how to deal with platform-specific libraries in generic jar files. At this moment, the standalone SDK for JavaFX 11-ea works fine, and javafx apps can be executed since the javafx jars will load the required native code from the libs that are part of the SDK. When we want to download the javafx modules as modules (or jars with module-info), we don't have a local SDK with native libraries. The native libraries need to come with the downloaded jar. There are a number of options to do this, and a number of ongoing discussions (e.g. see http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001541.html). In summary, jmods already have support for native code but they are not scoped at runtime, and jars don't have a standard way for supporting native code. I hope there will be a long-term solution for this in the VM in the future, but clearly we can't rely on this for the 11 release. Hence, we need to provide some JavaFX-specific fixes. Just to try the mechanism, I created a quick (and dirty) workaround in the NativeLibLoader. I committed it to a nativelibs branch of my openjfx fork: https://github.com/johanvos/openjdk-jfx/commit/f2c4c57a6197634e9c3bc1298ea14700057155a3 The good thing is that all JavaFX native lib loading is already delegated to the NativeLibLoader, so I only had to patch one file. I modified the generated javafx.graphics.jar to include all libs that are generated (something that can be automated in a gradle task), and could successfully run javafx apps using java -p /path/to/my/jars --add-modules javafx.controls without specifying java.library.path or native libs or so. This works for jars that I put myself on the classpath, hence it should also work for jars downloaded from maven central etc. In case there will be a standard for bundling native libs with jar files in a future JVM, we can remove this hack. But even in the meantime, there are better solutions. One of the best options I think we should consider is using JavaCPP ( https://github.com/bytedeco/javacpp) . The main author of JavaCPP, Samuel Audet (in cc) describes here ( https://github.com/tensorflow/tensorflow/issues/18397#issuecomment-381371636) why my hack will fail on Windows. Another advantage of JavaCPP is that it is proven to work on ios and Android as well. Actually, that would allow us to get rid of the ios-specific code that is currently in NativeLibLoader.java. Again, this is only tackling the issue of bunding native code with jars and not dealing with platform-specific resolution (although JavaCPP can help there as well). - Johan From matthew.james.elliot at gmail.com Thu May 17 19:32:33 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Thu, 17 May 2018 21:32:33 +0200 Subject: Matrox Graphics Cards Problems In-Reply-To: References: Message-ID: <2AB80E85-BEE8-486F-87A2-0EA3FA210A73@gmail.com> Hey, thanks for the second link, exactly what I needed just not the best news. I see all Matrox cards are disabled which is a bit tricky for us when many of our customers are have 4+ monitors and some have chosen those cards. I then managed to find this - https://bugs.openjdk.java.net/browse/JDK-8103350 I assume this means there will never be support of these cards or is there a work around? I.e. I see they support OpenGL so could I install OpenGL on a windows machine and try that pipeline? Is this exclusion of all Matrox cards still valid? Thanks in advance, Matt Sent from my phone. > On 17/05/2018, at 5:15 PM, Anirvan Sarkar wrote: > > Hi Matthew, > > Please see the below file for blaclisted hardware on D3D. > > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/9e0e0e65e642/modules/javafx.graphics/src/main/native-prism-d3d/D3DBadHardware.h > > Regards, > Anirvan > > >> On Thu, 17 May 2018 at 11:04 PM, Matthew Elliot wrote: >> Hi all, >> >> we have some customers in the wild who use Matrox 9148LP (9100 series) >> graphics cards because they drive more than 2 monitors and JavaFX always >> reports an error initializing HW pipeline and forcing gpu results in system >> instability. >> >> I checked the bug reports but couldn't see anything about JavaFX and Matrox >> cards. >> >> Questions >> Is anyone aware of an existing issue? >> Is there a way to get more details on why JavaFx fails to enable the D3D >> pipeline? >> Is there a list of known problematic graphics cards or a black list of >> graphics cards where JavaFX falls back? >> >> Thanks in advance, >> Matt > -- > Sent from Gmail Mobile From tom.schindl at bestsolution.at Thu May 17 19:50:55 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 17 May 2018 21:50:55 +0200 Subject: bundling native libs in jars or modules In-Reply-To: References: Message-ID: Did you check how SWT does addresses the problem? If you run it outside of OSGi it needs to deal with this problem as well. Tom Von meinem iPhone gesendet > Am 17.05.2018 um 21:25 schrieb Johan Vos : > > Note: This is different from what is discussed in > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021762.html > > The following text is about bundling native code within a jar, and doesn't > talk about how to deal with platform-specific libraries in generic jar > files. > > At this moment, the standalone SDK for JavaFX 11-ea works fine, and javafx > apps can be executed since the javafx jars will load the required native > code from the libs that are part of the SDK. > > When we want to download the javafx modules as modules (or jars with > module-info), we don't have a local SDK with native libraries. The native > libraries need to come with the downloaded jar. There are a number of > options to do this, and a number of ongoing discussions (e.g. see > http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001541.html). > In summary, jmods already have support for native code but they are not > scoped at runtime, and jars don't have a standard way for supporting native > code. > > I hope there will be a long-term solution for this in the VM in the future, > but clearly we can't rely on this for the 11 release. > Hence, we need to provide some JavaFX-specific fixes. > Just to try the mechanism, I created a quick (and dirty) workaround in the > NativeLibLoader. I committed it to a nativelibs branch of my openjfx fork: > https://github.com/johanvos/openjdk-jfx/commit/f2c4c57a6197634e9c3bc1298ea14700057155a3 > > The good thing is that all JavaFX native lib loading is already delegated > to the NativeLibLoader, so I only had to patch one file. > > I modified the generated javafx.graphics.jar to include all libs that are > generated (something that can be automated in a gradle task), and could > successfully run javafx apps using > java -p /path/to/my/jars --add-modules javafx.controls > without specifying java.library.path or native libs or so. > > This works for jars that I put myself on the classpath, hence it should > also work for jars downloaded from maven central etc. > > In case there will be a standard for bundling native libs with jar files in > a future JVM, we can remove this hack. But even in the meantime, there are > better solutions. > One of the best options I think we should consider is using JavaCPP ( > https://github.com/bytedeco/javacpp) . The main author of JavaCPP, Samuel > Audet (in cc) describes here ( > https://github.com/tensorflow/tensorflow/issues/18397#issuecomment-381371636) > why my hack will fail on Windows. > > Another advantage of JavaCPP is that it is proven to work on ios and > Android as well. Actually, that would allow us to get rid of the > ios-specific code that is currently in NativeLibLoader.java. > > Again, this is only tackling the issue of bunding native code with jars and > not dealing with platform-specific resolution (although JavaCPP can help > there as well). > > - Johan From tom.schindl at bestsolution.at Thu May 17 19:59:06 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 17 May 2018 21:59:06 +0200 Subject: bundling native libs in jars or modules In-Reply-To: References: Message-ID: <40E3DAE7-A4E3-42C5-A146-358C2E7C6CE9@bestsolution.at> To answer my own question the trick swt uses is to encode the build-id into the dll/so so it never needs to delete a file See http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/Eclipse%20SWT%20PI/common/org/eclipse/swt/internal/Library.java#n144 Tom Von meinem iPhone gesendet > Am 17.05.2018 um 21:50 schrieb Tom Schindl : > > Did you check how SWT does addresses the problem? If you run it outside of OSGi it needs to deal with this problem as well. > > Tom > > Von meinem iPhone gesendet > >> Am 17.05.2018 um 21:25 schrieb Johan Vos : >> >> Note: This is different from what is discussed in >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021762.html >> >> The following text is about bundling native code within a jar, and doesn't >> talk about how to deal with platform-specific libraries in generic jar >> files. >> >> At this moment, the standalone SDK for JavaFX 11-ea works fine, and javafx >> apps can be executed since the javafx jars will load the required native >> code from the libs that are part of the SDK. >> >> When we want to download the javafx modules as modules (or jars with >> module-info), we don't have a local SDK with native libraries. The native >> libraries need to come with the downloaded jar. There are a number of >> options to do this, and a number of ongoing discussions (e.g. see >> http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001541.html). >> In summary, jmods already have support for native code but they are not >> scoped at runtime, and jars don't have a standard way for supporting native >> code. >> >> I hope there will be a long-term solution for this in the VM in the future, >> but clearly we can't rely on this for the 11 release. >> Hence, we need to provide some JavaFX-specific fixes. >> Just to try the mechanism, I created a quick (and dirty) workaround in the >> NativeLibLoader. I committed it to a nativelibs branch of my openjfx fork: >> https://github.com/johanvos/openjdk-jfx/commit/f2c4c57a6197634e9c3bc1298ea14700057155a3 >> >> The good thing is that all JavaFX native lib loading is already delegated >> to the NativeLibLoader, so I only had to patch one file. >> >> I modified the generated javafx.graphics.jar to include all libs that are >> generated (something that can be automated in a gradle task), and could >> successfully run javafx apps using >> java -p /path/to/my/jars --add-modules javafx.controls >> without specifying java.library.path or native libs or so. >> >> This works for jars that I put myself on the classpath, hence it should >> also work for jars downloaded from maven central etc. >> >> In case there will be a standard for bundling native libs with jar files in >> a future JVM, we can remove this hack. But even in the meantime, there are >> better solutions. >> One of the best options I think we should consider is using JavaCPP ( >> https://github.com/bytedeco/javacpp) . The main author of JavaCPP, Samuel >> Audet (in cc) describes here ( >> https://github.com/tensorflow/tensorflow/issues/18397#issuecomment-381371636) >> why my hack will fail on Windows. >> >> Another advantage of JavaCPP is that it is proven to work on ios and >> Android as well. Actually, that would allow us to get rid of the >> ios-specific code that is currently in NativeLibLoader.java. >> >> Again, this is only tackling the issue of bunding native code with jars and >> not dealing with platform-specific resolution (although JavaCPP can help >> there as well). >> >> - Johan > From nlisker at gmail.com Thu May 17 20:25:12 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 17 May 2018 23:25:12 +0300 Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger In-Reply-To: References: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> Message-ID: Thanks Murali, Iv'e also commented out isDebug() (though maybe it can be completely removed, only that the commented out code relies on it). Kevin, after this change, HelloService in the packager is the only one requiring file handling. What is the future of the packager now? Is it worth supplying an alternative for these classes? - Nir On Thu, May 17, 2018 at 8:49 PM, Murali Billa wrote: > Hi Nir, > > > > Regarding ?com.sun.javafx.webkit.drt.DumpRenderTree?, you can comment out > the below code in ?main? method from DumpRenderTree.java file. > > > > if ( isDebug() ) { > > log.setLevel(Level.FINEST); > > FileHandler handler = new FileHandler("drt.log", true); > > handler.setFormatter(new Formatter() { > > @Override > > public String format(LogRecord record) { > > return formatMessage(record) + "\n"; > > } > > }); > > log.addHandler(handler); > > } > > > > Thanks, > > MUrali > > *From:* Murali Billa > *Sent:* Thursday, May 03, 2018 1:52 AM > *To:* Nir Lisker > *Cc:* openjfx-dev at openjdk.java.net Mailing > *Subject:* RE: JDK-8195974: Replace use of java.util.logging in javafx > with System logger > > > > Hi Nir, > > > > 1) Regarding ?verbose? flag usage: > > ? Currently verbose flag is used to show log Levels > (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl. I feel > it is not desirable to remove this flag as all these logs will start > appearing now by default. > > ? We can try 2 options: > > a) 1st Option: We can change all INFO log messages to FINE under > verbose flag (by leaving all log messages that use Level other than INFO > unchanged) and verbose flag can be removed. > > b) If 1st option results in too much noise for WARNING log messages, > then we can keep the verbose flag and introduce a System Property (for ex: > javafx.web.verbose) to enable the flag. I won?t suggest reading level value > from log/config file. > > > > 2) Regarding ?com.sun.javafx.webkit.drt.DumpRenderTree?, I need to > check few more things (since we use ?addHandler? in drt) and will get back > to you. > > > > Please let me know, if you have any queries for 1. > > Thanks, > > Murali > > *From:* Nir Lisker > *Sent:* Saturday, April 28, 2018 1:06 AM > *To:* Murali Billa > *Cc:* openjfx-dev at openjdk.java.net Mailing > *Subject:* JDK-8195974: Replace use of java.util.logging in javafx with > System logger > > > > Hi Murali, > > > > Can you have a look at https://bugs.openjdk.java.net/browse/JDK-8195974 > please? > > > > There are some usages of j.u.l in the web module I'd like your opinion on. > I'm not familiar with the intent of these pieces of code and would like to > know what the options are for advancing with this issue on that front. > > > > Thanks, > > Nir > From kevin.rushforth at oracle.com Thu May 17 20:39:01 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 May 2018 13:39:01 -0700 Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger In-Reply-To: References: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> Message-ID: <69c1a966-984c-2058-bf0f-6d9d5c828a86@oracle.com> I think it isn't worth doing anything for the packager. In any case, since "HelloService" is a test program, I see no problem with it continuing to use java.util.logging. Regarding your other comment: > Thanks Murali, Iv'e also commented out isDebug() (though maybe it can > be completely removed, only that the commented out code relies on it). > There was one other place where isDebug() was called, that being the mLog method. Did you replace the call ti isDebug() with a direct call to isLoggable instead? Note that without the isLoggable check you will incur the redundant cost of the method calls + string construction. -- Kevin On 5/17/2018 1:25 PM, Nir Lisker wrote: > Thanks Murali, Iv'e also commented out isDebug() (though maybe it can > be completely removed, only that the commented out code relies on it). > > Kevin, after this change, HelloService in the packager is the only one > requiring file handling. What is the future of the packager now? Is it > worth supplying an alternative for these classes? > > - Nir > > On Thu, May 17, 2018 at 8:49 PM, Murali Billa > wrote: > > Hi Nir, > > Regarding ?com.sun.javafx.webkit.drt.DumpRenderTree?, you can > comment out the below code in ?main? method from > DumpRenderTree.java file. > > if ( isDebug() ) { > > log.setLevel(Level.FINEST); > > FileHandler handler = new FileHandler("drt.log", true); > > handler.setFormatter(new Formatter() { > > @Override > > public String format(LogRecord record) { > > return formatMessage(record) + "\n"; > > } > > }); > > log.addHandler(handler); > > } > > Thanks, > > MUrali > > *From:*Murali Billa > *Sent:* Thursday, May 03, 2018 1:52 AM > *To:* Nir Lisker > > *Cc:* openjfx-dev at openjdk.java.net > Mailing > > > *Subject:* RE: JDK-8195974: Replace use of java.util.logging in > javafx with System logger > > Hi Nir, > > 1)Regarding ?verbose? flag usage: > > ?Currently verbose flag is used to show log Levels > (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl.?I > feel it is not desirable to remove this flag as all these logs > will start appearing now by default. > > ?We can try 2 options: > > a)1^st Option: We can change all INFO log messages to FINE ?under > verbose flag (by leaving all log messages that use Level other > than INFO unchanged) and verbose flag can be removed. > > b)If 1^st option results in too much noise for WARNING log > messages, then we can keep the verbose flag and introduce a System > Property (for ex: javafx.web.verbose) to enable the flag. I won?t > suggest reading level value from log/config file. > > 2)Regarding ??com.sun.javafx.webkit.drt.DumpRenderTree?, I need to > check few more things (since we use ?addHandler? in drt) and will > get back to you. > > Please let me know, if you have any queries for 1. > > Thanks, > > Murali > > *From:*Nir Lisker > > *Sent:* Saturday, April 28, 2018 1:06 AM > *To:* Murali Billa > > *Cc:* openjfx-dev at openjdk.java.net > Mailing > > > *Subject:* JDK-8195974: Replace use of java.util.logging in javafx > with System logger > > Hi Murali, > > Can you have a look at > https://bugs.openjdk.java.net/browse/JDK-8195974 > please? > > There are some usages of j.u.l in the web module I'd like your > opinion on. I'm not familiar with the intent of these pieces of > code and would like to know what the options are for advancing > with this issue on that front. > > Thanks, > > Nir > > From nlisker at gmail.com Thu May 17 21:07:22 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 18 May 2018 00:07:22 +0300 Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger In-Reply-To: <69c1a966-984c-2058-bf0f-6d9d5c828a86@oracle.com> References: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> <69c1a966-984c-2058-bf0f-6d9d5c828a86@oracle.com> Message-ID: > > There was one other place where isDebug() was called, that being the mLog > method. Did you replace the call ti isDebug() with a direct call to > isLoggable instead? > Yes, I should have been clearer: I inlined `isDebug` into `mLog`, then commented out `isDebug` so that if someone reads the commented-out code in `main` they'll know what it is referring to. I just didn't see a point in leaving a private static method just for this one use. In any case, since "HelloService" is a test program, I see no problem with > it continuing to use java.util.logging. For Eclipse users this it still a problem since Eclipse includes the tests in the module (it was discussed in the JIRA issue). Since the packager is out of scope, I'll just patch the last remnant in test.com.sun.javafx.binding.ErrorLoggingUtiltity and submit a Webrev tomorrow or this weekend since all other changes are already prepared (and mostly trivial). - Nir On Thu, May 17, 2018 at 11:39 PM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > I think it isn't worth doing anything for the packager. In any case, since > "HelloService" is a test program, I see no problem with it continuing to > use java.util.logging. > > Regarding your other comment: > > Thanks Murali, Iv'e also commented out isDebug() (though maybe it can be > completely removed, only that the commented out code relies on it). > > > There was one other place where isDebug() was called, that being the mLog > method. Did you replace the call ti isDebug() with a direct call to > isLoggable instead? Note that without the isLoggable check you will incur > the redundant cost of the method calls + string construction. > > -- Kevin > > > > On 5/17/2018 1:25 PM, Nir Lisker wrote: > > Thanks Murali, Iv'e also commented out isDebug() (though maybe it can be > completely removed, only that the commented out code relies on it). > > Kevin, after this change, HelloService in the packager is the only one > requiring file handling. What is the future of the packager now? Is it > worth supplying an alternative for these classes? > > - Nir > > On Thu, May 17, 2018 at 8:49 PM, Murali Billa > wrote: > >> Hi Nir, >> >> >> >> Regarding ?com.sun.javafx.webkit.drt.DumpRenderTree?, you can comment >> out the below code in ?main? method from DumpRenderTree.java file. >> >> >> >> if ( isDebug() ) { >> >> log.setLevel(Level.FINEST); >> >> FileHandler handler = new FileHandler("drt.log", true); >> >> handler.setFormatter(new Formatter() { >> >> @Override >> >> public String format(LogRecord record) { >> >> return formatMessage(record) + "\n"; >> >> } >> >> }); >> >> log.addHandler(handler); >> >> } >> >> >> >> Thanks, >> >> MUrali >> >> *From:* Murali Billa >> *Sent:* Thursday, May 03, 2018 1:52 AM >> *To:* Nir Lisker >> *Cc:* openjfx-dev at openjdk.java.net Mailing >> *Subject:* RE: JDK-8195974: Replace use of java.util.logging in javafx >> with System logger >> >> >> >> Hi Nir, >> >> >> >> 1) Regarding ?verbose? flag usage: >> >> ? Currently verbose flag is used to show log Levels >> (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl. I feel >> it is not desirable to remove this flag as all these logs will start >> appearing now by default. >> >> ? We can try 2 options: >> >> a) 1st Option: We can change all INFO log messages to FINE under >> verbose flag (by leaving all log messages that use Level other than INFO >> unchanged) and verbose flag can be removed. >> >> b) If 1st option results in too much noise for WARNING log >> messages, then we can keep the verbose flag and introduce a System Property >> (for ex: javafx.web.verbose) to enable the flag. I won?t suggest reading >> level value from log/config file. >> >> >> >> 2) Regarding ?com.sun.javafx.webkit.drt.DumpRenderTree?, I need >> to check few more things (since we use ?addHandler? in drt) and will get >> back to you. >> >> >> >> Please let me know, if you have any queries for 1. >> >> Thanks, >> >> Murali >> >> *From:* Nir Lisker >> *Sent:* Saturday, April 28, 2018 1:06 AM >> *To:* Murali Billa >> *Cc:* openjfx-dev at openjdk.java.net Mailing >> *Subject:* JDK-8195974: Replace use of java.util.logging in javafx with >> System logger >> >> >> >> Hi Murali, >> >> >> >> Can you have a look at https://bugs.openjdk.java.net/browse/JDK-8195974 >> please? >> >> >> >> There are some usages of j.u.l in the web module I'd like your opinion >> on. I'm not familiar with the intent of these pieces of code and would like >> to know what the options are for advancing with this issue on that front. >> >> >> >> Thanks, >> >> Nir >> > > > From kevin.rushforth at oracle.com Thu May 17 21:52:27 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 May 2018 14:52:27 -0700 Subject: OpenJFX status update In-Reply-To: <8762a0df-cde9-1e01-3000-7faa463fd2df@gmail.com> References: <27c67144-7b3d-311d-2479-f8a73d851dd5@oracle.com> <8762a0df-cde9-1e01-3000-7faa463fd2df@gmail.com> Message-ID: <29eb13dd-6d51-3596-0be6-ee4456761040@oracle.com> On 5/17/2018 3:16 AM, Ty Young wrote: >>>>> And could the new standalone modules be integrated with the source >>>>> code somehow so that a JDK without JavaFX support can be compiled? >>>> >>>> Not sure what you mean, but you can use an OpenJDK without modules >>>> + the JavaFX standalone modules to build and run your program. >>>> >>>> >>> >>> It's an option, sure. My problem with it is that it creates so much >>> unnecessary disk usage because each bundled application requires >>> it's own copy of JavaFX. If you had 10 standalone JavaFX >>> applications it would be 1GB easily if they where all modular >>> projects, which are around 106MB for me. Creating an app bundle >>> using classpath is around 200MB(post JDK 8 was 250+ IIRC). >> >> >> One option for you would be to use jlink to create a jre image that >> includes the javafx modules. This week's openjfx-11-ea+14 build will >> have a jmods bundle that you can use for this purpose. >> > > So like it was done with OpenJDK 8 overlay but just with modules > instead, basically? At a high-level, you can think of jlink as doing something like this. It can create a custom JRE image by taking the JDK, adding some additional modules -- including your application(s), if desired -- and strip out the modules you don't need. > Arch Linux uses the rolling release update model, so it usually gets > the newest software before any other Linux distro. > > Removing -Werror from those two lines got me a compile, though with > many more warnings. However, attempting to compile an OpenJDK with > JavaFX results in its own build fail due to jdk packager module being > missing in the JavaFX build. See: > > https://pastebin.com/MzFLDxgK Ah, I see the problem now. It seems you are trying to build JavaFX for inclusion into an OpenJDK. That isn't the expected mode any longer now that we have decoupled FX from the JDK, but it still should work. This is a regression caused by my recent change to enable building the standalone SDK. We no longer build the jdk.packager* modules in that mode, and yet there is still a qualified export from javafx.graphics to jdk.packager. This doesn't fail the FX build because we don't fail the FX build on warnings. I filed the following bug: https://bugs.openjdk.java.net/browse/JDK-8203378 I'll fix it soon, but your workaround is to do what you've been doing and use an Oracle JDK 10 build for as long as you need to build a JDK using FX bits that you build. Ultimately, switching to jlink will likely be the better solution for you. > I tried copying the modular src files from a previous build and > pasting them into the new one that doesn't have it and now I just get > a build fail saying that JDK packager is marked for deprecation. I > take it JDK Packager is in the process of being removed then? The javapackager tool and associated jdk.packager and jdk.packager.services modules have been removed from the JDK along with JavaFX. They are not part of the standalone JavaFX builds. -- Kevin From kevin.rushforth at oracle.com Thu May 17 22:10:39 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 May 2018 15:10:39 -0700 Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger In-Reply-To: References: <4d69fb27-cdb7-4a5f-81f2-39c6415908d0@default> <69c1a966-984c-2058-bf0f-6d9d5c828a86@oracle.com> Message-ID: That all sounds good. As for the packager, it will likely continue to be a source of issues like this now that it is gone from the JDK, and isn't part of the unbundled FX builds. I just filed a bug [1] to remove the qualified export from javafx.graphics to jdk.packager (and to disable building the packager even when building using an Oracle JDK) -- see my recent reply to the OpenJFX updates thread [1]. Perhaps I should expand that issue to remove references to it from the IDE files as well. Ultimately, we should delete modules/jdk.packager* and the references to it in build.gradle, etc., but that can be done as a follow-on cleanup issue, which I just filed [3]. Note that the source code would still available for anyone who wants it, either from the openjfx/10u-dev/rt repo or from the openjfx/jfx-dev/rt repo using the jdk-11+13 tag. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8203378 [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021894.html [3] https://bugs.openjdk.java.net/browse/JDK-8203379 On 5/17/2018 2:07 PM, Nir Lisker wrote: > > There was one other place where isDebug() was called, that being > the mLog method.Did you replace the call ti isDebug() with a > direct call to isLoggable instead? > > > Yes, I should have been clearer: I inlined `isDebug` into `mLog`, then > commented out `isDebug` so that if someone reads the commented-out > code in `main` they'll know what it is referring to. I just didn't see > a point in leaving a?private static method just for this one use. > > In any case, since "HelloService" is a test program, I see no > problem with it continuing to use java.util.logging. > > > For Eclipse users this it still a problem since Eclipse includes the > tests in the module (it was discussed in the JIRA issue). Since the > packager is out of scope, I'll just patch the last remnant > in?test.com.sun.javafx.binding.ErrorLoggingUtiltity and submit a > Webrev tomorrow or this weekend since all other changes are already > prepared (and mostly trivial). > > - Nir > > On Thu, May 17, 2018 at 11:39 PM, Kevin Rushforth > > wrote: > > I think it isn't worth doing anything for the packager. In any > case, since "HelloService" is a test program, I see no problem > with it continuing to use java.util.logging. > > Regarding your other comment: > >> Thanks Murali, Iv'e also commented out isDebug() (though maybe it >> can be completely removed, only that the commented out code >> relies on it). >> > > There was one other place where isDebug() was called, that being > the mLog method. Did you replace the call ti isDebug() with a > direct call to isLoggable instead? Note that without the > isLoggable check you will incur the redundant cost of the method > calls + string construction. > > -- Kevin > > > > On 5/17/2018 1:25 PM, Nir Lisker wrote: >> Thanks Murali, Iv'e also commented out isDebug() (though maybe it >> can be completely removed, only that the commented out code >> relies on it). >> >> Kevin, after this change, HelloService in the packager is the >> only one requiring file handling. What is the future of the >> packager now? Is it worth supplying an alternative for these classes? >> >> - Nir >> >> On Thu, May 17, 2018 at 8:49 PM, Murali Billa >> > wrote: >> >> Hi Nir, >> >> Regarding ?com.sun.javafx.webkit.drt.DumpRenderTree?, you can >> comment out the below code in ?main? method from >> DumpRenderTree.java file. >> >> if ( isDebug() ) { >> >> log.setLevel(Level.FINEST); >> >> FileHandler handler = new FileHandler("drt.log", true); >> >> handler.setFormatter(new Formatter() { >> >> @Override >> >> public String format(LogRecord record) { >> >> return formatMessage(record) + "\n"; >> >> } >> >> }); >> >> log.addHandler(handler); >> >> } >> >> Thanks, >> >> MUrali >> >> *From:*Murali Billa >> *Sent:* Thursday, May 03, 2018 1:52 AM >> *To:* Nir Lisker > >> *Cc:* openjfx-dev at openjdk.java.net >> Mailing >> > > >> *Subject:* RE: JDK-8195974: Replace use of java.util.logging >> in javafx with System logger >> >> Hi Nir, >> >> 1)Regarding ?verbose? flag usage: >> >> ?Currently verbose flag is used to show log Levels >> (FINER/FINE/INFO/WARNING) in WCMediaPlayer & >> WCMediaPlayerImpl.?I feel it is not desirable to remove this >> flag as all these logs will start appearing now by default. >> >> ?We can try 2 options: >> >> a)1^st Option: We can change all INFO log messages to FINE >> ?under verbose flag (by leaving all log messages that use >> Level other than INFO unchanged) and verbose flag can be removed. >> >> b)If 1^st option results in too much noise for WARNING log >> messages, then we can keep the verbose flag and introduce a >> System Property (for ex: javafx.web.verbose) to enable the >> flag. I won?t suggest reading level value from log/config file. >> >> 2)Regarding ??com.sun.javafx.webkit.drt.DumpRenderTree?, I >> need to check few more things (since we use ?addHandler? in >> drt) and will get back to you. >> >> Please let me know, if you have any queries for 1. >> >> Thanks, >> >> Murali >> >> *From:*Nir Lisker > >> *Sent:* Saturday, April 28, 2018 1:06 AM >> *To:* Murali Billa > > >> *Cc:* openjfx-dev at openjdk.java.net >> Mailing >> > > >> *Subject:* JDK-8195974: Replace use of java.util.logging in >> javafx with System logger >> >> Hi Murali, >> >> Can you have a look at >> https://bugs.openjdk.java.net/browse/JDK-8195974 >> please? >> >> There are some usages of j.u.l in the web module I'd like >> your opinion on. I'm not familiar with the intent of these >> pieces of code and would like to know what the options are >> for advancing with this issue on that front. >> >> Thanks, >> >> Nir >> >> > > From johan.vos at gluonhq.com Fri May 18 10:38:57 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 18 May 2018 12:38:57 +0200 Subject: bundling native libs in jars or modules In-Reply-To: References: <40E3DAE7-A4E3-42C5-A146-358C2E7C6CE9@bestsolution.at> Message-ID: I fully agree it should somehow somewhere sometime be standardized. But it is extremely unlikely it will be standardized before the Java 11 release, and we need a solution by the time Java 11 is released (and preferably sooner, as in "tomorrow") hence we need to have this or a similar workaround in openjfx. For the real solution, project panama or jigsaw is probably the right place (and I think a JEP might be required?) - Johan On Fri, May 18, 2018 at 3:51 AM Samuel Audet wrote: > Yes, SWT caches in ~/.swt/lib/ by default. This is the kind of thing that > should be standardized somewhere, but I'm not getting much feedback from > Oracle: > http://mail.openjdk.java.net/pipermail/panama-dev/2018-May/001669.html > We've been needing a mechanism like that with JNLP as well, so this isn't > anything new. I'd really like to know why we're not getting any feedback > about this... > > Samuel > > > On Fri, May 18, 2018 at 4:59 AM, Tom Schindl > wrote: > >> To answer my own question the trick swt uses is to encode the build-id >> into the dll/so so it never needs to delete a file >> >> See >> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/Eclipse%20SWT%20PI/common/org/eclipse/swt/internal/Library.java#n144 >> >> Tom >> >> Von meinem iPhone gesendet >> >> Am 17.05.2018 um 21:50 schrieb Tom Schindl : >> >> Did you check how SWT does addresses the problem? If you run it outside >> of OSGi it needs to deal with this problem as well. >> >> Tom >> >> Von meinem iPhone gesendet >> >> Am 17.05.2018 um 21:25 schrieb Johan Vos : >> >> >> Note: This is different from what is discussed in >> >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021762.html >> >> >> The following text is about bundling native code within a jar, and doesn't >> >> talk about how to deal with platform-specific libraries in generic jar >> >> files. >> >> >> At this moment, the standalone SDK for JavaFX 11-ea works fine, and javafx >> >> apps can be executed since the javafx jars will load the required native >> >> code from the libs that are part of the SDK. >> >> >> When we want to download the javafx modules as modules (or jars with >> >> module-info), we don't have a local SDK with native libraries. The native >> >> libraries need to come with the downloaded jar. There are a number of >> >> options to do this, and a number of ongoing discussions (e.g. see >> >> http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001541.html >> ). >> >> In summary, jmods already have support for native code but they are not >> >> scoped at runtime, and jars don't have a standard way for supporting >> native >> >> code. >> >> >> I hope there will be a long-term solution for this in the VM in the >> future, >> >> but clearly we can't rely on this for the 11 release. >> >> Hence, we need to provide some JavaFX-specific fixes. >> >> Just to try the mechanism, I created a quick (and dirty) workaround in the >> >> NativeLibLoader. I committed it to a nativelibs branch of my openjfx fork: >> >> >> https://github.com/johanvos/openjdk-jfx/commit/f2c4c57a6197634e9c3bc1298ea14700057155a3 >> >> >> The good thing is that all JavaFX native lib loading is already delegated >> >> to the NativeLibLoader, so I only had to patch one file. >> >> >> I modified the generated javafx.graphics.jar to include all libs that are >> >> generated (something that can be automated in a gradle task), and could >> >> successfully run javafx apps using >> >> java -p /path/to/my/jars --add-modules javafx.controls >> >> without specifying java.library.path or native libs or so. >> >> >> This works for jars that I put myself on the classpath, hence it should >> >> also work for jars downloaded from maven central etc. >> >> >> In case there will be a standard for bundling native libs with jar files >> in >> >> a future JVM, we can remove this hack. But even in the meantime, there are >> >> better solutions. >> >> One of the best options I think we should consider is using JavaCPP ( >> >> https://github.com/bytedeco/javacpp) . The main author of JavaCPP, >> Samuel >> >> Audet (in cc) describes here ( >> >> >> https://github.com/tensorflow/tensorflow/issues/18397#issuecomment-381371636 >> ) >> >> why my hack will fail on Windows. >> >> >> Another advantage of JavaCPP is that it is proven to work on ios and >> >> Android as well. Actually, that would allow us to get rid of the >> >> ios-specific code that is currently in NativeLibLoader.java. >> >> >> Again, this is only tackling the issue of bunding native code with jars >> and >> >> not dealing with platform-specific resolution (although JavaCPP can help >> >> there as well). >> >> >> - Johan >> >> >> > From johan.vos at gluonhq.com Fri May 18 11:51:03 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 18 May 2018 13:51:03 +0200 Subject: OpenJFX status update In-Reply-To: References: Message-ID: Hi Kevin, Related to point 3: what exactly do you mean with "Java FX has been removed from JDK 11"? It isn't part of the OpenJDK 11-ea13 either so I don't see the difference? I thought references to JavaFX would be removed from sun.launcher.LauncherHelper, but they are still there. Do you know if there are plans to remove the (implicit) launcher there? Thanks, - Johan On Wed, May 16, 2018 at 12:09 AM Kevin Rushforth wrote: > I wanted to update you on the progress of the last couple weeks on the > OpenJFX project: > > 1. As mentioned last week, we now have EA builds of OpenJFX 11 on > java.net [1]. We intend to update this roughly weekly. Currently the > build numbers match the corresponding JDK build number, but that will > not necessarily be the case going forward, so don't assume that they are > in sync. > > 2. Barring any build or staging issues, this week's OpenJFX 11 EA build > will include the jmods as mentioned earlier [2] [3] > > 3. JavaFX has been removed from JDK 11 as of this week. Starting with > jdk-11+14, early access builds of JDK 11 will not include JavaFX. > > 4. After jdk-11+14 is posted on java.net, and FX is no longer included > in JDK 11, we will start using openjfx-11 as the fix version in JBS to > distinguish it from JDK 11. We still expect to do a release of JavaFX 11 > around the same time as JDK 11, but using a different release number > will help track the actual content of JavaFX 11 separately from JDK 11. > > 5. Once this settles down, possibly later this week, I hope to restart > the discussion about OpenJFX policies, etc. I also hope to be a bit more > responsive over the coming days / weeks than I have been for the last > 3-4 weeks. Getting the standalone OpenJFX working and removing JavaFX > from the JDK was quite time consuming as you can probably imagine. > > If you have any general comments or questions about any of this, please > reply to this thread. We may want to split out more detailed discussions > into their own thread to make it easier to follow. > > -- Kevin > > [1] http://jdk.java.net/openjfx/ > > [2] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021856.html > [3] https://bugs.openjdk.java.net/browse/JDK-8202368 > > From kevin.rushforth at oracle.com Fri May 18 13:12:04 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 18 May 2018 06:12:04 -0700 Subject: OpenJFX status update In-Reply-To: References: Message-ID: <58cf1bf9-50f2-6e3b-dfe1-24041db29761@oracle.com> Hi Johan, On 5/18/2018 4:51 AM, Johan Vos wrote: > Hi Kevin, > > Related to point 3: > what exactly do you mean with "Java FX has been removed from JDK 11"? > It isn't part of the OpenJDK 11-ea13 either so I don't see the difference? It was removed from the Oracle JDK 11 (it never was part of OpenJDK 11). The javafx.* modules were included in jdk-11-ea+13 and gone in jdk-11-ea+14. From the point of view of OpenJDK 11 there is no change. > I thought references to JavaFX would be removed from > sun.launcher.LauncherHelper, but they are still there. Do you know if > there are plans to remove the (implicit) launcher there? This came up during the review of changes I made to FXLauncherTest [1]. Alan and Mandy suggested that this functionality should be removed at some point, but it will be an incompatible change if done in JDK 11. I plan to file a follow-up JBS issue to consider removing this. One possible timeline would be to "deprecate it for removal" in JDK 12 and remove it in JDK 13. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8202553 > > Thanks, > > - Johan > > On Wed, May 16, 2018 at 12:09 AM Kevin Rushforth > > wrote: > > I wanted to update you on the progress of the last couple weeks on > the > OpenJFX project: > > 1. As mentioned last week, we now have EA builds of OpenJFX 11 on > java.net [1]. We intend to update this roughly > weekly. Currently the > build numbers match the corresponding JDK build number, but that will > not necessarily be the case going forward, so don't assume that > they are > in sync. > > 2. Barring any build or staging issues, this week's OpenJFX 11 EA > build > will include the jmods as mentioned earlier [2] [3] > > 3. JavaFX has been removed from JDK 11 as of this week. Starting with > jdk-11+14, early access builds of JDK 11 will not include JavaFX. > > 4. After jdk-11+14 is posted on java.net , and FX > is no longer included > in JDK 11, we will start using openjfx-11 as the fix version in > JBS to > distinguish it from JDK 11. We still expect to do a release of > JavaFX 11 > around the same time as JDK 11, but using a different release number > will help track the actual content of JavaFX 11 separately from > JDK 11. > > 5. Once this settles down, possibly later this week, I hope to > restart > the discussion about OpenJFX policies, etc. I also hope to be a > bit more > responsive over the coming days / weeks than I have been for the last > 3-4 weeks. Getting the standalone OpenJFX working and removing JavaFX > from the JDK was quite time consuming as you can probably imagine. > > If you have any general comments or questions about any of this, > please > reply to this thread. We may want to split out more detailed > discussions > into their own thread to make it easier to follow. > > -- Kevin > > [1] http://jdk.java.net/openjfx/ > > [2] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021856.html > [3] https://bugs.openjdk.java.net/browse/JDK-8202368 > From ambarish.rapte at oracle.com Fri May 18 14:57:27 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Fri, 18 May 2018 07:57:27 -0700 (PDT) Subject: [11] RFR : JDK-8203365: [TESTBUG] Mark MeshManagerCacheLeakTest as unstable until test is fixed Message-ID: <6af6a79c-c63f-49cd-b698-68392477beeb@default> Hi Kevin & Ajit, Please review this small fix: Webrev: http://cr.openjdk.java.net/~arapte/fx/8203365/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8203365 Regards, Ambarish From powers.anirvan at gmail.com Fri May 18 17:09:33 2018 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Sat, 19 May 2018 02:09:33 +0900 Subject: Matrox Graphics Cards Problems In-Reply-To: <2AB80E85-BEE8-486F-87A2-0EA3FA210A73@gmail.com> References: <2AB80E85-BEE8-486F-87A2-0EA3FA210A73@gmail.com> Message-ID: Hi Matthew, OpenGL pipeline on Windows is not a supported configuration and so it is not present in JavaFX for Windows[1][2]. You would have to build JavaFX yourself to include this pipeline and "use it at your own risk". It may or may not work. Also it looks like the card should support OpenGL 2.1 or later[3]. [1]: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/071b040b8736/build.gradle#l478 [2]: http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-July/014936.html [3]: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/071b040b8736/modules/javafx.graphics/src/main/native-prism-es2/windows/WinGLFactory.c#l252 On 18 May 2018 at 04:32, Matthew Elliot wrote: > Hey, thanks for the second link, exactly what I needed just not the best > news. > > I see all Matrox cards are disabled which is a bit tricky for us when many > of our customers are have 4+ monitors and some have chosen those cards. > > I then managed to find this - https://bugs.openjdk.java. > net/browse/JDK-8103350 > I assume this means there will never be support of these cards or is there > a work around? I.e. I see they support OpenGL so could I install OpenGL on > a windows machine and try that pipeline? > Is this exclusion of all Matrox cards still valid? > > Thanks in advance, > Matt > > Sent from my phone. > > On 17/05/2018, at 5:15 PM, Anirvan Sarkar > wrote: > > Hi Matthew, > > Please see the below file for blaclisted hardware on D3D. > > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/ > 9e0e0e65e642/modules/javafx.graphics/src/main/native- > prism-d3d/D3DBadHardware.h > > Regards, > Anirvan > > > On Thu, 17 May 2018 at 11:04 PM, Matthew Elliot < > matthew.james.elliot at gmail.com> wrote: > >> Hi all, >> >> we have some customers in the wild who use Matrox 9148LP (9100 series) >> graphics cards because they drive more than 2 monitors and JavaFX always >> reports an error initializing HW pipeline and forcing gpu results in >> system >> instability. >> >> I checked the bug reports but couldn't see anything about JavaFX and >> Matrox >> cards. >> >> Questions >> Is anyone aware of an existing issue? >> Is there a way to get more details on why JavaFx fails to enable the D3D >> pipeline? >> Is there a list of known problematic graphics cards or a black list of >> graphics cards where JavaFX falls back? >> >> Thanks in advance, >> Matt >> > -- > Sent from Gmail Mobile > > -- Anirvan From matthew.james.elliot at gmail.com Fri May 18 17:45:23 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Fri, 18 May 2018 19:45:23 +0200 Subject: Matrox Graphics Cards Problems In-Reply-To: References: <2AB80E85-BEE8-486F-87A2-0EA3FA210A73@gmail.com> Message-ID: <1B0CFD79-79F4-4D8B-A90E-081D51FF10F7@gmail.com> Hey Anirvan, Thanks for the info - guess it?s not such a promising route either then. As these Jira for Matrox cards in JavaFX were from 2013 is it possible that later Matrox cards / drivers would now work if this global disablement was not present. I.e is forceGpu enough to test such scenarios? Or would I need to create another bug report for investigation at Oracle? To the wider group, has anyone else outside Oracle contributed code dealing with supporting graphics cards? Would something like implementing a workaround for whatever deficiency is present (pixel shaders?! from comments in Bug reports) even be possible / practical? Theoretically this could become an interesting topic for my company if a few percent of our users have these types of cards (which is possible) and it could be useful to the wider community. Kind regards, Matt Sent from my phone. > On 18/05/2018, at 7:09 PM, Anirvan Sarkar wrote: > > Hi Matthew, > > OpenGL pipeline on Windows is not a supported configuration and so it is not present in JavaFX for Windows[1][2]. > You would have to build JavaFX yourself to include this pipeline and "use it at your own risk". It may or may not work. > Also it looks like the card should support OpenGL 2.1 or later[3]. > > [1]: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/071b040b8736/build.gradle#l478 > [2]: http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-July/014936.html > [3]: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/071b040b8736/modules/javafx.graphics/src/main/native-prism-es2/windows/WinGLFactory.c#l252 > > >> On 18 May 2018 at 04:32, Matthew Elliot wrote: >> Hey, thanks for the second link, exactly what I needed just not the best news. >> >> I see all Matrox cards are disabled which is a bit tricky for us when many of our customers are have 4+ monitors and some have chosen those cards. >> >> I then managed to find this - https://bugs.openjdk.java.net/browse/JDK-8103350 >> I assume this means there will never be support of these cards or is there a work around? I.e. I see they support OpenGL so could I install OpenGL on a windows machine and try that pipeline? >> Is this exclusion of all Matrox cards still valid? >> >> Thanks in advance, >> Matt >> >> Sent from my phone. >> >>> On 17/05/2018, at 5:15 PM, Anirvan Sarkar wrote: >>> >>> Hi Matthew, >>> >>> Please see the below file for blaclisted hardware on D3D. >>> >>> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/9e0e0e65e642/modules/javafx.graphics/src/main/native-prism-d3d/D3DBadHardware.h >>> >>> Regards, >>> Anirvan >>> >>> >>>> On Thu, 17 May 2018 at 11:04 PM, Matthew Elliot wrote: >>>> Hi all, >>>> >>>> we have some customers in the wild who use Matrox 9148LP (9100 series) >>>> graphics cards because they drive more than 2 monitors and JavaFX always >>>> reports an error initializing HW pipeline and forcing gpu results in system >>>> instability. >>>> >>>> I checked the bug reports but couldn't see anything about JavaFX and Matrox >>>> cards. >>>> >>>> Questions >>>> Is anyone aware of an existing issue? >>>> Is there a way to get more details on why JavaFx fails to enable the D3D >>>> pipeline? >>>> Is there a list of known problematic graphics cards or a black list of >>>> graphics cards where JavaFX falls back? >>>> >>>> Thanks in advance, >>>> Matt >>> -- >>> Sent from Gmail Mobile > > > > -- > Anirvan From kevin.rushforth at oracle.com Fri May 18 18:39:13 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 18 May 2018 11:39:13 -0700 Subject: jfx-dev issues in JBS should now use "openjfx11" as release version Message-ID: <7922993f-95d5-2899-0bf1-6f0411de7c82@oracle.com> Starting now, the JBS release version for the "jfx-dev" repo is "openjfx11". All JBS issues for bugs that affect jfx-dev (e.g., are found in a local build or in an openjfx-11-ea release) should use "openjfx11" as the "affected version". Likewise, all bugs that are fixed in jfx-dev or targeted to be fixed in the 11 time frame should use "openjfx11" as the "fix version". Existing bugs (open bugs as well as any bugs found or fixed after last week's jdk-11+13 build) have been updated to reflect this. Let me know if you have any questions about this. Thanks. -- Kevin From nlisker at gmail.com Fri May 18 19:05:32 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 18 May 2018 22:05:32 +0300 Subject: OpenJFX status update In-Reply-To: References: Message-ID: > > We still expect to do a release of JavaFX 11 around the same time as JDK > 11, but using a different release number will help track the actual content > of JavaFX 11 separately from JDK 11. Iv'e just realized that not releasing JavaFX with version number 11 will cause confusion with all the '@since 11' tags. We could search for all '@since 11' and replace them with the new version number (maybe much to the confusion of users since it breaks continuity). - Nir On Wed, May 16, 2018 at 12:59 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > I wanted to update you on the progress of the last couple weeks on the > OpenJFX project: > > 1. As mentioned last week, we now have EA builds of OpenJFX 11 on java.net > [1]. We intend to update this roughly weekly. Currently the build numbers > match the corresponding JDK build number, but that will not necessarily be > the case going forward, so don't assume that they are in sync. > > 2. Barring any build or staging issues, this week's OpenJFX 11 EA build > will include the jmods as mentioned earlier [2] [3] > > 3. JavaFX has been removed from JDK 11 as of this week. Starting with > jdk-11+14, early access builds of JDK 11 will not include JavaFX. > > 4. After jdk-11+14 is posted on java.net, and FX is no longer included in > JDK 11, we will start using openjfx-11 as the fix version in JBS to > distinguish it from JDK 11. We still expect to do a release of JavaFX 11 > around the same time as JDK 11, but using a different release number will > help track the actual content of JavaFX 11 separately from JDK 11. > > 5. Once this settles down, possibly later this week, I hope to restart the > discussion about OpenJFX policies, etc. I also hope to be a bit more > responsive over the coming days / weeks than I have been for the last 3-4 > weeks. Getting the standalone OpenJFX working and removing JavaFX from the > JDK was quite time consuming as you can probably imagine. > > If you have any general comments or questions about any of this, please > reply to this thread. We may want to split out more detailed discussions > into their own thread to make it easier to follow. > > -- Kevin > > [1] http://jdk.java.net/openjfx/ > > [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/ > 021856.html > [3] https://bugs.openjdk.java.net/browse/JDK-8202368 > > From kevin.rushforth at oracle.com Fri May 18 20:13:14 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 18 May 2018 13:13:14 -0700 Subject: OpenJFX status update In-Reply-To: References: Message-ID: <3e7edb80-64cf-25bf-4007-f6e60d7bc970@oracle.com> I was somewhat imprecise. That should have read: > We still expect to do a release of JavaFX 11 around the same time as > JDK 11, but using a different **JBS release version** will help track > the actual content of JavaFX 11 separately from JDK 11. The JavaFX version is still 11 as reported by the value of the system property "javafx.version" and in the names of the release bundles. No changes are needed. We are just prefixing the release value in JBS with "openjfx" before the "11" to distinguish it from the JDK 11 release. After JavaFX 11, we could have a discussion on whether to make the next version "12" or something else. -- Kevin On 5/18/2018 12:05 PM, Nir Lisker wrote: > > We still expect to do a release of JavaFX 11 around the same time > as JDK 11, but using a different release number will help track > the actual content of JavaFX 11 separately from JDK 11. > > > ?Iv'e just realized that not releasing JavaFX with version number 11 > will cause confusion with all the '@since 11' tags. We could search > for all '@since 11' and replace them with the new version number > (maybe much to the confusion of users since it breaks continuity). > > - Nir > > On Wed, May 16, 2018 at 12:59 AM, Kevin Rushforth > > wrote: > > I wanted to update you on the progress of the last couple weeks on > the OpenJFX project: > > 1. As mentioned last week, we now have EA builds of OpenJFX 11 on > java.net [1]. We intend to update this roughly > weekly. Currently the build numbers match the corresponding JDK > build number, but that will not necessarily be the case going > forward, so don't assume that they are in sync. > > 2. Barring any build or staging issues, this week's OpenJFX 11 EA > build will include the jmods as mentioned earlier [2] [3] > > 3. JavaFX has been removed from JDK 11 as of this week. Starting > with jdk-11+14, early access builds of JDK 11 will not include JavaFX. > > 4. After jdk-11+14 is posted on java.net , and FX > is no longer included in JDK 11, we will start using openjfx-11 as > the fix version in JBS to distinguish it from JDK 11. We still > expect to do a release of JavaFX 11 around the same time as JDK > 11, but using a different release number will help track the > actual content of JavaFX 11 separately from JDK 11. > > 5. Once this settles down, possibly later this week, I hope to > restart the discussion about OpenJFX policies, etc. I also hope to > be a bit more responsive over the coming days / weeks than I have > been for the last 3-4 weeks. Getting the standalone OpenJFX > working and removing JavaFX from the JDK was quite time consuming > as you can probably imagine. > > If you have any general comments or questions about any of this, > please reply to this thread. We may want to split out more > detailed discussions into their own thread to make it easier to > follow. > > -- Kevin > > [1] http://jdk.java.net/openjfx/ > > [2] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021856.html > > [3] https://bugs.openjdk.java.net/browse/JDK-8202368 > > > From nlisker at gmail.com Fri May 18 20:22:08 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 18 May 2018 23:22:08 +0300 Subject: OpenJFX status update In-Reply-To: <3e7edb80-64cf-25bf-4007-f6e60d7bc970@oracle.com> References: <3e7edb80-64cf-25bf-4007-f6e60d7bc970@oracle.com> Message-ID: I see, sorry about the false flag. On Fri, May 18, 2018 at 11:13 PM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > I was somewhat imprecise. That should have read: > > We still expect to do a release of JavaFX 11 around the same time as JDK > 11, but using a different **JBS release version** will help track the > actual content of JavaFX 11 separately from JDK 11. > > > The JavaFX version is still 11 as reported by the value of the system > property "javafx.version" and in the names of the release bundles. No > changes are needed. We are just prefixing the release value in JBS with > "openjfx" before the "11" to distinguish it from the JDK 11 release. > > After JavaFX 11, we could have a discussion on whether to make the next > version "12" or something else. > > -- Kevin > > > On 5/18/2018 12:05 PM, Nir Lisker wrote: > > We still expect to do a release of JavaFX 11 around the same time as JDK >> 11, but using a different release number will help track the actual content >> of JavaFX 11 separately from JDK 11. > > > Iv'e just realized that not releasing JavaFX with version number 11 will > cause confusion with all the '@since 11' tags. We could search for all > '@since 11' and replace them with the new version number (maybe much to the > confusion of users since it breaks continuity). > > - Nir > > On Wed, May 16, 2018 at 12:59 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I wanted to update you on the progress of the last couple weeks on the >> OpenJFX project: >> >> 1. As mentioned last week, we now have EA builds of OpenJFX 11 on >> java.net [1]. We intend to update this roughly weekly. Currently the >> build numbers match the corresponding JDK build number, but that will not >> necessarily be the case going forward, so don't assume that they are in >> sync. >> >> 2. Barring any build or staging issues, this week's OpenJFX 11 EA build >> will include the jmods as mentioned earlier [2] [3] >> >> 3. JavaFX has been removed from JDK 11 as of this week. Starting with >> jdk-11+14, early access builds of JDK 11 will not include JavaFX. >> >> 4. After jdk-11+14 is posted on java.net, and FX is no longer included >> in JDK 11, we will start using openjfx-11 as the fix version in JBS to >> distinguish it from JDK 11. We still expect to do a release of JavaFX 11 >> around the same time as JDK 11, but using a different release number will >> help track the actual content of JavaFX 11 separately from JDK 11. >> >> 5. Once this settles down, possibly later this week, I hope to restart >> the discussion about OpenJFX policies, etc. I also hope to be a bit more >> responsive over the coming days / weeks than I have been for the last 3-4 >> weeks. Getting the standalone OpenJFX working and removing JavaFX from the >> JDK was quite time consuming as you can probably imagine. >> >> If you have any general comments or questions about any of this, please >> reply to this thread. We may want to split out more detailed discussions >> into their own thread to make it easier to follow. >> >> -- Kevin >> >> [1] http://jdk.java.net/openjfx/ >> >> [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/ >> 021856.html >> [3] https://bugs.openjdk.java.net/browse/JDK-8202368 >> >> > > From kevin.rushforth at oracle.com Fri May 18 20:27:57 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 18 May 2018 13:27:57 -0700 Subject: OpenJFX status update In-Reply-To: References: <3e7edb80-64cf-25bf-4007-f6e60d7bc970@oracle.com> Message-ID: <50279318-f50e-6ea6-4a46-47a90cd8b94f@oracle.com> Sure. No problem. -- Kevin On 5/18/2018 1:22 PM, Nir Lisker wrote: > I see, sorry about the false flag. > > On Fri, May 18, 2018 at 11:13 PM, Kevin Rushforth > > wrote: > > I was somewhat imprecise. That should have read: > >> We still expect to do a release of JavaFX 11 around the same time >> as JDK 11, but using a different **JBS release version** will >> help track the actual content of JavaFX 11 separately from JDK 11. > > The JavaFX version is still 11 as reported by the value of the > system property "javafx.version" and in the names of the release > bundles. No changes are needed. We are just prefixing the release > value in JBS with "openjfx" before the "11" to distinguish it from > the JDK 11 release. > > After JavaFX 11, we could have a discussion on whether to make the > next version "12" or something else. > > -- Kevin > > > On 5/18/2018 12:05 PM, Nir Lisker wrote: >> >> We still expect to do a release of JavaFX 11 around the same >> time as JDK 11, but using a different release number will >> help track the actual content of JavaFX 11 separately from >> JDK 11. >> >> >> ?Iv'e just realized that not releasing JavaFX with version number >> 11 will cause confusion with all the '@since 11' tags. We could >> search for all '@since 11' and replace them with the new version >> number (maybe much to the confusion of users since it breaks >> continuity). >> >> - Nir >> >> On Wed, May 16, 2018 at 12:59 AM, Kevin Rushforth >> > >> wrote: >> >> I wanted to update you on the progress of the last couple >> weeks on the OpenJFX project: >> >> 1. As mentioned last week, we now have EA builds of OpenJFX >> 11 on java.net [1]. We intend to update >> this roughly weekly. Currently the build numbers match the >> corresponding JDK build number, but that will not necessarily >> be the case going forward, so don't assume that they are in sync. >> >> 2. Barring any build or staging issues, this week's OpenJFX >> 11 EA build will include the jmods as mentioned earlier [2] [3] >> >> 3. JavaFX has been removed from JDK 11 as of this week. >> Starting with jdk-11+14, early access builds of JDK 11 will >> not include JavaFX. >> >> 4. After jdk-11+14 is posted on java.net , >> and FX is no longer included in JDK 11, we will start using >> openjfx-11 as the fix version in JBS to distinguish it from >> JDK 11. We still expect to do a release of JavaFX 11 around >> the same time as JDK 11, but using a different release number >> will help track the actual content of JavaFX 11 separately >> from JDK 11. >> >> 5. Once this settles down, possibly later this week, I hope >> to restart the discussion about OpenJFX policies, etc. I also >> hope to be a bit more responsive over the coming days / weeks >> than I have been for the last 3-4 weeks. Getting the >> standalone OpenJFX working and removing JavaFX from the JDK >> was quite time consuming as you can probably imagine. >> >> If you have any general comments or questions about any of >> this, please reply to this thread. We may want to split out >> more detailed discussions into their own thread to make it >> easier to follow. >> >> -- Kevin >> >> [1] http://jdk.java.net/openjfx/ >> >> [2] >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021856.html >> >> [3] https://bugs.openjdk.java.net/browse/JDK-8202368 >> >> >> > > From kevin.rushforth at oracle.com Fri May 18 20:54:02 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 18 May 2018 13:54:02 -0700 Subject: Matrox Graphics Cards Problems In-Reply-To: <1B0CFD79-79F4-4D8B-A90E-081D51FF10F7@gmail.com> References: <2AB80E85-BEE8-486F-87A2-0EA3FA210A73@gmail.com> <1B0CFD79-79F4-4D8B-A90E-081D51FF10F7@gmail.com> Message-ID: <84969590-0363-c452-5b90-f5dbf92624c3@oracle.com> On 5/18/2018 10:45 AM, Matthew Elliot wrote: > Hey Anirvan, > > Thanks for the info - guess it?s not such a promising route either then. > > As these Jira for Matrox cards in JavaFX were from 2013 is it possible that later Matrox cards / drivers would now work if this global disablement was not present. I.e is forceGpu enough to test such scenarios? Trying newer cards with forceGPU would be a good first step. > Or would I need to create another bug report for investigation at Oracle? If you find that this works consistently on newer Matrox cards, then you can raise a new bug for this, although it isn't something we are likely to work on ourselves. The challenge would be in testing this, since Matrox cards are not readily available. > To the wider group, has anyone else outside Oracle contributed code dealing with supporting graphics cards? > > Would something like implementing a workaround for whatever deficiency is present (pixel shaders?! from comments in Bug reports) even be possible / practical? We've done this is a very limited way in the past for issues that affected all Intel HD cards, for example. Good luck with your investigation. -- Kevin > Theoretically this could become an interesting topic for my company if a few percent of our users have these types of cards (which is possible) and it could be useful to the wider community. > > Kind regards, > Matt > > Sent from my phone. > >> On 18/05/2018, at 7:09 PM, Anirvan Sarkar wrote: >> >> Hi Matthew, >> >> OpenGL pipeline on Windows is not a supported configuration and so it is not present in JavaFX for Windows[1][2]. >> You would have to build JavaFX yourself to include this pipeline and "use it at your own risk". It may or may not work. >> Also it looks like the card should support OpenGL 2.1 or later[3]. >> >> [1]: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/071b040b8736/build.gradle#l478 >> [2]: http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-July/014936.html >> [3]: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/071b040b8736/modules/javafx.graphics/src/main/native-prism-es2/windows/WinGLFactory.c#l252 >> >> >>> On 18 May 2018 at 04:32, Matthew Elliot wrote: >>> Hey, thanks for the second link, exactly what I needed just not the best news. >>> >>> I see all Matrox cards are disabled which is a bit tricky for us when many of our customers are have 4+ monitors and some have chosen those cards. >>> >>> I then managed to find this - https://bugs.openjdk.java.net/browse/JDK-8103350 >>> I assume this means there will never be support of these cards or is there a work around? I.e. I see they support OpenGL so could I install OpenGL on a windows machine and try that pipeline? >>> Is this exclusion of all Matrox cards still valid? >>> >>> Thanks in advance, >>> Matt >>> >>> Sent from my phone. >>> >>>> On 17/05/2018, at 5:15 PM, Anirvan Sarkar wrote: >>>> >>>> Hi Matthew, >>>> >>>> Please see the below file for blaclisted hardware on D3D. >>>> >>>> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/9e0e0e65e642/modules/javafx.graphics/src/main/native-prism-d3d/D3DBadHardware.h >>>> >>>> Regards, >>>> Anirvan >>>> >>>> >>>>> On Thu, 17 May 2018 at 11:04 PM, Matthew Elliot wrote: >>>>> Hi all, >>>>> >>>>> we have some customers in the wild who use Matrox 9148LP (9100 series) >>>>> graphics cards because they drive more than 2 monitors and JavaFX always >>>>> reports an error initializing HW pipeline and forcing gpu results in system >>>>> instability. >>>>> >>>>> I checked the bug reports but couldn't see anything about JavaFX and Matrox >>>>> cards. >>>>> >>>>> Questions >>>>> Is anyone aware of an existing issue? >>>>> Is there a way to get more details on why JavaFx fails to enable the D3D >>>>> pipeline? >>>>> Is there a list of known problematic graphics cards or a black list of >>>>> graphics cards where JavaFX falls back? >>>>> >>>>> Thanks in advance, >>>>> Matt >>>> -- >>>> Sent from Gmail Mobile >> >> -- >> Anirvan From nlisker at gmail.com Sat May 19 17:10:09 2018 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 19 May 2018 20:10:09 +0300 Subject: Review Request: JDK-8195974: Replace use of java.util.logging in javafx with System logger Message-ID: Hi, Please review the fix approach for: https://bugs.openjdk.java.net/browse/JDK-8195974 http://cr.openjdk.java.net/~nlisker/8195974/webrev.00/ Many details in the issue. Thanks, Nir From ambarish.rapte at oracle.com Mon May 21 17:05:59 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 21 May 2018 10:05:59 -0700 (PDT) Subject: [11] JDK-8200285 : TabDragPolicy.REORDER prevents ContextMenu from showing Message-ID: <2a992afb-3567-4df1-8fbe-fe6c273c97d7@default> Hi Kevin & Ajit, Please review this fix, Webrev: http://cr.openjdk.java.net/~arapte/fx/8200285/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8200285 Regards, Ambarish From kevin.rushforth at oracle.com Mon May 21 17:54:40 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 21 May 2018 10:54:40 -0700 Subject: [11] Review request: 8203378: JDK build fails to compile javafx.graphics module-info.java if FX was built with OpenJDK Message-ID: <6eb7dec2-8bac-06ef-3c18-3a8cbd38cad9@oracle.com> Phil or Ajit, Please review the following simple fix: https://bugs.openjdk.java.net/browse/JDK-8203378 http://cr.openjdk.java.net/~kcr/8203378/webrev.00/ This removes one qualified export from javafx.graphics to the no-longer-built jdk.packager module. More details in JBS. Note to Eclipse users: This patch modifies the Eclipse files to remove references to jdk.packager. I would like a read from the users of Eclipse as to whether I should do this or not. I am equally happy to commit or revert my changes to these files. -- Kevin From nlisker at gmail.com Mon May 21 21:13:01 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 22 May 2018 00:13:01 +0300 Subject: [11] Review request: 8203378: JDK build fails to compile javafx.graphics module-info.java if FX was built with OpenJDK In-Reply-To: <6eb7dec2-8bac-06ef-3c18-3a8cbd38cad9@oracle.com> References: <6eb7dec2-8bac-06ef-3c18-3a8cbd38cad9@oracle.com> Message-ID: Since the packager is being removed I don't see a reason to keep any references to it. In any case, the Eclipse files are planned to be updated [1] after j.u.l. is removed [2]. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021740.html [2] https://bugs.openjdk.java.net/browse/JDK-8195974 - Nir On Mon, May 21, 2018 at 8:54 PM, Kevin Rushforth wrote: > Phil or Ajit, > > Please review the following simple fix: > > https://bugs.openjdk.java.net/browse/JDK-8203378 > http://cr.openjdk.java.net/~kcr/8203378/webrev.00/ > > This removes one qualified export from javafx.graphics to the > no-longer-built jdk.packager module. More details in JBS. > > Note to Eclipse users: This patch modifies the Eclipse files to remove > references to jdk.packager. I would like a read from the users of Eclipse > as to whether I should do this or not. I am equally happy to commit or > revert my changes to these files. > > -- Kevin > > From kevin.rushforth at oracle.com Mon May 21 21:29:10 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 21 May 2018 14:29:10 -0700 Subject: [11] Review request: 8203378: JDK build fails to compile javafx.graphics module-info.java if FX was built with OpenJDK In-Reply-To: References: <6eb7dec2-8bac-06ef-3c18-3a8cbd38cad9@oracle.com> Message-ID: <9237f2dd-8dc0-9b3f-a90a-30890db4f004@oracle.com> In that case, why don't I revert my changes and let you remove the references after j.u.l is removed. -- Kevin On 5/21/2018 2:13 PM, Nir Lisker wrote: > Since the packager is being removed I don't see a reason to keep any > references to it. In any case, the Eclipse files are planned to be > updated [1] after j.u.l. is removed [2]. > > [1] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021740.html > > [2] https://bugs.openjdk.java.net/browse/JDK-8195974 > > - Nir > > On Mon, May 21, 2018 at 8:54 PM, Kevin Rushforth > > wrote: > > Phil or Ajit, > > Please review the following simple fix: > > https://bugs.openjdk.java.net/browse/JDK-8203378 > > http://cr.openjdk.java.net/~kcr/8203378/webrev.00/ > > > This removes one qualified export from javafx.graphics to the > no-longer-built jdk.packager module. More details in JBS. > > Note to Eclipse users: This patch modifies the Eclipse files to > remove references to jdk.packager. I would like a read from the > users of Eclipse as to whether I should do this or not. I am > equally happy to commit or revert my changes to these files. > > -- Kevin > > From nlisker at gmail.com Mon May 21 21:31:59 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 22 May 2018 00:31:59 +0300 Subject: [11] Review request: 8203378: JDK build fails to compile javafx.graphics module-info.java if FX was built with OpenJDK In-Reply-To: <9237f2dd-8dc0-9b3f-a90a-30890db4f004@oracle.com> References: <6eb7dec2-8bac-06ef-3c18-3a8cbd38cad9@oracle.com> <9237f2dd-8dc0-9b3f-a90a-30890db4f004@oracle.com> Message-ID: Fine by me. - Nir On Tue, May 22, 2018 at 12:29 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > In that case, why don't I revert my changes and let you remove the > references after j.u.l is removed. > > -- Kevin > > > > On 5/21/2018 2:13 PM, Nir Lisker wrote: > > Since the packager is being removed I don't see a reason to keep any > references to it. In any case, the Eclipse files are planned to be updated > [1] after j.u.l. is removed [2]. > > [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/ > 2018-April/021740.html > > [2] https://bugs.openjdk.java.net/browse/JDK-8195974 > > - Nir > > On Mon, May 21, 2018 at 8:54 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Phil or Ajit, >> >> Please review the following simple fix: >> >> https://bugs.openjdk.java.net/browse/JDK-8203378 >> http://cr.openjdk.java.net/~kcr/8203378/webrev.00/ >> >> This removes one qualified export from javafx.graphics to the >> no-longer-built jdk.packager module. More details in JBS. >> >> Note to Eclipse users: This patch modifies the Eclipse files to remove >> references to jdk.packager. I would like a read from the users of Eclipse >> as to whether I should do this or not. I am equally happy to commit or >> revert my changes to these files. >> >> -- Kevin >> >> > > From mike.ennen at gmail.com Tue May 22 00:04:40 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 21 May 2018 17:04:40 -0700 Subject: RFR: JDK-8090763/CSR JDK-8203409 - Make JavaFX Robot Part of JavaFX Public API Message-ID: Hello all, Please review an enhancement to move the private Robot API into a new public javafx.scene.robot package. The internal com.sun.glass.ui.Robot class is removed as a result. Applications and test frameworks that reference this internal class will need to adapt to the new public API. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8090763 webrev: This is being worked on in the OpenJFX GitHub mirror: https://github.com/javafxports/openjdk-jfx/pull/36/commits CSR: https://bugs.openjdk.java.net/browse/JDK-8203409 Thanks very much to Kevin for all his help in getting to this stage, Michael Ennen From arunprasad.rajkumar at oracle.com Tue May 22 05:28:13 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 22 May 2018 10:58:13 +0530 Subject: [openjfx11] Review request for 8203294: [Linux] Link libgcc and libstdc++ statically to support gcc-7.x Message-ID: <921D97D2-6FFF-4B61-9EC5-54005DB4DC59@oracle.com> Hi, Please review the following fix: http://cr.openjdk.java.net/~arajkumar/8203294/webrev Root cause: Currently C and C++ standard libraries are linked dynamically(except javafx.web), it may restrict the usage of javafx on old Linux distros when we upgrade to latest compiler(GCC 7.3?) Solution: Fix all javafx module dynamic library linking process to use '-static-libgcc -static-libstdc++' flags to force the static linking of standard libs. Additionally '-ffunction-sections -fdata-sections' GCC compiler flags[1] are used to reduce the library size due to static linking. Testing: Used the following command to see the size difference of javafx libraries with and without static linking ```` find build/modular-sdk/modules_libs/ -type f -name *.so -exec ls -lh {} \; -exec sh -c 'ls -lh $JAVA_HOME/lib/$(basename {})' \; ```` Used the following command to verify the fix, ```` find build/modular-sdk/modules_libs -name *.so -exec sh -c "readelf -d {} | egrep 'libgcc|libstdc++' > /dev/null && echo {}" \; ```` [1] https://gcc.gnu.org/onlinedocs/gnat_ugn/Compilation-options.html Thanks, Arun From daniel.fuchs at oracle.com Tue May 22 12:01:09 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 May 2018 13:01:09 +0100 Subject: Review Request: JDK-8195974: Replace use of java.util.logging In-Reply-To: References: Message-ID: <5ee68663-bf1d-3693-1867-b4d74efd2bb7@oracle.com> Hi Nir, By default, the backend of System.Logger is java.util.logging, as long as the java.logging module is present and no custom LoggerFinder service has been deployed. This means that in a usual testing environment, if a library emits a log message using the System.Logger API, then a test for that library should still be able to observe that message using the regular java.util.logging APIs. (unless a LoggerFinder service has explicitly been deployed, or unless the test runs with a --limit-modules option that excludes java.logging). I see that you have changed javafx.base tests to stop using java.util.logging for verifying the log messages produced by javafx.base classes, and I was wondering whether that was really necessary? I mean - this could be necessary if the test was a whitebox test deployed by the test infrastructure in the same module than the code under test, and was therefore limited to only use those modules required by the module-info of that module, but if the test class is deployed on the class path / unnamed module then the test class should still be able to configure/access java.logging to verify the behaviour of the module under test. best regards, -- daniel On 20/05/2018 13:00, openjfx-dev-request at openjdk.java.net wrote: > Hi, > > Please review the fix approach for: > > https://bugs.openjdk.java.net/browse/JDK-8195974 > > http://cr.openjdk.java.net/~nlisker/8195974/webrev.00/ > > Many details in the issue. > > Thanks, > Nir > From nlisker at gmail.com Tue May 22 12:39:48 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 22 May 2018 15:39:48 +0300 Subject: Review Request: JDK-8195974: Replace use of java.util.logging In-Reply-To: <5ee68663-bf1d-3693-1867-b4d74efd2bb7@oracle.com> References: <5ee68663-bf1d-3693-1867-b4d74efd2bb7@oracle.com> Message-ID: Hi Daniel, I see that you have changed javafx.base tests to stop using > java.util.logging for verifying the log messages produced > by javafx.base classes, and I was wondering whether that > was really necessary? This was the most acceptable approach. The reason is that using j.u.l., even in tests, causes problems for OpenJFX on Eclipse. This was brought up a few times before: in a discussion about Eclipse-specific files [1], in the issue comments [2], and in a discussion about this issue [3]. I waited with the decision to remove j.u.l. completely until all its uses were understood and I could determine that they are minor enough for a replacement to be put in at the benefit of being able to develop OpenJFX on Eclipse. I'm aware that changing code because an IDE doesn't handle it well it isn't a good practice, but in this case there were no objections. In the future, if an irreplaceable need to use j.u.l. arises, we can reevaluate this point and see if Eclipse has made any changes to remove this conflict (I'm not sure if they're planning to). The availability of j.u.l. with respect to System.Logger isn't the issue. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021743.html [2] https://bugs.openjdk.java.net/browse/JDK-8195974?focusedCommentId=14176654&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14176654 [3] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021893.html Best, Nir On Tue, May 22, 2018 at 3:01 PM, Daniel Fuchs wrote: > Hi Nir, > > By default, the backend of System.Logger is java.util.logging, > as long as the java.logging module is present and no > custom LoggerFinder service has been deployed. > > This means that in a usual testing environment, if a library > emits a log message using the System.Logger API, then a test > for that library should still be able to observe that message > using the regular java.util.logging APIs. > (unless a LoggerFinder service has explicitly been deployed, > or unless the test runs with a --limit-modules option that > excludes java.logging). > > I see that you have changed javafx.base tests to stop using > java.util.logging for verifying the log messages produced > by javafx.base classes, and I was wondering whether that > was really necessary? > I mean - this could be necessary if the test was a whitebox > test deployed by the test infrastructure in the same module > than the code under test, and was therefore limited to only > use those modules required by the module-info of that module, > but if the test class is deployed on the class path / unnamed > module then the test class should still be able to > configure/access java.logging to verify the behaviour > of the module under test. > > best regards, > > -- daniel > > > On 20/05/2018 13:00, openjfx-dev-request at openjdk.java.net wrote: > >> Hi, >> >> Please review the fix approach for: >> >> https://bugs.openjdk.java.net/browse/JDK-8195974 >> >> http://cr.openjdk.java.net/~nlisker/8195974/webrev.00/ >> >> Many details in the issue. >> >> Thanks, >> Nir >> >> > From tom.schindl at bestsolution.at Tue May 22 14:37:03 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 22 May 2018 16:37:03 +0200 Subject: Review Request: JDK-8195974: Replace use of java.util.logging In-Reply-To: <5ee68663-bf1d-3693-1867-b4d74efd2bb7@oracle.com> References: <5ee68663-bf1d-3693-1867-b4d74efd2bb7@oracle.com> Message-ID: <7499d7cc-e782-a2f4-f1a6-94b6f3215c9f@bestsolution.at> >From a pure library developer point-of-view this would mean JavaFX would rely on an implementation detail of the JRE it runs (it's JUnit-Tests). Does this hold true if I run JavaFX on none Oracle VMs, like Eclipse J9 - not that i plan but well you know ;-) Tom On 22.05.18 14:01, Daniel Fuchs wrote: > Hi Nir, > > By default, the backend of System.Logger is java.util.logging, > as long as the java.logging module is present and no > custom LoggerFinder service has been deployed. > > This means that in a usual testing environment, if a library > emits a log message using the System.Logger API, then a test > for that library should still be able to observe that message > using the regular java.util.logging APIs. > (unless a LoggerFinder service has explicitly been deployed, > or unless the test runs with a --limit-modules option that > excludes java.logging). > > I see that you have changed javafx.base tests to stop using > java.util.logging for verifying the log messages produced > by javafx.base classes, and I was wondering whether that > was really necessary? > I mean - this could be necessary if the test was a whitebox > test deployed by the test infrastructure in the same module > than the code under test, and was therefore limited to only > use those modules required by the module-info of that module, > but if the test class is deployed on the class path / unnamed > module then the test class? should still be able to > configure/access java.logging to verify the behaviour > of the module under test. > > best regards, > > -- daniel > > > On 20/05/2018 13:00, openjfx-dev-request at openjdk.java.net wrote: >> Hi, >> >> Please review the fix approach for: >> >> https://bugs.openjdk.java.net/browse/JDK-8195974 >> >> http://cr.openjdk.java.net/~nlisker/8195974/webrev.00/ >> >> Many details in the issue. >> >> Thanks, >> Nir >> > From nlisker at gmail.com Tue May 22 14:47:12 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 22 May 2018 17:47:12 +0300 Subject: Review Request: JDK-8195974: Replace use of java.util.logging In-Reply-To: <7499d7cc-e782-a2f4-f1a6-94b6f3215c9f@bestsolution.at> References: <5ee68663-bf1d-3693-1867-b4d74efd2bb7@oracle.com> <7499d7cc-e782-a2f4-f1a6-94b6f3215c9f@bestsolution.at> Message-ID: Tom, is there an Eclipse issue about this in Bugzilla? As I mentioned some time ago, if I add the dependency to the .classpath it should function the same as adding it to module-info. On Tue, May 22, 2018 at 5:37 PM, Tom Schindl wrote: > From a pure library developer point-of-view this would mean JavaFX would > rely on an implementation detail of the JRE it runs (it's JUnit-Tests). > > Does this hold true if I run JavaFX on none Oracle VMs, like Eclipse J9 > - not that i plan but well you know ;-) > > Tom > > On 22.05.18 14:01, Daniel Fuchs wrote: > > Hi Nir, > > > > By default, the backend of System.Logger is java.util.logging, > > as long as the java.logging module is present and no > > custom LoggerFinder service has been deployed. > > > > This means that in a usual testing environment, if a library > > emits a log message using the System.Logger API, then a test > > for that library should still be able to observe that message > > using the regular java.util.logging APIs. > > (unless a LoggerFinder service has explicitly been deployed, > > or unless the test runs with a --limit-modules option that > > excludes java.logging). > > > > I see that you have changed javafx.base tests to stop using > > java.util.logging for verifying the log messages produced > > by javafx.base classes, and I was wondering whether that > > was really necessary? > > I mean - this could be necessary if the test was a whitebox > > test deployed by the test infrastructure in the same module > > than the code under test, and was therefore limited to only > > use those modules required by the module-info of that module, > > but if the test class is deployed on the class path / unnamed > > module then the test class should still be able to > > configure/access java.logging to verify the behaviour > > of the module under test. > > > > best regards, > > > > -- daniel > > > > > > On 20/05/2018 13:00, openjfx-dev-request at openjdk.java.net wrote: > >> Hi, > >> > >> Please review the fix approach for: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8195974 > >> > >> http://cr.openjdk.java.net/~nlisker/8195974/webrev.00/ > >> > >> Many details in the issue. > >> > >> Thanks, > >> Nir > >> > > > From sebastien.deries at gmail.com Wed May 23 06:44:44 2018 From: sebastien.deries at gmail.com (sebastien deries) Date: Wed, 23 May 2018 08:44:44 +0200 Subject: linux separate screen configuration issue In-Reply-To: References: Message-ID: Greetings, Am I really the only one getting this issue ? https://stackoverflow.com/questions/50168857/javafx-misreports-number-of-screen-devices Thanks. Sebastien On Fri, Apr 27, 2018 at 3:33 PM, sebastien deries < sebastien.deries at gmail.com> wrote: > Greetings, > > I develop an application on linux on a Red Hat 6.8 x64 using java 8u162 > and an NVidia GPU (and its latest driver), with 2 full HD Screens. > > I got an issue retrieving the number of physical screens: > > - when the X server is in extended desktop mode (2 physical screens, > but a single logical one from 0 to 3840 pixels), Screen.getScreens() > returns 2 Screen (which is normal) > - When the X server is in separate desktop mode (2 physical screens > and 2 logical screens from 0 to 1920 pixels), Screen.getScreens() returns 1 > Screen ==> is this normal or a bug? > > I compared the JavaFX API to the AWT API: > > GraphicsEnvironment env = GraphicsEnvironment. > getLocalGraphicsEnvironment(); > GraphicsDevice[] gdev = env.getScreenDevices(); > > AWT returns 2 screen devices in both configuration mode. > > > I Also checked on java 9 and java 10 using a ubuntu x64 machine and got > the same issue with JavaFX. > > I tried debugging this and it seems that the issue is in libglass.so in > native code. > > What do you think about this ? > > Thank you for your help. > > Regards > > Sebastien > > > Here is the code that reproduces the issue: > > public class ScreenTest extends Application { > > private static final int SIZE = 1600; > private final AnchorPane root = new AnchorPane(); > > @Override > public void start(Stage primaryStage) throws Exception { > > root.backgroundProperty().set(new Background(new > BackgroundFill(Color.BEIGE, null, null))); > Scene scene = new Scene(root, SIZE, SIZE); > primaryStage.show(); > > Screen.getScreens().forEach(screen -> System.out.println("JAVAFX > :" + screen)); > GraphicsEnvironment env = GraphicsEnvironment. > getLocalGraphicsEnvironment(); > GraphicsDevice[] gdev = env.getScreenDevices(); > > for (GraphicsDevice d : gdev) { > System.out.println("AWT:" + d); > } > } > public static void main(String... strings) { > launch(strings); > } > } > > > > here is the X11 Xorg.conf: > > Section "ServerLayout" > Identifier "Layout0" > Screen 0 "Screen0" 0 0 > Screen 1 "Screen1" RightOf "Screen0" > InputDevice "Keyboard0" "CoreKeyboard" > InputDevice "Mouse0" "CorePointer" > Option "Xinerama" "0" > EndSection > > Section "Files" > EndSection > > Section "InputDevice" > > # generated from default > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/psaux" > Option "Emulate3Buttons" "no" > Option "ZAxisMapping" "4 5" > EndSection > > Section "InputDevice" > > # generated from default > Identifier "Keyboard0" > Driver "kbd" > EndSection > > Section "Monitor" > Identifier "Monitor0" > VendorName "Unknown" > ModelName "CMN" > HorizSync 53.0 - 66.0 > VertRefresh 48.0 - 60.0 > Option "DPMS" > EndSection > > Section "Monitor" > Identifier "Monitor1" > VendorName "Unknown" > ModelName "DELL C7017T" > HorizSync 30.0 - 83.0 > VertRefresh 56.0 - 76.0 > EndSection > > Section "Device" > Identifier "Device0" > Driver "nvidia" > VendorName "NVIDIA Corporation" > BoardName "Quadro K3100M" > BusID "PCI:1:0:0" > Screen 0 > EndSection > > Section "Device" > Identifier "Device1" > Driver "nvidia" > VendorName "NVIDIA Corporation" > BoardName "Quadro K3100M" > BusID "PCI:1:0:0" > Screen 1 > EndSection > > > > > From pankaj.b.bansal at oracle.com Wed May 23 07:09:58 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Wed, 23 May 2018 00:09:58 -0700 (PDT) Subject: [11] JDK-8199614 : [macos] ImageCursor.getBestSize() throws NullPointerException Message-ID: <3fe74c00-5648-46fc-855d-71ddf0f72297@default> Hi Kevin & Ajit, Please review this fix, Webrev: http://cr.openjdk.java.net/~pbansal/8199614/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8199614 Regards, Pankaj From johan.vos at gluonhq.com Wed May 23 10:48:16 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 23 May 2018 12:48:16 +0200 Subject: modules for repositories Message-ID: When we create modules that are expected to be uploaded to e.g. maven central or bintray, we have to create jar's with native libs. That is technically possible (see http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021887.html) but before I can finalise PR #83 ( https://github.com/javafxports/openjdk-jfx/pull/83) we need to decide where the build results should reside. Currently, build/sdk/lib contains the jars. The current PR will modify those jars so that they contain the native libraries, but that is wrong as we don't want the native libs in the jars in the standalone SDK. What would be the appropriate path for those new jars? build/repository build/publish build/uploads build/artifacts ? - Johan From kevin.rushforth at oracle.com Wed May 23 22:16:49 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 May 2018 15:16:49 -0700 Subject: OpenJFX code review policies, etc. Message-ID: 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 paulrussell70 at gmail.com Thu May 24 12:30:31 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Thu, 24 May 2018 13:30:31 +0100 Subject: OpenJFX code review policies, etc. Message-ID: "and the desired direction of the Project" - perhaps, Kevin, it would be worth you taking a few words describing what this "direction" is. We all know with JFX is currently, but what is the future direction? What are contributors working towards in the long run? I'm sure we've all got our own personal areas of interest, and it's surely motivational to hold onto a less than broad idea of this. Best, Paul On 24 May 2018 at 13:00, 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. OpenJFX code review policies, etc. (Kevin Rushforth) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 23 May 2018 15:16:49 -0700 > From: Kevin Rushforth > To: "openjfx-dev at openjdk.java.net" > Subject: OpenJFX code review policies, etc. > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > 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 > > > > End of openjfx-dev Digest, Vol 78, Issue 39 > ******************************************* > From johan.vos at gluonhq.com Thu May 24 13:03:50 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 24 May 2018 15:03:50 +0200 Subject: OpenJFX code review policies, etc. In-Reply-To: References: Message-ID: Hi Paul, That is a great question, and it has surfaced a number of times here. In my opinion, the direction of the project is mainly determined by the contributors. In a good eco-system, this lead to good results. In general, I think that if there is a large interest from many companies and individual to have feature X in JavaFX, it is more likely to happen because I assume that those companies have contributors working on OpenJFX, or they might pay other companies or individuals to work on it. In the end, roadmaps result in work to be done, so someone has to do the job. If there is enough interest in something, it will be easier to find someone or some people who will do it. Having said that, I'm all in for a more general, high-level roadmap, as long as it is always checked with reality, which (whether we like it or not) comes down to who wants to contribute resources. While this probably sounds very commercial coming from an open-source person, I realise that in order to keep open-source projects alive, there should be a clear connection with what customers in the end would like to have. - Johan On Thu, May 24, 2018 at 2:41 PM Paul Ray Russell wrote: > "and the desired direction of the Project" - perhaps, Kevin, it would be > worth you taking a few words describing what this "direction" is. We all > know with JFX is currently, but what is the future direction? What are > contributors working towards in the long run? I'm sure we've all got our > own personal areas of interest, and it's surely motivational to hold onto a > less than broad idea of this. > > Best, > Paul > > On 24 May 2018 at 13:00, 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. OpenJFX code review policies, etc. (Kevin Rushforth) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 23 May 2018 15:16:49 -0700 > > From: Kevin Rushforth > > To: "openjfx-dev at openjdk.java.net" > > Subject: OpenJFX code review policies, etc. > > Message-ID: > > Content-Type: text/plain; charset=utf-8; format=flowed > > > > 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 > > > > > > > > End of openjfx-dev Digest, Vol 78, Issue 39 > > ******************************************* > > > From kevin.rushforth at oracle.com Thu May 24 14:36:56 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 24 May 2018 07:36:56 -0700 Subject: JavaFX roadmap In-Reply-To: References: Message-ID: [changing the subject so we can keep the threads separate] I think Johan hits the nail on the head here. Realistically, "large feature X" is only going to happen if there are enough resources to make it happen. Of course smaller features / enhancements can be done by part-time contributors, but even then we need to be careful to avoid "drive by" features. As for an overarching roadmap, that seems like something that we (Gluon, Oracle, the OpenJFX community) can work on over the next little while. As Johan indicated, it needs to be tempered with reality. -- Kevin On 5/24/2018 6:03 AM, Johan Vos wrote: > Hi Paul, > > That is a great question, and it has surfaced a number of times here. > In my opinion, the direction of the project is mainly determined by the > contributors. In a good eco-system, this lead to good results. > In general, I think that if there is a large interest from many companies > and individual to have feature X in JavaFX, it is more likely to happen > because I assume that those companies have contributors working on OpenJFX, > or they might pay other companies or individuals to work on it. In the end, > roadmaps result in work to be done, so someone has to do the job. If there > is enough interest in something, it will be easier to find someone or some > people who will do it. > > Having said that, I'm all in for a more general, high-level roadmap, as > long as it is always checked with reality, which (whether we like it or > not) comes down to who wants to contribute resources. > > While this probably sounds very commercial coming from an open-source > person, I realise that in order to keep open-source projects alive, there > should be a clear connection with what customers in the end would like to > have. > > - Johan > > > > > > On Thu, May 24, 2018 at 2:41 PM Paul Ray Russell > wrote: > >> "and the desired direction of the Project" - perhaps, Kevin, it would be >> worth you taking a few words describing what this "direction" is. We all >> know with JFX is currently, but what is the future direction? What are >> contributors working towards in the long run? I'm sure we've all got our >> own personal areas of interest, and it's surely motivational to hold onto a >> less than broad idea of this. >> >> Best, >> Paul >> >> On 24 May 2018 at 13:00, 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. OpenJFX code review policies, etc. (Kevin Rushforth) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Wed, 23 May 2018 15:16:49 -0700 >>> From: Kevin Rushforth >>> To: "openjfx-dev at openjdk.java.net" >>> Subject: OpenJFX code review policies, etc. >>> Message-ID: >>> Content-Type: text/plain; charset=utf-8; format=flowed >>> >>> 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 >>> >>> >>> >>> End of openjfx-dev Digest, Vol 78, Issue 39 >>> ******************************************* >>> From nlisker at gmail.com Thu May 24 16:31:35 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 24 May 2018 19:31:35 +0300 Subject: OpenJFX code review policies, etc. In-Reply-To: References: Message-ID: Thanks for the detailed plan Kevin, 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. It will be a good idea to list the reviewers/experts (names and mail) according to their field, as done in the outdated Wiki [1]. This way contributors know who to address in a review request mail. Currently, I need to filter a subcomponent in JIRA and see who provides the fixes there to know who to ask. 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. Continuing the point above, it makes sense to me that a Reviewer role is assigned per field (whether a "field" is module, a set of packages or something else). While formally we need to give a list of Reviewers for OpenJFX, practically I don't think a Reviewer who contributed 40 out of his 42 commits to javafx.base can (and probably wouldn't anyway) Review in javafx.web. What I'm getting at is that whatever the threshold numbers are, it makes sense, at least informally, to count per field. If I submit 5 contributions per module and pass the threshold, what exactly am I qualified to Review? Granted, the threshold numbers includes familiarizing oneself with code patterns and tools which are global to the project, so to become a Reviewer in a 2nd field takes much less effort than the first time. This is just a point I wanted to make about the Reviewer role. We don't have to change formal policies. I propose that a New Feature, API addition, or behavioral change must be > reviewed / approved by a "lead". Can you give the guidelines by which a lead reviews / approves one of the above? 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. I would hope that the people in openjfx-dev who are not watching all PRs will have a chance to comment before the work starts, and not when the work is done and before it's merged. Visiting the mirror from time to time reveals to me PRs that weren't mentioned on the mailing list. Those PRs might be in conflict with work that isn't visible on GitHub. Iv'e brought it up in a past discussion about the mirror - we need to centralize the discussion medium. It's the normal price to pay for synchronization. - Nir [1] https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership On Thu, May 24, 2018 at 1:16 AM, 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-Febr > uary/021335.html > > [3] https://wiki.openjdk.java.net/display/csr/Main > > From kevin.rushforth at oracle.com Thu May 24 17:36:49 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 24 May 2018 10:36:49 -0700 Subject: OpenJFX code review policies, etc. In-Reply-To: References: Message-ID: <8ff76719-31ad-e515-d3c0-691085103a28@oracle.com> 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 philip.race at oracle.com Thu May 24 20:35:38 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 24 May 2018 13:35:38 -0700 Subject: RFR: 8129582: Controls slow considerably when displaying RTL-languages text on Linux Message-ID: <09c497a3-8382-d279-2575-3c7f037fdda6@oracle.com> Please review this fix for a performance problem in Pango Text Layout. The root cause was pointed out by itaisha at gmail.com, that the fontmap is an expensive thing to create, and we were recreating it on each call to layout. By caching it we can avoid this huge overhead. Bug : https://bugs.openjdk.java.net/browse/JDK-8129582 webrev : http://cr.openjdk.java.net/~prr/8129582/ -phil. From bourges.laurent at gmail.com Thu May 24 20:52:49 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 24 May 2018 22:52:49 +0200 Subject: [11] RFR JDK-8202743: Dashed Stroke randomly painted incorrectly, may freeze application Message-ID: Please review this simple fix for MarlinFX Dasher: JBS: https://bugs.openjdk.java.net/browse/JDK-8202743 webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8202743.0/ Github Pull request: https://github.com/javafxports/openjdk-jfx/pull/87 Notes: - (D)Dasher changes corresponds to MarlinFX 0.8.2 (upgrade to 0.9.2 later) - test adapted to javafx API using scene.snapshot() Laurent From prem.balakrishnan at oracle.com Fri May 25 09:13:12 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Fri, 25 May 2018 02:13:12 -0700 (PDT) Subject: [11] Review Request JDK-8201285 DateCell text color are not updated correctly when DateCell with disable = true is reused Message-ID: <20e63813-8e09-4772-b157-a01402ba1599@default> Hi Kevin, Ajit Request you to review following fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8201285 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/fx/8201285/webrev00/"http://cr.openjdk.java.net/~pkbalakr/fx/8201285/webrev00/ Regards, Prem From johan.vos at gluonhq.com Fri May 25 09:41:57 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 25 May 2018 11:41:57 +0200 Subject: webrev for JDK-8202396 Message-ID: The webrev for the memory leak in the iOS imageloader, which is fixed by https://github.com/javafxports/openjdk-jfx/pull/73/commits/7f264eda17fc91aedfa47e60ffa4a096a4904350 is available at http://cr.openjdk.java.net/~jvos/8202396/webrev.00/ Is is a simple 2-line fix that is reviewed in the github process, but I wait for a +1 to commit it in the OpenJFX repository as well. - Johan From murali.billa at oracle.com Fri May 25 14:03:13 2018 From: murali.billa at oracle.com (Murali Billa) Date: Fri, 25 May 2018 07:03:13 -0700 (PDT) Subject: [11] Review request for 8203698: JavaFX WebView crashes when visiting certain web sites Message-ID: <3d5d57de-a99f-426e-9946-9d6eea10b173@default> ? Hi Kevin, Arun Please review the below fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8203698 ? webrev:? http://cr.openjdk.java.net/~mbilla/8203698/webrev.00/ Thanks, Murali From paulrussell70 at gmail.com Fri May 25 15:16:08 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Fri, 25 May 2018 16:16:08 +0100 Subject: OpenJFX code review policies, etc. In-Reply-To: References: Message-ID: >In general, I think that if there is a large interest from many companies and individual to have feature X in JavaFX, it is more likely to >happen because I assume that those companies have contributors working on OpenJFX, or they might pay other companies or >individuals to work on it. In the end, roadmaps result in work to be done, so someone has to do the job. If there is enough interest in >something, it will be easier to find someone or some people who will do it. Thanks, Johan. I refer mostly to an interest of my own, in seeing an OpenGL canvas tied in properly with JavaFX. The current canvas is fine, but having the ability get directly to OpenGL would be a great boon for graphics/games programmers. You might be aware of: http://www.java-gaming.org/topics/lwjgl-javafx-integration/27801/msg/250527/view.html https://www.youtube.com/watch?v=aYRF34UYu-E&t=1094s So then, what constitutes "enough interest" to get a feature properly kicked off? Microsoft XNA under Mono has been given a new lease of life. Of course there is already LibGDX for Java: but JavaFX is such great framework in so many ways, and just needs access to pipeline programming to finish, what for me, is a great framework. If an implementation exposed only a few pipeline shaders it would be enough. Best, Paul On 24 May 2018 at 14:03, Johan Vos wrote: > Hi Paul, > > That is a great question, and it has surfaced a number of times here. > In my opinion, the direction of the project is mainly determined by the > contributors. In a good eco-system, this lead to good results. > In general, I think that if there is a large interest from many companies > and individual to have feature X in JavaFX, it is more likely to happen > because I assume that those companies have contributors working on OpenJFX, > or they might pay other companies or individuals to work on it. In the end, > roadmaps result in work to be done, so someone has to do the job. If there > is enough interest in something, it will be easier to find someone or some > people who will do it. > > Having said that, I'm all in for a more general, high-level roadmap, as > long as it is always checked with reality, which (whether we like it or > not) comes down to who wants to contribute resources. > > While this probably sounds very commercial coming from an open-source > person, I realise that in order to keep open-source projects alive, there > should be a clear connection with what customers in the end would like to > have. > > - Johan > > > > > > On Thu, May 24, 2018 at 2:41 PM Paul Ray Russell > wrote: > >> "and the desired direction of the Project" - perhaps, Kevin, it would be >> worth you taking a few words describing what this "direction" is. We all >> know with JFX is currently, but what is the future direction? What are >> contributors working towards in the long run? I'm sure we've all got our >> own personal areas of interest, and it's surely motivational to hold onto >> a >> less than broad idea of this. >> >> Best, >> Paul >> >> On 24 May 2018 at 13:00, 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. OpenJFX code review policies, etc. (Kevin Rushforth) >> > >> > >> > ---------------------------------------------------------------------- >> > >> > Message: 1 >> > Date: Wed, 23 May 2018 15:16:49 -0700 >> > From: Kevin Rushforth >> > To: "openjfx-dev at openjdk.java.net" >> > Subject: OpenJFX code review policies, etc. >> > Message-ID: >> > Content-Type: text/plain; charset=utf-8; format=flowed >> > >> > 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 >> > >> > >> > >> > End of openjfx-dev Digest, Vol 78, Issue 39 >> > ******************************************* >> > >> > From philip.race at oracle.com Fri May 25 18:10:28 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 May 2018 11:10:28 -0700 Subject: RFR: 8195808: Eliminate dependency on sun.print in javafx.graphics Message-ID: <508efc52-2a07-b401-e2fc-975b0aae5687@oracle.com> FX bug : https://bugs.openjdk.java.net/browse/JDK-8195808 FX webrev: http://cr.openjdk.java.net/~prr/8195808/ This updates FX to use proposed new standard Java SE API to specify an owner window for a Java 2D printer dialog, or to specify "always on top" behaviour where that is not possible. The Java SE change is proposed here : http://mail.openjdk.java.net/pipermail/2d-dev/2018-May/009231.html The FX change is a simple switch of the class name to use the new class name. The rest is removal of now defunct build code. -phil From guy.abossolo.foh at scientificware.com Sat May 26 08:14:39 2018 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Sat, 26 May 2018 10:14:39 +0200 Subject: OpenJDK Wiki - OpenJFX - Using an IDE Message-ID: <28503ee5900320fed204a9bdbb20bbef@scientificware.com> Hi, In the (OpenJDK Wiki - OpenJFX) Using an IDE, we can read : "NOTE: You must add a new platform named "JDK 1.8" even if you already have your default platform pointing to a JDK 8 platform." I presume we have to read JDK_1.8 ? Best regards. From kevin.rushforth at oracle.com Tue May 29 21:35:08 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 29 May 2018 14:35:08 -0700 Subject: webrev for JDK-8202396 In-Reply-To: References: Message-ID: <9c26b7e3-b7aa-8216-e771-8f71a96dab52@oracle.com> +1 On 5/25/2018 2:41 AM, Johan Vos wrote: > The webrev for the memory leak in the iOS imageloader, which is fixed by > https://github.com/javafxports/openjdk-jfx/pull/73/commits/7f264eda17fc91aedfa47e60ffa4a096a4904350 > is > available at http://cr.openjdk.java.net/~jvos/8202396/webrev.00/ > > Is is a simple 2-line fix that is reviewed in the github process, but I > wait for a +1 to commit it in the OpenJFX repository as well. > > - Johan From philip.race at oracle.com Tue May 29 22:43:21 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 29 May 2018 15:43:21 -0700 Subject: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop In-Reply-To: <5AF4E8AF.60202@oracle.com> References: <2d05cbeb-6305-10c1-154a-3989836222ff@oracle.com> <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> Message-ID: <5B0DD789.8000809@oracle.com> 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 lbrtchx at gmail.com Wed May 30 00:52:31 2018 From: lbrtchx at gmail.com (Albretch Mueller) Date: Wed, 30 May 2018 00:52:31 +0000 Subject: Is there a way to register a (synchronizing) listener to a javafx media player? Message-ID: If you go: https://www.ted.com/talks/melissa_fleming_a_boat_carrying_500_refugees_sunk_at_sea_the_story_of_two_survivors/transcript you will notice that they use some (javascript) strategy to link the video section to the transcript (in that case of 26 languages) in actionably and two-way fashion. You will notice that the textual segment is being highlighted as the speaker talks. So: https://www.ted.com/talks/melissa_fleming_a_boat_carrying_500_refugees_sunk_at_sea_the_story_of_two_survivors/transcript#t-55066 will bring you to: "Fr?her eine aufstrebende Sch?lerin, nur auf ihre Zukunft bedacht, war sie jetzt st?ndig voller Angst." and the other way around as well, if you click on that part of the talk the video will be accordingly reset to that moment; so, if you click on the phrase: "Ich arbeite, du kannst studieren -- die M?glichkeit eines neuen Lebens" the video will be correspondingly moved to: #t-80372 You can even change the language of the transcript as the video is watch and the textual segments will be reset as well! ~ Using a WebView you can access the link itself: https://www.ted.com/talks/melissa_fleming_a_boat_carrying_500_refugees_sunk_at_sea_the_story_of_two_survivors/transcript and watch the video without the synchronization to the subtitles and/or the option to change the language of the transcript. Using a javafx.scene.media.MediaView you can watch the video locally (with the embedded captions for the chosen language after downloading it from them). I need the kind of synchronization capability that ted is offering, but I don't see how you could achieve this using the javafx API. In fact, I haven't seen such a thing in software other than ted and if you can do that with javascript sure can you do it with JavaFX. Basically, all you need is a way to register a listener interface to the synchronizing strategy of the (MV)Controller exposing the beat of the video. How could you do such a thing with JavaFX? lbrtchx From alexander.matveev at oracle.com Wed May 30 02:57:11 2018 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 29 May 2018 19:57:11 -0700 Subject: [11] Review request for 8199527: Upgrade GStreamer to 1.14 Message-ID: <7ea1adac-30d0-7f45-e326-83e35c926693@oracle.com> Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8199527 Upgraded GStreamer to 1.14. Thanks, Alexander From kevin.rushforth at oracle.com Thu May 31 00:11:13 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 30 May 2018 17:11:13 -0700 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) Message-ID: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> 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 From mp at jugs.org Thu May 31 20:25:25 2018 From: mp at jugs.org (Michael Paus) Date: Thu, 31 May 2018 22:25:25 +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: <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> 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-May/053503.html > From kevin.rushforth at oracle.com Thu May 31 20:56:53 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 31 May 2018 13:56:53 -0700 Subject: Draft JEP for new Packaging Tool (replacement for javapackager) In-Reply-To: <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> References: <967e5224-9ff7-271d-30dd-09555c40760f@oracle.com> <6cdd375c-84e5-c105-2477-10bab165abd9@jugs.org> Message-ID: 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-May/053503.html >> > From kevin.rushforth at oracle.com Thu May 31 21:14:29 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 31 May 2018 14:14:29 -0700 Subject: OpenJFX code review policies, etc. In-Reply-To: References: Message-ID: <39b9b81e-4aab-37ec-6b48-b7fa202446b9@oracle.com> On 5/24/2018 9:31 AM, Nir Lisker wrote: > Thanks for the detailed plan Kevin, > > 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. > > > It will be a good idea to list the reviewers/experts (names and mail) > according to their field, as done in the outdated Wiki [1]. This way > contributors know who to address in a review request mail. Currently, > I need to filter a subcomponent in JIRA and see who provides the fixes > there to know who to ask. That is a good idea. Reviving this page after we have the initial list of reviewers seems like a good idea. > 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. > > > Continuing the point above, it makes sense to me that a Reviewer role > is assigned per field (whether a "field" is module, a set of packages > or something else). While formally we need to give a list of Reviewers > for OpenJFX, practically I don't think a Reviewer who contributed 40 > out of his 42 commits to javafx.base can (and probably wouldn't > anyway) Review in javafx.web. What I'm getting at is that whatever the > threshold numbers are, it makes sense, at least informally, to count > per field. If I submit 5 contributions per module and pass the > threshold, what exactly am I qualified to Review? That's an interesting, and accurate, observation. It sort of goes along with your earlier point about having areas of expertise. > Granted, the threshold numbers includes familiarizing oneself with > code patterns and tools which are global to the project, so to become > a Reviewer in a 2nd field takes much less effort than the first time. > > This is just a point I wanted to make about the Reviewer role. We > don't have to change formal policies. > > I propose that a New Feature, API addition, or behavioral change > must be reviewed / approved by a "lead". > > > 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. > 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. > > > I would hope that the people in openjfx-dev who are not watching all > PRs will have a chance to comment before the work starts, and not when > the work is done and before it's merged. Visiting the mirror from time > to time reveals to me PRs that weren't mentioned on the mailing list. > Those PRs might be in conflict with work that isn't visible on GitHub. > Iv'e brought it up in a past discussion about the mirror - we need to > centralize the discussion medium. It's the normal price to pay for > synchronization. > A fair point, which is why I proposed that one of the requirements for having this fast track review includes "... sending email to openjfx-dev when you first make a PR that you intend to have merged into the develop" so that those who are interested in a particular bug will know that a fix is under review. Thanks. -- Kevin > - Nir > > [1] https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership > > > On Thu, May 24, 2018 at 1:16 AM, 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 > > >