From kevin.rushforth at oracle.com Tue Dec 1 01:11:46 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 30 Nov 2015 17:11:46 -0800 Subject: Bulk packager integration In-Reply-To: <24C28C93-95A8-428C-B4FA-3B4D6B25DB45@oracle.com> References: <7552A67A-2D59-4FF5-B9FC-3F9E7A1E15BC@oracle.com> <56566523.6050202@oracle.com> <24C28C93-95A8-428C-B4FA-3B4D6B25DB45@oracle.com> Message-ID: <565CF3D2.7000500@oracle.com> Inline Danno Ferrin wrote: > >> On Nov 25, 2015, at 6:49 PM, Kevin Rushforth >> > wrote: >> >> 1) I get the following error if I apply the patch and do a build: >> >> :fxpackager:compileJava/localhome/kcr/javafx/9-jake-kcr/jfx/rt/modules/fxpackager/src/main/java/com/oracle/tools/packager/JLinkBundlerHelper.java:3: >> error: package com.sun.tools.jdeps does not exist >> import com.sun.tools.jdeps.Main; >> ^ >> >> Does this require a newer version of JDK9 jigsaw or is there some >> other issue? If the former, then we need to solve a problem that >> isn't yet solved with the build environment on our Hudson machines >> before this can go in. >> >> > > Do you have the module-info.java.extra file loaded up? It may be a > build issue since that file is not exported by default. Is this the > same error we see when it doen't like the module boundaries? do we > need to add some -XaddExports? It works for me, and the file is years > old, so it may be order or operations issues with the JDK that is on > the build server. > > I'll look into building from a public EA build of Java 9 then (if I > have time, Chris or Dmitry may get to do that). The JDK on the build server was built about 3 weeks ago and hasn't been refreshed. We don't currently have a good way to take a JDK9 jigsaw build that contains packager modules and use that to build fxpackager. We will need a solution to this, so we don't have to keep generating two builds -- one with and one without the packager bits, the latter being what we currently need as the JDK9_HOME we use to build FX. >> 2) The JDK9_MODULES is a new variable that isn't currently defined. >> What should it be set to? It looks like it is only used by the >> packagerDev task, so might be OK. >> > > Right now it is for packagerdev, but going forward I see it being > needed for the unit tests. OK. >> 3) The classesModuleExclude mechanism duplicates an existing >> mechanism to filter out classes from going into the modules. Are you >> sure this new mechanism is needed? After I fixed >> https://bugs.openjdk.java.net/browse/JDK-8142381 a couple weeks ago I >> no longer see any classes from ant-javafx.jar showing up in the >> fxpackager module. >> > > I'll look into removing that code then. Thanks. -- Kevin > > >> -- Kevin >> >> >> Danno Ferrin wrote: >>> Here's the webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/ >>> (it's been a stressful morning) >>> >>> >>>> On Nov 25, 2015, at 9:38 AM, Danno Ferrin wrote: >>>> >>>> Kevin, Chris, Dmitry >>>> >>>> This is a bulk packager integration from the packager sandbox to the JavaFX Sandbox, please review. >>>> >>>> webrev: >>>> >>>> There are three changes outside of the fxpackager module that I think Kevin needs to give his approval for. >>>> >>>> Two changes are in the build.gradle. The first adds a concept of classesModuleExclude which is a regexp for files to exclude from the modular jar. This is to support creating the ant jar outside of the module system so that ant can read the required types and classes. >>>> >>>> The second change is to introduce JDK9_MODULES, read off of an environmental variable. This should point to your jmods directory (not explored modules, this must be jmods). This is to support the packagerdev target which now needs a pointer to the jmods which as of yet does not have a standard location relative to the JDK/JRE. >>>> >>>> The third change is the addition of another module-info.java.extra file. This one exposes the invocation API for JDeps to packager so the detectmodules can use it to sniff out modules from the classpath. >>>> >>>> The remainder of the changes are internal to the fxpackager modules and represent contributions from Chris Bensen, Dmitry Cherepanov, and myself finishing out the last details for JEP275. This patch should make it feature complete (but not bug complete, we got another milestone for that). >>>> >>>> --Danno >>>> >>> >>> > From felix.bembrick at gmail.com Tue Dec 1 02:00:51 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 1 Dec 2015 13:00:51 +1100 Subject: Future of JavaFX In-Reply-To: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> Message-ID: <6E273C5A-CB3A-40B2-BA72-EC7014D3D46B@gmail.com> The problem is that JavaFX is not used in any Oracle products (whereas Swing is), it makes them no money and it fact they are constantly bleeding while maintaining a team to develop a product that brings in no money and doesn't fit into their whole "cloud is everything" strategy. I would say that from Oracles point of view, JavaFX will not be developed any further. However, Gluon and RoboVM are doing their best to keep it alive but they are a very small under resourced team. In my opinion, JavaFX should be jettisoned from the JDK and managed by a company like Gluon on all platforms and be monetised just like the very successful Qt Company which just sells and supports Qt. With JavaFX, Oracle are an impediment to its success. We need a "JavaFX Company" that will develop it, sell it and support it. It should be separate from the JDK so it can have its own independent and more frequent release cycle. That's how to save JavaFX. But I am probably dreaming... > On 1 Dec 2015, at 09:54, Casall, Alexander wrote: > > Don, thanks for your important contribution to this thread. > > What exactly means oracle continues to develop on fx? What is the roadmap? > > If I check the mercurial archives there are 10-12 people working constantly on FX in this year. The most work was done by a few of them. I'm not sure whether this is enought to move FX forward to engage more and more adopters. > > The core question is, are there any plans to put more ressources on fx? > > - Alex > > > From: Donald Smith > Sent: 30.11.15, 17:35 > To: openjfx-dev at openjdk.java.net Mailing > Subject: Re: Future of JavaFX > Oracle is still committed to JavaFX and it will still be around for a while. > > As of 7u6 we bundled JavaFX with the Oracle JDK, we've open sourced 100% > of the code, we continue developing for it, etc. I understand that > while there is both Swing and JavaFX available that people will continue > to question the existence of each -- so be it. Each has it's own niches > and benefits and our strategy, as it has been for years now, is to > continue with each. > > - Don > > >> On 30/11/2015 11:13 AM, Dirk @ Google wrote: >> Hi there, >> >> there has been quite a shake-up in the JavaFX community last week when Shay Almog (Codename One) first responded to a blog of mine (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html>). >> >> I do understand that it is often a good strategy to not comment on stuff like this because commenting would just draw attention to it, but we have now reached the point where potential customers are questioning the sustainability of a JavaFX-based solution. They are now wondering if JavaFX will still be around in a few years. In my specific case the customer demands an answer from me and my partners within the next week, and if not convincing they will go with something / someone else. We will loose a contract worth around one million dollars because of one blog written by Shay with no follow-up from Oracle. >> >> What is needed is an official statement from Oracle / Oracle employees / JavaFX development team, saying that Oracle is still committed to JavaFX and that it will still be around for a while. Can somebody please do that? >> >> Dirk > From mik3hall at gmail.com Tue Dec 1 02:30:42 2015 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 30 Nov 2015 20:30:42 -0600 Subject: Bulk packager integration In-Reply-To: <24C28C93-95A8-428C-B4FA-3B4D6B25DB45@oracle.com> References: <7552A67A-2D59-4FF5-B9FC-3F9E7A1E15BC@oracle.com> <56566523.6050202@oracle.com> <24C28C93-95A8-428C-B4FA-3B4D6B25DB45@oracle.com> Message-ID: <59B34161-CF69-4A22-AE8E-7C3719B67434@gmail.com> > On Nov 30, 2015, at 9:19 AM, Danno Ferrin wrote: > > do we need to add some -XaddExports? Yes? java -cp . JRTLister -p com.sun.tools.jdeps.Main /modules/jdk.jdeps/com/sun/tools/jdeps/Main.class javac TestJdeps.java TestJdeps.java:1: error: package com.sun.tools.jdeps does not exist import com.sun.tools.jdeps.Main; Macintosh:jigsaw mjh$ javac -XaddExports:jdk.jdeps/com.sun.tools.jdeps=ALL-UNNAMED TestJdeps.java Macintosh:jigsaw mjh$ import com.sun.tools.jdeps.Main; public class TestJdeps { public static void main(String[] args) { try { Main.main(new String[] { "-version" }); } catch (Exception ex) { ex.printStackTrace(); } } } [fwiw http://www195.pair.com/mik3hall/JRTLister.java] Michael Hall From guru.hb at oracle.com Tue Dec 1 04:56:21 2015 From: guru.hb at oracle.com (Guru Hb) Date: Mon, 30 Nov 2015 20:56:21 -0800 (PST) Subject: [9] Review request for 8140501 : WebView crashes when loading content in a locationlistener In-Reply-To: <0ff4e990-4c6a-429d-bf38-26c6c9308717@default> References: <0ff4e990-4c6a-429d-bf38-26c6c9308717@default> Message-ID: Hi Arun, Alexander & Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8140501/ Webrev : http://cr.openjdk.java.net/~ghb/8140501/webrev.01/ Regression test incorporated and Async loadcontent executed only in READY state. Thanks, Guru -----Original Message----- From: Guru Hb Sent: Monday, November 30, 2015 12:22 PM To: Alexander Zvegintsev; Arunprasad Rajkumar; Kevin C Rushforth Cc: openjfx-dev at openjdk.java.net Subject: [9] Review request for 8140501 : WebView crashes when loading content in a locationlistener Hi Arunprasad, Alexander & Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8140501 Webrev : http://cr.openjdk.java.net/~ghb/8140501/webrev.00/ Tested on Windows and Linux (both 64 bit). Thnaks, Guru From guru.hb at oracle.com Tue Dec 1 04:59:19 2015 From: guru.hb at oracle.com (Guru Hb) Date: Mon, 30 Nov 2015 20:59:19 -0800 (PST) Subject: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time Message-ID: <1bee96ff-3087-4689-82ab-54d3ba21053d@default> Hi Arunprasad, Alexander & Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/ Webrev : http://cr.openjdk.java.net/~ghb/8143894/webrev.00 Tested on Windows and Linux (both 64 bit). Thnaks, Guru From alexander.casall at saxsys.de Tue Dec 1 06:35:40 2015 From: alexander.casall at saxsys.de (Casall, Alexander) Date: Tue, 1 Dec 2015 06:35:40 +0000 Subject: Future of JavaFX References: Future of JavaFX Message-ID: <6C6CE4A9B94582468498929459CEEF711011D22B@vmex1.saxsys.de> I don't agree. To move it away from Oracle would be the official death of fx. And you could hire oracle engineering services, so there is commercial support, if you have the money to pay for. I think one option would be, that oracle engages commiters to contribute. In addition the fx team should have the capacity to manage the open source process, like doing a lot of reviews to assure the quality. RoboVM is sold to xamarin, so they are not in he game anymore. I think the solution could be: - more developers (even in India :-) ) - make OpenJFX to a real open source project - Alex From: Felix Bembrick Sent: 01.12.15, 03:00 To: Casall, Alexander Cc: Donald Smith, openjfx mailing list Subject: Re: Future of JavaFX The problem is that JavaFX is not used in any Oracle products (whereas Swing is), it makes them no money and it fact they are constantly bleeding while maintaining a team to develop a product that brings in no money and doesn't fit into their whole "cloud is everything" strategy. I would say that from Oracles point of view, JavaFX will not be developed any further. However, Gluon and RoboVM are doing their best to keep it alive but they are a very small under resourced team. In my opinion, JavaFX should be jettisoned from the JDK and managed by a company like Gluon on all platforms and be monetised just like the very successful Qt Company which just sells and supports Qt. With JavaFX, Oracle are an impediment to its success. We need a "JavaFX Company" that will develop it, sell it and support it. It should be separate from the JDK so it can have its own independent and more frequent release cycle. That's how to save JavaFX. But I am probably dreaming... > alexander.casall at saxsys.de> wrote: > > Don, thanks for your important contribution to this thread. > > What exactly means oracle continues to develop on fx? What is the roadmap? > > If I check the mercurial archives there are 10-12 people working constantly on FX in this year. The most work was done by a few of them. I'm not sure whether this is enought to move FX forward to engage more and more adopters. > > The core question is, are there any plans to put more ressources on fx? > > - Alex > > > From: Donald Smith > Sent: 30.11.15, 17:35 > To: openjfx-dev at openjdk.java.net Mailing > Subject: Re: Future of JavaFX > Oracle is still committed to JavaFX and it will still be around for a while. > > As of 7u6 we bundled JavaFX with the Oracle JDK, we've open sourced 100% > of the code, we continue developing for it, etc. I understand that > while there is both Swing and JavaFX available that people will continue > to question the existence of each -- so be it. Each has it's own niches > and benefits and our strategy, as it has been for years now, is to > continue with each. > > - Don > > >> On 30/11/2015 11:13 AM, Dirk @ Google wrote: >> Hi there, >> >> there has been quite a shake-up in the JavaFX community last week when Shay Almog (Codename One) first responded to a blog of mine (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html>). >> >> I do understand that it is often a good strategy to not comment on stuff like this because commenting would just draw attention to it, but we have now reached the point where potential customers are questioning the sustainability of a JavaFX-based solution. They are now wondering if JavaFX will still be around in a few years. In my specific case the customer demands an answer from me and my partners within the next week, and if not convincing they will go with something / someone else. We will loose a contract worth around one million dollars because of one blog written by Shay with no follow-up from Oracle. >> >> What is needed is an official statement from Oracle / Oracle employees / JavaFX development team, saying that Oracle is still committed to JavaFX and that it will still be around for a while. Can somebody please do that? >> >> Dirk > From felix.bembrick at gmail.com Tue Dec 1 06:43:08 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 1 Dec 2015 17:43:08 +1100 Subject: Future of JavaFX In-Reply-To: <6C6CE4A9B94582468498929459CEEF711011D22B@vmex1.saxsys.de> References: <6C6CE4A9B94582468498929459CEEF711011D22B@vmex1.saxsys.de> Message-ID: <6262471A-7A57-450B-80B0-F5FD275DC55E@gmail.com> If JavaFX stays under Oracle control, it will be the same it is today in 5 years. I really doubt they will put another dollar into its expansion and new features. How can that be good? Plus the company that does take over could provide commercial support as well as training (which Oracle doesn't). > On 1 Dec 2015, at 17:35, Casall, Alexander wrote: > > I don't agree. To move it away from Oracle would be the official death of fx. > And you could hire oracle engineering services, so there is commercial support, if you have the money to pay for. > > I think one option would be, that oracle engages commiters to contribute. In addition the fx team should have the capacity to manage the open source process, like doing a lot of reviews to assure the quality. > > RoboVM is sold to xamarin, so they are not in he game anymore. > > I think the solution could be: > - more developers (even in India :-) ) > - make OpenJFX to a real open source project > > - Alex > > From: Felix Bembrick > Sent: 01.12.15, 03:00 > To: Casall, Alexander > Cc: Donald Smith, openjfx mailing list > Subject: Re: Future of JavaFX > > The problem is that JavaFX is not used in any Oracle products (whereas Swing is), it makes them no money and it fact they are constantly bleeding while maintaining a team to develop a product that brings in no money and doesn't fit into their whole "cloud is everything" strategy. > > I would say that from Oracles point of view, JavaFX will not be developed any further. > > However, Gluon and RoboVM are doing their best to keep it alive but they are a very small under resourced team. > > In my opinion, JavaFX should be jettisoned from the JDK and managed by a company like Gluon on all platforms and be monetised just like the very successful Qt Company which just sells and supports Qt. > > With JavaFX, Oracle are an impediment to its success. We need a "JavaFX Company" that will develop it, sell it and support it. It should be separate from the JDK so it can have its own independent and more frequent release cycle. > > That's how to save JavaFX. > > But I am probably dreaming... > > > alexander.casall at saxsys.de> wrote: > > > > Don, thanks for your important contribution to this thread. > > > > What exactly means oracle continues to develop on fx? What is the roadmap? > > > > If I check the mercurial archives there are 10-12 people working constantly on FX in this year. The most work was done by a few of them. I'm not sure whether this is enought to move FX forward to engage more and more adopters. > > > > The core question is, are there any plans to put more ressources on fx? > > > > - Alex > > > > > > From: Donald Smith > > Sent: 30.11.15, 17:35 > > To: openjfx-dev at openjdk.java.net Mailing > > Subject: Re: Future of JavaFX > > Oracle is still committed to JavaFX and it will still be around for a while. > > > > As of 7u6 we bundled JavaFX with the Oracle JDK, we've open sourced 100% > > of the code, we continue developing for it, etc. I understand that > > while there is both Swing and JavaFX available that people will continue > > to question the existence of each -- so be it. Each has it's own niches > > and benefits and our strategy, as it has been for years now, is to > > continue with each. > > > > - Don > > > > > >> On 30/11/2015 11:13 AM, Dirk @ Google wrote: > >> Hi there, > >> > >> there has been quite a shake-up in the JavaFX community last week when Shay Almog (Codename One) first responded to a blog of mine (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html>). > >> > >> I do understand that it is often a good strategy to not comment on stuff like this because commenting would just draw attention to it, but we have now reached the point where potential customers are questioning the sustainability of a JavaFX-based solution. They are now wondering if JavaFX will still be around in a few years. In my specific case the customer demands an answer from me and my partners within the next week, and if not convincing they will go with something / someone else. We will loose a contract worth around one million dollars because of one blog written by Shay with no follow-up from Oracle. > >> > >> What is needed is an official statement from Oracle / Oracle employees / JavaFX development team, saying that Oracle is still committed to JavaFX and that it will still be around for a while. Can somebody please do that? > >> > >> Dirk > > From info at cuhka.com Tue Dec 1 08:12:48 2015 From: info at cuhka.com (info at cuhka.com) Date: Tue, 01 Dec 2015 03:12:48 -0500 Subject: Future of JavaFX In-Reply-To: <6262471A-7A57-450B-80B0-F5FD275DC55E@gmail.com> References: <6C6CE4A9B94582468498929459CEEF711011D22B@vmex1.saxsys.de> <6262471A-7A57-450B-80B0-F5FD275DC55E@gmail.com> Message-ID: <20151201031248.Horde.JsY0KA6lAh-OFxB_pOU8M62@dime187.dizinc.com> If it is not a part of OpenJDK/Oracle JDK it will not work. Whether Oracle itself maintains the code doesn't really matter I think, but they have to put support and development in it. To me another downside if Oracle would suspend further development is that any statements made by Oracle seem to carry not so much value. If I'm correct JavaFX was presented by Oracle as the Swing replacement. If after a short time they revert from that position, what would that mean for any other statement? Citeren Felix Bembrick : > If JavaFX stays under Oracle control, it will be the same it is > today in 5 years. I really doubt they will put another dollar into > its expansion and new features. > > How can that be good? > > Plus the company that does take over could provide commercial > support as well as training (which Oracle doesn't). From felix.bembrick at gmail.com Tue Dec 1 08:21:15 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 1 Dec 2015 19:21:15 +1100 Subject: Future of JavaFX In-Reply-To: <20151201031248.Horde.JsY0KA6lAh-OFxB_pOU8M62@dime187.dizinc.com> References: <6C6CE4A9B94582468498929459CEEF711011D22B@vmex1.saxsys.de> <6262471A-7A57-450B-80B0-F5FD275DC55E@gmail.com> <20151201031248.Horde.JsY0KA6lAh-OFxB_pOU8M62@dime187.dizinc.com> Message-ID: <77B92266-D7DA-4D00-A523-3E3F65DF464D@gmail.com> Well, it is the official Swing replacement but look at Java 9 and you won't see many if any enhancements to JavaFX. The point is Oracle has no interest in desktop software other than maintaining any existing support contracts. I don't even think Oracle wants JavaFX so it would be better for everyone to take ownership of it and build a company purely around JavaFX that's actually profitable and keeps enhancing the product at a much faster pace. > On 1 Dec 2015, at 19:12, info at cuhka.com wrote: > > If it is not a part of OpenJDK/Oracle JDK it will not work. Whether Oracle itself maintains the code doesn't really matter I think, but they have to put support and development in it. > > To me another downside if Oracle would suspend further development is that any statements made by Oracle seem to carry not so much value. If I'm correct JavaFX was presented by Oracle as the Swing replacement. If after a short time they revert from that position, what would that mean for any other statement? > > > Citeren Felix Bembrick : > >> If JavaFX stays under Oracle control, it will be the same it is today in 5 years. I really doubt they will put another dollar into its expansion and new features. >> >> How can that be good? >> >> Plus the company that does take over could provide commercial support as well as training (which Oracle doesn't). > > From peter.pilgrim at gmail.com Tue Dec 1 09:45:24 2015 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Tue, 1 Dec 2015 09:45:24 +0000 Subject: Future of JavaFX In-Reply-To: <77B92266-D7DA-4D00-A523-3E3F65DF464D@gmail.com> References: <6C6CE4A9B94582468498929459CEEF711011D22B@vmex1.saxsys.de> <6262471A-7A57-450B-80B0-F5FD275DC55E@gmail.com> <20151201031248.Horde.JsY0KA6lAh-OFxB_pOU8M62@dime187.dizinc.com> <77B92266-D7DA-4D00-A523-3E3F65DF464D@gmail.com> Message-ID: Hi All I find it remarkable to see that this debate about innovation-versus-maintenance is similar to the one going on in the Java EE space. See https://java.net/projects/javaee-spec/lists/users/archive/2015-01/message/48 - Many Java EE experts, including myself, are now looking at the application servers and the ability to modularise the EE specification, so that we can just launch an application with `java -jar acme.jar'. Of course, we are already wrong about that command line option, because the JDK 9 will be a game changer. Anyway, Shai, has some valid interesting assertions in his blog entry. I don't think it is all FUD in the way that Microsoft used to secretly push in their strategic vision to conquer the desktop world. I do believe that his evidence shows how weak OTHER developers view Java client side technologies. JavaFX has not set the world on fire and has been the vision that I saw at the first presentation in JavaOne 2007. But that was yesterday, 8 years ago in fact. I lot of mistakes were made, and the vision could have better. We all had to follow the education and the learning path. Hindsight is a beautiful thing, a lot of us though scripting languages were exciting back then. We should have started with an all Java API solution in the first place, but there you go... Donald said the JavaFX is 100% open source, so what is the real issue. We have the code, go and build. Alexander, I downloaded your JavaOne presentation, I went through it last night. It is good stuff with all of those 11 business enterprise applications. Why are these applications not good enough to show adoption? Last year, 2014, I watch a JavaFX talk at JavaOne on a financial trading system written in JavaFX (CelerFX or something). What gives here? I am definitely a Java EE guy these days ever since I wrote two books, but you fellows need to step up, I think, promote FX more strongly yourselves. I know that Nandini (who is now at Twitter) pushed a FX show case a couple times in the past, first for JavaFX 1.0 and then 1.2. Jim did with blog and is still going at Pivotal. Guys you need to do more videos, screen captures and more talks. If the popular Java conferences don't take you on, then f*** e* and host your own video shows like Adam Bien. Build some excitement about what your have done with FX in your applications. Grow some con****** and come down with the attitude. The good news is that JDK 9 will bring a better deployment story for Java on the whole. You can have launchers and modules that only your application require. Perhaps, were the value is. On 1 December 2015 at 08:21, Felix Bembrick wrote: > Well, it is the official Swing replacement but look at Java 9 and you won't see many if any enhancements to JavaFX. The point is Oracle has no interest in desktop software other than maintaining any existing support contracts. > > I don't even think Oracle wants JavaFX so it would be better for everyone to take ownership of it and build a company purely around JavaFX that's actually profitable and keeps enhancing the product at a much faster pace. > >> On 1 Dec 2015, at 19:12, info at cuhka.com wrote: >> >> If it is not a part of OpenJDK/Oracle JDK it will not work. Whether Oracle itself maintains the code doesn't really matter I think, but they have to put support and development in it. >> >> To me another downside if Oracle would suspend further development is that any statements made by Oracle seem to carry not so much value. If I'm correct JavaFX was presented by Oracle as the Swing replacement. If after a short time they revert from that position, what would that mean for any other statement? >> >> >> Citeren Felix Bembrick : >> >>> If JavaFX stays under Oracle control, it will be the same it is today in 5 years. I really doubt they will put another dollar into its expansion and new features. >>> >>> How can that be good? >>> >>> Plus the company that does take over could provide commercial support as well as training (which Oracle doesn't). >> >> -- Best wishes Peter Pilgrim, Java Champion / Director P.E.A.T. LTD ++++ Scala and Java EE Software Development / Design / Architect for `BlueChip' enterprises, London, UK ++++ I am currently writing ``Digital Java EE 7 Development'' Packt Pub (September 2015) ++++ Digital ++ Finance ++ Adaptation ++ Transformation ++ Software ++++ :: http://www.xenonique.co.uk/blog/ :: :: http://twitter.com/peter_pilgrim :: :: http://java-champions.java.net/ :: From felix.bembrick at gmail.com Tue Dec 1 13:03:38 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Wed, 2 Dec 2015 00:03:38 +1100 Subject: Future of JavaFX In-Reply-To: References: <6C6CE4A9B94582468498929459CEEF711011D22B@vmex1.saxsys.de> <6262471A-7A57-450B-80B0-F5FD275DC55E@gmail.com> <20151201031248.Horde.JsY0KA6lAh-OFxB_pOU8M62@dime187.dizinc.com> <77B92266-D7DA-4D00-A523-3E3F65DF464D@gmail.com> Message-ID: Is it really true that *all* of JavaFX is open source? Even if it is, if I wanted to say take some aspects of the product in a radical new direction, wouldn't someone from Oracle have to approve the changes? If yes, then only Oracle can bring the big enhancements that are necessary which we know will never happen. As I said, the biggest impediment to the growth in features, performance and adoption of JavaFX is Oracle themselves. > On 1 Dec 2015, at 20:45, Peter Pilgrim wrote: > > Hi All > > I find it remarkable to see that this debate about > innovation-versus-maintenance is similar to the one going on in the > Java EE space. See > https://java.net/projects/javaee-spec/lists/users/archive/2015-01/message/48 > - Many Java EE experts, including myself, are now looking at the > application servers and the ability to modularise the EE > specification, so that we can just launch an application with `java > -jar acme.jar'. Of course, we are already wrong about that command > line option, because the JDK 9 will be a game changer. > > Anyway, Shai, has some valid interesting assertions in his blog entry. > I don't think it is all FUD in the way that Microsoft used to secretly > push in their strategic vision to conquer the desktop world. I do > believe that his evidence shows how weak OTHER developers view Java > client side technologies. JavaFX has not set the world on fire and has > been the vision that I saw at the first presentation in JavaOne 2007. > > But that was yesterday, 8 years ago in fact. I lot of mistakes were > made, and the vision could have better. We all had to follow the > education and the learning path. Hindsight is a beautiful thing, a lot > of us though scripting languages were exciting back then. We should > have started with an all Java API solution in the first place, but > there you go... > > Donald said the JavaFX is 100% open source, so what is the real > issue. We have the code, go and build. > > Alexander, I downloaded your JavaOne presentation, I went through it > last night. It is good stuff with all of those 11 business enterprise > applications. Why are these applications not good enough to show > adoption? > > Last year, 2014, I watch a JavaFX talk at JavaOne on a financial > trading system written in JavaFX (CelerFX or something). What gives > here? > > I am definitely a Java EE guy these days ever since I wrote two books, > but you fellows need to step up, I think, promote FX more strongly > yourselves. I know that Nandini (who is now at Twitter) pushed a FX > show case a couple times in the past, first for JavaFX 1.0 and then > 1.2. Jim did with blog and is still going at Pivotal. Guys you need to > do more videos, screen captures and more talks. If the popular Java > conferences don't take you on, then f*** e* and host your own video > shows like Adam Bien. Build some excitement about what your have done > with FX in your applications. Grow some con****** and come down with > the attitude. > > The good news is that JDK 9 will bring a better deployment story for > Java on the whole. You can have launchers and modules that only your > application require. Perhaps, were the value is. > > >> On 1 December 2015 at 08:21, Felix Bembrick wrote: >> Well, it is the official Swing replacement but look at Java 9 and you won't see many if any enhancements to JavaFX. The point is Oracle has no interest in desktop software other than maintaining any existing support contracts. >> >> I don't even think Oracle wants JavaFX so it would be better for everyone to take ownership of it and build a company purely around JavaFX that's actually profitable and keeps enhancing the product at a much faster pace. >> >>> On 1 Dec 2015, at 19:12, info at cuhka.com wrote: >>> >>> If it is not a part of OpenJDK/Oracle JDK it will not work. Whether Oracle itself maintains the code doesn't really matter I think, but they have to put support and development in it. >>> >>> To me another downside if Oracle would suspend further development is that any statements made by Oracle seem to carry not so much value. If I'm correct JavaFX was presented by Oracle as the Swing replacement. If after a short time they revert from that position, what would that mean for any other statement? >>> >>> >>> Citeren Felix Bembrick : >>> >>>> If JavaFX stays under Oracle control, it will be the same it is today in 5 years. I really doubt they will put another dollar into its expansion and new features. >>>> >>>> How can that be good? >>>> >>>> Plus the company that does take over could provide commercial support as well as training (which Oracle doesn't). > > > > -- > Best wishes > > Peter Pilgrim, > Java Champion / Director P.E.A.T. LTD > > ++++ Scala and Java EE Software Development / Design / Architect > for `BlueChip' enterprises, London, UK ++++ > > I am currently writing ``Digital Java EE 7 Development'' Packt Pub > (September 2015) > > ++++ Digital ++ Finance ++ Adaptation ++ Transformation ++ Software ++++ > > :: http://www.xenonique.co.uk/blog/ :: > :: http://twitter.com/peter_pilgrim :: > :: http://java-champions.java.net/ :: From neugens.limasoftware at gmail.com Tue Dec 1 13:22:14 2015 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 1 Dec 2015 14:22:14 +0100 Subject: Future of JavaFX In-Reply-To: References: <6C6CE4A9B94582468498929459CEEF711011D22B@vmex1.saxsys.de> <6262471A-7A57-450B-80B0-F5FD275DC55E@gmail.com> <20151201031248.Horde.JsY0KA6lAh-OFxB_pOU8M62@dime187.dizinc.com> <77B92266-D7DA-4D00-A523-3E3F65DF464D@gmail.com> Message-ID: 2015-12-01 14:03 GMT+01:00 Felix Bembrick : > Is it really true that *all* of JavaFX is open source? > > Even if it is, if I wanted to say take some aspects of the product in a radical new direction, wouldn't someone from Oracle have to approve the changes? > > If yes, then only Oracle can bring the big enhancements that are necessary which we know will never happen. You can always try to propose the changes you want to see, and if it fails, of course provided you follow the License (GPL + Classpath Exception), you can take, modify and redistribute the sources as you see fit. Btw, as a general note, I always find discussing about how impossible any contribution is *without* first trying to contribute anything a real waste of time. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From johan.vos at gluonhq.com Tue Dec 1 13:27:05 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 1 Dec 2015 14:27:05 +0100 Subject: Future of JavaFX In-Reply-To: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> Message-ID: Hi Dirk, all, Although this person from Codename One attacked me a few times before (using words like we're selling snake oil), I tried to ignore it. This is very uncommon for the Java community. In the Java community, we have different views, we prefer different technologies, but we show at least some basic respect to other views and we don't insult people. Clearly, this isn't the policy inside Codename One. I wonder where they get the time for writing negative things about others, rather than writing positive things about their own technologies. So although I'm offended, I try to write code and keep my customers happy rather than fighting. But the moment you may lose customers because what others write about a technology you want to use, a line is crossed. I keep all options open on how to respond, but here are already some thoughts: * The JavaFX engineers at Oracle (current and past) are doing a fantastic job. * Yes, I wish Oracle would spend more resources on JavaFX (and on Java in general). * JavaFX is growing. Gluon is growing. * There are many JavaFX success stories, but unfortunately many of those are hidden behind company walls. At Gluon, we have great customers with a huge investment in JavaFX that make amazing products. But company policies often prohibit us from even mentioning those on our website. This is an issue, as I believe many people would be surprised to see who is using JavaFX and at what size. I'm not sure how to address this, and it is something Peter Pilgrim talked about in a follow-up post as well. * JavaFX on Mobile is getting there. Don't believe self-declared and aggressive "mobile experts" with a different agenda. I'm one of those people working day and night to make this happen. And apart from very few exceptions, the Java community has been very supportive to this effort. I don't let those exceptions ruining my day or my customers. * There really is a JavaFX eco-system. Oracle is spending resources on it, and there are a large number of individuals and companies providing free and commercial frameworks, services, trainings, books. * JavaFX is open source with a business-friendly license. You don't like something? Fix it. Dirk, keep up the good work. I hope your customer realises that there is a large community behind JavaFX, with both open-source and commercial offerings. They should feel safe using JavaFX. - Johan On Mon, Nov 30, 2015 at 5:13 PM, Dirk @ Google wrote: > Hi there, > > there has been quite a shake-up in the JavaFX community last week when > Shay Almog (Codename One) first responded to a blog of mine ( > dlemmermann.wordpress.com) with a lot of negative comments regarding > JavaFX and its future. He then followed up with a long blog asking the > question ?Should Oracle Spring-Clean JavaFX? ( > https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html < > https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html>). > > I do understand that it is often a good strategy to not comment on stuff > like this because commenting would just draw attention to it, but we have > now reached the point where potential customers are questioning the > sustainability of a JavaFX-based solution. They are now wondering if JavaFX > will still be around in a few years. In my specific case the customer > demands an answer from me and my partners within the next week, and if not > convincing they will go with something / someone else. We will loose a > contract worth around one million dollars because of one blog written by > Shay with no follow-up from Oracle. > > What is needed is an official statement from Oracle / Oracle employees / > JavaFX development team, saying that Oracle is still committed to JavaFX > and that it will still be around for a while. Can somebody please do that? > > Dirk > > > From johan.vos at gluonhq.com Tue Dec 1 13:35:09 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 1 Dec 2015 14:35:09 +0100 Subject: Future of JavaFX In-Reply-To: References: <6C6CE4A9B94582468498929459CEEF711011D22B@vmex1.saxsys.de> <6262471A-7A57-450B-80B0-F5FD275DC55E@gmail.com> <20151201031248.Horde.JsY0KA6lAh-OFxB_pOU8M62@dime187.dizinc.com> <77B92266-D7DA-4D00-A523-3E3F65DF464D@gmail.com> Message-ID: As far as I know, all of JavaFX is open source indeed. If someone wants to make a big change, e.g. create another rendering pipeline, it is very well possible to do so. I would recommend submitting that work back to OpenJFX, by following the same procedures for committing to the OpenJDK project, but if you want to keep that as a private extension, I don't think there is a problem with that. But in general, if you see a performance issue and you have an idea about how to fix it, I don't think anyone (in or outside Oracle) will stop you from doing this. Clearly, there have to be some procedures for submitting patches, so the Oracle engineers won't accept every patch blindly. But as I mentioned a number of times, not only Oracle but also other companies and individuals can drive JavaFX forward. Personally, I like this combination, and I welcome more committers (from Oracle and from third parties). - Johan On Tue, Dec 1, 2015 at 2:03 PM, Felix Bembrick wrote: > Is it really true that *all* of JavaFX is open source? > > Even if it is, if I wanted to say take some aspects of the product in a > radical new direction, wouldn't someone from Oracle have to approve the > changes? > > If yes, then only Oracle can bring the big enhancements that are necessary > which we know will never happen. > > As I said, the biggest impediment to the growth in features, performance > and adoption of JavaFX is Oracle themselves. > > > On 1 Dec 2015, at 20:45, Peter Pilgrim wrote: > > > > Hi All > > > > I find it remarkable to see that this debate about > > innovation-versus-maintenance is similar to the one going on in the > > Java EE space. See > > > https://java.net/projects/javaee-spec/lists/users/archive/2015-01/message/48 > > - Many Java EE experts, including myself, are now looking at the > > application servers and the ability to modularise the EE > > specification, so that we can just launch an application with `java > > -jar acme.jar'. Of course, we are already wrong about that command > > line option, because the JDK 9 will be a game changer. > > > > Anyway, Shai, has some valid interesting assertions in his blog entry. > > I don't think it is all FUD in the way that Microsoft used to secretly > > push in their strategic vision to conquer the desktop world. I do > > believe that his evidence shows how weak OTHER developers view Java > > client side technologies. JavaFX has not set the world on fire and has > > been the vision that I saw at the first presentation in JavaOne 2007. > > > > But that was yesterday, 8 years ago in fact. I lot of mistakes were > > made, and the vision could have better. We all had to follow the > > education and the learning path. Hindsight is a beautiful thing, a lot > > of us though scripting languages were exciting back then. We should > > have started with an all Java API solution in the first place, but > > there you go... > > > > Donald said the JavaFX is 100% open source, so what is the real > > issue. We have the code, go and build. > > > > Alexander, I downloaded your JavaOne presentation, I went through it > > last night. It is good stuff with all of those 11 business enterprise > > applications. Why are these applications not good enough to show > > adoption? > > > > Last year, 2014, I watch a JavaFX talk at JavaOne on a financial > > trading system written in JavaFX (CelerFX or something). What gives > > here? > > > > I am definitely a Java EE guy these days ever since I wrote two books, > > but you fellows need to step up, I think, promote FX more strongly > > yourselves. I know that Nandini (who is now at Twitter) pushed a FX > > show case a couple times in the past, first for JavaFX 1.0 and then > > 1.2. Jim did with blog and is still going at Pivotal. Guys you need to > > do more videos, screen captures and more talks. If the popular Java > > conferences don't take you on, then f*** e* and host your own video > > shows like Adam Bien. Build some excitement about what your have done > > with FX in your applications. Grow some con****** and come down with > > the attitude. > > > > The good news is that JDK 9 will bring a better deployment story for > > Java on the whole. You can have launchers and modules that only your > > application require. Perhaps, were the value is. > > > > > >> On 1 December 2015 at 08:21, Felix Bembrick > wrote: > >> Well, it is the official Swing replacement but look at Java 9 and you > won't see many if any enhancements to JavaFX. The point is Oracle has no > interest in desktop software other than maintaining any existing support > contracts. > >> > >> I don't even think Oracle wants JavaFX so it would be better for > everyone to take ownership of it and build a company purely around JavaFX > that's actually profitable and keeps enhancing the product at a much faster > pace. > >> > >>> On 1 Dec 2015, at 19:12, info at cuhka.com wrote: > >>> > >>> If it is not a part of OpenJDK/Oracle JDK it will not work. Whether > Oracle itself maintains the code doesn't really matter I think, but they > have to put support and development in it. > >>> > >>> To me another downside if Oracle would suspend further development is > that any statements made by Oracle seem to carry not so much value. If I'm > correct JavaFX was presented by Oracle as the Swing replacement. If after a > short time they revert from that position, what would that mean for any > other statement? > >>> > >>> > >>> Citeren Felix Bembrick : > >>> > >>>> If JavaFX stays under Oracle control, it will be the same it is today > in 5 years. I really doubt they will put another dollar into its expansion > and new features. > >>>> > >>>> How can that be good? > >>>> > >>>> Plus the company that does take over could provide commercial support > as well as training (which Oracle doesn't). > > > > > > > > -- > > Best wishes > > > > Peter Pilgrim, > > Java Champion / Director P.E.A.T. LTD > > > > ++++ Scala and Java EE Software Development / Design / Architect > > for `BlueChip' enterprises, London, UK ++++ > > > > I am currently writing ``Digital Java EE 7 Development'' Packt Pub > > (September 2015) > > > > ++++ Digital ++ Finance ++ Adaptation ++ Transformation ++ Software ++++ > > > > :: http://www.xenonique.co.uk/blog/ :: > > :: http://twitter.com/peter_pilgrim :: > > :: http://java-champions.java.net/ :: > From felix.bembrick at gmail.com Tue Dec 1 13:35:33 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Wed, 2 Dec 2015 00:35:33 +1100 Subject: Future of JavaFX In-Reply-To: References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> Message-ID: <94CBB59D-F7B3-4D5E-BD70-C84FF8610D6E@gmail.com> I agree with Johan that there is a rich and vibrant JavaFX community and most examples of its adoption are behind corporate firewalls. But Johan, why would Oracle build a "JavaFX ecosystem" within Oracle and spend millions on a product that earns them nothing? Surely that is not sustainable. And where are all the big changes and enhancements in JFX 9? > On 2 Dec 2015, at 00:27, Johan Vos wrote: > > Hi Dirk, all, > > Although this person from Codename One attacked me a few times before > (using words like we're selling snake oil), I tried to ignore it. This is > very uncommon for the Java community. In the Java community, we have > different views, we prefer different technologies, but we show at least > some basic respect to other views and we don't insult people. Clearly, this > isn't the policy inside Codename One. I wonder where they get the time for > writing negative things about others, rather than writing positive things > about their own technologies. So although I'm offended, I try to write code > and keep my customers happy rather than fighting. > > But the moment you may lose customers because what others write about a > technology you want to use, a line is crossed. I keep all options open on > how to respond, but here are already some thoughts: > > * The JavaFX engineers at Oracle (current and past) are doing a fantastic > job. > > * Yes, I wish Oracle would spend more resources on JavaFX (and on Java in > general). > > * JavaFX is growing. Gluon is growing. > > * There are many JavaFX success stories, but unfortunately many of those > are hidden behind company walls. At Gluon, we have great customers with a > huge investment in JavaFX that make amazing products. But company policies > often prohibit us from even mentioning those on our website. This is an > issue, as I believe many people would be surprised to see who is using > JavaFX and at what size. I'm not sure how to address this, and it is > something Peter Pilgrim talked about in a follow-up post as well. > > * JavaFX on Mobile is getting there. Don't believe self-declared and > aggressive "mobile experts" with a different agenda. I'm one of those > people working day and night to make this happen. And apart from very few > exceptions, the Java community has been very supportive to this effort. I > don't let those exceptions ruining my day or my customers. > > * There really is a JavaFX eco-system. Oracle is spending resources on it, > and there are a large number of individuals and companies providing free > and commercial frameworks, services, trainings, books. > > * JavaFX is open source with a business-friendly license. You don't like > something? Fix it. > > Dirk, keep up the good work. I hope your customer realises that there is a > large community behind JavaFX, with both open-source and commercial > offerings. They should feel safe using JavaFX. > > - Johan > > > On Mon, Nov 30, 2015 at 5:13 PM, Dirk @ Google > wrote: > >> Hi there, >> >> there has been quite a shake-up in the JavaFX community last week when >> Shay Almog (Codename One) first responded to a blog of mine ( >> dlemmermann.wordpress.com) with a lot of negative comments regarding >> JavaFX and its future. He then followed up with a long blog asking the >> question ?Should Oracle Spring-Clean JavaFX? ( >> https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html < >> https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html>). >> >> I do understand that it is often a good strategy to not comment on stuff >> like this because commenting would just draw attention to it, but we have >> now reached the point where potential customers are questioning the >> sustainability of a JavaFX-based solution. They are now wondering if JavaFX >> will still be around in a few years. In my specific case the customer >> demands an answer from me and my partners within the next week, and if not >> convincing they will go with something / someone else. We will loose a >> contract worth around one million dollars because of one blog written by >> Shay with no follow-up from Oracle. >> >> What is needed is an official statement from Oracle / Oracle employees / >> JavaFX development team, saying that Oracle is still committed to JavaFX >> and that it will still be around for a while. Can somebody please do that? >> >> Dirk >> >> >> From dalibor.topic at oracle.com Tue Dec 1 13:50:13 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 1 Dec 2015 14:50:13 +0100 Subject: Future of JavaFX In-Reply-To: References: <6C6CE4A9B94582468498929459CEEF711011D22B@vmex1.saxsys.de> <6262471A-7A57-450B-80B0-F5FD275DC55E@gmail.com> <20151201031248.Horde.JsY0KA6lAh-OFxB_pOU8M62@dime187.dizinc.com> <77B92266-D7DA-4D00-A523-3E3F65DF464D@gmail.com> Message-ID: <565DA595.3050307@oracle.com> On 01.12.2015 14:22, Mario Torre wrote: > Btw, as a general note, I always find discussing about how impossible > any contribution is *without* first trying to contribute anything a > real waste of time. For mailing list environments with a bad signal/noise ratio, I suggest applying https://joeyh.name/blog/entry/thread_patterns/ when reading e-mail. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From kevin.rushforth at oracle.com Tue Dec 1 17:00:40 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 01 Dec 2015 09:00:40 -0800 Subject: gradle 2.9 is now the default in FX 9-dev Message-ID: <565DD238.9080008@oracle.com> The switch to gradle 2.9 has been pushed to 9-dev as indicated in [1]. Anyone who has not yet updated to gradle 2.9 should do so within the next two weeks. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-November/018210.html From peter.pilgrim at gmail.com Tue Dec 1 17:12:45 2015 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Tue, 1 Dec 2015 17:12:45 +0000 Subject: Future of JavaFX In-Reply-To: References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> Message-ID: Hi All On 1 December 2015 at 13:27, Johan Vos wrote: > Hi Dirk, all, > > Although this person from Codename One attacked me a few times before > (using words like we're selling snake oil), I tried to ignore it. This is > very uncommon for the Java community. In the Java community, we have > different views, we prefer different technologies, but we show at least > some basic respect to other views and we don't insult people. Clearly, this > isn't the policy inside Codename One. I wonder where they get the time for > writing negative things about others, rather than writing positive things > about their own technologies. So although I'm offended, I try to write code > and keep my customers happy rather than fighting. > I saw this appalling behaviour on the aforementioned blog site. Shai was hardly diplomatic, especially for an ex-Sun / Oracle wasn't he? I have heard on that Japanese anecdote BEATING THE GRASS in order to force the snakes to come out, but I wonder who is the enemy here. > But the moment you may lose customers because what others write about a > technology you want to use, a line is crossed. I keep all options open on > how to respond, but here are already some thoughts: It's a bad as somebody hating Spring Framework, however I think I will let that rest again, because I already posted a response for that. > > * The JavaFX engineers at Oracle (current and past) are doing a fantastic > job. Yes. It also included Brian Goetz and others people who were on the same mailing list circa 2008 and 2009 with JavaFX Script. > > * Yes, I wish Oracle would spend more resources on JavaFX (and on Java in > general). > > * JavaFX is growing. Gluon is growing. > And many executives can understand that Swing is no longer supported and there is a technology risk in terms of RECRUITMENT, TRAINING, MAINTAINABILITY and ROBUSTNESS if they continue to use it. There are financial services houses such Murex who are Swing based still and sell solutions to investment banks. These rich GUI solutions inside the big banks are very unlikely to go HTML5 and web based soon, so the lead developers in those businesses probably have evaluated JavaFX. So I asked Shai what needs to happens in order to cross the divide? For all you involved in FX, and now that Oracle evangelism, advocacy, whatever, has all but disappeared, need to come out three (3) requirements that get the product over the line. > * There are many JavaFX success stories, but unfortunately many of those > are hidden behind company walls. At Gluon, we have great customers with a > huge investment in JavaFX that make amazing products. But company policies > often prohibit us from even mentioning those on our website. This is an > issue, as I believe many people would be surprised to see who is using > JavaFX and at what size. I'm not sure how to address this, and it is > something Peter Pilgrim talked about in a follow-up post as well. > If these products can be exposed in some meaningful way then that would really help. Companies are willing to show these Responsive Web Design, Adaptive Web Design, HTML5 and latest browser support, and yet this must be achieve with JavaFX. Clearly what is needed is a poster child. Some JavaFX application that looks simple, does great thing, and work amazing well across all devices. I wish I knew what that would be. > * JavaFX on Mobile is getting there. Don't believe self-declared and > aggressive "mobile experts" with a different agenda. I'm one of those > people working day and night to make this happen. And apart from very few > exceptions, the Java community has been very supportive to this effort. I > don't let those exceptions ruining my day or my customers. > Nor should you or anyone else feel deflated. Shai is frustrated, obviously, with the mobile story so far. He feels that the scene graph solution is overkill for the current generation of smartphone and mobile devices. He reckons the scene graph abilities are hard to reach under GPU and the native operating system for the mobile devices. I don't necessarily agree with him, the scene graph was what sold me on Chris Oliver's original vision on (F3 (form follows function) precursor to JavaFX 1.0 (Script)). I think that mobile devices will gain scene graph and better GPU/CPU very soon. Johan has taken the mobile solution further with Gluon. At least there are working JavaFX applications in the app stores. This is better than 2011 when we were dreaming off the ability to achieve this. What is missing on mobile front? Common API for magnetrometry, gyroscope, media, camera support and of course high performance graphics? > * There really is a JavaFX eco-system. Oracle is spending resources on it, > and there are a large number of individuals and companies providing free > and commercial frameworks, services, trainings, books. > > * JavaFX is open source with a business-friendly license. You don't like > something? Fix it. > > Dirk, keep up the good work. I hope your customer realises that there is a > large community behind JavaFX, with both open-source and commercial > offerings. They should feel safe using JavaFX. And also now is the time to request changes for JDK 9 whilst it is still in early access. From the presentations at JavaOne, there will be only one FX module in the JDK. (There was this thing to do with DLL or shared runtimes when I was hanging around regularly in 2012 ) If you don't agree with it, or want to modularise FX in the JDK even more, then now is the time to act and let Mark Reinhold, Alex Buckley and Alan Bateman know asap. > > - Johan > > > On Mon, Nov 30, 2015 at 5:13 PM, Dirk @ Google > wrote: > >> Hi there, >> >> there has been quite a shake-up in the JavaFX community last week when >> Shay Almog (Codename One) first responded to a blog of mine ( >> dlemmermann.wordpress.com) with a lot of negative comments regarding >> JavaFX and its future. He then followed up with a long blog asking the >> question ?Should Oracle Spring-Clean JavaFX? ( >> https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html < >> https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html>). >> >> I do understand that it is often a good strategy to not comment on stuff >> like this because commenting would just draw attention to it, but we have >> now reached the point where potential customers are questioning the >> sustainability of a JavaFX-based solution. They are now wondering if JavaFX >> will still be around in a few years. In my specific case the customer >> demands an answer from me and my partners within the next week, and if not >> convincing they will go with something / someone else. We will loose a >> contract worth around one million dollars because of one blog written by >> Shay with no follow-up from Oracle. >> >> What is needed is an official statement from Oracle / Oracle employees / >> JavaFX development team, saying that Oracle is still committed to JavaFX >> and that it will still be around for a while. Can somebody please do that? >> >> Dirk >> >> >> -- Best wishes Peter Pilgrim, Java Champion / Director P.E.A.T. LTD ++++ Scala and Java EE Software Development / Design / Architect for `BlueChip' enterprises, London, UK ++++ I am currently writing ``Digital Java EE 7 Development'' Packt Pub (September 2015) ++++ Digital ++ Finance ++ Adaptation ++ Transformation ++ Software ++++ :: http://www.xenonique.co.uk/blog/ :: :: http://twitter.com/peter_pilgrim :: :: http://java-champions.java.net/ :: From peter.pilgrim at gmail.com Tue Dec 1 17:16:58 2015 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Tue, 1 Dec 2015 17:16:58 +0000 Subject: Future of JavaFX In-Reply-To: References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> Message-ID: How timely as I just posted that response and Dalibor's news just arrived in the my inbox within 1 minute ... #TLDR JDK 9 will arrive 6 months later than expected 23rd March 2017 ... so FX people go to work, really go work. On 1 December 2015 at 17:12, Peter Pilgrim wrote: > Hi All > > On 1 December 2015 at 13:27, Johan Vos wrote: >> Hi Dirk, all, >> >> Although this person from Codename One attacked me a few times before >> (using words like we're selling snake oil), I tried to ignore it. This is >> very uncommon for the Java community. In the Java community, we have >> different views, we prefer different technologies, but we show at least >> some basic respect to other views and we don't insult people. Clearly, this >> isn't the policy inside Codename One. I wonder where they get the time for >> writing negative things about others, rather than writing positive things >> about their own technologies. So although I'm offended, I try to write code >> and keep my customers happy rather than fighting. >> > > I saw this appalling behaviour on the aforementioned blog site. Shai > was hardly diplomatic, especially for an ex-Sun / Oracle wasn't he? > I have heard on that Japanese anecdote BEATING THE GRASS in order to > force the snakes to come out, but I wonder who is the enemy here. > >> But the moment you may lose customers because what others write about a >> technology you want to use, a line is crossed. I keep all options open on >> how to respond, but here are already some thoughts: > > It's a bad as somebody hating Spring Framework, however I think I will > let that rest again, because I already posted a response for that. >> >> * The JavaFX engineers at Oracle (current and past) are doing a fantastic >> job. > > Yes. It also included Brian Goetz and others people who were on the > same mailing list circa 2008 and 2009 with JavaFX Script. > >> >> * Yes, I wish Oracle would spend more resources on JavaFX (and on Java in >> general). >> >> * JavaFX is growing. Gluon is growing. >> > > And many executives can understand that Swing is no longer supported > and there is a technology risk in terms of RECRUITMENT, TRAINING, > MAINTAINABILITY and ROBUSTNESS if they continue to use it. There are > financial services houses such Murex who are Swing based still and > sell solutions to investment banks. These rich GUI solutions inside > the big banks are very unlikely to go HTML5 and web based soon, so the > lead developers in those businesses probably have evaluated JavaFX. > > So I asked Shai what needs to happens in order to cross the divide? > For all you involved in FX, and now that Oracle evangelism, advocacy, > whatever, has all but disappeared, need to come out three (3) > requirements that get the product over the line. > > >> * There are many JavaFX success stories, but unfortunately many of those >> are hidden behind company walls. At Gluon, we have great customers with a >> huge investment in JavaFX that make amazing products. But company policies >> often prohibit us from even mentioning those on our website. This is an >> issue, as I believe many people would be surprised to see who is using >> JavaFX and at what size. I'm not sure how to address this, and it is >> something Peter Pilgrim talked about in a follow-up post as well. >> > > If these products can be exposed in some meaningful way then that > would really help. > > Companies are willing to show these Responsive Web Design, Adaptive > Web Design, HTML5 and latest browser support, and yet this must be > achieve with JavaFX. > > Clearly what is needed is a poster child. Some JavaFX application that > looks simple, does great thing, and work amazing well across all > devices. I wish I knew what that would be. > > >> * JavaFX on Mobile is getting there. Don't believe self-declared and >> aggressive "mobile experts" with a different agenda. I'm one of those >> people working day and night to make this happen. And apart from very few >> exceptions, the Java community has been very supportive to this effort. I >> don't let those exceptions ruining my day or my customers. >> > > Nor should you or anyone else feel deflated. > > Shai is frustrated, obviously, with the mobile story so far. He feels > that the scene graph solution is overkill for the current generation > of smartphone and mobile devices. He reckons the scene graph abilities > are hard to reach under GPU and the native operating system for the > mobile devices. I don't necessarily agree with him, the scene graph > was what sold me on Chris Oliver's original vision on (F3 (form > follows function) precursor to JavaFX 1.0 (Script)). I think that > mobile devices will gain scene graph and better GPU/CPU very soon. > > Johan has taken the mobile solution further with Gluon. At least there > are working JavaFX applications in the app stores. This is better than > 2011 when we were dreaming off the ability to achieve this. > > What is missing on mobile front? Common API for magnetrometry, > gyroscope, media, camera support and of course high performance > graphics? > > >> * There really is a JavaFX eco-system. Oracle is spending resources on it, >> and there are a large number of individuals and companies providing free >> and commercial frameworks, services, trainings, books. >> >> * JavaFX is open source with a business-friendly license. You don't like >> something? Fix it. >> >> Dirk, keep up the good work. I hope your customer realises that there is a >> large community behind JavaFX, with both open-source and commercial >> offerings. They should feel safe using JavaFX. > > > And also now is the time to request changes for JDK 9 whilst it is > still in early access. From the presentations at JavaOne, there will > be only one FX module in the JDK. (There was this thing to do with > DLL or shared runtimes when I was hanging around regularly in 2012 ) > If you don't agree with it, or want to modularise FX in the JDK even > more, then now is the time to act and let Mark Reinhold, Alex Buckley > and Alan Bateman know asap. > >> >> - Johan >> >> >> On Mon, Nov 30, 2015 at 5:13 PM, Dirk @ Google >> wrote: >> >>> Hi there, >>> >>> there has been quite a shake-up in the JavaFX community last week when >>> Shay Almog (Codename One) first responded to a blog of mine ( >>> dlemmermann.wordpress.com) with a lot of negative comments regarding >>> JavaFX and its future. He then followed up with a long blog asking the >>> question ?Should Oracle Spring-Clean JavaFX? ( >>> https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html < >>> https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html>). >>> >>> I do understand that it is often a good strategy to not comment on stuff >>> like this because commenting would just draw attention to it, but we have >>> now reached the point where potential customers are questioning the >>> sustainability of a JavaFX-based solution. They are now wondering if JavaFX >>> will still be around in a few years. In my specific case the customer >>> demands an answer from me and my partners within the next week, and if not >>> convincing they will go with something / someone else. We will loose a >>> contract worth around one million dollars because of one blog written by >>> Shay with no follow-up from Oracle. >>> >>> What is needed is an official statement from Oracle / Oracle employees / >>> JavaFX development team, saying that Oracle is still committed to JavaFX >>> and that it will still be around for a while. Can somebody please do that? >>> >>> Dirk >>> >>> >>> > > > > -- > Best wishes > > Peter Pilgrim, > Java Champion / Director P.E.A.T. LTD > > ++++ Scala and Java EE Software Development / Design / Architect > for `BlueChip' enterprises, London, UK ++++ > > I am currently writing ``Digital Java EE 7 Development'' Packt Pub > (September 2015) > > ++++ Digital ++ Finance ++ Adaptation ++ Transformation ++ Software ++++ > > :: http://www.xenonique.co.uk/blog/ :: > :: http://twitter.com/peter_pilgrim :: > :: http://java-champions.java.net/ :: -- Best wishes Peter Pilgrim, Java Champion / Director P.E.A.T. LTD ++++ Scala and Java EE Software Development / Design / Architect for `BlueChip' enterprises, London, UK ++++ I am currently writing ``Digital Java EE 7 Development'' Packt Pub (September 2015) ++++ Digital ++ Finance ++ Adaptation ++ Transformation ++ Software ++++ :: http://www.xenonique.co.uk/blog/ :: :: http://twitter.com/peter_pilgrim :: :: http://java-champions.java.net/ :: From markus at headcrashing.eu Tue Dec 1 17:31:43 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 1 Dec 2015 18:31:43 +0100 Subject: Future of JavaFX In-Reply-To: References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <3555650.UByc31Jqhd@andor> Message-ID: <002401d12c5e$25609690$7021c3b0$@eu> I assume you already opened a JIRA ticket and filed a reproducible test case, so Oracle can fix the issue ASAP? ;-) -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel. Sent: Montag, 30. November 2015 22:49 To: Florian Brunner Cc: openjfx-dev at openjdk.java.net Subject: Re: Future of JavaFX The company where I work is using and developing with JavaFX. We're not in production yet but have already some testing embedded systems with it running on a [possible]customer site. The main drawback is not having the same performance running from X than running directly from framebuffer. By not using X we have a other big drawback too that is not having x11vnc working, so every developer need to have a monitor with HDMI attached to our device. I have a task to "look for possible solutions" but I haven't found time to attend it yet. Regards, - dhs 2015-11-30 18:35 GMT-02:00 Florian Brunner : > I read this article as well some days ago. It has some very valid points, but > all in all I think JavaFX is still the best option out there. > > That said I was quite surprised that I got confronted today with the very same > article by colleagues of mine who are in charge with company-wide adoption of > various technologies. They tend to agree with the article. Currently JavaFX is > still just on our technology radar, but not promoted yet. And now they start > thinking JavFX (and probably thus Java on desktop not even speaking about > mobile platforms) won't make it and it's getting hard to convince them that > JavaFX is actually a great option. > > Now reading this mail of yours, this article really seems to make waves. > > -Florian > > > Am Montag, 30. November 2015, 17.13:10 schrieb Dirk @ Google: >> Hi there, >> >> there has been quite a shake-up in the JavaFX community last week when Shay >> Almog (Codename One) first responded to a blog of mine >> (dlemmermann.wordpress.com) with a lot of negative comments regarding >> JavaFX and its future. He then followed up with a long blog asking the >> question ?Should Oracle Spring-Clean JavaFX? >> (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html >> ). >> >> I do understand that it is often a good strategy to not comment on stuff >> like this because commenting would just draw attention to it, but we have >> now reached the point where potential customers are questioning the >> sustainability of a JavaFX-based solution. They are now wondering if JavaFX >> will still be around in a few years. In my specific case the customer >> demands an answer from me and my partners within the next week, and if not >> convincing they will go with something / someone else. We will loose a >> contract worth around one million dollars because of one blog written by >> Shay with no follow-up from Oracle. >> >> What is needed is an official statement from Oracle / Oracle employees / >> JavaFX development team, saying that Oracle is still committed to JavaFX >> and that it will still be around for a while. Can somebody please do that? >> >> Dirk > -- "Do or do not. There is no try" Yoda Master From markus at headcrashing.eu Tue Dec 1 17:34:32 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 1 Dec 2015 18:34:32 +0100 Subject: Future of JavaFX In-Reply-To: <565CC521.9030905@tbee.org> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <3555650.UByc31Jqhd@andor> <565CC521.9030905@tbee.org> Message-ID: <002701d12c5e$8a61fac0$9f25f040$@eu> Speaking of promotion an VW, does it make the Golf an outdated car just because they stopped TV marketing in Germany because their sales is running quite well still? ;-) -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Eugelink Sent: Montag, 30. November 2015 22:53 To: openjfx-dev at openjdk.java.net Subject: Re: Future of JavaFX There indeed seems to be negative buzz around JavaFX, and Oracle stopping with promoting it, is indeed confusing, at the very least. And it is noticeable everywhere; without wanting to wine, I really do have a nice JavaFX / JFXtras presentation, but it being declined on all conferences for me is a signal about the interest of the community in JavaFX. And let's be honest, Oracle's whole "let's do cloud and forget there are companies doing this many many years already" U turn is not contributing to the mood as well. OTOH, from what I hear VW has chosen to use JavaFX for it's in car systems. And I have just been on an interview for a traffic management system where they chose JavaFX over web based. So there also is adoption. But it will be slow. My gut says: give it time, and a bit of TLC promotionwise would not be bad. Tom On 30-11-2015 21:35, Florian Brunner wrote: > I read this article as well some days ago. It has some very valid points, but > all in all I think JavaFX is still the best option out there. > > That said I was quite surprised that I got confronted today with the very same > article by colleagues of mine who are in charge with company-wide adoption of > various technologies. They tend to agree with the article. Currently JavaFX is > still just on our technology radar, but not promoted yet. And now they start > thinking JavFX (and probably thus Java on desktop not even speaking about > mobile platforms) won't make it and it's getting hard to convince them that > JavaFX is actually a great option. > > Now reading this mail of yours, this article really seems to make waves. > > -Florian > > > Am Montag, 30. November 2015, 17.13:10 schrieb Dirk @ Google: >> Hi there, >> >> there has been quite a shake-up in the JavaFX community last week when Shay >> Almog (Codename One) first responded to a blog of mine >> (dlemmermann.wordpress.com) with a lot of negative comments regarding >> JavaFX and its future. He then followed up with a long blog asking the >> question ?Should Oracle Spring-Clean JavaFX? >> (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html >> ). >> >> I do understand that it is often a good strategy to not comment on stuff >> like this because commenting would just draw attention to it, but we have >> now reached the point where potential customers are questioning the >> sustainability of a JavaFX-based solution. They are now wondering if JavaFX >> will still be around in a few years. In my specific case the customer >> demands an answer from me and my partners within the next week, and if not >> convincing they will go with something / someone else. We will loose a >> contract worth around one million dollars because of one blog written by >> Shay with no follow-up from Oracle. >> >> What is needed is an official statement from Oracle / Oracle employees / >> JavaFX development team, saying that Oracle is still committed to JavaFX >> and that it will still be around for a while. Can somebody please do that? >> >> Dirk From markus at headcrashing.eu Tue Dec 1 17:35:57 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 1 Dec 2015 18:35:57 +0100 Subject: Future of JavaFX In-Reply-To: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> References: Future of JavaFX <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> Message-ID: <002a01d12c5e$bd44dd90$37ce98b0$@eu> With respect to TeamFX, the better question is: Are there plans to further open the project so third party has an easier channel to contribute without the hazzle of contributor agreements, JIRA accounts, and so on? -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Casall, Alexander Sent: Montag, 30. November 2015 23:55 To: Donald Smith; openjfx-dev at openjdk.java.net Mailing Subject: Re: Future of JavaFX Don, thanks for your important contribution to this thread. What exactly means oracle continues to develop on fx? What is the roadmap? If I check the mercurial archives there are 10-12 people working constantly on FX in this year. The most work was done by a few of them. I'm not sure whether this is enought to move FX forward to engage more and more adopters. The core question is, are there any plans to put more ressources on fx? - Alex From: Donald Smith Sent: 30.11.15, 17:35 To: openjfx-dev at openjdk.java.net Mailing Subject: Re: Future of JavaFX Oracle is still committed to JavaFX and it will still be around for a while. As of 7u6 we bundled JavaFX with the Oracle JDK, we've open sourced 100% of the code, we continue developing for it, etc. I understand that while there is both Swing and JavaFX available that people will continue to question the existence of each -- so be it. Each has it's own niches and benefits and our strategy, as it has been for years now, is to continue with each. - Don On 30/11/2015 11:13 AM, Dirk @ Google wrote: > Hi there, > > there has been quite a shake-up in the JavaFX community last week when Shay Almog (Codename One) first responded to a blog of mine (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html>). > > I do understand that it is often a good strategy to not comment on stuff like this because commenting would just draw attention to it, but we have now reached the point where potential customers are questioning the sustainability of a JavaFX-based solution. They are now wondering if JavaFX will still be around in a few years. In my specific case the customer demands an answer from me and my partners within the next week, and if not convincing they will go with something / someone else. We will loose a contract worth around one million dollars because of one blog written by Shay with no follow-up from Oracle. > > What is needed is an official statement from Oracle / Oracle employees / JavaFX development team, saying that Oracle is still committed to JavaFX and that it will still be around for a while. Can somebody please do that? > > Dirk > > From dalibor.topic at oracle.com Tue Dec 1 18:05:40 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 1 Dec 2015 19:05:40 +0100 Subject: Future of JavaFX In-Reply-To: <002a01d12c5e$bd44dd90$37ce98b0$@eu> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> Message-ID: <565DE174.7020604@oracle.com> On 01.12.2015 18:35, Markus KARG wrote: > With respect to TeamFX, the better question is: Are there plans to further > open the project so third party has an easier channel to contribute without > the hazzle of contributor agreements "Like many other open-source communities, the OpenJDK Community requires Contributors to jointly assign their copyright on contributed code." as http://openjdk.java.net/contribute/ wisely says. There is no good reason to change that. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From markus at headcrashing.eu Tue Dec 1 19:13:25 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 1 Dec 2015 20:13:25 +0100 Subject: Future of JavaFX In-Reply-To: <565DE174.7020604@oracle.com> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> Message-ID: <006901d12c6c$5aa88a20$0ff99e60$@eu> I wonder why I was able to jointly assign my copyright with a lot of other open source projects without having to sign papers, sent them in by fax, wait for a written agreement, and pray to get a JIRA account... ;-) See, I talked to a real lot of former JavaFX contributors in the past weeks (visited some European JUGs in 2015), and *virtually everybody* told me that he is really unsatisfied with the fact that he cannot directly file to JIRA anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX team clear about how many contributors you lost by that policy? I really wonder whether you see the reality there outside of Oracle. People stopped reporting bugs! This is a real problem for JavaFX. You should act. Now. -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of dalibor topic Sent: Dienstag, 1. Dezember 2015 19:06 To: openjfx-dev at openjdk.java.net Subject: Re: Future of JavaFX On 01.12.2015 18:35, Markus KARG wrote: > With respect to TeamFX, the better question is: Are there plans to further > open the project so third party has an easier channel to contribute without > the hazzle of contributor agreements "Like many other open-source communities, the OpenJDK Community requires Contributors to jointly assign their copyright on contributed code." as http://openjdk.java.net/contribute/ wisely says. There is no good reason to change that. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From herve.girod at gmail.com Tue Dec 1 19:18:45 2015 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Tue, 1 Dec 2015 20:18:45 +0100 Subject: Future of JavaFX In-Reply-To: <006901d12c6c$5aa88a20$0ff99e60$@eu> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> Message-ID: <676EAF84-EB02-4BA1-9356-D478FD5993CA@gmail.com> Things are not different for Apache projects. Google does not accept any external contributions. The Linux kernel development is very tightly controlled. We should stop considering that widespread open source policies are only a problem with JavaFX. These policies are in place for a reason. Herv? Sent from my iPhone > On Dec 1, 2015, at 20:13, Markus KARG wrote: > > I wonder why I was able to jointly assign my copyright with a lot of other > open source projects without having to sign papers, sent them in by fax, > wait for a written agreement, and pray to get a JIRA account... ;-) > > See, I talked to a real lot of former JavaFX contributors in the past weeks > (visited some European JUGs in 2015), and *virtually everybody* told me that > he is really unsatisfied with the fact that he cannot directly file to JIRA > anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX team > clear about how many contributors you lost by that policy? I really wonder > whether you see the reality there outside of Oracle. People stopped > reporting bugs! This is a real problem for JavaFX. You should act. Now. > > -Markus > > > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of > dalibor topic > Sent: Dienstag, 1. Dezember 2015 19:06 > To: openjfx-dev at openjdk.java.net > Subject: Re: Future of JavaFX > >> On 01.12.2015 18:35, Markus KARG wrote: >> With respect to TeamFX, the better question is: Are there plans to further >> open the project so third party has an easier channel to contribute > without >> the hazzle of contributor agreements > > "Like many other open-source communities, the OpenJDK Community requires > Contributors to jointly assign their copyright on contributed code." as > http://openjdk.java.net/contribute/ wisely says. > > There is no good reason to change that. > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From dalibor.topic at oracle.com Tue Dec 1 19:38:06 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 1 Dec 2015 20:38:06 +0100 Subject: Future of JavaFX In-Reply-To: <006901d12c6c$5aa88a20$0ff99e60$@eu> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> Message-ID: <565DF71E.107@oracle.com> On 01.12.2015 20:13, Markus KARG wrote: > anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX team > clear about how many contributors you lost by that policy? I think the number you're looking for is zero, judging by the number of 'Contributed-by' changesets in the rt repository in the last 12 months.[0] In fact, the number of such changesets has increased significantly after the migration to JIRA back in June. Looks like the objective reality is quite different from subjective perception. ;) cheers, dalibor topic [0] http://hg.openjdk.java.net/openjfx/9-dev/rt/search/?rev=contributed-by&revcount=40 -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From tomas.mikula at gmail.com Tue Dec 1 20:36:49 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Tue, 1 Dec 2015 15:36:49 -0500 Subject: Future of JavaFX In-Reply-To: <676EAF84-EB02-4BA1-9356-D478FD5993CA@gmail.com> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <676EAF84-EB02-4BA1-9356-D478FD5993CA@gmail.com> Message-ID: The fact that there are other projects with equally bad or worse contribution process does not make the JavaFX's any less bad. Yes, there should be (strict) policies regarding code quality. The rest of the process should be as easy as opening a pull request. Tomas On Tue, Dec 1, 2015 at 2:18 PM, Herv? Girod wrote: > Things are not different for Apache projects. Google does not accept any > external contributions. The Linux kernel development is very tightly > controlled. We should stop considering that widespread open source policies > are only a problem with JavaFX. These policies are in place for a reason. > > Herv? > > Sent from my iPhone > > > On Dec 1, 2015, at 20:13, Markus KARG wrote: > > > > I wonder why I was able to jointly assign my copyright with a lot of > other > > open source projects without having to sign papers, sent them in by fax, > > wait for a written agreement, and pray to get a JIRA account... ;-) > > > > See, I talked to a real lot of former JavaFX contributors in the past > weeks > > (visited some European JUGs in 2015), and *virtually everybody* told me > that > > he is really unsatisfied with the fact that he cannot directly file to > JIRA > > anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX > team > > clear about how many contributors you lost by that policy? I really > wonder > > whether you see the reality there outside of Oracle. People stopped > > reporting bugs! This is a real problem for JavaFX. You should act. Now. > > > > -Markus > > > > > > > > -----Original Message----- > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On > Behalf Of > > dalibor topic > > Sent: Dienstag, 1. Dezember 2015 19:06 > > To: openjfx-dev at openjdk.java.net > > Subject: Re: Future of JavaFX > > > >> On 01.12.2015 18:35, Markus KARG wrote: > >> With respect to TeamFX, the better question is: Are there plans to > further > >> open the project so third party has an easier channel to contribute > > without > >> the hazzle of contributor agreements > > > > "Like many other open-source communities, the OpenJDK Community requires > > Contributors to jointly assign their copyright on contributed code." as > > http://openjdk.java.net/contribute/ wisely says. > > > > There is no good reason to change that. > > > > cheers, > > dalibor topic > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment > > > From markus at headcrashing.eu Tue Dec 1 21:41:07 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 1 Dec 2015 22:41:07 +0100 Subject: Future of JavaFX In-Reply-To: <676EAF84-EB02-4BA1-9356-D478FD5993CA@gmail.com> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <676EAF84-EB02-4BA1-9356-D478FD5993CA@gmail.com> Message-ID: <000b01d12c80$fcfe1100$f6fa3300$@eu> We should ask ourselfs whether we want more contributions or not. We will not get them until we change something. Most contributors in the Open Source just want to drop a bug report or a feature or two, and multiplied by the number of those guys, this is a lot of stuff. Only few contributors are willing to stay for long time, and only for those it makes sense to have the complex rules. For example, I do not see why we cannot have a dedicated full time "Community Officer" who simply collects the contributions, reviews it, applies the needed checks and rules and all that instead of asking everybody to follow a complex process? That would ensure the quality, but not for the cost of losing contributors. -----Original Message----- From: Herv? Girod [mailto:herve.girod at gmail.com] Sent: Dienstag, 1. Dezember 2015 20:19 To: Markus KARG Cc: openjfx-dev at openjdk.java.net Subject: Re: Future of JavaFX Things are not different for Apache projects. Google does not accept any external contributions. The Linux kernel development is very tightly controlled. We should stop considering that widespread open source policies are only a problem with JavaFX. These policies are in place for a reason. Herv? Sent from my iPhone > On Dec 1, 2015, at 20:13, Markus KARG wrote: > > I wonder why I was able to jointly assign my copyright with a lot of other > open source projects without having to sign papers, sent them in by fax, > wait for a written agreement, and pray to get a JIRA account... ;-) > > See, I talked to a real lot of former JavaFX contributors in the past weeks > (visited some European JUGs in 2015), and *virtually everybody* told me that > he is really unsatisfied with the fact that he cannot directly file to JIRA > anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX team > clear about how many contributors you lost by that policy? I really wonder > whether you see the reality there outside of Oracle. People stopped > reporting bugs! This is a real problem for JavaFX. You should act. Now. > > -Markus > > > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of > dalibor topic > Sent: Dienstag, 1. Dezember 2015 19:06 > To: openjfx-dev at openjdk.java.net > Subject: Re: Future of JavaFX > >> On 01.12.2015 18:35, Markus KARG wrote: >> With respect to TeamFX, the better question is: Are there plans to further >> open the project so third party has an easier channel to contribute > without >> the hazzle of contributor agreements > > "Like many other open-source communities, the OpenJDK Community requires > Contributors to jointly assign their copyright on contributed code." as > http://openjdk.java.net/contribute/ wisely says. > > There is no good reason to change that. > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From markus at headcrashing.eu Tue Dec 1 21:58:47 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 1 Dec 2015 22:58:47 +0100 Subject: Future of JavaFX In-Reply-To: <565DF71E.107@oracle.com> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <565DF71E.107@oracle.com> Message-ID: <001f01d12c83$74541360$5cfc3a20$@eu> Dalibor, exactly what I expected to hear from Oracle! You count the number of input that actually made it through exactly that bureaucracy I am talking about holding back contributors! Well done! Certainly the number is zero, that's what I try to tell you. I actually talk about those people that *did not* invest the time to contribute their JavaFX improvents, because they feat that bureaucracy. This number is what you can gain, and it is much higher. In fact, the number of people who feel p*-off by the JIRA-change this Summer is much larger than you would assume. Some of them being well-known in the JavaFX community, BTW. There are many people willing to contribute, but you simply ignore them thanks to statistics like those. Actually I assume we're talking about 100 people only in Germany from what the JUG leaders told me. Further ignore them if you like. Your choice. Count just my own JIRA tickets and multiply it by the number of JUGs and you come near to the real potential that you miss. -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of dalibor topic Sent: Dienstag, 1. Dezember 2015 20:38 To: openjfx-dev at openjdk.java.net Subject: Re: Future of JavaFX On 01.12.2015 20:13, Markus KARG wrote: > anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX team > clear about how many contributors you lost by that policy? I think the number you're looking for is zero, judging by the number of 'Contributed-by' changesets in the rt repository in the last 12 months.[0] In fact, the number of such changesets has increased significantly after the migration to JIRA back in June. Looks like the objective reality is quite different from subjective perception. ;) cheers, dalibor topic [0] http://hg.openjdk.java.net/openjfx/9-dev/rt/search/?rev=contributed-by&revco unt=40 -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From tomas.mikula at gmail.com Tue Dec 1 22:04:45 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Tue, 1 Dec 2015 17:04:45 -0500 Subject: Future of JavaFX In-Reply-To: <000b01d12c80$fcfe1100$f6fa3300$@eu> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <676EAF84-EB02-4BA1-9356-D478FD5993CA@gmail.com> <000b01d12c80$fcfe1100$f6fa3300$@eu> Message-ID: The review process for external contributions does not even have to be different from the internal review process. There can be a virtual organization on GitHub called "Oracle CLA signatories". After a pull request has been reviewed, all that the OpenJFX committer has to do before merging is to check whether the contributor is a member of this organization. Tomas On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG wrote: > We should ask ourselfs whether we want more contributions or not. We will > not get them until we change something. Most contributors in the Open > Source just want to drop a bug report or a feature or two, and multiplied > by the number of those guys, this is a lot of stuff. Only few contributors > are willing to stay for long time, and only for those it makes sense to > have the complex rules. For example, I do not see why we cannot have a > dedicated full time "Community Officer" who simply collects the > contributions, reviews it, applies the needed checks and rules and all that > instead of asking everybody to follow a complex process? That would ensure > the quality, but not for the cost of losing contributors. > > -----Original Message----- > From: Herv? Girod [mailto:herve.girod at gmail.com] > Sent: Dienstag, 1. Dezember 2015 20:19 > To: Markus KARG > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Future of JavaFX > > Things are not different for Apache projects. Google does not accept any > external contributions. The Linux kernel development is very tightly > controlled. We should stop considering that widespread open source policies > are only a problem with JavaFX. These policies are in place for a reason. > > Herv? > > Sent from my iPhone > > > On Dec 1, 2015, at 20:13, Markus KARG wrote: > > > > I wonder why I was able to jointly assign my copyright with a lot of > other > > open source projects without having to sign papers, sent them in by fax, > > wait for a written agreement, and pray to get a JIRA account... ;-) > > > > See, I talked to a real lot of former JavaFX contributors in the past > weeks > > (visited some European JUGs in 2015), and *virtually everybody* told me > that > > he is really unsatisfied with the fact that he cannot directly file to > JIRA > > anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX > team > > clear about how many contributors you lost by that policy? I really > wonder > > whether you see the reality there outside of Oracle. People stopped > > reporting bugs! This is a real problem for JavaFX. You should act. Now. > > > > -Markus > > > > > > > > -----Original Message----- > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On > Behalf Of > > dalibor topic > > Sent: Dienstag, 1. Dezember 2015 19:06 > > To: openjfx-dev at openjdk.java.net > > Subject: Re: Future of JavaFX > > > >> On 01.12.2015 18:35, Markus KARG wrote: > >> With respect to TeamFX, the better question is: Are there plans to > further > >> open the project so third party has an easier channel to contribute > > without > >> the hazzle of contributor agreements > > > > "Like many other open-source communities, the OpenJDK Community requires > > Contributors to jointly assign their copyright on contributed code." as > > http://openjdk.java.net/contribute/ wisely says. > > > > There is no good reason to change that. > > > > cheers, > > dalibor topic > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment > > > > From markus at headcrashing.eu Tue Dec 1 22:12:07 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 1 Dec 2015 23:12:07 +0100 Subject: Future of JavaFX In-Reply-To: References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <676EAF84-EB02-4BA1-9356-D478FD5993CA@gmail.com> <000b01d12c80$fcfe1100$f6fa3300$@eu> Message-ID: <003101d12c85$515718b0$f4054a10$@eu> Too bad that Github cannot fork mercurial repos. It would be interesting to see the real number of pull requests such a fork would gain. Maybe Dalibor is right and we would end up with zero? ;-) -Markus From: Tomas Mikula [mailto:tomas.mikula at gmail.com] Sent: Dienstag, 1. Dezember 2015 23:05 To: Markus KARG Cc: openjfx-dev at openjdk.java.net Subject: Re: Future of JavaFX The review process for external contributions does not even have to be different from the internal review process. There can be a virtual organization on GitHub called "Oracle CLA signatories". After a pull request has been reviewed, all that the OpenJFX committer has to do before merging is to check whether the contributor is a member of this organization. Tomas On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG wrote: We should ask ourselfs whether we want more contributions or not. We will not get them until we change something. Most contributors in the Open Source just want to drop a bug report or a feature or two, and multiplied by the number of those guys, this is a lot of stuff. Only few contributors are willing to stay for long time, and only for those it makes sense to have the complex rules. For example, I do not see why we cannot have a dedicated full time "Community Officer" who simply collects the contributions, reviews it, applies the needed checks and rules and all that instead of asking everybody to follow a complex process? That would ensure the quality, but not for the cost of losing contributors. -----Original Message----- From: Herv? Girod [mailto:herve.girod at gmail.com] Sent: Dienstag, 1. Dezember 2015 20:19 To: Markus KARG Cc: openjfx-dev at openjdk.java.net Subject: Re: Future of JavaFX Things are not different for Apache projects. Google does not accept any external contributions. The Linux kernel development is very tightly controlled. We should stop considering that widespread open source policies are only a problem with JavaFX. These policies are in place for a reason. Herv? Sent from my iPhone > On Dec 1, 2015, at 20:13, Markus KARG wrote: > > I wonder why I was able to jointly assign my copyright with a lot of other > open source projects without having to sign papers, sent them in by fax, > wait for a written agreement, and pray to get a JIRA account... ;-) > > See, I talked to a real lot of former JavaFX contributors in the past weeks > (visited some European JUGs in 2015), and *virtually everybody* told me that > he is really unsatisfied with the fact that he cannot directly file to JIRA > anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX team > clear about how many contributors you lost by that policy? I really wonder > whether you see the reality there outside of Oracle. People stopped > reporting bugs! This is a real problem for JavaFX. You should act. Now. > > -Markus > > > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of > dalibor topic > Sent: Dienstag, 1. Dezember 2015 19:06 > To: openjfx-dev at openjdk.java.net > Subject: Re: Future of JavaFX > >> On 01.12.2015 18:35, Markus KARG wrote: >> With respect to TeamFX, the better question is: Are there plans to further >> open the project so third party has an easier channel to contribute > without >> the hazzle of contributor agreements > > "Like many other open-source communities, the OpenJDK Community requires > Contributors to jointly assign their copyright on contributed code." as > http://openjdk.java.net/contribute/ wisely says. > > There is no good reason to change that. > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 > | Mobile: +491737185961 > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From tomas.mikula at gmail.com Tue Dec 1 22:16:46 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Tue, 1 Dec 2015 17:16:46 -0500 Subject: Future of JavaFX In-Reply-To: <003101d12c85$515718b0$f4054a10$@eu> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <676EAF84-EB02-4BA1-9356-D478FD5993CA@gmail.com> <000b01d12c80$fcfe1100$f6fa3300$@eu> <003101d12c85$515718b0$f4054a10$@eu> Message-ID: The proposed strategy also applies to bitbucket, which does have mercurial support ;) On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG wrote: > Too bad that Github cannot fork mercurial repos. It would be interesting > to see the real number of pull requests such a fork would gain. Maybe > Dalibor is right and we would end up with zero? ;-) > > -Markus > > > > From: Tomas Mikula [mailto:tomas.mikula at gmail.com] > Sent: Dienstag, 1. Dezember 2015 23:05 > To: Markus KARG > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Future of JavaFX > > > > The review process for external contributions does not even have to be > different from the internal review process. There can be a virtual > organization on GitHub called "Oracle CLA signatories". After a pull > request has been reviewed, all that the OpenJFX committer has to do before > merging is to check whether the contributor is a member of this > organization. > > > > Tomas > > > > On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG > wrote: > > We should ask ourselfs whether we want more contributions or not. We will > not get them until we change something. Most contributors in the Open > Source just want to drop a bug report or a feature or two, and multiplied > by the number of those guys, this is a lot of stuff. Only few contributors > are willing to stay for long time, and only for those it makes sense to > have the complex rules. For example, I do not see why we cannot have a > dedicated full time "Community Officer" who simply collects the > contributions, reviews it, applies the needed checks and rules and all that > instead of asking everybody to follow a complex process? That would ensure > the quality, but not for the cost of losing contributors. > > > -----Original Message----- > From: Herv? Girod [mailto:herve.girod at gmail.com] > Sent: Dienstag, 1. Dezember 2015 20:19 > To: Markus KARG > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Future of JavaFX > > Things are not different for Apache projects. Google does not accept any > external contributions. The Linux kernel development is very tightly > controlled. We should stop considering that widespread open source policies > are only a problem with JavaFX. These policies are in place for a reason. > > Herv? > > Sent from my iPhone > > > On Dec 1, 2015, at 20:13, Markus KARG wrote: > > > > I wonder why I was able to jointly assign my copyright with a lot of > other > > open source projects without having to sign papers, sent them in by fax, > > wait for a written agreement, and pray to get a JIRA account... ;-) > > > > See, I talked to a real lot of former JavaFX contributors in the past > weeks > > (visited some European JUGs in 2015), and *virtually everybody* told me > that > > he is really unsatisfied with the fact that he cannot directly file to > JIRA > > anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX > team > > clear about how many contributors you lost by that policy? I really > wonder > > whether you see the reality there outside of Oracle. People stopped > > reporting bugs! This is a real problem for JavaFX. You should act. Now. > > > > -Markus > > > > > > > > -----Original Message----- > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On > Behalf Of > > dalibor topic > > Sent: Dienstag, 1. Dezember 2015 19:06 > > To: openjfx-dev at openjdk.java.net > > Subject: Re: Future of JavaFX > > > >> On 01.12.2015 18:35, Markus KARG wrote: > >> With respect to TeamFX, the better question is: Are there plans to > further > >> open the project so third party has an easier channel to contribute > > without > >> the hazzle of contributor agreements > > > > "Like many other open-source communities, the OpenJDK Community requires > > Contributors to jointly assign their copyright on contributed code." as > > http://openjdk.java.net/contribute/ wisely says. > > > > There is no good reason to change that. > > > > cheers, > > dalibor topic > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 > | Mobile: +491737185961 > > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment > > > > > > From donald.smith at oracle.com Tue Dec 1 22:23:00 2015 From: donald.smith at oracle.com (Donald Smith) Date: Tue, 1 Dec 2015 17:23:00 -0500 Subject: Future of JavaFX In-Reply-To: References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <676EAF84-EB02-4BA1-9356-D478FD5993CA@gmail.com> <000b01d12c80$fcfe1100$f6fa3300$@eu> <003101d12c85$515718b0$f4054a10$@eu> Message-ID: <565E1DC4.2060208@oracle.com> Check in with the Adopt OpenJDK list, I know there's a few people who pull source OpenJDK into Github -- it can't be that difficult. I'm sure someone can help. - Don On 01/12/2015 5:16 PM, Tomas Mikula wrote: > The proposed strategy also applies to bitbucket, which does have mercurial > support ;) > > On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG wrote: > >> Too bad that Github cannot fork mercurial repos. It would be interesting >> to see the real number of pull requests such a fork would gain. Maybe >> Dalibor is right and we would end up with zero? ;-) >> >> -Markus >> >> >> >> From: Tomas Mikula [mailto:tomas.mikula at gmail.com] >> Sent: Dienstag, 1. Dezember 2015 23:05 >> To: Markus KARG >> Cc: openjfx-dev at openjdk.java.net >> Subject: Re: Future of JavaFX >> >> >> >> The review process for external contributions does not even have to be >> different from the internal review process. There can be a virtual >> organization on GitHub called "Oracle CLA signatories". After a pull >> request has been reviewed, all that the OpenJFX committer has to do before >> merging is to check whether the contributor is a member of this >> organization. >> >> >> >> Tomas >> >> >> >> On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG >> wrote: >> >> We should ask ourselfs whether we want more contributions or not. We will >> not get them until we change something. Most contributors in the Open >> Source just want to drop a bug report or a feature or two, and multiplied >> by the number of those guys, this is a lot of stuff. Only few contributors >> are willing to stay for long time, and only for those it makes sense to >> have the complex rules. For example, I do not see why we cannot have a >> dedicated full time "Community Officer" who simply collects the >> contributions, reviews it, applies the needed checks and rules and all that >> instead of asking everybody to follow a complex process? That would ensure >> the quality, but not for the cost of losing contributors. >> >> >> -----Original Message----- >> From: Herv? Girod [mailto:herve.girod at gmail.com] >> Sent: Dienstag, 1. Dezember 2015 20:19 >> To: Markus KARG >> Cc: openjfx-dev at openjdk.java.net >> Subject: Re: Future of JavaFX >> >> Things are not different for Apache projects. Google does not accept any >> external contributions. The Linux kernel development is very tightly >> controlled. We should stop considering that widespread open source policies >> are only a problem with JavaFX. These policies are in place for a reason. >> >> Herv? >> >> Sent from my iPhone >> >>> On Dec 1, 2015, at 20:13, Markus KARG wrote: >>> >>> I wonder why I was able to jointly assign my copyright with a lot of >> other >>> open source projects without having to sign papers, sent them in by fax, >>> wait for a written agreement, and pray to get a JIRA account... ;-) >>> >>> See, I talked to a real lot of former JavaFX contributors in the past >> weeks >>> (visited some European JUGs in 2015), and *virtually everybody* told me >> that >>> he is really unsatisfied with the fact that he cannot directly file to >> JIRA >>> anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX >> team >>> clear about how many contributors you lost by that policy? I really >> wonder >>> whether you see the reality there outside of Oracle. People stopped >>> reporting bugs! This is a real problem for JavaFX. You should act. Now. >>> >>> -Markus >>> >>> >>> >>> -----Original Message----- >>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >> Behalf Of >>> dalibor topic >>> Sent: Dienstag, 1. Dezember 2015 19:06 >>> To: openjfx-dev at openjdk.java.net >>> Subject: Re: Future of JavaFX >>> >>>> On 01.12.2015 18:35, Markus KARG wrote: >>>> With respect to TeamFX, the better question is: Are there plans to >> further >>>> open the project so third party has an easier channel to contribute >>> without >>>> the hazzle of contributor agreements >>> "Like many other open-source communities, the OpenJDK Community requires >>> Contributors to jointly assign their copyright on contributed code." as >>> http://openjdk.java.net/contribute/ wisely says. >>> >>> There is no good reason to change that. >>> >>> cheers, >>> dalibor topic >>> -- >>> Dalibor Topic | Principal Product Manager >>> Phone: +494089091214 > > | Mobile: +491737185961 >>> > >>> >>> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >>> >>> ORACLE Deutschland B.V. & Co. KG >>> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >>> Registergericht: Amtsgericht M?nchen, HRA 95603 >>> >>> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >>> Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher >>> >>> Oracle is committed to developing >>> practices and products that help protect the environment >>> >> >> >> From daniel.kraus at mailbox.org Tue Dec 1 22:26:44 2015 From: daniel.kraus at mailbox.org (Daniel Kraus) Date: Tue, 1 Dec 2015 23:26:44 +0100 (CET) Subject: Future of JavaFX Message-ID: <332427212.316.21dce89c-3c02-4a4d-8a34-f69712edfc42.open-xchange@office.mailbox.org> Volkswagen is doing a lot of research with JavaFX. For more than two years now, it is their technology of choice for rapid HMI prototyping. The have developed a framework?namely Tappas?entirely written in Java/JavaFX, which already runs on embedded hardware, featuring a 3D map renderer.[1][2][3] Projects like this are good to create trust in JavaFX, especially when huge companies like Volkswagen promote the technology. However, it is uncertain whether JavaFX will ever make it into series development. [1] https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=3700 [2] https://www.youtube.com/watch?v=y2mvLSzM1kg [3] http://www.bredex.de/blog_article_en/research-into-the-use-of-javafx-for-in-car-infotainment.html On 30-11-2015 22:52, Tom Eugelink wrote: > OTOH, from what I hear VW has chosen to use JavaFX for it's in car > systems. And I have just been on an interview for a traffic management > system where they chose JavaFX over web based. So there also is > adoption. But it will be slow. My gut says: give it time, and a bit of > TLC promotionwise would not be bad. > > Tom From jeffhain at rocketmail.com Tue Dec 1 22:48:22 2015 From: jeffhain at rocketmail.com (Jeff Hain) Date: Tue, 1 Dec 2015 22:48:22 +0000 (UTC) Subject: Future of JavaFX References: <149456164.22546453.1449010102855.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <149456164.22546453.1449010102855.JavaMail.yahoo@mail.yahoo.com> Felix Bembrick wrote: >it makes them no money >In my opinion, JavaFX should be jettisoned from the JDK Like AWT or Swing, it plays in favor of Java adoption by people looking for a portable way of doing something as simple as lighting up a pixel - which are still, after all these years, quite scarce - without having to resort to scripts like Tcl/Tk, or web's ever-changing mixture of dubious technologies (I say dubious to stay polite, else I would use a more Zed Shaw-esque vocabulary). That said (here comes my hobbyhorse), if Java also provided stable lower level UI primitives, on which other UI frameworks could be built, maybe UI frameworks would flourish in it as much as messaging frameworks do (as if we still had to invent the "sockets" of UI...), improving diversity, satisfaction and resilience within the Java ecosystem (and Oracle would have less need to grow a single monolithic framework attempting to fit every possible usage). -Jeff From kevin.rushforth at oracle.com Wed Dec 2 00:29:03 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 01 Dec 2015 16:29:03 -0800 Subject: Future of JavaFX In-Reply-To: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> Message-ID: <565E3B4F.6070907@oracle.com> Just to chime in on a couple of points that have been raised in this discussion... * We are interested in working with the OpenJFX community to improve JavaFX. In particular: if you find a bug, file it (via bugs.java.com if you don't have a JBS account); if you want to contribute a patch to fix the bug, we'd love to review it; if you have an idea for an improvement, file it as an RFE (enhancement) and start up a thread on the mailing list. Larger features need a JEP, but smaller improvements do not. Please be aware that as part of the OpenJDK community, we are bound by the processes of the OpenJDK, including the need for a signed OCA in order to contribute, and before you can get a JBS account. If you are dissatisfied with those processes and policies, then I invite you to discuss it on the discuss at openjdk.java.net alias, and not here. * While we aren't planning a huge number of features in JDK 9, we are delivering some interesting improvements. Jigsaw is the big release driver and most of our effort on JavaFX is to align with that. For those of you who weren't at JavaOne, here is a list of things that are currently planned for JDK 9: - A modularized JavaFX (into 6 core modules + deploy, swing interop, swt interop) - JEP 253 -- Control Skins & additional CSS APIs (proper support for third-party controls) - High DPI enhancements (full support on Windows; add support for Linux) - Public API for commonly used methods from internal packages: * Nested Event Loop * Pulse Listener * Platform Startup * Text API (HitTest, etc) * Static utility functions (under investigation) - New versions of WebKit and GStreamer And here is an incomplete list of things we are thinking about for after JDK 9, possibly in an update release. In fact, the recently proposed JDK 9 slip [1] makes it possible to consider pulling a few of them into JDK 9, so let us know which ones you consider most important: - Provide a JavaFX equivalent for JEP 272 / AWT ?Desktop? API - Make UI Control Behaviors public - UI Control Actions API - Public Focus Traversal API - JavaFX support for multi-resolution images - Draggable tabs - Image IO -- Kevin [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html From bryanb at webbtide.com Wed Dec 2 08:29:58 2015 From: bryanb at webbtide.com (Bryan Buchanan) Date: Wed, 2 Dec 2015 18:29:58 +1000 Subject: App freezing on Linux Message-ID: I have a customer testing an FX app and more often than not, if the app is left open for a while (20 minutes or so), either the mouse ceases to work, or if it does work, when you click a field, or do something that should re-paint the window, the whole FX window goes totally grey and the app "disappears". I've tried starting with "-Dprism.verbose=true -Dprism.order=sw" and without these options, and it seems to make no difference. The system is Xubuntu 14.0.43, kernel 3.13.0-71 running on a Gigabyte Brix, and Java 64 bit build 1.8.0_60-b27. I don't have this hardware in my office, but have run up a system with the same OS, kernel and Java, and cannot re-produce the problem. Are the any other command line switches, or debug flags that I can set to try and get a handle on why this is happening ? (Hope this is the right list for issues like this). From dalibor.topic at oracle.com Wed Dec 2 09:11:03 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 2 Dec 2015 10:11:03 +0100 Subject: Future of JavaFX In-Reply-To: <565E3B4F.6070907@oracle.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <565E3B4F.6070907@oracle.com> Message-ID: <565EB5A7.3040203@oracle.com> On 02.12.2015 01:29, Kevin Rushforth wrote: > Please be aware that as part of the OpenJDK community, we are bound by > the processes of the OpenJDK, including the need for a signed OCA in > order to contribute, and before you can get a JBS account. If you are > dissatisfied with those processes and policies, then I invite you to > discuss it on the discuss at openjdk.java.net alias, and not here. Suggestions for general improvements in that area are welcome on the adoption-discuss [0] mailing list. Please do make sure to check the list archives before posting to see if an idea hasn't been discussed already. cheers, dalibor topic [0] http://mail.openjdk.java.net/mailman/listinfo/adoption-discuss -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From ryan at jaeb.ca Wed Dec 2 09:44:47 2015 From: ryan at jaeb.ca (Ryan Jaeb) Date: Wed, 2 Dec 2015 03:44:47 -0600 Subject: Future of JavaFX In-Reply-To: <565EB5A7.3040203@oracle.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <565E3B4F.6070907@oracle.com> <565EB5A7.3040203@oracle.com> Message-ID: Which is it - discuss or adoption-discuss? I really hope someone jumps over and restarts the JBS policy conversation. I tried when the JIRA change was initially announced and my misunderstanding of some key facts undermined the message I was trying to get across. I also think it may have devalued the concerns that others were trying to raise, so it would be great to see everyone get another opportunity to participate in a discussion that may get taken more seriously. Learning from the mistakes I made last time, I think it would be useful if someone that's been using bugs.java.com could start the discussion with an overview of the bugs.java.com submission process. I would volunteer, but I quit submitting bugs when the submission process changed, so I wouldn't be able to offer an accurate explanation of the current process. Ryan Jaeb On Wed, Dec 2, 2015 at 3:11 AM, dalibor topic wrote: > > > On 02.12.2015 01:29, Kevin Rushforth wrote: > >> Please be aware that as part of the OpenJDK community, we are bound by >> the processes of the OpenJDK, including the need for a signed OCA in >> order to contribute, and before you can get a JBS account. If you are >> dissatisfied with those processes and policies, then I invite you to >> discuss it on the discuss at openjdk.java.net alias, and not here. >> > > Suggestions for general improvements in that area are welcome on the > adoption-discuss [0] mailing list. Please do make sure to check the list > archives before posting to see if an idea hasn't been discussed already. > > cheers, > dalibor topic > > [0] http://mail.openjdk.java.net/mailman/listinfo/adoption-discuss > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From dalibor.topic at oracle.com Wed Dec 2 09:45:40 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 2 Dec 2015 10:45:40 +0100 Subject: Future of JavaFX In-Reply-To: <001f01d12c83$74541360$5cfc3a20$@eu> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <565DF71E.107@oracle.com> <001f01d12c83$74541360$5cfc3a20$@eu> Message-ID: <565EBDC4.5040802@oracle.com> On 01.12.2015 22:58, Markus KARG wrote: > I actually talk about those people that *did not* invest the time to > contribute Making high quality contributions to open source projects takes a considerable amount of humbleness, time and effort. People who aren't able or willing to invest the necessary time and effort into making high quality contributions are not likely to produce acceptable results - in any open source community. To quote Jono Bacon: "Low-quality contributors don't bring much other than noise: they are a net drain on resources because other good contributors have to take time away to support them." [1] cheers, dalibor topic [1] http://opensource.com/life/15/3/how-to-fire-community-members -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Dec 2 09:52:53 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 2 Dec 2015 10:52:53 +0100 Subject: Future of JavaFX In-Reply-To: References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <565E3B4F.6070907@oracle.com> <565EB5A7.3040203@oracle.com> Message-ID: <565EBF75.8040305@oracle.com> On 02.12.2015 10:44, Ryan Jaeb wrote: > Which is it - discuss or adoption-discuss? adoption-discuss is for general discussion about bundling and aiding OpenJDK collaboration, discuss is for general discussion about the OpenJDK Community. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From krueger at lesspain.de Wed Dec 2 12:32:22 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Wed, 2 Dec 2015 13:32:22 +0100 Subject: Future of JavaFX In-Reply-To: <565EBDC4.5040802@oracle.com> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <565DF71E.107@oracle.com> <001f01d12c83$74541360$5cfc3a20$@eu> <565EBDC4.5040802@oracle.com> Message-ID: Please, you're really oversimplifying things, I'm not sure if intentionally. It's not just coding. In my company I pay people serious money who do testing and file reproducible test cases with a qualified analysis of what they observed and what may be the problem and that's what I have done in the past for JavaFX using my Jira account as also have a number of other qualified people who were affronted by the policy changes, which probably resulted in many of them stopping this because they could no longer follow their Jira tickets including taking part in discussions there or answering questions by the engineers. If you don't count these things as meaningful/valuable contributions that make a difference, I don't really know on what basis to argue anymore. Then I have to assume, you just don't want to really deal with criticism. Of course some unqualified ranting in a Jira issue hurts (i.e. consumes resources) more than it helps but putting the many qualified people (many of them on this list) all in that category is neither correct, nor a smart move in anyone's interest. On Wed, Dec 2, 2015 at 10:45 AM, dalibor topic wrote: > On 01.12.2015 22:58, Markus KARG wrote: > >> I actually talk about those people that *did not* invest the time to >> contribute >> > > Making high quality contributions to open source projects takes a > considerable amount of humbleness, time and effort. People who aren't able > or willing to invest the necessary time and effort into making high quality > contributions are not likely to produce acceptable results - in any open > source community. > > To quote Jono Bacon: > > "Low-quality contributors don't bring much other than noise: they are a > net drain on resources because other good contributors have to take time > away to support them." [1] > > cheers, > dalibor topic > > [1] http://opensource.com/life/15/3/how-to-fire-community-members > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > -- Robert Kr?ger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com From krueger at lesspain.de Wed Dec 2 12:46:17 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Wed, 2 Dec 2015 13:46:17 +0100 Subject: Future of JavaFX In-Reply-To: <565E3B4F.6070907@oracle.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <565E3B4F.6070907@oracle.com> Message-ID: Kevin, thanks for sharing those plans. How much of a priority are quality issues, especially on the Mac (which clearly is a second-class citizen as far as JavaFX is concerned)? Are things like flashing when opening Stages, bad rendering performance, broken media APIs etc. an issue? As far as my company is concerned, the biggest problem (which resulted in us reluctantly dropping the idea of a migration of our product to JFX for the time being after lengthy evaluation) is not so much lack of features but primarily quality in terms of robustness and user experience and the number of problems we have run into in almost every area that we did tests in was what led us to that decision (especially with Mac being our most important platform). Is there awareness that there are serious problems of the described kind that block the adoption of JFX in companies who desperately want to switch? It's always difficult to judge that by the priorities in Jira but it appeared to me that in many cases the perception on the Oracle side was very different, if things like the white flashing problem when opening windows or the tree view scrolling incorrectly or looping in a media api not working seemed to be viewed rather like a minor glitch. People have different requirements and thus different views on the topic of this thread but I found the analysis and observations in Shay's posting not very far from that of our own engineering team (no affiliation with him or his company btw.) for the reasons described above. Best regards, Robert On Wed, Dec 2, 2015 at 1:29 AM, Kevin Rushforth wrote: > Just to chime in on a couple of points that have been raised in this > discussion... > > * We are interested in working with the OpenJFX community to improve > JavaFX. In particular: if you find a bug, file it (via bugs.java.com if > you don't have a JBS account); if you want to contribute a patch to fix the > bug, we'd love to review it; if you have an idea for an improvement, file > it as an RFE (enhancement) and start up a thread on the mailing list. > Larger features need a JEP, but smaller improvements do not. > > Please be aware that as part of the OpenJDK community, we are bound by the > processes of the OpenJDK, including the need for a signed OCA in order to > contribute, and before you can get a JBS account. If you are dissatisfied > with those processes and policies, then I invite you to discuss it on the > discuss at openjdk.java.net alias, and not here. > > > * While we aren't planning a huge number of features in JDK 9, we are > delivering some interesting improvements. Jigsaw is the big release driver > and most of our effort on JavaFX is to align with that. For those of you > who weren't at JavaOne, here is a list of things that are currently planned > for JDK 9: > > - A modularized JavaFX (into 6 core modules + deploy, swing interop, swt > interop) > > - JEP 253 -- Control Skins & additional CSS APIs (proper support for > third-party controls) > > - High DPI enhancements (full support on Windows; add support for Linux) > > - Public API for commonly used methods from internal packages: > * Nested Event Loop > * Pulse Listener > * Platform Startup > * Text API (HitTest, etc) > * Static utility functions (under investigation) > > - New versions of WebKit and GStreamer > > And here is an incomplete list of things we are thinking about for after > JDK 9, possibly in an update release. In fact, the recently proposed JDK 9 > slip [1] makes it possible to consider pulling a few of them into JDK 9, so > let us know which ones you consider most important: > > - Provide a JavaFX equivalent for JEP 272 / AWT ?Desktop? API > > - Make UI Control Behaviors public > > - UI Control Actions API > > - Public Focus Traversal API > > - JavaFX support for multi-resolution images > > - Draggable tabs > > - Image IO > > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html > > -- Robert Kr?ger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com From tobi at ultramixer.com Wed Dec 2 13:05:05 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 2 Dec 2015 14:05:05 +0100 Subject: Future of JavaFX In-Reply-To: References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <565DF71E.107@oracle.com> <001f01d12c83$74541360$5cfc3a20$@eu> <565EBDC4.5040802@oracle.com> Message-ID: <9ACA2D10-B40E-417E-9282-C23F05127D7E@ultramixer.com> I absolutely agree. While we are committing to many Github projects it?s too hard to do that for JavaFX via bugs.sun.com?. Github is a modern way of developing together. The ?bugs.sun.com? way is like using a candle instead of electric light? Best Regards, Tobi > Am 02.12.2015 um 13:32 schrieb Robert Kr?ger : > > Please, you're really oversimplifying things, I'm not sure if > intentionally. It's not just coding. In my company I pay people > serious money who do testing and file reproducible test cases with a > qualified analysis of what they observed and what may be the problem and > that's what I have done in the past for JavaFX using my Jira account as > also have a number of other qualified people who were affronted by the > policy changes, which probably resulted in many of them stopping this > because they could no longer follow their Jira tickets including taking > part in discussions there or answering questions by the engineers. If you > don't count these things as meaningful/valuable contributions that make a > difference, I don't really know on what basis to argue anymore. Then I have > to assume, you just don't want to really deal with criticism. Of course > some unqualified ranting in a Jira issue hurts (i.e. consumes resources) > more than it helps but putting the many qualified people (many of them on > this list) all in that category is neither correct, nor a smart move in > anyone's interest. > > On Wed, Dec 2, 2015 at 10:45 AM, dalibor topic > wrote: > >> On 01.12.2015 22:58, Markus KARG wrote: >> >>> I actually talk about those people that *did not* invest the time to >>> contribute >>> >> >> Making high quality contributions to open source projects takes a >> considerable amount of humbleness, time and effort. People who aren't able >> or willing to invest the necessary time and effort into making high quality >> contributions are not likely to produce acceptable results - in any open >> source community. >> >> To quote Jono Bacon: >> >> "Low-quality contributors don't bring much other than noise: they are a >> net drain on resources because other good contributors have to take time >> away to support them." [1] >> >> cheers, >> dalibor topic >> >> [1] http://opensource.com/life/15/3/how-to-fire-community-members >> >> -- >> Dalibor Topic | Principal Product Manager >> Phone: +494089091214 | Mobile: +491737185961 >> >> >> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >> >> ORACLE Deutschland B.V. & Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher >> >> Oracle is committed to developing >> practices and products that help protect the environment >> > > > > -- > Robert Kr?ger > Managing Partner > Lesspain GmbH & Co. KG > > www.lesspain-software.com From kevin.rushforth at oracle.com Wed Dec 2 16:36:51 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 02 Dec 2015 08:36:51 -0800 Subject: Verona (JEP 223) Integration to JDK 9 In-Reply-To: <5654BF49.5030707@oracle.com> References: <5654BF49.5030707@oracle.com> Message-ID: <565F1E23.8070201@oracle.com> The Verona integration is complete and has been synced back down into FX 9-dev. The per-build tags now match the JDK, so build 94 was tagged with "9-b94" and build 95 is tagged with "jdk-9+95". -- Kevin Kevin Rushforth wrote: > Hi, > > The Verona (JEP 223) Integration to JDK 9 is planned for next week as > announced on the jdk9-dev mailing list [1]. > > This will have a small impact on JavaFX in that we will skip next > week's integration from FX 9-dev into 9 master, for the same reason as > the JDK. The anticipated FX-specific dates are: > > On or before Mon 30 Nov > - Sync FX sandbox-9-verona [2] with FX 9 MASTER (build 94) > > Mon 30 Nov (evening) or Tue 1 Dec (morning) > - Integrate sandbox-9-verona to 9 (MASTER) > > Wed 2 Dec > - After promotion, sync down to FX 9-dev and sandbox-9-jake > > Thanks. > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-November/003100.html > [2] http://hg.openjdk.java.net/openjfx/sandbox-9-verona/rt > From markus at headcrashing.eu Wed Dec 2 17:36:03 2015 From: markus at headcrashing.eu (Markus KARG) Date: Wed, 2 Dec 2015 18:36:03 +0100 Subject: App freezing on Linux In-Reply-To: References: Message-ID: <001e01d12d27$eb0dce20$c1296a60$@eu> Please try again with JavaFX 1.8.0_66. -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Bryan Buchanan Sent: Mittwoch, 2. Dezember 2015 09:30 To: openjfx-dev at openjdk.java.net Subject: App freezing on Linux I have a customer testing an FX app and more often than not, if the app is left open for a while (20 minutes or so), either the mouse ceases to work, or if it does work, when you click a field, or do something that should re-paint the window, the whole FX window goes totally grey and the app "disappears". I've tried starting with "-Dprism.verbose=true -Dprism.order=sw" and without these options, and it seems to make no difference. The system is Xubuntu 14.0.43, kernel 3.13.0-71 running on a Gigabyte Brix, and Java 64 bit build 1.8.0_60-b27. I don't have this hardware in my office, but have run up a system with the same OS, kernel and Java, and cannot re-produce the problem. Are the any other command line switches, or debug flags that I can set to try and get a handle on why this is happening ? (Hope this is the right list for issues like this). From markus at headcrashing.eu Wed Dec 2 17:45:02 2015 From: markus at headcrashing.eu (Markus KARG) Date: Wed, 2 Dec 2015 18:45:02 +0100 Subject: Future of JavaFX In-Reply-To: <565EBDC4.5040802@oracle.com> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <565DF71E.107@oracle.com> <001f01d12c83$74541360$5cfc3a20$@eu> <565EBDC4.5040802@oracle.com> Message-ID: <002401d12d29$2c24e6e0$846eb4a0$@eu> I see it differently. Often the initial contribution does not fulfil the quality, because the original author alone has not the time to fix all the law stuff, but just has a great idea and hacks it down. Then others chime in an fix it. I often saw (an helped with) such features in other open source projects like PostgreSQL, JOnAS, FOP, DITA-OT... and it was always a great experience to work *together* to get the thing running and finally done in the wanted quality. This is not possible in the JavaFX project, as the original author has no chance to file to core idea and let others finish it, since you expect the original author not only having the great idea and hack together the first draw, but first of all, sign papers, read lots of rules and process definitions, and so on, before you even take a look at his idea (this is what happened to me several times). Hence, you expect the original author to have plenty of time to do all that on his own, all alone. That does not match on most community driven open source authors, it only matches on commercial open source vendors. So actually you only want to get contributions from Oracle, IBM, Gluan and possibly a hand full of fully paid others, but not from the user space. That's a pity, because that user space has a lot of great ideas. So if you only want full-time contributors, please say it loud and clear on the "how to contribute" page, and all that "noise" from the community will stop at once -- including USING JavaFX as a side effect. I wouldn't bother you if I wouldn't have met those people and listened to their ideas, BTW. -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of dalibor topic Sent: Mittwoch, 2. Dezember 2015 10:46 To: openjfx-dev at openjdk.java.net Subject: Re: Future of JavaFX On 01.12.2015 22:58, Markus KARG wrote: > I actually talk about those people that *did not* invest the time to > contribute Making high quality contributions to open source projects takes a considerable amount of humbleness, time and effort. People who aren't able or willing to invest the necessary time and effort into making high quality contributions are not likely to produce acceptable results - in any open source community. To quote Jono Bacon: "Low-quality contributors don't bring much other than noise: they are a net drain on resources because other good contributors have to take time away to support them." [1] cheers, dalibor topic [1] http://opensource.com/life/15/3/how-to-fire-community-members -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From chien.yang at oracle.com Wed Dec 2 19:44:37 2015 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 02 Dec 2015 11:44:37 -0800 Subject: Future of JavaFX In-Reply-To: References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <565E3B4F.6070907@oracle.com> Message-ID: <565F4A25.2090502@oracle.com> On 12/2/15, 4:46 AM, Robert Kr?ger wrote: > How much of a priority are quality issues, > especially on the Mac (which clearly is a second-class citizen as far as > JavaFX is concerned)? Are things like flashing when opening Stages, bad > rendering performance, broken media APIs etc. an issue? We have been busy fixing bugs to ensure a high quality release for 9 on all supported platforms. Many of our developers have a Mac and it is tested weekly. If you found a bug that is still reproducible on the JDK 9 early access please file it [1]. We will definitely investigate it. [1] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report - Chien From kevin.rushforth at oracle.com Wed Dec 2 20:51:17 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 02 Dec 2015 12:51:17 -0800 Subject: Future of JavaFX In-Reply-To: <565F4A25.2090502@oracle.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <565E3B4F.6070907@oracle.com> <565F4A25.2090502@oracle.com> Message-ID: <565F59C5.5090308@oracle.com> To add to this, if there is an existing open bug that you consider important, please let us know. -- Kevin Chien Yang wrote: > On 12/2/15, 4:46 AM, Robert Kr?ger wrote: >> How much of a priority are quality issues, >> especially on the Mac (which clearly is a second-class citizen as far as >> JavaFX is concerned)? Are things like flashing when opening Stages, bad >> rendering performance, broken media APIs etc. an issue? > We have been busy fixing bugs to ensure a high quality release for 9 > on all supported platforms. Many of our developers have a Mac and it > is tested weekly. If you found a bug that is still reproducible on the > JDK 9 early access please file it [1]. We will definitely investigate it. > > [1] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report > > - Chien From ilyabuziuk at gmail.com Wed Dec 2 21:19:45 2015 From: ilyabuziuk at gmail.com (Ilya Buziuk) Date: Thu, 3 Dec 2015 00:19:45 +0300 Subject: Future of JavaFX In-Reply-To: <565F59C5.5090308@oracle.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <565E3B4F.6070907@oracle.com> <565F4A25.2090502@oracle.com> <565F59C5.5090308@oracle.com> Message-ID: Hello, guys If the question about bugs that are considered important was risen I would say that for me (as a JBoss Tools developer who uses JavaFx for cordova ripple based mobile emulator) the regression JDK-8090205 is utterly important. Basically, it makes Debugger API unusable since 8u20 On Wed, Dec 2, 2015 at 11:51 PM, Kevin Rushforth wrote: > To add to this, if there is an existing open bug that you consider > important, please let us know. > > -- Kevin > > > > Chien Yang wrote: > >> On 12/2/15, 4:46 AM, Robert Kr?ger wrote: >> >>> How much of a priority are quality issues, >>> especially on the Mac (which clearly is a second-class citizen as far as >>> JavaFX is concerned)? Are things like flashing when opening Stages, bad >>> rendering performance, broken media APIs etc. an issue? >>> >> We have been busy fixing bugs to ensure a high quality release for 9 on >> all supported platforms. Many of our developers have a Mac and it is tested >> weekly. If you found a bug that is still reproducible on the JDK 9 early >> access please file it [1]. We will definitely investigate it. >> >> [1] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report >> >> - Chien >> > -- Best Regards, Ilya Buziuk From kevin.rushforth at oracle.com Wed Dec 2 21:29:19 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 02 Dec 2015 13:29:19 -0800 Subject: Future of JavaFX In-Reply-To: References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <565E3B4F.6070907@oracle.com> <565F4A25.2090502@oracle.com> <565F59C5.5090308@oracle.com> Message-ID: <565F62AF.6050408@oracle.com> I'll add a comment to the bug report. -- Kevin Ilya Buziuk wrote: > Hello, guys > If the question about bugs that are considered important was risen I > would say that for me (as a JBoss Tools > developer who uses JavaFx for cordova ripple based mobile emulator) > the regression JDK-8090205 > is utterly > important. Basically, it makes Debugger API unusable since 8u20 > > On Wed, Dec 2, 2015 at 11:51 PM, Kevin Rushforth > > wrote: > > To add to this, if there is an existing open bug that you consider > important, please let us know. > > -- Kevin > > > > Chien Yang wrote: > > On 12/2/15, 4:46 AM, Robert Kr?ger wrote: > > How much of a priority are quality issues, > especially on the Mac (which clearly is a second-class > citizen as far as > JavaFX is concerned)? Are things like flashing when > opening Stages, bad > rendering performance, broken media APIs etc. an issue? > > We have been busy fixing bugs to ensure a high quality release > for 9 on all supported platforms. Many of our developers have > a Mac and it is tested weekly. If you found a bug that is > still reproducible on the JDK 9 early access please file it > [1]. We will definitely investigate it. > > [1] > https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report > > - Chien > > > > > -- > Best Regards, > Ilya Buziuk From fbrunnerlist at gmx.ch Wed Dec 2 22:43:44 2015 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Wed, 02 Dec 2015 23:43:44 +0100 Subject: Future of JavaFX In-Reply-To: References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <003101d12c85$515718b0$f4054a10$@eu> Message-ID: <1622862.nWnHI9qTSB@andor> Some time ago there actaully was a OpenJFX mirror repository on BitBucket. I'm not totally sure anymore why this was stopped. I think it needs someone who keeps the repositories in sync and there were some concerns that it's harder to control who wrote a patch. But maybe the idea with CLA signers only members would solve this issue? So I see 3 pain points being raised. 1. Signing the CLA. - Personally, I don't see any way around this. If there is no CLA then you end up with a project _nobody_ is in control of. - Basically it envolves the following steps: -- Download it from the website -- print it -- sign it -- send it off -- you only have to do this once -- you don't have to wait for Oracle to receive it to start working on the issue you like to solve Can this be presented in a way it doesn't scare people away as according to some statements it seems to do now? 2. State-of-the-art code collaboration platform. -- This would have to be something like GitHub or BitBucket -- Only CLA signers can be members of the project -- Someone has to be in charge to synchronize the repositories (probably one way only) -- personally I like to work with feature branches in Git but I think you can get something similar with Mercurial bookmarks. So --- pick an issue you would like to work on --- consider to announce it on this mailing list --- create a feature branch --- start pushing your changes to the feature branch --- other developers of the projects (all CLA signers) might chime in as they like --- once you think you're finished create a patch from the feature branch and add it to the issue or (if you don't have enough rights) send it to the mailing list --- take the feedback from the review, do the fixes an create another patch etc. So the main benefit would be that several developers could work on the same issue until it gets to a high enough qualiy state to be merged into the main repository and not requiring one developer to do it all on his/ her own. 3. Filing and commenting on issues - if you don't have enough rights, file it on bugs.java.com - ask on this mailing list (or ask someone you know on this mailing list to do it for you) about the corresponding issue on bugs.openjdk.java.net - someone from Oracle should give anyone who filed an issue that made it to bugs.openjdk.java.net the enough rights so he/ she can join on the discussion in the issue Any better way? -Florian Am Dienstag, 1. Dezember 2015, 17.16:46 schrieb Tomas Mikula: > The proposed strategy also applies to bitbucket, which does have mercurial > support ;) > > On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG wrote: > > Too bad that Github cannot fork mercurial repos. It would be interesting > > to see the real number of pull requests such a fork would gain. Maybe > > Dalibor is right and we would end up with zero? ;-) > > > > -Markus > > > > > > > > From: Tomas Mikula [mailto:tomas.mikula at gmail.com] > > Sent: Dienstag, 1. Dezember 2015 23:05 > > To: Markus KARG > > Cc: openjfx-dev at openjdk.java.net > > Subject: Re: Future of JavaFX > > > > > > > > The review process for external contributions does not even have to be > > different from the internal review process. There can be a virtual > > organization on GitHub called "Oracle CLA signatories". After a pull > > request has been reviewed, all that the OpenJFX committer has to do before > > merging is to check whether the contributor is a member of this > > organization. > > > > > > > > Tomas > > > > > > > > On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG > > wrote: > > > > We should ask ourselfs whether we want more contributions or not. We will > > not get them until we change something. Most contributors in the Open > > Source just want to drop a bug report or a feature or two, and multiplied > > by the number of those guys, this is a lot of stuff. Only few contributors > > are willing to stay for long time, and only for those it makes sense to > > have the complex rules. For example, I do not see why we cannot have a > > dedicated full time "Community Officer" who simply collects the > > contributions, reviews it, applies the needed checks and rules and all > > that > > instead of asking everybody to follow a complex process? That would ensure > > the quality, but not for the cost of losing contributors. > > > > > > -----Original Message----- > > From: Herv? Girod [mailto:herve.girod at gmail.com] > > Sent: Dienstag, 1. Dezember 2015 20:19 > > To: Markus KARG > > Cc: openjfx-dev at openjdk.java.net > > Subject: Re: Future of JavaFX > > > > Things are not different for Apache projects. Google does not accept any > > external contributions. The Linux kernel development is very tightly > > controlled. We should stop considering that widespread open source > > policies > > are only a problem with JavaFX. These policies are in place for a reason. > > > > Herv? > > > > Sent from my iPhone > > > > > On Dec 1, 2015, at 20:13, Markus KARG wrote: > > > > > > I wonder why I was able to jointly assign my copyright with a lot of > > > > other > > > > > open source projects without having to sign papers, sent them in by fax, > > > wait for a written agreement, and pray to get a JIRA account... ;-) > > > > > > See, I talked to a real lot of former JavaFX contributors in the past > > > > weeks > > > > > (visited some European JUGs in 2015), and *virtually everybody* told me > > > > that > > > > > he is really unsatisfied with the fact that he cannot directly file to > > > > JIRA > > > > > anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX > > > > team > > > > > clear about how many contributors you lost by that policy? I really > > > > wonder > > > > > whether you see the reality there outside of Oracle. People stopped > > > reporting bugs! This is a real problem for JavaFX. You should act. Now. > > > > > > -Markus > > > > > > > > > > > > -----Original Message----- > > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On > > > > Behalf Of > > > > > dalibor topic > > > Sent: Dienstag, 1. Dezember 2015 19:06 > > > To: openjfx-dev at openjdk.java.net > > > Subject: Re: Future of JavaFX > > > > > >> On 01.12.2015 18:35, Markus KARG wrote: > > >> With respect to TeamFX, the better question is: Are there plans to > > > > further > > > > >> open the project so third party has an easier channel to contribute > > > > > > without > > > > > >> the hazzle of contributor agreements > > > > > > "Like many other open-source communities, the OpenJDK Community requires > > > Contributors to jointly assign their copyright on contributed code." as > > > http://openjdk.java.net/contribute/ wisely says. > > > > > > There is no good reason to change that. > > > > > > cheers, > > > dalibor topic > > > -- > > > Dalibor Topic | Principal Product Manager > > > Phone: +494089091214 > > > > | Mobile: +491737185961 > > > > > > > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > > > ORACLE Deutschland B.V. & Co. KG > > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > > > > > Oracle is committed to developing > > > practices and products that help protect the environment From phidias51 at gmail.com Wed Dec 2 23:12:00 2015 From: phidias51 at gmail.com (Mark Fortner) Date: Wed, 2 Dec 2015 17:12:00 -0600 Subject: Future of JavaFX In-Reply-To: <1622862.nWnHI9qTSB@andor> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <003101d12c85$515718b0$f4054a10$@eu> <1622862.nWnHI9qTSB@andor> Message-ID: I think the first hurdle is to get people to sign the CLA. Having to print a copy, sign it, and find a fax machine or scanner to resend it seems kind of archaic in this day and age. That said, e-signing a PDF shouldn't be too difficult, but it would be better if it were simply a form that you attached your public key to. This would serve 2 purposes: (1) you have a proxy for a signature, (2) the key could be used to access the repo. That said, even that might be too much for people who just have a quick bug fix that they'd like to see reviewed and merged. Cheers, Mark On Wed, Dec 2, 2015 at 4:43 PM, Florian Brunner wrote: > Some time ago there actaully was a OpenJFX mirror repository on BitBucket. > > I'm not totally sure anymore why this was stopped. I think it needs someone > who keeps the repositories in sync and there were some concerns that it's > harder to control who wrote a patch. But maybe the idea with CLA signers > only > members would solve this issue? > > So I see 3 pain points being raised. > > 1. Signing the CLA. > - Personally, I don't see any way around this. If there is no CLA > then you > end up with a project _nobody_ is in control of. > - Basically it envolves the following steps: > -- Download it from the website > -- print it > -- sign it > -- send it off > -- you only have to do this once > -- you don't have to wait for Oracle to receive it to start > working > on the issue you like to solve > > Can this be presented in a way it doesn't scare people away as > according to > some statements it seems to do now? > > 2. State-of-the-art code collaboration platform. > -- This would have to be something like GitHub or BitBucket > -- Only CLA signers can be members of the project > -- Someone has to be in charge to synchronize the repositories > (probably one way only) > -- personally I like to work with feature branches in Git but I > think > you can get something similar with Mercurial bookmarks. So > --- pick an issue you would like to work on > --- consider to announce it on this mailing list > --- create a feature branch > --- start pushing your changes to the feature branch > --- other developers of the projects (all CLA signers) might chime > in > as they like > --- once you think you're finished create a patch from the feature > branch and add it to the issue or (if you don't have enough rights) send > it to > the mailing list > --- take the feedback from the review, do the fixes an create > another > patch etc. > > So the main benefit would be that several developers could work on the same > issue until it gets to a high enough qualiy state to be merged into the > main > repository and not requiring one developer to do it all on his/ her own. > > > 3. Filing and commenting on issues > - if you don't have enough rights, file it on bugs.java.com > - ask on this mailing list (or ask someone you know on this mailing list > to > do it for you) about the corresponding issue on bugs.openjdk.java.net > - someone from Oracle should give anyone who filed an issue that made it > to > bugs.openjdk.java.net the enough rights so he/ she can join on the > discussion > in the issue > > Any better way? > > > -Florian > > Am Dienstag, 1. Dezember 2015, 17.16:46 schrieb Tomas Mikula: > > The proposed strategy also applies to bitbucket, which does have > mercurial > > support ;) > > > > On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG > wrote: > > > Too bad that Github cannot fork mercurial repos. It would be > interesting > > > to see the real number of pull requests such a fork would gain. Maybe > > > Dalibor is right and we would end up with zero? ;-) > > > > > > -Markus > > > > > > > > > > > > From: Tomas Mikula [mailto:tomas.mikula at gmail.com] > > > Sent: Dienstag, 1. Dezember 2015 23:05 > > > To: Markus KARG > > > Cc: openjfx-dev at openjdk.java.net > > > Subject: Re: Future of JavaFX > > > > > > > > > > > > The review process for external contributions does not even have to be > > > different from the internal review process. There can be a virtual > > > organization on GitHub called "Oracle CLA signatories". After a pull > > > request has been reviewed, all that the OpenJFX committer has to do > before > > > merging is to check whether the contributor is a member of this > > > organization. > > > > > > > > > > > > Tomas > > > > > > > > > > > > On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG > > > wrote: > > > > > > We should ask ourselfs whether we want more contributions or not. We > will > > > not get them until we change something. Most contributors in the Open > > > Source just want to drop a bug report or a feature or two, and > multiplied > > > by the number of those guys, this is a lot of stuff. Only few > contributors > > > are willing to stay for long time, and only for those it makes sense to > > > have the complex rules. For example, I do not see why we cannot have a > > > dedicated full time "Community Officer" who simply collects the > > > contributions, reviews it, applies the needed checks and rules and all > > > that > > > instead of asking everybody to follow a complex process? That would > ensure > > > the quality, but not for the cost of losing contributors. > > > > > > > > > -----Original Message----- > > > From: Herv? Girod [mailto:herve.girod at gmail.com] > > > Sent: Dienstag, 1. Dezember 2015 20:19 > > > To: Markus KARG > > > Cc: openjfx-dev at openjdk.java.net > > > Subject: Re: Future of JavaFX > > > > > > Things are not different for Apache projects. Google does not accept > any > > > external contributions. The Linux kernel development is very tightly > > > controlled. We should stop considering that widespread open source > > > policies > > > are only a problem with JavaFX. These policies are in place for a > reason. > > > > > > Herv? > > > > > > Sent from my iPhone > > > > > > > On Dec 1, 2015, at 20:13, Markus KARG > wrote: > > > > > > > > I wonder why I was able to jointly assign my copyright with a lot of > > > > > > other > > > > > > > open source projects without having to sign papers, sent them in by > fax, > > > > wait for a written agreement, and pray to get a JIRA account... ;-) > > > > > > > > See, I talked to a real lot of former JavaFX contributors in the past > > > > > > weeks > > > > > > > (visited some European JUGs in 2015), and *virtually everybody* told > me > > > > > > that > > > > > > > he is really unsatisfied with the fact that he cannot directly file > to > > > > > > JIRA > > > > > > > anymore or AT LEAST vote and comment on existing tickets. Is the > JavaFX > > > > > > team > > > > > > > clear about how many contributors you lost by that policy? I really > > > > > > wonder > > > > > > > whether you see the reality there outside of Oracle. People stopped > > > > reporting bugs! This is a real problem for JavaFX. You should act. > Now. > > > > > > > > -Markus > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On > > > > > > Behalf Of > > > > > > > dalibor topic > > > > Sent: Dienstag, 1. Dezember 2015 19:06 > > > > To: openjfx-dev at openjdk.java.net > > > > Subject: Re: Future of JavaFX > > > > > > > >> On 01.12.2015 18:35, Markus KARG wrote: > > > >> With respect to TeamFX, the better question is: Are there plans to > > > > > > further > > > > > > >> open the project so third party has an easier channel to contribute > > > > > > > > without > > > > > > > >> the hazzle of contributor agreements > > > > > > > > "Like many other open-source communities, the OpenJDK Community > requires > > > > Contributors to jointly assign their copyright on contributed code." > as > > > > http://openjdk.java.net/contribute/ wisely says. > > > > > > > > There is no good reason to change that. > > > > > > > > cheers, > > > > dalibor topic > > > > -- > > > > Dalibor Topic | Principal Product Manager > > > > Phone: +494089091214 > > > > > > | Mobile: +491737185961 > > > > > > > > > > > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > > > > > ORACLE Deutschland B.V. & Co. KG > > > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > > > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > > > > > > > Oracle is committed to developing > > > > practices and products that help protect the environment > > From jonathan.giles at oracle.com Wed Dec 2 23:42:55 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 3 Dec 2015 12:42:55 +1300 Subject: Reviewing impl_* methods in JavaFX Message-ID: <565F81FF.8070605@oracle.com> Hi all. As you may recall a few months back I kicked off a review of APIs that exist in com.sun.* packages that were going to be lost due to the arrival of JDK 9. This resulted in a small number of APIs being proposed and made public in the last few weeks. With JDK 9 slipping we think it is prudent to use some of this time to do a similar exercise for the many impl_* methods that exist as deprecated methods in JavaFX. We would like to do two things: 1) Remove as many of these as possible. 2) Replace the relevant (and most important) impl_ methods with proper, non-deprecated API instead. Some impl_* methods need to go simply because they take as arguments com.sun.* API. Other impl_* methods need to go away as they are bad or wrong API, intended for internal use only. Some subset of impl_* methods exist because they were added without the benefit of a full API review, but should now be reviewed and possibly made public. Another indicator of how far we should progress this review is your usage of these methods. Therefore, it would be very interesting to us if you could email me (off list!) the output of a grep search in your projects. You could try running a command along the lines of the following: grep -r --include "*.java" "impl_" . This will help to inform us about the extent to which methods are being used, and which ones we need to think more carefully about before removing or replacing. Thanks, Jonathan From chien.yang at oracle.com Wed Dec 2 23:43:23 2015 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 02 Dec 2015 15:43:23 -0800 Subject: Code Review Request For JDK-8144542: Remove an experimental stopgap fix (-Dprism.experimental.skipMeshNormalComputation) that is no longer needed Message-ID: <565F821B.7070207@oracle.com> Hi Kevin, Please review the proposed fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8144542 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8144542/webrev.00/ Thanks, - Chien From fbrunnerlist at gmx.ch Wed Dec 2 23:50:07 2015 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Thu, 03 Dec 2015 00:50:07 +0100 Subject: Future of JavaFX In-Reply-To: <1622862.nWnHI9qTSB@andor> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <1622862.nWnHI9qTSB@andor> Message-ID: <1613094.Rc6KRyOcE3@andor> I think actually the 2nd point (State-of-the-art code collaboration platform) is not comfortable enough how I described it. Firstly, it should be a CI server, not a person, who synchronizes the repositories whenever there is a change on a non-feature branch of the main repository. Secondly, try to work with pull requests For this to work in such an environment the collaborations platform needs the following features, I think: - restrict write access to the non-feature branchens (in Gitflow based Git repositories these are usually at least the "master" and "develop" branch), Only the CI server (or maybe the platform) should have write access to these branches, but no developer. - provide the possibility to define a reviewer group and set up a rule that at least one member of this reviewer group needs to approve the pull request - the reviewer should get an email (push notfication) whenever there is a new pull request or whenever a pull request changed At least for Git, Atlassian Stash can provide such features, AFAIK. Maybe BitBucket does provide some similar features for Mercurial repositories? If such a collaboration platform can be established/ configured it should even be possible to set-up another CI server job for 2 way synchronization, as it can be made sure everything has been reviewed by an accepted reviewer. -Florian Am Mittwoch, 2. Dezember 2015, 23.43:44 schrieb Florian Brunner: > Some time ago there actaully was a OpenJFX mirror repository on BitBucket. > > I'm not totally sure anymore why this was stopped. I think it needs someone > who keeps the repositories in sync and there were some concerns that it's > harder to control who wrote a patch. But maybe the idea with CLA signers > only members would solve this issue? > > So I see 3 pain points being raised. > > 1. Signing the CLA. > - Personally, I don't see any way around this. If there is no CLA then you > end up with a project _nobody_ is in control of. > - Basically it envolves the following steps: > -- Download it from the website > -- print it > -- sign it > -- send it off > -- you only have to do this once > -- you don't have to wait for Oracle to receive it to start working > on the issue you like to solve > > Can this be presented in a way it doesn't scare people away as according > to some statements it seems to do now? > > 2. State-of-the-art code collaboration platform. > -- This would have to be something like GitHub or BitBucket > -- Only CLA signers can be members of the project > -- Someone has to be in charge to synchronize the repositories > (probably one way only) > -- personally I like to work with feature branches in Git but I > think you can get something similar with Mercurial bookmarks. So > --- pick an issue you would like to work on > --- consider to announce it on this mailing list > --- create a feature branch > --- start pushing your changes to the feature branch > --- other developers of the projects (all CLA signers) might chime > in as they like > --- once you think you're finished create a patch from the feature > branch and add it to the issue or (if you don't have enough rights) send it > to the mailing list > --- take the feedback from the review, do the fixes an create another > patch etc. > > So the main benefit would be that several developers could work on the same > issue until it gets to a high enough qualiy state to be merged into the main > repository and not requiring one developer to do it all on his/ her own. > > > 3. Filing and commenting on issues > - if you don't have enough rights, file it on bugs.java.com > - ask on this mailing list (or ask someone you know on this mailing list > to do it for you) about the corresponding issue on bugs.openjdk.java.net - > someone from Oracle should give anyone who filed an issue that made it to > bugs.openjdk.java.net the enough rights so he/ she can join on the > discussion in the issue > > Any better way? > > > -Florian > > Am Dienstag, 1. Dezember 2015, 17.16:46 schrieb Tomas Mikula: > > The proposed strategy also applies to bitbucket, which does have mercurial > > support ;) > > > > On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG wrote: > > > Too bad that Github cannot fork mercurial repos. It would be interesting > > > to see the real number of pull requests such a fork would gain. Maybe > > > Dalibor is right and we would end up with zero? ;-) > > > > > > -Markus > > > > > > > > > > > > From: Tomas Mikula [mailto:tomas.mikula at gmail.com] > > > Sent: Dienstag, 1. Dezember 2015 23:05 > > > To: Markus KARG > > > Cc: openjfx-dev at openjdk.java.net > > > Subject: Re: Future of JavaFX > > > > > > > > > > > > The review process for external contributions does not even have to be > > > different from the internal review process. There can be a virtual > > > organization on GitHub called "Oracle CLA signatories". After a pull > > > request has been reviewed, all that the OpenJFX committer has to do > > > before > > > merging is to check whether the contributor is a member of this > > > organization. > > > > > > > > > > > > Tomas > > > > > > > > > > > > On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG > > > wrote: > > > > > > We should ask ourselfs whether we want more contributions or not. We > > > will > > > not get them until we change something. Most contributors in the Open > > > Source just want to drop a bug report or a feature or two, and > > > multiplied > > > by the number of those guys, this is a lot of stuff. Only few > > > contributors > > > are willing to stay for long time, and only for those it makes sense to > > > have the complex rules. For example, I do not see why we cannot have a > > > dedicated full time "Community Officer" who simply collects the > > > contributions, reviews it, applies the needed checks and rules and all > > > that > > > instead of asking everybody to follow a complex process? That would > > > ensure > > > the quality, but not for the cost of losing contributors. > > > > > > > > > -----Original Message----- > > > From: Herv? Girod [mailto:herve.girod at gmail.com] > > > Sent: Dienstag, 1. Dezember 2015 20:19 > > > To: Markus KARG > > > Cc: openjfx-dev at openjdk.java.net > > > Subject: Re: Future of JavaFX > > > > > > Things are not different for Apache projects. Google does not accept any > > > external contributions. The Linux kernel development is very tightly > > > controlled. We should stop considering that widespread open source > > > policies > > > are only a problem with JavaFX. These policies are in place for a > > > reason. > > > > > > Herv? > > > > > > Sent from my iPhone > > > > > > > On Dec 1, 2015, at 20:13, Markus KARG wrote: > > > > > > > > I wonder why I was able to jointly assign my copyright with a lot of > > > > > > other > > > > > > > open source projects without having to sign papers, sent them in by > > > > fax, > > > > wait for a written agreement, and pray to get a JIRA account... ;-) > > > > > > > > See, I talked to a real lot of former JavaFX contributors in the past > > > > > > weeks > > > > > > > (visited some European JUGs in 2015), and *virtually everybody* told > > > > me > > > > > > that > > > > > > > he is really unsatisfied with the fact that he cannot directly file to > > > > > > JIRA > > > > > > > anymore or AT LEAST vote and comment on existing tickets. Is the > > > > JavaFX > > > > > > team > > > > > > > clear about how many contributors you lost by that policy? I really > > > > > > wonder > > > > > > > whether you see the reality there outside of Oracle. People stopped > > > > reporting bugs! This is a real problem for JavaFX. You should act. > > > > Now. > > > > > > > > -Markus > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On > > > > > > Behalf Of > > > > > > > dalibor topic > > > > Sent: Dienstag, 1. Dezember 2015 19:06 > > > > To: openjfx-dev at openjdk.java.net > > > > Subject: Re: Future of JavaFX > > > > > > > >> On 01.12.2015 18:35, Markus KARG wrote: > > > >> With respect to TeamFX, the better question is: Are there plans to > > > > > > further > > > > > > >> open the project so third party has an easier channel to contribute > > > > > > > > without > > > > > > > >> the hazzle of contributor agreements > > > > > > > > "Like many other open-source communities, the OpenJDK Community > > > > requires > > > > Contributors to jointly assign their copyright on contributed code." > > > > as > > > > http://openjdk.java.net/contribute/ wisely says. > > > > > > > > There is no good reason to change that. > > > > > > > > cheers, > > > > dalibor topic > > > > -- > > > > Dalibor Topic | Principal Product Manager > > > > Phone: +494089091214 > > > > > > | Mobile: +491737185961 > > > > > > > > > > > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > > > > > ORACLE Deutschland B.V. & Co. KG > > > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > > > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > > > > > > > Oracle is committed to developing > > > > practices and products that help protect the environment From swpalmer at gmail.com Thu Dec 3 00:35:03 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 2 Dec 2015 19:35:03 -0500 Subject: Future of JavaFX In-Reply-To: References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <003101d12c85$515718b0$f4054a10$@eu> <1622862.nWnHI9qTSB@andor> Message-ID: I didn't find it too difficult to get the form signed and submitted, but a key exchange is also a good idea. The mirror of the Mercurial repo on BitBucket also makes a lot of sense as a staging area for contributions. (So long as I can avoid dealing with the insanity of Git and its ridiculous UI.) However just as an overall point to this whole conversation... I don't believe the sky is falling. I choose JavaFX as the basis of all my GUI app. There is no crisis, the primary theme of this thread is complete FUD IMO. This thread alone does more harm to the perception of JavaFX in the community than anything Oracle has done. The main thing that prevents me from contributing to OpenJFX is time. Nothing else in the process is a deal breaker. Sure I was a bit irked when the open JavaFX Jira was moved to the more restricted OpenJDK Jira, because Jira (with proper access) is so much better than bugs.java.com. I wouldn't have a problem reporting issues through bugs.java.com though, like I did for years when reporting issues with Swing. (It turns out that I got access to the OpenJDK Jira anyway.) Quite frankly, there are very few features I would add the JavaFX. (+1 to desktop integration APIs and access to cameras though.) So I am not concerned much that the focus for Java 9 has been mostly about bug fixing. The issue I have with that is the timeframe in terms of getting those fixes in a JRE that I can ship with. A similar thing happened between JavaFX 2.x an JavaFX 8. Only a handful of issues were backported while I agonized over the fact that I had to fill my code with workarounds for issues that were already fixed in the Java 8 release that was still many months away. So the delay for Java 9 may be a benefit in terms of getting more features into JavaFX 9, but it's bad from the perspective of delaying the release of all those fixes! Perhaps if the community could help the effort to backport, some of that could be remedied. I expect a lot of the problem is the QA cycles needed to qualify the changes for release in a Java 8 update though. Scott > On Dec 2, 2015, at 6:12 PM, Mark Fortner wrote: > > I think the first hurdle is to get people to sign the CLA. Having to print > a copy, sign it, and find a fax machine or scanner to resend it seems kind > of archaic in this day and age. That said, e-signing a PDF shouldn't be > too difficult, but it would be better if it were simply a form that you > attached your public key to. This would serve 2 purposes: (1) you have a > proxy for a signature, (2) the key could be used to access the repo. > > That said, even that might be too much for people who just have a quick bug > fix that they'd like to see reviewed and merged. > > Cheers, > > Mark > > >> On Wed, Dec 2, 2015 at 4:43 PM, Florian Brunner wrote: >> >> Some time ago there actaully was a OpenJFX mirror repository on BitBucket. >> >> I'm not totally sure anymore why this was stopped. I think it needs someone >> who keeps the repositories in sync and there were some concerns that it's >> harder to control who wrote a patch. But maybe the idea with CLA signers >> only >> members would solve this issue? >> >> So I see 3 pain points being raised. >> >> 1. Signing the CLA. >> - Personally, I don't see any way around this. If there is no CLA >> then you >> end up with a project _nobody_ is in control of. >> - Basically it envolves the following steps: >> -- Download it from the website >> -- print it >> -- sign it >> -- send it off >> -- you only have to do this once >> -- you don't have to wait for Oracle to receive it to start >> working >> on the issue you like to solve >> >> Can this be presented in a way it doesn't scare people away as >> according to >> some statements it seems to do now? >> >> 2. State-of-the-art code collaboration platform. >> -- This would have to be something like GitHub or BitBucket >> -- Only CLA signers can be members of the project >> -- Someone has to be in charge to synchronize the repositories >> (probably one way only) >> -- personally I like to work with feature branches in Git but I >> think >> you can get something similar with Mercurial bookmarks. So >> --- pick an issue you would like to work on >> --- consider to announce it on this mailing list >> --- create a feature branch >> --- start pushing your changes to the feature branch >> --- other developers of the projects (all CLA signers) might chime >> in >> as they like >> --- once you think you're finished create a patch from the feature >> branch and add it to the issue or (if you don't have enough rights) send >> it to >> the mailing list >> --- take the feedback from the review, do the fixes an create >> another >> patch etc. >> >> So the main benefit would be that several developers could work on the same >> issue until it gets to a high enough qualiy state to be merged into the >> main >> repository and not requiring one developer to do it all on his/ her own. >> >> >> 3. Filing and commenting on issues >> - if you don't have enough rights, file it on bugs.java.com >> - ask on this mailing list (or ask someone you know on this mailing list >> to >> do it for you) about the corresponding issue on bugs.openjdk.java.net >> - someone from Oracle should give anyone who filed an issue that made it >> to >> bugs.openjdk.java.net the enough rights so he/ she can join on the >> discussion >> in the issue >> >> Any better way? >> >> >> -Florian >> >> Am Dienstag, 1. Dezember 2015, 17.16:46 schrieb Tomas Mikula: >>> The proposed strategy also applies to bitbucket, which does have >> mercurial >>> support ;) >>> >>> On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG >> wrote: >>>> Too bad that Github cannot fork mercurial repos. It would be >> interesting >>>> to see the real number of pull requests such a fork would gain. Maybe >>>> Dalibor is right and we would end up with zero? ;-) >>>> >>>> -Markus >>>> >>>> >>>> >>>> From: Tomas Mikula [mailto:tomas.mikula at gmail.com] >>>> Sent: Dienstag, 1. Dezember 2015 23:05 >>>> To: Markus KARG >>>> Cc: openjfx-dev at openjdk.java.net >>>> Subject: Re: Future of JavaFX >>>> >>>> >>>> >>>> The review process for external contributions does not even have to be >>>> different from the internal review process. There can be a virtual >>>> organization on GitHub called "Oracle CLA signatories". After a pull >>>> request has been reviewed, all that the OpenJFX committer has to do >> before >>>> merging is to check whether the contributor is a member of this >>>> organization. >>>> >>>> >>>> >>>> Tomas >>>> >>>> >>>> >>>> On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG >>>> wrote: >>>> >>>> We should ask ourselfs whether we want more contributions or not. We >> will >>>> not get them until we change something. Most contributors in the Open >>>> Source just want to drop a bug report or a feature or two, and >> multiplied >>>> by the number of those guys, this is a lot of stuff. Only few >> contributors >>>> are willing to stay for long time, and only for those it makes sense to >>>> have the complex rules. For example, I do not see why we cannot have a >>>> dedicated full time "Community Officer" who simply collects the >>>> contributions, reviews it, applies the needed checks and rules and all >>>> that >>>> instead of asking everybody to follow a complex process? That would >> ensure >>>> the quality, but not for the cost of losing contributors. >>>> >>>> >>>> -----Original Message----- >>>> From: Herv? Girod [mailto:herve.girod at gmail.com] >>>> Sent: Dienstag, 1. Dezember 2015 20:19 >>>> To: Markus KARG >>>> Cc: openjfx-dev at openjdk.java.net >>>> Subject: Re: Future of JavaFX >>>> >>>> Things are not different for Apache projects. Google does not accept >> any >>>> external contributions. The Linux kernel development is very tightly >>>> controlled. We should stop considering that widespread open source >>>> policies >>>> are only a problem with JavaFX. These policies are in place for a >> reason. >>>> >>>> Herv? >>>> >>>> Sent from my iPhone >>>> >>>>> On Dec 1, 2015, at 20:13, Markus KARG >> wrote: >>>>> >>>>> I wonder why I was able to jointly assign my copyright with a lot of >>>> >>>> other >>>> >>>>> open source projects without having to sign papers, sent them in by >> fax, >>>>> wait for a written agreement, and pray to get a JIRA account... ;-) >>>>> >>>>> See, I talked to a real lot of former JavaFX contributors in the past >>>> >>>> weeks >>>> >>>>> (visited some European JUGs in 2015), and *virtually everybody* told >> me >>>> >>>> that >>>> >>>>> he is really unsatisfied with the fact that he cannot directly file >> to >>>> >>>> JIRA >>>> >>>>> anymore or AT LEAST vote and comment on existing tickets. Is the >> JavaFX >>>> >>>> team >>>> >>>>> clear about how many contributors you lost by that policy? I really >>>> >>>> wonder >>>> >>>>> whether you see the reality there outside of Oracle. People stopped >>>>> reporting bugs! This is a real problem for JavaFX. You should act. >> Now. >>>>> >>>>> -Markus >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>>> >>>> Behalf Of >>>> >>>>> dalibor topic >>>>> Sent: Dienstag, 1. Dezember 2015 19:06 >>>>> To: openjfx-dev at openjdk.java.net >>>>> Subject: Re: Future of JavaFX >>>>> >>>>>> On 01.12.2015 18:35, Markus KARG wrote: >>>>>> With respect to TeamFX, the better question is: Are there plans to >>>> >>>> further >>>> >>>>>> open the project so third party has an easier channel to contribute >>>>> >>>>> without >>>>> >>>>>> the hazzle of contributor agreements >>>>> >>>>> "Like many other open-source communities, the OpenJDK Community >> requires >>>>> Contributors to jointly assign their copyright on contributed code." >> as >>>>> http://openjdk.java.net/contribute/ wisely says. >>>>> >>>>> There is no good reason to change that. >>>>> >>>>> cheers, >>>>> dalibor topic >>>>> -- >>>>> Dalibor Topic | Principal Product Manager >>>>> Phone: +494089091214 >>> >>>> > | Mobile: +491737185961 >>>> >>>>> > >>>>> >>>>> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >>>>> >>>>> ORACLE Deutschland B.V. & Co. KG >>>>> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >>>>> Registergericht: Amtsgericht M?nchen, HRA 95603 >>>>> >>>>> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >>>>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >>>>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >>>>> Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher >>>>> >>>>> Oracle is committed to developing >>>>> practices and products that help protect the environment >> >> From krueger at lesspain.de Thu Dec 3 09:49:38 2015 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Thu, 3 Dec 2015 10:49:38 +0100 Subject: Future of JavaFX In-Reply-To: <565F4A25.2090502@oracle.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <565E3B4F.6070907@oracle.com> <565F4A25.2090502@oracle.com> Message-ID: Thanks Chien and Kevin. I will recheck my issues with JDK 9 early access and report back, probably here because I cannot comment in JBS. On Wed, Dec 2, 2015 at 8:44 PM, Chien Yang wrote: > On 12/2/15, 4:46 AM, Robert Kr?ger wrote: > >> How much of a priority are quality issues, >> especially on the Mac (which clearly is a second-class citizen as far as >> JavaFX is concerned)? Are things like flashing when opening Stages, bad >> rendering performance, broken media APIs etc. an issue? >> > We have been busy fixing bugs to ensure a high quality release for 9 on > all supported platforms. Many of our developers have a Mac and it is tested > weekly. If you found a bug that is still reproducible on the JDK 9 early > access please file it [1]. We will definitely investigate it. > > [1] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report > > - Chien > -- Robert Kr?ger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com From dalibor.topic at oracle.com Thu Dec 3 12:43:47 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 3 Dec 2015 13:43:47 +0100 Subject: Future of JavaFX In-Reply-To: References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <003101d12c85$515718b0$f4054a10$@eu> <1622862.nWnHI9qTSB@andor> Message-ID: <56603903.20803@oracle.com> On 03.12.2015 01:35, Scott Palmer wrote: > The issue I have with that is the timeframe in terms of getting those fixes in a JRE that I can ship with. Assuming that you are talking about the Oracle JRE specifically, please see http://www.oracle.com/technetwork/java/javase/documentation/8u-relnotes-2225394.html for information about Bundled Patch Release (BPR) builds of JDK 8. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Dec 3 13:35:00 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 3 Dec 2015 14:35:00 +0100 Subject: Future of JavaFX In-Reply-To: <002401d12d29$2c24e6e0$846eb4a0$@eu> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <565DF71E.107@oracle.com> <001f01d12c83$74541360$5cfc3a20$@eu> <565EBDC4.5040802@oracle.com> <002401d12d29$2c24e6e0$846eb4a0$@eu> Message-ID: <56604504.5000301@oracle.com> On 02.12.2015 18:45, Markus KARG wrote: > I wouldn't bother you if I wouldn't have met those people and listened to > their ideas, BTW. One type of ideas one can regularly see in open source communities is 'someone else should do X', where X can range from 'change their workflow to suit mine', over 'add a feature or fix a bug affecting my customer', to 'pay other people to do what I tell them to do', for example. While the idea of being entitled to benefiting from other people's work is individually attractive, in open source communities allowing too much of this type of free riding attitude can cause a 'tragedy of the commons'. [1] When it comes to OpenJDK, the way it is set up to work (since its inception) to avoid that type of problems is to mostly cater to the needs of OpenJDK developers, rather then to the needs of users of downstream products. The OpenJDK processes allow and enable contributors with sufficient skills, humbleness and experience to become OpenJDK developers themselves, getting write access to corresponding parts of OpenJDK infrastructure. But contrary to what some people may think, one should not attempt to recruit the largest possible number of contributors just for the sake of attracting contributors. The best kind of open source contributors come with a purpose, rather than armed with ideas they want others to work on. On the other hand, if someone is just looking for others to work on issues they are interested in, that's fine, too. They can, for example, find Oracle's Java SE Support at [0], or in other ways attempt to arrange for others to pursue those ideas for them, for example by filing an issue or RFE on bugs.java.com, or hiring someone to implement/fix it for them. Whatever option one picks, please refrain from using this technical mailing list for non-technical discussions. [2] As a reminder, technical discussions are about code. cheers, dalibor topic [0] http://www.oracle.com/us/technologies/java/standard-edition/support/overview/index.html [1] https://www.youtube.com/watch?v=xC3J2pdVXX0 [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018320.html -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From rahman.usta.88 at gmail.com Thu Dec 3 13:51:32 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Thu, 3 Dec 2015 15:51:32 +0200 Subject: Where to sign up for bug tracker Message-ID: Hi; I want to file a bug on https://id.openjdk.java.net/console/login , but how wifll I create an account for bug tracker ? Thanks. -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From kevin.rushforth at oracle.com Thu Dec 3 13:54:28 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 03 Dec 2015 05:54:28 -0800 Subject: Where to sign up for bug tracker In-Reply-To: References: Message-ID: <56604994.7000907@oracle.com> See the OpenJFX Wiki [1] for information about reporting a bug. Application developers should file a bug at bugs.java.com [2]. -- Kevin [1] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report [2] http://bugs.java.com/ Rahman USTA wrote: > Hi; > > I want to file a bug on https://id.openjdk.java.net/console/login , but how > wifll I create an account for bug tracker ? > > Thanks. > > From rahman.usta.88 at gmail.com Thu Dec 3 14:09:17 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Thu, 3 Dec 2015 16:09:17 +0200 Subject: Where to sign up for bug tracker In-Reply-To: <56604994.7000907@oracle.com> References: <56604994.7000907@oracle.com> Message-ID: Thank you Kevin, it is a bit tiresome but ok, I filed the bug. 2015-12-03 15:54 GMT+02:00 Kevin Rushforth : > See the OpenJFX Wiki [1] for information about reporting a bug. > Application developers should file a bug at bugs.java.com [2]. > > -- Kevin > > [1] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report > [2] http://bugs.java.com/ > > > > Rahman USTA wrote: > >> Hi; >> >> I want to file a bug on https://id.openjdk.java.net/console/login , but >> how >> wifll I create an account for bug tracker ? >> >> Thanks. >> >> >> > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From murali.billa at oracle.com Thu Dec 3 15:40:46 2015 From: murali.billa at oracle.com (Murali Billa) Date: Thu, 3 Dec 2015 07:40:46 -0800 (PST) Subject: [9] review request: 8144472 [Webcore] DRT test fast/dom/HTMLInputElement/input-line-height.html fails Message-ID: <6184aab1-9aa3-4c69-8732-455704666e34@default> Hi Kevin, Alexander, Please review the fix related to DumpRenderTree CSS line-height issue. JIRA: https://bugs.openjdk.java.net/browse/JDK-8144472 Webrev: http://cr.openjdk.java.net/~ghb/murali/8144472/webrev.00/ Thanks, Murali From victor.dyakov at oracle.com Thu Dec 3 17:50:37 2015 From: victor.dyakov at oracle.com (Victor D'yakov) Date: Thu, 3 Dec 2015 09:50:37 -0800 Subject: [9] review request: 8144472 [Webcore] DRT test fast/dom/HTMLInputElement/input-line-height.html fails In-Reply-To: <6184aab1-9aa3-4c69-8732-455704666e34@default> References: <6184aab1-9aa3-4c69-8732-455704666e34@default> Message-ID: <566080ED.8090207@oracle.com> Hi Murali, Could you please share some details about issue root cause and brief description of your fix? Thanks, Victor On 03.12.2015 7:40, Murali Billa wrote: > Hi Kevin, Alexander, > > > > Please review the fix related to DumpRenderTree CSS line-height issue. > > > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8144472 > > > > > > Webrev: http://cr.openjdk.java.net/~ghb/murali/8144472/webrev.00/ > > > > Thanks, > > Murali > > > > From markus at headcrashing.eu Thu Dec 3 18:31:14 2015 From: markus at headcrashing.eu (Markus KARG) Date: Thu, 3 Dec 2015 19:31:14 +0100 Subject: Future of JavaFX In-Reply-To: References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <003101d12c85$515718b0$f4054a10$@eu> <1622862.nWnHI9qTSB@andor> Message-ID: <00f601d12df8$cb1a1ac0$614e5040$@eu> +1 It simply must be possibly for *everyone* to open tickets, comment on tickets, vote for tickets, without signing a CLA. We simply could have bylaws that say that you agree to the CLA simply by using the tracker. In Germany for example, this is possible by posting the licence agreement on the same web site and the words "By using this service you agree to this terms.". The must be people in charge reviewing small contributions and directly tell in the comments field what exactly is needed to be accepted as a contribution. Everything else will hold people back from contributing small contributions or even report bugs. -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner Sent: Donnerstag, 3. Dezember 2015 00:12 To: Florian Brunner Cc: openjfx-dev at openjdk.java.net Subject: Re: Future of JavaFX I think the first hurdle is to get people to sign the CLA. Having to print a copy, sign it, and find a fax machine or scanner to resend it seems kind of archaic in this day and age. That said, e-signing a PDF shouldn't be too difficult, but it would be better if it were simply a form that you attached your public key to. This would serve 2 purposes: (1) you have a proxy for a signature, (2) the key could be used to access the repo. That said, even that might be too much for people who just have a quick bug fix that they'd like to see reviewed and merged. Cheers, Mark On Wed, Dec 2, 2015 at 4:43 PM, Florian Brunner wrote: > Some time ago there actaully was a OpenJFX mirror repository on BitBucket. > > I'm not totally sure anymore why this was stopped. I think it needs someone > who keeps the repositories in sync and there were some concerns that it's > harder to control who wrote a patch. But maybe the idea with CLA signers > only > members would solve this issue? > > So I see 3 pain points being raised. > > 1. Signing the CLA. > - Personally, I don't see any way around this. If there is no CLA > then you > end up with a project _nobody_ is in control of. > - Basically it envolves the following steps: > -- Download it from the website > -- print it > -- sign it > -- send it off > -- you only have to do this once > -- you don't have to wait for Oracle to receive it to start > working > on the issue you like to solve > > Can this be presented in a way it doesn't scare people away as > according to > some statements it seems to do now? > > 2. State-of-the-art code collaboration platform. > -- This would have to be something like GitHub or BitBucket > -- Only CLA signers can be members of the project > -- Someone has to be in charge to synchronize the repositories > (probably one way only) > -- personally I like to work with feature branches in Git but I > think > you can get something similar with Mercurial bookmarks. So > --- pick an issue you would like to work on > --- consider to announce it on this mailing list > --- create a feature branch > --- start pushing your changes to the feature branch > --- other developers of the projects (all CLA signers) might chime > in > as they like > --- once you think you're finished create a patch from the feature > branch and add it to the issue or (if you don't have enough rights) send > it to > the mailing list > --- take the feedback from the review, do the fixes an create > another > patch etc. > > So the main benefit would be that several developers could work on the same > issue until it gets to a high enough qualiy state to be merged into the > main > repository and not requiring one developer to do it all on his/ her own. > > > 3. Filing and commenting on issues > - if you don't have enough rights, file it on bugs.java.com > - ask on this mailing list (or ask someone you know on this mailing list > to > do it for you) about the corresponding issue on bugs.openjdk.java.net > - someone from Oracle should give anyone who filed an issue that made it > to > bugs.openjdk.java.net the enough rights so he/ she can join on the > discussion > in the issue > > Any better way? > > > -Florian > > Am Dienstag, 1. Dezember 2015, 17.16:46 schrieb Tomas Mikula: > > The proposed strategy also applies to bitbucket, which does have > mercurial > > support ;) > > > > On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG > wrote: > > > Too bad that Github cannot fork mercurial repos. It would be > interesting > > > to see the real number of pull requests such a fork would gain. Maybe > > > Dalibor is right and we would end up with zero? ;-) > > > > > > -Markus > > > > > > > > > > > > From: Tomas Mikula [mailto:tomas.mikula at gmail.com] > > > Sent: Dienstag, 1. Dezember 2015 23:05 > > > To: Markus KARG > > > Cc: openjfx-dev at openjdk.java.net > > > Subject: Re: Future of JavaFX > > > > > > > > > > > > The review process for external contributions does not even have to be > > > different from the internal review process. There can be a virtual > > > organization on GitHub called "Oracle CLA signatories". After a pull > > > request has been reviewed, all that the OpenJFX committer has to do > before > > > merging is to check whether the contributor is a member of this > > > organization. > > > > > > > > > > > > Tomas > > > > > > > > > > > > On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG > > > wrote: > > > > > > We should ask ourselfs whether we want more contributions or not. We > will > > > not get them until we change something. Most contributors in the Open > > > Source just want to drop a bug report or a feature or two, and > multiplied > > > by the number of those guys, this is a lot of stuff. Only few > contributors > > > are willing to stay for long time, and only for those it makes sense to > > > have the complex rules. For example, I do not see why we cannot have a > > > dedicated full time "Community Officer" who simply collects the > > > contributions, reviews it, applies the needed checks and rules and all > > > that > > > instead of asking everybody to follow a complex process? That would > ensure > > > the quality, but not for the cost of losing contributors. > > > > > > > > > -----Original Message----- > > > From: Herv? Girod [mailto:herve.girod at gmail.com] > > > Sent: Dienstag, 1. Dezember 2015 20:19 > > > To: Markus KARG > > > Cc: openjfx-dev at openjdk.java.net > > > Subject: Re: Future of JavaFX > > > > > > Things are not different for Apache projects. Google does not accept > any > > > external contributions. The Linux kernel development is very tightly > > > controlled. We should stop considering that widespread open source > > > policies > > > are only a problem with JavaFX. These policies are in place for a > reason. > > > > > > Herv? > > > > > > Sent from my iPhone > > > > > > > On Dec 1, 2015, at 20:13, Markus KARG > wrote: > > > > > > > > I wonder why I was able to jointly assign my copyright with a lot of > > > > > > other > > > > > > > open source projects without having to sign papers, sent them in by > fax, > > > > wait for a written agreement, and pray to get a JIRA account... ;-) > > > > > > > > See, I talked to a real lot of former JavaFX contributors in the past > > > > > > weeks > > > > > > > (visited some European JUGs in 2015), and *virtually everybody* told > me > > > > > > that > > > > > > > he is really unsatisfied with the fact that he cannot directly file > to > > > > > > JIRA > > > > > > > anymore or AT LEAST vote and comment on existing tickets. Is the > JavaFX > > > > > > team > > > > > > > clear about how many contributors you lost by that policy? I really > > > > > > wonder > > > > > > > whether you see the reality there outside of Oracle. People stopped > > > > reporting bugs! This is a real problem for JavaFX. You should act. > Now. > > > > > > > > -Markus > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On > > > > > > Behalf Of > > > > > > > dalibor topic > > > > Sent: Dienstag, 1. Dezember 2015 19:06 > > > > To: openjfx-dev at openjdk.java.net > > > > Subject: Re: Future of JavaFX > > > > > > > >> On 01.12.2015 18:35, Markus KARG wrote: > > > >> With respect to TeamFX, the better question is: Are there plans to > > > > > > further > > > > > > >> open the project so third party has an easier channel to contribute > > > > > > > > without > > > > > > > >> the hazzle of contributor agreements > > > > > > > > "Like many other open-source communities, the OpenJDK Community > requires > > > > Contributors to jointly assign their copyright on contributed code." > as > > > > http://openjdk.java.net/contribute/ wisely says. > > > > > > > > There is no good reason to change that. > > > > > > > > cheers, > > > > dalibor topic > > > > -- > > > > Dalibor Topic | Principal Product Manager > > > > Phone: +494089091214 > > > > > > | Mobile: +491737185961 > > > > > > > > > > > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > > > > > ORACLE Deutschland B.V. & Co. KG > > > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > > > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > > > > > > > Oracle is committed to developing > > > > practices and products that help protect the environment > > From philip.race at oracle.com Thu Dec 3 18:39:15 2015 From: philip.race at oracle.com (Phil Race) Date: Thu, 3 Dec 2015 10:39:15 -0800 Subject: Future of JavaFX In-Reply-To: <00f601d12df8$cb1a1ac0$614e5040$@eu> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <003101d12c85$515718b0$f4054a10$@eu> <1622862.nWnHI9qTSB@andor> <00f601d12df8$cb1a1ac0$614e5040$@eu> Message-ID: <56608C53.8010802@oracle.com> As Kevin already said, you won't get anywhere by discussing that on *this* list. It is out of the control of JavaFX. It is an OpenJDK-wide policy regarding the bug tracker. You would need to take it to openjdk-discuss since it is common across all OpenJDK projects. And there is some work in progress the submission easier and to provide means to add updates. I think that may have been shared in a previous thread on this or some other list. -phil. On 12/3/2015 10:31 AM, Markus KARG wrote: > +1 > > It simply must be possibly for *everyone* to open tickets, comment on tickets, vote for tickets, without signing a CLA. We simply could have bylaws that say that you agree to the CLA simply by using the tracker. In Germany for example, this is possible by posting the licence agreement on the same web site and the words "By using this service you agree to this terms.". > > The must be people in charge reviewing small contributions and directly tell in the comments field what exactly is needed to be accepted as a contribution. > > Everything else will hold people back from contributing small contributions or even report bugs. > > -Markus > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner > Sent: Donnerstag, 3. Dezember 2015 00:12 > To: Florian Brunner > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Future of JavaFX > > I think the first hurdle is to get people to sign the CLA. Having to print > a copy, sign it, and find a fax machine or scanner to resend it seems kind > of archaic in this day and age. That said, e-signing a PDF shouldn't be > too difficult, but it would be better if it were simply a form that you > attached your public key to. This would serve 2 purposes: (1) you have a > proxy for a signature, (2) the key could be used to access the repo. > > That said, even that might be too much for people who just have a quick bug > fix that they'd like to see reviewed and merged. > > Cheers, > > Mark > > > On Wed, Dec 2, 2015 at 4:43 PM, Florian Brunner wrote: > >> Some time ago there actaully was a OpenJFX mirror repository on BitBucket. >> >> I'm not totally sure anymore why this was stopped. I think it needs someone >> who keeps the repositories in sync and there were some concerns that it's >> harder to control who wrote a patch. But maybe the idea with CLA signers >> only >> members would solve this issue? >> >> So I see 3 pain points being raised. >> >> 1. Signing the CLA. >> - Personally, I don't see any way around this. If there is no CLA >> then you >> end up with a project _nobody_ is in control of. >> - Basically it envolves the following steps: >> -- Download it from the website >> -- print it >> -- sign it >> -- send it off >> -- you only have to do this once >> -- you don't have to wait for Oracle to receive it to start >> working >> on the issue you like to solve >> >> Can this be presented in a way it doesn't scare people away as >> according to >> some statements it seems to do now? >> >> 2. State-of-the-art code collaboration platform. >> -- This would have to be something like GitHub or BitBucket >> -- Only CLA signers can be members of the project >> -- Someone has to be in charge to synchronize the repositories >> (probably one way only) >> -- personally I like to work with feature branches in Git but I >> think >> you can get something similar with Mercurial bookmarks. So >> --- pick an issue you would like to work on >> --- consider to announce it on this mailing list >> --- create a feature branch >> --- start pushing your changes to the feature branch >> --- other developers of the projects (all CLA signers) might chime >> in >> as they like >> --- once you think you're finished create a patch from the feature >> branch and add it to the issue or (if you don't have enough rights) send >> it to >> the mailing list >> --- take the feedback from the review, do the fixes an create >> another >> patch etc. >> >> So the main benefit would be that several developers could work on the same >> issue until it gets to a high enough qualiy state to be merged into the >> main >> repository and not requiring one developer to do it all on his/ her own. >> >> >> 3. Filing and commenting on issues >> - if you don't have enough rights, file it on bugs.java.com >> - ask on this mailing list (or ask someone you know on this mailing list >> to >> do it for you) about the corresponding issue on bugs.openjdk.java.net >> - someone from Oracle should give anyone who filed an issue that made it >> to >> bugs.openjdk.java.net the enough rights so he/ she can join on the >> discussion >> in the issue >> >> Any better way? >> >> >> -Florian >> >> Am Dienstag, 1. Dezember 2015, 17.16:46 schrieb Tomas Mikula: >>> The proposed strategy also applies to bitbucket, which does have >> mercurial >>> support ;) >>> >>> On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG >> wrote: >>>> Too bad that Github cannot fork mercurial repos. It would be >> interesting >>>> to see the real number of pull requests such a fork would gain. Maybe >>>> Dalibor is right and we would end up with zero? ;-) >>>> >>>> -Markus >>>> >>>> >>>> >>>> From: Tomas Mikula [mailto:tomas.mikula at gmail.com] >>>> Sent: Dienstag, 1. Dezember 2015 23:05 >>>> To: Markus KARG >>>> Cc: openjfx-dev at openjdk.java.net >>>> Subject: Re: Future of JavaFX >>>> >>>> >>>> >>>> The review process for external contributions does not even have to be >>>> different from the internal review process. There can be a virtual >>>> organization on GitHub called "Oracle CLA signatories". After a pull >>>> request has been reviewed, all that the OpenJFX committer has to do >> before >>>> merging is to check whether the contributor is a member of this >>>> organization. >>>> >>>> >>>> >>>> Tomas >>>> >>>> >>>> >>>> On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG >>>> wrote: >>>> >>>> We should ask ourselfs whether we want more contributions or not. We >> will >>>> not get them until we change something. Most contributors in the Open >>>> Source just want to drop a bug report or a feature or two, and >> multiplied >>>> by the number of those guys, this is a lot of stuff. Only few >> contributors >>>> are willing to stay for long time, and only for those it makes sense to >>>> have the complex rules. For example, I do not see why we cannot have a >>>> dedicated full time "Community Officer" who simply collects the >>>> contributions, reviews it, applies the needed checks and rules and all >>>> that >>>> instead of asking everybody to follow a complex process? That would >> ensure >>>> the quality, but not for the cost of losing contributors. >>>> >>>> >>>> -----Original Message----- >>>> From: Herv? Girod [mailto:herve.girod at gmail.com] >>>> Sent: Dienstag, 1. Dezember 2015 20:19 >>>> To: Markus KARG >>>> Cc: openjfx-dev at openjdk.java.net >>>> Subject: Re: Future of JavaFX >>>> >>>> Things are not different for Apache projects. Google does not accept >> any >>>> external contributions. The Linux kernel development is very tightly >>>> controlled. We should stop considering that widespread open source >>>> policies >>>> are only a problem with JavaFX. These policies are in place for a >> reason. >>>> Herv? >>>> >>>> Sent from my iPhone >>>> >>>>> On Dec 1, 2015, at 20:13, Markus KARG >> wrote: >>>>> I wonder why I was able to jointly assign my copyright with a lot of >>>> other >>>> >>>>> open source projects without having to sign papers, sent them in by >> fax, >>>>> wait for a written agreement, and pray to get a JIRA account... ;-) >>>>> >>>>> See, I talked to a real lot of former JavaFX contributors in the past >>>> weeks >>>> >>>>> (visited some European JUGs in 2015), and *virtually everybody* told >> me >>>> that >>>> >>>>> he is really unsatisfied with the fact that he cannot directly file >> to >>>> JIRA >>>> >>>>> anymore or AT LEAST vote and comment on existing tickets. Is the >> JavaFX >>>> team >>>> >>>>> clear about how many contributors you lost by that policy? I really >>>> wonder >>>> >>>>> whether you see the reality there outside of Oracle. People stopped >>>>> reporting bugs! This is a real problem for JavaFX. You should act. >> Now. >>>>> -Markus >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>>> Behalf Of >>>> >>>>> dalibor topic >>>>> Sent: Dienstag, 1. Dezember 2015 19:06 >>>>> To: openjfx-dev at openjdk.java.net >>>>> Subject: Re: Future of JavaFX >>>>> >>>>>> On 01.12.2015 18:35, Markus KARG wrote: >>>>>> With respect to TeamFX, the better question is: Are there plans to >>>> further >>>> >>>>>> open the project so third party has an easier channel to contribute >>>>> without >>>>> >>>>>> the hazzle of contributor agreements >>>>> "Like many other open-source communities, the OpenJDK Community >> requires >>>>> Contributors to jointly assign their copyright on contributed code." >> as >>>>> http://openjdk.java.net/contribute/ wisely says. >>>>> >>>>> There is no good reason to change that. >>>>> >>>>> cheers, >>>>> dalibor topic >>>>> -- >>>>> Dalibor Topic | Principal Product Manager >>>>> Phone: +494089091214 >>> > | Mobile: +491737185961 >>>> >>>>> > >>>>> >>>>> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >>>>> >>>>> ORACLE Deutschland B.V. & Co. KG >>>>> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >>>>> Registergericht: Amtsgericht M?nchen, HRA 95603 >>>>> >>>>> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >>>>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >>>>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >>>>> Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher >>>>> >>>>> Oracle is committed to developing >>>>> practices and products that help protect the environment >> From markus at headcrashing.eu Thu Dec 3 18:45:04 2015 From: markus at headcrashing.eu (Markus KARG) Date: Thu, 3 Dec 2015 19:45:04 +0100 Subject: Future of JavaFX In-Reply-To: <56604504.5000301@oracle.com> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <002a01d12c5e$bd44dd90$37ce98b0$@eu> <565DE174.7020604@oracle.com> <006901d12c6c$5aa88a20$0ff99e60$@eu> <565DF71E.107@oracle.com> <001f01d12c83$74541360$5cfc3a20$@eu> <565EBDC4.5040802@oracle.com> <002401d12d29$2c24e6e0$846eb4a0$@eu> <56604504.5000301@oracle.com> Message-ID: <012801d12dfa$b9948f90$2cbdaeb0$@eu> I understand all you said, but at least, let me answer to your accusations, before we stop this thread and go back to technical discussions: In fact you blaim the wrong person. Indeed am speaking for TeamFX (a group of JavaFX experts) and JUG leaders, wanting to actually help Oracle; but to do that, we need the ability to vote and comment on tickets, so we can work together with Oracle. We also want to add small contributions made by us (partly done and visible in JIRA already, but cannot get finished, due to missing JIRA accounts), but we need to have a JIRA ticket for each of it as the main communication system for the team. JIRA is essential for a team these days. Unfortunately, OpenJDK does not provide JIRA access to *Some* of us, so simply we cannot *efficiently* work together with Oracle as we have to send back-and-forth the building bricks and then wait for someone from Oracle to find the time to review it. That's the sole point. Not asking Oracle to do the work. Exactly the opposite! :-) Reagrds -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of dalibor topic Sent: Donnerstag, 3. Dezember 2015 14:35 To: openjfx-dev at openjdk.java.net Subject: Re: Future of JavaFX On 02.12.2015 18:45, Markus KARG wrote: > I wouldn't bother you if I wouldn't have met those people and listened to > their ideas, BTW. One type of ideas one can regularly see in open source communities is 'someone else should do X', where X can range from 'change their workflow to suit mine', over 'add a feature or fix a bug affecting my customer', to 'pay other people to do what I tell them to do', for example. While the idea of being entitled to benefiting from other people's work is individually attractive, in open source communities allowing too much of this type of free riding attitude can cause a 'tragedy of the commons'. [1] When it comes to OpenJDK, the way it is set up to work (since its inception) to avoid that type of problems is to mostly cater to the needs of OpenJDK developers, rather then to the needs of users of downstream products. The OpenJDK processes allow and enable contributors with sufficient skills, humbleness and experience to become OpenJDK developers themselves, getting write access to corresponding parts of OpenJDK infrastructure. But contrary to what some people may think, one should not attempt to recruit the largest possible number of contributors just for the sake of attracting contributors. The best kind of open source contributors come with a purpose, rather than armed with ideas they want others to work on. On the other hand, if someone is just looking for others to work on issues they are interested in, that's fine, too. They can, for example, find Oracle's Java SE Support at [0], or in other ways attempt to arrange for others to pursue those ideas for them, for example by filing an issue or RFE on bugs.java.com, or hiring someone to implement/fix it for them. Whatever option one picks, please refrain from using this technical mailing list for non-technical discussions. [2] As a reminder, technical discussions are about code. cheers, dalibor topic [0] http://www.oracle.com/us/technologies/java/standard-edition/support/overview /index.html [1] https://www.youtube.com/watch?v=xC3J2pdVXX0 [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018320.html -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From markus at headcrashing.eu Thu Dec 3 18:50:27 2015 From: markus at headcrashing.eu (Markus KARG) Date: Thu, 3 Dec 2015 19:50:27 +0100 Subject: Future of JavaFX In-Reply-To: <56608C53.8010802@oracle.com> References: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> <003101d12c85$515718b0$f4054a10$@eu> <1622862.nWnHI9qTSB@andor> <00f601d12df8$cb1a1ac0$614e5040$@eu> <56608C53.8010802@oracle.com> Message-ID: <015201d12dfb$7a6ba050$6f42e0f0$@eu> Agreed. -----Original Message----- From: Phil Race [mailto:philip.race at oracle.com] Sent: Donnerstag, 3. Dezember 2015 19:39 To: Markus KARG; openjfx-dev at openjdk.java.net Subject: Re: Future of JavaFX As Kevin already said, you won't get anywhere by discussing that on *this* list. It is out of the control of JavaFX. It is an OpenJDK-wide policy regarding the bug tracker. You would need to take it to openjdk-discuss since it is common across all OpenJDK projects. And there is some work in progress the submission easier and to provide means to add updates. I think that may have been shared in a previous thread on this or some other list. -phil. On 12/3/2015 10:31 AM, Markus KARG wrote: > +1 > > It simply must be possibly for *everyone* to open tickets, comment on tickets, vote for tickets, without signing a CLA. We simply could have bylaws that say that you agree to the CLA simply by using the tracker. In Germany for example, this is possible by posting the licence agreement on the same web site and the words "By using this service you agree to this terms.". > > The must be people in charge reviewing small contributions and directly tell in the comments field what exactly is needed to be accepted as a contribution. > > Everything else will hold people back from contributing small contributions or even report bugs. > > -Markus > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On > Behalf Of Mark Fortner > Sent: Donnerstag, 3. Dezember 2015 00:12 > To: Florian Brunner > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Future of JavaFX > > I think the first hurdle is to get people to sign the CLA. Having to > print a copy, sign it, and find a fax machine or scanner to resend it > seems kind of archaic in this day and age. That said, e-signing a PDF > shouldn't be too difficult, but it would be better if it were simply a > form that you attached your public key to. This would serve 2 > purposes: (1) you have a proxy for a signature, (2) the key could be used to access the repo. > > That said, even that might be too much for people who just have a > quick bug fix that they'd like to see reviewed and merged. > > Cheers, > > Mark > > > On Wed, Dec 2, 2015 at 4:43 PM, Florian Brunner wrote: > >> Some time ago there actaully was a OpenJFX mirror repository on BitBucket. >> >> I'm not totally sure anymore why this was stopped. I think it needs >> someone who keeps the repositories in sync and there were some >> concerns that it's harder to control who wrote a patch. But maybe the >> idea with CLA signers only members would solve this issue? >> >> So I see 3 pain points being raised. >> >> 1. Signing the CLA. >> - Personally, I don't see any way around this. If there is >> no CLA then you end up with a project _nobody_ is in control of. >> - Basically it envolves the following steps: >> -- Download it from the website >> -- print it >> -- sign it >> -- send it off >> -- you only have to do this once >> -- you don't have to wait for Oracle to receive it to start >> working on the issue you like to solve >> >> Can this be presented in a way it doesn't scare people away as >> according to some statements it seems to do now? >> >> 2. State-of-the-art code collaboration platform. >> -- This would have to be something like GitHub or BitBucket >> -- Only CLA signers can be members of the project >> -- Someone has to be in charge to synchronize the >> repositories (probably one way only) >> -- personally I like to work with feature branches in Git >> but I think you can get something similar with Mercurial bookmarks. >> So >> --- pick an issue you would like to work on >> --- consider to announce it on this mailing list >> --- create a feature branch >> --- start pushing your changes to the feature branch >> --- other developers of the projects (all CLA signers) might >> chime in as they like >> --- once you think you're finished create a patch from the >> feature branch and add it to the issue or (if you don't have enough >> rights) send it to the mailing list >> --- take the feedback from the review, do the fixes an create >> another patch etc. >> >> So the main benefit would be that several developers could work on >> the same issue until it gets to a high enough qualiy state to be >> merged into the main repository and not requiring one developer to do >> it all on his/ her own. >> >> >> 3. Filing and commenting on issues >> - if you don't have enough rights, file it on bugs.java.com >> - ask on this mailing list (or ask someone you know on this >> mailing list to do it for you) about the corresponding issue on >> bugs.openjdk.java.net >> - someone from Oracle should give anyone who filed an issue that >> made it to bugs.openjdk.java.net the enough rights so he/ she can >> join on the discussion in the issue >> >> Any better way? >> >> >> -Florian >> >> Am Dienstag, 1. Dezember 2015, 17.16:46 schrieb Tomas Mikula: >>> The proposed strategy also applies to bitbucket, which does have >> mercurial >>> support ;) >>> >>> On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG >> wrote: >>>> Too bad that Github cannot fork mercurial repos. It would be >> interesting >>>> to see the real number of pull requests such a fork would gain. >>>> Maybe Dalibor is right and we would end up with zero? ;-) >>>> >>>> -Markus >>>> >>>> >>>> >>>> From: Tomas Mikula [mailto:tomas.mikula at gmail.com] >>>> Sent: Dienstag, 1. Dezember 2015 23:05 >>>> To: Markus KARG >>>> Cc: openjfx-dev at openjdk.java.net >>>> Subject: Re: Future of JavaFX >>>> >>>> >>>> >>>> The review process for external contributions does not even have to >>>> be different from the internal review process. There can be a >>>> virtual organization on GitHub called "Oracle CLA signatories". >>>> After a pull request has been reviewed, all that the OpenJFX >>>> committer has to do >> before >>>> merging is to check whether the contributor is a member of this >>>> organization. >>>> >>>> >>>> >>>> Tomas >>>> >>>> >>>> >>>> On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG >>>> >>>> wrote: >>>> >>>> We should ask ourselfs whether we want more contributions or not. >>>> We >> will >>>> not get them until we change something. Most contributors in the >>>> Open Source just want to drop a bug report or a feature or two, and >> multiplied >>>> by the number of those guys, this is a lot of stuff. Only few >> contributors >>>> are willing to stay for long time, and only for those it makes >>>> sense to have the complex rules. For example, I do not see why we >>>> cannot have a dedicated full time "Community Officer" who simply >>>> collects the contributions, reviews it, applies the needed checks >>>> and rules and all that instead of asking everybody to follow a >>>> complex process? That would >> ensure >>>> the quality, but not for the cost of losing contributors. >>>> >>>> >>>> -----Original Message----- >>>> From: Herv? Girod [mailto:herve.girod at gmail.com] >>>> Sent: Dienstag, 1. Dezember 2015 20:19 >>>> To: Markus KARG >>>> Cc: openjfx-dev at openjdk.java.net >>>> Subject: Re: Future of JavaFX >>>> >>>> Things are not different for Apache projects. Google does not >>>> accept >> any >>>> external contributions. The Linux kernel development is very >>>> tightly controlled. We should stop considering that widespread open >>>> source policies are only a problem with JavaFX. These policies are >>>> in place for a >> reason. >>>> Herv? >>>> >>>> Sent from my iPhone >>>> >>>>> On Dec 1, 2015, at 20:13, Markus KARG >> wrote: >>>>> I wonder why I was able to jointly assign my copyright with a lot >>>>> of >>>> other >>>> >>>>> open source projects without having to sign papers, sent them in >>>>> by >> fax, >>>>> wait for a written agreement, and pray to get a JIRA account... >>>>> ;-) >>>>> >>>>> See, I talked to a real lot of former JavaFX contributors in the >>>>> past >>>> weeks >>>> >>>>> (visited some European JUGs in 2015), and *virtually everybody* >>>>> told >> me >>>> that >>>> >>>>> he is really unsatisfied with the fact that he cannot directly >>>>> file >> to >>>> JIRA >>>> >>>>> anymore or AT LEAST vote and comment on existing tickets. Is the >> JavaFX >>>> team >>>> >>>>> clear about how many contributors you lost by that policy? I >>>>> really >>>> wonder >>>> >>>>> whether you see the reality there outside of Oracle. People >>>>> stopped reporting bugs! This is a real problem for JavaFX. You should act. >> Now. >>>>> -Markus >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>>> Behalf Of >>>> >>>>> dalibor topic >>>>> Sent: Dienstag, 1. Dezember 2015 19:06 >>>>> To: openjfx-dev at openjdk.java.net >>>>> Subject: Re: Future of JavaFX >>>>> >>>>>> On 01.12.2015 18:35, Markus KARG wrote: >>>>>> With respect to TeamFX, the better question is: Are there plans >>>>>> to >>>> further >>>> >>>>>> open the project so third party has an easier channel to >>>>>> contribute >>>>> without >>>>> >>>>>> the hazzle of contributor agreements >>>>> "Like many other open-source communities, the OpenJDK Community >> requires >>>>> Contributors to jointly assign their copyright on contributed code." >> as >>>>> http://openjdk.java.net/contribute/ wisely says. >>>>> >>>>> There is no good reason to change that. >>>>> >>>>> cheers, >>>>> dalibor topic >>>>> -- >>>>> Dalibor Topic | Principal Product Manager >>>>> Phone: +494089091214 >>> > | Mobile: +491737185961 >>>> >>>> >>>>> > >>>>> >>>>> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >>>>> >>>>> ORACLE Deutschland B.V. & Co. KG >>>>> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >>>>> Registergericht: Amtsgericht M?nchen, HRA 95603 >>>>> >>>>> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >>>>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >>>>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >>>>> Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher >>>>> >>>>> Oracle is committed to >>>>> developing practices and products that help protect the >>>>> environment >> From David.Hill at Oracle.com Thu Dec 3 20:05:27 2015 From: David.Hill at Oracle.com (David Hill) Date: Thu, 03 Dec 2015 15:05:27 -0500 Subject: App freezing on Linux In-Reply-To: References: Message-ID: <5660A087.7010708@Oracle.com> On 12/2/15, 3:29 AM, Bryan Buchanan wrote: > I have a customer testing an FX app and more often than not, if the app is > left open for a while (20 minutes or so), either the mouse ceases to work, > or if it does work, when you click a field, or do something that should > re-paint the window, the whole FX window goes totally grey and the app > "disappears". "disappears" would seem to indicate that the app has failed in some nasty fashion. The obvious question is if there is anything on the console/command line, or if there is any java crash dump in the launch directory (usually something like hs*.log). If you have an indication that this is happening (mouse dying for example), then you try to force a jvm dump. The way I normally do it is to type ctrl-\ in the terminal window that is running the java command. The command line 'kill -QUIT " or "kill -3 " can also do this. In this case the dump goes to stdout, so you need something to capture this to a file. For this I tend to do something like: java 2>&1 | tee my_log.txt This also grabs stderr as a bonus. I suspect that there is something going on that is kicking to application thread main loop - something we try to protect against. If you can capture a decent log, file a bug against it and I will likely be the one to root around in it to see if I can find anything that helps (there is a lot of stuff in one of those logs and it takes a bit to learn how to untangle one). Dave > > I've tried starting with "-Dprism.verbose=true -Dprism.order=sw" and > without these options, and it seems to make no difference. > > The system is Xubuntu 14.0.43, kernel 3.13.0-71 running on a Gigabyte > Brix, and Java 64 bit build 1.8.0_60-b27. I don't have this hardware in my > office, but have run up a system with the same OS, kernel and Java, and > cannot re-produce the problem. > > Are the any other command line switches, or debug flags that I can set to > try and get a handle on why this is happening ? > > (Hope this is the right list for issues like this). -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From murali.billa at oracle.com Fri Dec 4 08:24:52 2015 From: murali.billa at oracle.com (Murali Billa) Date: Fri, 4 Dec 2015 00:24:52 -0800 (PST) Subject: [9] review request: 8144472 [Webcore] DRT test fast/dom/HTMLInputElement/input-line-height.html fails In-Reply-To: <566080ED.8090207@oracle.com> References: <6184aab1-9aa3-4c69-8732-455704666e34@default> <566080ED.8090207@oracle.com> Message-ID: <611d5b2b-22f2-4dc7-9aea-2ad01d1c791b@default> Hi, Root Cause: fast/dom/HTMLInputElement/input-line-height.html" file is introduced by the webkit changeset "http://trac.webkit.org/changeset/155324. This changeset is reverted in webkit revision 169780 ( "http://trac.webkit.org/changeset/169780" -- Japanese text in Google search is rendered too low and clipped) as patch set 155324 is causing regression. Description of Fix: Revert the webkit patch set 155324 and the associated layout test cases (input-line-height.html, input-line-height-expected.txt and placeholder-position-expected.txt).Also reverted the line-height which is introduced in html.css. Thanks, Murali -----Original Message----- From: Victor D'yakov Sent: Thursday, December 03, 2015 11:21 PM To: Murali Billa; Alexander Zvegintsev; Kevin Rushforth; Guru Hb; Arunprasad Rajkumar Cc: openjfx-dev at openjdk.java.net Subject: Re: [9] review request: 8144472 [Webcore] DRT test fast/dom/HTMLInputElement/input-line-height.html fails Hi Murali, Could you please share some details about issue root cause and brief description of your fix? Thanks, Victor On 03.12.2015 7:40, Murali Billa wrote: > Hi Kevin, Alexander, > > > > Please review the fix related to DumpRenderTree CSS line-height issue. > > > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8144472 > > > > > > Webrev: http://cr.openjdk.java.net/~ghb/murali/8144472/webrev.00/ > > > > Thanks, > > Murali > > > > From rahman.usta.88 at gmail.com Fri Dec 4 09:58:13 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Fri, 4 Dec 2015 11:58:13 +0200 Subject: Where to sign up for bug tracker In-Reply-To: References: <56604994.7000907@oracle.com> Message-ID: Hey Kevin; I filed the bug, where will I follow the review process ? JI-9027150 Thanks. 2015-12-03 16:09 GMT+02:00 Rahman USTA : > Thank you Kevin, it is a bit tiresome but ok, I filed the bug. > > 2015-12-03 15:54 GMT+02:00 Kevin Rushforth : > >> See the OpenJFX Wiki [1] for information about reporting a bug. >> Application developers should file a bug at bugs.java.com [2]. >> >> -- Kevin >> >> [1] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report >> [2] http://bugs.java.com/ >> >> >> >> Rahman USTA wrote: >> >>> Hi; >>> >>> I want to file a bug on https://id.openjdk.java.net/console/login , but >>> how >>> wifll I create an account for bug tracker ? >>> >>> Thanks. >>> >>> >>> >> > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From anthony.vanelverdinghe at gmail.com Fri Dec 4 11:41:22 2015 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Fri, 4 Dec 2015 12:41:22 +0100 Subject: Where to sign up for bug tracker In-Reply-To: References: <56604994.7000907@oracle.com> Message-ID: Hi Rahman You can follow your bug by using the following URL: https://bugs.openjdk.java.net/browse/JI-9027150 The JI (Java Incidents) project is not publicly visible, so this will give you the OpenJDK Log In page for now. However, as soon as a JDK issue is created for your report, this same URL will redirect you to the appropriate JDK issue. For more information, please refer to this page: https://wiki.openjdk.java.net/display/general/JBS+Overview Kind regards, Anthony 2015-12-04 10:58 GMT+01:00 Rahman USTA : > Hey Kevin; > > I filed the bug, where will I follow the review process ? JI-9027150 > > Thanks. > > 2015-12-03 16:09 GMT+02:00 Rahman USTA : > > > Thank you Kevin, it is a bit tiresome but ok, I filed the bug. > > > > 2015-12-03 15:54 GMT+02:00 Kevin Rushforth : > > > >> See the OpenJFX Wiki [1] for information about reporting a bug. > >> Application developers should file a bug at bugs.java.com [2]. > >> > >> -- Kevin > >> > >> [1] > https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report > >> [2] http://bugs.java.com/ > >> > >> > >> > >> Rahman USTA wrote: > >> > >>> Hi; > >>> > >>> I want to file a bug on https://id.openjdk.java.net/console/login , > but > >>> how > >>> wifll I create an account for bug tracker ? > >>> > >>> Thanks. > >>> > >>> > >>> > >> > > > > > > -- > > Rahman USTA > > Istanbul JUG > > https://github.com/rahmanusta > > > > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta > From rahman.usta.88 at gmail.com Fri Dec 4 11:52:41 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Fri, 4 Dec 2015 13:52:41 +0200 Subject: Where to sign up for bug tracker In-Reply-To: References: <56604994.7000907@oracle.com> Message-ID: Thank you Anthony; I think before/after of bug report process is not clear. I don't know who manages the bug report system but, does anyone think to improve it? I'll think twice while sending a bug report again. Thanks. 2015-12-04 13:41 GMT+02:00 Anthony Vanelverdinghe < anthony.vanelverdinghe at gmail.com>: > Hi Rahman > > You can follow your bug by using the following URL: > https://bugs.openjdk.java.net/browse/JI-9027150 > The JI (Java Incidents) project is not publicly visible, so this will give > you the OpenJDK Log In page for now. However, as soon as a JDK issue is > created for your report, this same URL will redirect you to the appropriate > JDK issue. > For more information, please refer to this page: > https://wiki.openjdk.java.net/display/general/JBS+Overview > > Kind regards, > Anthony > > 2015-12-04 10:58 GMT+01:00 Rahman USTA : > >> Hey Kevin; >> >> I filed the bug, where will I follow the review process ? JI-9027150 >> >> Thanks. >> >> 2015-12-03 16:09 GMT+02:00 Rahman USTA : >> >> > Thank you Kevin, it is a bit tiresome but ok, I filed the bug. >> > >> > 2015-12-03 15:54 GMT+02:00 Kevin Rushforth > >: >> > >> >> See the OpenJFX Wiki [1] for information about reporting a bug. >> >> Application developers should file a bug at bugs.java.com [2]. >> >> >> >> -- Kevin >> >> >> >> [1] >> https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report >> >> [2] http://bugs.java.com/ >> >> >> >> >> >> >> >> Rahman USTA wrote: >> >> >> >>> Hi; >> >>> >> >>> I want to file a bug on https://id.openjdk.java.net/console/login , >> but >> >>> how >> >>> wifll I create an account for bug tracker ? >> >>> >> >>> Thanks. >> >>> >> >>> >> >>> >> >> >> > >> > >> > -- >> > Rahman USTA >> > Istanbul JUG >> > https://github.com/rahmanusta >> > >> >> >> >> -- >> Rahman USTA >> Istanbul JUG >> https://github.com/rahmanusta >> > > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From dmitry.cherepanov at oracle.com Fri Dec 4 12:31:57 2015 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 4 Dec 2015 07:31:57 -0500 Subject: [9] Review request for 8144619: [packager] GetSystemJRE fails after changes for new version string Message-ID: <566187BD.9000306@oracle.com> Chris, Kevin, Please review the following fix https://bugs.openjdk.java.net/browse/JDK-8144619 http://cr.openjdk.java.net/~dcherepanov/8144619/webrev.v0/ Thanks, Dmitry From kevin.rushforth at oracle.com Fri Dec 4 13:16:05 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 04 Dec 2015 05:16:05 -0800 Subject: Where to sign up for bug tracker In-Reply-To: References: <56604994.7000907@oracle.com> Message-ID: <56619215.80802@oracle.com> The Java incident team reviews incoming bugs and transfers them to the JDK project within one week if there is enough information to reproduce it. Otherwise, they will contact you with a request for more information. -- Kevin Rahman USTA wrote: > Hey Kevin; > > I filed the bug, where will I follow the review process ? JI-9027150 > > Thanks. > > 2015-12-03 16:09 GMT+02:00 Rahman USTA >: > > Thank you Kevin, it is a bit tiresome but ok, I filed the bug. > > 2015-12-03 15:54 GMT+02:00 Kevin Rushforth > >: > > See the OpenJFX Wiki [1] for information about reporting a > bug. Application developers should file a bug at bugs.java.com > [2]. > > -- Kevin > > [1] > https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report > [2] http://bugs.java.com/ > > > > Rahman USTA wrote: > > Hi; > > I want to file a bug on > https://id.openjdk.java.net/console/login , but how > wifll I create an account for bug tracker ? > > Thanks. > > > > > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta > > > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta From rahman.usta.88 at gmail.com Fri Dec 4 13:18:53 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Fri, 4 Dec 2015 15:18:53 +0200 Subject: Where to sign up for bug tracker In-Reply-To: <56619215.80802@oracle.com> References: <56604994.7000907@oracle.com> <56619215.80802@oracle.com> Message-ID: Thanks 4 Ara 2015 15:16 tarihinde "Kevin Rushforth" yazd?: > The Java incident team reviews incoming bugs and transfers them to the JDK > project within one week if there is enough information to reproduce it. > Otherwise, they will contact you with a request for more information. > > -- Kevin > > > Rahman USTA wrote: > > Hey Kevin; > > I filed the bug, where will I follow the review process ? JI-9027150 > > Thanks. > > 2015-12-03 16:09 GMT+02:00 Rahman USTA : > >> Thank you Kevin, it is a bit tiresome but ok, I filed the bug. >> >> 2015-12-03 15:54 GMT+02:00 Kevin Rushforth : >> >>> See the OpenJFX Wiki [1] for information about reporting a bug. >>> Application developers should file a bug at bugs.java.com [2]. >>> >>> -- Kevin >>> >>> [1] >>> https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report >>> [2] http://bugs.java.com/ >>> >>> >>> >>> Rahman USTA wrote: >>> >>>> Hi; >>>> >>>> I want to file a bug on https://id.openjdk.java.net/console/login , >>>> but how >>>> wifll I create an account for bug tracker ? >>>> >>>> Thanks. >>>> >>>> >>>> >>> >> >> >> -- >> Rahman USTA >> Istanbul JUG >> https://github.com/rahmanusta >> > > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta > > From kevin.rushforth at oracle.com Fri Dec 4 13:26:57 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 04 Dec 2015 05:26:57 -0800 Subject: Where to sign up for bug tracker In-Reply-To: References: <56604994.7000907@oracle.com> Message-ID: <566194A1.9020908@oracle.com> There are efforts underway to improve the process and make it more more transparent. Also, if you need to provide additional information, you can e-mail me directly and I will add it to the bug report. -- Kevin Rahman USTA wrote: > Thank you Anthony; > > I think before/after of bug report process is not clear. I don't know > who manages the bug report system but, does anyone think to improve > it? I'll think twice while sending a bug report again. > > Thanks. > > 2015-12-04 13:41 GMT+02:00 Anthony Vanelverdinghe > >: > > Hi Rahman > > You can follow your bug by using the following URL: > https://bugs.openjdk.java.net/browse/JI-9027150 > The JI (Java Incidents) project is not publicly visible, so this > will give you the OpenJDK Log In page for now. However, as soon as > a JDK issue is created for your report, this same URL will > redirect you to the appropriate JDK issue. > For more information, please refer to this page: > https://wiki.openjdk.java.net/display/general/JBS+Overview > > Kind regards, > Anthony > > 2015-12-04 10:58 GMT+01:00 Rahman USTA >: > > Hey Kevin; > > I filed the bug, where will I follow the review process ? > JI-9027150 > > Thanks. > > 2015-12-03 16:09 GMT+02:00 Rahman USTA > >: > > > Thank you Kevin, it is a bit tiresome but ok, I filed the bug. > > > > 2015-12-03 15:54 GMT+02:00 Kevin Rushforth > >: > > > >> See the OpenJFX Wiki [1] for information about reporting a bug. > >> Application developers should file a bug at bugs.java.com > [2]. > >> > >> -- Kevin > >> > >> [1] > https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report > >> [2] http://bugs.java.com/ > >> > >> > >> > >> Rahman USTA wrote: > >> > >>> Hi; > >>> > >>> I want to file a bug on > https://id.openjdk.java.net/console/login , but > >>> how > >>> wifll I create an account for bug tracker ? > >>> > >>> Thanks. > >>> > >>> > >>> > >> > > > > > > -- > > Rahman USTA > > Istanbul JUG > > https://github.com/rahmanusta > > > > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta > > > > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta From vadim.pakhnushev at oracle.com Fri Dec 4 16:08:13 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 4 Dec 2015 19:08:13 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <5661BA6D.7050400@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From victor.dyakov at oracle.com Fri Dec 4 16:58:34 2015 From: victor.dyakov at oracle.com (Victor D'yakov) Date: Fri, 4 Dec 2015 08:58:34 -0800 Subject: [9] review request: 8144472 [Webcore] DRT test fast/dom/HTMLInputElement/input-line-height.html fails In-Reply-To: <611d5b2b-22f2-4dc7-9aea-2ad01d1c791b@default> References: <6184aab1-9aa3-4c69-8732-455704666e34@default> <566080ED.8090207@oracle.com> <611d5b2b-22f2-4dc7-9aea-2ad01d1c791b@default> Message-ID: <5661C63A.1010700@oracle.com> Thanks Murali, That is clear now. Victor On 04.12.2015 0:24, Murali Billa wrote: > Hi, > > Root Cause: > > fast/dom/HTMLInputElement/input-line-height.html" file is introduced by the webkit changeset "http://trac.webkit.org/changeset/155324. > This changeset is reverted in webkit revision 169780 ( "http://trac.webkit.org/changeset/169780" -- Japanese text in Google search is rendered too low and clipped) as patch set 155324 is causing regression. > > Description of Fix: > > Revert the webkit patch set 155324 and the associated layout test cases (input-line-height.html, input-line-height-expected.txt and placeholder-position-expected.txt).Also reverted the line-height which is introduced in html.css. > > Thanks, > Murali > > > -----Original Message----- > From: Victor D'yakov > Sent: Thursday, December 03, 2015 11:21 PM > To: Murali Billa; Alexander Zvegintsev; Kevin Rushforth; Guru Hb; Arunprasad Rajkumar > Cc: openjfx-dev at openjdk.java.net > Subject: Re: [9] review request: 8144472 [Webcore] DRT test fast/dom/HTMLInputElement/input-line-height.html fails > > > Hi Murali, > > Could you please share some details about issue root cause and brief description of your fix? > > Thanks, > Victor > > On 03.12.2015 7:40, Murali Billa wrote: >> Hi Kevin, Alexander, >> >> >> >> Please review the fix related to DumpRenderTree CSS line-height issue. >> >> >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8144472 >> >> >> >> >> >> Webrev: http://cr.openjdk.java.net/~ghb/murali/8144472/webrev.00/ >> >> >> >> Thanks, >> >> Murali >> >> >> >> From markus at headcrashing.eu Sat Dec 5 08:56:36 2015 From: markus at headcrashing.eu (Markus KARG) Date: Sat, 5 Dec 2015 09:56:36 +0100 Subject: Future of JavaFX In-Reply-To: <565E3B4F.6070907@oracle.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <565E3B4F.6070907@oracle.com> Message-ID: <007401d12f3a$d92738d0$8b75aa70$@eu> JavaFX support for multi-resolution images is really a killer feature, as it simply is ridiculous how small images render on HiDPI that are scaled for LowDPI. For JDK 10, I'd kindly ask to review the list of essentials that I sent you some months back by personal mail. -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Mittwoch, 2. Dezember 2015 01:29 To: openjfx-dev at openjdk.java.net Subject: Re: Future of JavaFX Just to chime in on a couple of points that have been raised in this discussion... * We are interested in working with the OpenJFX community to improve JavaFX. In particular: if you find a bug, file it (via bugs.java.com if you don't have a JBS account); if you want to contribute a patch to fix the bug, we'd love to review it; if you have an idea for an improvement, file it as an RFE (enhancement) and start up a thread on the mailing list. Larger features need a JEP, but smaller improvements do not. Please be aware that as part of the OpenJDK community, we are bound by the processes of the OpenJDK, including the need for a signed OCA in order to contribute, and before you can get a JBS account. If you are dissatisfied with those processes and policies, then I invite you to discuss it on the discuss at openjdk.java.net alias, and not here. * While we aren't planning a huge number of features in JDK 9, we are delivering some interesting improvements. Jigsaw is the big release driver and most of our effort on JavaFX is to align with that. For those of you who weren't at JavaOne, here is a list of things that are currently planned for JDK 9: - A modularized JavaFX (into 6 core modules + deploy, swing interop, swt interop) - JEP 253 -- Control Skins & additional CSS APIs (proper support for third-party controls) - High DPI enhancements (full support on Windows; add support for Linux) - Public API for commonly used methods from internal packages: * Nested Event Loop * Pulse Listener * Platform Startup * Text API (HitTest, etc) * Static utility functions (under investigation) - New versions of WebKit and GStreamer And here is an incomplete list of things we are thinking about for after JDK 9, possibly in an update release. In fact, the recently proposed JDK 9 slip [1] makes it possible to consider pulling a few of them into JDK 9, so let us know which ones you consider most important: - Provide a JavaFX equivalent for JEP 272 / AWT ?Desktop? API - Make UI Control Behaviors public - UI Control Actions API - Public Focus Traversal API - JavaFX support for multi-resolution images - Draggable tabs - Image IO -- Kevin [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html From swpalmer at gmail.com Sun Dec 6 02:29:27 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 5 Dec 2015 21:29:27 -0500 Subject: JavaFX on Raspberry Pi Message-ID: I seem to recall that the Arm builds of Java 8 no longer include JavaFX. I just installed 8u65 on my Raspberry Pi and that does in fact appear to be the case. The web page https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+the+Raspberry+Pi was last updated in June and it implies that JavaFX is included in the Java 8 Arm build. Where do I find the current instructions for getting JavaFX onto a Raspberry Pi? Is there anything pre-built available, or am I forced to build it myself with the instructions here: https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float ? I?m using a Mac, and the instructions say that mainly Linux is used to cross-build for Arm, so hopefully I won?t get stuck in build hell :-) I also noticed that JavaME builds include the Device I/O API (http://docs.oracle.com/javame/8.0/api/dio/api/index.html) Is it possible to use these APIs and JavaFX on a Raspberry Pi at the same time? Can the Device I/O libraries (.jar and .so) simply be copied over from a JavaME install to a JavaSE install? Do Java 9 modules help with any of that? Regards, Scott From jonathan.giles at oracle.com Sun Dec 6 03:00:04 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sun, 06 Dec 2015 16:00:04 +1300 Subject: JavaFX on Raspberry Pi In-Reply-To: References: Message-ID: I've not tested myself, but this might help: http://gluonhq.com/gluon-supports-javafx-embedded-binary-builds-now-available/ -- Jonathan Sent from a touch device. Please excuse my brevity. On 6 December 2015 15:29:27 GMT+13:00, Scott Palmer wrote: >I seem to recall that the Arm builds of Java 8 no longer include >JavaFX. I just installed 8u65 on my Raspberry Pi and that does in fact >appear to be the case. > >The web page >https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+the+Raspberry+Pi >was last updated in June and it implies that JavaFX is included in the >Java 8 Arm build. Where do I find the current instructions for getting >JavaFX onto a Raspberry Pi? > >Is there anything pre-built available, or am I forced to build it >myself with the instructions here: >https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float >? > >I?m using a Mac, and the instructions say that mainly Linux is used to >cross-build for Arm, so hopefully I won?t get stuck in build hell :-) > >I also noticed that JavaME builds include the Device I/O API >(http://docs.oracle.com/javame/8.0/api/dio/api/index.html) >Is it possible to use these APIs and JavaFX on a Raspberry Pi at the >same time? Can the Device I/O libraries (.jar and .so) simply be >copied over from a JavaME install to a JavaSE install? Do Java 9 >modules help with any of that? > > >Regards, > >Scott From swpalmer at gmail.com Sun Dec 6 04:37:37 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 5 Dec 2015 23:37:37 -0500 Subject: JavaFX on Raspberry Pi In-Reply-To: References: Message-ID: Thanks, that worked. Now I have to see how easily I can get he Device I/O stuff working. If I'm lucky, I might even get the camera writing into a WritableImage. Cheers, Scott > On Dec 5, 2015, at 10:00 PM, Jonathan Giles wrote: > > I've not tested myself, but this might help: > > http://gluonhq.com/gluon-supports-javafx-embedded-binary-builds-now-available/ > > -- Jonathan > Sent from a touch device. Please excuse my brevity. > >> On 6 December 2015 15:29:27 GMT+13:00, Scott Palmer wrote: >> I seem to recall that the Arm builds of Java 8 no longer include JavaFX. I just installed 8u65 on my Raspberry Pi and that does in fact appear to be the case. >> >> The web page https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+the+Raspberry+Pi was last updated in June and it implies that JavaFX is included in the Java 8 Arm build. Where do I find the current instructions for getting JavaFX onto a Raspberry Pi? >> >> Is there anything pre-built available, or am I forced to build it myself with the instructions here: https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float ? >> >> I?m using a Mac, and the instructions say that mainly Linux is used to cross-build for Arm, so hopefully I won?t get stuck in build hell :-) >> >> I also noticed that JavaME builds include the Device I/O API (http://docs.oracle.com/javame/8.0/api/dio/api/index.html) >> Is it possible to use these APIs and JavaFX on a Raspberry Pi at the same time? Can the Device I/O libraries (.jar and .so) simply be copied over from a JavaME install to a JavaSE install? Do Java 9 modules help with any of that? >> >> >> Regards, >> >> Scott From chris at chrisnewland.com Sun Dec 6 11:10:16 2015 From: chris at chrisnewland.com (Chris Newland) Date: Sun, 6 Dec 2015 11:10:16 +0000 Subject: JavaFX on Raspberry Pi In-Reply-To: References: Message-ID: Hi Scott, If you don't mind the bleeding edge I publish OpenJFX nightlies here for x86 (Linux and OSX) and ARM (Pi etc) http://108.61.191.178/ They just unzip over your existing JDK/JRE. Cheers, Chris Sent from my iPhone > On 6 Dec 2015, at 02:29, Scott Palmer wrote: > > I seem to recall that the Arm builds of Java 8 no longer include JavaFX. I just installed 8u65 on my Raspberry Pi and that does in fact appear to be the case. > > The web page https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+the+Raspberry+Pi was last updated in June and it implies that JavaFX is included in the Java 8 Arm build. Where do I find the current instructions for getting JavaFX onto a Raspberry Pi? > > Is there anything pre-built available, or am I forced to build it myself with the instructions here: https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float ? > > I?m using a Mac, and the instructions say that mainly Linux is used to cross-build for Arm, so hopefully I won?t get stuck in build hell :-) > > I also noticed that JavaME builds include the Device I/O API (http://docs.oracle.com/javame/8.0/api/dio/api/index.html) > Is it possible to use these APIs and JavaFX on a Raspberry Pi at the same time? Can the Device I/O libraries (.jar and .so) simply be copied over from a JavaME install to a JavaSE install? Do Java 9 modules help with any of that? > > > Regards, > > Scott From bryanb at webbtide.com Mon Dec 7 08:12:51 2015 From: bryanb at webbtide.com (Bryan Buchanan) Date: Mon, 7 Dec 2015 18:12:51 +1000 Subject: App freezing on Linux Message-ID: Found out what the problem was - I'm using Thrift for RPC, and was initialising the underlying Thrift socket with a connection timeout of zero (i.e. infinite). When there was a network disconnection, it appeared the FX UI thread was getting starved and the app freezes. All good now, and FX is fine. From kevin.rushforth at oracle.com Mon Dec 7 15:58:25 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 07 Dec 2015 07:58:25 -0800 Subject: App freezing on Linux In-Reply-To: References: Message-ID: <5665ACA1.40603@oracle.com> Good to hear. -- Kevin Bryan Buchanan wrote: > Found out what the problem was - I'm using Thrift for RPC, and was > initialising the underlying Thrift socket with a connection timeout of zero > (i.e. infinite). When there was a network disconnection, it appeared the FX > UI thread was getting starved and the app freezes. All good now, and FX is > fine. > From David.Hill at Oracle.com Mon Dec 7 17:45:18 2015 From: David.Hill at Oracle.com (David Hill) Date: Mon, 07 Dec 2015 12:45:18 -0500 Subject: App freezing on Linux In-Reply-To: References: Message-ID: <5665C5AE.2020402@Oracle.com> On 12/7/15, 3:12 AM, Bryan Buchanan wrote: > Found out what the problem was - I'm using Thrift for RPC, and was > initialising the underlying Thrift socket with a connection timeout of zero > (i.e. infinite). When there was a network disconnection, it appeared the FX > UI thread was getting starved and the app freezes. All good now, and FX is > fine. Glad to hear you found your issue. Sounds like a good place to use a worker thread to get that work off the UI thread. In fact, I happen to have this handy link to documentation on it :-) https://docs.oracle.com/javase/8/javafx/interoperability-tutorial/concurrency.htm Dave -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From kevin.rushforth at oracle.com Mon Dec 7 20:59:54 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 07 Dec 2015 12:59:54 -0800 Subject: 9-dev unlocked following sanity testing Message-ID: <5665F34A.3060003@oracle.com> From chien.yang at oracle.com Mon Dec 7 23:04:21 2015 From: chien.yang at oracle.com (Chien Yang) Date: Mon, 07 Dec 2015 15:04:21 -0800 Subject: Code Review Request For JDK-8090866: Mac GL APIs do not need to be looked up Message-ID: <56661075.3060903@oracle.com> Hi Kevin, Please review the proposed fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8090866 webrev: http://cr.openjdk.java.net/~ckyang/JDK-8090866/webrev.00/ Thanks, - Chien From guru.hb at oracle.com Tue Dec 8 10:37:54 2015 From: guru.hb at oracle.com (Guru Hb) Date: Tue, 8 Dec 2015 02:37:54 -0800 (PST) Subject: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time In-Reply-To: <1bee96ff-3087-4689-82ab-54d3ba21053d@default> References: <1bee96ff-3087-4689-82ab-54d3ba21053d@default> Message-ID: <4ce1d14c-ebdf-44d2-a84e-6d9f8e75bc15@default> Hi Arunprasad, Alexander and Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/ Webrev : http://cr.openjdk.java.net/~arapte/ghb/8143894/webrev.01/ (Due to permission bit corrupted to my ghb at cr.openjdk.java.net account I am sending this patch from ~arapte account) Fix updated with regression test Thanks, Guru -----Original Message----- From: Guru Hb Sent: Tuesday, December 01, 2015 10:29 AM To: Arunprasad Rajkumar; Alexander Zvegintsev; Kevin Rushforth Cc: openjfx-dev at openjdk.java.net Subject: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time Hi Arunprasad, Alexander & Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/ Webrev : http://cr.openjdk.java.net/~ghb/8143894/webrev.00 Tested on Windows and Linux (both 64 bit). Thnaks, Guru From kacper.bostrom at combitech.se Tue Dec 8 12:07:05 2015 From: kacper.bostrom at combitech.se (=?iso-8859-1?Q?Bostr=F6m_Kacper?=) Date: Tue, 8 Dec 2015 12:07:05 +0000 Subject: JDK-8090029: NullPointerException in DatePicker when a custom ButtonSkin is set - possible backport to JDK 8? Message-ID: <16fe6532179c422582b5fa9892c76715@corpappl841.corp.saab.se> Hello, Since the shutdown of the official JavaFX Jira one has been unable to comment/discus ongoing or resolved bugs. So I've turned to this mailing list in hope that I came to the right place and if not please do point me in the right direction. I would like to request the backport of the fix for JDK-8090029. Since Java 9 won't be here until 2017 it would be beneficial if the fix could be backported. Regards, Kacper From rahman.usta.88 at gmail.com Tue Dec 8 12:49:21 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Tue, 8 Dec 2015 14:49:21 +0200 Subject: Why there is no WebWorker like mechanism for JavaFX Message-ID: I'm really enjoying developing apps in JavaFX, but I think there is a limitation point; When we think HTML5, there is WebWorker to run long-running tasks in another process. So, we know WebWorker has no DOM access, it is generally used computational needs. Ok, We can run long-running tasks in JavaFX with many threading services, but there is one exception; There are a lot of JavaScript libraries, and executing them in WebView needs JavaFX Application Thread. But, what if your JS code takes long time to execute ? Your UI will hang. Is it required to execute JS code in WebView if it is not accessing DOM API? Thanks. -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From hastebrot at gmail.com Tue Dec 8 13:09:54 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Tue, 8 Dec 2015 14:09:54 +0100 Subject: Why there is no WebWorker like mechanism for JavaFX In-Reply-To: References: Message-ID: The JavaFX API offers Worker class for long running tasks. If you want to execute JavaScript code without DOM and JavaFX you can use the Nashorn JS Virtual machine, which is included in Java 8. I guess the Nashorn documentation also has examples how it's used with the Java scripting API. On Dec 8, 2015 1:50 PM, "Rahman USTA" wrote: > I'm really enjoying developing apps in JavaFX, but I think there is a > limitation point; > > When we think HTML5, there is WebWorker to run long-running tasks in > another process. So, we know WebWorker has no DOM access, it is generally > used computational needs. > > Ok, We can run long-running tasks in JavaFX with many threading services, > but there is one exception; > > There are a lot of JavaScript libraries, and executing them in WebView > needs JavaFX Application Thread. But, what if your JS code takes long time > to execute ? Your UI will hang. Is it required to execute JS code in > WebView if it is not accessing DOM API? > > Thanks. > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta > From rahman.usta.88 at gmail.com Tue Dec 8 13:17:13 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Tue, 8 Dec 2015 15:17:13 +0200 Subject: Why there is no WebWorker like mechanism for JavaFX In-Reply-To: References: Message-ID: Yes your suggestion is OK in theory but in practice, Nashorn is too slow without Warmup. I can say Nashorn is 5x to 10x slower than embedded webkit to run script. 2015-12-08 15:09 GMT+02:00 Benjamin Gudehus : > The JavaFX API offers Worker class for long running tasks. > > If you want to execute JavaScript code without DOM and JavaFX you can use > the Nashorn JS Virtual machine, which is included in Java 8. I guess the > Nashorn documentation also has examples how it's used with the Java > scripting API. > On Dec 8, 2015 1:50 PM, "Rahman USTA" wrote: > >> I'm really enjoying developing apps in JavaFX, but I think there is a >> limitation point; >> >> When we think HTML5, there is WebWorker to run long-running tasks in >> another process. So, we know WebWorker has no DOM access, it is generally >> used computational needs. >> >> Ok, We can run long-running tasks in JavaFX with many threading services, >> but there is one exception; >> >> There are a lot of JavaScript libraries, and executing them in WebView >> needs JavaFX Application Thread. But, what if your JS code takes long time >> to execute ? Your UI will hang. Is it required to execute JS code in >> WebView if it is not accessing DOM API? >> >> Thanks. >> >> -- >> Rahman USTA >> Istanbul JUG >> https://github.com/rahmanusta >> > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From kevin.rushforth at oracle.com Tue Dec 8 13:50:49 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 08 Dec 2015 05:50:49 -0800 Subject: JDK-8090029: NullPointerException in DatePicker when a custom ButtonSkin is set - possible backport to JDK 8? In-Reply-To: <16fe6532179c422582b5fa9892c76715@corpappl841.corp.saab.se> References: <16fe6532179c422582b5fa9892c76715@corpappl841.corp.saab.se> Message-ID: <5666E039.8040201@oracle.com> In general, we will only backport to 8 fixes for critical bugs, regressions, and a few others with safe, simple fixes. This bug meets that criteria, so I have created a backport issue for it. -- Kevin Bostr?m Kacper wrote: > Hello, > > Since the shutdown of the official JavaFX Jira one has been unable to comment/discus ongoing or resolved bugs. So I've turned to this mailing list in hope that I came to the right place and if not please do point me in the right direction. > > I would like to request the backport of the fix for JDK-8090029. Since Java 9 won't be here until 2017 it would be beneficial if the fix could be backported. > > Regards, > Kacper > From dmitry.cherepanov at oracle.com Tue Dec 8 14:29:10 2015 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Tue, 8 Dec 2015 09:29:10 -0500 Subject: [9] Review request for 8144922: [packager] intermittent test failures Message-ID: <5666E936.1030501@oracle.com> Chris, Please review the following fix https://bugs.openjdk.java.net/browse/JDK-8144922 http://cr.openjdk.java.net/~dcherepanov/8144922/webrev.v0/ Thanks, Dmitry From Dell.Green at ideaworks.co.uk Tue Dec 8 14:25:07 2015 From: Dell.Green at ideaworks.co.uk (Dell Green) Date: Tue, 8 Dec 2015 14:25:07 +0000 Subject: OpenJFX armv6hf libjavafx_font_freetype.so x11 Message-ID: <9D740561-A52C-42D7-BF3B-716A431AA408@ideaworks.co.uk> Hi Guys, Is it correct that ?libjavafx_font_freetype.so? be linked against X libraries? as our embedded guys who are running without X were surprised to see this as they are running without X using monocle and frame buffer platforms on raspberry pi and MX6? Do we meet to install X11 if running in frame buffer modes? libjavafx_font_freetype.so: libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f68000) libgtk-x11-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0 (0xb6bc0000) libgdk-x11-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (0xb6b24000) libatk-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libatk-1.0.so.0 (0xb6b00000) libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0xb69c0000) libpangoft2-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0xb69a4000) libpangocairo-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0xb6990000) libgdk_pixbuf-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0xb696c000) libcairo.so.2 => /usr/lib/arm-linux-gnueabihf/libcairo.so.2 (0xb6890000) libpango-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0 (0xb6844000) libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0xb67b8000) libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0xb6780000) libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb6730000) libgthread-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0 (0xb6724000) librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6714000) libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0xb6620000) libXtst.so.6 => /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000) libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6540000) libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb64cc000) libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb64a4000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6484000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6354000) /lib/ld-linux-armhf.so.3 (0xb6f94000) libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6240000) libXcomposite.so.1 => /usr/lib/arm-linux-gnueabihf/libXcomposite.so.1 (0xb6234000) libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 (0xb6228000) libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 (0xb6218000) libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6200000) libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 (0xb61f0000) libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 (0xb61e4000) libXi.so.6 => /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d0000) libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 (0xb61c0000) libXcursor.so.1 => /usr/lib/arm-linux-gnueabihf/libXcursor.so.1 (0xb61b0000) libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0xb61a4000) libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6184000) libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0xb6160000) libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb614c000) libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 (0xb60f4000) libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0xb60cc000) libpixman-1.so.0 => /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0 (0xb6040000) libxcb-shm.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-shm.so.0 (0xb6034000) libxcb-render.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-render.so.0 (0xb6024000) libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6004000) libthai.so.0 => /usr/lib/arm-linux-gnueabihf/libthai.so.0 (0xb5ff4000) libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb5fc8000) libffi.so.5 => /usr/lib/arm-linux-gnueabihf/libffi.so.5 (0xb5fb4000) libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb5f70000) libgraphite2.so.2.0.0 => /usr/lib/libgraphite2.so.2.0.0 (0xb5f54000) libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb5f48000) libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb5f3c000) libdatrie.so.1 => /usr/lib/arm-linux-gnueabihf/libdatrie.so.1 (0xb5f2c000) Dell Green R&D Software Manager t: (+44)203 668 9870 206 Great Portland Street London W1W 5QJ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726 From morris.meyer at oracle.com Tue Dec 8 17:03:10 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Tue, 8 Dec 2015 12:03:10 -0500 Subject: [9] Review request for JDK-8144789: Incorrect assertion fails in the GlassCursor.m Message-ID: <56670D4E.6080105@oracle.com> Vadim and Kevin, Please review this fix for the GlassCursor.m assertion failure. Thanks, --morris WEBREV - http://cr.openjdk.java.net/~morris/JDK-8144780.01a BUG - https://bugs.openjdk.java.net/browse/JDK-8144780 From David.Hill at Oracle.com Tue Dec 8 17:26:08 2015 From: David.Hill at Oracle.com (David Hill) Date: Tue, 08 Dec 2015 12:26:08 -0500 Subject: OpenJFX armv6hf libjavafx_font_freetype.so x11 In-Reply-To: <9D740561-A52C-42D7-BF3B-716A431AA408@ideaworks.co.uk> References: <9D740561-A52C-42D7-BF3B-716A431AA408@ideaworks.co.uk> Message-ID: <566712B0.4020002@Oracle.com> On 12/8/15, 9:25 AM, Dell Green wrote: > > Hi Guys, > > Is it correct that ?libjavafx_font_freetype.so? be linked against X libraries? as our embedded guys who are running without X were surprised to see this as they are running without X using monocle and frame buffer platforms on raspberry pi and MX6? Do we meet to install X11 if running in frame buffer modes? This is a false dependency that appears to have crept back in, and I did not notice because I have both X11 and framebuffer setup for testing. The pkg_config files for a number of these libs we use pack a few extra libs to be "helpful" This will take me a day or so to resolve. I filed https://bugs.openjdk.java.net/browse/JDK-8144942 against it. Dave > > > libjavafx_font_freetype.so: > libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f68000) > libgtk-x11-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0 (0xb6bc0000) > libgdk-x11-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (0xb6b24000) > libatk-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libatk-1.0.so.0 (0xb6b00000) > libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0xb69c0000) > libpangoft2-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0xb69a4000) > libpangocairo-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0xb6990000) > libgdk_pixbuf-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0xb696c000) > libcairo.so.2 => /usr/lib/arm-linux-gnueabihf/libcairo.so.2 (0xb6890000) > libpango-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0 (0xb6844000) > libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0xb67b8000) > libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0xb6780000) > libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb6730000) > libgthread-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0 (0xb6724000) > librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6714000) > libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0xb6620000) > libXtst.so.6 => /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000) > libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6540000) > libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb64cc000) > libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb64a4000) > libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6484000) > libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6354000) > /lib/ld-linux-armhf.so.3 (0xb6f94000) > libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6240000) > libXcomposite.so.1 => /usr/lib/arm-linux-gnueabihf/libXcomposite.so.1 (0xb6234000) > libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 (0xb6228000) > libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 (0xb6218000) > libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6200000) > libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 (0xb61f0000) > libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 (0xb61e4000) > libXi.so.6 => /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d0000) > libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 (0xb61c0000) > libXcursor.so.1 => /usr/lib/arm-linux-gnueabihf/libXcursor.so.1 (0xb61b0000) > libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0xb61a4000) > libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6184000) > libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0xb6160000) > libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb614c000) > libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 (0xb60f4000) > libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0xb60cc000) > libpixman-1.so.0 => /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0 (0xb6040000) > libxcb-shm.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-shm.so.0 (0xb6034000) > libxcb-render.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-render.so.0 (0xb6024000) > libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6004000) > libthai.so.0 => /usr/lib/arm-linux-gnueabihf/libthai.so.0 (0xb5ff4000) > libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb5fc8000) > libffi.so.5 => /usr/lib/arm-linux-gnueabihf/libffi.so.5 (0xb5fb4000) > libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb5f70000) > libgraphite2.so.2.0.0 => /usr/lib/libgraphite2.so.2.0.0 (0xb5f54000) > libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb5f48000) > libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb5f3c000) > libdatrie.so.1 => /usr/lib/arm-linux-gnueabihf/libdatrie.so.1 (0xb5f2c000) > > Dell Green > R&D Software Manager > t: (+44)203 668 9870 > > > > > 206 Great Portland Street > London W1W 5QJ > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From tom.schindl at bestsolution.at Tue Dec 8 17:37:45 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 8 Dec 2015 18:37:45 +0100 Subject: Why there is no WebWorker like mechanism for JavaFX In-Reply-To: References: Message-ID: <56671569.3050709@bestsolution.at> Let's bring this back on the list - i once more accidentally replied just to you. IMHO if you want to execute javascript which is not related to a browser/html you should run that in a javascript vm like nashorn, ... and not through the WebView. Tom On 08.12.15 15:39, Rahman USTA wrote: > I handled the issue by using WebWorker in WebView, my main suggestion is > about JavaFX's threading model, not for a workaround. > > I can try j2v8 if it supports Java Scripting API > > Thanks. > > 2015-12-08 16:24 GMT+02:00 Tom Schindl >: > > Use j2v8 - it is insanely fast as long as you don't do a lot > java->js->java calls which you don't > https://github.com/eclipsesource/j2v8 > > Tom > > Von meinem iPhone gesendet > > > Am 08.12.2015 um 14:17 schrieb Rahman USTA > >: > > > > Yes your suggestion is OK in theory but in practice, Nashorn is > too slow > > without Warmup. I can say Nashorn is 5x to 10x slower than > embedded webkit > > to run script. > > > > 2015-12-08 15:09 GMT+02:00 Benjamin Gudehus >: > > > >> The JavaFX API offers Worker class for long running tasks. > >> > >> If you want to execute JavaScript code without DOM and JavaFX you > can use > >> the Nashorn JS Virtual machine, which is included in Java 8. I > guess the > >> Nashorn documentation also has examples how it's used with the Java > >> scripting API. > >>> On Dec 8, 2015 1:50 PM, "Rahman USTA" > wrote: > >>> > >>> I'm really enjoying developing apps in JavaFX, but I think there > is a > >>> limitation point; > >>> > >>> When we think HTML5, there is WebWorker to run long-running tasks in > >>> another process. So, we know WebWorker has no DOM access, it is > generally > >>> used computational needs. > >>> > >>> Ok, We can run long-running tasks in JavaFX with many threading > services, > >>> but there is one exception; > >>> > >>> There are a lot of JavaScript libraries, and executing them in > WebView > >>> needs JavaFX Application Thread. But, what if your JS code takes > long time > >>> to execute ? Your UI will hang. Is it required to execute JS code in > >>> WebView if it is not accessing DOM API? > >>> > >>> Thanks. > >>> > >>> -- > >>> Rahman USTA > >>> Istanbul JUG > >>> https://github.com/rahmanusta > > > > > > -- > > Rahman USTA > > Istanbul JUG > > https://github.com/rahmanusta > > > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From mike at plan99.net Tue Dec 8 19:54:52 2015 From: mike at plan99.net (Mike Hearn) Date: Tue, 8 Dec 2015 20:54:52 +0100 Subject: Future of JavaFX In-Reply-To: <007401d12f3a$d92738d0$8b75aa70$@eu> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <565E3B4F.6070907@oracle.com> <007401d12f3a$d92738d0$8b75aa70$@eu> Message-ID: I'm pretty surprised by this thread. Guys, JavaFX is a widget toolkit. That's it, that's all it is. GUIs haven't changed that much in their general design and capabilities for decades now, probably the last major 'innovations' being things like the MS Office Ribbon. JFX has all the capabilities I'd hope for in a widget toolkit, plus a lot more. As a bonus it's open source and cross platform, with a full time team of developers. Just take a moment to appreciate that for a second! What's the competition? Qt and that's about it, right? Software can always be better, but this hysteria over "zomg oracle is abandoning us!" doesn't seem justified. Even if all Oracle did from now on was fix bugs and keep it working as the underlying platforms evolve, OK, it's an open source library with people paid to fix bugs. That's still better than many of the open source libraries I depend on! But they aren't just fixing bugs, they're also making enhancements. Yes, Java 9 is going to be boring because Jigsaw is forcing Team FX to go pay off some technical debt by making previously private-but-used APIs public. OK, fine, that amounts to new features for all 3 of you that weren't cheating previously ;) Beyond that, the fact that "draggable tabs" is the most user visible feature planned says to me what I already felt - JavaFX is pretty mature. It'd be nice if Scene Builder was being officially distributed again, and I find the decision not do so baffling (perhaps they're assuming IDE makers will take it off their hands), but the app is still out there and still works. I suspect once the Jigsaw changes are finished off further enhancements will be things like better performance, maybe some new effects, etc. Nice to haves but not essentials. IMO the biggest pain-point now isn't even GUI related stuff, it's the lack of a modern replacement for Java Web Start. I made UpdateFX to try and fill this hole but it's not as good as something that a skilled full time dev with 6 months on hand would make. On Sat, Dec 5, 2015 at 9:56 AM, Markus KARG wrote: > JavaFX support for multi-resolution images is really a killer feature, as > it simply is ridiculous how small images render on HiDPI that are scaled > for LowDPI. > > For JDK 10, I'd kindly ask to review the list of essentials that I sent > you some months back by personal mail. > > -Markus > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf > Of Kevin Rushforth > Sent: Mittwoch, 2. Dezember 2015 01:29 > To: openjfx-dev at openjdk.java.net > Subject: Re: Future of JavaFX > > Just to chime in on a couple of points that have been raised in this > discussion... > > * We are interested in working with the OpenJFX community to improve > JavaFX. In particular: if you find a bug, file it (via bugs.java.com if > you don't have a JBS account); if you want to contribute a patch to fix the > bug, we'd love to review it; if you have an idea for an improvement, file > it as an RFE (enhancement) and start up a thread on the mailing list. > Larger features need a JEP, but smaller improvements do not. > > Please be aware that as part of the OpenJDK community, we are bound by the > processes of the OpenJDK, including the need for a signed OCA in order to > contribute, and before you can get a JBS account. If you are dissatisfied > with those processes and policies, then I invite you to discuss it on the > discuss at openjdk.java.net alias, and not here. > > > * While we aren't planning a huge number of features in JDK 9, we are > delivering some interesting improvements. Jigsaw is the big release driver > and most of our effort on JavaFX is to align with that. For those of you > who weren't at JavaOne, here is a list of things that are currently planned > for JDK 9: > > - A modularized JavaFX (into 6 core modules + deploy, swing interop, swt > interop) > > - JEP 253 -- Control Skins & additional CSS APIs (proper support for > third-party controls) > > - High DPI enhancements (full support on Windows; add support for Linux) > > - Public API for commonly used methods from internal packages: > * Nested Event Loop > * Pulse Listener > * Platform Startup > * Text API (HitTest, etc) > * Static utility functions (under investigation) > > - New versions of WebKit and GStreamer > > And here is an incomplete list of things we are thinking about for after > JDK 9, possibly in an update release. In fact, the recently proposed JDK > 9 slip [1] makes it possible to consider pulling a few of them into JDK 9, > so let us know which ones you consider most important: > > - Provide a JavaFX equivalent for JEP 272 / AWT ?Desktop? API > > - Make UI Control Behaviors public > > - UI Control Actions API > > - Public Focus Traversal API > > - JavaFX support for multi-resolution images > > - Draggable tabs > > - Image IO > > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html > > > From Dell.Green at ideaworks.co.uk Tue Dec 8 20:15:46 2015 From: Dell.Green at ideaworks.co.uk (Dell Green) Date: Tue, 8 Dec 2015 20:15:46 +0000 Subject: OpenJFX armv6hf libjavafx_font_freetype.so x11 Message-ID: great, many thanks, is it a correct assumption that if running javafx on embedded platform using monocle and framebuffer platforms (i.e no x11)? if we run pmap on our Java process then we shouldn't see any linking to X related libraries? On 8 Dec 2015 19:55, openjfx-dev-request at openjdk.java.net 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 armv6hf libjavafx_font_freetype.so x11 (Dell Green) > ?? 2. [9] Review request for JDK-8144789: Incorrect assertion fails > ????? in the??? GlassCursor.m (Morris Meyer) > ?? 3. Re: OpenJFX armv6hf libjavafx_font_freetype.so x11 (David Hill) > ?? 4. Re: Why there is no WebWorker like mechanism for JavaFX > ????? (Tom Schindl) > ?? 5. Re: Future of JavaFX (Mike Hearn) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 8 Dec 2015 14:25:07 +0000 Dell Green R&D Software Manager t: (+44)203 668 9870 > From: Dell Green > To: "openjfx-dev at openjdk.java.net" > Subject: OpenJFX armv6hf libjavafx_font_freetype.so x11 > Message-ID: <9D740561-A52C-42D7-BF3B-716A431AA408 at ideaworks.co.uk> > Content-Type: text/plain; charset="utf-8" > > > > Hi Guys, > > Is it correct that? ?libjavafx_font_freetype.so?? be linked against X libraries? as our embedded guys who are running without X were surprised to see this as they are running without X using monocle and frame buffer platforms on raspberry pi and MX6? Do we meet to install X11 if running in frame buffer modes? > > > libjavafx_font_freetype.so: > ??????? libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f68000) > ??????? libgtk-x11-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0 (0xb6bc0000) > ??????? libgdk-x11-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (0xb6b24000) > ??????? libatk-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libatk-1.0.so.0 (0xb6b00000) > ??????? libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0xb69c0000) > ??????? libpangoft2-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0xb69a4000) > ??????? libpangocairo-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0xb6990000) > ??????? libgdk_pixbuf-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0xb696c000) > ??????? libcairo.so.2 => /usr/lib/arm-linux-gnueabihf/libcairo.so.2 (0xb6890000) > ??????? libpango-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0 (0xb6844000) > ??????? libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0xb67b8000) > ??????? libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0xb6780000) > ??????? libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb6730000) > ??????? libgthread-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0 (0xb6724000) > ??????? librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6714000) > ??????? libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0xb6620000) > ??????? libXtst.so.6 => /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000) > ??????? libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6540000) > ??????? libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb64cc000) > ??????? libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb64a4000) > ??????? libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6484000) > ??????? libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6354000) > ??????? /lib/ld-linux-armhf.so.3 (0xb6f94000) > ??????? libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6240000) > ??????? libXcomposite.so.1 => /usr/lib/arm-linux-gnueabihf/libXcomposite.so.1 (0xb6234000) > ??????? libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 (0xb6228000) > ??????? libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 (0xb6218000) > ??????? libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6200000) > ??????? libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 (0xb61f0000) > ??????? libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 (0xb61e4000) > ??????? libXi.so.6 => /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d0000) > ??????? libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 (0xb61c0000) > ??????? libXcursor.so.1 => /usr/lib/arm-linux-gnueabihf/libXcursor.so.1 (0xb61b0000) > ??????? libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0xb61a4000) > ??????? libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6184000) > ??????? libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0xb6160000) > ??????? libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb614c000) > ??????? libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 (0xb60f4000) > ??????? libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0xb60cc000) > ??????? libpixman-1.so.0 => /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0 (0xb6040000) > ??????? libxcb-shm.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-shm.so.0 (0xb6034000) > ??????? libxcb-render.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-render.so.0 (0xb6024000) > ??????? libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6004000) > ??????? libthai.so.0 => /usr/lib/arm-linux-gnueabihf/libthai.so.0 (0xb5ff4000) > ??????? libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb5fc8000) > ??????? libffi.so.5 => /usr/lib/arm-linux-gnueabihf/libffi.so.5 (0xb5fb4000) > ??????? libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb5f70000) > ??????? libgraphite2.so.2.0.0 => /usr/lib/libgraphite2.so.2.0.0 (0xb5f54000) > ??????? libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb5f48000) > ??????? libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb5f3c000) > ??????? libdatrie.so.1 => /usr/lib/arm-linux-gnueabihf/libdatrie.so.1 (0xb5f2c000) > > Dell Green > R&D Software Manager > t: (+44)203 668 9870 > > > > > 206 Great Portland Street > London W1W 5QJ > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726 > > > ------------------------------ > > Message: 2 > Date: Tue, 8 Dec 2015 12:03:10 -0500 > From: Morris Meyer > To: vadim.pakhnushev at oracle.com, Kevin Rushforth > ??????? ,?? "openjfx-dev at openjdk.java.net" > ??????? > Subject: [9] Review request for JDK-8144789: Incorrect assertion fails > ??????? in the? GlassCursor.m > Message-ID: <56670D4E.6080105 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Vadim and Kevin, > > Please review this fix for the GlassCursor.m assertion failure. > > Thanks, > > ???????? --morris > > WEBREV - http://cr.openjdk.java.net/~morris/JDK-8144780.01a > BUG - https://bugs.openjdk.java.net/browse/JDK-8144780 > > > ------------------------------ > > Message: 3 > Date: Tue, 08 Dec 2015 12:26:08 -0500 > From: David Hill > To: openjfx-dev at openjdk.java.net > Subject: Re: OpenJFX armv6hf libjavafx_font_freetype.so x11 > Message-ID: <566712B0.4020002 at Oracle.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 12/8/15, 9:25 AM, Dell Green wrote: > > > > Hi Guys, > > > > Is it correct that? ?libjavafx_font_freetype.so?? be linked against X libraries? as our embedded guys who are running without X were surprised to see this as they are running without X using monocle and frame buffer platforms on raspberry pi and MX6? Do we meet to install X11 if running in frame buffer modes? > > This is a false dependency that appears to have crept back in, and I did not notice because I have both X11 and framebuffer setup for testing. The pkg_config files for a number of these libs we use pack a few extra libs to be "helpful" > > This will take me a day or so to resolve. I filed https://bugs.openjdk.java.net/browse/JDK-8144942 against it. > > Dave > > > > > > > libjavafx_font_freetype.so: > >??????? libdl.so.2 =>? /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f68000) > >??????? libgtk-x11-2.0.so.0 =>? /usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0 (0xb6bc0000) > >??????? libgdk-x11-2.0.so.0 =>? /usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (0xb6b24000) > >??????? libatk-1.0.so.0 =>? /usr/lib/arm-linux-gnueabihf/libatk-1.0.so.0 (0xb6b00000) > >??????? libgio-2.0.so.0 =>? /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0xb69c0000) > >??????? libpangoft2-1.0.so.0 =>? /usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0xb69a4000) > >??????? libpangocairo-1.0.so.0 =>? /usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0xb6990000) > >??????? libgdk_pixbuf-2.0.so.0 =>? /usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0xb696c000) > >??????? libcairo.so.2 =>? /usr/lib/arm-linux-gnueabihf/libcairo.so.2 (0xb6890000) > >??????? libpango-1.0.so.0 =>? /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0 (0xb6844000) > >??????? libfreetype.so.6 =>? /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0xb67b8000) > >??????? libfontconfig.so.1 =>? /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0xb6780000) > >??????? libgobject-2.0.so.0 =>? /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb6730000) > >??????? libgthread-2.0.so.0 =>? /usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0 (0xb6724000) > >??????? librt.so.1 =>? /lib/arm-linux-gnueabihf/librt.so.1 (0xb6714000) > >??????? libglib-2.0.so.0 =>? /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0xb6620000) > >??????? libXtst.so.6 =>? /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000) > >??????? libstdc++.so.6 =>? /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6540000) > >??????? libm.so.6 =>? /lib/arm-linux-gnueabihf/libm.so.6 (0xb64cc000) > >??????? libgcc_s.so.1 =>? /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb64a4000) > >??????? libpthread.so.0 =>? /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6484000) > >??????? libc.so.6 =>? /lib/arm-linux-gnueabihf/libc.so.6 (0xb6354000) > >??????? /lib/ld-linux-armhf.so.3 (0xb6f94000) > >??????? libX11.so.6 =>? /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6240000) > >??????? libXcomposite.so.1 =>? /usr/lib/arm-linux-gnueabihf/libXcomposite.so.1 (0xb6234000) > >??????? libXdamage.so.1 =>? /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 (0xb6228000) > >??????? libXfixes.so.3 =>? /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 (0xb6218000) > >??????? libXext.so.6 =>? /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6200000) > >??????? libXrender.so.1 =>? /usr/lib/arm-linux-gnueabihf/libXrender.so.1 (0xb61f0000) > >??????? libXinerama.so.1 =>? /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 (0xb61e4000) > >??????? libXi.so.6 =>? /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d0000) > >??????? libXrandr.so.2 =>? /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 (0xb61c0000) > >??????? libXcursor.so.1 =>? /usr/lib/arm-linux-gnueabihf/libXcursor.so.1 (0xb61b0000) > >??????? libgmodule-2.0.so.0 =>? /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0xb61a4000) > >??????? libz.so.1 =>? /lib/arm-linux-gnueabihf/libz.so.1 (0xb6184000) > >??????? libselinux.so.1 =>? /lib/arm-linux-gnueabihf/libselinux.so.1 (0xb6160000) > >??????? libresolv.so.2 =>? /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb614c000) > >??????? libharfbuzz.so.0 =>? /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 (0xb60f4000) > >??????? libpng12.so.0 =>? /lib/arm-linux-gnueabihf/libpng12.so.0 (0xb60cc000) > >??????? libpixman-1.so.0 =>? /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0 (0xb6040000) > >??????? libxcb-shm.so.0 =>? /usr/lib/arm-linux-gnueabihf/libxcb-shm.so.0 (0xb6034000) > >??????? libxcb-render.so.0 =>? /usr/lib/arm-linux-gnueabihf/libxcb-render.so.0 (0xb6024000) > >??????? libxcb.so.1 =>? /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6004000) > >??????? libthai.so.0 =>? /usr/lib/arm-linux-gnueabihf/libthai.so.0 (0xb5ff4000) > >??????? libexpat.so.1 =>? /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb5fc8000) > >??????? libffi.so.5 =>? /usr/lib/arm-linux-gnueabihf/libffi.so.5 (0xb5fb4000) > >??????? libpcre.so.3 =>? /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb5f70000) > >??????? libgraphite2.so.2.0.0 =>? /usr/lib/libgraphite2.so.2.0.0 (0xb5f54000) > >??????? libXau.so.6 =>? /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb5f48000) > >??????? libXdmcp.so.6 =>? /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb5f3c000) > >??????? libdatrie.so.1 =>? /usr/lib/arm-linux-gnueabihf/libdatrie.so.1 (0xb5f2c000) > > > > Dell Green > > R&D Software Manager > > t: (+44)203 668 9870 > > > > > > > > > > 206 Great Portland Street > > London W1W 5QJ > > > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726 > > > -- > David Hill > Java Embedded Development > > "A man's feet should be planted in his country, but his eyes should survey the world." > -- George Santayana (1863 - 1952) > > > > ------------------------------ > > Message: 4 > Date: Tue, 8 Dec 2015 18:37:45 +0100 > From: Tom Schindl > To: Rahman USTA , > ??????? "openjfx-dev at openjdk.java.net" > Subject: Re: Why there is no WebWorker like mechanism for JavaFX > Message-ID: <56671569.3050709 at bestsolution.at> > Content-Type: text/plain; charset=windows-1252 > > Let's bring this back on the list - i once more accidentally replied > just to you. > > IMHO if you want to execute javascript which is not related to a > browser/html you should run that in a javascript vm like nashorn, ... > and not through the WebView. > > Tom > > On 08.12.15 15:39, Rahman USTA wrote: > > I handled the issue by using WebWorker in WebView, my main suggestion is > > about JavaFX's threading model, not for a workaround. > > > > I can try j2v8 if it supports Java Scripting API > > > > Thanks. > > > > 2015-12-08 16:24 GMT+02:00 Tom Schindl > >: > > > >???? Use j2v8 - it is insanely fast as long as you don't do a lot > >???? java->js->java calls which you don't > >???? https://github.com/eclipsesource/j2v8 > > > >???? Tom > > > >???? Von meinem iPhone gesendet > > > >???? > Am 08.12.2015 um 14:17 schrieb Rahman USTA > >???? >: > >???? > > >???? > Yes your suggestion is OK in theory but in practice, Nashorn is > >???? too slow > >???? > without Warmup. I can say Nashorn is 5x to 10x slower than > >???? embedded webkit > >???? > to run script. > >???? > > >???? > 2015-12-08 15:09 GMT+02:00 Benjamin Gudehus >???? >: > >???? > > >???? >> The JavaFX API offers Worker class for long running tasks. > >???? >> > >???? >> If you want to execute JavaScript code without DOM and JavaFX you > >???? can use > >???? >> the Nashorn JS Virtual machine, which is included in Java 8. I > >???? guess the > >???? >> Nashorn documentation also has examples how it's used with the Java > >???? >> scripting API. > >???? >>> On Dec 8, 2015 1:50 PM, "Rahman USTA" >???? > wrote: > >???? >>> > >???? >>> I'm really enjoying developing apps in JavaFX, but I think there > >???? is a > >???? >>> limitation point; > >???? >>> > >???? >>> When we think HTML5, there is WebWorker to run long-running tasks in > >???? >>> another process. So, we know WebWorker has no DOM access, it is > >???? generally > >???? >>> used computational needs. > >???? >>> > >???? >>> Ok, We can run long-running tasks in JavaFX with many threading > >???? services, > >???? >>> but there is one exception; > >???? >>> > >???? >>> There are a lot of JavaScript libraries, and executing them in > >???? WebView > >???? >>> needs JavaFX Application Thread. But, what if your JS code takes > >???? long time > >???? >>> to execute ? Your UI will hang. Is it required to execute JS code in > >???? >>> WebView if it is not accessing DOM API? > >???? >>> > >???? >>> Thanks. > >???? >>> > >???? >>> -- > >???? >>> Rahman USTA > >???? >>> Istanbul JUG > >???? >>> https://github.com/rahmanusta > >???? > > >???? > > >???? > -- > >???? > Rahman USTA > >???? > Istanbul JUG > >???? > https://github.com/rahmanusta > > > > > > > > > > -- > > Rahman USTA > > Istanbul JUG > > https://github.com/rahmanusta > > > -- > Thomas Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > > > ------------------------------ > > Message: 5 > Date: Tue, 8 Dec 2015 20:54:52 +0100 > From: Mike Hearn > To: Markus KARG > Cc: "openjfx-dev at openjdk.java.net" > Subject: Re: Future of JavaFX > Message-ID: > ??????? > Content-Type: text/plain; charset=UTF-8 > > I'm pretty surprised by this thread. > > Guys, JavaFX is a widget toolkit. That's it, that's all it is. GUIs haven't > changed that much in their general design and capabilities for decades now, > probably the last major 'innovations' being things like the MS Office > Ribbon. > > JFX has all the capabilities I'd hope for in a widget toolkit, plus a lot > more. As a bonus it's open source and cross platform, with a full time team > of developers. Just take a moment to appreciate that for a second! What's > the competition? Qt and that's about it, right? > > Software can always be better, but this hysteria over "zomg oracle is > abandoning us!" doesn't seem justified. Even if all Oracle did from now on > was fix bugs and keep it working as the underlying platforms evolve, OK, > it's an open source library with people paid to fix bugs. That's still > better than many of the open source libraries I depend on! > > But they aren't just fixing bugs, they're also making enhancements. Yes, > Java 9 is going to be boring because Jigsaw is forcing Team FX to go pay > off some technical debt by making previously private-but-used APIs public. > OK, fine, that amounts to new features for all 3 of you that weren't > cheating previously ;) > > Beyond that, the fact that "draggable tabs" is the most user visible > feature planned says to me what I already felt? - JavaFX is pretty mature. > It'd be nice if Scene Builder was being officially distributed again, and I > find the decision not do so baffling (perhaps they're assuming IDE makers > will take it off their hands), but the app is still out there and still > works. I suspect once the Jigsaw changes are finished off further > enhancements will be things like better performance, maybe some new > effects, etc. Nice to haves but not essentials. > > IMO the biggest pain-point now isn't even GUI related stuff, it's the lack > of a modern replacement for Java Web Start. I made UpdateFX to try and fill > this hole but it's not as good as something that a skilled full time dev > with 6 months on hand would make. > > > On Sat, Dec 5, 2015 at 9:56 AM, Markus KARG wrote: > > > JavaFX support for multi-resolution images is really a killer feature, as > > it simply is ridiculous how small images render on HiDPI that are scaled > > for LowDPI. > > > > For JDK 10, I'd kindly ask to review the list of essentials that I sent > > you some months back by personal mail. > > > > -Markus > > > > -----Original Message----- > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf > > Of Kevin Rushforth > > Sent: Mittwoch, 2. Dezember 2015 01:29 > > To: openjfx-dev at openjdk.java.net > > Subject: Re: Future of JavaFX > > > > Just to chime in on a couple of points that have been raised in this > > discussion... > > > > * We are interested in working with the OpenJFX community to improve > > JavaFX. In particular: if you find a bug, file it (via bugs.java.com if > > you don't have a JBS account); if you want to contribute a patch to fix the > > bug, we'd love to review it; if you have an idea for an improvement, file > > it as an RFE (enhancement) and start up a thread on the mailing list. > > Larger features need a JEP, but smaller improvements do not. > > > > Please be aware that as part of the OpenJDK community, we are bound by the > > processes of the OpenJDK, including the need for a signed OCA in order to > > contribute, and before you can get a JBS account. If you are dissatisfied > > with those processes and policies, then I invite you to discuss it on the > > discuss at openjdk.java.net alias, and not here. > > > > > > * While we aren't planning a huge number of features in JDK 9, we are > > delivering some interesting improvements. Jigsaw is the big release driver > > and most of our effort on JavaFX is to align with that. For those of you > > who weren't at JavaOne, here is a list of things that are currently planned > > for JDK 9: > > > > - A modularized JavaFX (into 6 core modules + deploy, swing interop, swt > > interop) > > > > - JEP 253 -- Control Skins & additional CSS APIs (proper support for > > third-party controls) > > > > - High DPI enhancements (full support on Windows; add support for Linux) > > > > - Public API for commonly used methods from internal packages: > >???? * Nested Event Loop > >???? * Pulse Listener > >???? * Platform Startup > >???? * Text API (HitTest, etc) > >???? * Static utility functions (under investigation) > > > > - New versions of WebKit and GStreamer > > > > And here is an incomplete list of things we are thinking about for after > > JDK 9, possibly in an update release. In fact, the recently proposed JDK > > 9 slip [1] makes it possible to consider pulling a few of them into JDK 9, > > so let us know which ones you consider most important: > > > > - Provide a JavaFX equivalent for JEP 272 / AWT ?Desktop? API > > > > - Make UI Control Behaviors public > > > > - UI Control Actions API > > > > - Public Focus Traversal API > > > > - JavaFX support for multi-resolution images > > > > - Draggable tabs > > > > - Image IO > > > > > > -- Kevin > > > > [1] > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html > > > > > > > > > End of openjfx-dev Digest, Vol 49, Issue 17 > ******************************************* 206 Great Portland Street London W1W 5QJ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726 From David.Hill at Oracle.com Tue Dec 8 20:28:41 2015 From: David.Hill at Oracle.com (David Hill) Date: Tue, 08 Dec 2015 15:28:41 -0500 Subject: OpenJFX armv6hf libjavafx_font_freetype.so x11 In-Reply-To: References: Message-ID: <56673D79.1040905@Oracle.com> On 12/8/15, 3:15 PM, Dell Green wrote: > > > > great, many thanks, is it a correct assumption that if running javafx on embedded platform using monocle and framebuffer platforms (i.e no x11) if we run pmap on our Java process then we shouldn't see any linking to X related libraries? When my fix goes in and you use the right binaries - then yes. In framebuffer mode, the design was for no X11. If you are building your own OpenJFX, then the gist of the fix is in https://bugs.openjdk.java.net/browse/JDK-8144942 I have to resurrect my Pi to double check the resulting image before I will commit it, so it may be a day or so. This was caused by a cut and paste error when I simplified the build script a while back, taking out the use of pkg-config in a cross compile environment - pasting in the results instead of running the problematic script. Problem was I pasted the wrong variable name... :-o Dave > > On 8 Dec 2015 19:55, openjfx-dev-request at openjdk.java.net 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 armv6hf libjavafx_font_freetype.so x11 (Dell Green) >> 2. [9] Review request for JDK-8144789: Incorrect assertion fails >> in the GlassCursor.m (Morris Meyer) >> 3. Re: OpenJFX armv6hf libjavafx_font_freetype.so x11 (David Hill) >> 4. Re: Why there is no WebWorker like mechanism for JavaFX >> (Tom Schindl) >> 5. Re: Future of JavaFX (Mike Hearn) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 8 Dec 2015 14:25:07 +0000 > > Dell Green > R&D Software Manager > t: (+44)203 668 9870 > >> From: Dell Green >> To: "openjfx-dev at openjdk.java.net" >> Subject: OpenJFX armv6hf libjavafx_font_freetype.so x11 >> Message-ID:<9D740561-A52C-42D7-BF3B-716A431AA408 at ideaworks.co.uk> >> Content-Type: text/plain; charset="utf-8" >> >> >> >> Hi Guys, >> >> Is it correct that ?libjavafx_font_freetype.so? be linked against X libraries? as our embedded guys who are running without X were surprised to see this as they are running without X using monocle and frame buffer platforms on raspberry pi and MX6? Do we meet to install X11 if running in frame buffer modes? >> >> >> libjavafx_font_freetype.so: >> libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f68000) >> libgtk-x11-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0 (0xb6bc0000) >> libgdk-x11-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (0xb6b24000) >> libatk-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libatk-1.0.so.0 (0xb6b00000) >> libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0xb69c0000) >> libpangoft2-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0xb69a4000) >> libpangocairo-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0xb6990000) >> libgdk_pixbuf-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0xb696c000) >> libcairo.so.2 => /usr/lib/arm-linux-gnueabihf/libcairo.so.2 (0xb6890000) >> libpango-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0 (0xb6844000) >> libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0xb67b8000) >> libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0xb6780000) >> libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb6730000) >> libgthread-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0 (0xb6724000) >> librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6714000) >> libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0xb6620000) >> libXtst.so.6 => /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000) >> libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6540000) >> libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb64cc000) >> libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb64a4000) >> libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6484000) >> libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6354000) >> /lib/ld-linux-armhf.so.3 (0xb6f94000) >> libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6240000) >> libXcomposite.so.1 => /usr/lib/arm-linux-gnueabihf/libXcomposite.so.1 (0xb6234000) >> libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 (0xb6228000) >> libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 (0xb6218000) >> libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6200000) >> libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 (0xb61f0000) >> libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 (0xb61e4000) >> libXi.so.6 => /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d0000) >> libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 (0xb61c0000) >> libXcursor.so.1 => /usr/lib/arm-linux-gnueabihf/libXcursor.so.1 (0xb61b0000) >> libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0xb61a4000) >> libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6184000) >> libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0xb6160000) >> libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb614c000) >> libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 (0xb60f4000) >> libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0xb60cc000) >> libpixman-1.so.0 => /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0 (0xb6040000) >> libxcb-shm.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-shm.so.0 (0xb6034000) >> libxcb-render.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-render.so.0 (0xb6024000) >> libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6004000) >> libthai.so.0 => /usr/lib/arm-linux-gnueabihf/libthai.so.0 (0xb5ff4000) >> libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb5fc8000) >> libffi.so.5 => /usr/lib/arm-linux-gnueabihf/libffi.so.5 (0xb5fb4000) >> libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb5f70000) >> libgraphite2.so.2.0.0 => /usr/lib/libgraphite2.so.2.0.0 (0xb5f54000) >> libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb5f48000) >> libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb5f3c000) >> libdatrie.so.1 => /usr/lib/arm-linux-gnueabihf/libdatrie.so.1 (0xb5f2c000) >> >> Dell Green >> R&D Software Manager >> t: (+44)203 668 9870 >> >> >> >> >> 206 Great Portland Street >> London W1W 5QJ >> >> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726 >> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 8 Dec 2015 12:03:10 -0500 >> From: Morris Meyer >> To: vadim.pakhnushev at oracle.com, Kevin Rushforth >> , "openjfx-dev at openjdk.java.net" >> >> Subject: [9] Review request for JDK-8144789: Incorrect assertion fails >> in the GlassCursor.m >> Message-ID:<56670D4E.6080105 at oracle.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> Vadim and Kevin, >> >> Please review this fix for the GlassCursor.m assertion failure. >> >> Thanks, >> >> --morris >> >> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8144780.01a >> BUG - https://bugs.openjdk.java.net/browse/JDK-8144780 >> >> >> ------------------------------ >> >> Message: 3 >> Date: Tue, 08 Dec 2015 12:26:08 -0500 >> From: David Hill >> To: openjfx-dev at openjdk.java.net >> Subject: Re: OpenJFX armv6hf libjavafx_font_freetype.so x11 >> Message-ID:<566712B0.4020002 at Oracle.com> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> On 12/8/15, 9:25 AM, Dell Green wrote: >>> Hi Guys, >>> >>> Is it correct that ?libjavafx_font_freetype.so? be linked against X libraries? as our embedded guys who are running without X were surprised to see this as they are running without X using monocle and frame buffer platforms on raspberry pi and MX6? Do we meet to install X11 if running in frame buffer modes? >> This is a false dependency that appears to have crept back in, and I did not notice because I have both X11 and framebuffer setup for testing. The pkg_config files for a number of these libs we use pack a few extra libs to be "helpful" >> >> This will take me a day or so to resolve. I filed https://bugs.openjdk.java.net/browse/JDK-8144942 against it. >> >> Dave >> >>> >>> libjavafx_font_freetype.so: >>> libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f68000) >>> libgtk-x11-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0 (0xb6bc0000) >>> libgdk-x11-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (0xb6b24000) >>> libatk-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libatk-1.0.so.0 (0xb6b00000) >>> libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0xb69c0000) >>> libpangoft2-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0xb69a4000) >>> libpangocairo-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0xb6990000) >>> libgdk_pixbuf-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0xb696c000) >>> libcairo.so.2 => /usr/lib/arm-linux-gnueabihf/libcairo.so.2 (0xb6890000) >>> libpango-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0 (0xb6844000) >>> libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0xb67b8000) >>> libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0xb6780000) >>> libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb6730000) >>> libgthread-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0 (0xb6724000) >>> librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6714000) >>> libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0xb6620000) >>> libXtst.so.6 => /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000) >>> libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6540000) >>> libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb64cc000) >>> libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb64a4000) >>> libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6484000) >>> libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6354000) >>> /lib/ld-linux-armhf.so.3 (0xb6f94000) >>> libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6240000) >>> libXcomposite.so.1 => /usr/lib/arm-linux-gnueabihf/libXcomposite.so.1 (0xb6234000) >>> libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 (0xb6228000) >>> libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 (0xb6218000) >>> libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6200000) >>> libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 (0xb61f0000) >>> libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 (0xb61e4000) >>> libXi.so.6 => /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d0000) >>> libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 (0xb61c0000) >>> libXcursor.so.1 => /usr/lib/arm-linux-gnueabihf/libXcursor.so.1 (0xb61b0000) >>> libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0xb61a4000) >>> libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6184000) >>> libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0xb6160000) >>> libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb614c000) >>> libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 (0xb60f4000) >>> libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0xb60cc000) >>> libpixman-1.so.0 => /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0 (0xb6040000) >>> libxcb-shm.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-shm.so.0 (0xb6034000) >>> libxcb-render.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-render.so.0 (0xb6024000) >>> libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6004000) >>> libthai.so.0 => /usr/lib/arm-linux-gnueabihf/libthai.so.0 (0xb5ff4000) >>> libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb5fc8000) >>> libffi.so.5 => /usr/lib/arm-linux-gnueabihf/libffi.so.5 (0xb5fb4000) >>> libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb5f70000) >>> libgraphite2.so.2.0.0 => /usr/lib/libgraphite2.so.2.0.0 (0xb5f54000) >>> libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb5f48000) >>> libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb5f3c000) >>> libdatrie.so.1 => /usr/lib/arm-linux-gnueabihf/libdatrie.so.1 (0xb5f2c000) >>> >>> Dell Green >>> R&D Software Manager >>> t: (+44)203 668 9870 >>> >>> >>> >>> >>> 206 Great Portland Street >>> London W1W 5QJ >>> >>> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726 >> >> -- >> David Hill >> Java Embedded Development >> >> "A man's feet should be planted in his country, but his eyes should survey the world." >> -- George Santayana (1863 - 1952) >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Tue, 8 Dec 2015 18:37:45 +0100 >> From: Tom Schindl >> To: Rahman USTA, >> "openjfx-dev at openjdk.java.net" >> Subject: Re: Why there is no WebWorker like mechanism for JavaFX >> Message-ID:<56671569.3050709 at bestsolution.at> >> Content-Type: text/plain; charset=windows-1252 >> >> Let's bring this back on the list - i once more accidentally replied >> just to you. >> >> IMHO if you want to execute javascript which is not related to a >> browser/html you should run that in a javascript vm like nashorn, ... >> and not through the WebView. >> >> Tom >> >> On 08.12.15 15:39, Rahman USTA wrote: >>> I handled the issue by using WebWorker in WebView, my main suggestion is >>> about JavaFX's threading model, not for a workaround. >>> >>> I can try j2v8 if it supports Java Scripting API >>> >>> Thanks. >>> >>> 2015-12-08 16:24 GMT+02:00 Tom Schindl>> >: >>> >>> Use j2v8 - it is insanely fast as long as you don't do a lot >>> java->js->java calls which you don't >>> https://github.com/eclipsesource/j2v8 >>> >>> Tom >>> >>> Von meinem iPhone gesendet >>> >>> > Am 08.12.2015 um 14:17 schrieb Rahman USTA >>> >: >>> > >>> > Yes your suggestion is OK in theory but in practice, Nashorn is >>> too slow >>> > without Warmup. I can say Nashorn is 5x to 10x slower than >>> embedded webkit >>> > to run script. >>> > >>> > 2015-12-08 15:09 GMT+02:00 Benjamin Gudehus>> >: >>> > >>> >> The JavaFX API offers Worker class for long running tasks. >>> >> >>> >> If you want to execute JavaScript code without DOM and JavaFX you >>> can use >>> >> the Nashorn JS Virtual machine, which is included in Java 8. I >>> guess the >>> >> Nashorn documentation also has examples how it's used with the Java >>> >> scripting API. >>> >>> On Dec 8, 2015 1:50 PM, "Rahman USTA">> > wrote: >>> >>> >>> >>> I'm really enjoying developing apps in JavaFX, but I think there >>> is a >>> >>> limitation point; >>> >>> >>> >>> When we think HTML5, there is WebWorker to run long-running tasks in >>> >>> another process. So, we know WebWorker has no DOM access, it is >>> generally >>> >>> used computational needs. >>> >>> >>> >>> Ok, We can run long-running tasks in JavaFX with many threading >>> services, >>> >>> but there is one exception; >>> >>> >>> >>> There are a lot of JavaScript libraries, and executing them in >>> WebView >>> >>> needs JavaFX Application Thread. But, what if your JS code takes >>> long time >>> >>> to execute ? Your UI will hang. Is it required to execute JS code in >>> >>> WebView if it is not accessing DOM API? >>> >>> >>> >>> Thanks. >>> >>> >>> >>> -- >>> >>> Rahman USTA >>> >>> Istanbul JUG >>> >>> https://github.com/rahmanusta >>> > >>> > >>> > -- >>> > Rahman USTA >>> > Istanbul JUG >>> > https://github.com/rahmanusta >>> >>> >>> >>> >>> -- >>> Rahman USTA >>> Istanbul JUG >>> https://github.com/rahmanusta >> >> -- >> Thomas Schindl, CTO >> BestSolution.at EDV Systemhaus GmbH >> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck >> http://www.bestsolution.at/ >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck >> >> >> ------------------------------ >> >> Message: 5 >> Date: Tue, 8 Dec 2015 20:54:52 +0100 >> From: Mike Hearn >> To: Markus KARG >> Cc: "openjfx-dev at openjdk.java.net" >> Subject: Re: Future of JavaFX >> Message-ID: >> >> Content-Type: text/plain; charset=UTF-8 >> >> I'm pretty surprised by this thread. >> >> Guys, JavaFX is a widget toolkit. That's it, that's all it is. GUIs haven't >> changed that much in their general design and capabilities for decades now, >> probably the last major 'innovations' being things like the MS Office >> Ribbon. >> >> JFX has all the capabilities I'd hope for in a widget toolkit, plus a lot >> more. As a bonus it's open source and cross platform, with a full time team >> of developers. Just take a moment to appreciate that for a second! What's >> the competition? Qt and that's about it, right? >> >> Software can always be better, but this hysteria over "zomg oracle is >> abandoning us!" doesn't seem justified. Even if all Oracle did from now on >> was fix bugs and keep it working as the underlying platforms evolve, OK, >> it's an open source library with people paid to fix bugs. That's still >> better than many of the open source libraries I depend on! >> >> But they aren't just fixing bugs, they're also making enhancements. Yes, >> Java 9 is going to be boring because Jigsaw is forcing Team FX to go pay >> off some technical debt by making previously private-but-used APIs public. >> OK, fine, that amounts to new features for all 3 of you that weren't >> cheating previously ;) >> >> Beyond that, the fact that "draggable tabs" is the most user visible >> feature planned says to me what I already felt - JavaFX is pretty mature. >> It'd be nice if Scene Builder was being officially distributed again, and I >> find the decision not do so baffling (perhaps they're assuming IDE makers >> will take it off their hands), but the app is still out there and still >> works. I suspect once the Jigsaw changes are finished off further >> enhancements will be things like better performance, maybe some new >> effects, etc. Nice to haves but not essentials. >> >> IMO the biggest pain-point now isn't even GUI related stuff, it's the lack >> of a modern replacement for Java Web Start. I made UpdateFX to try and fill >> this hole but it's not as good as something that a skilled full time dev >> with 6 months on hand would make. >> >> >> On Sat, Dec 5, 2015 at 9:56 AM, Markus KARG wrote: >> >>> JavaFX support for multi-resolution images is really a killer feature, as >>> it simply is ridiculous how small images render on HiDPI that are scaled >>> for LowDPI. >>> >>> For JDK 10, I'd kindly ask to review the list of essentials that I sent >>> you some months back by personal mail. >>> >>> -Markus >>> >>> -----Original Message----- >>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf >>> Of Kevin Rushforth >>> Sent: Mittwoch, 2. Dezember 2015 01:29 >>> To: openjfx-dev at openjdk.java.net >>> Subject: Re: Future of JavaFX >>> >>> Just to chime in on a couple of points that have been raised in this >>> discussion... >>> >>> * We are interested in working with the OpenJFX community to improve >>> JavaFX. In particular: if you find a bug, file it (via bugs.java.com if >>> you don't have a JBS account); if you want to contribute a patch to fix the >>> bug, we'd love to review it; if you have an idea for an improvement, file >>> it as an RFE (enhancement) and start up a thread on the mailing list. >>> Larger features need a JEP, but smaller improvements do not. >>> >>> Please be aware that as part of the OpenJDK community, we are bound by the >>> processes of the OpenJDK, including the need for a signed OCA in order to >>> contribute, and before you can get a JBS account. If you are dissatisfied >>> with those processes and policies, then I invite you to discuss it on the >>> discuss at openjdk.java.net alias, and not here. >>> >>> >>> * While we aren't planning a huge number of features in JDK 9, we are >>> delivering some interesting improvements. Jigsaw is the big release driver >>> and most of our effort on JavaFX is to align with that. For those of you >>> who weren't at JavaOne, here is a list of things that are currently planned >>> for JDK 9: >>> >>> - A modularized JavaFX (into 6 core modules + deploy, swing interop, swt >>> interop) >>> >>> - JEP 253 -- Control Skins& additional CSS APIs (proper support for >>> third-party controls) >>> >>> - High DPI enhancements (full support on Windows; add support for Linux) >>> >>> - Public API for commonly used methods from internal packages: >>> * Nested Event Loop >>> * Pulse Listener >>> * Platform Startup >>> * Text API (HitTest, etc) >>> * Static utility functions (under investigation) >>> >>> - New versions of WebKit and GStreamer >>> >>> And here is an incomplete list of things we are thinking about for after >>> JDK 9, possibly in an update release. In fact, the recently proposed JDK >>> 9 slip [1] makes it possible to consider pulling a few of them into JDK 9, >>> so let us know which ones you consider most important: >>> >>> - Provide a JavaFX equivalent for JEP 272 / AWT ?Desktop? API >>> >>> - Make UI Control Behaviors public >>> >>> - UI Control Actions API >>> >>> - Public Focus Traversal API >>> >>> - JavaFX support for multi-resolution images >>> >>> - Draggable tabs >>> >>> - Image IO >>> >>> >>> -- Kevin >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html >>> >>> >>> >> >> End of openjfx-dev Digest, Vol 49, Issue 17 >> ******************************************* > > > 206 Great Portland Street > London W1W 5QJ > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From guru.hb at oracle.com Tue Dec 8 21:41:43 2015 From: guru.hb at oracle.com (Guru Hb) Date: Tue, 8 Dec 2015 13:41:43 -0800 (PST) Subject: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time In-Reply-To: <4ce1d14c-ebdf-44d2-a84e-6d9f8e75bc15@default> References: <1bee96ff-3087-4689-82ab-54d3ba21053d@default> <4ce1d14c-ebdf-44d2-a84e-6d9f8e75bc15@default> Message-ID: <40367ac3-3ec3-4050-ae0c-0174a2618385@default> Fixed Test failure on MAC Webrev : http://cr.openjdk.java.net/~ghb/8143894/webrev.02/ Tested on Windows , Linux and Mac Thanks, Guru -----Original Message----- From: Guru Hb Sent: Tuesday, December 08, 2015 4:08 PM To: Arunprasad Rajkumar; Alexander Zvegintsev; Kevin Rushforth Cc: openjfx-dev at openjdk.java.net; Ankit Srivastava; Murali Billa Subject: RE: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time Hi Arunprasad, Alexander and Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/ Webrev : http://cr.openjdk.java.net/~arapte/ghb/8143894/webrev.01/ (Due to permission bit corrupted to my ghb at cr.openjdk.java.net account I am sending this patch from ~arapte account) Fix updated with regression test Thanks, Guru -----Original Message----- From: Guru Hb Sent: Tuesday, December 01, 2015 10:29 AM To: Arunprasad Rajkumar; Alexander Zvegintsev; Kevin Rushforth Cc: openjfx-dev at openjdk.java.net Subject: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time Hi Arunprasad, Alexander & Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/ Webrev : http://cr.openjdk.java.net/~ghb/8143894/webrev.00 Tested on Windows and Linux (both 64 bit). Thnaks, Guru From Dell.Green at ideaworks.co.uk Tue Dec 8 22:10:32 2015 From: Dell.Green at ideaworks.co.uk (Dell Green) Date: Tue, 8 Dec 2015 22:10:32 +0000 Subject: OpenJFX armv6hf libjavafx_font_freetype.so x11 Message-ID: OK great many thanks. I can wait a few days until your happy with your changes and commit them. ? Dell Green R&D Software Manager t: (+44)203 668 9870 206 Great Portland Street London W1W 5QJ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726 From chien.yang at oracle.com Wed Dec 9 02:45:03 2015 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 08 Dec 2015 18:45:03 -0800 Subject: Code Review Request For JDK-8091170: Compile-time warnings in prism-es2 code Message-ID: <566795AF.7010907@oracle.com> Hi Kevin, Please review the proposed fix which was moved from JDK-8090866 as per our conversation: JIRA: https://bugs.openjdk.java.net/browse/JDK-8091170 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8091170/webrev.00/ Thanks, - Chien From arunprasad.rajkumar at oracle.com Wed Dec 9 10:07:20 2015 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 9 Dec 2015 15:37:20 +0530 Subject: [9] Review request for 8144688: JFX WebView DRT implementation doesn't pass mouse button for mousemove simulation In-Reply-To: <5645CEF6.9070408@oracle.com> References: <5645CEF6.9070408@oracle.com> Message-ID: <5667FD58.4090503@oracle.com> Hi Kevin, Alexander, Guru, Please review the below patch. JIRA: https://bugs.openjdk.java.net/browse/JDK-8144688 Webrev: http://cr.openjdk.java.net/~ghb/arunprasad/8144688/webrev.00/ Issue: DRT testcases uses mouse simulation APIs to do the selection and drag. Our implementation of DRT doesn't pass mouse button type(left, center/middle, right) for mouse move. Fix: Store the mouse button type during mouse down and pass it when DRT calls mouse move. Regards, Arun From David.Hill at Oracle.com Wed Dec 9 19:04:20 2015 From: David.Hill at Oracle.com (David Hill) Date: Wed, 09 Dec 2015 14:04:20 -0500 Subject: review for ARM buildSrc file changes to remove a false dependancy on X11 Message-ID: <56687B34.4010706@Oracle.com> Kevin, could I get a review for ARM buildSrc file changes to remove a false dependancy on X11 bug: https://bugs.openjdk.java.net/browse/JDK-8144942 webrev: http://cr.openjdk.java.net/~ddhill/8144942/ same change in all the flavor variants. Verified with ldd and pmap on a Pi (using the latest Pi version Jessie!) -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From guru.hb at oracle.com Wed Dec 9 19:04:27 2015 From: guru.hb at oracle.com (Guru Hb) Date: Wed, 9 Dec 2015 11:04:27 -0800 (PST) Subject: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time In-Reply-To: <40367ac3-3ec3-4050-ae0c-0174a2618385@default> References: <1bee96ff-3087-4689-82ab-54d3ba21053d@default> <4ce1d14c-ebdf-44d2-a84e-6d9f8e75bc15@default> <40367ac3-3ec3-4050-ae0c-0174a2618385@default> Message-ID: JBS : https://bugs.openjdk.java.net/browse/JDK-8143894 Review comments incorporated with updated fix : http://cr.openjdk.java.net/~ghb/8143894/webrev.03/ (Tested on Windows and Linux) //Todo : setURL, setFiles, setData, setHtml (needs URL) : will be tracked in https://bugs.openjdk.java.net/browse/JDK-8145028 Thanks, Guru -----Original Message----- From: Guru Hb Sent: Wednesday, December 09, 2015 3:12 AM To: Arunprasad Rajkumar; Alexander Zvegintsev; Kevin Rushforth Cc: Ankit Srivastava; openjfx-dev at openjdk.java.net Subject: RE: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time Fixed Test failure on MAC Webrev : http://cr.openjdk.java.net/~ghb/8143894/webrev.02/ Tested on Windows , Linux and Mac Thanks, Guru -----Original Message----- From: Guru Hb Sent: Tuesday, December 08, 2015 4:08 PM To: Arunprasad Rajkumar; Alexander Zvegintsev; Kevin Rushforth Cc: openjfx-dev at openjdk.java.net; Ankit Srivastava; Murali Billa Subject: RE: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time Hi Arunprasad, Alexander and Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/ Webrev : http://cr.openjdk.java.net/~arapte/ghb/8143894/webrev.01/ (Due to permission bit corrupted to my ghb at cr.openjdk.java.net account I am sending this patch from ~arapte account) Fix updated with regression test Thanks, Guru -----Original Message----- From: Guru Hb Sent: Tuesday, December 01, 2015 10:29 AM To: Arunprasad Rajkumar; Alexander Zvegintsev; Kevin Rushforth Cc: openjfx-dev at openjdk.java.net Subject: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time Hi Arunprasad, Alexander & Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/ Webrev : http://cr.openjdk.java.net/~ghb/8143894/webrev.00 Tested on Windows and Linux (both 64 bit). Thnaks, Guru From jonathan.giles at oracle.com Wed Dec 9 21:34:56 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 10 Dec 2015 10:34:56 +1300 Subject: [Review Request] Provide API to expose list of showing Windows Message-ID: <56689E80.6000209@oracle.com> Hi Kevin, all, Please review the most recent patch attached to the following JBS issue: https://bugs.openjdk.java.net/browse/JDK-8144628 This API removes the Window.impl_getWindows() method that returned an Iterator, and replaces it with Window.getWindows(), which returns an unmodifiable ObservableList. Thanks, -- Jonathan From jonathan.giles at oracle.com Thu Dec 10 00:11:41 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 10 Dec 2015 13:11:41 +1300 Subject: [Review request] Promote TableColumn reorderable property to public API Message-ID: <5668C33D.1050000@oracle.com> Hi Kevin, all, Please review the patch attached to the following JBS issue: https://bugs.openjdk.java.net/browse/JDK-8144962 This API removes the deprecated TableColumnBase.impl_reorderable property, and replaces it with a TableColumnBase.reorderable property. Thanks, -- Jonathan From guru.hb at oracle.com Thu Dec 10 16:59:27 2015 From: guru.hb at oracle.com (Guru Hb) Date: Thu, 10 Dec 2015 08:59:27 -0800 (PST) Subject: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time Message-ID: Review comments incorporated and updated fix : http://cr.openjdk.java.net/~ghb/8143894/webrev.04/ ----- Original Message ----- From: guru.hb at oracle.com To: arunprasad.rajkumar at oracle.com, alexander.zvegintsev at oracle.com, kevin.rushforth at oracle.com Cc: openjfx-dev at openjdk.java.net, a.ankit.srivastava at oracle.com Sent: Thursday, December 10, 2015 12:34:47 AM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi Subject: RE: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time JBS : https://bugs.openjdk.java.net/browse/JDK-8143894 Review comments incorporated with updated fix : http://cr.openjdk.java.net/~ghb/8143894/webrev.03/ (Tested on Windows and Linux) //Todo : setURL, setFiles, setData, setHtml (needs URL) : will be tracked in https://bugs.openjdk.java.net/browse/JDK-8145028 Thanks, Guru -----Original Message----- From: Guru Hb Sent: Wednesday, December 09, 2015 3:12 AM To: Arunprasad Rajkumar; Alexander Zvegintsev; Kevin Rushforth Cc: Ankit Srivastava; openjfx-dev at openjdk.java.net Subject: RE: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time Fixed Test failure on MAC Webrev : http://cr.openjdk.java.net/~ghb/8143894/webrev.02/ Tested on Windows , Linux and Mac Thanks, Guru -----Original Message----- From: Guru Hb Sent: Tuesday, December 08, 2015 4:08 PM To: Arunprasad Rajkumar; Alexander Zvegintsev; Kevin Rushforth Cc: openjfx-dev at openjdk.java.net; Ankit Srivastava; Murali Billa Subject: RE: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time Hi Arunprasad, Alexander and Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/ Webrev : http://cr.openjdk.java.net/~arapte/ghb/8143894/webrev.01/ (Due to permission bit corrupted to my ghb at cr.openjdk.java.net account I am sending this patch from ~arapte account) Fix updated with regression test Thanks, Guru -----Original Message----- From: Guru Hb Sent: Tuesday, December 01, 2015 10:29 AM To: Arunprasad Rajkumar; Alexander Zvegintsev; Kevin Rushforth Cc: openjfx-dev at openjdk.java.net Subject: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time Hi Arunprasad, Alexander & Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/ Webrev : http://cr.openjdk.java.net/~ghb/8143894/webrev.00 Tested on Windows and Linux (both 64 bit). Thnaks, Guru From jonathan.giles at oracle.com Thu Dec 10 19:34:17 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 11 Dec 2015 08:34:17 +1300 Subject: [Review request] 8144625: Expose code and char properties on KeyCode Message-ID: <5669D3B9.9080404@oracle.com> Hi Kevin, all, Please review the patch attached to the following JBS issue: https://bugs.openjdk.java.net/browse/JDK-8144625 This change removes the impl_getCode() and impl_getChar() methods from KeyCode, and adds in getCode() and getChar() methods. -- -- Jonathan From jonathan.giles at oracle.com Thu Dec 10 20:54:52 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 11 Dec 2015 09:54:52 +1300 Subject: [Review request] 8145143: Promote Image.impl_getUrl() to public API as Image.getUrl() Message-ID: <5669E69C.4020107@oracle.com> Hi Chien, Kevin, Please can you review the following JBS issue (and attached patch): https://bugs.openjdk.java.net/browse/JDK-8145143 As the subject line states, this issue proposes to promote the Image.impl_getUrl() method to Image.getUrl(), so that it is public API. -- -- Jonathan From tom.schindl at bestsolution.at Thu Dec 10 21:27:29 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 10 Dec 2015 22:27:29 +0100 Subject: [Review request] 8145143: Promote Image.impl_getUrl() to public API as Image.getUrl() In-Reply-To: <5669E69C.4020107@oracle.com> References: <5669E69C.4020107@oracle.com> Message-ID: <79ECD854-BA8F-49B5-A920-A3367BE68C5E@bestsolution.at> As i see it the url is optional so wouldn't make sense to return Optional to make this more explicit? Tom Von meinem iPhone gesendet > Am 10.12.2015 um 21:54 schrieb Jonathan Giles : > > Hi Chien, Kevin, > > Please can you review the following JBS issue (and attached patch): > > https://bugs.openjdk.java.net/browse/JDK-8145143 > > As the subject line states, this issue proposes to promote the Image.impl_getUrl() method to Image.getUrl(), so that it is public API. > > -- > > > -- Jonathan > From jonathan.giles at oracle.com Thu Dec 10 21:29:08 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 11 Dec 2015 10:29:08 +1300 Subject: [Review request] 8145143: Promote Image.impl_getUrl() to public API as Image.getUrl() In-Reply-To: <79ECD854-BA8F-49B5-A920-A3367BE68C5E@bestsolution.at> References: <5669E69C.4020107@oracle.com> <79ECD854-BA8F-49B5-A920-A3367BE68C5E@bestsolution.at> Message-ID: <5669EEA4.6080806@oracle.com> I tend to be a fan of Optional....but it isn't something we have used much of in JavaFX (I might be the only user of it so far in the Dialog API). From my perspective then, I can +1 on the Optional, but we'll see what others say. -- Jonathan On 11/12/15 10:27 AM, Tom Schindl wrote: > As i see it the url is optional so wouldn't make sense to return Optional to make this more explicit? > > Tom > > Von meinem iPhone gesendet > >> Am 10.12.2015 um 21:54 schrieb Jonathan Giles : >> >> Hi Chien, Kevin, >> >> Please can you review the following JBS issue (and attached patch): >> >> https://bugs.openjdk.java.net/browse/JDK-8145143 >> >> As the subject line states, this issue proposes to promote the Image.impl_getUrl() method to Image.getUrl(), so that it is public API. >> >> -- >> >> >> -- Jonathan >> From kevin.rushforth at oracle.com Thu Dec 10 21:39:31 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 10 Dec 2015 13:39:31 -0800 Subject: [Review request] 8145143: Promote Image.impl_getUrl() to public API as Image.getUrl() In-Reply-To: <79ECD854-BA8F-49B5-A920-A3367BE68C5E@bestsolution.at> References: <5669E69C.4020107@oracle.com> <79ECD854-BA8F-49B5-A920-A3367BE68C5E@bestsolution.at> Message-ID: <5669F113.7090905@oracle.com> That's an interesting question. We haven't used Optional for such cases except the return value of Dialog showAndWait. Wrapping the URL in an Optional is more self-documenting, but perhaps less convenient if you know that it is non-null (and basically the same if you don't know, since this doesn't seem like something you would do anything with other than asking "is it valid"). Another interesting question: how useful is this API? It was on the list of impl_* method that Jonathan and I felt would be worth making public API out of, but I don't know how prevalent its use is? -- Kevin Tom Schindl wrote: > As i see it the url is optional so wouldn't make sense to return Optional to make this more explicit? > > Tom > > Von meinem iPhone gesendet > > >> Am 10.12.2015 um 21:54 schrieb Jonathan Giles : >> >> Hi Chien, Kevin, >> >> Please can you review the following JBS issue (and attached patch): >> >> https://bugs.openjdk.java.net/browse/JDK-8145143 >> >> As the subject line states, this issue proposes to promote the Image.impl_getUrl() method to Image.getUrl(), so that it is public API. >> >> -- >> >> >> -- Jonathan >> >> From kevin.rushforth at oracle.com Thu Dec 10 21:42:06 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 10 Dec 2015 13:42:06 -0800 Subject: [Review request] 8145143: Promote Image.impl_getUrl() to public API as Image.getUrl() In-Reply-To: <5669EEA4.6080806@oracle.com> References: <5669E69C.4020107@oracle.com> <79ECD854-BA8F-49B5-A920-A3367BE68C5E@bestsolution.at> <5669EEA4.6080806@oracle.com> Message-ID: <5669F1AE.2040407@oracle.com> Since this is a read-only get method of an immutable property, I guess it doesn't matter much. We can make it an Optional if that's what most folks want. -- Kevin Jonathan Giles wrote: > I tend to be a fan of Optional....but it isn't something we have used > much of in JavaFX (I might be the only user of it so far in the Dialog > API). > > From my perspective then, I can +1 on the Optional, but we'll see what > others say. > > -- Jonathan > > On 11/12/15 10:27 AM, Tom Schindl wrote: >> As i see it the url is optional so wouldn't make sense to return >> Optional to make this more explicit? >> >> Tom >> >> Von meinem iPhone gesendet >> >>> Am 10.12.2015 um 21:54 schrieb Jonathan Giles >>> : >>> >>> Hi Chien, Kevin, >>> >>> Please can you review the following JBS issue (and attached patch): >>> >>> https://bugs.openjdk.java.net/browse/JDK-8145143 >>> >>> As the subject line states, this issue proposes to promote the >>> Image.impl_getUrl() method to Image.getUrl(), so that it is public API. >>> >>> -- >>> >>> >>> -- Jonathan >>> > From david.grieve at oracle.com Thu Dec 10 22:16:41 2015 From: david.grieve at oracle.com (David Grieve) Date: Thu, 10 Dec 2015 17:16:41 -0500 Subject: [Review request] 8145143: Promote Image.impl_getUrl() to public API as Image.getUrl() In-Reply-To: <5669F113.7090905@oracle.com> References: <5669E69C.4020107@oracle.com> <79ECD854-BA8F-49B5-A920-A3367BE68C5E@bestsolution.at> <5669F113.7090905@oracle.com> Message-ID: <5669F9C9.2010908@oracle.com> I believe the url might be used in the CSS engine for caching images loaded from .css files. If the css image cache is made public (I don't know if that is planned, but it should be considered), then this API will matter. On 12/10/15 4:39 PM, Kevin Rushforth wrote: > That's an interesting question. We haven't used Optional for such > cases except the return value of Dialog showAndWait. Wrapping the URL > in an Optional is more self-documenting, but perhaps less convenient > if you know that it is non-null (and basically the same if you don't > know, since this doesn't seem like something you would do anything > with other than asking "is it valid"). > > Another interesting question: how useful is this API? It was on the > list of impl_* method that Jonathan and I felt would be worth making > public API out of, but I don't know how prevalent its use is? > > -- Kevin > > > Tom Schindl wrote: >> As i see it the url is optional so wouldn't make sense to return >> Optional to make this more explicit? >> >> Tom >> >> Von meinem iPhone gesendet >> >>> Am 10.12.2015 um 21:54 schrieb Jonathan Giles >>> : >>> >>> Hi Chien, Kevin, >>> >>> Please can you review the following JBS issue (and attached patch): >>> >>> https://bugs.openjdk.java.net/browse/JDK-8145143 >>> >>> As the subject line states, this issue proposes to promote the >>> Image.impl_getUrl() method to Image.getUrl(), so that it is public API. >>> >>> -- >>> >>> >>> -- Jonathan >>> From chien.yang at oracle.com Thu Dec 10 22:34:41 2015 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 10 Dec 2015 14:34:41 -0800 Subject: [Review request] 8145143: Promote Image.impl_getUrl() to public API as Image.getUrl() In-Reply-To: <5669F9C9.2010908@oracle.com> References: <5669E69C.4020107@oracle.com> <79ECD854-BA8F-49B5-A920-A3367BE68C5E@bestsolution.at> <5669F113.7090905@oracle.com> <5669F9C9.2010908@oracle.com> Message-ID: <5669FE01.6040302@oracle.com> The patch looks good to me as it is. Question: Will the change to Optional makes it at odd with the existing public constructors? Or API cleanliness though I do see the beauty of using Optional here. - Chien On 12/10/15, 2:16 PM, David Grieve wrote: > I believe the url might be used in the CSS engine for caching images > loaded from .css files. If the css image cache is made public (I don't > know if that is planned, but it should be considered), then this API > will matter. > > On 12/10/15 4:39 PM, Kevin Rushforth wrote: >> That's an interesting question. We haven't used Optional for such >> cases except the return value of Dialog showAndWait. Wrapping the URL >> in an Optional is more self-documenting, but perhaps less convenient >> if you know that it is non-null (and basically the same if you don't >> know, since this doesn't seem like something you would do anything >> with other than asking "is it valid"). >> >> Another interesting question: how useful is this API? It was on the >> list of impl_* method that Jonathan and I felt would be worth making >> public API out of, but I don't know how prevalent its use is? >> >> -- Kevin >> >> >> Tom Schindl wrote: >>> As i see it the url is optional so wouldn't make sense to return >>> Optional to make this more explicit? >>> >>> Tom >>> >>> Von meinem iPhone gesendet >>> >>>> Am 10.12.2015 um 21:54 schrieb Jonathan Giles >>>> : >>>> >>>> Hi Chien, Kevin, >>>> >>>> Please can you review the following JBS issue (and attached patch): >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8145143 >>>> >>>> As the subject line states, this issue proposes to promote the >>>> Image.impl_getUrl() method to Image.getUrl(), so that it is public >>>> API. >>>> >>>> -- >>>> >>>> >>>> -- Jonathan >>>> > From kevin.rushforth at oracle.com Fri Dec 11 00:44:22 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 10 Dec 2015 16:44:22 -0800 Subject: [9] Review request: 8144680: Stage.alwaysOnTop() doesn't work if a security manager is set Message-ID: <566A1C66.3040102@oracle.com> David & Chien, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8144680 http://cr.openjdk.java.net/~kcr/8144680/webrev.00/ Thanks. -- Kevin From vadim.pakhnushev at oracle.com Fri Dec 11 14:30:10 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 11 Dec 2015 17:30:10 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <566ADDF2.4080705@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From David.Hill at Oracle.com Fri Dec 11 14:37:06 2015 From: David.Hill at Oracle.com (David Hill) Date: Fri, 11 Dec 2015 09:37:06 -0500 Subject: [9] Review request: 8144680: Stage.alwaysOnTop() doesn't work if a security manager is set In-Reply-To: <566A1C66.3040102@oracle.com> References: <566A1C66.3040102@oracle.com> Message-ID: <566ADF92.1040200@Oracle.com> On 12/10/15, 7:44 PM, Kevin Rushforth wrote: > David & Chien, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8144680 > http://cr.openjdk.java.net/~kcr/8144680/webrev.00/ > > Thanks. > > -- Kevin > +1 in the bug. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From victor.dyakov at oracle.com Fri Dec 11 17:28:55 2015 From: victor.dyakov at oracle.com (Victor D'yakov) Date: Fri, 11 Dec 2015 09:28:55 -0800 Subject: In(Sanity) Testing Mondays In-Reply-To: <566ADDF2.4080705@oracle.com> References: <566ADDF2.4080705@oracle.com> Message-ID: <566B07D7.1060804@oracle.com> Hi Vadim, Please include our new teammates to attend Sanity testing: Arunprasad Rajkumar Murali Billa Ankit Srivastava Please define assignments with Kevin next week to run starting next week. Thanks, Victor On 11.12.2015 6:30, Vadim Pakhnushev wrote: > Reminder, Monday is our weekly sanity testing. > > You can find your testing assignment at: > https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing > > Also please remember that the repo will be locked from 1am PST until > 1pm PST. > > Happy testing! > > Thanks, > Vadim From guru.hb at oracle.com Fri Dec 11 17:39:08 2015 From: guru.hb at oracle.com (Guru Hb) Date: Fri, 11 Dec 2015 09:39:08 -0800 (PST) Subject: [9] Review request for 8140501 : WebView crashes when loading content in a locationlistener Message-ID: <2efd6ecd-2204-4d66-8ecc-0bb2977f1a09@default> Updated webrev : http://cr.openjdk.java.net/~ghb/8140501/webrev.03/ Changes updated in JBS : https://bugs.openjdk.java.net/browse/JDK-8140501 ----- Original Message ----- From: guru.hb at oracle.com To: alexander.zvegintsev at oracle.com, arunprasad.rajkumar at oracle.com, kevin.rushforth at oracle.com Cc: openjfx-dev at openjdk.java.net Sent: Tuesday, December 1, 2015 10:26:23 AM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi Subject: RE: [9] Review request for 8140501 : WebView crashes when loading content in a locationlistener Hi Arun, Alexander & Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8140501/ Webrev : http://cr.openjdk.java.net/~ghb/8140501/webrev.01/ Regression test incorporated and Async loadcontent executed only in READY state. Thanks, Guru -----Original Message----- From: Guru Hb Sent: Monday, November 30, 2015 12:22 PM To: Alexander Zvegintsev; Arunprasad Rajkumar; Kevin C Rushforth Cc: openjfx-dev at openjdk.java.net Subject: [9] Review request for 8140501 : WebView crashes when loading content in a locationlistener Hi Arunprasad, Alexander & Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8140501 Webrev : http://cr.openjdk.java.net/~ghb/8140501/webrev.00/ Tested on Windows and Linux (both 64 bit). Thnaks, Guru From alexander.kouznetsov at oracle.com Sat Dec 12 01:21:37 2015 From: alexander.kouznetsov at oracle.com (Alexander Kouznetsov) Date: Fri, 11 Dec 2015 17:21:37 -0800 Subject: JavaFX on Raspberry Pi In-Reply-To: References: Message-ID: <566B76A1.9030606@oracle.com> I believe Gluon has support for camera. Not sure what platforms are supported, though. Best regards, Alexander Kouznetsov (408) 276-0387 On 5 ??? 2015 20:37, Scott Palmer wrote: > Thanks, that worked. > > Now I have to see how easily I can get he Device I/O stuff working. If I'm lucky, I might even get the camera writing into a WritableImage. > > Cheers, > > Scott > >> On Dec 5, 2015, at 10:00 PM, Jonathan Giles wrote: >> >> I've not tested myself, but this might help: >> >> http://gluonhq.com/gluon-supports-javafx-embedded-binary-builds-now-available/ >> >> -- Jonathan >> Sent from a touch device. Please excuse my brevity. >> >>> On 6 December 2015 15:29:27 GMT+13:00, Scott Palmer wrote: >>> I seem to recall that the Arm builds of Java 8 no longer include JavaFX. I just installed 8u65 on my Raspberry Pi and that does in fact appear to be the case. >>> >>> The web page https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+the+Raspberry+Pi was last updated in June and it implies that JavaFX is included in the Java 8 Arm build. Where do I find the current instructions for getting JavaFX onto a Raspberry Pi? >>> >>> Is there anything pre-built available, or am I forced to build it myself with the instructions here: https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float ? >>> >>> I?m using a Mac, and the instructions say that mainly Linux is used to cross-build for Arm, so hopefully I won?t get stuck in build hell :-) >>> >>> I also noticed that JavaME builds include the Device I/O API (http://docs.oracle.com/javame/8.0/api/dio/api/index.html) >>> Is it possible to use these APIs and JavaFX on a Raspberry Pi at the same time? Can the Device I/O libraries (.jar and .so) simply be copied over from a JavaME install to a JavaSE install? Do Java 9 modules help with any of that? >>> >>> >>> Regards, >>> >>> Scott From hastebrot at gmail.com Mon Dec 14 10:41:04 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Mon, 14 Dec 2015 11:41:04 +0100 Subject: Public API for robot classes in JDK 9 Message-ID: The missing public API for robots (`com.sun.glass.ui.Robot` and `com.sun.javafx.robot.FXRobot`) is causing me sleepless nights. Here ( https://github.com/TestFX/Robot) is a small prototype for a possible API to ignite some discussion. In case the proposed delay of JDK 9 ( http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html) takes place. About the architecture: In the prototype I decided to not touch classes in `com.sun.glass.ui` and instead provide "wrapper" classes. This is a pattern which is also used for other classes in the JavaFX codebase, to provide a public API for functionality from e.g. `com.sun.prism` and `com.sun.javafx`. Additionally `com.sun.glass.ui.Robot` has dependencies to other private classes in its package and to native bindings to different operating systems and Monocle. About the implementation: - `javafx.application.ApplicationMixin::createGlassRobot()` returns a new `javafx.application.util.GlassRobot`. The methods of `ApplicationMixin` will of course find their places in `javafx.application.Application` eventually. - The `GlassRobot` is in the `javafx.util` package. It could also go into a new `javafx.robot` package instead. `GlassRobot` uses classes from the JavaFX API like `KeyCode`, `Point2D` and `MouseButton` instead of primitive types which are used by `com.sun.glass.ui.Robot`. (I've created a new mail thread in order to permalink to it and allow others without JIRA writing access to participate in the discussion. A JIRA ticket should be definately created via bugs.java.com -- if none already exist; I'll check this. I also know the code needs to be patch files into order to be merged into HG.) --Benjamin From Dell.Green at ideaworks.co.uk Mon Dec 14 11:48:05 2015 From: Dell.Green at ideaworks.co.uk (Dell Green) Date: Mon, 14 Dec 2015 11:48:05 +0000 Subject: Armv6hf cross compile build compiles host version of some native libraries Message-ID: Hi Guys, On closer inspection of running an Armv6hf build we have discovered that we are getting out host versions of some libraries in our build. Please see below for contents of our rt/lib/arm folder: gradle -PCOMPILE_TARGETS=armv6hf sdk build/armv6hf-sdk/rt/lib/arm/libdecora_sse.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=8052ae5d7f230ee0629743f9ee421371e3522538, not stripped build/armv6hf-sdk/rt/lib/arm/libfxplugins.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=87241c5679bcd9b7d738aff08a539f889d6105bb, not stripped build/armv6hf-sdk/rt/lib/arm/libglass_monocle.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=f9305441860f255079646812acf50ef46774317e, not stripped build/armv6hf-sdk/rt/lib/arm/libglass_monocle_x11.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=d1735e47b13e56d58d4e9b7a7f6dee338ccccd9f, not stripped build/armv6hf-sdk/rt/lib/arm/libglass.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=6b349cfc4b349f858dd24f5cfbef7eb446c089cc, not stripped build/armv6hf-sdk/rt/lib/arm/libgstreamer-lite.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=b83f109a6b80bd56120e4bf8f8b7f5d1eb7b1bc8, not stripped build/armv6hf-sdk/rt/lib/arm/libjavafx_font_freetype.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=3decd38bb952c5fefde54a1ad1f01b39799a45e6, not stripped build/armv6hf-sdk/rt/lib/arm/libjavafx_font_pango.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=5652ddbd48bf62a10213474aadc8b5bbfae3e494, not stripped build/armv6hf-sdk/rt/lib/arm/libjavafx_font.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=c84058878ffaeebf60be04eb0d138ecf3fdf5cd1, not stripped build/armv6hf-sdk/rt/lib/arm/libjavafx_iio.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=fd4e40c059944941d52bf88b48121d0815531bd0, not stripped build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2530edd674a52bb07c487b5cd726babc266b2013, not stripped build/armv6hf-sdk/rt/lib/arm/libjfxwebkit.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=0cd8f455ee93e101a5d4442027a8248d675a0888, stripped build/armv6hf-sdk/rt/lib/arm/libprism_common.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=658886a9bead9068f4111679e8f5f350386d235b, not stripped build/armv6hf-sdk/rt/lib/arm/libprism_es2_eglfb.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=25264a33f919a3a925ef2d2f8ec5d4a10bfbdbf9, not stripped build/armv6hf-sdk/rt/lib/arm/libprism_es2_monocle.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=6827d044682876f8ace57cfdc3417e026688701c, not stripped build/armv6hf-sdk/rt/lib/arm/libprism_sw.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=1159563bbed17f830c3c64cdf16d3790fa91a713, not stripped We decided that those particular libraries were not required for the project we were currently doing so decided to use gradle.properties to disable the compiling of these. It turns out changing the gradle.properties values have no impact on the production of native libraries with them always being produced irrespective of any changes made to gradle.properties file. Also tried supplying the properties at command line to gradle command and some problem. Further investigation shows that the following messages are being piped to stdout during build whether I change anything or not, with the end result still compiling native libraries for these as host versions. "Not compiling native Media for armv6hf per configuration request" "Not compiling native Webkit for armv6hf per configuration request" Am I doing something wrong? I have followed instructions as per the wiki apart from installing QT 5.2 as don?t require webkit for my projects. Dell Green R&D Software Manager t: (+44)203 668 9870 206 Great Portland Street London W1W 5QJ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726 From kevin.rushforth at oracle.com Mon Dec 14 21:17:39 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 14 Dec 2015 13:17:39 -0800 Subject: 9-dev unlocked following sanity testing Message-ID: <566F31F3.2000901@oracle.com> From kevin.rushforth at oracle.com Mon Dec 14 22:02:46 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 14 Dec 2015 14:02:46 -0800 Subject: gradle 2.9 is now required to build FX 9-dev Message-ID: <566F3C86.7090600@oracle.com> I just pushed a changeset to 9-dev [1] making gradle 2.9 the minimum version as indicated in [2]. Anyone who has not yet updated to gradle 2.9 must do so in order to be able to build 9-dev starting today. -- Kevin [1] http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/4612daff0009 [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-November/018210.html From felix.bembrick at gmail.com Tue Dec 15 08:05:05 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 15 Dec 2015 19:05:05 +1100 Subject: Oracle's mobile JDK ports & JavaFX Message-ID: <578410B9-236B-460B-B89D-0A175DEE0956@gmail.com> With Oracle now officially announcing their intention to port the Java 9 JDK to iOS, Android and even Windows Phone, how does this impact or fit in with the current work being done through OpenJFXPorts and Gluon with JavaFX? Is it something that could be used with JavaFX, complementing the existing work or would it be a completely new strategy for porting Java and JavaFX to mobile platforms? Could it potentially result in a faster port of JavaFX on those platforms? Thanks, Felix From johan.vos at gluonhq.com Tue Dec 15 08:50:22 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 15 Dec 2015 09:50:22 +0100 Subject: Oracle's mobile JDK ports & JavaFX In-Reply-To: <578410B9-236B-460B-B89D-0A175DEE0956@gmail.com> References: <578410B9-236B-460B-B89D-0A175DEE0956@gmail.com> Message-ID: Hi Felix, The Oracle Mobile JVM ports are headless so they are very complimentary to the work done in javafxports/Gluon. A couple of months ago, we tested the iOS simulator (created a JDK 9 build and added a slightly modified javafxports version on top) with a simple JavaFX app and that worked nice. Have a look at https://twitter.com/eryzhikov/status/659148074397229056 for a short movie on how it looks like. In general, JavaFX just requires a JVM to run, and it doesn't matter if this is provided by Oracle, RoboVM or Dalvik/ART. However, having a single codebase for the VM that runs on desktop and the VM's that run on mobile is a huge advantage. It is still early to tell, but I am very excited about this project. With this project, you can write your Java Client apps in Java 9 and run them on almost any device. Combine that with JavaFX 9 and you have a great platform for UI development. One codebase, one language, almost all devices. It sounds marketing talk but it is the technical reality. To be honest, I don't have too high expectations for performance at this moment. But it is something that can be worked on. From what I've seen, there are some really smart people working on it. I hope there will be many contributions from inside and outside of Oracle to this project. So I hope it results in faster apps, but don't expect amazing performance gains from day one. Unrelated, we are still working on performance enhancements inside JavaFXPorts, and those are mainly native so the VM won't have a big impact on this. We will add the option to select a specific JVM (RoboVM free/commercial/OpenJDK/Android) in the jfxmobile plugin, and let developers decide what they want to bundle their app with. This blog post might be interesting to you: http://gluonhq.com/gluon-supports-multiple-jvms/ - Johan On Tue, Dec 15, 2015 at 9:05 AM, Felix Bembrick wrote: > With Oracle now officially announcing their intention to port the Java 9 > JDK to iOS, Android and even Windows Phone, how does this impact or fit in > with the current work being done through OpenJFXPorts and Gluon with JavaFX? > > Is it something that could be used with JavaFX, complementing the existing > work or would it be a completely new strategy for porting Java and JavaFX > to mobile platforms? > > Could it potentially result in a faster port of JavaFX on those platforms? > > Thanks, > > Felix From markus at headcrashing.eu Tue Dec 15 09:22:28 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 15 Dec 2015 10:22:28 +0100 Subject: Oracle's mobile JDK ports & JavaFX In-Reply-To: References: <578410B9-236B-460B-B89D-0A175DEE0956@gmail.com> Message-ID: <00d001d1371a$1e535470$5af9fd50$@eu> This sounds very encouraging! Are there any forecasts of a time frame when this will be stable enough to let us "play" with? :-) -Markus (TeamFX) -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Johan Vos Sent: Dienstag, 15. Dezember 2015 09:50 To: Felix Bembrick Cc: openjfx-dev at openjdk.java.net Subject: Re: Oracle's mobile JDK ports & JavaFX Hi Felix, The Oracle Mobile JVM ports are headless so they are very complimentary to the work done in javafxports/Gluon. A couple of months ago, we tested the iOS simulator (created a JDK 9 build and added a slightly modified javafxports version on top) with a simple JavaFX app and that worked nice. Have a look at https://twitter.com/eryzhikov/status/659148074397229056 for a short movie on how it looks like. In general, JavaFX just requires a JVM to run, and it doesn't matter if this is provided by Oracle, RoboVM or Dalvik/ART. However, having a single codebase for the VM that runs on desktop and the VM's that run on mobile is a huge advantage. It is still early to tell, but I am very excited about this project. With this project, you can write your Java Client apps in Java 9 and run them on almost any device. Combine that with JavaFX 9 and you have a great platform for UI development. One codebase, one language, almost all devices. It sounds marketing talk but it is the technical reality. To be honest, I don't have too high expectations for performance at this moment. But it is something that can be worked on. From what I've seen, there are some really smart people working on it. I hope there will be many contributions from inside and outside of Oracle to this project. So I hope it results in faster apps, but don't expect amazing performance gains from day one. Unrelated, we are still working on performance enhancements inside JavaFXPorts, and those are mainly native so the VM won't have a big impact on this. We will add the option to select a specific JVM (RoboVM free/commercial/OpenJDK/Android) in the jfxmobile plugin, and let developers decide what they want to bundle their app with. This blog post might be interesting to you: http://gluonhq.com/gluon-supports-multiple-jvms/ - Johan On Tue, Dec 15, 2015 at 9:05 AM, Felix Bembrick wrote: > With Oracle now officially announcing their intention to port the Java > 9 JDK to iOS, Android and even Windows Phone, how does this impact or > fit in with the current work being done through OpenJFXPorts and Gluon with JavaFX? > > Is it something that could be used with JavaFX, complementing the > existing work or would it be a completely new strategy for porting > Java and JavaFX to mobile platforms? > > Could it potentially result in a faster port of JavaFX on those platforms? > > Thanks, > > Felix From tom.schindl at bestsolution.at Tue Dec 15 10:34:19 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 15 Dec 2015 11:34:19 +0100 Subject: Oracle's mobile JDK ports & JavaFX In-Reply-To: <578410B9-236B-460B-B89D-0A175DEE0956@gmail.com> References: <578410B9-236B-460B-B89D-0A175DEE0956@gmail.com> Message-ID: <566FECAB.6080108@bestsolution.at> Hi, If I read this correct [1]: * Zero is an interpreter only VM hence it it is slow * Shark does provide JIT features but * on iOS you are not allowed to produce exectuable code at runtime hence you stick with the interpreter only * AOT is not on the table for Zero/Shark, at least I didn't find any information on that Anyways I think OpenJFX is not the mailing list to discuss this, I guess. [1]http://openjdk.java.net/projects/zero/ On 15.12.15 09:05, Felix Bembrick wrote: > With Oracle now officially announcing their intention to port the Java 9 JDK to iOS, Android and even Windows Phone, how does this impact or fit in with the current work being done through OpenJFXPorts and Gluon with JavaFX? > > Is it something that could be used with JavaFX, complementing the existing work or would it be a completely new strategy for porting Java and JavaFX to mobile platforms? > > Could it potentially result in a faster port of JavaFX on those platforms? > > Thanks, > > Felix > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From david.dehaven at oracle.com Tue Dec 15 18:09:02 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 15 Dec 2015 10:09:02 -0800 Subject: [8u-dev] Review Request for 8144678: JVM crashes when selecting video on youtube in WebView Message-ID: Kevin, Alexander, can you please review this fairly trivial fix: https://bugs.openjdk.java.net/browse/JDK-8144678 The fix is only five lines, no webrev. It's pasted in a comment and below for reference. --- cut here --- diff --git a/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm b/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm --- a/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm +++ b/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm @@ -401,6 +401,11 @@ - (void) dispose { @synchronized(self) { if (!isDisposed) { + if (_player != nil) { + // this should stop and dealloc the audio processor + _player.currentItem.audioMix = nil; + } + if (_playerOutput != nil) { [_playerItem removeOutput:_playerOutput]; [_playerOutput setDelegate:nil queue:nil]; --- cut here --- -DrD- From kevin.rushforth at oracle.com Tue Dec 15 18:40:15 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Dec 2015 10:40:15 -0800 Subject: [8u-dev] Review Request for 8144678: JVM crashes when selecting video on youtube in WebView In-Reply-To: References: Message-ID: <56705E8F.1070207@oracle.com> This is going into 9-dev first, right? I'll add comments in JIRA. -- Kevin David DeHaven wrote: > Kevin, Alexander, can you please review this fairly trivial fix: > https://bugs.openjdk.java.net/browse/JDK-8144678 > > The fix is only five lines, no webrev. It's pasted in a comment and below for reference. > > --- cut here --- > diff --git a/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm b/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm > --- a/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm > +++ b/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm > @@ -401,6 +401,11 @@ > - (void) dispose { > @synchronized(self) { > if (!isDisposed) { > + if (_player != nil) { > + // this should stop and dealloc the audio processor > + _player.currentItem.audioMix = nil; > + } > + > if (_playerOutput != nil) { > [_playerItem removeOutput:_playerOutput]; > [_playerOutput setDelegate:nil queue:nil]; > --- cut here --- > > -DrD- > > From kevin.rushforth at oracle.com Tue Dec 15 18:47:27 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Dec 2015 10:47:27 -0800 Subject: [9] Review request: 8133750: Parse new JDK version string format in build.gradle Message-ID: <5670603F.7080706@oracle.com> Chien, David, and all, Please review the version string changes in build.gradle to prepare for using a JDK 9 with the new version string format for JEP 223 (aka Verona). https://bugs.openjdk.java.net/browse/JDK-8133750 http://cr.openjdk.java.net/~kcr/8133750/webrev.00/ I have tested this with a JDK 8u40 fcs build, 8u45 fcs build, jdk8u-dev local build, JDK 9 pre-Verona ea build, JDK 9-ea+96 post-Verona build, and a local jdk9-dev build. -- Kevin From david.dehaven at oracle.com Tue Dec 15 19:18:39 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 15 Dec 2015 11:18:39 -0800 Subject: [8u-dev] Review Request for 8144678: JVM crashes when selecting video on youtube in WebView In-Reply-To: <56705E8F.1070207@oracle.com> References: <56705E8F.1070207@oracle.com> Message-ID: <930ACFC6-A768-415F-9ED0-11DAFB09DCE2@oracle.com> Yes, I can push to 9-dev first. -DrD- > This is going into 9-dev first, right? I'll add comments in JIRA. > > -- Kevin > > > David DeHaven wrote: >> Kevin, Alexander, can you please review this fairly trivial fix: >> https://bugs.openjdk.java.net/browse/JDK-8144678 >> >> The fix is only five lines, no webrev. It's pasted in a comment and below for reference. >> >> --- cut here --- >> diff --git a/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm b/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm >> --- a/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm >> +++ b/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm >> @@ -401,6 +401,11 @@ >> - (void) dispose { >> @synchronized(self) { >> if (!isDisposed) { >> + if (_player != nil) { >> + // this should stop and dealloc the audio processor >> + _player.currentItem.audioMix = nil; >> + } >> + >> if (_playerOutput != nil) { >> [_playerItem removeOutput:_playerOutput]; >> [_playerOutput setDelegate:nil queue:nil]; >> --- cut here --- >> >> -DrD- >> >> From guru.hb at oracle.com Tue Dec 15 23:38:18 2015 From: guru.hb at oracle.com (Guru Hb) Date: Tue, 15 Dec 2015 15:38:18 -0800 (PST) Subject: [9] Review request: 8139842: NullPointerException in WCPageBackBufferImpl when a WebView is too large Message-ID: Hi Kevin, Jim, Alexander Please provide your review comments for JBS : https://bugs.openjdk.java.net/browse/JDK-8139842 Webrev : http://cr.openjdk.java.net/~ghb/8139842/webrev.00/ Tested on Windows , Linux and Mac. Thanks, Guru From robert.fisher.ext at zeiss.com Wed Dec 16 07:33:50 2015 From: robert.fisher.ext at zeiss.com (Fisher, Robert) Date: Wed, 16 Dec 2015 07:33:50 +0000 Subject: WebView is eating our Cookies Message-ID: <025E25CA98F8AE46BE306AB33F6A38D50127FE13@ADEFUE01SMS003.cznet.zeiss.org> I have a question about this bug: https://bugs.openjdk.java.net/browse/JDK-8027021 It's over 2 years old at this point, so I wonder if it has fallen through the cracks. For us it means as soon as anyone instantiates a WebView anywhere in our app, our REST clients stop processing Cookies correctly. Is it on the agenda at all? Below I've included a test program using jersey-client 1.18.1 and the output in our case. Cheers, Rob ------------------- public class WebViewBug extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage stage) throws Exception { callAndPrintResponseInfo(); new WebView(); callAndPrintResponseInfo(); } private void callAndPrintResponseInfo() { String url = "some URL that returns a cookie in its response header"; Client client = Client.create(); ClientResponse response = client.resource(url).accept(MediaType.APPLICATION_XML_TYPE).get(ClientResponse.class); System.out.println(); System.out.println("Status: " + response.getStatus()); System.out.println("Set-Cookie: " + response.getHeaders().getFirst("Set-Cookie")); System.out.println("Content-Type: " + response.getHeaders().getFirst("Content-Type")); } } ------------------- Status: 200 Set-Cookie: JSESSIONID=9a5873b18b843c2bece162e36b0c; Path=[not relevant]; HttpOnly Content-Type: application/xml Status: 200 Set-Cookie: Content-Type: application/xml From rahman.usta.88 at gmail.com Wed Dec 16 13:20:41 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Wed, 16 Dec 2015 15:20:41 +0200 Subject: New annotation suggestion @WebkitCall Message-ID: Hi; When calling Java method from WebView component, I generally forget which methods are called from JavaScript side. For that reason, I created an annotation called @WebkitCall to represent which methods called from JS side. Like this https://github.com/asciidocfx/AsciidocFX/blob/b0c4d94e7cad95bb8aa6d6da8feb50a1c8236bab/src/main/java/com/kodcu/component/WebkitCall.java What do you think? Thanks -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From kevin.rushforth at oracle.com Wed Dec 16 13:28:36 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Dec 2015 05:28:36 -0800 Subject: WebView is eating our Cookies In-Reply-To: <025E25CA98F8AE46BE306AB33F6A38D50127FE13@ADEFUE01SMS003.cznet.zeiss.org> References: <025E25CA98F8AE46BE306AB33F6A38D50127FE13@ADEFUE01SMS003.cznet.zeiss.org> Message-ID: <56716704.3020707@oracle.com> I see that this bug was filed against core-libs and not javafx, so we have never seen the bug report until now. -- Kevin Fisher, Robert wrote: > I have a question about this bug: > > https://bugs.openjdk.java.net/browse/JDK-8027021 > > It's over 2 years old at this point, so I wonder if it has fallen through the cracks. For us it means as soon as anyone instantiates a WebView anywhere in our app, our REST clients stop processing Cookies correctly. > > Is it on the agenda at all? > > Below I've included a test program using jersey-client 1.18.1 and the output in our case. > > Cheers, > Rob > > ------------------- > > public class WebViewBug extends Application { > > public static void main(String[] args) { > launch(args); > } > > @Override > public void start(Stage stage) throws Exception { > callAndPrintResponseInfo(); > new WebView(); > callAndPrintResponseInfo(); > } > > private void callAndPrintResponseInfo() { > String url = "some URL that returns a cookie in its response header"; > Client client = Client.create(); > ClientResponse response = client.resource(url).accept(MediaType.APPLICATION_XML_TYPE).get(ClientResponse.class); > > System.out.println(); > System.out.println("Status: " + response.getStatus()); > System.out.println("Set-Cookie: " + response.getHeaders().getFirst("Set-Cookie")); > System.out.println("Content-Type: " + response.getHeaders().getFirst("Content-Type")); > } > } > > ------------------- > > Status: 200 > Set-Cookie: JSESSIONID=9a5873b18b843c2bece162e36b0c; Path=[not relevant]; HttpOnly > Content-Type: application/xml > > Status: 200 > Set-Cookie: > Content-Type: application/xml > From james.graham at oracle.com Wed Dec 16 20:38:54 2015 From: james.graham at oracle.com (Jim Graham) Date: Wed, 16 Dec 2015 12:38:54 -0800 Subject: [9] Review request: 8139842: NullPointerException in WCPageBackBufferImpl when a WebView is too large In-Reply-To: References: Message-ID: <5671CBDE.4050100@oracle.com> A formatting nit - "if" is not a function, it is a control statement and so there should always be a space between it and the condition being tested: "if(foo)" => "if (foo)" Just to make sure we are on the same page, ResourceFactory.getMaxTextureSize() is clamped by an arbitrary limit we use for tiling ImageView images. It's not actually the limit enforced by hardware and can be less than that. As to the correctness of the fix - if w,h are clipped to the maximum texture size, where is the code that then tiles the content of the page so that it doesn't get clipped out? I experimented with a very large web page (I just cut and pasted 20 paragraphs of "Lorem ipsum dolor" text created by a generator into an HTML file and loaded it into the WebView's engine) and it seems that what happens is that your clipping of the WebPage makes it smaller than the indicated size and the WebView rendering somehow then manages to tile that image into the requested space. In other words, you get multiple horizontal copies of the page to fill out the horizontal space. This doesn't "fix" the problem, it simply avoids an exception. To adequately fix the problem we'd have to detect that the corresponding WebPage object was created smaller than the indicated size and tile the content into multiple WebPage objects - but WebPage is not set up for that. There is tiling support for the page itself at a lower level - we should rework WebPage so that instead of creating a single texture for all of the webkit tiles, it creates one per webkit tile and so ties naturally into the existing tiling at the lower levels of webkit... ...jim On 12/15/15 3:38 PM, Guru Hb wrote: > Hi Kevin, Jim, Alexander > > Please provide your review comments for > > JBS : https://bugs.openjdk.java.net/browse/JDK-8139842 > > Webrev : http://cr.openjdk.java.net/~ghb/8139842/webrev.00/ > > Tested on Windows , Linux and Mac. > > Thanks, > > Guru > From alexander.casall at saxsys.de Thu Dec 17 11:02:52 2015 From: alexander.casall at saxsys.de (Casall, Alexander) Date: Thu, 17 Dec 2015 11:02:52 +0000 Subject: MediaView does not play video on Ubuntu Message-ID: <7E691632-A427-4CBD-BD8F-AE66DC08457E@saxsys.de> Hi, I?m trying to get the MediaView running on an Ubuntu 14.04 Target JRE: 1.8.0_66-b17 I?m building the app on Mac with: jdk1.8.0_40.jdk The Video is h264 encoded and is running perfectly on the MacOS. When I launch it on Ubuntu the MediaView just shows a blank screen, no exceptions, nothing. Any suggestions? Cheers Alex From kevin.rushforth at oracle.com Thu Dec 17 14:21:36 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Dec 2015 06:21:36 -0800 Subject: Update on FX plans for JDK 9 Message-ID: <5672C4F0.20901@oracle.com> Given the recently announced JDK 9 schedule slip [1], we have taken the opportunity to explore what RFE's / Features we could possibly now work on for inclusion in JDK 9. We wanted to give you a pre-holiday season update on what we are currently thinking. The following RFEs are in progress or planned for JDK 9: JDK-8144585: Encapsulate JavaFX impl_* implementation methods JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs JDK-8091308: Define fine-grained permissions for JavaFX Expose Hi-DPI properties for render scale and screen scale (FX equivalent task for JEP 263 JDK-8055212) Multi-resolution image support (FX equivalent task for JEP 251 JDK-8046010) Additionally, we have started to look into making public API for some of the impl_* API that will otherwise be hidden by JDK-8144585. See Jonathan's earlier e-mail on the subject [2]. Here is what we have so far: JDK-8144628: Provide API to expose list of showing Windows JDK-8144625: Expose code and char properties on KeyCode JDK-8144962: Promote TableColumn reorderable property to public API JDK-8144871: Add default method getStyleableNode to Styleable interface JDK-8145143: Promote Image.impl_getUrl() to public API as Image.getUrl() JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and Labeled If there are any we have missed that your application depends on, please send e-mail to Jonathan. Finally, here is an updated list of other RFEs we might consider for JDK 9. We will not be able to do all of these, but hope to be able to do many of them. We could use the help of the OpenJFX community in prioritizing this list or possibly adding something that we missed, as long as the scope is small enough. JDK-8091107: Add java.awt.Desktop support to javafx JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX (FX equivalent for JEP 272) JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux JDK-8092040: Implement Image writers for JavaFX JDK-8091673: Runtime should have a published focus traversal API for use in custom controls JDK-8089311: [TableCell] commit on focus lost not possible in every case JDK-8090477: Customizable visibility timing for Tooltip JDK-8092098: [TabPane] Support for draggable tabs JDK-8144556: Add support to allow user specified rendering order JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer for non-applet Stage JDK-8145154: Provide public API support for PerformanceTracker functionality JDK-8090763: Public API for Glass's robot functionality Let us know what is most important to your application. We will keep you posted with updates on what exactly is being targeted (note that you can track it by looking at the Fix Version in JBS, which we strive to keep up-to-date). Thanks! -- Kevin [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html From j.kapitza at schwarze-allianz.de Thu Dec 17 14:43:45 2015 From: j.kapitza at schwarze-allianz.de (Jens Kapitza) Date: Thu, 17 Dec 2015 15:43:45 +0100 Subject: MediaView does not play video on Ubuntu In-Reply-To: <7E691632-A427-4CBD-BD8F-AE66DC08457E@saxsys.de> References: <7E691632-A427-4CBD-BD8F-AE66DC08457E@saxsys.de> Message-ID: <1450363425.14396.6.camel@schwarze-allianz.de> Hi, are the -extra codecs installed? http://askubuntu.com/questions/214421/how-to-install-the-mpeg-4-aac-dec oder-and-the-h-264-decoder F?r Ubuntu 15.10 k?nnte das hier helfen?!: sudo apt-get install libavcodec-extra libavcodec-ffmpeg-extra56 libav-tools ffmpeg Am Donnerstag, den 17.12.2015, 11:02 +0000 schrieb Casall, Alexander: > Hi, > > I?m trying to get the MediaView running on an Ubuntu 14.04 > > Target JRE: 1.8.0_66-b17 > I?m building the app on Mac with: jdk1.8.0_40.jdk > > The Video is h264 encoded and is running perfectly on the MacOS. > > When I launch it on Ubuntu the MediaView just shows a blank screen, > no exceptions, nothing. > > Any suggestions? > > Cheers Alex > > From elina.kleyman at oracle.com Thu Dec 17 17:12:03 2015 From: elina.kleyman at oracle.com (Elina Kleyman Matok) Date: Thu, 17 Dec 2015 09:12:03 -0800 (PST) Subject: [9] Review request for 8144686 - PathElement.isAbsolute() return value changes after calling absoluteProperty() Message-ID: Chien, Kevin, guys, Please review my fix for next issue: JIRA: https://bugs.openjdk.java.net/browse/JDK-8144686 WEBREV: http://cr.openjdk.java.net/~ekleyman/8144686_3/ Thanks, Elina From markus at headcrashing.eu Thu Dec 17 17:31:41 2015 From: markus at headcrashing.eu (Markus KARG) Date: Thu, 17 Dec 2015 18:31:41 +0100 Subject: Update on FX plans for JDK 9 In-Reply-To: <5672C4F0.20901@oracle.com> References: <5672C4F0.20901@oracle.com> Message-ID: <011901d138f0$cb553300$61ff9900$@eu> Does you plan to make more APIs public the Area class? Applications which simply want to register events like "when the mouse hovers of this area of a picture then notify me" where 'area' is an arbitrarily shaped region of the screen. Currently this has to be done with invisible Shapes, which 'feels' to be the wrong way as there is an Area class inside of JavaFX. :-) -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Donnerstag, 17. Dezember 2015 15:22 To: openjfx-dev at openjdk.java.net Subject: Update on FX plans for JDK 9 Given the recently announced JDK 9 schedule slip [1], we have taken the opportunity to explore what RFE's / Features we could possibly now work on for inclusion in JDK 9. We wanted to give you a pre-holiday season update on what we are currently thinking. The following RFEs are in progress or planned for JDK 9: JDK-8144585: Encapsulate JavaFX impl_* implementation methods JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs JDK-8091308: Define fine-grained permissions for JavaFX Expose Hi-DPI properties for render scale and screen scale (FX equivalent task for JEP 263 JDK-8055212) Multi-resolution image support (FX equivalent task for JEP 251 JDK-8046010) Additionally, we have started to look into making public API for some of the impl_* API that will otherwise be hidden by JDK-8144585. See Jonathan's earlier e-mail on the subject [2]. Here is what we have so far: JDK-8144628: Provide API to expose list of showing Windows JDK-8144625: Expose code and char properties on KeyCode JDK-8144962: Promote TableColumn reorderable property to public API JDK-8144871: Add default method getStyleableNode to Styleable interface JDK-8145143: Promote Image.impl_getUrl() to public API as Image.getUrl() JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and Labeled If there are any we have missed that your application depends on, please send e-mail to Jonathan. Finally, here is an updated list of other RFEs we might consider for JDK 9. We will not be able to do all of these, but hope to be able to do many of them. We could use the help of the OpenJFX community in prioritizing this list or possibly adding something that we missed, as long as the scope is small enough. JDK-8091107: Add java.awt.Desktop support to javafx JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX (FX equivalent for JEP 272) JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux JDK-8092040: Implement Image writers for JavaFX JDK-8091673: Runtime should have a published focus traversal API for use in custom controls JDK-8089311: [TableCell] commit on focus lost not possible in every case JDK-8090477: Customizable visibility timing for Tooltip JDK-8092098: [TabPane] Support for draggable tabs JDK-8144556: Add support to allow user specified rendering order JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer for non-applet Stage JDK-8145154: Provide public API support for PerformanceTracker functionality JDK-8090763: Public API for Glass's robot functionality Let us know what is most important to your application. We will keep you posted with updates on what exactly is being targeted (note that you can track it by looking at the Fix Version in JBS, which we strive to keep up-to-date). Thanks! -- Kevin [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html From tom.schindl at bestsolution.at Thu Dec 17 18:10:52 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 17 Dec 2015 19:10:52 +0100 Subject: Update on FX plans for JDK 9 In-Reply-To: <5672C4F0.20901@oracle.com> References: <5672C4F0.20901@oracle.com> Message-ID: <5672FAAC.8060702@bestsolution.at> [...] > JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux This is a real problem for the SWT-FX integration because SWT is more and more setting GTK3 as the default. We (the OSGi-FXClassloader) currently saves people from hard core-dumps by refusing to load FXCanvas but they'll get a CNF instead with a decent error message why we refused to load that classes. Naturally this requires FXCanvas to work in FX9 but that is a different topic ;-) Tom -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From tom.schindl at bestsolution.at Thu Dec 17 18:19:23 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 17 Dec 2015 19:19:23 +0100 Subject: Update on FX plans for JDK 9 In-Reply-To: <5672C4F0.20901@oracle.com> References: <5672C4F0.20901@oracle.com> Message-ID: <5672FCAB.8000703@bestsolution.at> Hi, I have a another API I'd like to get into FX9 which makes my implementation of Source-Code editors smoother: https://bugs.openjdk.java.net/browse/JDK-8090688 It even has a patch which most likely does not apply any more because of the whole stuff getting public API but I would recreate it if it gets on the FX9 list. Tom On 17.12.15 15:21, Kevin Rushforth wrote: > Given the recently announced JDK 9 schedule slip [1], we have taken the > opportunity to explore what RFE's / Features we could possibly now work > on for inclusion in JDK 9. We wanted to give you a pre-holiday season > update on what we are currently thinking. > > The following RFEs are in progress or planned for JDK 9: > > JDK-8144585: Encapsulate JavaFX impl_* implementation methods > JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs > JDK-8091308: Define fine-grained permissions for JavaFX > Expose Hi-DPI properties for render scale and screen scale (FX > equivalent task for JEP 263 JDK-8055212) > Multi-resolution image support (FX equivalent task for JEP 251 > JDK-8046010) > > Additionally, we have started to look into making public API for some of > the impl_* API that will otherwise be hidden by JDK-8144585. See > Jonathan's earlier e-mail on the subject [2]. Here is what we have so far: > > JDK-8144628: Provide API to expose list of showing Windows > JDK-8144625: Expose code and char properties on KeyCode > JDK-8144962: Promote TableColumn reorderable property to public API > JDK-8144871: Add default method getStyleableNode to Styleable interface > JDK-8145143: Promote Image.impl_getUrl() to public API as Image.getUrl() > JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and > Labeled > > If there are any we have missed that your application depends on, please > send e-mail to Jonathan. > > Finally, here is an updated list of other RFEs we might consider for JDK > 9. We will not be able to do all of these, but hope to be able to do > many of them. We could use the help of the OpenJFX community in > prioritizing this list or possibly adding something that we missed, as > long as the scope is small enough. > > JDK-8091107: Add java.awt.Desktop support to javafx > JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX > (FX equivalent for JEP 272) > JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux > JDK-8092040: Implement Image writers for JavaFX > JDK-8091673: Runtime should have a published focus traversal API for > use in custom controls > JDK-8089311: [TableCell] commit on focus lost not possible in every case > JDK-8090477: Customizable visibility timing for Tooltip > JDK-8092098: [TabPane] Support for draggable tabs > JDK-8144556: Add support to allow user specified rendering order > JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer > for non-applet Stage > JDK-8145154: Provide public API support for PerformanceTracker > functionality > JDK-8090763: Public API for Glass's robot functionality > > Let us know what is most important to your application. > > We will keep you posted with updates on what exactly is being targeted > (note that you can track it by looking at the Fix Version in JBS, which > we strive to keep up-to-date). > > Thanks! > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html > [2] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html > > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From mp at jugs.org Thu Dec 17 18:39:28 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Thu, 17 Dec 2015 19:39:28 +0100 Subject: Update on FX plans for JDK 9 In-Reply-To: <5672C4F0.20901@oracle.com> References: <5672C4F0.20901@oracle.com> Message-ID: <56730160.4050800@jugs.org> Hi, what I am missing in this list are any activities to generally improve the interaction of JavaFX applications with the operating system they are running on. Some of these issues may be covered in an OS specific way by "JDK-8091517: Implement com.apple.eawt APIs ..." but should actually be treated in a more general way. For example double clicking a file and launching an associated JavaFX application. This is a concept which is used by all major operating systems although the internal handling is different. For the Mac this issue is for example discussed here: http://stackoverflow.com/questions/29101472/pass-parameters-to-javafx-application-by-double-click-on-file But as this is a general concept I would also appreciate a general solution in JavaFX so that you do not have to clutter your code with various system specific handlers. Michael Am 17.12.15 um 15:21 schrieb Kevin Rushforth: > Given the recently announced JDK 9 schedule slip [1], we have taken > the opportunity to explore what RFE's / Features we could possibly now > work on for inclusion in JDK 9. We wanted to give you a pre-holiday > season update on what we are currently thinking. > > The following RFEs are in progress or planned for JDK 9: > > JDK-8144585: Encapsulate JavaFX impl_* implementation methods > JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs > JDK-8091308: Define fine-grained permissions for JavaFX > Expose Hi-DPI properties for render scale and screen scale (FX > equivalent task for JEP 263 JDK-8055212) > Multi-resolution image support (FX equivalent task for JEP 251 > JDK-8046010) > > Additionally, we have started to look into making public API for some > of the impl_* API that will otherwise be hidden by JDK-8144585. See > Jonathan's earlier e-mail on the subject [2]. Here is what we have so > far: > > JDK-8144628: Provide API to expose list of showing Windows > JDK-8144625: Expose code and char properties on KeyCode > JDK-8144962: Promote TableColumn reorderable property to public API > JDK-8144871: Add default method getStyleableNode to Styleable interface > JDK-8145143: Promote Image.impl_getUrl() to public API as > Image.getUrl() > JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and > Labeled > > If there are any we have missed that your application depends on, > please send e-mail to Jonathan. > > Finally, here is an updated list of other RFEs we might consider for > JDK 9. We will not be able to do all of these, but hope to be able to > do many of them. We could use the help of the OpenJFX community in > prioritizing this list or possibly adding something that we missed, as > long as the scope is small enough. > > JDK-8091107: Add java.awt.Desktop support to javafx > JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX > (FX equivalent for JEP 272) > JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux > JDK-8092040: Implement Image writers for JavaFX > JDK-8091673: Runtime should have a published focus traversal API for > use in custom controls > JDK-8089311: [TableCell] commit on focus lost not possible in every > case > JDK-8090477: Customizable visibility timing for Tooltip > JDK-8092098: [TabPane] Support for draggable tabs > JDK-8144556: Add support to allow user specified rendering order > JDK-8145443: [Mac] Render directly to NSWIndow rather than via > CALayer for non-applet Stage > JDK-8145154: Provide public API support for PerformanceTracker > functionality > JDK-8090763: Public API for Glass's robot functionality > > Let us know what is most important to your application. > > We will keep you posted with updates on what exactly is being targeted > (note that you can track it by looking at the Fix Version in JBS, > which we strive to keep up-to-date). > > Thanks! > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html > [2] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html > From mike at plan99.net Thu Dec 17 22:05:05 2015 From: mike at plan99.net (Mike Hearn) Date: Thu, 17 Dec 2015 23:05:05 +0100 Subject: Update on FX plans for JDK 9 In-Reply-To: <5672C4F0.20901@oracle.com> References: <5672C4F0.20901@oracle.com> Message-ID: > > JDK-8091107: Add java.awt.Desktop support to javafx > JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX (FX > equivalent for JEP 272) > Exposing platform APIs is a big deal for anyone who wants to make an app that really benefits from being on the desktop. Doing things like handling files, registering URL handlers etc was a big PITA in my app. Definitely +1 to supporting these cases better. > JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer > for non-applet Stage > It's unclear from this description or the bug what the benefit of doing that would be. Performance? > JDK-8145154: Provide public API support for PerformanceTracker > functionality > JDK-8090763: Public API for Glass's robot functionality > For testing and so on, public APIs seem lower priority to me. A developer can always override Jigsaw from the command line and use whatever internal APIs are needed. Breakage is less of a concern because it's under the control of the developer. The biggest lack in the JavaFX/javapackager/jlink story is still, by far, a slick auto update system. Shipping apps that can't update themselves in 2015 is unacceptable even for corporate deployments. From david.dehaven at oracle.com Thu Dec 17 23:08:09 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 17 Dec 2015 15:08:09 -0800 Subject: [9] Review Request: 8145602: [macosx] Remove QTKit based media player Message-ID: <3D788EC5-B891-4F1B-8368-51F3E87A0E75@oracle.com> Kevin, Alexander, please review the changes to remove QTKMediaPlayer and do some cleanup in the AVF media player since we no longer build against the 10.7 SDK. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8145602 webrev: http://cr.openjdk.java.net/~ddehaven/8145602/rt/v0/ Note that this is blocked by JDK-8145604, so this won't be pushed until Kevin finishes that. Also note that I've de-tabbed a few files, so the formatting looks off in the webrev (something is expanding the tabs to 8 spaces instead of 4). It looks correct in the code, if in doubt you can apply the patch and check it. AVFKernelProcessor.cpp and AVFMediaPlayer.mm appear to be unchanged because it's whitespace only (de-tabbed) and webrev was set to ignore those changes. -DrD- From james.graham at oracle.com Fri Dec 18 01:17:38 2015 From: james.graham at oracle.com (Jim Graham) Date: Thu, 17 Dec 2015 17:17:38 -0800 Subject: [9] Review Request: 8143598: Stage min/max Width values not scaled for DPI Message-ID: <56735EB2.30504@oracle.com> Jira: https://bugs.openjdk.java.net/browse/JDK-8143598 webrev: http://cr.openjdk.java.net/~flar/JDK-8143598/webrev.00/ Since the min/max properties are enforced asynchronously (at least on the Windows platform), there wasn't an easy test case to write to verify that the values were enforced unfortunately. This will be back-ported to 8u-dev shortly... ...jim From hastebrot at gmail.com Fri Dec 18 04:47:22 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Fri, 18 Dec 2015 05:47:22 +0100 Subject: Update on FX plans for JDK 9 In-Reply-To: References: <5672C4F0.20901@oracle.com> Message-ID: >For testing and so on, public APIs seem lower priority to me. A developer can always override Jigsaw from the command line and use whatever internal APIs are needed. That's true, although is increases the initial hurdle of testing a bit. >JDK-8145154: Provide public API support for PerformanceTracker functionality The ability to register custom Loggers would be nice; they currently behind private fields. On Thu, Dec 17, 2015 at 11:05 PM, Mike Hearn wrote: > > > > JDK-8091107: Add java.awt.Desktop support to javafx > > JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX > (FX > > equivalent for JEP 272) > > > > Exposing platform APIs is a big deal for anyone who wants to make an app > that really benefits from being on the desktop. Doing things like handling > files, registering URL handlers etc was a big PITA in my app. Definitely +1 > to supporting these cases better. > > > > JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer > > for non-applet Stage > > > > It's unclear from this description or the bug what the benefit of doing > that would be. Performance? > > > > JDK-8145154: Provide public API support for PerformanceTracker > > functionality > > JDK-8090763: Public API for Glass's robot functionality > > > > For testing and so on, public APIs seem lower priority to me. A developer > can always override Jigsaw from the command line and use whatever internal > APIs are needed. Breakage is less of a concern because it's under the > control of the developer. > > The biggest lack in the JavaFX/javapackager/jlink story is still, by far, a > slick auto update system. Shipping apps that can't update themselves in > 2015 is unacceptable even for corporate deployments. > From murali.billa at oracle.com Fri Dec 18 09:38:50 2015 From: murali.billa at oracle.com (Murali Billa) Date: Fri, 18 Dec 2015 01:38:50 -0800 (PST) Subject: [9] review request: 8145682 topDocument() returns an incorrect reference for cached Documents Message-ID: <9bbfe3f1-3d31-4c26-a2c9-df469c01ec3b@default> Hi Kevin, Alexander, Please review the fix for below : JIRA: https://bugs.openjdk.java.net/browse/JDK-8145682 Webrev: http://cr.openjdk.java.net/~ghb/murali/8145682/webrev.00/ Root Cause: There is a regression with r162947 which changed the way the top document is determined, effecting below 2 cases: 1) when the Document is in page cache 2) Document is in the middle of having its render tree destroyed OR notification posting for cached or being-destroyed documents., leading to non-deletion of the proper top document's AXObjectCache Fix: Applying pre- r162947 way of determining the top document and r164718 patch applied. Also tested to make sure that fast/history/timed-refresh-in-cached-frame.html is also passed. Thanks, Murali From vadim.pakhnushev at oracle.com Fri Dec 18 17:14:10 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 18 Dec 2015 20:14:10 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <56743EE2.50809@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From David.Hill at Oracle.com Fri Dec 18 18:38:02 2015 From: David.Hill at Oracle.com (David Hill) Date: Fri, 18 Dec 2015 13:38:02 -0500 Subject: Update on FX plans for JDK 9 In-Reply-To: <5672FAAC.8060702@bestsolution.at> References: <5672C4F0.20901@oracle.com> <5672FAAC.8060702@bestsolution.at> Message-ID: <5674528A.3040901@Oracle.com> On 12/17/15, 1:10 PM, Tom Schindl wrote: > [...] > >> JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux > This is a real problem for the SWT-FX integration because SWT is more > and more setting GTK3 as the default. We (the OSGi-FXClassloader) > currently saves people from hard core-dumps by refusing to load FXCanvas > but they'll get a CNF instead with a decent error message why we refused > to load that classes. Sounds like I have someone to help test my code. :-) Not quite there yet. > > Naturally this requires FXCanvas to work in FX9 but that is a different > topic ;-) > > Tom > -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From kevin.rushforth at oracle.com Fri Dec 18 19:37:24 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 18 Dec 2015 11:37:24 -0800 Subject: HEADS-UP: Bumping minimum OS X version to build FX 9 to OS X 10.9 Message-ID: <56746074.7040305@oracle.com> We currently build FX 9 on Mac OS X 10.9.5 and run on 10.9.5 or later. As part of an ongoing effort to cleanup old, unused code that is only there to support older OS versions, we filed the following two issues: https://bugs.openjdk.java.net/browse/JDK-8145602 https://bugs.openjdk.java.net/browse/JDK-8145604 The impact of this cleanup is that FX 9 will no longer build with OS X 10.8 or earlier. You will need at least OS X 10.9.5 and XCode 5.1.1 in order to build FX 9. Note that the minimum version of Mac OS X that will be supported in JDK 9 is 10.10, although we intend to keep FX buildable and runnable on OS X 10.9.5 for the foreseeable future. -- Kevin From alexander.casall at saxsys.de Fri Dec 18 20:51:39 2015 From: alexander.casall at saxsys.de (Casall, Alexander) Date: Fri, 18 Dec 2015 20:51:39 +0000 Subject: MediaView does not play video on Ubuntu In-Reply-To: <1450363425.14396.6.camel@schwarze-allianz.de> References: <7E691632-A427-4CBD-BD8F-AE66DC08457E@saxsys.de> <1450363425.14396.6.camel@schwarze-allianz.de> Message-ID: <5AC8575C-29E8-4B26-B54C-3006745E0395@saxsys.de> Hi Jens, Thanks for the hint. We already had the codecs installed. We figured out that there seems to be a bug in the media implementation of Windows and Linux. Our video was vertical and had a resolution of 800x1500. It played perfectly on MacOS. On Windows the MediaView startet with an unknown error and on Ubuntu it didn?t do anything, neither putting something in the errorProperty nor having any warning. So the solution was to render the video in 1500x800 and rotate it in FX. Thanks for your response, Alex Am [DATE] schrieb "openjfx-dev im Auftrag von Jens Kapitza" <[ADDRESS]>: >Hi, > >are the -extra codecs installed? > >http://askubuntu.com/questions/214421/how-to-install-the-mpeg-4-aac-dec >oder-and-the-h-264-decoder > > >F?r Ubuntu 15.10 k?nnte das hier helfen?!: > >sudo apt-get install libavcodec-extra libavcodec-ffmpeg-extra56 >libav-tools ffmpeg > > > > >Am Donnerstag, den 17.12.2015, 11:02 +0000 schrieb Casall, Alexander: >> Hi, > >> >> I?m trying to get the MediaView running on an Ubuntu 14.04 >> >> Target JRE: 1.8.0_66-b17 >> I?m building the app on Mac with: jdk1.8.0_40.jdk >> >> The Video is h264 encoded and is running perfectly on the MacOS. >> >> When I launch it on Ubuntu the MediaView just shows a blank screen, >> no exceptions, nothing. >> >> Any suggestions? >> >> Cheers Alex >> >> From mike.ennen at gmail.com Fri Dec 18 20:55:44 2015 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 18 Dec 2015 13:55:44 -0700 Subject: Update on FX plans for JDK 9 In-Reply-To: References: <5672C4F0.20901@oracle.com> Message-ID: Exposing platform APIs for the major supported platforms (Windows, OS X, sensible Linux distros) for registering URL handlers gets a big +1 from me. While feasibly outside of the scope of OpenJFX, an auto updater would be amazing. I know you, Mike, have done work in this area with UpdateFX which could serve a starting point for the JavaFX devs if they agree to tackle this issue. On Thu, Dec 17, 2015 at 3:05 PM, Mike Hearn wrote: > > > > JDK-8091107: Add java.awt.Desktop support to javafx > > JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX > (FX > > equivalent for JEP 272) > > > > Exposing platform APIs is a big deal for anyone who wants to make an app > that really benefits from being on the desktop. Doing things like handling > files, registering URL handlers etc was a big PITA in my app. Definitely +1 > to supporting these cases better. > > > > JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer > > for non-applet Stage > > > > It's unclear from this description or the bug what the benefit of doing > that would be. Performance? > > > > JDK-8145154: Provide public API support for PerformanceTracker > > functionality > > JDK-8090763: Public API for Glass's robot functionality > > > > For testing and so on, public APIs seem lower priority to me. A developer > can always override Jigsaw from the command line and use whatever internal > APIs are needed. Breakage is less of a concern because it's under the > control of the developer. > > The biggest lack in the JavaFX/javapackager/jlink story is still, by far, a > slick auto update system. Shipping apps that can't update themselves in > 2015 is unacceptable even for corporate deployments. > -- Michael Ennen From mike.ennen at gmail.com Fri Dec 18 20:56:19 2015 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 18 Dec 2015 13:56:19 -0700 Subject: Update on FX plans for JDK 9 In-Reply-To: References: <5672C4F0.20901@oracle.com> Message-ID: Exposing platform APIs for the major supported platforms (Windows, OS X, sensible Linux distros) for registering URL handlers gets a big +1 from me. While feasibly outside of the scope of OpenJFX, an auto updater would be amazing. I know you, Mike, have done work in this area with UpdateFX which could serve a starting point for the JavaFX devs if they agree to tackle this issue. On Thu, Dec 17, 2015 at 3:05 PM, Mike Hearn wrote: > > > > JDK-8091107: Add java.awt.Desktop support to javafx > > JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX > (FX > > equivalent for JEP 272) > > > > Exposing platform APIs is a big deal for anyone who wants to make an app > that really benefits from being on the desktop. Doing things like handling > files, registering URL handlers etc was a big PITA in my app. Definitely +1 > to supporting these cases better. > > > > JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer > > for non-applet Stage > > > > It's unclear from this description or the bug what the benefit of doing > that would be. Performance? > > > > JDK-8145154: Provide public API support for PerformanceTracker > > functionality > > JDK-8090763: Public API for Glass's robot functionality > > > > For testing and so on, public APIs seem lower priority to me. A developer > can always override Jigsaw from the command line and use whatever internal > APIs are needed. Breakage is less of a concern because it's under the > control of the developer. > > The biggest lack in the JavaFX/javapackager/jlink story is still, by far, a > slick auto update system. Shipping apps that can't update themselves in > 2015 is unacceptable even for corporate deployments. > -- Michael Ennen From David.Hill at Oracle.com Fri Dec 18 23:53:05 2015 From: David.Hill at Oracle.com (David Hill) Date: Fri, 18 Dec 2015 18:53:05 -0500 Subject: review Remove deprecated GTK2 calls in JavaFX Message-ID: <56749C61.6010009@Oracle.com> Kevin, A small change, substituting the "approved" way of calling GTK. This helps in a small way moving to GTK3 support. bug: https://bugs.openjdk.java.net/browse/JDK-8145837 webrev: http://cr.openjdk.java.net/~ddhill/8145837/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From boskokg at gmail.com Sat Dec 19 13:51:08 2015 From: boskokg at gmail.com (Bosko Popovic) Date: Sat, 19 Dec 2015 13:51:08 +0000 (UTC) Subject: WebKit future planning Message-ID: Hi, We are developing application that uses Chromium Embedded Framework (CEF). Application supports Win, OSX and Linux. We want to switch to JavaFx WebView. The major things that concern us: 1) WebKit removed support for Windows acording to https://bugs.webkit.org/show_bug.cgi?id=106264 and https://bugs.webkit.org/show_bug.cgi?id=136385 Question: What is the plan for JavaFx browser support for Windows OS in future? 2) JavaFX uses WebView based on WebKit 538.19 (released on February 2014). Is there a plan to update WebKit version? Thanks, Bosko From David.Hill at Oracle.com Sat Dec 19 21:19:35 2015 From: David.Hill at Oracle.com (David Hill) Date: Sat, 19 Dec 2015 16:19:35 -0500 Subject: review for Refactor web module for clear separation of tests Message-ID: <5675C9E7.3010605@Oracle.com> Alexander, Kevin, Refactor web module for clear separation of tests https://bugs.openjdk.java.net/browse/JDK-8145856 http://cr.openjdk.java.net/~ddhill/8145856/ tested so far on Linux, Mac -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From David.Hill at Oracle.com Sat Dec 19 23:58:09 2015 From: David.Hill at Oracle.com (David Hill) Date: Sat, 19 Dec 2015 18:58:09 -0500 Subject: review: Refactor fxml module for clear separation of tests Message-ID: <5675EF11.5020803@Oracle.com> Jonathan, Kevin, https://bugs.openjdk.java.net/browse/JDK-8145858 http://cr.openjdk.java.net/~ddhill/8145858 Run on Linux, Mac so far. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From guru.hb at oracle.com Mon Dec 21 05:28:58 2015 From: guru.hb at oracle.com (Guru Hb) Date: Sun, 20 Dec 2015 21:28:58 -0800 (PST) Subject: WebKit future planning In-Reply-To: References: Message-ID: <68f4b178-3ee8-42e6-b133-5313375602dc@default> Hi Bosko, Please find my comments embedded below. Thanks, Guru -----Original Message----- From: Bosko Popovic [mailto:boskokg at gmail.com] Sent: Saturday, December 19, 2015 7:21 PM To: openjfx-dev at openjdk.java.net Subject: WebKit future planning Hi, We are developing application that uses Chromium Embedded Framework (CEF). Application supports Win, OSX and Linux. We want to switch to JavaFx WebView. The major things that concern us: 1) WebKit removed support for Windows acording to https://bugs.webkit.org/show_bug.cgi?id=106264 and https://bugs.webkit.org/show_bug.cgi?id=136385 Question: What is the plan for JavaFx browser support for Windows OS in future? [This wont impact our JavaFX WebView support on Windows OS, Above two defects is for multi process model but our existing webkit port is based on non Webkit2] 2) JavaFX uses WebView based on WebKit 538.19 (released on February 2014). Is there a plan to update WebKit version? [Yes, we are in process of merging latest trunk (webkit.org) to our WebView] Thanks, Bosko From David.Hill at Oracle.com Mon Dec 21 19:45:44 2015 From: David.Hill at Oracle.com (David Hill) Date: Mon, 21 Dec 2015 14:45:44 -0500 Subject: CFV: New OpenJFX Committer: Johan Vos Message-ID: <567856E8.5020905@Oracle.com> I hereby nominate Johan Vos to OpenJFX Committer. Johan Vos (jvos) has been active in the OpenJFX community, and instrumental in the maturity of Monocle, the owner of the Android and IOS ports and is an OpenJFX Author. A list of Johan's commits is also available by the following links http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos Votes are due by January 5th, 2016. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave From kevin.rushforth at oracle.com Mon Dec 21 19:46:39 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 21 Dec 2015 11:46:39 -0800 Subject: CFV: New OpenJFX Committer: Johan Vos In-Reply-To: <567856E8.5020905@Oracle.com> References: <567856E8.5020905@Oracle.com> Message-ID: <5678571F.7050904@oracle.com> Vote: YES David Hill wrote: > > I hereby nominate Johan Vos to OpenJFX Committer. > > Johan Vos (jvos) has been active in the OpenJFX community, and > instrumental in the maturity of Monocle, the owner of the Android and > IOS ports and is an OpenJFX Author. > > A list of Johan's commits is also available by the following links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos > > Votes are due by January 5th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From jonathan.giles at oracle.com Mon Dec 21 19:47:16 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 22 Dec 2015 08:47:16 +1300 Subject: CFV: New OpenJFX Committer: Johan Vos In-Reply-To: <567856E8.5020905@Oracle.com> References: <567856E8.5020905@Oracle.com> Message-ID: <56785744.8080405@oracle.com> Vote: YES -- Jonathan On 22/12/15 8:45 AM, David Hill wrote: > > I hereby nominate Johan Vos to OpenJFX Committer. > > Johan Vos (jvos) has been active in the OpenJFX community, and > instrumental in the maturity of Monocle, the owner of the Android and > IOS ports and is an OpenJFX Author. > > A list of Johan's commits is also available by the following links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos > > Votes are due by January 5th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From kevin.rushforth at oracle.com Mon Dec 21 21:21:32 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 21 Dec 2015 13:21:32 -0800 Subject: 9-dev unlocked following sanity testing Message-ID: <56786D5C.5090102@oracle.com> From kevin.rushforth at oracle.com Mon Dec 21 21:23:20 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 21 Dec 2015 13:23:20 -0800 Subject: No FX 9 integration on Mon, Dec 28 Message-ID: <56786DC8.5050607@oracle.com> There will be no FX 9 integration next Monday, Dec 28 due to the US holidays. We will dispense with the usual Monday sanity testing that day as a result. The next integration will be on Monday, Jan 4, 2016. -- Kevin From cnewland at chrisnewland.com Mon Dec 21 23:02:33 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Mon, 21 Dec 2015 23:02:33 -0000 Subject: Huge JavaFX performance drop in Debian Jessie Message-ID: Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy to Debian Jessie and JavaFX performance has suffered a huge drop :( Possibly not JavaFX related but native apps (firefox etc) all seem to perform the same and glxgears runs full sync framerate and 350fps unsynced. JavaFX stages open blank and can take 5 seconds to render. Trying to scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app for 10s+. Previously stages opened in under 1s and scrolling was instant. My DemoFX test platform (Canvas based effects) seems to run the same so it only appears to be windows / stages that are affected. It's an old (2010) system but JavaFX performance has dropped from slow to unusable. Will keep investigating and test on my Debian desktop once I upgrade it to Jessie. Cheers, Chris @chriswhocodes JavaFX debug: Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension initializeIfAvailable INFO: Failed to initialize management extension java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:695) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(LauncherImpl.java:182) at java.lang.Thread.run(Thread.java:745) Prism pipeline init order: es2 sw Using java-based Pisces rasterizer Using dirty region optimizations Not using texture mask for primitives Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode Opting in for HiDPI pixel scaling Prism pipeline name = com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2 Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from relative path succeeded. GLFactory using com.sun.prism.es2.X11GLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from relative path Maximum supported texture size: 2048 Non power of two texture support = true Maximum number of vertex attributes = 16 Maximum number of uniform vertex components = 16384 Maximum number of uniform fragment components = 16384 Maximum number of varying components = 32 Maximum number of texture units usable in a vertex shader = 8 Maximum number of texture units usable in a fragment shader = 8 Graphics Vendor: Intel Open Source Technology Center Renderer: Mesa DRI Intel(R) IGD Version: 2.1 Mesa 10.3.2 vsync: true vpipe: true Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so from relative path Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.so from relative path Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so from relative path ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag new alphas ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag ES2ResourceFactory: Prism - createStockShader: Texture_LinearGradient_PAD.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureFirstPassLCD.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureSecondPassLCD.frag ES2ResourceFactory: Prism - createStockShader: FillPgram_LinearGradient_PAD.frag ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag new alphas new alphas PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_4 From murali.billa at oracle.com Tue Dec 22 05:59:16 2015 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 21 Dec 2015 21:59:16 -0800 (PST) Subject: [9] review request: JDK-8145937 Not able to enter text and pop menu disappearing on Mouseover Menu Message-ID: <1ddd2dc4-e1be-498e-97d9-20a2b78d98bc@default> Hi Kevin, Alexander, Please review the fix for below issue : JIRA: https://bugs.openjdk.java.net/browse/JDK-8145937 Webrev: http://cr.openjdk.java.net/~ghb/murali/8145937/webrev.00/ Root Cause: There is a regression with r157328 (http://trac.webkit.org/changeset/157328) from 8u60, which simplified Event propagating logic in Event Dispatcher. The commit r157328 caused regressions in websites where we are not able to enter input text on Mouse over menu. For Example: 1. http://www.emirates.com/in/english/ and mouseover "Manage". Try to enter "last name" OR "booking reference" in "find your booking". Now pop up disappears and not able to enter the text. 2. HYPERLINK "http://www.britishairways.com/travel/home/public/en_us"www.britishairways.com/travel/home/public/en_us and mouse over "Manage My Booking". Not able to enter input in fields for "Online check-in" or "Find my booking". Fix: Applying webkit patches http://trac.webkit.org/changeset/167689, http://trac.webkit.org/changeset/167805 and http://trac.webkit.org/changeset/167840 Verified the fix for above mentioned websites. Thanks, Murali From tom.schindl at bestsolution.at Tue Dec 22 06:15:51 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 22 Dec 2015 07:15:51 +0100 Subject: Constant resetting to initial-state when adding/remove styleclasses Message-ID: <5678EA97.1080803@bestsolution.at> Hi, While debugging some code I attached a listener to a property and noticed that whenever a style-class is added to the control or even worse somewhere in the parent hierarchy that FX resets the value to its initial state (Node#reapplyCss & CssStyleHelper) only to set it back to it's real value with the next CSS-Pass triggered by the next pulse. I don't want to imagine if this happens with many value set via CSS and eg adding/remove a styleclass to the scene root. Is this behavior really by design like this? You can try that yourself with the attached program below and using the css at the end. I'm writing this because of Kevins request what the team should invest time to because of Java9 delays and frankly all of those bugs/features sound relevant and interesting but JavaFX performance (most important CSS-Performance) is still miles away from eg browsers who are the main competitors. It doesn't help me to get an java.awt.Desktop replacement if my input-forms do not render in a decent time frame - I would even say rendering them in 2015 most be almost instant. Tom > package application; > > import javafx.application.Application; > import javafx.stage.Stage; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.scene.layout.StackPane; > > > public class Main extends Application { > @Override > public void start(Stage primaryStage) { > try { > BorderPane root = new BorderPane(); > > StackPane p = new StackPane(); > p.getStyleClass().add("test-css"); > p.maxWidthProperty().addListener( (o, ol, ne) -> { > System.err.println("Modified : " + ol + " " + ne); > Thread.dumpStack(); > }); > > root.setCenter(p); > > HBox box = new HBox(); > > { > Button b = new Button("Modify Pane CSS"); > b.setOnAction( e -> p.getStyleClass().add("dummy")); > box.getChildren().add(b); > } > > { > Button b = new Button("Modify Root CSS"); > b.setOnAction( e -> { > root.getStyleClass().add("dummy"); > }); > box.getChildren().add(b); > } > > root.setBottom(box); > > Scene scene = new Scene(root,400,400); > scene.getStylesheets().addAll(getClass().getResource("application.css").toExternalForm()); > primaryStage.setScene(scene); > primaryStage.show(); > } catch(Exception e) { > e.printStackTrace(); > } > } > > public static void main(String[] args) { > launch(args); > } > } > .test-css { > -fx-max-width: 300; > } -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From han.solo at mac.com Tue Dec 22 06:55:13 2015 From: han.solo at mac.com (Gerrit Grunwald) Date: Tue, 22 Dec 2015 07:55:13 +0100 Subject: Constant resetting to initial-state when adding/remove styleclasses In-Reply-To: <5678EA97.1080803@bestsolution.at> References: <5678EA97.1080803@bestsolution.at> Message-ID: Hi, I just can confirm what Tom wrote, figured that out some time ago when playing around with JavaFX on embedded. The focus on improving JavaFX should be on Performance and esp. CSS performance. You can make JavaFX fast but then you find yourself back in workarounds like in former Swing days. Just my 0.02?... Cheers, Gerrit Grunwald Westfalenstrasse 93 48165 M?nster - Germany - twitter @hansolo_ web harmonic-code.org mob +49 (0)171 1745350 > Am 22.12.2015 um 07:15 schrieb Tom Schindl : > > Hi, > > While debugging some code I attached a listener to a property and > noticed that whenever a style-class is added to the control or even > worse somewhere in the parent hierarchy that FX resets the value to its > initial state (Node#reapplyCss & CssStyleHelper) only to set it back to > it's real value with the next CSS-Pass triggered by the next pulse. > > I don't want to imagine if this happens with many value set via CSS and > eg adding/remove a styleclass to the scene root. Is this behavior really > by design like this? > > You can try that yourself with the attached program below and using the > css at the end. I'm writing this because of Kevins request what the team > should invest time to because of Java9 delays and frankly all of those > bugs/features sound relevant and interesting but JavaFX performance > (most important CSS-Performance) is still miles away from eg browsers > who are the main competitors. > > It doesn't help me to get an java.awt.Desktop replacement if my > input-forms do not render in a decent time frame - I would even say > rendering them in 2015 most be almost instant. > > Tom > >> package application; >> >> import javafx.application.Application; >> import javafx.stage.Stage; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.layout.BorderPane; >> import javafx.scene.layout.HBox; >> import javafx.scene.layout.StackPane; >> >> >> public class Main extends Application { >> @Override >> public void start(Stage primaryStage) { >> try { >> BorderPane root = new BorderPane(); >> >> StackPane p = new StackPane(); >> p.getStyleClass().add("test-css"); >> p.maxWidthProperty().addListener( (o, ol, ne) -> { >> System.err.println("Modified : " + ol + " " + ne); >> Thread.dumpStack(); >> }); >> >> root.setCenter(p); >> >> HBox box = new HBox(); >> >> { >> Button b = new Button("Modify Pane CSS"); >> b.setOnAction( e -> p.getStyleClass().add("dummy")); >> box.getChildren().add(b); >> } >> >> { >> Button b = new Button("Modify Root CSS"); >> b.setOnAction( e -> { >> root.getStyleClass().add("dummy"); >> }); >> box.getChildren().add(b); >> } >> >> root.setBottom(box); >> >> Scene scene = new Scene(root,400,400); >> scene.getStylesheets().addAll(getClass().getResource("application.css").toExternalForm()); >> primaryStage.setScene(scene); >> primaryStage.show(); >> } catch(Exception e) { >> e.printStackTrace(); >> } >> } >> >> public static void main(String[] args) { >> launch(args); >> } >> } > > >> .test-css { >> -fx-max-width: 300; >> } > > > > -- > Thomas Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From chien.yang at oracle.com Tue Dec 22 07:31:22 2015 From: chien.yang at oracle.com (Chien Yang) Date: Mon, 21 Dec 2015 23:31:22 -0800 Subject: CFV: New OpenJFX Committer: Johan Vos In-Reply-To: <567856E8.5020905@Oracle.com> References: <567856E8.5020905@Oracle.com> Message-ID: <5678FC4A.70909@oracle.com> Vote: YES On 12/21/2015 11:45 AM, David Hill wrote: > > I hereby nominate Johan Vos to OpenJFX Committer. > > Johan Vos (jvos) has been active in the OpenJFX community, and > instrumental in the maturity of Monocle, the owner of the Android and > IOS ports and is an OpenJFX Author. > > A list of Johan's commits is also available by the following links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos > > Votes are due by January 5th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From chien.yang at oracle.com Tue Dec 22 08:00:42 2015 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 22 Dec 2015 00:00:42 -0800 Subject: Huge JavaFX performance drop in Debian Jessie In-Reply-To: References: Message-ID: <5679032A.4030708@oracle.com> Hi Chris, JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There is a high likelihood that the drop in performance is caused by the switch from sw pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing JavaFX to use its sw pipe by specifying -Dprism.order=sw in the run command. - Chien On 12/21/2015 03:02 PM, Chris Newland wrote: > Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy to > Debian Jessie and JavaFX performance has suffered a huge drop :( > > Possibly not JavaFX related but native apps (firefox etc) all seem to > perform the same and glxgears runs full sync framerate and 350fps > unsynced. > > JavaFX stages open blank and can take 5 seconds to render. Trying to > scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app > for 10s+. > > Previously stages opened in under 1s and scrolling was instant. > > My DemoFX test platform (Canvas based effects) seems to run the same so it > only appears to be windows / stages that are affected. > > It's an old (2010) system but JavaFX performance has dropped from slow to > unusable. > > Will keep investigating and test on my Debian desktop once I upgrade it to > Jessie. > > Cheers, > > Chris > @chriswhocodes > > JavaFX debug: > > Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension initializeIfAvailable > INFO: Failed to initialize management extension > java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40) > at > com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669) > at > com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:695) > at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(LauncherImpl.java:182) > at java.lang.Thread.run(Thread.java:745) > > Prism pipeline init order: es2 sw > Using java-based Pisces rasterizer > Using dirty region optimizations > Not using texture mask for primitives > Not forcing power of 2 sizes for textures > Using hardware CLAMP_TO_ZERO mode > Opting in for HiDPI pixel scaling > Prism pipeline name = com.sun.prism.es2.ES2Pipeline > Loading ES2 native library ... prism_es2 > Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from > relative path > succeeded. > GLFactory using com.sun.prism.es2.X11GLFactory > (X) Got class = class com.sun.prism.es2.ES2Pipeline > Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline > JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit > Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from > relative path > Maximum supported texture size: 2048 > Non power of two texture support = true > Maximum number of vertex attributes = 16 > Maximum number of uniform vertex components = 16384 > Maximum number of uniform fragment components = 16384 > Maximum number of varying components = 32 > Maximum number of texture units usable in a vertex shader = 8 > Maximum number of texture units usable in a fragment shader = 8 > Graphics Vendor: Intel Open Source Technology Center > Renderer: Mesa DRI Intel(R) IGD > Version: 2.1 Mesa 10.3.2 > vsync: true vpipe: true > Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so from > relative path > Loaded > /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.so > from relative path > Loaded > /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so from > relative path > ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag > new alphas > ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag > ES2ResourceFactory: Prism - createStockShader: > Texture_LinearGradient_PAD.frag > ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag > ES2ResourceFactory: Prism - createStockShader: Solid_TextureFirstPassLCD.frag > ES2ResourceFactory: Prism - createStockShader: > Solid_TextureSecondPassLCD.frag > ES2ResourceFactory: Prism - createStockShader: > FillPgram_LinearGradient_PAD.frag > ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag > ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag > new alphas > new alphas > PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_4 > > From markus at headcrashing.eu Tue Dec 22 08:04:44 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 22 Dec 2015 09:04:44 +0100 Subject: Huge JavaFX performance drop in Debian Jessie In-Reply-To: References: Message-ID: <034c01d13c8f$6b97dec0$42c79c40$@eu> Chris, can you please check what the JFX thread does whilst the scroll-freeze (e. g. using jstack or jvisualvm)? It would be great to learn whether it is related to JDK-8145565. -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Chris Newland Sent: Dienstag, 22. Dezember 2015 00:03 To: openjfx-dev at openjdk.java.net Subject: Huge JavaFX performance drop in Debian Jessie Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy to Debian Jessie and JavaFX performance has suffered a huge drop :( Possibly not JavaFX related but native apps (firefox etc) all seem to perform the same and glxgears runs full sync framerate and 350fps unsynced. JavaFX stages open blank and can take 5 seconds to render. Trying to scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app for 10s+. Previously stages opened in under 1s and scrolling was instant. My DemoFX test platform (Canvas based effects) seems to run the same so it only appears to be windows / stages that are affected. It's an old (2010) system but JavaFX performance has dropped from slow to unusable. Will keep investigating and test on my Debian desktop once I upgrade it to Jessie. Cheers, Chris @chriswhocodes JavaFX debug: Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension initializeIfAvailable INFO: Failed to initialize management extension java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java :695) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(Launche rImpl.java:182) at java.lang.Thread.run(Thread.java:745) Prism pipeline init order: es2 sw Using java-based Pisces rasterizer Using dirty region optimizations Not using texture mask for primitives Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode Opting in for HiDPI pixel scaling Prism pipeline name = com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2 Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from relative path succeeded. GLFactory using com.sun.prism.es2.X11GLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from relative path Maximum supported texture size: 2048 Non power of two texture support = true Maximum number of vertex attributes = 16 Maximum number of uniform vertex components = 16384 Maximum number of uniform fragment components = 16384 Maximum number of varying components = 32 Maximum number of texture units usable in a vertex shader = 8 Maximum number of texture units usable in a fragment shader = 8 Graphics Vendor: Intel Open Source Technology Center Renderer: Mesa DRI Intel(R) IGD Version: 2.1 Mesa 10.3.2 vsync: true vpipe: true Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so from relative path Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.so from relative path Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so from relative path ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag new alphas ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag ES2ResourceFactory: Prism - createStockShader: Texture_LinearGradient_PAD.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureFirstPassLCD.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureSecondPassLCD.frag ES2ResourceFactory: Prism - createStockShader: FillPgram_LinearGradient_PAD.frag ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag new alphas new alphas PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_4 From markus at headcrashing.eu Tue Dec 22 08:06:49 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 22 Dec 2015 09:06:49 +0100 Subject: Constant resetting to initial-state when adding/remove styleclasses In-Reply-To: <5678EA97.1080803@bestsolution.at> References: <5678EA97.1080803@bestsolution.at> Message-ID: <035c01d13c8f$b61ed980$225c8c80$@eu> +1 -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Schindl Sent: Dienstag, 22. Dezember 2015 07:16 To: openjfx-dev at openjdk.java.net Subject: Constant resetting to initial-state when adding/remove styleclasses Hi, While debugging some code I attached a listener to a property and noticed that whenever a style-class is added to the control or even worse somewhere in the parent hierarchy that FX resets the value to its initial state (Node#reapplyCss & CssStyleHelper) only to set it back to it's real value with the next CSS-Pass triggered by the next pulse. I don't want to imagine if this happens with many value set via CSS and eg adding/remove a styleclass to the scene root. Is this behavior really by design like this? You can try that yourself with the attached program below and using the css at the end. I'm writing this because of Kevins request what the team should invest time to because of Java9 delays and frankly all of those bugs/features sound relevant and interesting but JavaFX performance (most important CSS-Performance) is still miles away from eg browsers who are the main competitors. It doesn't help me to get an java.awt.Desktop replacement if my input-forms do not render in a decent time frame - I would even say rendering them in 2015 most be almost instant. Tom > package application; > > import javafx.application.Application; > import javafx.stage.Stage; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.scene.layout.StackPane; > > > public class Main extends Application { > @Override > public void start(Stage primaryStage) { > try { > BorderPane root = new BorderPane(); > > StackPane p = new StackPane(); > p.getStyleClass().add("test-css"); > p.maxWidthProperty().addListener( (o, ol, ne) -> { > System.err.println("Modified : " + ol + " " + ne); > Thread.dumpStack(); > }); > > root.setCenter(p); > > HBox box = new HBox(); > > { > Button b = new Button("Modify Pane CSS"); > b.setOnAction( e -> p.getStyleClass().add("dummy")); > box.getChildren().add(b); > } > > { > Button b = new Button("Modify Root CSS"); > b.setOnAction( e -> { > root.getStyleClass().add("dummy"); > }); > box.getChildren().add(b); > } > > root.setBottom(box); > > Scene scene = new Scene(root,400,400); > scene.getStylesheets().addAll(getClass().getResource("application.css").toExternalForm()); > primaryStage.setScene(scene); > primaryStage.show(); > } catch(Exception e) { > e.printStackTrace(); > } > } > > public static void main(String[] args) { > launch(args); > } > } > .test-css { > -fx-max-width: 300; > } -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From markus at headcrashing.eu Tue Dec 22 08:13:17 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 22 Dec 2015 09:13:17 +0100 Subject: Huge JavaFX performance drop in Debian Jessie In-Reply-To: <5679032A.4030708@oracle.com> References: <5679032A.4030708@oracle.com> Message-ID: <036f01d13c90$9d4a8980$d7df9c80$@eu> Just to understand "not supported GPU" better: Is there GPU-specific code in JavaFX? I thought JFX is using vendor-neutral APIs to access the GPU? -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Chien Yang Sent: Dienstag, 22. Dezember 2015 09:01 To: cnewland at chrisnewland.com; openjfx-dev at openjdk.java.net Subject: Re: Huge JavaFX performance drop in Debian Jessie Hi Chris, JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There is a high likelihood that the drop in performance is caused by the switch from sw pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing JavaFX to use its sw pipe by specifying -Dprism.order=sw in the run command. - Chien On 12/21/2015 03:02 PM, Chris Newland wrote: > Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian > Wheezy to Debian Jessie and JavaFX performance has suffered a huge > drop :( > > Possibly not JavaFX related but native apps (firefox etc) all seem to > perform the same and glxgears runs full sync framerate and 350fps > unsynced. > > JavaFX stages open blank and can take 5 seconds to render. Trying to > scroll a scrollbar pegs the CPU (java process at 100%) and hangs the > app for 10s+. > > Previously stages opened in under 1s and scrolling was instant. > > My DemoFX test platform (Canvas based effects) seems to run the same > so it only appears to be windows / stages that are affected. > > It's an old (2010) system but JavaFX performance has dropped from slow > to unusable. > > Will keep investigating and test on my Debian desktop once I upgrade > it to Jessie. > > Cheers, > > Chris > @chriswhocodes > > JavaFX debug: > > Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension > initializeIfAvailable > INFO: Failed to initialize management extension > java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40) > at > com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669) > at > com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java :695) > at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(Launche rImpl.java:182) > at java.lang.Thread.run(Thread.java:745) > > Prism pipeline init order: es2 sw > Using java-based Pisces rasterizer > Using dirty region optimizations > Not using texture mask for primitives > Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO > mode Opting in for HiDPI pixel scaling Prism pipeline name = > com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2 > Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so > from relative path > succeeded. > GLFactory using com.sun.prism.es2.X11GLFactory > (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism > pipeline: com.sun.prism.es2.ES2Pipeline > JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit > Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from > relative path Maximum supported texture size: 2048 Non power of two > texture support = true Maximum number of vertex attributes = 16 > Maximum number of uniform vertex components = 16384 Maximum number of > uniform fragment components = 16384 Maximum number of varying > components = 32 Maximum number of texture units usable in a vertex > shader = 8 Maximum number of texture units usable in a fragment shader > = 8 Graphics Vendor: Intel Open Source Technology Center > Renderer: Mesa DRI Intel(R) IGD > Version: 2.1 Mesa 10.3.2 > vsync: true vpipe: true > Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so > from relative path Loaded > /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.s > o > from relative path > Loaded > /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so > from relative path > ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag > new alphas > ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag > ES2ResourceFactory: Prism - createStockShader: > Texture_LinearGradient_PAD.frag > ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag > ES2ResourceFactory: Prism - createStockShader: > Solid_TextureFirstPassLCD.frag > ES2ResourceFactory: Prism - createStockShader: > Solid_TextureSecondPassLCD.frag > ES2ResourceFactory: Prism - createStockShader: > FillPgram_LinearGradient_PAD.frag > ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag > ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag > new alphas new alphas > PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_4 > > From alexander.casall at saxsys.de Tue Dec 22 08:37:06 2015 From: alexander.casall at saxsys.de (Casall, Alexander) Date: Tue, 22 Dec 2015 08:37:06 +0000 Subject: Constant resetting to initial-state when adding/remove styleclasses References: Constant resetting to initial-state when adding/remove styleclasses Message-ID: <6C6CE4A9B94582468498929459CEEF711014850B@vmex1.saxsys.de> +1 I also vote for performance related optimizations From: Gerrit Grunwald Sent: 22.12.15, 07:55 To: Tom Schindl Cc: OpenJFX Subject: Re: Constant resetting to initial-state when adding/remove styleclasses Hi, I just can confirm what Tom wrote, figured that out some time ago when playing around with JavaFX on embedded. The focus on improving JavaFX should be on Performance and esp. CSS performance. You can make JavaFX fast but then you find yourself back in workarounds like in former Swing days. Just my 0.02?... Cheers, Gerrit Grunwald Westfalenstrasse 93 48165 M?nster - Germany - twitter @hansolo_ web harmonic-code.org mob +49 (0)171 1745350 > tom.schindl at bestsolution.at>: > > Hi, > > While debugging some code I attached a listener to a property and > noticed that whenever a style-class is added to the control or even > worse somewhere in the parent hierarchy that FX resets the value to its > initial state (Node#reapplyCss & CssStyleHelper) only to set it back to > it's real value with the next CSS-Pass triggered by the next pulse. > > I don't want to imagine if this happens with many value set via CSS and > eg adding/remove a styleclass to the scene root. Is this behavior really > by design like this? > > You can try that yourself with the attached program below and using the > css at the end. I'm writing this because of Kevins request what the team > should invest time to because of Java9 delays and frankly all of those > bugs/features sound relevant and interesting but JavaFX performance > (most important CSS-Performance) is still miles away from eg browsers > who are the main competitors. > > It doesn't help me to get an java.awt.Desktop replacement if my > input-forms do not render in a decent time frame - I would even say > rendering them in 2015 most be almost instant. > > Tom > >> package application; >> >> import javafx.application.Application; >> import javafx.stage.Stage; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.layout.BorderPane; >> import javafx.scene.layout.HBox; >> import javafx.scene.layout.StackPane; >> >> >> public class Main extends Application { >> @Override >> public void start(Stage primaryStage) { >> try { >> BorderPane root = new BorderPane(); >> >> StackPane p = new StackPane(); >> p.getStyleClass().add("test-css"); >> p.maxWidthProperty().addListener( (o, ol, ne) -> { >> System.err.println("Modified : " + ol + " " + ne); >> Thread.dumpStack(); >> }); >> >> root.setCenter(p); >> >> HBox box = new HBox(); >> >> { >> Button b = new Button("Modify Pane CSS"); >> b.setOnAction( e -> p.getStyleClass().add("dummy")); >> box.getChildren().add(b); >> } >> >> { >> Button b = new Button("Modify Root CSS"); >> b.setOnAction( e -> { >> root.getStyleClass().add("dummy"); >> }); >> box.getChildren().add(b); >> } >> >> root.setBottom(box); >> >> Scene scene = new Scene(root,400,400); >> scene.getStylesheets().addAll(getClass().getResource("application.css").toExternalForm()); >> primaryStage.setScene(scene); >> primaryStage.show(); >> } catch(Exception e) { >> e.printStackTrace(); >> } >> } >> >> public static void main(String[] args) { >> launch(args); >> } >> } > > >> .test-css { >> -fx-max-width: 300; >> } > > > > -- > Thomas Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From mp at jugs.org Tue Dec 22 09:05:21 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Tue, 22 Dec 2015 10:05:21 +0100 Subject: Constant resetting to initial-state when adding/remove styleclasses In-Reply-To: <5678EA97.1080803@bestsolution.at> References: <5678EA97.1080803@bestsolution.at> Message-ID: <56791251.8090503@jugs.org> If anyone is counting these votes for better performance I'll add 1+ too :-) Am 22.12.15 um 07:15 schrieb Tom Schindl: > Hi, > > While debugging some code I attached a listener to a property and > noticed that whenever a style-class is added to the control or even > worse somewhere in the parent hierarchy that FX resets the value to its > initial state (Node#reapplyCss & CssStyleHelper) only to set it back to > it's real value with the next CSS-Pass triggered by the next pulse. > > I don't want to imagine if this happens with many value set via CSS and > eg adding/remove a styleclass to the scene root. Is this behavior really > by design like this? > > You can try that yourself with the attached program below and using the > css at the end. I'm writing this because of Kevins request what the team > should invest time to because of Java9 delays and frankly all of those > bugs/features sound relevant and interesting but JavaFX performance > (most important CSS-Performance) is still miles away from eg browsers > who are the main competitors. > > It doesn't help me to get an java.awt.Desktop replacement if my > input-forms do not render in a decent time frame - I would even say > rendering them in 2015 most be almost instant. > > Tom > >> package application; >> >> import javafx.application.Application; >> import javafx.stage.Stage; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.layout.BorderPane; >> import javafx.scene.layout.HBox; >> import javafx.scene.layout.StackPane; >> >> >> public class Main extends Application { >> @Override >> public void start(Stage primaryStage) { >> try { >> BorderPane root = new BorderPane(); >> >> StackPane p = new StackPane(); >> p.getStyleClass().add("test-css"); >> p.maxWidthProperty().addListener( (o, ol, ne) -> { >> System.err.println("Modified : " + ol + " " + ne); >> Thread.dumpStack(); >> }); >> >> root.setCenter(p); >> >> HBox box = new HBox(); >> >> { >> Button b = new Button("Modify Pane CSS"); >> b.setOnAction( e -> p.getStyleClass().add("dummy")); >> box.getChildren().add(b); >> } >> >> { >> Button b = new Button("Modify Root CSS"); >> b.setOnAction( e -> { >> root.getStyleClass().add("dummy"); >> }); >> box.getChildren().add(b); >> } >> >> root.setBottom(box); >> >> Scene scene = new Scene(root,400,400); >> scene.getStylesheets().addAll(getClass().getResource("application.css").toExternalForm()); >> primaryStage.setScene(scene); >> primaryStage.show(); >> } catch(Exception e) { >> e.printStackTrace(); >> } >> } >> >> public static void main(String[] args) { >> launch(args); >> } >> } > >> .test-css { >> -fx-max-width: 300; >> } > > From cnewland at chrisnewland.com Tue Dec 22 09:05:33 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Tue, 22 Dec 2015 09:05:33 -0000 Subject: Huge JavaFX performance drop in Debian Jessie In-Reply-To: <5679032A.4030708@oracle.com> References: <5679032A.4030708@oracle.com> Message-ID: <76ecebad11668a4e19ff299c98f145bf.squirrel@excalibur.xssl.net> Hi Chien, Thanks, using -Dprism.order=sw prevents the multi-second hangs but JavaFX desktop performance is still noticably worse than in Wheezy (probably because the CPU is now doing all the work and this little Atom is maxed out). Something has definitely changed under the hood in Jessie but it's probably only noticeable in these low powered GPUs. Slowdown is with LXDE+lightdm and also Gnome3. Markus, Here is what the threads are doing when the scrollbar is hanging (with es2) Regards, Chris 2015-12-22 09:00:30 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode): "Attach Listener" #14 daemon prio=9 os_prio=0 tid=0x00007fec58001000 nid=0x17f9 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Prism Font Disposer" #13 daemon prio=10 os_prio=0 tid=0x00007fec2c192800 nid=0x17e1 in Object.wait() [0x00007fec3a5b2000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000e10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0x00000000e10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at com.sun.javafx.font.Disposer.run(Disposer.java:93) at java.lang.Thread.run(Thread.java:745) "JavaFX Application Thread" #12 prio=5 os_prio=0 tid=0x00007fec4c093800 nid=0x17e0 waiting on condition [0x00007fec4412e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f67d7668> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.tk.quantum.PaintCollector.waitForRenderingToComplete(PaintCollector.java:157) at com.sun.javafx.tk.quantum.GlassScene.waitForRenderingToComplete(GlassScene.java:127) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2410) at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) at com.sun.javafx.tk.Toolkit$$Lambda$359/1368562994.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolkit.java:319) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/1617205338.run(Unknown Source) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$49(GtkApplication.java:139) at com.sun.glass.ui.gtk.GtkApplication$$Lambda$43/357920869.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) "Thread-2" #11 daemon prio=5 os_prio=0 tid=0x00007fec4c08f800 nid=0x17df in Object.wait() [0x00007fec70143000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at com.sun.glass.ui.InvokeLaterDispatcher.run(InvokeLaterDispatcher.java:126) - locked <0x00000000e0ffc670> (a java.lang.StringBuilder) "QuantumRenderer-0" #9 daemon prio=5 os_prio=0 tid=0x00007fec4c04c000 nid=0x17de runnable [0x00007fec7118b000] java.lang.Thread.State: RUNNABLE at com.sun.prism.es2.GLContext.nDrawIndexedQuads(Native Method) at com.sun.prism.es2.GLContext.drawIndexedQuads(GLContext.java:724) at com.sun.prism.es2.ES2VertexBuffer.drawQuads(ES2VertexBuffer.java:65) at com.sun.prism.impl.VertexBuffer.flush(VertexBuffer.java:105) at com.sun.prism.impl.BaseContext.flushVertexBuffer(BaseContext.java:111) at com.sun.prism.impl.ps.BaseShaderContext.setRenderTarget(BaseShaderContext.java:747) at com.sun.prism.impl.BaseContext.setRenderTarget(BaseContext.java:121) at com.sun.prism.impl.BaseGraphics.(BaseGraphics.java:105) at com.sun.prism.impl.ps.BaseShaderGraphics.(BaseShaderGraphics.java:86) at com.sun.prism.es2.ES2Graphics.(ES2Graphics.java:42) at com.sun.prism.es2.ES2Graphics.create(ES2Graphics.java:50) at com.sun.prism.es2.ES2RTTexture.createGraphics(ES2RTTexture.java:312) at com.sun.prism.impl.ps.BaseShaderGraphics.initLCDSampleRT(BaseShaderGraphics.java:1929) at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2059) at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312) at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270) at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:261) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.CacheFilter.impl_renderNodeToCache(CacheFilter.java:671) at com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:575) at com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2358) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2044) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:477) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:323) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.lang.Thread.run(Thread.java:745) "JavaFX-Launcher" #8 prio=5 os_prio=0 tid=0x00007fec883c5800 nid=0x17dd waiting on condition [0x00007fec71292000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000e0ba48f0> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:873) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(LauncherImpl.java:182) at com.sun.javafx.application.LauncherImpl$$Lambda$2/93122545.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) "Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007fec880ba000 nid=0x17db runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007fec880b5000 nid=0x17da waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007fec880b2000 nid=0x17d9 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007fec880b0800 nid=0x17d8 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007fec8807a800 nid=0x17d7 in Object.wait() [0x00007fec72046000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000e0a33fe8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0x00000000e0a33fe8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209) "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007fec88078800 nid=0x17d6 in Object.wait() [0x00007fec72147000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000e0a34028> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) - locked <0x00000000e0a34028> (a java.lang.ref.Reference$Lock) "main" #1 prio=5 os_prio=0 tid=0x00007fec8800a000 nid=0x17d2 waiting on condition [0x00007fec8edbb000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000e0ffcda8> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:200) at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:143) at javafx.application.Application.launch(Application.java:252) at org.adoptopenjdk.jitwatch.ui.JITWatchUI.(JITWatchUI.java:185) at org.adoptopenjdk.jitwatch.launch.LaunchUI.main(LaunchUI.java:18) "VM Thread" os_prio=0 tid=0x00007fec88073800 nid=0x17d5 runnable "GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007fec8801f000 nid=0x17d3 runnable "GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007fec88021000 nid=0x17d4 runnable "VM Periodic Task Thread" os_prio=0 tid=0x00007fec880bd000 nid=0x17dc waiting on condition JNI global references: 1037 On Tue, December 22, 2015 08:00, Chien Yang wrote: > Hi Chris, > > > JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There > is a high likelihood that the drop in performance is caused by the switch > from sw pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA 3150 is an > underpowered GPU for JavaFX's es2 pipe. You can try forcing JavaFX to use > its sw pipe by specifying -Dprism.order=sw in the run command. > > - Chien > > > On 12/21/2015 03:02 PM, Chris Newland wrote: > >> Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy >> to Debian Jessie and JavaFX performance has suffered a huge drop :( >> >> >> Possibly not JavaFX related but native apps (firefox etc) all seem to >> perform the same and glxgears runs full sync framerate and 350fps >> unsynced. >> >> JavaFX stages open blank and can take 5 seconds to render. Trying to >> scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app >> for 10s+. >> >> Previously stages opened in under 1s and scrolling was instant. >> >> >> My DemoFX test platform (Canvas based effects) seems to run the same so >> it only appears to be windows / stages that are affected. >> >> It's an old (2010) system but JavaFX performance has dropped from slow >> to unusable. >> >> Will keep investigating and test on my Debian desktop once I upgrade it >> to Jessie. >> >> >> Cheers, >> >> >> Chris >> @chriswhocodes >> >> >> JavaFX debug: >> >> >> Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension >> initializeIfAvailable INFO: Failed to initialize management extension >> java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl >> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at >> java.lang.ClassLoader.loadClass(ClassLoader.java:424) >> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at >> java.lang.Class.forName0(Native Method) at >> java.lang.Class.forName(Class.java:264) >> at >> com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:4 >> 0) >> at >> com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java: >> 669) >> at >> com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl >> .java:695) >> at >> com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(La >> uncherImpl.java:182) >> at java.lang.Thread.run(Thread.java:745) >> >> Prism pipeline init order: es2 sw >> Using java-based Pisces rasterizer >> Using dirty region optimizations >> Not using texture mask for primitives >> Not forcing power of 2 sizes for textures >> Using hardware CLAMP_TO_ZERO mode >> Opting in for HiDPI pixel scaling >> Prism pipeline name = com.sun.prism.es2.ES2Pipeline >> Loading ES2 native library ... prism_es2 >> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from >> relative path succeeded. GLFactory using com.sun.prism.es2.X11GLFactory >> (X) Got class = class com.sun.prism.es2.ES2Pipeline >> Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline >> JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit >> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from >> relative path Maximum supported texture size: 2048 >> Non power of two texture support = true >> Maximum number of vertex attributes = 16 >> Maximum number of uniform vertex components = 16384 >> Maximum number of uniform fragment components = 16384 >> Maximum number of varying components = 32 >> Maximum number of texture units usable in a vertex shader = 8 >> Maximum number of texture units usable in a fragment shader = 8 >> Graphics Vendor: Intel Open Source Technology Center >> Renderer: Mesa DRI Intel(R) IGD >> Version: 2.1 Mesa 10.3.2 >> vsync: true vpipe: true >> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so >> from relative path Loaded >> /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.so >> from relative path Loaded >> /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so >> from relative path ES2ResourceFactory: Prism - createStockShader: >> FillPgram_Color.frag >> new alphas ES2ResourceFactory: Prism - createStockShader: >> Texture_Color.frag >> ES2ResourceFactory: Prism - createStockShader: >> Texture_LinearGradient_PAD.frag >> ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag >> ES2ResourceFactory: Prism - createStockShader: >> Solid_TextureFirstPassLCD.frag >> ES2ResourceFactory: Prism - createStockShader: >> Solid_TextureSecondPassLCD.frag >> ES2ResourceFactory: Prism - createStockShader: >> FillPgram_LinearGradient_PAD.frag >> ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag >> ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag >> new alphas new alphas PPSRenderer: scenario.effect - createShader: >> LinearConvolveShadow_4 >> >> >> > > From markus at headcrashing.eu Tue Dec 22 09:29:12 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 22 Dec 2015 10:29:12 +0100 Subject: Huge JavaFX performance drop in Debian Jessie In-Reply-To: <76ecebad11668a4e19ff299c98f145bf.squirrel@excalibur.xssl.net> References: <5679032A.4030708@oracle.com> <76ecebad11668a4e19ff299c98f145bf.squirrel@excalibur.xssl.net> Message-ID: <038f01d13c9b$381ce430$a856ac90$@eu> Thanks for the stacktrace. This is definitively a separate issue. Yours actually waits for the renderer to complete the previous frame. Mine is heavily working inside ToolbarSkin. Technically unrelated, but leading to the same outcome: frozen UI. What seems odd is that the object reference the JavaFX thread is waiting for is not locked by any other thread, particularly *not* the renderer. Never saw something like that. One more thing I noticed in your stacktrace: The prism font dispose has locked an object and now waits for exactly that object. That looks strange. How can a thread wait for an object which itself has locked?! -Markus -----Original Message----- From: Chris Newland [mailto:cnewland at chrisnewland.com] Sent: Dienstag, 22. Dezember 2015 10:06 To: Chien Yang; Markus KARG Cc: openjfx-dev at openjdk.java.net Subject: Re: Huge JavaFX performance drop in Debian Jessie Hi Chien, Thanks, using -Dprism.order=sw prevents the multi-second hangs but JavaFX desktop performance is still noticably worse than in Wheezy (probably because the CPU is now doing all the work and this little Atom is maxed out). Something has definitely changed under the hood in Jessie but it's probably only noticeable in these low powered GPUs. Slowdown is with LXDE+lightdm and also Gnome3. Markus, Here is what the threads are doing when the scrollbar is hanging (with es2) Regards, Chris 2015-12-22 09:00:30 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode): "Attach Listener" #14 daemon prio=9 os_prio=0 tid=0x00007fec58001000 nid=0x17f9 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Prism Font Disposer" #13 daemon prio=10 os_prio=0 tid=0x00007fec2c192800 nid=0x17e1 in Object.wait() [0x00007fec3a5b2000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000e10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0x00000000e10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at com.sun.javafx.font.Disposer.run(Disposer.java:93) at java.lang.Thread.run(Thread.java:745) "JavaFX Application Thread" #12 prio=5 os_prio=0 tid=0x00007fec4c093800 nid=0x17e0 waiting on condition [0x00007fec4412e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f67d7668> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru ptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt ibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.tk.quantum.PaintCollector.waitForRenderingToComplete(PaintCol lector.java:157) at com.sun.javafx.tk.quantum.GlassScene.waitForRenderingToComplete(GlassScene.j ava:127) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2410) at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) at com.sun.javafx.tk.Toolkit$$Lambda$359/1368562994.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolki t.java:319) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/1617205338.run(Unknown Source) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java :95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$49(GtkApplication.java:139) at com.sun.glass.ui.gtk.GtkApplication$$Lambda$43/357920869.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) "Thread-2" #11 daemon prio=5 os_prio=0 tid=0x00007fec4c08f800 nid=0x17df in Object.wait() [0x00007fec70143000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at com.sun.glass.ui.InvokeLaterDispatcher.run(InvokeLaterDispatcher.java:126) - locked <0x00000000e0ffc670> (a java.lang.StringBuilder) "QuantumRenderer-0" #9 daemon prio=5 os_prio=0 tid=0x00007fec4c04c000 nid=0x17de runnable [0x00007fec7118b000] java.lang.Thread.State: RUNNABLE at com.sun.prism.es2.GLContext.nDrawIndexedQuads(Native Method) at com.sun.prism.es2.GLContext.drawIndexedQuads(GLContext.java:724) at com.sun.prism.es2.ES2VertexBuffer.drawQuads(ES2VertexBuffer.java:65) at com.sun.prism.impl.VertexBuffer.flush(VertexBuffer.java:105) at com.sun.prism.impl.BaseContext.flushVertexBuffer(BaseContext.java:111) at com.sun.prism.impl.ps.BaseShaderContext.setRenderTarget(BaseShaderContext.ja va:747) at com.sun.prism.impl.BaseContext.setRenderTarget(BaseContext.java:121) at com.sun.prism.impl.BaseGraphics.(BaseGraphics.java:105) at com.sun.prism.impl.ps.BaseShaderGraphics.(BaseShaderGraphics.java:86) at com.sun.prism.es2.ES2Graphics.(ES2Graphics.java:42) at com.sun.prism.es2.ES2Graphics.create(ES2Graphics.java:50) at com.sun.prism.es2.ES2RTTexture.createGraphics(ES2RTTexture.java:312) at com.sun.prism.impl.ps.BaseShaderGraphics.initLCDSampleRT(BaseShaderGraphics. java:1929) at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java: 2059) at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312) at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270) at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:261) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.CacheFilter.impl_renderNodeToCache(CacheFilter.java: 671) at com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:575) at com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2358) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2044) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:477) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:323) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11 42) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6 17) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRender er.java:125) at java.lang.Thread.run(Thread.java:745) "JavaFX-Launcher" #8 prio=5 os_prio=0 tid=0x00007fec883c5800 nid=0x17dd waiting on condition [0x00007fec71292000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000e0ba48f0> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru ptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt ibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java :873) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(Launche rImpl.java:182) at com.sun.javafx.application.LauncherImpl$$Lambda$2/93122545.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) "Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007fec880ba000 nid=0x17db runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007fec880b5000 nid=0x17da waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007fec880b2000 nid=0x17d9 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007fec880b0800 nid=0x17d8 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007fec8807a800 nid=0x17d7 in Object.wait() [0x00007fec72046000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000e0a33fe8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0x00000000e0a33fe8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209) "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007fec88078800 nid=0x17d6 in Object.wait() [0x00007fec72147000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000e0a34028> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) - locked <0x00000000e0a34028> (a java.lang.ref.Reference$Lock) "main" #1 prio=5 os_prio=0 tid=0x00007fec8800a000 nid=0x17d2 waiting on condition [0x00007fec8edbb000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000e0ffcda8> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru ptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt ibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java: 200) at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java: 143) at javafx.application.Application.launch(Application.java:252) at org.adoptopenjdk.jitwatch.ui.JITWatchUI.(JITWatchUI.java:185) at org.adoptopenjdk.jitwatch.launch.LaunchUI.main(LaunchUI.java:18) "VM Thread" os_prio=0 tid=0x00007fec88073800 nid=0x17d5 runnable "GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007fec8801f000 nid=0x17d3 runnable "GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007fec88021000 nid=0x17d4 runnable "VM Periodic Task Thread" os_prio=0 tid=0x00007fec880bd000 nid=0x17dc waiting on condition JNI global references: 1037 On Tue, December 22, 2015 08:00, Chien Yang wrote: > Hi Chris, > > > JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There > is a high likelihood that the drop in performance is caused by the switch > from sw pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA 3150 is an > underpowered GPU for JavaFX's es2 pipe. You can try forcing JavaFX to use > its sw pipe by specifying -Dprism.order=sw in the run command. > > - Chien > > > On 12/21/2015 03:02 PM, Chris Newland wrote: > >> Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy >> to Debian Jessie and JavaFX performance has suffered a huge drop :( >> >> >> Possibly not JavaFX related but native apps (firefox etc) all seem to >> perform the same and glxgears runs full sync framerate and 350fps >> unsynced. >> >> JavaFX stages open blank and can take 5 seconds to render. Trying to >> scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app >> for 10s+. >> >> Previously stages opened in under 1s and scrolling was instant. >> >> >> My DemoFX test platform (Canvas based effects) seems to run the same so >> it only appears to be windows / stages that are affected. >> >> It's an old (2010) system but JavaFX performance has dropped from slow >> to unusable. >> >> Will keep investigating and test on my Debian desktop once I upgrade it >> to Jessie. >> >> >> Cheers, >> >> >> Chris >> @chriswhocodes >> >> >> JavaFX debug: >> >> >> Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension >> initializeIfAvailable INFO: Failed to initialize management extension >> java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl >> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at >> java.lang.ClassLoader.loadClass(ClassLoader.java:424) >> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at >> java.lang.Class.forName0(Native Method) at >> java.lang.Class.forName(Class.java:264) >> at >> com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:4 >> 0) >> at >> com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java: >> 669) >> at >> com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl >> .java:695) >> at >> com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(La >> uncherImpl.java:182) >> at java.lang.Thread.run(Thread.java:745) >> >> Prism pipeline init order: es2 sw >> Using java-based Pisces rasterizer >> Using dirty region optimizations >> Not using texture mask for primitives >> Not forcing power of 2 sizes for textures >> Using hardware CLAMP_TO_ZERO mode >> Opting in for HiDPI pixel scaling >> Prism pipeline name = com.sun.prism.es2.ES2Pipeline >> Loading ES2 native library ... prism_es2 >> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from >> relative path succeeded. GLFactory using com.sun.prism.es2.X11GLFactory >> (X) Got class = class com.sun.prism.es2.ES2Pipeline >> Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline >> JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit >> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from >> relative path Maximum supported texture size: 2048 >> Non power of two texture support = true >> Maximum number of vertex attributes = 16 >> Maximum number of uniform vertex components = 16384 >> Maximum number of uniform fragment components = 16384 >> Maximum number of varying components = 32 >> Maximum number of texture units usable in a vertex shader = 8 >> Maximum number of texture units usable in a fragment shader = 8 >> Graphics Vendor: Intel Open Source Technology Center >> Renderer: Mesa DRI Intel(R) IGD >> Version: 2.1 Mesa 10.3.2 >> vsync: true vpipe: true >> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so >> from relative path Loaded >> /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.so >> from relative path Loaded >> /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so >> from relative path ES2ResourceFactory: Prism - createStockShader: >> FillPgram_Color.frag >> new alphas ES2ResourceFactory: Prism - createStockShader: >> Texture_Color.frag >> ES2ResourceFactory: Prism - createStockShader: >> Texture_LinearGradient_PAD.frag >> ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag >> ES2ResourceFactory: Prism - createStockShader: >> Solid_TextureFirstPassLCD.frag >> ES2ResourceFactory: Prism - createStockShader: >> Solid_TextureSecondPassLCD.frag >> ES2ResourceFactory: Prism - createStockShader: >> FillPgram_LinearGradient_PAD.frag >> ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag >> ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag >> new alphas new alphas PPSRenderer: scenario.effect - createShader: >> LinearConvolveShadow_4 >> >> >> > > From david.grieve at oracle.com Tue Dec 22 13:51:44 2015 From: david.grieve at oracle.com (David Grieve) Date: Tue, 22 Dec 2015 08:51:44 -0500 Subject: Constant resetting to initial-state when adding/remove styleclasses In-Reply-To: <5678EA97.1080803@bestsolution.at> References: <5678EA97.1080803@bestsolution.at> Message-ID: <56795570.2000408@oracle.com> Adding/removing style-classes is simply bad practice. And not just in JavaFX. It is better to use pseudo-class state. When the style-class changes, the set of styles that match a node can, and is very likely to, change. The css implementation 're-applies' css to the node and its children by finding the new set of matching styles, resetting all properties that were set by css to their defaults, and then setting the properties according to the new set of matching styles. With pseudo-class state, the only thing that happens is the set of styles that match the pseudo-class state are applied. Much less overhead. That said, there are plenty of places where the css implementation could be better optimized. This use-case is certainly one of them. On 12/22/15 1:15 AM, Tom Schindl wrote: > Hi, > > While debugging some code I attached a listener to a property and > noticed that whenever a style-class is added to the control or even > worse somewhere in the parent hierarchy that FX resets the value to its > initial state (Node#reapplyCss & CssStyleHelper) only to set it back to > it's real value with the next CSS-Pass triggered by the next pulse. > > I don't want to imagine if this happens with many value set via CSS and > eg adding/remove a styleclass to the scene root. Is this behavior really > by design like this? > > You can try that yourself with the attached program below and using the > css at the end. I'm writing this because of Kevins request what the team > should invest time to because of Java9 delays and frankly all of those > bugs/features sound relevant and interesting but JavaFX performance > (most important CSS-Performance) is still miles away from eg browsers > who are the main competitors. > > It doesn't help me to get an java.awt.Desktop replacement if my > input-forms do not render in a decent time frame - I would even say > rendering them in 2015 most be almost instant. > > Tom > >> package application; >> >> import javafx.application.Application; >> import javafx.stage.Stage; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.layout.BorderPane; >> import javafx.scene.layout.HBox; >> import javafx.scene.layout.StackPane; >> >> >> public class Main extends Application { >> @Override >> public void start(Stage primaryStage) { >> try { >> BorderPane root = new BorderPane(); >> >> StackPane p = new StackPane(); >> p.getStyleClass().add("test-css"); >> p.maxWidthProperty().addListener( (o, ol, ne) -> { >> System.err.println("Modified : " + ol + " " + ne); >> Thread.dumpStack(); >> }); >> >> root.setCenter(p); >> >> HBox box = new HBox(); >> >> { >> Button b = new Button("Modify Pane CSS"); >> b.setOnAction( e -> p.getStyleClass().add("dummy")); >> box.getChildren().add(b); >> } >> >> { >> Button b = new Button("Modify Root CSS"); >> b.setOnAction( e -> { >> root.getStyleClass().add("dummy"); >> }); >> box.getChildren().add(b); >> } >> >> root.setBottom(box); >> >> Scene scene = new Scene(root,400,400); >> scene.getStylesheets().addAll(getClass().getResource("application.css").toExternalForm()); >> primaryStage.setScene(scene); >> primaryStage.show(); >> } catch(Exception e) { >> e.printStackTrace(); >> } >> } >> >> public static void main(String[] args) { >> launch(args); >> } >> } > >> .test-css { >> -fx-max-width: 300; >> } > > From kevin.rushforth at oracle.com Tue Dec 22 15:52:26 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 22 Dec 2015 07:52:26 -0800 Subject: Huge JavaFX performance drop in Debian Jessie In-Reply-To: <036f01d13c90$9d4a8980$d7df9c80$@eu> References: <5679032A.4030708@oracle.com> <036f01d13c90$9d4a8980$d7df9c80$@eu> Message-ID: <567971BA.6010909@oracle.com> We require Pixel Shader 3 support and this GPU doesn't really have full HW support. Most drivers will attempt to emulate with somewhat mixed results. If this card were in a system running Windows we would automatically detect and fall back to SW. This isn't as easy to do in Linux, but maybe it would be possible (Chien might want to comment on the feasibility of detecting this on Linux). -- Kevin Markus KARG wrote: > Just to understand "not supported GPU" better: Is there GPU-specific code in > JavaFX? I thought JFX is using vendor-neutral APIs to access the GPU? > > -Markus > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of > Chien Yang > Sent: Dienstag, 22. Dezember 2015 09:01 > To: cnewland at chrisnewland.com; openjfx-dev at openjdk.java.net > Subject: Re: Huge JavaFX performance drop in Debian Jessie > > Hi Chris, > > JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There is a > high likelihood that the drop in performance is caused by the switch from sw > pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA > 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing > JavaFX to use its sw pipe by specifying -Dprism.order=sw in the run command. > > - Chien > > On 12/21/2015 03:02 PM, Chris Newland wrote: > >> Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian >> Wheezy to Debian Jessie and JavaFX performance has suffered a huge >> drop :( >> >> Possibly not JavaFX related but native apps (firefox etc) all seem to >> perform the same and glxgears runs full sync framerate and 350fps >> unsynced. >> >> JavaFX stages open blank and can take 5 seconds to render. Trying to >> scroll a scrollbar pegs the CPU (java process at 100%) and hangs the >> app for 10s+. >> >> Previously stages opened in under 1s and scrolling was instant. >> >> My DemoFX test platform (Canvas based effects) seems to run the same >> so it only appears to be windows / stages that are affected. >> >> It's an old (2010) system but JavaFX performance has dropped from slow >> to unusable. >> >> Will keep investigating and test on my Debian desktop once I upgrade >> it to Jessie. >> >> Cheers, >> >> Chris >> @chriswhocodes >> >> JavaFX debug: >> >> Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension >> initializeIfAvailable >> INFO: Failed to initialize management extension >> java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl >> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) >> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) >> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) >> at java.lang.Class.forName0(Native Method) >> at java.lang.Class.forName(Class.java:264) >> at >> > com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40) > >> at >> >> > com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669) > >> at >> >> > com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java > :695) > >> at >> >> > com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(Launche > rImpl.java:182) > >> at java.lang.Thread.run(Thread.java:745) >> >> Prism pipeline init order: es2 sw >> Using java-based Pisces rasterizer >> Using dirty region optimizations >> Not using texture mask for primitives >> Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO >> mode Opting in for HiDPI pixel scaling Prism pipeline name = >> com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2 >> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so >> from relative path >> succeeded. >> GLFactory using com.sun.prism.es2.X11GLFactory >> (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism >> pipeline: com.sun.prism.es2.ES2Pipeline >> JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit >> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from >> relative path Maximum supported texture size: 2048 Non power of two >> texture support = true Maximum number of vertex attributes = 16 >> Maximum number of uniform vertex components = 16384 Maximum number of >> uniform fragment components = 16384 Maximum number of varying >> components = 32 Maximum number of texture units usable in a vertex >> shader = 8 Maximum number of texture units usable in a fragment shader >> = 8 Graphics Vendor: Intel Open Source Technology Center >> Renderer: Mesa DRI Intel(R) IGD >> Version: 2.1 Mesa 10.3.2 >> vsync: true vpipe: true >> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so >> from relative path Loaded >> /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.s >> o >> from relative path >> Loaded >> /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so >> from relative path >> ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag >> new alphas >> ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag >> ES2ResourceFactory: Prism - createStockShader: >> Texture_LinearGradient_PAD.frag >> ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag >> ES2ResourceFactory: Prism - createStockShader: >> Solid_TextureFirstPassLCD.frag >> ES2ResourceFactory: Prism - createStockShader: >> Solid_TextureSecondPassLCD.frag >> ES2ResourceFactory: Prism - createStockShader: >> FillPgram_LinearGradient_PAD.frag >> ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag >> ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag >> new alphas new alphas >> PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_4 >> >> >> > > > From kevin.rushforth at oracle.com Tue Dec 22 15:57:12 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 22 Dec 2015 07:57:12 -0800 Subject: Huge JavaFX performance drop in Debian Jessie In-Reply-To: <038f01d13c9b$381ce430$a856ac90$@eu> References: <5679032A.4030708@oracle.com> <76ecebad11668a4e19ff299c98f145bf.squirrel@excalibur.xssl.net> <038f01d13c9b$381ce430$a856ac90$@eu> Message-ID: <567972D8.3070006@oracle.com> This is the normal stack trace I would expect when waiting for rendering to complete and the rendering is taking a long time. So in short: I see nothing strange or remarkable about the stack trace. -- Kevin Markus KARG wrote: > Thanks for the stacktrace. This is definitively a separate issue. Yours > actually waits for the renderer to complete the previous frame. Mine is > heavily working inside ToolbarSkin. Technically unrelated, but leading to > the same outcome: frozen UI. > > What seems odd is that the object reference the JavaFX thread is waiting for > is not locked by any other thread, particularly *not* the renderer. Never > saw something like that. > > One more thing I noticed in your stacktrace: The prism font dispose has > locked an object and now waits for exactly that object. That looks strange. > How can a thread wait for an object which itself has locked?! > > -Markus > > -----Original Message----- > From: Chris Newland [mailto:cnewland at chrisnewland.com] > Sent: Dienstag, 22. Dezember 2015 10:06 > To: Chien Yang; Markus KARG > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Huge JavaFX performance drop in Debian Jessie > > Hi Chien, > > Thanks, using -Dprism.order=sw prevents the multi-second hangs but JavaFX > desktop performance is still noticably worse than in Wheezy (probably > because the CPU is now doing all the work and this little Atom is maxed > out). > > Something has definitely changed under the hood in Jessie but it's > probably only noticeable in these low powered GPUs. Slowdown is with > LXDE+lightdm and also Gnome3. > > Markus, > > Here is what the threads are doing when the scrollbar is hanging (with es2) > > Regards, > > Chris > > 2015-12-22 09:00:30 > Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode): > > "Attach Listener" #14 daemon prio=9 os_prio=0 tid=0x00007fec58001000 > nid=0x17f9 waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Prism Font Disposer" #13 daemon prio=10 os_prio=0 tid=0x00007fec2c192800 > nid=0x17e1 in Object.wait() [0x00007fec3a5b2000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000e10486f8> (a > java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) > - locked <0x00000000e10486f8> (a java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) > at com.sun.javafx.font.Disposer.run(Disposer.java:93) > at java.lang.Thread.run(Thread.java:745) > > "JavaFX Application Thread" #12 prio=5 os_prio=0 tid=0x00007fec4c093800 > nid=0x17e0 waiting on condition [0x00007fec4412e000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000f67d7668> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( > AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru > ptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt > ibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > com.sun.javafx.tk.quantum.PaintCollector.waitForRenderingToComplete(PaintCol > lector.java:157) > at > com.sun.javafx.tk.quantum.GlassScene.waitForRenderingToComplete(GlassScene.j > ava:127) > at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2410) > at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) > at com.sun.javafx.tk.Toolkit$$Lambda$359/1368562994.run(Unknown > Source) > at java.security.AccessController.doPrivileged(Native Method) > at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) > at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) > at > com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) > at > com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) > at > com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolki > t.java:319) > at > com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/1617205338.run(Unknown > Source) > at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java > :95) > at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) > at > com.sun.glass.ui.gtk.GtkApplication.lambda$null$49(GtkApplication.java:139) > at > com.sun.glass.ui.gtk.GtkApplication$$Lambda$43/357920869.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:745) > > "Thread-2" #11 daemon prio=5 os_prio=0 tid=0x00007fec4c08f800 nid=0x17df > in Object.wait() [0x00007fec70143000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:502) > at > com.sun.glass.ui.InvokeLaterDispatcher.run(InvokeLaterDispatcher.java:126) > - locked <0x00000000e0ffc670> (a java.lang.StringBuilder) > > "QuantumRenderer-0" #9 daemon prio=5 os_prio=0 tid=0x00007fec4c04c000 > nid=0x17de runnable [0x00007fec7118b000] > java.lang.Thread.State: RUNNABLE > at com.sun.prism.es2.GLContext.nDrawIndexedQuads(Native Method) > at com.sun.prism.es2.GLContext.drawIndexedQuads(GLContext.java:724) > at > com.sun.prism.es2.ES2VertexBuffer.drawQuads(ES2VertexBuffer.java:65) > at com.sun.prism.impl.VertexBuffer.flush(VertexBuffer.java:105) > at > com.sun.prism.impl.BaseContext.flushVertexBuffer(BaseContext.java:111) > at > com.sun.prism.impl.ps.BaseShaderContext.setRenderTarget(BaseShaderContext.ja > va:747) > at > com.sun.prism.impl.BaseContext.setRenderTarget(BaseContext.java:121) > at com.sun.prism.impl.BaseGraphics.(BaseGraphics.java:105) > at > com.sun.prism.impl.ps.BaseShaderGraphics.(BaseShaderGraphics.java:86) > at com.sun.prism.es2.ES2Graphics.(ES2Graphics.java:42) > at com.sun.prism.es2.ES2Graphics.create(ES2Graphics.java:50) > at > com.sun.prism.es2.ES2RTTexture.createGraphics(ES2RTTexture.java:312) > at > com.sun.prism.impl.ps.BaseShaderGraphics.initLCDSampleRT(BaseShaderGraphics. > java:1929) > at > com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java: > 2059) > at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312) > at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270) > at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:261) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at > com.sun.javafx.sg.prism.CacheFilter.impl_renderNodeToCache(CacheFilter.java: > 671) > at com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:575) > at com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2358) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2044) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > at > com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:477) > at > com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:323) > at > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11 > 42) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6 > 17) > at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRender > er.java:125) > at java.lang.Thread.run(Thread.java:745) > > "JavaFX-Launcher" #8 prio=5 os_prio=0 tid=0x00007fec883c5800 nid=0x17dd > waiting on condition [0x00007fec71292000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000e0ba48f0> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( > AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru > ptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt > ibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java > :873) > at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(Launche > rImpl.java:182) > at > com.sun.javafx.application.LauncherImpl$$Lambda$2/93122545.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:745) > > "Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007fec880ba000 > nid=0x17db runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007fec880b5000 > nid=0x17da waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007fec880b2000 > nid=0x17d9 waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007fec880b0800 > nid=0x17d8 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007fec8807a800 nid=0x17d7 > in Object.wait() [0x00007fec72046000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000e0a33fe8> (a > java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) > - locked <0x00000000e0a33fe8> (a java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) > at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209) > > "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007fec88078800 > nid=0x17d6 in Object.wait() [0x00007fec72147000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000e0a34028> (a java.lang.ref.Reference$Lock) > at java.lang.Object.wait(Object.java:502) > at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) > - locked <0x00000000e0a34028> (a java.lang.ref.Reference$Lock) > > "main" #1 prio=5 os_prio=0 tid=0x00007fec8800a000 nid=0x17d2 waiting on > condition [0x00007fec8edbb000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000e0ffcda8> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( > AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru > ptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt > ibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java: > 200) > at > com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java: > 143) > at javafx.application.Application.launch(Application.java:252) > at > org.adoptopenjdk.jitwatch.ui.JITWatchUI.(JITWatchUI.java:185) > at org.adoptopenjdk.jitwatch.launch.LaunchUI.main(LaunchUI.java:18) > > "VM Thread" os_prio=0 tid=0x00007fec88073800 nid=0x17d5 runnable > > "GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007fec8801f000 > nid=0x17d3 runnable > > "GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007fec88021000 > nid=0x17d4 runnable > > "VM Periodic Task Thread" os_prio=0 tid=0x00007fec880bd000 nid=0x17dc > waiting on condition > > JNI global references: 1037 > > > > > > > > On Tue, December 22, 2015 08:00, Chien Yang wrote: > >> Hi Chris, >> >> >> JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There >> is a high likelihood that the drop in performance is caused by the switch >> from sw pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA 3150 is an >> underpowered GPU for JavaFX's es2 pipe. You can try forcing JavaFX to use >> its sw pipe by specifying -Dprism.order=sw in the run command. >> >> - Chien >> >> >> On 12/21/2015 03:02 PM, Chris Newland wrote: >> >> >>> Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy >>> to Debian Jessie and JavaFX performance has suffered a huge drop :( >>> >>> >>> Possibly not JavaFX related but native apps (firefox etc) all seem to >>> perform the same and glxgears runs full sync framerate and 350fps >>> unsynced. >>> >>> JavaFX stages open blank and can take 5 seconds to render. Trying to >>> scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app >>> for 10s+. >>> >>> Previously stages opened in under 1s and scrolling was instant. >>> >>> >>> My DemoFX test platform (Canvas based effects) seems to run the same so >>> it only appears to be windows / stages that are affected. >>> >>> It's an old (2010) system but JavaFX performance has dropped from slow >>> to unusable. >>> >>> Will keep investigating and test on my Debian desktop once I upgrade it >>> to Jessie. >>> >>> >>> Cheers, >>> >>> >>> Chris >>> @chriswhocodes >>> >>> >>> JavaFX debug: >>> >>> >>> Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension >>> initializeIfAvailable INFO: Failed to initialize management extension >>> java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl >>> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at >>> java.lang.ClassLoader.loadClass(ClassLoader.java:424) >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at >>> java.lang.Class.forName0(Native Method) at >>> java.lang.Class.forName(Class.java:264) >>> at >>> com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:4 >>> 0) >>> at >>> com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java: >>> 669) >>> at >>> com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl >>> .java:695) >>> at >>> com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(La >>> uncherImpl.java:182) >>> at java.lang.Thread.run(Thread.java:745) >>> >>> Prism pipeline init order: es2 sw >>> Using java-based Pisces rasterizer >>> Using dirty region optimizations >>> Not using texture mask for primitives >>> Not forcing power of 2 sizes for textures >>> Using hardware CLAMP_TO_ZERO mode >>> Opting in for HiDPI pixel scaling >>> Prism pipeline name = com.sun.prism.es2.ES2Pipeline >>> Loading ES2 native library ... prism_es2 >>> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from >>> relative path succeeded. GLFactory using com.sun.prism.es2.X11GLFactory >>> (X) Got class = class com.sun.prism.es2.ES2Pipeline >>> Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline >>> JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit >>> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from >>> relative path Maximum supported texture size: 2048 >>> Non power of two texture support = true >>> Maximum number of vertex attributes = 16 >>> Maximum number of uniform vertex components = 16384 >>> Maximum number of uniform fragment components = 16384 >>> Maximum number of varying components = 32 >>> Maximum number of texture units usable in a vertex shader = 8 >>> Maximum number of texture units usable in a fragment shader = 8 >>> Graphics Vendor: Intel Open Source Technology Center >>> Renderer: Mesa DRI Intel(R) IGD >>> Version: 2.1 Mesa 10.3.2 >>> vsync: true vpipe: true >>> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so >>> from relative path Loaded >>> /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.so >>> from relative path Loaded >>> /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so >>> from relative path ES2ResourceFactory: Prism - createStockShader: >>> FillPgram_Color.frag >>> new alphas ES2ResourceFactory: Prism - createStockShader: >>> Texture_Color.frag >>> ES2ResourceFactory: Prism - createStockShader: >>> Texture_LinearGradient_PAD.frag >>> ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag >>> ES2ResourceFactory: Prism - createStockShader: >>> Solid_TextureFirstPassLCD.frag >>> ES2ResourceFactory: Prism - createStockShader: >>> Solid_TextureSecondPassLCD.frag >>> ES2ResourceFactory: Prism - createStockShader: >>> FillPgram_LinearGradient_PAD.frag >>> ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag >>> ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag >>> new alphas new alphas PPSRenderer: scenario.effect - createShader: >>> LinearConvolveShadow_4 >>> >>> >>> >>> >> > > > > From markus at headcrashing.eu Tue Dec 22 16:19:40 2015 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 22 Dec 2015 17:19:40 +0100 Subject: Huge JavaFX performance drop in Debian Jessie In-Reply-To: <567972D8.3070006@oracle.com> References: <5679032A.4030708@oracle.com> <76ecebad11668a4e19ff299c98f145bf.squirrel@excalibur.xssl.net> <038f01d13c9b$381ce430$a856ac90$@eu> <567972D8.3070006@oracle.com> Message-ID: <048101d13cd4$8fab0c20$af012460$@eu> What I meant with "odd" is the fact that a thread is waiting for a lock instance which is not told by the stack trace as locked by another thread, and that there is a thread which is waiting for a lock obtained by itself. I haven't seen this patterns before, but I also must confess that I am not an expert in reading stack traces. ;-) -Markus From: Kevin Rushforth [mailto:kevin.rushforth at oracle.com] Sent: Dienstag, 22. Dezember 2015 16:57 To: Markus KARG Cc: openjfx-dev at openjdk.java.net Subject: Re: Huge JavaFX performance drop in Debian Jessie This is the normal stack trace I would expect when waiting for rendering to complete and the rendering is taking a long time. So in short: I see nothing strange or remarkable about the stack trace. -- Kevin Markus KARG wrote: Thanks for the stacktrace. This is definitively a separate issue. Yours actually waits for the renderer to complete the previous frame. Mine is heavily working inside ToolbarSkin. Technically unrelated, but leading to the same outcome: frozen UI. What seems odd is that the object reference the JavaFX thread is waiting for is not locked by any other thread, particularly *not* the renderer. Never saw something like that. One more thing I noticed in your stacktrace: The prism font dispose has locked an object and now waits for exactly that object. That looks strange. How can a thread wait for an object which itself has locked?! -Markus -----Original Message----- From: Chris Newland [mailto:cnewland at chrisnewland.com] Sent: Dienstag, 22. Dezember 2015 10:06 To: Chien Yang; Markus KARG Cc: openjfx-dev at openjdk.java.net Subject: Re: Huge JavaFX performance drop in Debian Jessie Hi Chien, Thanks, using -Dprism.order=sw prevents the multi-second hangs but JavaFX desktop performance is still noticably worse than in Wheezy (probably because the CPU is now doing all the work and this little Atom is maxed out). Something has definitely changed under the hood in Jessie but it's probably only noticeable in these low powered GPUs. Slowdown is with LXDE+lightdm and also Gnome3. Markus, Here is what the threads are doing when the scrollbar is hanging (with es2) Regards, Chris 2015-12-22 09:00:30 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode): "Attach Listener" #14 daemon prio=9 os_prio=0 tid=0x00007fec58001000 nid=0x17f9 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Prism Font Disposer" #13 daemon prio=10 os_prio=0 tid=0x00007fec2c192800 nid=0x17e1 in Object.wait() [0x00007fec3a5b2000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000e10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0x00000000e10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at com.sun.javafx.font.Disposer.run(Disposer.java:93) at java.lang.Thread.run(Thread.java:745) "JavaFX Application Thread" #12 prio=5 os_prio=0 tid=0x00007fec4c093800 nid=0x17e0 waiting on condition [0x00007fec4412e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f67d7668> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru ptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt ibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.tk.quantum.PaintCollector.waitForRenderingToComplete(PaintCol lector.java:157) at com.sun.javafx.tk.quantum.GlassScene.waitForRenderingToComplete(GlassScene.j ava:127) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2410) at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) at com.sun.javafx.tk.Toolkit$$Lambda$359/1368562994.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolki t.java:319) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/1617205338.run(Unknown Source) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java :95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$49(GtkApplication.java:139) at com.sun.glass.ui.gtk.GtkApplication$$Lambda$43/357920869.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) "Thread-2" #11 daemon prio=5 os_prio=0 tid=0x00007fec4c08f800 nid=0x17df in Object.wait() [0x00007fec70143000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at com.sun.glass.ui.InvokeLaterDispatcher.run(InvokeLaterDispatcher.java:126) - locked <0x00000000e0ffc670> (a java.lang.StringBuilder) "QuantumRenderer-0" #9 daemon prio=5 os_prio=0 tid=0x00007fec4c04c000 nid=0x17de runnable [0x00007fec7118b000] java.lang.Thread.State: RUNNABLE at com.sun.prism.es2.GLContext.nDrawIndexedQuads(Native Method) at com.sun.prism.es2.GLContext.drawIndexedQuads(GLContext.java:724) at com.sun.prism.es2.ES2VertexBuffer.drawQuads(ES2VertexBuffer.java:65) at com.sun.prism.impl.VertexBuffer.flush(VertexBuffer.java:105) at com.sun.prism.impl.BaseContext.flushVertexBuffer(BaseContext.java:111) at com.sun.prism.impl.ps.BaseShaderContext.setRenderTarget(BaseShaderContext.ja va:747) at com.sun.prism.impl.BaseContext.setRenderTarget(BaseContext.java:121) at com.sun.prism.impl.BaseGraphics.(BaseGraphics.java:105) at com.sun.prism.impl.ps.BaseShaderGraphics.(BaseShaderGraphics.java:86) at com.sun.prism.es2.ES2Graphics.(ES2Graphics.java:42) at com.sun.prism.es2.ES2Graphics.create(ES2Graphics.java:50) at com.sun.prism.es2.ES2RTTexture.createGraphics(ES2RTTexture.java:312) at com.sun.prism.impl.ps.BaseShaderGraphics.initLCDSampleRT(BaseShaderGraphics. java:1929) at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java: 2059) at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312) at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270) at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:261) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.CacheFilter.impl_renderNodeToCache(CacheFilter.java: 671) at com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:575) at com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2358) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2044) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:477) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:323) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11 42) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6 17) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRender er.java:125) at java.lang.Thread.run(Thread.java:745) "JavaFX-Launcher" #8 prio=5 os_prio=0 tid=0x00007fec883c5800 nid=0x17dd waiting on condition [0x00007fec71292000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000e0ba48f0> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru ptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt ibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java :873) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(Launche rImpl.java:182) at com.sun.javafx.application.LauncherImpl$$Lambda$2/93122545.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) "Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007fec880ba000 nid=0x17db runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007fec880b5000 nid=0x17da waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007fec880b2000 nid=0x17d9 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007fec880b0800 nid=0x17d8 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007fec8807a800 nid=0x17d7 in Object.wait() [0x00007fec72046000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000e0a33fe8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0x00000000e0a33fe8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209) "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007fec88078800 nid=0x17d6 in Object.wait() [0x00007fec72147000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000e0a34028> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) - locked <0x00000000e0a34028> (a java.lang.ref.Reference$Lock) "main" #1 prio=5 os_prio=0 tid=0x00007fec8800a000 nid=0x17d2 waiting on condition [0x00007fec8edbb000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000e0ffcda8> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru ptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt ibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java: 200) at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java: 143) at javafx.application.Application.launch(Application.java:252) at org.adoptopenjdk.jitwatch.ui.JITWatchUI.(JITWatchUI.java:185) at org.adoptopenjdk.jitwatch.launch.LaunchUI.main(LaunchUI.java:18) "VM Thread" os_prio=0 tid=0x00007fec88073800 nid=0x17d5 runnable "GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007fec8801f000 nid=0x17d3 runnable "GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007fec88021000 nid=0x17d4 runnable "VM Periodic Task Thread" os_prio=0 tid=0x00007fec880bd000 nid=0x17dc waiting on condition JNI global references: 1037 On Tue, December 22, 2015 08:00, Chien Yang wrote: Hi Chris, JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There is a high likelihood that the drop in performance is caused by the switch from sw pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing JavaFX to use its sw pipe by specifying -Dprism.order=sw in the run command. - Chien On 12/21/2015 03:02 PM, Chris Newland wrote: Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy to Debian Jessie and JavaFX performance has suffered a huge drop :( Possibly not JavaFX related but native apps (firefox etc) all seem to perform the same and glxgears runs full sync framerate and 350fps unsynced. JavaFX stages open blank and can take 5 seconds to render. Trying to scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app for 10s+. Previously stages opened in under 1s and scrolling was instant. My DemoFX test platform (Canvas based effects) seems to run the same so it only appears to be windows / stages that are affected. It's an old (2010) system but JavaFX performance has dropped from slow to unusable. Will keep investigating and test on my Debian desktop once I upgrade it to Jessie. Cheers, Chris @chriswhocodes JavaFX debug: Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension initializeIfAvailable INFO: Failed to initialize management extension java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:4 0) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java: 669) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl .java:695) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(La uncherImpl.java:182) at java.lang.Thread.run(Thread.java:745) Prism pipeline init order: es2 sw Using java-based Pisces rasterizer Using dirty region optimizations Not using texture mask for primitives Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode Opting in for HiDPI pixel scaling Prism pipeline name = com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2 Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from relative path succeeded. GLFactory using com.sun.prism.es2.X11GLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from relative path Maximum supported texture size: 2048 Non power of two texture support = true Maximum number of vertex attributes = 16 Maximum number of uniform vertex components = 16384 Maximum number of uniform fragment components = 16384 Maximum number of varying components = 32 Maximum number of texture units usable in a vertex shader = 8 Maximum number of texture units usable in a fragment shader = 8 Graphics Vendor: Intel Open Source Technology Center Renderer: Mesa DRI Intel(R) IGD Version: 2.1 Mesa 10.3.2 vsync: true vpipe: true Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so from relative path Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.so from relative path Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so from relative path ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag new alphas ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag ES2ResourceFactory: Prism - createStockShader: Texture_LinearGradient_PAD.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureFirstPassLCD.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureSecondPassLCD.frag ES2ResourceFactory: Prism - createStockShader: FillPgram_LinearGradient_PAD.frag ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag new alphas new alphas PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_4 From chris at chrisnewland.com Tue Dec 22 18:13:12 2015 From: chris at chrisnewland.com (Chris Newland) Date: Tue, 22 Dec 2015 18:13:12 +0000 Subject: Huge JavaFX performance drop in Debian Jessie In-Reply-To: <567971BA.6010909@oracle.com> References: <5679032A.4030708@oracle.com> <036f01d13c90$9d4a8980$d7df9c80$@eu> <567971BA.6010909@oracle.com> Message-ID: <65008618-3D2F-48C9-B563-4996B4305077@chrisnewland.com> Hi Kevin, The JavaFX performance when forcing the sw pipeline is still much slower with Jessie than Wheezy so I'm hoping there is something I can do at the OS level to get back to previous sw performance. Will let you know if I find it! Cheers, Chris Sent from my iPhone > On 22 Dec 2015, at 15:52, Kevin Rushforth wrote: > > We require Pixel Shader 3 support and this GPU doesn't really have full HW support. Most drivers will attempt to emulate with somewhat mixed results. If this card were in a system running Windows we would automatically detect and fall back to SW. This isn't as easy to do in Linux, but maybe it would be possible (Chien might want to comment on the feasibility of detecting this on Linux). > > -- Kevin > > > Markus KARG wrote: >> Just to understand "not supported GPU" better: Is there GPU-specific code in >> JavaFX? I thought JFX is using vendor-neutral APIs to access the GPU? >> >> -Markus >> >> -----Original Message----- >> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of >> Chien Yang >> Sent: Dienstag, 22. Dezember 2015 09:01 >> To: cnewland at chrisnewland.com; openjfx-dev at openjdk.java.net >> Subject: Re: Huge JavaFX performance drop in Debian Jessie >> >> Hi Chris, >> >> JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There is a >> high likelihood that the drop in performance is caused by the switch from sw >> pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA >> 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing >> JavaFX to use its sw pipe by specifying -Dprism.order=sw in the run command. >> >> - Chien >> From vadim.pakhnushev at oracle.com Tue Dec 22 18:34:37 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 22 Dec 2015 21:34:37 +0300 Subject: CFV: New OpenJFX Committer: Johan Vos In-Reply-To: <567856E8.5020905@Oracle.com> References: <567856E8.5020905@Oracle.com> Message-ID: <567997BD.5000706@oracle.com> Vote: yes On 21.12.2015 22:45, David Hill wrote: > > I hereby nominate Johan Vos to OpenJFX Committer. > > Johan Vos (jvos) has been active in the OpenJFX community, and > instrumental in the maturity of Monocle, the owner of the Android and > IOS ports and is an OpenJFX Author. > > A list of Johan's commits is also available by the following links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos > > Votes are due by January 5th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From morris.meyer at oracle.com Tue Dec 22 20:07:44 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Tue, 22 Dec 2015 15:07:44 -0500 Subject: CFV: New OpenJFX Committer: Johan Vos In-Reply-To: <567856E8.5020905@Oracle.com> References: <567856E8.5020905@Oracle.com> Message-ID: <5679AD90.6020401@oracle.com> Vote: YES --morris On 12/21/15 2:45 PM, David Hill wrote: > > I hereby nominate Johan Vos to OpenJFX Committer. > > Johan Vos (jvos) has been active in the OpenJFX community, and > instrumental in the maturity of Monocle, the owner of the Android and > IOS ports and is an OpenJFX Author. > > A list of Johan's commits is also available by the following links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos > > Votes are due by January 5th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From David.Hill at Oracle.com Tue Dec 22 20:46:12 2015 From: David.Hill at Oracle.com (David Hill) Date: Tue, 22 Dec 2015 15:46:12 -0500 Subject: review: Cannot run gradle test tasks using a Jigsaw (jake) build Message-ID: <5679B694.4010801@Oracle.com> Kevin, Please review this JDK9/Jake specific change: Cannot run gradle test tasks using a Jigsaw (jake) build Note, that this change only enabled JDK9 based testing for base, graphics, controls. Coming soon: fxml and web which have been refactored and will be enabled later. SystemTest refactoring is in progress. https://bugs.openjdk.java.net/browse/JDK-8131896 http://cr.openjdk.java.net/~ddhill/8131896 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From David.Hill at Oracle.com Tue Dec 22 21:13:53 2015 From: David.Hill at Oracle.com (David Hill) Date: Tue, 22 Dec 2015 16:13:53 -0500 Subject: Update Netbeans test dependancies for Javafx Message-ID: <5679BD11.8020300@Oracle.com> Kevin, A small change so that a couple of modules can resolve dependent test shims. https://bugs.openjdk.java.net/browse/JDK-8146018 http://cr.openjdk.java.net/~ddhill/8146018 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From j.kapitza at schwarze-allianz.de Tue Dec 22 22:02:06 2015 From: j.kapitza at schwarze-allianz.de (Jens Kapitza) Date: Tue, 22 Dec 2015 23:02:06 +0100 Subject: Huge JavaFX performance drop in Debian Jessie In-Reply-To: <65008618-3D2F-48C9-B563-4996B4305077@chrisnewland.com> References: <5679032A.4030708@oracle.com> <036f01d13c90$9d4a8980$d7df9c80$@eu> <567971BA.6010909@oracle.com> <65008618-3D2F-48C9-B563-4996B4305077@chrisnewland.com> Message-ID: <1450821726.6751.7.camel@schwarze-allianz.de> Hi @all, i had just a quick look at the stack trace may be you can make your app perform better with setting javafx.animation.pulse. i have never used this by my own. (but may be you can slow down the pulse of repainting) there are much more options for debug and testing [1,2] On Linux maybe you can fallback to vesa driver for the old devices? and test the performance without intel driver? for an old PC the VESA driver has a better performance then the 'new' intel driver (card is not supported well enough) Cheers, Jens [1] https://community.oracle.com/thread/2390862?start=0&tstart=0 [2] https://bugs.openjdk.java.net/browse/JDK-8091497 Am Dienstag, den 22.12.2015, 18:13 +0000 schrieb Chris Newland: > Hi Kevin, > > The JavaFX performance when forcing the sw pipeline is still much > slower with Jessie than Wheezy so I'm hoping there is something I can > do at the OS level to get back to previous sw performance. > > Will let you know if I find it! > > Cheers, > > Chris > > Sent from my iPhone > > > On 22 Dec 2015, at 15:52, Kevin Rushforth < > > kevin.rushforth at oracle.com> wrote: > > > > We require Pixel Shader 3 support and this GPU doesn't really have > > full HW support. Most drivers will attempt to emulate with somewhat > > mixed results. If this card were in a system running Windows we > > would automatically detect and fall back to SW. This isn't as easy > > to do in Linux, but maybe it would be possible (Chien might want to > > comment on the feasibility of detecting this on Linux). > > > > -- Kevin > > > > > > Markus KARG wrote: > > > Just to understand "not supported GPU" better: Is there GPU > > > -specific code in > > > JavaFX? I thought JFX is using vendor-neutral APIs to access the > > > GPU? > > > > > > -Markus > > > > > > -----Original Message----- > > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] > > > On Behalf Of > > > Chien Yang > > > Sent: Dienstag, 22. Dezember 2015 09:01 > > > To: cnewland at chrisnewland.com; openjfx-dev at openjdk.java.net > > > Subject: Re: Huge JavaFX performance drop in Debian Jessie > > > > > > Hi Chris, > > > > > > JavaFX may run on Intel GMA 3150, but it is not a supported GPU. > > > There is a > > > high likelihood that the drop in performance is caused by the > > > switch from sw > > > pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA > > > 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try > > > forcing > > > JavaFX to use its sw pipe by specifying -Dprism.order=sw in the > > > run command. > > > > > > - Chien > > > From james.graham at oracle.com Tue Dec 22 23:46:29 2015 From: james.graham at oracle.com (Jim Graham) Date: Tue, 22 Dec 2015 15:46:29 -0800 Subject: CFV: New OpenJFX Committer: Johan Vos In-Reply-To: <567856E8.5020905@Oracle.com> References: <567856E8.5020905@Oracle.com> Message-ID: <5679E0D5.3090405@oracle.com> Vote: yes ...jim On 12/21/15 11:45 AM, David Hill wrote: > > I hereby nominate Johan Vos to OpenJFX Committer. > > Johan Vos (jvos) has been active in the OpenJFX community, and > instrumental in the maturity of Monocle, the owner of the Android and > IOS ports and is an OpenJFX Author. > > A list of Johan's commits is also available by the following links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos > > Votes are due by January 5th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a project > Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From alexander.kouznetsov at oracle.com Wed Dec 23 01:03:11 2015 From: alexander.kouznetsov at oracle.com (Alexander Kouznetsov) Date: Tue, 22 Dec 2015 17:03:11 -0800 Subject: CFV: New OpenJFX Committer: Johan Vos In-Reply-To: <567856E8.5020905@Oracle.com> References: <567856E8.5020905@Oracle.com> Message-ID: <5679F2CF.2010907@oracle.com> Vote: yes Best regards, Alexander Kouznetsov (408) 276-0387 On 21 ??? 2015 11:45, David Hill wrote: > > I hereby nominate Johan Vos to OpenJFX Committer. > > Johan Vos (jvos) has been active in the OpenJFX community, and > instrumental in the maturity of Monocle, the owner of the Android and > IOS ports and is an OpenJFX Author. > > A list of Johan's commits is also available by the following links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos > > Votes are due by January 5th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From jasper.potts at oracle.com Wed Dec 23 02:10:48 2015 From: jasper.potts at oracle.com (Jasper Potts) Date: Tue, 22 Dec 2015 18:10:48 -0800 Subject: CFV: New OpenJFX Committer: Johan Vos In-Reply-To: <5679F2CF.2010907@oracle.com> References: <567856E8.5020905@Oracle.com> <5679F2CF.2010907@oracle.com> Message-ID: <25A81133-8721-4AFC-BE78-1EC5A4934476@oracle.com> Vote: yes Sent from my iPhone > On Dec 22, 2015, at 5:03 PM, Alexander Kouznetsov wrote: > > Vote: yes > > Best regards, > Alexander Kouznetsov > (408) 276-0387 > >> On 21 ??? 2015 11:45, David Hill wrote: >> >> I hereby nominate Johan Vos to OpenJFX Committer. >> >> Johan Vos (jvos) has been active in the OpenJFX community, and instrumental in the maturity of Monocle, the owner of the Android and IOS ports and is an OpenJFX Author. >> >> A list of Johan's commits is also available by the following links >> >> http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos >> http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos >> >> Votes are due by January 5th, 2016. >> >> Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. >> >> [1] http://openjdk.java.net/census#openjfx >> >> [2] http://openjdk.java.net/bylaws#lazy-consensus >> >> [3] http://openjdk.java.net/projects#project-committer >> >> Thanks, >> >> Dave > From markus at headcrashing.eu Wed Dec 23 09:13:34 2015 From: markus at headcrashing.eu (Markus KARG) Date: Wed, 23 Dec 2015 10:13:34 +0100 Subject: EventFilter efficiency Message-ID: <050b01d13d62$3356a220$9a03e660$@eu> I need to react upon two distinct EventTypes. There are two possibilities: Adding two distinct event filters, each for its own event type, or add one event filter for a family of event types, using a switch statement in "application space" to filter for the right event. Certainly for an application programmer it might be more nice to have one distinct filter per event type, but I could imagine that having one common filter might reduce the overhead for JavaFX's event management? -Markus From David.Hill at Oracle.com Wed Dec 23 15:43:56 2015 From: David.Hill at Oracle.com (David Hill) Date: Wed, 23 Dec 2015 10:43:56 -0500 Subject: review: 8145857: Enable fxml module tests in jake Message-ID: <567AC13C.6060501@Oracle.com> Kevin, https://bugs.openjdk.java.net/browse/JDK-8145857 http://cr.openjdk.java.net/~ddhill/8145857 One small step closer.... -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From richard.bair at oracle.com Thu Dec 24 00:19:56 2015 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 23 Dec 2015 16:19:56 -0800 Subject: CFV: New OpenJFX Committer: Johan Vos In-Reply-To: <25A81133-8721-4AFC-BE78-1EC5A4934476@oracle.com> References: <567856E8.5020905@Oracle.com> <5679F2CF.2010907@oracle.com> <25A81133-8721-4AFC-BE78-1EC5A4934476@oracle.com> Message-ID: <59ECA697-0F35-4E0F-8374-65EFF7D0EAB6@oracle.com> Vote: YES > On Dec 22, 2015, at 6:10 PM, Jasper Potts wrote: > > Vote: yes > > Sent from my iPhone > >> On Dec 22, 2015, at 5:03 PM, Alexander Kouznetsov wrote: >> >> Vote: yes >> >> Best regards, >> Alexander Kouznetsov >> (408) 276-0387 >> >>> On 21 ??? 2015 11:45, David Hill wrote: >>> >>> I hereby nominate Johan Vos to OpenJFX Committer. >>> >>> Johan Vos (jvos) has been active in the OpenJFX community, and instrumental in the maturity of Monocle, the owner of the Android and IOS ports and is an OpenJFX Author. >>> >>> A list of Johan's commits is also available by the following links >>> >>> http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos >>> http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos >>> >>> Votes are due by January 5th, 2016. >>> >>> Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. >>> >>> For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. >>> >>> [1] http://openjdk.java.net/census#openjfx >>> >>> [2] http://openjdk.java.net/bylaws#lazy-consensus >>> >>> [3] http://openjdk.java.net/projects#project-committer >>> >>> Thanks, >>> >>> Dave >> From kevin.rushforth at oracle.com Thu Dec 24 01:27:25 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Dec 2015 17:27:25 -0800 Subject: Update on FX plans for JDK 9 In-Reply-To: <5672C4F0.20901@oracle.com> References: <5672C4F0.20901@oracle.com> Message-ID: <567B49FD.2030206@oracle.com> Thanks to everyone who has commented on this. With the winter holidays upon us, we will respond to feedback and pick this up next year. -- Kevin Kevin Rushforth wrote: > Given the recently announced JDK 9 schedule slip [1], we have taken > the opportunity to explore what RFE's / Features we could possibly now > work on for inclusion in JDK 9. We wanted to give you a pre-holiday > season update on what we are currently thinking. > > The following RFEs are in progress or planned for JDK 9: > > JDK-8144585: Encapsulate JavaFX impl_* implementation methods > JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs > JDK-8091308: Define fine-grained permissions for JavaFX > Expose Hi-DPI properties for render scale and screen scale (FX > equivalent task for JEP 263 JDK-8055212) > Multi-resolution image support (FX equivalent task for JEP 251 > JDK-8046010) > > Additionally, we have started to look into making public API for some > of the impl_* API that will otherwise be hidden by JDK-8144585. See > Jonathan's earlier e-mail on the subject [2]. Here is what we have so > far: > > JDK-8144628: Provide API to expose list of showing Windows > JDK-8144625: Expose code and char properties on KeyCode > JDK-8144962: Promote TableColumn reorderable property to public API > JDK-8144871: Add default method getStyleableNode to Styleable interface > JDK-8145143: Promote Image.impl_getUrl() to public API as > Image.getUrl() > JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and > Labeled > > If there are any we have missed that your application depends on, > please send e-mail to Jonathan. > > Finally, here is an updated list of other RFEs we might consider for > JDK 9. We will not be able to do all of these, but hope to be able to > do many of them. We could use the help of the OpenJFX community in > prioritizing this list or possibly adding something that we missed, as > long as the scope is small enough. > > JDK-8091107: Add java.awt.Desktop support to javafx > JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX > (FX equivalent for JEP 272) > JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux > JDK-8092040: Implement Image writers for JavaFX > JDK-8091673: Runtime should have a published focus traversal API for > use in custom controls > JDK-8089311: [TableCell] commit on focus lost not possible in every > case > JDK-8090477: Customizable visibility timing for Tooltip > JDK-8092098: [TabPane] Support for draggable tabs > JDK-8144556: Add support to allow user specified rendering order > JDK-8145443: [Mac] Render directly to NSWIndow rather than via > CALayer for non-applet Stage > JDK-8145154: Provide public API support for PerformanceTracker > functionality > JDK-8090763: Public API for Glass's robot functionality > > Let us know what is most important to your application. > > We will keep you posted with updates on what exactly is being targeted > (note that you can track it by looking at the Fix Version in JBS, > which we strive to keep up-to-date). > > Thanks! > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html > [2] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html > > From james.graham at oracle.com Thu Dec 24 02:18:01 2015 From: james.graham at oracle.com (Jim Graham) Date: Wed, 23 Dec 2015 18:18:01 -0800 Subject: [8u/9] review request for 8139210: JavaFX rendering glitch when rendering many Paths using HW pipeline In-Reply-To: <563E8FCC.5050709@oracle.com> References: <563E8FCC.5050709@oracle.com> Message-ID: <567B55D9.2080705@oracle.com> Bumping this review request since it was shelved for a few weeks while I was working on other issues. The latest webrev (for 9 only for now) is now at: http://cr.openjdk.java.net/~flar/JDK-8139210/webrev.fx9.02/ This should address all of the concerns raised in the reviews in the bug report... ...jim On 11/7/15 3:57 PM, Jim Graham wrote: > I've created 2 versions of the fix for this bug. One is low source > impact but maintains the current convoluted role of the VertexBuffer > class in the code base and makes it slightly more murky. The second fix > touches a bunch of files, but it cleans up the use of the VB class > throughout the code base. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8139210 > > webrev for simple fix (8u & 9): > http://cr.openjdk.java.net/~flar/JDK-8139210/webrev.00/ > > webrev for bigger fix (8u): > http://cr.openjdk.java.net/~flar/JDK-8139210/webrev.alt8u.00/ > webrev for bigger fix (9): > http://cr.openjdk.java.net/~flar/JDK-8139210/webrev.alt9.00/ > (the 2 webrevs differ *only* in the location of the TestGraphics.java file) > > We should consider this for both 8u and 9. I recommend going with the > more complete fix for 9, but which is more appropriate for 8u? > > ...jim From markus at headcrashing.eu Thu Dec 24 08:12:00 2015 From: markus at headcrashing.eu (Markus KARG) Date: Thu, 24 Dec 2015 09:12:00 +0100 Subject: Update on FX plans for JDK 9 In-Reply-To: <567B49FD.2030206@oracle.com> References: <5672C4F0.20901@oracle.com> <567B49FD.2030206@oracle.com> Message-ID: <055701d13e22$c44d3760$4ce7a620$@eu> Kevin, I did a quick survey at TeamFX and asked every member to vote. Here is the official TeamFX opinion. I hope it is of any worth for you. Preface: Besides the ticket IDs you asked to prioritise TeamFX thinks that the top issue for JDK 9 should be performance, most notably of CSS processing. If there is one thing that holds back people from adopting JavaFX 8 for professional use cases, then it is the fact that you can quickly produce UI freezes of several seconds due to bugs and non-optimal CSS processing within JavaFX. If there would be a free voting upon features, TeamFX would replace all the below points if instead we could have JDK 9 running as fast as it could (i. e. for example create and show more than 1000 TextFields in less than a second; rotate a canvas containing 1000 complex paths fluently; and so an). Having said that, here is the summary of our survey: JIRA Ticket Votes Topic JDK-8092040 34 Implement Image writers for JavaFX JDK-8091673 30 Runtime should have a published focus traversal API for use in custom controls JDK-8090477 26 Customizable visibility timing for Tooltip JDK-8090763 22 Public API for Glass's robot functionality JDK-8089311 21 [TableCell] commit on focus lost not possible in every case JDK-8092098 21 [TabPane] Support for draggable tabs JDK-8091107 16 Add java.awt.Desktop support to javafx JDK-8144556 16 Add support to allow user specified rendering order JDK-8145443 16 [Mac] Render directly to NSWIndow rather than via CALayer for non-applet Stage JDK-8145154 16 Provide public API support for PerformanceTracker functionality JDK-8087516 15 Conditional support in JavaFX for GTK 3 on Linux JDK-8091517 7 Implement com.apple.eawt APIs that make sense in JavaFX (FX equivalent for JEP 272) Merry Christmas -Markus (TeamFX) -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Donnerstag, 24. Dezember 2015 02:27 To: openjfx-dev at openjdk.java.net Subject: Re: Update on FX plans for JDK 9 Thanks to everyone who has commented on this. With the winter holidays upon us, we will respond to feedback and pick this up next year. -- Kevin Kevin Rushforth wrote: > Given the recently announced JDK 9 schedule slip [1], we have taken > the opportunity to explore what RFE's / Features we could possibly now > work on for inclusion in JDK 9. We wanted to give you a pre-holiday > season update on what we are currently thinking. > > The following RFEs are in progress or planned for JDK 9: > > JDK-8144585: Encapsulate JavaFX impl_* implementation methods > JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs > JDK-8091308: Define fine-grained permissions for JavaFX > Expose Hi-DPI properties for render scale and screen scale (FX > equivalent task for JEP 263 JDK-8055212) > Multi-resolution image support (FX equivalent task for JEP 251 > JDK-8046010) > > Additionally, we have started to look into making public API for some > of the impl_* API that will otherwise be hidden by JDK-8144585. See > Jonathan's earlier e-mail on the subject [2]. Here is what we have so > far: > > JDK-8144628: Provide API to expose list of showing Windows > JDK-8144625: Expose code and char properties on KeyCode > JDK-8144962: Promote TableColumn reorderable property to public API > JDK-8144871: Add default method getStyleableNode to Styleable interface > JDK-8145143: Promote Image.impl_getUrl() to public API as > Image.getUrl() > JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and > Labeled > > If there are any we have missed that your application depends on, > please send e-mail to Jonathan. > > Finally, here is an updated list of other RFEs we might consider for > JDK 9. We will not be able to do all of these, but hope to be able to > do many of them. We could use the help of the OpenJFX community in > prioritizing this list or possibly adding something that we missed, as > long as the scope is small enough. > > JDK-8091107: Add java.awt.Desktop support to javafx > JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX > (FX equivalent for JEP 272) > JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux > JDK-8092040: Implement Image writers for JavaFX > JDK-8091673: Runtime should have a published focus traversal API for > use in custom controls > JDK-8089311: [TableCell] commit on focus lost not possible in every > case > JDK-8090477: Customizable visibility timing for Tooltip > JDK-8092098: [TabPane] Support for draggable tabs > JDK-8144556: Add support to allow user specified rendering order > JDK-8145443: [Mac] Render directly to NSWIndow rather than via > CALayer for non-applet Stage > JDK-8145154: Provide public API support for PerformanceTracker > functionality > JDK-8090763: Public API for Glass's robot functionality > > Let us know what is most important to your application. > > We will keep you posted with updates on what exactly is being targeted > (note that you can track it by looking at the Fix Version in JBS, > which we strive to keep up-to-date). > > Thanks! > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html > [2] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html > > From swpalmer at gmail.com Thu Dec 24 21:37:40 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 24 Dec 2015 16:37:40 -0500 Subject: JavaFX Docs Message-ID: Is there a plan to unify them with the rest of the JDK? I noticed the JDK 9 EA releases still have separate links to JDK and JavaFX docs. Scott From tbee at tbee.org Sat Dec 26 22:05:34 2015 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 26 Dec 2015 23:05:34 +0100 Subject: Text differences between OSes Message-ID: <567F0F2E.1080509@tbee.org> Maybe someone can help me get going on this: my 'unit' tests on some of the component in JFXtras fail when run on different operating systems; right now I'm running Debian next to Windows and rending the same Text node has different results: on Windows it is 847 pixels wide, on Linux it is 1083 pixels. So I suspected that a different default font was the cause, so I setup Google Roboto on both systems, but even then I have 1786 vs 2000 pixels (13.64 vs 15.26 for a single "0" with Roboto Medium on font-size 24). What else besides the font can cause this difference? Tom From herve.girod at gmail.com Sat Dec 26 22:24:18 2015 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Sat, 26 Dec 2015 23:24:18 +0100 Subject: Text differences between OSes In-Reply-To: <567F0F2E.1080509@tbee.org> References: <567F0F2E.1080509@tbee.org> Message-ID: <956A1EFD-FABB-4283-A541-88678323496B@gmail.com> In my memory the point size in Unix systems and Windows do not consider the same default screen density. See this for example: http://www.rfwilmut.clara.net/about/fonts.html Herv? Sent from my iPhone > On Dec 26, 2015, at 23:05, Tom Eugelink wrote: > > Maybe someone can help me get going on this: my 'unit' tests on some of the component in JFXtras fail when run on different operating systems; right now I'm running Debian next to Windows and rending the same Text node has different results: on Windows it is 847 pixels wide, on Linux it is 1083 pixels. > > So I suspected that a different default font was the cause, so I setup Google Roboto on both systems, but even then I have 1786 vs 2000 pixels (13.64 vs 15.26 for a single "0" with Roboto Medium on font-size 24). What else besides the font can cause this difference? > > Tom > From tbee at tbee.org Sun Dec 27 08:48:48 2015 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 27 Dec 2015 09:48:48 +0100 Subject: Text differences between OSes In-Reply-To: <956A1EFD-FABB-4283-A541-88678323496B@gmail.com> References: <567F0F2E.1080509@tbee.org> <956A1EFD-FABB-4283-A541-88678323496B@gmail.com> Message-ID: <567FA5F0.4050707@tbee.org> The article behind the link says that specifying the size in px should solve it, I just retried that, but unfortunately specifying the font size in any unit, pt, cm, px, results in different values on either OS. I've also tried replacing Text with Label and there a 24pt text is rendered as 19.0 or 21.0. Cleaner numbers. A 24px text as either 14.0 or 16.0, both exactly 2.0 width difference. So 12px is rendered as expected as 7.0 and 8.0, exactly 1.0 difference; half the size, half of the difference. Seems to indicate a scaling. But 18px as 11.0 and 12.0, I had expected 1.5 difference if it were a scale. On 26-12-2015 23:24, Herv? Girod wrote: > In my memory the point size in Unix systems and Windows do not consider the same default screen density. See this for example: http://www.rfwilmut.clara.net/about/fonts.html > > Herv? > > Sent from my iPhone > >> On Dec 26, 2015, at 23:05, Tom Eugelink wrote: >> >> Maybe someone can help me get going on this: my 'unit' tests on some of the component in JFXtras fail when run on different operating systems; right now I'm running Debian next to Windows and rending the same Text node has different results: on Windows it is 847 pixels wide, on Linux it is 1083 pixels. >> >> So I suspected that a different default font was the cause, so I setup Google Roboto on both systems, but even then I have 1786 vs 2000 pixels (13.64 vs 15.26 for a single "0" with Roboto Medium on font-size 24). What else besides the font can cause this difference? >> >> Tom >> From tbee at tbee.org Sun Dec 27 10:54:03 2015 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 27 Dec 2015 11:54:03 +0100 Subject: Text differences between OSes In-Reply-To: <567FA5F0.4050707@tbee.org> References: <567F0F2E.1080509@tbee.org> <956A1EFD-FABB-4283-A541-88678323496B@gmail.com> <567FA5F0.4050707@tbee.org> Message-ID: <567FC34B.8090904@tbee.org> Right. Nevermind. That's the drawback of CSS; on Debian the font was not correctly loaded, but there was no error. Both render at 11.0 now. Tom On 27-12-2015 09:48, Tom Eugelink wrote: > The article behind the link says that specifying the size in px should solve it, I just retried that, but unfortunately specifying the font size in any unit, pt, cm, px, results in different values on either OS. > > I've also tried replacing Text with Label and there a 24pt text is rendered as 19.0 or 21.0. Cleaner numbers. > A 24px text as either 14.0 or 16.0, both exactly 2.0 width difference. > So 12px is rendered as expected as 7.0 and 8.0, exactly 1.0 difference; half the size, half of the difference. Seems to indicate a scaling. > But 18px as 11.0 and 12.0, I had expected 1.5 difference if it were a scale. > > > > > On 26-12-2015 23:24, Herv? Girod wrote: >> In my memory the point size in Unix systems and Windows do not consider the same default screen density. See this for example: http://www.rfwilmut.clara.net/about/fonts.html >> >> Herv? >> >> Sent from my iPhone >> >>> On Dec 26, 2015, at 23:05, Tom Eugelink wrote: >>> >>> Maybe someone can help me get going on this: my 'unit' tests on some of the component in JFXtras fail when run on different operating systems; right now I'm running Debian next to Windows and rending the same Text node has different results: on Windows it is 847 pixels wide, on Linux it is 1083 pixels. >>> >>> So I suspected that a different default font was the cause, so I setup Google Roboto on both systems, but even then I have 1786 vs 2000 pixels (13.64 vs 15.26 for a single "0" with Roboto Medium on font-size 24). What else besides the font can cause this difference? >>> >>> Tom >>> > From charlesl at benetech.org Mon Dec 28 14:14:35 2015 From: charlesl at benetech.org (Charles LaPierre) Date: Mon, 28 Dec 2015 14:14:35 +0000 Subject: Update on FX plans for JDK 9 In-Reply-To: <055701d13e22$c44d3760$4ce7a620$@eu> References: <5672C4F0.20901@oracle.com> <567B49FD.2030206@oracle.com> <055701d13e22$c44d3760$4ce7a620$@eu> Message-ID: <53D3D7A3-D999-4F06-885A-670886D756C5@benetech.org> With the 508 refresh on the horizon has their been any thought to improving the accessibility of JavaFx? Thanks Charles LaPierre Sr. Software Engineer charlesl at benetech.org > On Dec 24, 2015, at 12:12 AM, Markus KARG wrote: > > Kevin, > > I did a quick survey at TeamFX and asked every member to vote. Here is the > official TeamFX opinion. I hope it is of any worth for you. > > Preface: Besides the ticket IDs you asked to prioritise TeamFX thinks that > the top issue for JDK 9 should be performance, most notably of CSS > processing. If there is one thing that holds back people from adopting > JavaFX 8 for professional use cases, then it is the fact that you can > quickly produce UI freezes of several seconds due to bugs and non-optimal > CSS processing within JavaFX. If there would be a free voting upon features, > TeamFX would replace all the below points if instead we could have JDK 9 > running as fast as it could (i. e. for example create and show more than > 1000 TextFields in less than a second; rotate a canvas containing 1000 > complex paths fluently; and so an). > > Having said that, here is the summary of our survey: > > JIRA Ticket Votes Topic > JDK-8092040 34 Implement Image writers for JavaFX > JDK-8091673 30 Runtime should have a published focus traversal API > for use in custom controls > JDK-8090477 26 Customizable visibility timing for Tooltip > JDK-8090763 22 Public API for Glass's robot functionality > JDK-8089311 21 [TableCell] commit on focus lost not possible in > every case > JDK-8092098 21 [TabPane] Support for draggable tabs > JDK-8091107 16 Add java.awt.Desktop support to javafx > JDK-8144556 16 Add support to allow user specified rendering order > JDK-8145443 16 [Mac] Render directly to NSWIndow rather than via > CALayer for non-applet Stage > JDK-8145154 16 Provide public API support for PerformanceTracker > functionality > JDK-8087516 15 Conditional support in JavaFX for GTK 3 on Linux > JDK-8091517 7 Implement com.apple.eawt APIs that make sense in > JavaFX (FX equivalent for JEP 272) > > Merry Christmas > -Markus (TeamFX) > > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of > Kevin Rushforth > Sent: Donnerstag, 24. Dezember 2015 02:27 > To: openjfx-dev at openjdk.java.net > Subject: Re: Update on FX plans for JDK 9 > > Thanks to everyone who has commented on this. With the winter holidays > upon us, we will respond to feedback and pick this up next year. > > -- Kevin > > > Kevin Rushforth wrote: >> Given the recently announced JDK 9 schedule slip [1], we have taken >> the opportunity to explore what RFE's / Features we could possibly now >> work on for inclusion in JDK 9. We wanted to give you a pre-holiday >> season update on what we are currently thinking. >> >> The following RFEs are in progress or planned for JDK 9: >> >> JDK-8144585: Encapsulate JavaFX impl_* implementation methods >> JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs >> JDK-8091308: Define fine-grained permissions for JavaFX >> Expose Hi-DPI properties for render scale and screen scale (FX >> equivalent task for JEP 263 JDK-8055212) >> Multi-resolution image support (FX equivalent task for JEP 251 >> JDK-8046010) >> >> Additionally, we have started to look into making public API for some >> of the impl_* API that will otherwise be hidden by JDK-8144585. See >> Jonathan's earlier e-mail on the subject [2]. Here is what we have so >> far: >> >> JDK-8144628: Provide API to expose list of showing Windows >> JDK-8144625: Expose code and char properties on KeyCode >> JDK-8144962: Promote TableColumn reorderable property to public API >> JDK-8144871: Add default method getStyleableNode to Styleable interface >> JDK-8145143: Promote Image.impl_getUrl() to public API as >> Image.getUrl() >> JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and >> Labeled >> >> If there are any we have missed that your application depends on, >> please send e-mail to Jonathan. >> >> Finally, here is an updated list of other RFEs we might consider for >> JDK 9. We will not be able to do all of these, but hope to be able to >> do many of them. We could use the help of the OpenJFX community in >> prioritizing this list or possibly adding something that we missed, as >> long as the scope is small enough. >> >> JDK-8091107: Add java.awt.Desktop support to javafx >> JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX >> (FX equivalent for JEP 272) >> JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux >> JDK-8092040: Implement Image writers for JavaFX >> JDK-8091673: Runtime should have a published focus traversal API for >> use in custom controls >> JDK-8089311: [TableCell] commit on focus lost not possible in every >> case >> JDK-8090477: Customizable visibility timing for Tooltip >> JDK-8092098: [TabPane] Support for draggable tabs >> JDK-8144556: Add support to allow user specified rendering order >> JDK-8145443: [Mac] Render directly to NSWIndow rather than via >> CALayer for non-applet Stage >> JDK-8145154: Provide public API support for PerformanceTracker >> functionality >> JDK-8090763: Public API for Glass's robot functionality >> >> Let us know what is most important to your application. >> >> We will keep you posted with updates on what exactly is being targeted >> (note that you can track it by looking at the Fix Version in JBS, >> which we strive to keep up-to-date). >> >> Thanks! >> >> -- Kevin >> >> [1] >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html >> [2] >> > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html > >> >> > From danno.ferrin at shemnon.com Mon Dec 28 21:59:31 2015 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Mon, 28 Dec 2015 14:59:31 -0700 Subject: CFV: New OpenJFX Committer: Johan Vos In-Reply-To: <59ECA697-0F35-4E0F-8374-65EFF7D0EAB6@oracle.com> References: <567856E8.5020905@Oracle.com> <5679F2CF.2010907@oracle.com> <25A81133-8721-4AFC-BE78-1EC5A4934476@oracle.com> <59ECA697-0F35-4E0F-8374-65EFF7D0EAB6@oracle.com> Message-ID: Vote: Yes On Wed, Dec 23, 2015 at 5:19 PM, Richard Bair wrote: > Vote: YES > > > On Dec 22, 2015, at 6:10 PM, Jasper Potts > wrote: > > > > Vote: yes > > > > Sent from my iPhone > > > >> On Dec 22, 2015, at 5:03 PM, Alexander Kouznetsov < > alexander.kouznetsov at oracle.com> wrote: > >> > >> Vote: yes > >> > >> Best regards, > >> Alexander Kouznetsov > >> (408) 276-0387 > >> > >>> On 21 ??? 2015 11:45, David Hill wrote: > >>> > >>> I hereby nominate Johan Vos to OpenJFX Committer. > >>> > >>> Johan Vos (jvos) has been active in the OpenJFX community, and > instrumental in the maturity of Monocle, the owner of the Android and IOS > ports and is an OpenJFX Author. > >>> > >>> A list of Johan's commits is also available by the following links > >>> > >>> http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos > >>> http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos > >>> > >>> Votes are due by January 5th, 2016. > >>> > >>> Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > >>> > >>> For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > >>> > >>> [1] http://openjdk.java.net/census#openjfx > >>> > >>> [2] http://openjdk.java.net/bylaws#lazy-consensus > >>> > >>> [3] http://openjdk.java.net/projects#project-committer > >>> > >>> Thanks, > >>> > >>> Dave > >> > > From johan.vos at gluonhq.com Wed Dec 30 12:33:42 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 30 Dec 2015 13:33:42 +0100 Subject: Shader issue: #extension repeated in shader Message-ID: When upgrading a Nexus 6 from Android 5.1.1 to Android 6, the JavaFX 3D stopped working. The relevant error is this: java.lang.RuntimeException: Error creating fragment shader in com.sun.prism.es2.ES2Shader.createFromSource The shader compilation failed with this error: GLSL compile error: Extension directives must occur before any non-preprocessor tokens. which occurs in When debugging this, it seems the fragment shader passed to glCtx.compileShader is created by ES2PhongShader.getShader() which starts from main1Light.frag and which will do a replaceAll for a number of statements which will replace those statements with other shader code that also contains an #extension directive. As a result, the resulting shader source contains a number of identical #extension directives. It seems the latest drivers on Android are much more strict in compiling shaders, and they complain about the position of the extension directives. It seems to me some post-processing needs to be done on the result of the replaceAll() statements when creating the fragment shader in ES2PhongShader.getShader(ES2MeshView meshView, ES2Context context) I did a quick and dirty workaround for this in the 8u-dev-tree on javafxports: https://bitbucket.org/javafxports/8u-dev-rt/commits/a84eb188c73ff60b68c016f14b6ebf85449a6bbe With this patch, JavaFX 3D works again on Android, but it is not the best post-processing solution. Another solution might be to remove the extension directives from the individual files in glsl and add them at the end of the processing chain? - Johan From ozemale at ozemail.com.au Thu Dec 31 08:37:46 2015 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Thu, 31 Dec 2015 19:37:46 +1100 Subject: Android and the OpenJDK Message-ID: I am a tad confused. Google has announced that its next version of Android will be based entirely on the OpenJDK. Could this be a eureka moment for JavaFX? I mean, wouldn't it be the case then that using JavaFX to develop an Android app would actually be a way to create a "native" app, hence significantly increasing the use of JavaFX and ensuring its longevity? -jct From johan at lodgon.com Thu Dec 31 09:21:46 2015 From: johan at lodgon.com (Johan Vos) Date: Thu, 31 Dec 2015 10:21:46 +0100 Subject: Android and the OpenJDK In-Reply-To: References: Message-ID: Hi John, There is a difference between the underlying class libraries and the UI framework on top of it. Currently, Android uses the Harmony class libraries. It appears they will use the OpenJDK class libraries in the future. On top of the class libraries, Android provides its own (specific) UI framework. However, you can already run your JavaFX applications on top of it, using the JavaFX SDK for Android (see http://javafxports.org). The problem with Harmony is that it is somewhere between Java 6 and Java 7. Fortunately, JavaFX 8 runs on top of Java 6/7 (we convert lambda's to inner classes at compile time). So while JavaFX 8 already runs on top of the current Android implementations, it will be possible to use Java 8 API's in your JavaFX application in the future. To make it more complete, there are actually 3 "layers": 1. the VM/runtime 2. the class libraries 3. the ui framework 1.a. Android currently uses its own runtime, called ART. 1.b. A mobile port of the OpenJDK is being developed that will allow to use the OpenJDK VM (hotspot), see http://openjdk.java.net/projects/mobile/ 2.a. Android currently uses Harmony 2.b. The mobile port of the OpenJDK can be used to build class libraries based on the OpenJDK sources. I don't know if those classes will be used by Android, or if they will build the class libraries themselves. If the latter happens, this is option 2.c. 3.a. Android comes with its own UI API (i.e. android.widget.Button), running on {1.a/2.a} 3.b. JavaFX runs on top of any combination {[1.a,1.b],[2.a,2.b]} and uses the standard JavaFX API that also works on Desktop, iOS and embedded. I'm biased of course, but 3.b. seems the long-term solution to me. It is already available and being used. We need to work more on performance and fix issues, but in general, I am very positive about it. - Johan 2015-12-31 9:37 GMT+01:00 John C. Turnbull : > I am a tad confused. > > Google has announced that its next version of Android will be based > entirely on the OpenJDK. > > Could this be a eureka moment for JavaFX? I mean, wouldn't it be the case > then that using JavaFX to develop an Android app would actually be a way to > create a "native" app, hence significantly increasing the use of JavaFX and > ensuring its longevity? > > -jct