From augustnagro at gmail.com Thu Feb 1 01:49:02 2018 From: augustnagro at gmail.com (August Nagro) Date: Thu, 01 Feb 2018 01:49:02 +0000 Subject: Public API for Robot Class Message-ID: Since Java 9 makes com.sun.glass.ui.Robot unavailable, is there any interest in making it public? There seems to be a bug for it here: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8090763# The TestFX developers also made a proposal (not sure if they shared on this list): https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 https://github.com/TestFX/Robot In addition to their notes, I'd also suggest that keyPress and keyRelease be handled globally like in AWT Robot. Developers could then press Ctrl + Tab to change applications, for example. Regards, August From nlisker at gmail.com Thu Feb 1 18:41:45 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 1 Feb 2018 20:41:45 +0200 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: <5A71D0FF.1040004@oracle.com> References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> <5A70C18E.30805@oracle.com> <5A71D0FF.1040004@oracle.com> Message-ID: Looks like I understood the problem. Eclipse does not support (yet) multiple modules per project. Do you know any specifications I can point them to to fix this properly? The current workaround would be to add 'requires' for all the modules which are used in tests as well. This change is local and would be excluded from webrevs. At this point I can either submit the partially fixed Eclipse files, which work with main code fully and with test code only if the above fix is used; or wait until Eclipse sorts it out. On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth wrote: > > > Nir Lisker wrote: > > rt/modules/javafx.base/build/classes/main/javafx.base/ >> rt/modules/javafx.base/src/main/java/ > > > Why not rely on source first? > > > Yes, that might work...you could try switching the order. > > > > Another question as I move along: there are imports from java.util.logging > in base module, but the module-info doesn't require java.logging. How do I > give access to these imports? > > > The only references to java.util.logging are in the javafx.base unit > tests, which are compiled and run in the unnamed modules (no > module-info.java for the unit tests). > > -- Kevin > > > > On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Oh, I see. You are pointing to the exploded modules for the JDK in >> build/XXXXX/jdk rather than the JDK image in build/XXXXX/images/jdk. >> >> Yes, I think it would be preferable to both reverse the order and also >> add in the location of the built class files. So the following order seems >> best: >> >> rt/modules/javafx.base/build/classes/main/javafx.base/ >> rt/modules/javafx.base/src/main/java/ >> jdk/modules/javafx.base >> >> >> -- Kevin >> >> >> Nir Lisker wrote: >> >> This is what I mean: In the type /base/src/test/java/test/ >> com/sun/javafx/collections/ListListenerHelperTest.java there are these >> imports: >> >> import test.javafx.collections.MockListObserver; >> import java.util.BitSet; >> import javafx.beans.Observable; >> >> The first one is the one in FX: rt\modules\javafx.base\src >> \test\java\test\javafx\collections\MockListObserver.java >> The second one is in the referenced JDK which was built with >> FX: jdk\modules\java.base\java\util\BitSet.class >> The third one exists in both: >> - in JFX it's in: rt\modules\javafx.base\src\mai >> n\java\javafx\beans\Observable.java >> - in the JDK it's in: jdk\modules\javafx.base\ja >> vafx\beans\Observable.class >> >> Does the question make sense now? >> >> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> >>> one in "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>> or the one in "jdk\modules\javafx.base\javaf >>> x\beans\InvalidationListener.class"? >>> >>> >>> Not sure I get what you mean. There isn't a jdk/modules/ directory >>> created by the build. Perhaps this is an Eclipse construct that it uses to >>> indicate the modules that are in the JDK that you are using? The FX build >>> puts the class files in: >>> >>> rt/build/modular_sdk/modules/javafx.base/... >>> >>> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>> >>> Another question: do imports of javafx.* packages point to the javafx >>> source or to the jdk compilation? >>> >>> For example, in the base module, the type test.javafx.beans.InvalidationListenerMock >>> imports javafx.beans.InvalidationListener (twice, by the way, along >>> with Observable). Should the imported class be the one in >>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>> or the one in "jdk\modules\javafx.base\javaf >>> x\beans\InvalidationListener.class"? >>> >>> Currently, the way it is in the Eclipse files is that the jdk .class >>> files are imported first[1], but it seemed odd to me - if I work on 2 files >>> which depend on each other they should see the changes in each other at >>> once. >>> >>> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d12 >>> 7c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before >>> "src/main/java"), >>> >>> - Nir >>> >>> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> inline >>>> >>>> Nir Lisker wrote: >>>> >>>> Alright, cleaned that part. fxpackager build fails with an internal NPE >>>> in Eclipse, so I'm going to leave that alone and all of the projects that >>>> depends on it. >>>> >>>> Now that projects can be built there are errors in deeper levels: >>>> >>>> 1. All org.junit imports cannot be resolved. This causes tons of errors >>>> in various test folders obviously. All the .classpath files use >>>> >>>> >>>> >>>> which is a jar distributed with Eclipse (in the plugins folder) with >>>> version 4.12.0. Is this really where the imports are supposed to come from? >>>> How does it work in Netbeans or IntelliJ? >>>> >>>> >>>> For NetBeans we use their internal version of JUnit. I don't know about >>>> IntelliJ (maybe someone else on the list can answer that). >>>> >>>> 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging" >>>> there are imports of com.oracle.jrockit.jfr that can't be resolved. Where >>>> are these located? >>>> >>>> >>>> These classes used to be part of the JFR commercial feature in the >>>> Oracle JDK. The java-jfr sources are obsolete and no longer built (and no >>>> longer buildable), so you can safely remove it from your IDE files. I also >>>> still see references to it in the netbeans/base project. I will file a bug >>>> to remove this obsolete code and fix the NetBeans references at the same >>>> time. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> Ah, I see. Then yes, just removing the old ones is fine. >>>>> >>>>> As for the larger question, unless there are dependencies on apps, you >>>>> can assume that the only ones you care about are the ones created by >>>>> "gradle sdk". >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Nir Lisker wrote: >>>>> >>>>> So this is why I was asking about the optional stuff: 'graphics' >>>>> module has BOTH >>>>> >>>>> build/resources/jsl-decora >>>>> build/resources/jsl-prism >>>>> >>>>> and >>>>> >>>>> build/gensrc/jsl-decora >>>>> build/gensrc/jsl-prism >>>>> >>>>> That led me to think that when the new dependencies were added the old >>>>> ones weren't removed. Those that weren't optional (like the /resources >>>>> ones, which I removed) were easy to catch and we could have finished here. >>>>> Those that are optional are not causing trouble even when missing because >>>>> they are optional. >>>>> >>>>> gradle sdk does not create the ones which are marked optional that >>>>> Iv'e surveyed, but I don't know if that's the only way they can be created. >>>>> If I compare solely with gradle sdk then I can just remove whatever is >>>>> missing on grounds that it's left over. >>>>> >>>>> - Nir >>>>> >>>>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> One more thing about the specific path you mentioned as not being >>>>>> there. >>>>>> >>>>>> >>>>> path="build/resources/jsl-decora"/> >>>>>> >>>>> path="build/resources/jsl-prism"/> >>>>>> >>>>>> These are still being created by 'gradle sdk', but the path is wrong >>>>>> (the files moved in JDK 9) and should be: >>>>>> >>>>>> build/gensrc/jsl-decora >>>>>> build/gensrc/jsl-prism >>>>>> >>>>>> You might want to take that into account. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Kevin Rushforth wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> Nir Lisker wrote: >>>>>>> >>>>>>>> Iv'e removed all the classpath dependencies that were causing >>>>>>>> errors. I don't mind sorting out the rest of the files while at it, though >>>>>>>> for that there are a few things I'm not sure about: >>>>>>>> >>>>>>>> 1. Some dependencies are marked as optional and as such they don't >>>>>>>> cause errors, but they are still missing. Is it safe to remove them or is >>>>>>>> it possible that they will be created as some point? >>>>>>>> >>>>>>> >>>>>>> Some of them might be created...not sure without checking. I >>>>>>> recommend running "gradle sdk" and then seeing if the dependencies are >>>>>>> there. >>>>>>> >>>>>>> Examples are the 'base' module with "src/test/resources" and >>>>>>>> "src/main/resources" optional dependencies, and 'controls' module has the >>>>>>>> optional dependency "src/main/resources" commented out. >>>>>>>> >>>>>>> >>>>>>> I see. You might as well leave them, but it probably doesn't matter. >>>>>>> >>>>>>> 2. Can I assume that all other dependencies are really needed? >>>>>>>> (Eclipse won't complain about unused ones as far as I know.) >>>>>>>> >>>>>>> >>>>>>> That seems best. >>>>>>> >>>>>>> 3. What are the formatting standards for XML (indentation, line >>>>>>>> length...)? From a quick look I see different styles in different files. >>>>>>>> >>>>>>> >>>>>>> For IDE files, we don't worry about formatting. In many cases they >>>>>>> are auto-generated anyway. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>>> - Nir >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From mp at jugs.org Thu Feb 1 19:27:07 2018 From: mp at jugs.org (Michael Paus) Date: Thu, 1 Feb 2018 20:27:07 +0100 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> <5A70C18E.30805@oracle.com> <5A71D0FF.1040004@oracle.com> Message-ID: Am 01.02.18 um 19:41 schrieb Nir Lisker: > Looks like I understood the problem. Eclipse does not support (yet) > multiple modules per project. Do you know any specifications I can point > them to to fix this properly? I would not expect a change of this any time soon. There was a lengthy discussion of this topic and they decided to do it the way they have always done it. One project = one module. > > The current workaround would be to add 'requires' for all the modules which > are used in tests as well. This change is local and would be excluded from > webrevs. > > At this point I can either submit the partially fixed Eclipse files, which > work with main code fully and with test code only if the above fix is used; > or wait until Eclipse sorts it out. > > On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth > wrote: >> >> Nir Lisker wrote: >> >> rt/modules/javafx.base/build/classes/main/javafx.base/ >>> rt/modules/javafx.base/src/main/java/ >> >> Why not rely on source first? >> >> >> Yes, that might work...you could try switching the order. >> >> >> >> Another question as I move along: there are imports from java.util.logging >> in base module, but the module-info doesn't require java.logging. How do I >> give access to these imports? >> >> >> The only references to java.util.logging are in the javafx.base unit >> tests, which are compiled and run in the unnamed modules (no >> module-info.java for the unit tests). >> >> -- Kevin >> >> >> >> On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> Oh, I see. You are pointing to the exploded modules for the JDK in >>> build/XXXXX/jdk rather than the JDK image in build/XXXXX/images/jdk. >>> >>> Yes, I think it would be preferable to both reverse the order and also >>> add in the location of the built class files. So the following order seems >>> best: >>> >>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>> rt/modules/javafx.base/src/main/java/ >>> jdk/modules/javafx.base >>> >>> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>> >>> This is what I mean: In the type /base/src/test/java/test/ >>> com/sun/javafx/collections/ListListenerHelperTest.java there are these >>> imports: >>> >>> import test.javafx.collections.MockListObserver; >>> import java.util.BitSet; >>> import javafx.beans.Observable; >>> >>> The first one is the one in FX: rt\modules\javafx.base\src >>> \test\java\test\javafx\collections\MockListObserver.java >>> The second one is in the referenced JDK which was built with >>> FX: jdk\modules\java.base\java\util\BitSet.class >>> The third one exists in both: >>> - in JFX it's in: rt\modules\javafx.base\src\mai >>> n\java\javafx\beans\Observable.java >>> - in the JDK it's in: jdk\modules\javafx.base\ja >>> vafx\beans\Observable.class >>> >>> Does the question make sense now? >>> >>> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> one in "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>> or the one in "jdk\modules\javafx.base\javaf >>>> x\beans\InvalidationListener.class"? >>>> >>>> >>>> Not sure I get what you mean. There isn't a jdk/modules/ directory >>>> created by the build. Perhaps this is an Eclipse construct that it uses to >>>> indicate the modules that are in the JDK that you are using? The FX build >>>> puts the class files in: >>>> >>>> rt/build/modular_sdk/modules/javafx.base/... >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Nir Lisker wrote: >>>> >>>> Another question: do imports of javafx.* packages point to the javafx >>>> source or to the jdk compilation? >>>> >>>> For example, in the base module, the type test.javafx.beans.InvalidationListenerMock >>>> imports javafx.beans.InvalidationListener (twice, by the way, along >>>> with Observable). Should the imported class be the one in >>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>> or the one in "jdk\modules\javafx.base\javaf >>>> x\beans\InvalidationListener.class"? >>>> >>>> Currently, the way it is in the Eclipse files is that the jdk .class >>>> files are imported first[1], but it seemed odd to me - if I work on 2 files >>>> which depend on each other they should see the changes in each other at >>>> once. >>>> >>>> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d12 >>>> 7c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before >>>> "src/main/java"), >>>> >>>> - Nir >>>> >>>> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> inline >>>>> >>>>> Nir Lisker wrote: >>>>> >>>>> Alright, cleaned that part. fxpackager build fails with an internal NPE >>>>> in Eclipse, so I'm going to leave that alone and all of the projects that >>>>> depends on it. >>>>> >>>>> Now that projects can be built there are errors in deeper levels: >>>>> >>>>> 1. All org.junit imports cannot be resolved. This causes tons of errors >>>>> in various test folders obviously. All the .classpath files use >>>>> >>>>> >>>>> >>>>> which is a jar distributed with Eclipse (in the plugins folder) with >>>>> version 4.12.0. Is this really where the imports are supposed to come from? >>>>> How does it work in Netbeans or IntelliJ? >>>>> >>>>> >>>>> For NetBeans we use their internal version of JUnit. I don't know about >>>>> IntelliJ (maybe someone else on the list can answer that). >>>>> >>>>> 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging" >>>>> there are imports of com.oracle.jrockit.jfr that can't be resolved. Where >>>>> are these located? >>>>> >>>>> >>>>> These classes used to be part of the JFR commercial feature in the >>>>> Oracle JDK. The java-jfr sources are obsolete and no longer built (and no >>>>> longer buildable), so you can safely remove it from your IDE files. I also >>>>> still see references to it in the netbeans/base project. I will file a bug >>>>> to remove this obsolete code and fix the NetBeans references at the same >>>>> time. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> Ah, I see. Then yes, just removing the old ones is fine. >>>>>> >>>>>> As for the larger question, unless there are dependencies on apps, you >>>>>> can assume that the only ones you care about are the ones created by >>>>>> "gradle sdk". >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Nir Lisker wrote: >>>>>> >>>>>> So this is why I was asking about the optional stuff: 'graphics' >>>>>> module has BOTH >>>>>> >>>>>> build/resources/jsl-decora >>>>>> build/resources/jsl-prism >>>>>> >>>>>> and >>>>>> >>>>>> build/gensrc/jsl-decora >>>>>> build/gensrc/jsl-prism >>>>>> >>>>>> That led me to think that when the new dependencies were added the old >>>>>> ones weren't removed. Those that weren't optional (like the /resources >>>>>> ones, which I removed) were easy to catch and we could have finished here. >>>>>> Those that are optional are not causing trouble even when missing because >>>>>> they are optional. >>>>>> >>>>>> gradle sdk does not create the ones which are marked optional that >>>>>> Iv'e surveyed, but I don't know if that's the only way they can be created. >>>>>> If I compare solely with gradle sdk then I can just remove whatever is >>>>>> missing on grounds that it's left over. >>>>>> >>>>>> - Nir >>>>>> >>>>>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth < >>>>>> kevin.rushforth at oracle.com> wrote: >>>>>> >>>>>>> One more thing about the specific path you mentioned as not being >>>>>>> there. >>>>>>> >>>>>>> >>>>>> path="build/resources/jsl-decora"/> >>>>>>> >>>>>> path="build/resources/jsl-prism"/> >>>>>>> >>>>>>> These are still being created by 'gradle sdk', but the path is wrong >>>>>>> (the files moved in JDK 9) and should be: >>>>>>> >>>>>>> build/gensrc/jsl-decora >>>>>>> build/gensrc/jsl-prism >>>>>>> >>>>>>> You might want to take that into account. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Kevin Rushforth wrote: >>>>>>> >>>>>>>> >>>>>>>> Nir Lisker wrote: >>>>>>>> >>>>>>>>> Iv'e removed all the classpath dependencies that were causing >>>>>>>>> errors. I don't mind sorting out the rest of the files while at it, though >>>>>>>>> for that there are a few things I'm not sure about: >>>>>>>>> >>>>>>>>> 1. Some dependencies are marked as optional and as such they don't >>>>>>>>> cause errors, but they are still missing. Is it safe to remove them or is >>>>>>>>> it possible that they will be created as some point? >>>>>>>>> >>>>>>>> Some of them might be created...not sure without checking. I >>>>>>>> recommend running "gradle sdk" and then seeing if the dependencies are >>>>>>>> there. >>>>>>>> >>>>>>>> Examples are the 'base' module with "src/test/resources" and >>>>>>>>> "src/main/resources" optional dependencies, and 'controls' module has the >>>>>>>>> optional dependency "src/main/resources" commented out. >>>>>>>>> >>>>>>>> I see. You might as well leave them, but it probably doesn't matter. >>>>>>>> >>>>>>>> 2. Can I assume that all other dependencies are really needed? >>>>>>>>> (Eclipse won't complain about unused ones as far as I know.) >>>>>>>>> >>>>>>>> That seems best. >>>>>>>> >>>>>>>> 3. What are the formatting standards for XML (indentation, line >>>>>>>>> length...)? From a quick look I see different styles in different files. >>>>>>>>> >>>>>>>> For IDE files, we don't worry about formatting. In many cases they >>>>>>>> are auto-generated anyway. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>>> - Nir >>>>>>>>> From kevin.rushforth at oracle.com Thu Feb 1 19:48:41 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 01 Feb 2018 11:48:41 -0800 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> <5A70C18E.30805@oracle.com> <5A71D0FF.1040004@oracle.com> Message-ID: <5A736F19.30503@oracle.com> It probably makes sense to submit what you have now as a partially working solution. As for Eclipse making any changes, I'm not sure there is a spec you could point to ... we do some of the same magic that I'm sure other projects have had to do w.r.t running tests: * We have test "shims" for white-box testing that we add into our modules when running tests (this requires copying all of the class files for our modules and adding the shim classes on top of that) * We build the tests separately (the tests are in a separate source set in gradle) without a module-info so that they run in the unnamed module. This allows them to access JUnit, etc., as well as any public package of any module in the system. As such we need to explicitly list any internal packages that they use from the module they are testing. These are listed in src/test/addExports -- Kevin Nir Lisker wrote: > Looks like I understood the problem. Eclipse does not support (yet) > multiple modules per project. Do you know any specifications I can > point them to to fix this properly? > > The current workaround would be to add 'requires' for all the modules > which are used in tests as well. This change is local and would be > excluded from webrevs. > > At this point I can either submit the partially fixed Eclipse files, > which work with main code fully and with test code only if the above > fix is used; or wait until Eclipse sorts it out. > > On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth > > wrote: > > > > Nir Lisker wrote: >> >> rt/modules/javafx.base/build/classes/main/javafx.base/ >> rt/modules/javafx.base/src/main/java/ >> >> >> Why not rely on source first? > > Yes, that might work...you could try switching the order. > > >> >> Another question as I move along: there are imports >> from java.util.logging in base module, but the module-info >> doesn't require java.logging. How do I give access to these imports? > > The only references to java.util.logging are in the javafx.base > unit tests, which are compiled and run in the unnamed modules (no > module-info.java for the unit tests). > > -- Kevin > > > >> On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth >> > >> wrote: >> >> Oh, I see. You are pointing to the exploded modules for the >> JDK in build/XXXXX/jdk rather than the JDK image in >> build/XXXXX/images/jdk. >> >> Yes, I think it would be preferable to both reverse the order >> and also add in the location of the built class files. So the >> following order seems best: >> >> rt/modules/javafx.base/build/classes/main/javafx.base/ >> rt/modules/javafx.base/src/main/java/ >> jdk/modules/javafx.base >> >> >> -- Kevin >> >> >> Nir Lisker wrote: >>> This is what I mean: In the >>> type /base/src/test/java/test/com/sun/javafx/collections/ListListenerHelperTest.java >>> there are these imports: >>> >>> import test.javafx.collections.MockListObserver; >>> import java.util.BitSet; >>> import javafx.beans.Observable; >>> >>> The first one is the one in >>> FX: rt\modules\javafx.base\src\test\java\test\javafx\collections\MockListObserver.java >>> The second one is in the referenced JDK which was built with >>> FX: jdk\modules\java.base\java\util\BitSet.class >>> The third one exists in both: >>> - in JFX it's in: >>> rt\modules\javafx.base\src\main\java\javafx\beans\Observable.java >>> - in the JDK it's >>> in: jdk\modules\javafx.base\javafx\beans\Observable.class >>> >>> Does the question make sense now? >>> >>> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth >>> >> > wrote: >>> >>> >>>> one in >>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>> or the one in >>>> "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? >>> >>> Not sure I get what you mean. There isn't a jdk/modules/ >>> directory created by the build. Perhaps this is an >>> Eclipse construct that it uses to indicate the modules >>> that are in the JDK that you are using? The FX build >>> puts the class files in: >>> >>> rt/build/modular_sdk/modules/javafx.base/... >>> >>> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>>> Another question: do imports of javafx.* packages point >>>> to the javafx source or to the jdk compilation? >>>> >>>> For example, in the base module, the type >>>> test.javafx.beans.InvalidationListenerMock >>>> imports javafx.beans.InvalidationListener (twice, by >>>> the way, along with Observable). Should the imported >>>> class be the one in >>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>> or the one in >>>> "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? >>>> >>>> Currently, the way it is in the Eclipse files is that >>>> the jdk .class files are imported first[1], but it >>>> seemed odd to me - if I work on 2 files which depend on >>>> each other they should see the changes in each other at >>>> once. >>>> >>>> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d127c6ed5/modules/javafx.base/.classpath >>>> >>>> ("JRE_CONTAINER" is before "src/main/java"), >>>> >>>> - Nir >>>> >>>> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth >>>> >>> > wrote: >>>> >>>> inline >>>> >>>> Nir Lisker wrote: >>>>> Alright, cleaned that part. fxpackager build fails >>>>> with an internal NPE in Eclipse, so I'm going to >>>>> leave that alone and all of the projects that >>>>> depends on it. >>>>> >>>>> Now that projects can be built there are errors in >>>>> deeper levels: >>>>> >>>>> 1. All org.junit imports cannot be resolved. This >>>>> causes tons of errors in various test folders >>>>> obviously. All the .classpath files use >>>>> >>>>> >>>> path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/> >>>>> >>>>> which is a jar distributed with Eclipse (in the >>>>> plugins folder) with version 4.12.0. Is this >>>>> really where the imports are supposed to come >>>>> from? How does it work in Netbeans or IntelliJ? >>>> >>>> For NetBeans we use their internal version of >>>> JUnit. I don't know about IntelliJ (maybe someone >>>> else on the list can answer that). >>>> >>>>> 2. In the 'base' module, in >>>>> "/src/main/java-jfr/com/sun/javafx/logging" there >>>>> are imports of com.oracle.jrockit.jfr that can't >>>>> be resolved. Where are these located? >>>> >>>> These classes used to be part of the JFR commercial >>>> feature in the Oracle JDK. The java-jfr sources are >>>> obsolete and no longer built (and no longer >>>> buildable), so you can safely remove it from your >>>> IDE files. I also still see references to it in the >>>> netbeans/base project. I will file a bug to remove >>>> this obsolete code and fix the NetBeans references >>>> at the same time. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth >>>>> >>>> > wrote: >>>>> >>>>> Ah, I see. Then yes, just removing the old >>>>> ones is fine. >>>>> >>>>> As for the larger question, unless there are >>>>> dependencies on apps, you can assume that the >>>>> only ones you care about are the ones created >>>>> by "gradle sdk". >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Nir Lisker wrote: >>>>>> So this is why I was asking about the >>>>>> optional stuff: 'graphics' module has BOTH >>>>>> >>>>>> build/resources/jsl-decora >>>>>> build/resources/jsl-prism >>>>>> >>>>>> and >>>>>> >>>>>> build/gensrc/jsl-decora >>>>>> build/gensrc/jsl-prism >>>>>> >>>>>> That led me to think that when the new >>>>>> dependencies were added the old ones weren't >>>>>> removed. Those that weren't optional >>>>>> (like the /resources ones, which I removed) >>>>>> were easy to catch and we could have finished >>>>>> here. Those that are optional are not causing >>>>>> trouble even when missing because they are >>>>>> optional. >>>>>> >>>>>> gradle sdk does not create the ones which are >>>>>> marked optional that Iv'e surveyed, but I >>>>>> don't know if that's the only way they can be >>>>>> created. If I compare solely with gradle sdk >>>>>> then I can just remove whatever is missing on >>>>>> grounds that it's left over. >>>>>> >>>>>> - Nir >>>>>> >>>>>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin >>>>>> Rushforth >>>>> > wrote: >>>>>> >>>>>> One more thing about the specific path >>>>>> you mentioned as not being there. >>>>>> >>>>>> >>>>> exported="true" >>>>>> path="build/resources/jsl-decora"/> >>>>>> >>>>> exported="true" >>>>>> path="build/resources/jsl-prism"/> >>>>>> >>>>>> These are still being created by 'gradle >>>>>> sdk', but the path is wrong (the files >>>>>> moved in JDK 9) and should be: >>>>>> >>>>>> build/gensrc/jsl-decora >>>>>> build/gensrc/jsl-prism >>>>>> >>>>>> You might want to take that into account. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Kevin Rushforth wrote: >>>>>> >>>>>> >>>>>> >>>>>> Nir Lisker wrote: >>>>>> >>>>>> Iv'e removed all the classpath >>>>>> dependencies that were causing >>>>>> errors. I don't mind sorting out >>>>>> the rest of the files while at >>>>>> it, though for that there are a >>>>>> few things I'm not sure about: >>>>>> >>>>>> 1. Some dependencies are marked >>>>>> as optional and as such they >>>>>> don't cause errors, but they are >>>>>> still missing. Is it safe to >>>>>> remove them or is it possible >>>>>> that they will be created as some >>>>>> point? >>>>>> >>>>>> >>>>>> Some of them might be created...not >>>>>> sure without checking. I recommend >>>>>> running "gradle sdk" and then seeing >>>>>> if the dependencies are there. >>>>>> >>>>>> Examples are the 'base' module >>>>>> with "src/test/resources" and >>>>>> "src/main/resources" optional >>>>>> dependencies, and 'controls' >>>>>> module has the optional >>>>>> dependency "src/main/resources" >>>>>> commented out. >>>>>> >>>>>> >>>>>> I see. You might as well leave them, >>>>>> but it probably doesn't matter. >>>>>> >>>>>> 2. Can I assume that all other >>>>>> dependencies are really needed? >>>>>> (Eclipse won't complain about >>>>>> unused ones as far as I know.) >>>>>> >>>>>> >>>>>> That seems best. >>>>>> >>>>>> 3. What are the formatting >>>>>> standards for XML (indentation, >>>>>> line length...)? From a quick >>>>>> look I see different styles in >>>>>> different files. >>>>>> >>>>>> >>>>>> For IDE files, we don't worry about >>>>>> formatting. In many cases they are >>>>>> auto-generated anyway. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> - Nir >>>>>> >>>>>> >>>>> >>>> >>> >> > From mike.ennen at gmail.com Thu Feb 1 20:03:54 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Thu, 1 Feb 2018 13:03:54 -0700 Subject: Public API for Robot Class In-Reply-To: References: Message-ID: I have a thread on this list entitled "Proposal For Inclusion of Robot and ParametersImpl in the Public API". I have made a webrev of the suggested changes. Kevin is going to look at the changes sometime after RDP 2. On Wed, Jan 31, 2018 at 6:49 PM, August Nagro wrote: > Since Java 9 makes com.sun.glass.ui.Robot unavailable, is there any > interest in making it public? There seems to be a bug for it here: > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8090763# > > The TestFX developers also made a proposal (not sure if they shared on this > list): > https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 > https://github.com/TestFX/Robot > > In addition to their notes, I'd also suggest that keyPress and keyRelease > be handled globally like in AWT Robot. Developers could then press Ctrl + > Tab to change applications, for example. > > Regards, > > August > -- Michael Ennen From augustnagro at gmail.com Thu Feb 1 20:40:40 2018 From: augustnagro at gmail.com (August Nagro) Date: Thu, 01 Feb 2018 20:40:40 +0000 Subject: Public API for Robot Class In-Reply-To: References: Message-ID: Great news; thanks! On Thu, Feb 1, 2018 at 2:03 PM Michael Ennen wrote: > I have a thread on this list entitled "Proposal For Inclusion of Robot and > ParametersImpl in the Public API". > > I have made a webrev of the suggested changes. > > Kevin is going to look at the changes sometime after RDP 2. > > On Wed, Jan 31, 2018 at 6:49 PM, August Nagro > wrote: > >> Since Java 9 makes com.sun.glass.ui.Robot unavailable, is there any >> interest in making it public? There seems to be a bug for it here: >> >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8090763# >> >> The TestFX developers also made a proposal (not sure if they shared on >> this >> list): >> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >> https://github.com/TestFX/Robot >> >> In addition to their notes, I'd also suggest that keyPress and keyRelease >> be handled globally like in AWT Robot. Developers could then press Ctrl + >> Tab to change applications, for example. >> >> Regards, >> >> August >> > > > > -- > Michael Ennen > From kevin.rushforth at oracle.com Thu Feb 1 21:09:31 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 01 Feb 2018 13:09:31 -0800 Subject: Public API for Robot Class In-Reply-To: References: Message-ID: <5A73820B.6000807@oracle.com> Yes, there is interest in creating a public JavaFX API for Robot. See the following: http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-January/021212.html This is a good reminder, mostly to myself, that I need to do a review of the proof-of-concept. -- Kevin August Nagro wrote: > Since Java 9 makes com.sun.glass.ui.Robot unavailable, is there any > interest in making it public? There seems to be a bug for it here: > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8090763# > > The TestFX developers also made a proposal (not sure if they shared on this > list): > https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 > https://github.com/TestFX/Robot > > In addition to their notes, I'd also suggest that keyPress and keyRelease > be handled globally like in AWT Robot. Developers could then press Ctrl + > Tab to change applications, for example. > > Regards, > > August > From kevin.rushforth at oracle.com Thu Feb 1 21:11:27 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 01 Feb 2018 13:11:27 -0800 Subject: Public API for Robot Class In-Reply-To: References: Message-ID: <5A73827F.1040604@oracle.com> I didn't see this before I replied with basically the same answer. -- Kevin Michael Ennen wrote: > I have a thread on this list entitled "Proposal For Inclusion of Robot and > ParametersImpl in the Public API". > > I have made a webrev of the suggested changes. > > Kevin is going to look at the changes sometime after RDP 2. > > On Wed, Jan 31, 2018 at 6:49 PM, August Nagro wrote: > > >> Since Java 9 makes com.sun.glass.ui.Robot unavailable, is there any >> interest in making it public? There seems to be a bug for it here: >> >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8090763# >> >> The TestFX developers also made a proposal (not sure if they shared on this >> list): >> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >> https://github.com/TestFX/Robot >> >> In addition to their notes, I'd also suggest that keyPress and keyRelease >> be handled globally like in AWT Robot. Developers could then press Ctrl + >> Tab to change applications, for example. >> >> Regards, >> >> August >> >> > > > > From kevin.rushforth at oracle.com Thu Feb 1 21:13:50 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 01 Feb 2018 13:13:50 -0800 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> <5A70C18E.30805@oracle.com> <5A71D0FF.1040004@oracle.com> Message-ID: <5A73830E.5050108@oracle.com> So it seems either a workaround is needed, or else maybe create two Eclipse projects: one for the sources and one for the tests. -- Kevin Michael Paus wrote: > Am 01.02.18 um 19:41 schrieb Nir Lisker: >> Looks like I understood the problem. Eclipse does not support (yet) >> multiple modules per project. Do you know any specifications I can point >> them to to fix this properly? > I would not expect a change of this any time soon. There was a lengthy > discussion of this topic and they decided to do it the way they have > always > done it. One project = one module. >> >> The current workaround would be to add 'requires' for all the modules >> which >> are used in tests as well. This change is local and would be excluded >> from >> webrevs. >> >> At this point I can either submit the partially fixed Eclipse files, >> which >> work with main code fully and with test code only if the above fix is >> used; >> or wait until Eclipse sorts it out. >> >> On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth >> >> wrote: >>> >>> Nir Lisker wrote: >>> >>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>>> rt/modules/javafx.base/src/main/java/ >>> >>> Why not rely on source first? >>> >>> >>> Yes, that might work...you could try switching the order. >>> >>> >>> >>> Another question as I move along: there are imports from >>> java.util.logging >>> in base module, but the module-info doesn't require java.logging. >>> How do I >>> give access to these imports? >>> >>> >>> The only references to java.util.logging are in the javafx.base unit >>> tests, which are compiled and run in the unnamed modules (no >>> module-info.java for the unit tests). >>> >>> -- Kevin >>> >>> >>> >>> On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> Oh, I see. You are pointing to the exploded modules for the JDK in >>>> build/XXXXX/jdk rather than the JDK image in build/XXXXX/images/jdk. >>>> >>>> Yes, I think it would be preferable to both reverse the order and also >>>> add in the location of the built class files. So the following >>>> order seems >>>> best: >>>> >>>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>>> rt/modules/javafx.base/src/main/java/ >>>> jdk/modules/javafx.base >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Nir Lisker wrote: >>>> >>>> This is what I mean: In the type /base/src/test/java/test/ >>>> com/sun/javafx/collections/ListListenerHelperTest.java there are these >>>> imports: >>>> >>>> import test.javafx.collections.MockListObserver; >>>> import java.util.BitSet; >>>> import javafx.beans.Observable; >>>> >>>> The first one is the one in FX: rt\modules\javafx.base\src >>>> \test\java\test\javafx\collections\MockListObserver.java >>>> The second one is in the referenced JDK which was built with >>>> FX: jdk\modules\java.base\java\util\BitSet.class >>>> The third one exists in both: >>>> - in JFX it's in: rt\modules\javafx.base\src\mai >>>> n\java\javafx\beans\Observable.java >>>> - in the JDK it's in: jdk\modules\javafx.base\ja >>>> vafx\beans\Observable.class >>>> >>>> Does the question make sense now? >>>> >>>> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> one in >>>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>>> >>>>> or the one in "jdk\modules\javafx.base\javaf >>>>> x\beans\InvalidationListener.class"? >>>>> >>>>> >>>>> Not sure I get what you mean. There isn't a jdk/modules/ directory >>>>> created by the build. Perhaps this is an Eclipse construct that it >>>>> uses to >>>>> indicate the modules that are in the JDK that you are using? The >>>>> FX build >>>>> puts the class files in: >>>>> >>>>> rt/build/modular_sdk/modules/javafx.base/... >>>>> >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Nir Lisker wrote: >>>>> >>>>> Another question: do imports of javafx.* packages point to the javafx >>>>> source or to the jdk compilation? >>>>> >>>>> For example, in the base module, the type >>>>> test.javafx.beans.InvalidationListenerMock >>>>> imports javafx.beans.InvalidationListener (twice, by the way, along >>>>> with Observable). Should the imported class be the one in >>>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>>> >>>>> or the one in "jdk\modules\javafx.base\javaf >>>>> x\beans\InvalidationListener.class"? >>>>> >>>>> Currently, the way it is in the Eclipse files is that the jdk .class >>>>> files are imported first[1], but it seemed odd to me - if I work >>>>> on 2 files >>>>> which depend on each other they should see the changes in each >>>>> other at >>>>> once. >>>>> >>>>> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d12 >>>>> 7c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before >>>>> "src/main/java"), >>>>> >>>>> - Nir >>>>> >>>>> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> inline >>>>>> >>>>>> Nir Lisker wrote: >>>>>> >>>>>> Alright, cleaned that part. fxpackager build fails with an >>>>>> internal NPE >>>>>> in Eclipse, so I'm going to leave that alone and all of the >>>>>> projects that >>>>>> depends on it. >>>>>> >>>>>> Now that projects can be built there are errors in deeper levels: >>>>>> >>>>>> 1. All org.junit imports cannot be resolved. This causes tons of >>>>>> errors >>>>>> in various test folders obviously. All the .classpath files use >>>>>> >>>>>> >>>>>> >>>>>> which is a jar distributed with Eclipse (in the plugins folder) with >>>>>> version 4.12.0. Is this really where the imports are supposed to >>>>>> come from? >>>>>> How does it work in Netbeans or IntelliJ? >>>>>> >>>>>> >>>>>> For NetBeans we use their internal version of JUnit. I don't know >>>>>> about >>>>>> IntelliJ (maybe someone else on the list can answer that). >>>>>> >>>>>> 2. In the 'base' module, in >>>>>> "/src/main/java-jfr/com/sun/javafx/logging" >>>>>> there are imports of com.oracle.jrockit.jfr that can't be >>>>>> resolved. Where >>>>>> are these located? >>>>>> >>>>>> >>>>>> These classes used to be part of the JFR commercial feature in the >>>>>> Oracle JDK. The java-jfr sources are obsolete and no longer built >>>>>> (and no >>>>>> longer buildable), so you can safely remove it from your IDE >>>>>> files. I also >>>>>> still see references to it in the netbeans/base project. I will >>>>>> file a bug >>>>>> to remove this obsolete code and fix the NetBeans references at >>>>>> the same >>>>>> time. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth < >>>>>> kevin.rushforth at oracle.com> wrote: >>>>>> >>>>>>> Ah, I see. Then yes, just removing the old ones is fine. >>>>>>> >>>>>>> As for the larger question, unless there are dependencies on >>>>>>> apps, you >>>>>>> can assume that the only ones you care about are the ones >>>>>>> created by >>>>>>> "gradle sdk". >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Nir Lisker wrote: >>>>>>> >>>>>>> So this is why I was asking about the optional stuff: 'graphics' >>>>>>> module has BOTH >>>>>>> >>>>>>> build/resources/jsl-decora >>>>>>> build/resources/jsl-prism >>>>>>> >>>>>>> and >>>>>>> >>>>>>> build/gensrc/jsl-decora >>>>>>> build/gensrc/jsl-prism >>>>>>> >>>>>>> That led me to think that when the new dependencies were added >>>>>>> the old >>>>>>> ones weren't removed. Those that weren't optional (like the >>>>>>> /resources >>>>>>> ones, which I removed) were easy to catch and we could have >>>>>>> finished here. >>>>>>> Those that are optional are not causing trouble even when >>>>>>> missing because >>>>>>> they are optional. >>>>>>> >>>>>>> gradle sdk does not create the ones which are marked optional that >>>>>>> Iv'e surveyed, but I don't know if that's the only way they can >>>>>>> be created. >>>>>>> If I compare solely with gradle sdk then I can just remove >>>>>>> whatever is >>>>>>> missing on grounds that it's left over. >>>>>>> >>>>>>> - Nir >>>>>>> >>>>>>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth < >>>>>>> kevin.rushforth at oracle.com> wrote: >>>>>>> >>>>>>>> One more thing about the specific path you mentioned as not being >>>>>>>> there. >>>>>>>> >>>>>>>> >>>>>>> path="build/resources/jsl-decora"/> >>>>>>>> >>>>>>> path="build/resources/jsl-prism"/> >>>>>>>> >>>>>>>> These are still being created by 'gradle sdk', but the path is >>>>>>>> wrong >>>>>>>> (the files moved in JDK 9) and should be: >>>>>>>> >>>>>>>> build/gensrc/jsl-decora >>>>>>>> build/gensrc/jsl-prism >>>>>>>> >>>>>>>> You might want to take that into account. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Kevin Rushforth wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Nir Lisker wrote: >>>>>>>>> >>>>>>>>>> Iv'e removed all the classpath dependencies that were causing >>>>>>>>>> errors. I don't mind sorting out the rest of the files while >>>>>>>>>> at it, though >>>>>>>>>> for that there are a few things I'm not sure about: >>>>>>>>>> >>>>>>>>>> 1. Some dependencies are marked as optional and as such they >>>>>>>>>> don't >>>>>>>>>> cause errors, but they are still missing. Is it safe to >>>>>>>>>> remove them or is >>>>>>>>>> it possible that they will be created as some point? >>>>>>>>>> >>>>>>>>> Some of them might be created...not sure without checking. I >>>>>>>>> recommend running "gradle sdk" and then seeing if the >>>>>>>>> dependencies are >>>>>>>>> there. >>>>>>>>> >>>>>>>>> Examples are the 'base' module with "src/test/resources" and >>>>>>>>>> "src/main/resources" optional dependencies, and 'controls' >>>>>>>>>> module has the >>>>>>>>>> optional dependency "src/main/resources" commented out. >>>>>>>>>> >>>>>>>>> I see. You might as well leave them, but it probably doesn't >>>>>>>>> matter. >>>>>>>>> >>>>>>>>> 2. Can I assume that all other dependencies are really needed? >>>>>>>>>> (Eclipse won't complain about unused ones as far as I know.) >>>>>>>>>> >>>>>>>>> That seems best. >>>>>>>>> >>>>>>>>> 3. What are the formatting standards for XML (indentation, line >>>>>>>>>> length...)? From a quick look I see different styles in >>>>>>>>>> different files. >>>>>>>>>> >>>>>>>>> For IDE files, we don't worry about formatting. In many cases >>>>>>>>> they >>>>>>>>> are auto-generated anyway. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>>> - Nir >>>>>>>>>> > From kevin.rushforth at oracle.com Thu Feb 1 23:26:24 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 01 Feb 2018 15:26:24 -0800 Subject: More community participation in JavaFX Message-ID: <5A73A220.7030706@oracle.com> To: OpenJFX Developers We are looking to grow the community of contributors to the OpenJFX project, especially serious contributors who will stick around long enough to become reviewers, to help us keep the platform vibrant. To this end we are looking at ways to encourage more participation and make it easier for interested folks to contribute. We are specifically looking to discuss ideas around the following areas: * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) * Code review policies * API / feature review policies * Code review tools (we currently use webrev, but that isn't set in stone) To keep this thread productive, the following are explicitly out of scope: * Discussion of specific features or bugs that you would like to implement (or wish someone else would) * Discussion about platform support * Discussion about version control systems (e.g., hg versus git), hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus github), etc...at least for now. We are aware of the potential benefits of such changes, but we'd like to focus our efforts on higher-leverage things we can do in the short term. * Discussion about the requirement of a signed OCA to become a contributor * Off-topic or tangential commentary about OpenJFX that isn't directly related to the topic at hand As a starting point for discussion, here are some areas I think need improvement; I'm sure there are others: I. Helping contributors get started It isn?t as easy to get started with OpenJFX as it should be. We want to make it easier for potential OpenJFX contributors to get started. Here are some ideas that I think might help: * Improve the build instructions / Wiki (I made a first start, but there is much more to be done) * Make the build itself more resilient where possible, and provide better error messages, specifically when dealing with native compilers and libraries * Add an option to skip building all native code and use prebuilt binaries (like we do already for media and webkit); this is tracked by JDK-8092279, but it hasn?t been looked at recently * Make it easier to build / test your local OpenJFX build using an OpenJDK build (currently the only way to do this is to build OpenJDK locally, after using configure to point to your just-built javafx.* modules). * Provide step-by-step instructions for how to make a contribution, including testing requirements; a lot of the pieces are there, but are out of date or scattered in several places. As part of this, we could have a section on how to contribute docs, samples or tests, since that is often a good place to start. * Provide a sandbox environment where contributors can discuss and test ideas. For example, an OpenJFX mirror on github, potentially connected to AdoptOpenJDK. II. Code reviews and API reviews Code reviews are important to maintain high-quality contributions, but we recognize that not every type of change needs the same level of review. Without lowering our standards of quality, we want to make it easier to get low-impact changes (simple bug fixes) accepted. There are three categories of changes, each of which might merit a different review standard: 1. Low-impact bug fixes. These are typically isolated bug fixes with little or no impact beyond fixing the bug in question; included in this category are test fixes (including new tests) doc fixes, and fixes to sample applications (including new samples). 2. Higher impact bug fixes or RFEs. These include changes to the implementation that potentially have a performance or behavioral impact, or are otherwise broad in scope. Some larger bug fixes will fall into this category, as will fixes in high-risk areas (e.g., CSS). 3. New features / API additions. In addition to reviewing the implementation, we will need a separate approval process for the new API / feature (such as the CSR, which is what we use now, or a similar process). We take compatibility seriously, so anything that adds new API needs to be done with an eye towards supporting it for at least 10 years. We don't want to add new public API without that level of commitment. Every new feature forecloses on alternate future features. Significant effort must be taken to think about "if we did this, what could it interact with in the future?" Also, anything with a large potential impact on performance or behavioral compatibility needs to be looked at carefully. Put another way, we want to encourage thinking about new features or new API in terms of a design / stewardship process; to think in terms of questions like "what's the right thing for JavaFX in the next 10+ years" rather than "here's some code that solves my problem, please take it". As a stake in the ground, I might suggest the following: * All changes need at least one reviewer other than the person making the change who can evaluate the change for correctness and consistency. For simple bug fixes, a single reviewer may be sufficient. Of course, one of our big challenges in all this is: "how do we grow more reviewers?", by which I mean "how do we facilitate getting contributors with enough expertise in a given area to eventually be able to effectively review contributions from others?" * We need clear criteria for the other two categories that balance process efficiency with the desire to maintain compatibility and stability. API changes need to be approved by a lead. My thought is to combine the last two into a single category for purposes of reviewing the implementation. Anything that affects public API or behavioral compatibility will require CSR or similar approval, over and above the implementation review, which seems sufficient. * I recommend that we formalize the concept of reviewers, using the OpenJDK Reviewer role for the Project. We might also consider if we want to make any changes to the criteria used by the JDK Project for becoming an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK bylaws allow projects a fair degree of latitude to define these criteria, so we might consider making some modifications. For example, we might make it somewhat easier for a Contributor to become an Author, or for a Committer to become a Reviewer. I have some thoughts on this, but want to hear from others first. I look forward to feedback on this proposal, and hope it will spark a productive discussion. -- Kevin Rushforth, OpenJFX Project Lead From mike.ennen at gmail.com Thu Feb 1 23:58:52 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Thu, 1 Feb 2018 16:58:52 -0700 Subject: More community participation in JavaFX In-Reply-To: <5A73A220.7030706@oracle.com> References: <5A73A220.7030706@oracle.com> Message-ID: I think that having a public sandbox mirror on GitHub, as you mentioned, is a great idea. The idea is that PRs could be opened and the test suites could be run using CI for the platforms supported by JavaFX. The PR itself would never be directly merged into the OpenJFX hg repository. Instead the PR would be a launching point that provides a means for review and feedback. Once all feedback is taken into account, the PR can be marked as "Ready" which means it is ready to move up to the more formal review processes already in place. Automating the creation of a webrev for the PR, as well as converting the git PR to a mercurial one would make the process streamlined and efficient. I only mention GitHub because I think it would allow for the smallest barrier of entry and cast the widest net of potential contributors. Setting up this mirroring infrastructure wouldn't be a simple task but it is very doable IMO. I messed around with creating Travis and Appveyor CI builds for openjfx and besides running up against a 45 minute time limit I didn't encounter any show-stoppers. I believe we need such a sandbox to act as a "staging ground" or an adapter between the high barrier to entry and first-time or new contributions. The only way it would work, in my opinion, is that there is a vibrant community of reviewers who, in their free time, help get the PRs in shape to move to the next level (which is the more formal processes that already exist, as you mentioned). Thanks for starting this important discussion, Kevin. -- Michael Ennen On Thu, Feb 1, 2018 at 4:26 PM, Kevin Rushforth wrote: > To: OpenJFX Developers > > We are looking to grow the community of contributors to the OpenJFX > project, especially serious contributors who will stick around long enough > to become reviewers, to help us keep the platform vibrant. To this end we > are looking at ways to encourage more participation and make it easier for > interested folks to contribute. > > We are specifically looking to discuss ideas around the following areas: > > * Easing barriers to contribution (e.g., making JavaFX easier to build, > better documentation, making it easier to test changes) > > * Code review policies > > * API / feature review policies > > * Code review tools (we currently use webrev, but that isn't set in stone) > > > To keep this thread productive, the following are explicitly out of scope: > > * Discussion of specific features or bugs that you would like to implement > (or wish someone else would) > > * Discussion about platform support > > * Discussion about version control systems (e.g., hg versus git), hosting > of the OpenJFX repos and bug database (e.g., OpenJDK versus github), > etc...at least for now. We are aware of the potential benefits of such > changes, but we'd like to focus our efforts on higher-leverage things we > can do in the short term. > > * Discussion about the requirement of a signed OCA to become a contributor > > * Off-topic or tangential commentary about OpenJFX that isn't directly > related to the topic at hand > > > As a starting point for discussion, here are some areas I think need > improvement; I'm sure there are others: > > I. Helping contributors get started > > It isn?t as easy to get started with OpenJFX as it should be. We want to > make it easier for potential OpenJFX contributors to get started. Here are > some ideas that I think might help: > > * Improve the build instructions / Wiki (I made a first start, but there > is much more to be done) > > * Make the build itself more resilient where possible, and provide better > error messages, specifically when dealing with native compilers and > libraries > > * Add an option to skip building all native code and use prebuilt binaries > (like we do already for media and webkit); this is tracked by JDK-8092279, > but it hasn?t been looked at recently > > * Make it easier to build / test your local OpenJFX build using an OpenJDK > build (currently the only way to do this is to build OpenJDK locally, after > using configure to point to your just-built javafx.* modules). > > * Provide step-by-step instructions for how to make a contribution, > including testing requirements; a lot of the pieces are there, but are out > of date or scattered in several places. As part of this, we could have a > section on how to contribute docs, samples or tests, since that is often a > good place to start. > > * Provide a sandbox environment where contributors can discuss and test > ideas. For example, an OpenJFX mirror on github, potentially connected to > AdoptOpenJDK. > > > II. Code reviews and API reviews > > Code reviews are important to maintain high-quality contributions, but we > recognize that not every type of change needs the same level of review. > Without lowering our standards of quality, we want to make it easier to get > low-impact changes (simple bug fixes) accepted. > > There are three categories of changes, each of which might merit a > different review standard: > > 1. Low-impact bug fixes. These are typically isolated bug fixes with > little or no impact beyond fixing the bug in question; included in this > category are test fixes (including new tests) doc fixes, and fixes to > sample applications (including new samples). > > 2. Higher impact bug fixes or RFEs. These include changes to the > implementation that potentially have a performance or behavioral impact, or > are otherwise broad in scope. Some larger bug fixes will fall into this > category, as will fixes in high-risk areas (e.g., CSS). > > 3. New features / API additions. In addition to reviewing the > implementation, we will need a separate approval process for the new API / > feature (such as the CSR, which is what we use now, or a similar process). > > We take compatibility seriously, so anything that adds new API needs to be > done with an eye towards supporting it for at least 10 years. We don't want > to add new public API without that level of commitment. Every new feature > forecloses on alternate future features. Significant effort must be taken > to think about "if we did this, what could it interact with in the future?" > Also, anything with a large potential impact on performance or behavioral > compatibility needs to be looked at carefully. > > Put another way, we want to encourage thinking about new features or new > API in terms of a design / stewardship process; to think in terms of > questions like "what's the right thing for JavaFX in the next 10+ years" > rather than "here's some code that solves my problem, please take it". > > > As a stake in the ground, I might suggest the following: > > * All changes need at least one reviewer other than the person making the > change who can evaluate the change for correctness and consistency. For > simple bug fixes, a single reviewer may be sufficient. Of course, one of > our big challenges in all this is: "how do we grow more reviewers?", by > which I mean "how do we facilitate getting contributors with enough > expertise in a given area to eventually be able to effectively review > contributions from others?" > > * We need clear criteria for the other two categories that balance process > efficiency with the desire to maintain compatibility and stability. API > changes need to be approved by a lead. My thought is to combine the last > two into a single category for purposes of reviewing the implementation. > Anything that affects public API or behavioral compatibility will require > CSR or similar approval, over and above the implementation review, which > seems sufficient. > > * I recommend that we formalize the concept of reviewers, using the > OpenJDK Reviewer role for the Project. We might also consider if we want to > make any changes to the criteria used by the JDK Project for becoming an > OpenJFX Project Author, Committer, and Reviewer. The OpenJDK bylaws allow > projects a fair degree of latitude to define these criteria, so we might > consider making some modifications. For example, we might make it somewhat > easier for a Contributor to become an Author, or for a Committer to become > a Reviewer. I have some thoughts on this, but want to hear from others > first. > > > I look forward to feedback on this proposal, and hope it will spark a > productive discussion. > > -- Kevin Rushforth, OpenJFX Project Lead > > From rsteiger at ensemblesoft.net Fri Feb 2 00:03:06 2018 From: rsteiger at ensemblesoft.net (Richard Steiger) Date: Thu, 1 Feb 2018 16:03:06 -0800 Subject: More community participation in JavaFX In-Reply-To: <5A73A220.7030706@oracle.com> References: <5A73A220.7030706@oracle.com> Message-ID: Hi Kevin, As a long-time observer of the OpenJFX project, let me put all my chips at this point on making builds more stable, bullet-proof, and automated, and give equal weight making them so on Win10 and OS/X, specifically, the same weight as is given to making building and developing on Linux work well. Over the last 3 or so years, on at least 3 separate occasions, I've gotten a head of inspirational steam to try-out some new features (the latest being using byte-code engineering to radically streamline binding, rendering most of the current API obsolete, and hugely improving performance).? I then attempt to build the whole project from sources (not always required, but essential when it is) on Win10, my development platform of choice, and invariably get wound around the axel of no-longer published VS tooling, missing binaries, and other show-stopper glitches. Like many potential contributors, I've got a day job, plus am trying to launch a garage startup, so my time is a very scarce resource.? I simply don't have the extra cycles to troubleshoot highly convoluted builds (of which OpenJFX is one of the worst I've seen), so my head of steam bleeds-off for another year or so.? Nor am I willing to switch to a Linux development environment, remap my motor memory, take-on care and feeding of another platform (Windows and OS/X suck enough time, and are essential for my business).? Every time I've hit this wall, I've puzzled over how the team has tolerated the situation, and moved on. So, to be redundant, all the other issues you've so cogently enumerated pale in the face of development portability, starting with build stability and cleanliness on widely-used platforms. Thanks for considering the above input. -rjs On 2/1/18 3:26 PM, Kevin Rushforth wrote: > To: OpenJFX Developers > > We are looking to grow the community of contributors to the OpenJFX > project, especially serious contributors who will stick around long > enough to become reviewers, to help us keep the platform vibrant. To > this end we are looking at ways to encourage more participation and > make it easier for interested folks to contribute. > > We are specifically looking to discuss ideas around the following areas: > > * Easing barriers to contribution (e.g., making JavaFX easier to > build, better documentation, making it easier to test changes) > > * Code review policies > > * API / feature review policies > > * Code review tools (we currently use webrev, but that isn't set in > stone) > > > To keep this thread productive, the following are explicitly out of > scope: > > * Discussion of specific features or bugs that you would like to > implement (or wish someone else would) > > * Discussion about platform support > > * Discussion about version control systems (e.g., hg versus git), > hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus > github), etc...at least for now. We are aware of the potential > benefits of such changes, but we'd like to focus our efforts on > higher-leverage things we can do in the short term. > > * Discussion about the requirement of a signed OCA to become a > contributor > > * Off-topic or tangential commentary about OpenJFX that isn't directly > related to the topic at hand > > > As a starting point for discussion, here are some areas I think need > improvement; I'm sure there are others: > > I. Helping contributors get started > > It isn?t as easy to get started with OpenJFX as it should be. We want > to make it easier for potential OpenJFX contributors to get started. > Here are some ideas that I think might help: > > * Improve the build instructions / Wiki (I made a first start, but > there is much more to be done) > > * Make the build itself more resilient where possible, and provide > better error messages, specifically when dealing with native compilers > and libraries > > * Add an option to skip building all native code and use prebuilt > binaries (like we do already for media and webkit); this is tracked by > JDK-8092279, but it hasn?t been looked at recently > > * Make it easier to build / test your local OpenJFX build using an > OpenJDK build (currently the only way to do this is to build OpenJDK > locally, after using configure to point to your just-built javafx.* > modules). > > * Provide step-by-step instructions for how to make a contribution, > including testing requirements; a lot of the pieces are there, but are > out of date or scattered in several places. As part of this, we could > have a section on how to contribute docs, samples or tests, since that > is often a good place to start. > > * Provide a sandbox environment where contributors can discuss and > test ideas. For example, an OpenJFX mirror on github, potentially > connected to AdoptOpenJDK. > > > II. Code reviews and API reviews > > Code reviews are important to maintain high-quality contributions, but > we recognize that not every type of change needs the same level of > review. Without lowering our standards of quality, we want to make it > easier to get low-impact changes (simple bug fixes) accepted. > > There are three categories of changes, each of which might merit a > different review standard: > > 1. Low-impact bug fixes. These are typically isolated bug fixes with > little or no impact beyond fixing the bug in question; included in > this category are test fixes (including new tests) doc fixes, and > fixes to sample applications (including new samples). > > 2. Higher impact bug fixes or RFEs. These include changes to the > implementation that potentially have a performance or behavioral > impact, or are otherwise broad in scope. Some larger bug fixes will > fall into this category, as will fixes in high-risk areas (e.g., CSS). > > 3. New features / API additions. In addition to reviewing the > implementation, we will need a separate approval process for the new > API / feature (such as the CSR, which is what we use now, or a similar > process). > > We take compatibility seriously, so anything that adds new API needs > to be done with an eye towards supporting it for at least 10 years. We > don't want to add new public API without that level of commitment. > Every new feature forecloses on alternate future features. Significant > effort must be taken to think about "if we did this, what could it > interact with in the future?" Also, anything with a large potential > impact on performance or behavioral compatibility needs to be looked > at carefully. > > Put another way, we want to encourage thinking about new features or > new API in terms of a design / stewardship process; to think in terms > of questions like "what's the right thing for JavaFX in the next 10+ > years" rather than "here's some code that solves my problem, please > take it". > > > As a stake in the ground, I might suggest the following: > > * All changes need at least one reviewer other than the person making > the change who can evaluate the change for correctness and > consistency. For simple bug fixes, a single reviewer may be > sufficient. Of course, one of our big challenges in all this is: "how > do we grow more reviewers?", by which I mean "how do we facilitate > getting contributors with enough expertise in a given area to > eventually be able to effectively review contributions from others?" > > * We need clear criteria for the other two categories that balance > process efficiency with the desire to maintain compatibility and > stability. API changes need to be approved by a lead. My thought is to > combine the last two into a single category for purposes of reviewing > the implementation. Anything that affects public API or behavioral > compatibility will require CSR or similar approval, over and above the > implementation review, which seems sufficient. > > * I recommend that we formalize the concept of reviewers, using the > OpenJDK Reviewer role for the Project. We might also consider if we > want to make any changes to the criteria used by the JDK Project for > becoming an OpenJFX Project Author, Committer, and Reviewer. The > OpenJDK bylaws allow projects a fair degree of latitude to define > these criteria, so we might consider making some modifications. For > example, we might make it somewhat easier for a Contributor to become > an Author, or for a Committer to become a Reviewer. I have some > thoughts on this, but want to hear from others first. > > > I look forward to feedback on this proposal, and hope it will spark a > productive discussion. > > -- Kevin Rushforth, OpenJFX Project Lead > From johnvalrose at gmail.com Fri Feb 2 09:41:00 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Fri, 2 Feb 2018 20:41:00 +1100 Subject: More community participation in JavaFX In-Reply-To: References: <5A73A220.7030706@oracle.com> Message-ID: <0CD55CC7-7F37-4BE1-869B-B4D3E790F372@gmail.com> Kevin - thanks so much for this extremely well thought-out, informative and positive email. It?s the best post I?ve ever seen from Oracle on this list! It clearly highlights 2 things: 1. The future of JavaFX is heavily reliant on community involvement. 2. Oracle are actually listening to community concerns and are actively trying to address the main issues raised. I?ve never doubted the enthusiasm or expertise of the ?small? Oracle JavaFX team and I?m sure if Larry came downstairs and said ?Hey Kevin, would you like another 50 devs on your team??, your answer would probably be ?Sure, but 100 would be even better!?. But, we know you must work within the resourcing and financial constraints that prevail. So, I for one have been very keen to contribute to OpenJFX, have suggested several innovative features and have tried to devote at least some of my own very limited time to achieving this, only to be met with a few major barricades. It has been noted that the most fundamental aspect of development (i.e. building the project from source) is currently a significant challenge on all platforms and having to attempt to decipher errors and get the builds to work reliably is in itself enough to put off many potential contributors (perhaps permanently). So, I?m very pleased to see that this issue has been prioritised - thank you. Another barricade is the complexity of the formal process of making contributions and the extensive ?red tape? which I see you are also addressing. I?m willing to bet that once the community can build OpenJFX on any platform reliably, quickly and in a repeatable manner, a large increase in the number of people who actually *do* contribute will follow. It is well known that one of the real strengths of JavaFX is the vibrant and passionate community. These proposals give us all a much better chance to become tangible contributors and for JavaFX to not just continue to ?exist? but for real innovation and progress to occur. It?s somewhat ironic that I have been discussing setting up and maintaining a mirror build with some devs privately which could act as a sandbox or incubation platform so I?m very pleased to know that the large amount of effort that would have entailed is mostly going to be addressed through these proposals. These are now exciting times for JavaFX! I foresee the fusion of Oracle expertise and stewardship with community passion and skills and the great result for everyone being a living, breathing and thriving OpenJFX :-) Thanks again for putting the time and effort into these awesome proposals and I hope that many ?lurkers? will step up and together we can build something of tremendous quality, utility and value! Graciously, John-Val Rose > On 2 Feb 2018, at 11:03, Richard Steiger wrote: > > Hi Kevin, > > As a long-time observer of the OpenJFX project, let me put all my chips at this point on making builds more stable, bullet-proof, and automated, and give equal weight making them so on Win10 and OS/X, specifically, the same weight as is given to making building and developing on Linux work well. > > Over the last 3 or so years, on at least 3 separate occasions, I've gotten a head of inspirational steam to try-out some new features (the latest being using byte-code engineering to radically streamline binding, rendering most of the current API obsolete, and hugely improving performance). I then attempt to build the whole project from sources (not always required, but essential when it is) on Win10, my development platform of choice, and invariably get wound around the axel of no-longer published VS tooling, missing binaries, and other show-stopper glitches. > > Like many potential contributors, I've got a day job, plus am trying to launch a garage startup, so my time is a very scarce resource. I simply don't have the extra cycles to troubleshoot highly convoluted builds (of which OpenJFX is one of the worst I've seen), so my head of steam bleeds-off for another year or so. Nor am I willing to switch to a Linux development environment, remap my motor memory, take-on care and feeding of another platform (Windows and OS/X suck enough time, and are essential for my business). Every time I've hit this wall, I've puzzled over how the team has tolerated the situation, and moved on. > > So, to be redundant, all the other issues you've so cogently enumerated pale in the face of development portability, starting with build stability and cleanliness on widely-used platforms. > > Thanks for considering the above input. > > -rjs > > >> On 2/1/18 3:26 PM, Kevin Rushforth wrote: >> To: OpenJFX Developers >> >> We are looking to grow the community of contributors to the OpenJFX project, especially serious contributors who will stick around long enough to become reviewers, to help us keep the platform vibrant. To this end we are looking at ways to encourage more participation and make it easier for interested folks to contribute. >> >> We are specifically looking to discuss ideas around the following areas: >> >> * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) >> >> * Code review policies >> >> * API / feature review policies >> >> * Code review tools (we currently use webrev, but that isn't set in stone) >> >> >> To keep this thread productive, the following are explicitly out of scope: >> >> * Discussion of specific features or bugs that you would like to implement (or wish someone else would) >> >> * Discussion about platform support >> >> * Discussion about version control systems (e.g., hg versus git), hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus github), etc...at least for now. We are aware of the potential benefits of such changes, but we'd like to focus our efforts on higher-leverage things we can do in the short term. >> >> * Discussion about the requirement of a signed OCA to become a contributor >> >> * Off-topic or tangential commentary about OpenJFX that isn't directly related to the topic at hand >> >> >> As a starting point for discussion, here are some areas I think need improvement; I'm sure there are others: >> >> I. Helping contributors get started >> >> It isn?t as easy to get started with OpenJFX as it should be. We want to make it easier for potential OpenJFX contributors to get started. Here are some ideas that I think might help: >> >> * Improve the build instructions / Wiki (I made a first start, but there is much more to be done) >> >> * Make the build itself more resilient where possible, and provide better error messages, specifically when dealing with native compilers and libraries >> >> * Add an option to skip building all native code and use prebuilt binaries (like we do already for media and webkit); this is tracked by JDK-8092279, but it hasn?t been looked at recently >> >> * Make it easier to build / test your local OpenJFX build using an OpenJDK build (currently the only way to do this is to build OpenJDK locally, after using configure to point to your just-built javafx.* modules). >> >> * Provide step-by-step instructions for how to make a contribution, including testing requirements; a lot of the pieces are there, but are out of date or scattered in several places. As part of this, we could have a section on how to contribute docs, samples or tests, since that is often a good place to start. >> >> * Provide a sandbox environment where contributors can discuss and test ideas. For example, an OpenJFX mirror on github, potentially connected to AdoptOpenJDK. >> >> >> II. Code reviews and API reviews >> >> Code reviews are important to maintain high-quality contributions, but we recognize that not every type of change needs the same level of review. Without lowering our standards of quality, we want to make it easier to get low-impact changes (simple bug fixes) accepted. >> >> There are three categories of changes, each of which might merit a different review standard: >> >> 1. Low-impact bug fixes. These are typically isolated bug fixes with little or no impact beyond fixing the bug in question; included in this category are test fixes (including new tests) doc fixes, and fixes to sample applications (including new samples). >> >> 2. Higher impact bug fixes or RFEs. These include changes to the implementation that potentially have a performance or behavioral impact, or are otherwise broad in scope. Some larger bug fixes will fall into this category, as will fixes in high-risk areas (e.g., CSS). >> >> 3. New features / API additions. In addition to reviewing the implementation, we will need a separate approval process for the new API / feature (such as the CSR, which is what we use now, or a similar process). >> >> We take compatibility seriously, so anything that adds new API needs to be done with an eye towards supporting it for at least 10 years. We don't want to add new public API without that level of commitment. Every new feature forecloses on alternate future features. Significant effort must be taken to think about "if we did this, what could it interact with in the future?" Also, anything with a large potential impact on performance or behavioral compatibility needs to be looked at carefully. >> >> Put another way, we want to encourage thinking about new features or new API in terms of a design / stewardship process; to think in terms of questions like "what's the right thing for JavaFX in the next 10+ years" rather than "here's some code that solves my problem, please take it". >> >> >> As a stake in the ground, I might suggest the following: >> >> * All changes need at least one reviewer other than the person making the change who can evaluate the change for correctness and consistency. For simple bug fixes, a single reviewer may be sufficient. Of course, one of our big challenges in all this is: "how do we grow more reviewers?", by which I mean "how do we facilitate getting contributors with enough expertise in a given area to eventually be able to effectively review contributions from others?" >> >> * We need clear criteria for the other two categories that balance process efficiency with the desire to maintain compatibility and stability. API changes need to be approved by a lead. My thought is to combine the last two into a single category for purposes of reviewing the implementation. Anything that affects public API or behavioral compatibility will require CSR or similar approval, over and above the implementation review, which seems sufficient. >> >> * I recommend that we formalize the concept of reviewers, using the OpenJDK Reviewer role for the Project. We might also consider if we want to make any changes to the criteria used by the JDK Project for becoming an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK bylaws allow projects a fair degree of latitude to define these criteria, so we might consider making some modifications. For example, we might make it somewhat easier for a Contributor to become an Author, or for a Committer to become a Reviewer. I have some thoughts on this, but want to hear from others first. >> >> >> I look forward to feedback on this proposal, and hope it will spark a productive discussion. >> >> -- Kevin Rushforth, OpenJFX Project Lead >> > From paulrussell70 at gmail.com Fri Feb 2 10:14:59 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Fri, 2 Feb 2018 10:14:59 +0000 Subject: More community participation in JavaFX Message-ID: Yeah - I looked at the windows build process recently - which was enough to dissuade me from starting. I do know JavaFX fairly well, and have a potted history working in software companies. I'd like to get on-board once I finish my current game. I'd be interested in game related areas; but realise these may not be areas of development that JavaFX was ever intended, or *will* ever be directed to cover. That would be another whole conversation to have. If it's the case that JavaFX is to remain a GUI toolkit, with v. limited graphics abilities: something useful for front-ending business apps, but not much more, then it needs to be made clearer that this is the aim. The games community has grown despondent about JavaFX as a framework, which is a shame. I see evidence of this scattered all over the web. Too many abandoned projects from 2013 era. It's all bit depressing. It's such a great framework. On 2 February 2018 at 00:07, 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. More community participation in JavaFX (Kevin Rushforth) > 2. Re: More community participation in JavaFX (Michael Ennen) > 3. Re: More community participation in JavaFX (Richard Steiger) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 01 Feb 2018 15:26:24 -0800 > From: Kevin Rushforth > To: "openjfx-dev at openjdk.java.net" > Subject: More community participation in JavaFX > Message-ID: <5A73A220.7030706 at oracle.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > To: OpenJFX Developers > > We are looking to grow the community of contributors to the OpenJFX > project, especially serious contributors who will stick around long > enough to become reviewers, to help us keep the platform vibrant. To > this end we are looking at ways to encourage more participation and make > it easier for interested folks to contribute. > > We are specifically looking to discuss ideas around the following areas: > > * Easing barriers to contribution (e.g., making JavaFX easier to build, > better documentation, making it easier to test changes) > > * Code review policies > > * API / feature review policies > > * Code review tools (we currently use webrev, but that isn't set in stone) > > > To keep this thread productive, the following are explicitly out of scope: > > * Discussion of specific features or bugs that you would like to > implement (or wish someone else would) > > * Discussion about platform support > > * Discussion about version control systems (e.g., hg versus git), > hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus > github), etc...at least for now. We are aware of the potential benefits > of such changes, but we'd like to focus our efforts on higher-leverage > things we can do in the short term. > > * Discussion about the requirement of a signed OCA to become a contributor > > * Off-topic or tangential commentary about OpenJFX that isn't directly > related to the topic at hand > > > As a starting point for discussion, here are some areas I think need > improvement; I'm sure there are others: > > I. Helping contributors get started > > It isn?t as easy to get started with OpenJFX as it should be. We want to > make it easier for potential OpenJFX contributors to get started. Here > are some ideas that I think might help: > > * Improve the build instructions / Wiki (I made a first start, but there > is much more to be done) > > * Make the build itself more resilient where possible, and provide > better error messages, specifically when dealing with native compilers > and libraries > > * Add an option to skip building all native code and use prebuilt > binaries (like we do already for media and webkit); this is tracked by > JDK-8092279, but it hasn?t been looked at recently > > * Make it easier to build / test your local OpenJFX build using an > OpenJDK build (currently the only way to do this is to build OpenJDK > locally, after using configure to point to your just-built javafx.* > modules). > > * Provide step-by-step instructions for how to make a contribution, > including testing requirements; a lot of the pieces are there, but are > out of date or scattered in several places. As part of this, we could > have a section on how to contribute docs, samples or tests, since that > is often a good place to start. > > * Provide a sandbox environment where contributors can discuss and test > ideas. For example, an OpenJFX mirror on github, potentially connected > to AdoptOpenJDK. > > > II. Code reviews and API reviews > > Code reviews are important to maintain high-quality contributions, but > we recognize that not every type of change needs the same level of > review. Without lowering our standards of quality, we want to make it > easier to get low-impact changes (simple bug fixes) accepted. > > There are three categories of changes, each of which might merit a > different review standard: > > 1. Low-impact bug fixes. These are typically isolated bug fixes with > little or no impact beyond fixing the bug in question; included in this > category are test fixes (including new tests) doc fixes, and fixes to > sample applications (including new samples). > > 2. Higher impact bug fixes or RFEs. These include changes to the > implementation that potentially have a performance or behavioral impact, > or are otherwise broad in scope. Some larger bug fixes will fall into > this category, as will fixes in high-risk areas (e.g., CSS). > > 3. New features / API additions. In addition to reviewing the > implementation, we will need a separate approval process for the new API > / feature (such as the CSR, which is what we use now, or a similar > process). > > We take compatibility seriously, so anything that adds new API needs to > be done with an eye towards supporting it for at least 10 years. We > don't want to add new public API without that level of commitment. Every > new feature forecloses on alternate future features. Significant effort > must be taken to think about "if we did this, what could it interact > with in the future?" Also, anything with a large potential impact on > performance or behavioral compatibility needs to be looked at carefully. > > Put another way, we want to encourage thinking about new features or new > API in terms of a design / stewardship process; to think in terms of > questions like "what's the right thing for JavaFX in the next 10+ years" > rather than "here's some code that solves my problem, please take it". > > > As a stake in the ground, I might suggest the following: > > * All changes need at least one reviewer other than the person making > the change who can evaluate the change for correctness and consistency. > For simple bug fixes, a single reviewer may be sufficient. Of course, > one of our big challenges in all this is: "how do we grow more > reviewers?", by which I mean "how do we facilitate getting contributors > with enough expertise in a given area to eventually be able to > effectively review contributions from others?" > > * We need clear criteria for the other two categories that balance > process efficiency with the desire to maintain compatibility and > stability. API changes need to be approved by a lead. My thought is to > combine the last two into a single category for purposes of reviewing > the implementation. Anything that affects public API or behavioral > compatibility will require CSR or similar approval, over and above the > implementation review, which seems sufficient. > > * I recommend that we formalize the concept of reviewers, using the > OpenJDK Reviewer role for the Project. We might also consider if we want > to make any changes to the criteria used by the JDK Project for becoming > an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK bylaws > allow projects a fair degree of latitude to define these criteria, so we > might consider making some modifications. For example, we might make it > somewhat easier for a Contributor to become an Author, or for a > Committer to become a Reviewer. I have some thoughts on this, but want > to hear from others first. > > > I look forward to feedback on this proposal, and hope it will spark a > productive discussion. > > -- Kevin Rushforth, OpenJFX Project Lead > > > > ------------------------------ > > Message: 2 > Date: Thu, 1 Feb 2018 16:58:52 -0700 > From: Michael Ennen > To: Kevin Rushforth > Cc: "openjfx-dev at openjdk.java.net" > Subject: Re: More community participation in JavaFX > Message-ID: > GZmNoTVxg at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > I think that having a public sandbox mirror on GitHub, as you mentioned, is > a great idea. > > The idea is that PRs could be opened and the test suites could be run using > CI for the > platforms supported by JavaFX. The PR itself would never be directly merged > into the > OpenJFX hg repository. Instead the PR would be a launching point that > provides a means > for review and feedback. Once all feedback is taken into account, the PR > can be marked > as "Ready" which means it is ready to move up to the more formal review > processes > already in place. Automating the creation of a webrev for the PR, as well > as converting > the git PR to a mercurial one would make the process streamlined and > efficient. > > I only mention GitHub because I think it would allow for the smallest > barrier of entry and > cast the widest net of potential contributors. Setting up this mirroring > infrastructure wouldn't > be a simple task but it is very doable IMO. I messed around with creating > Travis and Appveyor > CI builds for openjfx and besides running up against a 45 minute time limit > I didn't encounter > any show-stoppers. > > I believe we need such a sandbox to act as a "staging ground" or an adapter > between the > high barrier to entry and first-time or new contributions. The only way it > would work, > in my opinion, is that there is a vibrant community of reviewers who, in > their free time, > help get the PRs in shape to move to the next level (which is the more > formal processes > that already exist, as you mentioned). > > Thanks for starting this important discussion, Kevin. > > -- Michael Ennen > > On Thu, Feb 1, 2018 at 4:26 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> > wrote: > > > To: OpenJFX Developers > > > > We are looking to grow the community of contributors to the OpenJFX > > project, especially serious contributors who will stick around long > enough > > to become reviewers, to help us keep the platform vibrant. To this end we > > are looking at ways to encourage more participation and make it easier > for > > interested folks to contribute. > > > > We are specifically looking to discuss ideas around the following areas: > > > > * Easing barriers to contribution (e.g., making JavaFX easier to build, > > better documentation, making it easier to test changes) > > > > * Code review policies > > > > * API / feature review policies > > > > * Code review tools (we currently use webrev, but that isn't set in > stone) > > > > > > To keep this thread productive, the following are explicitly out of > scope: > > > > * Discussion of specific features or bugs that you would like to > implement > > (or wish someone else would) > > > > * Discussion about platform support > > > > * Discussion about version control systems (e.g., hg versus git), hosting > > of the OpenJFX repos and bug database (e.g., OpenJDK versus github), > > etc...at least for now. We are aware of the potential benefits of such > > changes, but we'd like to focus our efforts on higher-leverage things we > > can do in the short term. > > > > * Discussion about the requirement of a signed OCA to become a > contributor > > > > * Off-topic or tangential commentary about OpenJFX that isn't directly > > related to the topic at hand > > > > > > As a starting point for discussion, here are some areas I think need > > improvement; I'm sure there are others: > > > > I. Helping contributors get started > > > > It isn?t as easy to get started with OpenJFX as it should be. We want to > > make it easier for potential OpenJFX contributors to get started. Here > are > > some ideas that I think might help: > > > > * Improve the build instructions / Wiki (I made a first start, but there > > is much more to be done) > > > > * Make the build itself more resilient where possible, and provide better > > error messages, specifically when dealing with native compilers and > > libraries > > > > * Add an option to skip building all native code and use prebuilt > binaries > > (like we do already for media and webkit); this is tracked by > JDK-8092279, > > but it hasn?t been looked at recently > > > > * Make it easier to build / test your local OpenJFX build using an > OpenJDK > > build (currently the only way to do this is to build OpenJDK locally, > after > > using configure to point to your just-built javafx.* modules). > > > > * Provide step-by-step instructions for how to make a contribution, > > including testing requirements; a lot of the pieces are there, but are > out > > of date or scattered in several places. As part of this, we could have a > > section on how to contribute docs, samples or tests, since that is often > a > > good place to start. > > > > * Provide a sandbox environment where contributors can discuss and test > > ideas. For example, an OpenJFX mirror on github, potentially connected to > > AdoptOpenJDK. > > > > > > II. Code reviews and API reviews > > > > Code reviews are important to maintain high-quality contributions, but we > > recognize that not every type of change needs the same level of review. > > Without lowering our standards of quality, we want to make it easier to > get > > low-impact changes (simple bug fixes) accepted. > > > > There are three categories of changes, each of which might merit a > > different review standard: > > > > 1. Low-impact bug fixes. These are typically isolated bug fixes with > > little or no impact beyond fixing the bug in question; included in this > > category are test fixes (including new tests) doc fixes, and fixes to > > sample applications (including new samples). > > > > 2. Higher impact bug fixes or RFEs. These include changes to the > > implementation that potentially have a performance or behavioral impact, > or > > are otherwise broad in scope. Some larger bug fixes will fall into this > > category, as will fixes in high-risk areas (e.g., CSS). > > > > 3. New features / API additions. In addition to reviewing the > > implementation, we will need a separate approval process for the new API > / > > feature (such as the CSR, which is what we use now, or a similar > process). > > > > We take compatibility seriously, so anything that adds new API needs to > be > > done with an eye towards supporting it for at least 10 years. We don't > want > > to add new public API without that level of commitment. Every new feature > > forecloses on alternate future features. Significant effort must be taken > > to think about "if we did this, what could it interact with in the > future?" > > Also, anything with a large potential impact on performance or behavioral > > compatibility needs to be looked at carefully. > > > > Put another way, we want to encourage thinking about new features or new > > API in terms of a design / stewardship process; to think in terms of > > questions like "what's the right thing for JavaFX in the next 10+ years" > > rather than "here's some code that solves my problem, please take it". > > > > > > As a stake in the ground, I might suggest the following: > > > > * All changes need at least one reviewer other than the person making the > > change who can evaluate the change for correctness and consistency. For > > simple bug fixes, a single reviewer may be sufficient. Of course, one of > > our big challenges in all this is: "how do we grow more reviewers?", by > > which I mean "how do we facilitate getting contributors with enough > > expertise in a given area to eventually be able to effectively review > > contributions from others?" > > > > * We need clear criteria for the other two categories that balance > process > > efficiency with the desire to maintain compatibility and stability. API > > changes need to be approved by a lead. My thought is to combine the last > > two into a single category for purposes of reviewing the implementation. > > Anything that affects public API or behavioral compatibility will require > > CSR or similar approval, over and above the implementation review, which > > seems sufficient. > > > > * I recommend that we formalize the concept of reviewers, using the > > OpenJDK Reviewer role for the Project. We might also consider if we want > to > > make any changes to the criteria used by the JDK Project for becoming an > > OpenJFX Project Author, Committer, and Reviewer. The OpenJDK bylaws allow > > projects a fair degree of latitude to define these criteria, so we might > > consider making some modifications. For example, we might make it > somewhat > > easier for a Contributor to become an Author, or for a Committer to > become > > a Reviewer. I have some thoughts on this, but want to hear from others > > first. > > > > > > I look forward to feedback on this proposal, and hope it will spark a > > productive discussion. > > > > -- Kevin Rushforth, OpenJFX Project Lead > > > > > > > ------------------------------ > > Message: 3 > Date: Thu, 1 Feb 2018 16:03:06 -0800 > From: Richard Steiger > To: openjfx-dev at openjdk.java.net > Subject: Re: More community participation in JavaFX > Message-ID: > Content-Type: text/plain; charset=windows-1252; format=flowed > > Hi Kevin, > > As a long-time observer of the OpenJFX project, let me put all my chips > at this point on making builds more stable, bullet-proof, and automated, > and give equal weight making them so on Win10 and OS/X, specifically, > the same weight as is given to making building and developing on Linux > work well. > > Over the last 3 or so years, on at least 3 separate occasions, I've > gotten a head of inspirational steam to try-out some new features (the > latest being using byte-code engineering to radically streamline > binding, rendering most of the current API obsolete, and hugely > improving performance).? I then attempt to build the whole project from > sources (not always required, but essential when it is) on Win10, my > development platform of choice, and invariably get wound around the axel > of no-longer published VS tooling, missing binaries, and other > show-stopper glitches. > > Like many potential contributors, I've got a day job, plus am trying to > launch a garage startup, so my time is a very scarce resource.? I simply > don't have the extra cycles to troubleshoot highly convoluted builds (of > which OpenJFX is one of the worst I've seen), so my head of steam > bleeds-off for another year or so.? Nor am I willing to switch to a > Linux development environment, remap my motor memory, take-on care and > feeding of another platform (Windows and OS/X suck enough time, and are > essential for my business).? Every time I've hit this wall, I've puzzled > over how the team has tolerated the situation, and moved on. > > So, to be redundant, all the other issues you've so cogently enumerated > pale in the face of development portability, starting with build > stability and cleanliness on widely-used platforms. > > Thanks for considering the above input. > > -rjs > > > On 2/1/18 3:26 PM, Kevin Rushforth wrote: > > To: OpenJFX Developers > > > > We are looking to grow the community of contributors to the OpenJFX > > project, especially serious contributors who will stick around long > > enough to become reviewers, to help us keep the platform vibrant. To > > this end we are looking at ways to encourage more participation and > > make it easier for interested folks to contribute. > > > > We are specifically looking to discuss ideas around the following areas: > > > > * Easing barriers to contribution (e.g., making JavaFX easier to > > build, better documentation, making it easier to test changes) > > > > * Code review policies > > > > * API / feature review policies > > > > * Code review tools (we currently use webrev, but that isn't set in > > stone) > > > > > > To keep this thread productive, the following are explicitly out of > > scope: > > > > * Discussion of specific features or bugs that you would like to > > implement (or wish someone else would) > > > > * Discussion about platform support > > > > * Discussion about version control systems (e.g., hg versus git), > > hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus > > github), etc...at least for now. We are aware of the potential > > benefits of such changes, but we'd like to focus our efforts on > > higher-leverage things we can do in the short term. > > > > * Discussion about the requirement of a signed OCA to become a > > contributor > > > > * Off-topic or tangential commentary about OpenJFX that isn't directly > > related to the topic at hand > > > > > > As a starting point for discussion, here are some areas I think need > > improvement; I'm sure there are others: > > > > I. Helping contributors get started > > > > It isn?t as easy to get started with OpenJFX as it should be. We want > > to make it easier for potential OpenJFX contributors to get started. > > Here are some ideas that I think might help: > > > > * Improve the build instructions / Wiki (I made a first start, but > > there is much more to be done) > > > > * Make the build itself more resilient where possible, and provide > > better error messages, specifically when dealing with native compilers > > and libraries > > > > * Add an option to skip building all native code and use prebuilt > > binaries (like we do already for media and webkit); this is tracked by > > JDK-8092279, but it hasn?t been looked at recently > > > > * Make it easier to build / test your local OpenJFX build using an > > OpenJDK build (currently the only way to do this is to build OpenJDK > > locally, after using configure to point to your just-built javafx.* > > modules). > > > > * Provide step-by-step instructions for how to make a contribution, > > including testing requirements; a lot of the pieces are there, but are > > out of date or scattered in several places. As part of this, we could > > have a section on how to contribute docs, samples or tests, since that > > is often a good place to start. > > > > * Provide a sandbox environment where contributors can discuss and > > test ideas. For example, an OpenJFX mirror on github, potentially > > connected to AdoptOpenJDK. > > > > > > II. Code reviews and API reviews > > > > Code reviews are important to maintain high-quality contributions, but > > we recognize that not every type of change needs the same level of > > review. Without lowering our standards of quality, we want to make it > > easier to get low-impact changes (simple bug fixes) accepted. > > > > There are three categories of changes, each of which might merit a > > different review standard: > > > > 1. Low-impact bug fixes. These are typically isolated bug fixes with > > little or no impact beyond fixing the bug in question; included in > > this category are test fixes (including new tests) doc fixes, and > > fixes to sample applications (including new samples). > > > > 2. Higher impact bug fixes or RFEs. These include changes to the > > implementation that potentially have a performance or behavioral > > impact, or are otherwise broad in scope. Some larger bug fixes will > > fall into this category, as will fixes in high-risk areas (e.g., CSS). > > > > 3. New features / API additions. In addition to reviewing the > > implementation, we will need a separate approval process for the new > > API / feature (such as the CSR, which is what we use now, or a similar > > process). > > > > We take compatibility seriously, so anything that adds new API needs > > to be done with an eye towards supporting it for at least 10 years. We > > don't want to add new public API without that level of commitment. > > Every new feature forecloses on alternate future features. Significant > > effort must be taken to think about "if we did this, what could it > > interact with in the future?" Also, anything with a large potential > > impact on performance or behavioral compatibility needs to be looked > > at carefully. > > > > Put another way, we want to encourage thinking about new features or > > new API in terms of a design / stewardship process; to think in terms > > of questions like "what's the right thing for JavaFX in the next 10+ > > years" rather than "here's some code that solves my problem, please > > take it". > > > > > > As a stake in the ground, I might suggest the following: > > > > * All changes need at least one reviewer other than the person making > > the change who can evaluate the change for correctness and > > consistency. For simple bug fixes, a single reviewer may be > > sufficient. Of course, one of our big challenges in all this is: "how > > do we grow more reviewers?", by which I mean "how do we facilitate > > getting contributors with enough expertise in a given area to > > eventually be able to effectively review contributions from others?" > > > > * We need clear criteria for the other two categories that balance > > process efficiency with the desire to maintain compatibility and > > stability. API changes need to be approved by a lead. My thought is to > > combine the last two into a single category for purposes of reviewing > > the implementation. Anything that affects public API or behavioral > > compatibility will require CSR or similar approval, over and above the > > implementation review, which seems sufficient. > > > > * I recommend that we formalize the concept of reviewers, using the > > OpenJDK Reviewer role for the Project. We might also consider if we > > want to make any changes to the criteria used by the JDK Project for > > becoming an OpenJFX Project Author, Committer, and Reviewer. The > > OpenJDK bylaws allow projects a fair degree of latitude to define > > these criteria, so we might consider making some modifications. For > > example, we might make it somewhat easier for a Contributor to become > > an Author, or for a Committer to become a Reviewer. I have some > > thoughts on this, but want to hear from others first. > > > > > > I look forward to feedback on this proposal, and hope it will spark a > > productive discussion. > > > > -- Kevin Rushforth, OpenJFX Project Lead > > > > > > End of openjfx-dev Digest, Vol 75, Issue 4 > ****************************************** > From cnewland at chrisnewland.com Fri Feb 2 11:11:25 2018 From: cnewland at chrisnewland.com (Chris Newland) Date: Fri, 2 Feb 2018 11:11:25 -0000 Subject: More community participation in JavaFX In-Reply-To: <5A73A220.7030706@oracle.com> References: <5A73A220.7030706@oracle.com> Message-ID: <2866034b02b2dace60f510815d1b995a.squirrel@excalibur.xssl.net> Hi Kevin, I'm more than happy to keep the community JavaFX build server at chriswhocodes.com running and host JDK 8/9/10/n + FX builds there. At the moment it's mostly used by the Raspberry Pi community to grab JavaFX overlays for JDK8 on ARM. I can also build and host OSX and Windows builds there once the build instructions are updated. Lastly I'd also be interested in profiling and contributing performance enhancements to the FX Java source code based on JIT analysis. IMO it would be useful if the OpenJFX team would make a statement on what kind of contributions fit with their overall vision (e.g. increasing performance vs bug fixing desktop widgets). Thanks, Chris On Thu, February 1, 2018 23:26, Kevin Rushforth wrote: To: OpenJFX Developers We are looking to grow the community of contributors to the OpenJFX project, especially serious contributors who will stick around long enough to become reviewers, to help us keep the platform vibrant. To this end we are looking at ways to encourage more participation and make it easier for interested folks to contribute. ... From murali.billa at oracle.com Fri Feb 2 11:52:37 2018 From: murali.billa at oracle.com (Murali Billa) Date: Fri, 2 Feb 2018 03:52:37 -0800 (PST) Subject: [11] Review request for 8196605: Robot tests fail on Windows platforms if terminal windows are in the way Message-ID: <7adeb861-8f10-4698-a87e-ac3e6e6c58f2@default> ? Hi Kevin, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8196605 ? ? webrev: http://cr.openjdk.java.net/~mbilla/8196605/webrev.00/ Thanks, Murali From nlisker at gmail.com Fri Feb 2 16:52:33 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 2 Feb 2018 18:52:33 +0200 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: <5A736F19.30503@oracle.com> References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> <5A70C18E.30805@oracle.com> <5A71D0FF.1040004@oracle.com> <5A736F19.30503@oracle.com> Message-ID: Alright, got most of them ready. About buildSrc: - What is "rt\buildSrc\build\generated-src\antlr\com\sun\scenario\effect\compiler" supposed to be? It is listed as a source folder but it's empty. - The project lists dependencies such as "build/libs/swt-debug.jar", JUnit and a JRE/JDK, but doesn't need any of them (from Eclipse's point of view). I see the base module listing this project as a dependency, but it's not used. Where is it located in the dependency chain? On Thu, Feb 1, 2018 at 9:48 PM, Kevin Rushforth wrote: > It probably makes sense to submit what you have now as a partially working > solution. > > As for Eclipse making any changes, I'm not sure there is a spec you could > point to ... we do some of the same magic that I'm sure other projects have > had to do w.r.t running tests: > > * We have test "shims" for white-box testing that we add into our modules > when running tests (this requires copying all of the class files for our > modules and adding the shim classes on top of that) > > * We build the tests separately (the tests are in a separate source set in > gradle) without a module-info so that they run in the unnamed module. This > allows them to access JUnit, etc., as well as any public package of any > module in the system. As such we need to explicitly list any internal > packages that they use from the module they are testing. These are listed > in src/test/addExports > > > -- Kevin > > > Nir Lisker wrote: > > Looks like I understood the problem. Eclipse does not support (yet) > multiple modules per project. Do you know any specifications I can point > them to to fix this properly? > > The current workaround would be to add 'requires' for all the modules > which are used in tests as well. This change is local and would be excluded > from webrevs. > > At this point I can either submit the partially fixed Eclipse files, which > work with main code fully and with test code only if the above fix is used; > or wait until Eclipse sorts it out. > > On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> >> >> Nir Lisker wrote: >> >> rt/modules/javafx.base/build/classes/main/javafx.base/ >>> rt/modules/javafx.base/src/main/java/ >> >> >> Why not rely on source first? >> >> >> Yes, that might work...you could try switching the order. >> >> >> >> Another question as I move along: there are imports >> from java.util.logging in base module, but the module-info doesn't >> require java.logging. How do I give access to these imports? >> >> >> The only references to java.util.logging are in the javafx.base unit >> tests, which are compiled and run in the unnamed modules (no >> module-info.java for the unit tests). >> >> -- Kevin >> >> >> >> On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> Oh, I see. You are pointing to the exploded modules for the JDK in >>> build/XXXXX/jdk rather than the JDK image in build/XXXXX/images/jdk. >>> >>> Yes, I think it would be preferable to both reverse the order and also >>> add in the location of the built class files. So the following order seems >>> best: >>> >>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>> rt/modules/javafx.base/src/main/java/ >>> jdk/modules/javafx.base >>> >>> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>> >>> This is what I mean: In the type /base/src/test/java/test/ >>> com/sun/javafx/collections/ListListenerHelperTest.java there are these >>> imports: >>> >>> import test.javafx.collections.MockListObserver; >>> import java.util.BitSet; >>> import javafx.beans.Observable; >>> >>> The first one is the one in FX: rt\modules\javafx.base\src >>> \test\java\test\javafx\collections\MockListObserver.java >>> The second one is in the referenced JDK which was built with >>> FX: jdk\modules\java.base\java\util\BitSet.class >>> The third one exists in both: >>> - in JFX it's in: rt\modules\javafx.base\src\mai >>> n\java\javafx\beans\Observable.java >>> - in the JDK it's in: jdk\modules\javafx.base\ja >>> vafx\beans\Observable.class >>> >>> Does the question make sense now? >>> >>> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> >>>> one in "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>> or the one in "jdk\modules\javafx.base\javaf >>>> x\beans\InvalidationListener.class"? >>>> >>>> >>>> Not sure I get what you mean. There isn't a jdk/modules/ directory >>>> created by the build. Perhaps this is an Eclipse construct that it uses to >>>> indicate the modules that are in the JDK that you are using? The FX build >>>> puts the class files in: >>>> >>>> rt/build/modular_sdk/modules/javafx.base/... >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Nir Lisker wrote: >>>> >>>> Another question: do imports of javafx.* packages point to the javafx >>>> source or to the jdk compilation? >>>> >>>> For example, in the base module, the type test.javafx.beans.InvalidationListenerMock >>>> imports javafx.beans.InvalidationListener (twice, by the way, along >>>> with Observable). Should the imported class be the one in >>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>> or the one in "jdk\modules\javafx.base\javaf >>>> x\beans\InvalidationListener.class"? >>>> >>>> Currently, the way it is in the Eclipse files is that the jdk .class >>>> files are imported first[1], but it seemed odd to me - if I work on 2 files >>>> which depend on each other they should see the changes in each other at >>>> once. >>>> >>>> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d12 >>>> 7c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before >>>> "src/main/java"), >>>> >>>> - Nir >>>> >>>> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> inline >>>>> >>>>> Nir Lisker wrote: >>>>> >>>>> Alright, cleaned that part. fxpackager build fails with an internal >>>>> NPE in Eclipse, so I'm going to leave that alone and all of the projects >>>>> that depends on it. >>>>> >>>>> Now that projects can be built there are errors in deeper levels: >>>>> >>>>> 1. All org.junit imports cannot be resolved. This causes tons of >>>>> errors in various test folders obviously. All the .classpath files use >>>>> >>>>> >>>>> >>>>> which is a jar distributed with Eclipse (in the plugins folder) with >>>>> version 4.12.0. Is this really where the imports are supposed to come from? >>>>> How does it work in Netbeans or IntelliJ? >>>>> >>>>> >>>>> For NetBeans we use their internal version of JUnit. I don't know >>>>> about IntelliJ (maybe someone else on the list can answer that). >>>>> >>>>> 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging" >>>>> there are imports of com.oracle.jrockit.jfr that can't be resolved. Where >>>>> are these located? >>>>> >>>>> >>>>> These classes used to be part of the JFR commercial feature in the >>>>> Oracle JDK. The java-jfr sources are obsolete and no longer built (and no >>>>> longer buildable), so you can safely remove it from your IDE files. I also >>>>> still see references to it in the netbeans/base project. I will file a bug >>>>> to remove this obsolete code and fix the NetBeans references at the same >>>>> time. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> Ah, I see. Then yes, just removing the old ones is fine. >>>>>> >>>>>> As for the larger question, unless there are dependencies on apps, >>>>>> you can assume that the only ones you care about are the ones created by >>>>>> "gradle sdk". >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Nir Lisker wrote: >>>>>> >>>>>> So this is why I was asking about the optional stuff: 'graphics' >>>>>> module has BOTH >>>>>> >>>>>> build/resources/jsl-decora >>>>>> build/resources/jsl-prism >>>>>> >>>>>> and >>>>>> >>>>>> build/gensrc/jsl-decora >>>>>> build/gensrc/jsl-prism >>>>>> >>>>>> That led me to think that when the new dependencies were added the >>>>>> old ones weren't removed. Those that weren't optional (like the /resources >>>>>> ones, which I removed) were easy to catch and we could have finished here. >>>>>> Those that are optional are not causing trouble even when missing because >>>>>> they are optional. >>>>>> >>>>>> gradle sdk does not create the ones which are marked optional that >>>>>> Iv'e surveyed, but I don't know if that's the only way they can be created. >>>>>> If I compare solely with gradle sdk then I can just remove whatever is >>>>>> missing on grounds that it's left over. >>>>>> >>>>>> - Nir >>>>>> >>>>>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth < >>>>>> kevin.rushforth at oracle.com> wrote: >>>>>> >>>>>>> One more thing about the specific path you mentioned as not being >>>>>>> there. >>>>>>> >>>>>>> >>>>>> path="build/resources/jsl-decora"/> >>>>>>> >>>>>> path="build/resources/jsl-prism"/> >>>>>>> >>>>>>> These are still being created by 'gradle sdk', but the path is wrong >>>>>>> (the files moved in JDK 9) and should be: >>>>>>> >>>>>>> build/gensrc/jsl-decora >>>>>>> build/gensrc/jsl-prism >>>>>>> >>>>>>> You might want to take that into account. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Kevin Rushforth wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Nir Lisker wrote: >>>>>>>> >>>>>>>>> Iv'e removed all the classpath dependencies that were causing >>>>>>>>> errors. I don't mind sorting out the rest of the files while at it, though >>>>>>>>> for that there are a few things I'm not sure about: >>>>>>>>> >>>>>>>>> 1. Some dependencies are marked as optional and as such they don't >>>>>>>>> cause errors, but they are still missing. Is it safe to remove them or is >>>>>>>>> it possible that they will be created as some point? >>>>>>>>> >>>>>>>> >>>>>>>> Some of them might be created...not sure without checking. I >>>>>>>> recommend running "gradle sdk" and then seeing if the dependencies are >>>>>>>> there. >>>>>>>> >>>>>>>> Examples are the 'base' module with "src/test/resources" and >>>>>>>>> "src/main/resources" optional dependencies, and 'controls' module has the >>>>>>>>> optional dependency "src/main/resources" commented out. >>>>>>>>> >>>>>>>> >>>>>>>> I see. You might as well leave them, but it probably doesn't matter. >>>>>>>> >>>>>>>> 2. Can I assume that all other dependencies are really needed? >>>>>>>>> (Eclipse won't complain about unused ones as far as I know.) >>>>>>>>> >>>>>>>> >>>>>>>> That seems best. >>>>>>>> >>>>>>>> 3. What are the formatting standards for XML (indentation, line >>>>>>>>> length...)? From a quick look I see different styles in different files. >>>>>>>>> >>>>>>>> >>>>>>>> For IDE files, we don't worry about formatting. In many cases they >>>>>>>> are auto-generated anyway. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>>> - Nir >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From john at status6.com Fri Feb 2 17:29:31 2018 From: john at status6.com (John Neffenger) Date: Fri, 2 Feb 2018 09:29:31 -0800 Subject: More community participation in JavaFX In-Reply-To: <5A73A220.7030706@oracle.com> References: <5A73A220.7030706@oracle.com> Message-ID: On 02/01/2018 03:26 PM, Kevin Rushforth wrote: > We are specifically looking to discuss ideas around the following areas: > > * Easing barriers to contribution (e.g., making JavaFX easier to build, > better documentation, making it easier to test changes) Thank you for asking. In my case, the barrier was not being able to upload images to a bug report or even add a comment to my own report after creating it. The specific bugs don't matter. I'm concerned about the process, because I've always ended up contributing to projects by finding some bug and being motivated enough to fix it. Bugs are the hooks that get me involved. So I spent a couple of months porting JavaFX to an ARM E-Ink device and found three bugs in the process. I lost enthusiasm, though, when I realized I had to get these bug reports: https://gitlab.com/groups/openjfxepd/-/issues into here: https://bugreport.java.com/ One of the reports has five images that illustrate the problem, but I see no way to add those. Worse yet, once I submit the report, my participation ends, and there's no record that I was involved at all. In other systems, from GNOME to Mozilla to Ubuntu, I can open a bug report directly, upload images, and participate in the discussion until it's closed. Of course, I will eventually submit those bug reports if they're not already fixed, but it takes just enough extra emotional effort -- giving up credit, control, and participation -- that I haven't. John From mp at jugs.org Fri Feb 2 17:37:14 2018 From: mp at jugs.org (Michael Paus) Date: Fri, 2 Feb 2018 18:37:14 +0100 Subject: More community participation in JavaFX In-Reply-To: References: <5A73A220.7030706@oracle.com> Message-ID: Hi, I fully agree with what you said with one exception. Via the bug report form it is possible to add any kind of attachments. So this is no problem. The rest is sadly true. Cheers Michael Am 02.02.18 um 18:29 schrieb John Neffenger: > On 02/01/2018 03:26 PM, Kevin Rushforth wrote: >> We are specifically looking to discuss ideas around the following areas: >> >> * Easing barriers to contribution (e.g., making JavaFX easier to >> build, better documentation, making it easier to test changes) > > Thank you for asking. In my case, the barrier was not being able to > upload images to a bug report or even add a comment to my own report > after creating it. > > The specific bugs don't matter. I'm concerned about the process, > because I've always ended up contributing to projects by finding some > bug and being motivated enough to fix it. Bugs are the hooks that get > me involved. > > So I spent a couple of months porting JavaFX to an ARM E-Ink device > and found three bugs in the process. I lost enthusiasm, though, when I > realized I had to get these bug reports: > > https://gitlab.com/groups/openjfxepd/-/issues > > into here: > > https://bugreport.java.com/ > > One of the reports has five images that illustrate the problem, but I > see no way to add those. Worse yet, once I submit the report, my > participation ends, and there's no record that I was involved at all. > > In other systems, from GNOME to Mozilla to Ubuntu, I can open a bug > report directly, upload images, and participate in the discussion > until it's closed. > > Of course, I will eventually submit those bug reports if they're not > already fixed, but it takes just enough extra emotional effort -- > giving up credit, control, and participation -- that I haven't. > > John From javasabr at gmail.com Fri Feb 2 17:54:26 2018 From: javasabr at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCR0YDRg9C5?=) Date: Fri, 2 Feb 2018 20:54:26 +0300 Subject: JavaFX embed API Message-ID: Hi everyone, Since Java 9 makes com.sun.javafx.embed.* unavailable. Some people use this internal API to integrate javaFX as GUI into some OpenGL based games. This API is a great thing to integrate javaFX with any other graphics frameworks/engines, so do you have any plans to make this internal API as public? From sdesofi at icloud.com Sat Feb 3 00:36:23 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Sat, 03 Feb 2018 00:36:23 +0000 (GMT) Subject: More community participation in JavaFX Message-ID: +1 It is not only games that would benefit from better graphics support, but also other areas such as?CAD/CAM or architectural drawing which is less spoken about but is also an?important part of the?graphics world as well. With Apple pushing for WebGPU and working with the W3C to make it a Web Standard and Khronos pushing Vulkan,?I see no reason Java FX should by intention become a laggard. Years ago Apple proposed the Canvas API and made it a Web standard and JavaFX adopted it. The FX Canvas and Web Canvas API?s are nearly identical. I see no reason why we can?t follow suit and once again and?make FX a great WebGPU platform. Apple is doing all the heavy lifting, why shouldn't FX follow?? Where else should JavaFX go? With new languages on the horizon like Dart, Swift, and TypScript, Java is getting competition and if we don?t keep up we will slowly become irrelevant. Over the years Java has gotten new Java language features, but it is falling?behind in it's ?graphics support. In the end it is not the syntax of the language that matters most, it is what?you can do with the language that matters. ? Just look at JavaScript for proof. ? It is a horrendous language but it's capabilities keep increasing?and so does it's usage. ? ?Soon browsers will have heavy graphics capabilities, and Swift will be everywhere. ? Dart is making serious inroads (in capability, not in usage). ? Why would a new?programmer?pick JavaFX as a starting point? Rather than starting off by declaring "Java is not for Games" we should instead aim to say "anything you can do with Swift, we can be done with?FX, and even better!". ? ? Apple's WebGPU will?become a winner. ? They are using the same winning formula they used the last time with Canvas. ? Just release it as a standard and declare "WE ARE APPLE". ? They are more powerful a company today than they were back then, so of course they will succeed. ? Will they be the only standard? ? Maybe not. ? The Web has SVG and Canvas. ? In the 3D world it will?have WebGPU and maybe Vulkan, although there are serious reasons to question Vulkan's success. ? SVG and Canvas are really two different technologies. ? WebGPU and Vulkan are just two different API's to the same technology. ? ?I'll bet on Apple. ? They have already made it a W3C working group,?and the world doesn't need two different API's to the same technology. ? Apple will win. I have limited time for projects, ?and I also have a day job. ?At night I am doing a lot of graphics work using both Web Canvas and JavaFX Canvas. ? ? Soon I will have to make a decision. ? ?Will it be Web Graphics plus Java or Web Graphics plus Swift. ? ?Swift is getting a clearer roadmap. ? JavaFX is declaring itself out of the game. ?(no pun intended) I have not contributed time to the FX platform, but would love to, but I have to be assured that JavaFX has a future. ? If I feel this way, how many others feel the same way as I do? You mentioned planning for the next 10 years. ? ?What will JavaFX look like in 10 years without serious graphics support? ? ?Without it, I don't think JavaFX will?exist. ? ?Other platforms will have past us by. Steve Desofi Sent from iCloud On Feb 02, 2018, at 05:15 AM, Paul Ray Russell wrote: Yeah - I looked at the windows build process recently - which was enough to dissuade me from starting. I do know JavaFX fairly well, and have a potted history working in software companies. I'd like to get on-board once I finish my current game. I'd be interested in game related areas; but realise these may not be areas of development that JavaFX was ever intended, or *will* ever be directed to cover. That would be another whole conversation to have. If it's the case that JavaFX is to remain a GUI toolkit, with v. limited graphics abilities: something useful for front-ending business apps, but not much more, then it needs to be made clearer that this is the aim. The games community has grown despondent about JavaFX as a framework, which is a shame. I see evidence of this scattered all over the web. Too many abandoned projects from 2013 era. It's all bit depressing. It's such a great framework. On 2 February 2018 at 00:07, 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. More community participation in JavaFX (Kevin Rushforth) 2. Re: More community participation in JavaFX (Michael Ennen) 3. Re: More community participation in JavaFX (Richard Steiger) ---------------------------------------------------------------------- Message: 1 Date: Thu, 01 Feb 2018 15:26:24 -0800 From: Kevin Rushforth To: "openjfx-dev at openjdk.java.net" Subject: More community participation in JavaFX Message-ID: <5A73A220.7030706 at oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed To: OpenJFX Developers We are looking to grow the community of contributors to the OpenJFX project, especially serious contributors who will stick around long enough to become reviewers, to help us keep the platform vibrant. To this end we are looking at ways to encourage more participation and make it easier for interested folks to contribute. We are specifically looking to discuss ideas around the following areas: * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) * Code review policies * API / feature review policies * Code review tools (we currently use webrev, but that isn't set in stone) To keep this thread productive, the following are explicitly out of scope: * Discussion of specific features or bugs that you would like to implement (or wish someone else would) * Discussion about platform support * Discussion about version control systems (e.g., hg versus git), hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus github), etc...at least for now. We are aware of the potential benefits of such changes, but we'd like to focus our efforts on higher-leverage things we can do in the short term. * Discussion about the requirement of a signed OCA to become a contributor * Off-topic or tangential commentary about OpenJFX that isn't directly related to the topic at hand As a starting point for discussion, here are some areas I think need improvement; I'm sure there are others: I. Helping contributors get started It isn?t as easy to get started with OpenJFX as it should be. We want to make it easier for potential OpenJFX contributors to get started. Here are some ideas that I think might help: * Improve the build instructions / Wiki (I made a first start, but there is much more to be done) * Make the build itself more resilient where possible, and provide better error messages, specifically when dealing with native compilers and libraries * Add an option to skip building all native code and use prebuilt binaries (like we do already for media and webkit); this is tracked by JDK-8092279, but it hasn?t been looked at recently * Make it easier to build / test your local OpenJFX build using an OpenJDK build (currently the only way to do this is to build OpenJDK locally, after using configure to point to your just-built javafx.* modules). * Provide step-by-step instructions for how to make a contribution, including testing requirements; a lot of the pieces are there, but are out of date or scattered in several places. As part of this, we could have a section on how to contribute docs, samples or tests, since that is often a good place to start. * Provide a sandbox environment where contributors can discuss and test ideas. For example, an OpenJFX mirror on github, potentially connected to AdoptOpenJDK. II. Code reviews and API reviews Code reviews are important to maintain high-quality contributions, but we recognize that not every type of change needs the same level of review. Without lowering our standards of quality, we want to make it easier to get low-impact changes (simple bug fixes) accepted. There are three categories of changes, each of which might merit a different review standard: 1. Low-impact bug fixes. These are typically isolated bug fixes with little or no impact beyond fixing the bug in question; included in this category are test fixes (including new tests) doc fixes, and fixes to sample applications (including new samples). 2. Higher impact bug fixes or RFEs. These include changes to the implementation that potentially have a performance or behavioral impact, or are otherwise broad in scope. Some larger bug fixes will fall into this category, as will fixes in high-risk areas (e.g., CSS). 3. New features / API additions. In addition to reviewing the implementation, we will need a separate approval process for the new API / feature (such as the CSR, which is what we use now, or a similar process). We take compatibility seriously, so anything that adds new API needs to be done with an eye towards supporting it for at least 10 years. We don't want to add new public API without that level of commitment. Every new feature forecloses on alternate future features. Significant effort must be taken to think about "if we did this, what could it interact with in the future?" Also, anything with a large potential impact on performance or behavioral compatibility needs to be looked at carefully. Put another way, we want to encourage thinking about new features or new API in terms of a design / stewardship process; to think in terms of questions like "what's the right thing for JavaFX in the next 10+ years" rather than "here's some code that solves my problem, please take it". As a stake in the ground, I might suggest the following: * All changes need at least one reviewer other than the person making the change who can evaluate the change for correctness and consistency. For simple bug fixes, a single reviewer may be sufficient. Of course, one of our big challenges in all this is: "how do we grow more reviewers?", by which I mean "how do we facilitate getting contributors with enough expertise in a given area to eventually be able to effectively review contributions from others?" * We need clear criteria for the other two categories that balance process efficiency with the desire to maintain compatibility and stability. API changes need to be approved by a lead. My thought is to combine the last two into a single category for purposes of reviewing the implementation. Anything that affects public API or behavioral compatibility will require CSR or similar approval, over and above the implementation review, which seems sufficient. * I recommend that we formalize the concept of reviewers, using the OpenJDK Reviewer role for the Project. We might also consider if we want to make any changes to the criteria used by the JDK Project for becoming an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK bylaws allow projects a fair degree of latitude to define these criteria, so we might consider making some modifications. For example, we might make it somewhat easier for a Contributor to become an Author, or for a Committer to become a Reviewer. I have some thoughts on this, but want to hear from others first. I look forward to feedback on this proposal, and hope it will spark a productive discussion. -- Kevin Rushforth, OpenJFX Project Lead ------------------------------ Message: 2 Date: Thu, 1 Feb 2018 16:58:52 -0700 From: Michael Ennen To: Kevin Rushforth Cc: "openjfx-dev at openjdk.java.net" Subject: Re: More community participation in JavaFX Message-ID: Content-Type: text/plain; charset="UTF-8" I think that having a public sandbox mirror on GitHub, as you mentioned, is a great idea. The idea is that PRs could be opened and the test suites could be run using CI for the platforms supported by JavaFX. The PR itself would never be directly merged into the OpenJFX hg repository. Instead the PR would be a launching point that provides a means for review and feedback. Once all feedback is taken into account, the PR can be marked as "Ready" which means it is ready to move up to the more formal review processes already in place. Automating the creation of a webrev for the PR, as well as converting the git PR to a mercurial one would make the process streamlined and efficient. I only mention GitHub because I think it would allow for the smallest barrier of entry and cast the widest net of potential contributors. Setting up this mirroring infrastructure wouldn't be a simple task but it is very doable IMO. I messed around with creating Travis and Appveyor CI builds for openjfx and besides running up against a 45 minute time limit I didn't encounter any show-stoppers. I believe we need such a sandbox to act as a "staging ground" or an adapter between the high barrier to entry and first-time or new contributions. The only way it would work, in my opinion, is that there is a vibrant community of reviewers who, in their free time, help get the PRs in shape to move to the next level (which is the more formal processes that already exist, as you mentioned). Thanks for starting this important discussion, Kevin. -- Michael Ennen On Thu, Feb 1, 2018 at 4:26 PM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > To: OpenJFX Developers > > We are looking to grow the community of contributors to the OpenJFX > project, especially serious contributors who will stick around long enough > to become reviewers, to help us keep the platform vibrant. To this end we > are looking at ways to encourage more participation and make it easier for > interested folks to contribute. > > We are specifically looking to discuss ideas around the following areas: > > * Easing barriers to contribution (e.g., making JavaFX easier to build, > better documentation, making it easier to test changes) > > * Code review policies > > * API / feature review policies > > * Code review tools (we currently use webrev, but that isn't set in stone) > > > To keep this thread productive, the following are explicitly out of scope: > > * Discussion of specific features or bugs that you would like to implement > (or wish someone else would) > > * Discussion about platform support > > * Discussion about version control systems (e.g., hg versus git), hosting > of the OpenJFX repos and bug database (e.g., OpenJDK versus github), > etc...at least for now. We are aware of the potential benefits of such > changes, but we'd like to focus our efforts on higher-leverage things we > can do in the short term. > > * Discussion about the requirement of a signed OCA to become a contributor > > * Off-topic or tangential commentary about OpenJFX that isn't directly > related to the topic at hand > > > As a starting point for discussion, here are some areas I think need > improvement; I'm sure there are others: > > I. Helping contributors get started > > It isn?t as easy to get started with OpenJFX as it should be. We want to > make it easier for potential OpenJFX contributors to get started. Here are > some ideas that I think might help: > > * Improve the build instructions / Wiki (I made a first start, but there > is much more to be done) > > * Make the build itself more resilient where possible, and provide better > error messages, specifically when dealing with native compilers and > libraries > > * Add an option to skip building all native code and use prebuilt binaries > (like we do already for media and webkit); this is tracked by JDK-8092279, > but it hasn?t been looked at recently > > * Make it easier to build / test your local OpenJFX build using an OpenJDK > build (currently the only way to do this is to build OpenJDK locally, after > using configure to point to your just-built javafx.* modules). > > * Provide step-by-step instructions for how to make a contribution, > including testing requirements; a lot of the pieces are there, but are out > of date or scattered in several places. As part of this, we could have a > section on how to contribute docs, samples or tests, since that is often a > good place to start. > > * Provide a sandbox environment where contributors can discuss and test > ideas. For example, an OpenJFX mirror on github, potentially connected to > AdoptOpenJDK. > > > II. Code reviews and API reviews > > Code reviews are important to maintain high-quality contributions, but we > recognize that not every type of change needs the same level of review. > Without lowering our standards of quality, we want to make it easier to get > low-impact changes (simple bug fixes) accepted. > > There are three categories of changes, each of which might merit a > different review standard: > > 1. Low-impact bug fixes. These are typically isolated bug fixes with > little or no impact beyond fixing the bug in question; included in this > category are test fixes (including new tests) doc fixes, and fixes to > sample applications (including new samples). > > 2. Higher impact bug fixes or RFEs. These include changes to the > implementation that potentially have a performance or behavioral impact, or > are otherwise broad in scope. Some larger bug fixes will fall into this > category, as will fixes in high-risk areas (e.g., CSS). > > 3. New features / API additions. In addition to reviewing the > implementation, we will need a separate approval process for the new API / > feature (such as the CSR, which is what we use now, or a similar process). > > We take compatibility seriously, so anything that adds new API needs to be > done with an eye towards supporting it for at least 10 years. We don't want > to add new public API without that level of commitment. Every new feature > forecloses on alternate future features. Significant effort must be taken > to think about "if we did this, what could it interact with in the future?" > Also, anything with a large potential impact on performance or behavioral > compatibility needs to be looked at carefully. > > Put another way, we want to encourage thinking about new features or new > API in terms of a design / stewardship process; to think in terms of > questions like "what's the right thing for JavaFX in the next 10+ years" > rather than "here's some code that solves my problem, please take it". > > > As a stake in the ground, I might suggest the following: > > * All changes need at least one reviewer other than the person making the > change who can evaluate the change for correctness and consistency. For > simple bug fixes, a single reviewer may be sufficient. Of course, one of > our big challenges in all this is: "how do we grow more reviewers?", by > which I mean "how do we facilitate getting contributors with enough > expertise in a given area to eventually be able to effectively review > contributions from others?" > > * We need clear criteria for the other two categories that balance process > efficiency with the desire to maintain compatibility and stability. API > changes need to be approved by a lead. My thought is to combine the last > two into a single category for purposes of reviewing the implementation. > Anything that affects public API or behavioral compatibility will require > CSR or similar approval, over and above the implementation review, which > seems sufficient. > > * I recommend that we formalize the concept of reviewers, using the > OpenJDK Reviewer role for the Project. We might also consider if we want to > make any changes to the criteria used by the JDK Project for becoming an > OpenJFX Project Author, Committer, and Reviewer. The OpenJDK bylaws allow > projects a fair degree of latitude to define these criteria, so we might > consider making some modifications. For example, we might make it somewhat > easier for a Contributor to become an Author, or for a Committer to become > a Reviewer. I have some thoughts on this, but want to hear from others > first. > > > I look forward to feedback on this proposal, and hope it will spark a > productive discussion. > > -- Kevin Rushforth, OpenJFX Project Lead > > ------------------------------ Message: 3 Date: Thu, 1 Feb 2018 16:03:06 -0800 From: Richard Steiger To: openjfx-dev at openjdk.java.net Subject: Re: More community participation in JavaFX Message-ID: Content-Type: text/plain; charset=windows-1252; format=flowed Hi Kevin, As a long-time observer of the OpenJFX project, let me put all my chips at this point on making builds more stable, bullet-proof, and automated, and give equal weight making them so on Win10 and OS/X, specifically, the same weight as is given to making building and developing on Linux work well. Over the last 3 or so years, on at least 3 separate occasions, I've gotten a head of inspirational steam to try-out some new features (the latest being using byte-code engineering to radically streamline binding, rendering most of the current API obsolete, and hugely improving performance).? I then attempt to build the whole project from sources (not always required, but essential when it is) on Win10, my development platform of choice, and invariably get wound around the axel of no-longer published VS tooling, missing binaries, and other show-stopper glitches. Like many potential contributors, I've got a day job, plus am trying to launch a garage startup, so my time is a very scarce resource.? I simply don't have the extra cycles to troubleshoot highly convoluted builds (of which OpenJFX is one of the worst I've seen), so my head of steam bleeds-off for another year or so.? Nor am I willing to switch to a Linux development environment, remap my motor memory, take-on care and feeding of another platform (Windows and OS/X suck enough time, and are essential for my business).? Every time I've hit this wall, I've puzzled over how the team has tolerated the situation, and moved on. So, to be redundant, all the other issues you've so cogently enumerated pale in the face of development portability, starting with build stability and cleanliness on widely-used platforms. Thanks for considering the above input. -rjs On 2/1/18 3:26 PM, Kevin Rushforth wrote: > To: OpenJFX Developers > > We are looking to grow the community of contributors to the OpenJFX > project, especially serious contributors who will stick around long > enough to become reviewers, to help us keep the platform vibrant. To > this end we are looking at ways to encourage more participation and > make it easier for interested folks to contribute. > > We are specifically looking to discuss ideas around the following areas: > > * Easing barriers to contribution (e.g., making JavaFX easier to > build, better documentation, making it easier to test changes) > > * Code review policies > > * API / feature review policies > > * Code review tools (we currently use webrev, but that isn't set in > stone) > > > To keep this thread productive, the following are explicitly out of > scope: > > * Discussion of specific features or bugs that you would like to > implement (or wish someone else would) > > * Discussion about platform support > > * Discussion about version control systems (e.g., hg versus git), > hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus > github), etc...at least for now. We are aware of the potential > benefits of such changes, but we'd like to focus our efforts on > higher-leverage things we can do in the short term. > > * Discussion about the requirement of a signed OCA to become a > contributor > > * Off-topic or tangential commentary about OpenJFX that isn't directly > related to the topic at hand > > > As a starting point for discussion, here are some areas I think need > improvement; I'm sure there are others: > > I. Helping contributors get started > > It isn?t as easy to get started with OpenJFX as it should be. We want > to make it easier for potential OpenJFX contributors to get started. > Here are some ideas that I think might help: > > * Improve the build instructions / Wiki (I made a first start, but > there is much more to be done) > > * Make the build itself more resilient where possible, and provide > better error messages, specifically when dealing with native compilers > and libraries > > * Add an option to skip building all native code and use prebuilt > binaries (like we do already for media and webkit); this is tracked by > JDK-8092279, but it hasn?t been looked at recently > > * Make it easier to build / test your local OpenJFX build using an > OpenJDK build (currently the only way to do this is to build OpenJDK > locally, after using configure to point to your just-built javafx.* > modules). > > * Provide step-by-step instructions for how to make a contribution, > including testing requirements; a lot of the pieces are there, but are > out of date or scattered in several places. As part of this, we could > have a section on how to contribute docs, samples or tests, since that > is often a good place to start. > > * Provide a sandbox environment where contributors can discuss and > test ideas. For example, an OpenJFX mirror on github, potentially > connected to AdoptOpenJDK. > > > II. Code reviews and API reviews > > Code reviews are important to maintain high-quality contributions, but > we recognize that not every type of change needs the same level of > review. Without lowering our standards of quality, we want to make it > easier to get low-impact changes (simple bug fixes) accepted. > > There are three categories of changes, each of which might merit a > different review standard: > > 1. Low-impact bug fixes. These are typically isolated bug fixes with > little or no impact beyond fixing the bug in question; included in > this category are test fixes (including new tests) doc fixes, and > fixes to sample applications (including new samples). > > 2. Higher impact bug fixes or RFEs. These include changes to the > implementation that potentially have a performance or behavioral > impact, or are otherwise broad in scope. Some larger bug fixes will > fall into this category, as will fixes in high-risk areas (e.g., CSS). > > 3. New features / API additions. In addition to reviewing the > implementation, we will need a separate approval process for the new > API / feature (such as the CSR, which is what we use now, or a similar > process). > > We take compatibility seriously, so anything that adds new API needs > to be done with an eye towards supporting it for at least 10 years. We > don't want to add new public API without that level of commitment. > Every new feature forecloses on alternate future features. Significant > effort must be taken to think about "if we did this, what could it > interact with in the future?" Also, anything with a large potential > impact on performance or behavioral compatibility needs to be looked > at carefully. > > Put another way, we want to encourage thinking about new features or > new API in terms of a design / stewardship process; to think in terms > of questions like "what's the right thing for JavaFX in the next 10+ > years" rather than "here's some code that solves my problem, please > take it". > > > As a stake in the ground, I might suggest the following: > > * All changes need at least one reviewer other than the person making > the change who can evaluate the change for correctness and > consistency. For simple bug fixes, a single reviewer may be > sufficient. Of course, one of our big challenges in all this is: "how > do we grow more reviewers?", by which I mean "how do we facilitate > getting contributors with enough expertise in a given area to > eventually be able to effectively review contributions from others?" > > * We need clear criteria for the other two categories that balance > process efficiency with the desire to maintain compatibility and > stability. API changes need to be approved by a lead. My thought is to > combine the last two into a single category for purposes of reviewing > the implementation. Anything that affects public API or behavioral > compatibility will require CSR or similar approval, over and above the > implementation review, which seems sufficient. > > * I recommend that we formalize the concept of reviewers, using the > OpenJDK Reviewer role for the Project. We might also consider if we > want to make any changes to the criteria used by the JDK Project for > becoming an OpenJFX Project Author, Committer, and Reviewer. The > OpenJDK bylaws allow projects a fair degree of latitude to define > these criteria, so we might consider making some modifications. For > example, we might make it somewhat easier for a Contributor to become > an Author, or for a Committer to become a Reviewer. I have some > thoughts on this, but want to hear from others first. > > > I look forward to feedback on this proposal, and hope it will spark a > productive discussion. > > -- Kevin Rushforth, OpenJFX Project Lead > End of openjfx-dev Digest, Vol 75, Issue 4 ****************************************** From kevin.rushforth at oracle.com Sat Feb 3 01:51:18 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 02 Feb 2018 17:51:18 -0800 Subject: More community participation in JavaFX In-Reply-To: <5A73A220.7030706@oracle.com> References: <5A73A220.7030706@oracle.com> Message-ID: <5A751596.9090001@oracle.com> Looks like we have some good discussion so far. I see a few themes emerging (build/test, sandbox on GitHub, ease of filing bugs, etc) along with some discussion on graphics performance (which is fine as long as the discussion doesn't veer too far into discussing specific graphics features). I'll let more folks chime in before I reply to anything specifically (and I'll be offline over the weekend anyway). Thanks! -- Kevin From sdesofi at icloud.com Sat Feb 3 03:07:39 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Fri, 02 Feb 2018 22:07:39 -0500 Subject: More community participation in JavaFX In-Reply-To: <5A751596.9090001@oracle.com> References: <5A73A220.7030706@oracle.com> <5A751596.9090001@oracle.com> Message-ID: <37E192A9-6349-40E6-B481-2AFF728D52C3@icloud.com> I don?t understand why discussing new graphics capabilities such as gaming or WebGPU, etc is so off limits. Can you explain that? Steve Desofi Sent from my iPhone > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth wrote: > > Looks like we have some good discussion so far. > > I see a few themes emerging (build/test, sandbox on GitHub, ease of filing bugs, etc) along with some discussion on graphics performance (which is fine as long as the discussion doesn't veer too far into discussing specific graphics features). > > I'll let more folks chime in before I reply to anything specifically (and I'll be offline over the weekend anyway). > > Thanks! > > -- Kevin > From johnvalrose at gmail.com Sat Feb 3 04:55:32 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 3 Feb 2018 15:55:32 +1100 Subject: More community participation in JavaFX In-Reply-To: <37E192A9-6349-40E6-B481-2AFF728D52C3@icloud.com> References: <5A73A220.7030706@oracle.com> <5A751596.9090001@oracle.com> <37E192A9-6349-40E6-B481-2AFF728D52C3@icloud.com> Message-ID: I think Kevin outlined in his opening post what would be considered "out of scope". However, I agree with you on the basic premise that, in general, the bar has been set way too low as to the potential use cases and performance of JavaFX. In fact, I firmly believe that games & complex visualisations etc. *should* be possible with JavaFX given that most of the heavy lifting is being done by the GPU. It's just that, at the moment, the scene graph rendering pipeline is significantly slower than it could be and it is for this reason that we don't find applications using advanced 3D graphics & animations etc. (like we see in games) being built with JavaFX. It's just not possible when the node count reaches even a very small threshold. This is a topic I have tried to discuss numerous times and also believe that I can improve the performance of the scene graph rendering in a very tangible way. If things pan-out as they are being described and becoming & being a contributor is simplified to the extent where it justifies me devoting a large chunk of my time to OpenJFX, this is probably what I would want to work on first. ?? Graciously, John-Val Rose On 3 February 2018 at 14:07, Stephen Desofi wrote: > I don?t understand why discussing new graphics capabilities such as gaming > or WebGPU, etc is so off limits. Can you explain that? > > Steve Desofi > > Sent from my iPhone > > > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth > wrote: > > > > Looks like we have some good discussion so far. > > > > I see a few themes emerging (build/test, sandbox on GitHub, ease of > filing bugs, etc) along with some discussion on graphics performance (which > is fine as long as the discussion doesn't veer too far into discussing > specific graphics features). > > > > I'll let more folks chime in before I reply to anything specifically > (and I'll be offline over the weekend anyway). > > > > Thanks! > > > > -- Kevin > > > From rajath.kamath at oracle.com Sat Feb 3 06:03:34 2018 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Fri, 2 Feb 2018 22:03:34 -0800 (PST) Subject: [11] Review Request - JDK-8196615: Skip 3D unit tests on system without 3D capability Message-ID: <775aa27b-3c48-4c07-99a3-fb36902efeae@default> Hi Kevin,Murali, Please review this fix for skipping 3D tests on systems with missing hardware support. JBS : https://bugs.openjdk.java.net/browse/JDK-8196615 WebRev : http://cr.openjdk.java.net/~rkamath/8196615/webrev.00/ Thanks, Rajath From sdesofi at icloud.com Sat Feb 3 13:18:55 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Sat, 03 Feb 2018 08:18:55 -0500 Subject: More community participation in JavaFX In-Reply-To: References: <5A73A220.7030706@oracle.com> <5A751596.9090001@oracle.com> <37E192A9-6349-40E6-B481-2AFF728D52C3@icloud.com> Message-ID: <7B21C534-2B56-4CBB-B32F-E91249B6AD44@icloud.com> This begs the question, why has the bar been set too low? I am new to this community and don?t know much history other than a couple weeks of bug fix messages flying by. I am not even clear of what our role and purpose is supposed to be. Are we here for only bug fixes, and follow the direction and flow that is already set, or as contributors would we be allowed to contribute to the goals and direction of JavaFX? FX is a good platform with great potential, but it biggest deficiency is ?mind share?. People don?t see too many real world accomplishments that knock your socks off. Most people use web and phone to run apps. PC and Desktop apps are a small part of the market. Gluon has just recently released gluon VM and Gluon Mobile to allow FX on phones and tablets. The problem I see is once I can use FX on phones how will it compete with Swift? True that ?write once, run everywhere? is important and Java has a lead over Swift. But Swift has a lead on capability. In the end Swift will catch up with Java in the ?write once, run anywhere? mantra. Will FX catch up with Swift in graphics by then? Java has a lead in many areas, but if we look 10 years out, it seems clear to me that Java needs to raise the bar or face extinction as a client side development platform or forever be confined to the server. This is why I need some clarification as to what our role as contributors is going to be. I don?t believe an open source project can flourish if the contributors have no say or stake in the direction. Steve Desofi Sent from my iPhone > On Feb 2, 2018, at 11:55 PM, John-Val Rose wrote: > > I think Kevin outlined in his opening post what would be considered "out of scope". > > However, I agree with you on the basic premise that, in general, the bar has been set way too low as to the potential use cases and performance of JavaFX. In fact, I firmly believe that games & complex visualisations etc. *should* be possible with JavaFX given that most of the heavy lifting is being done by the GPU. It's just that, at the moment, the scene graph rendering pipeline is significantly slower than it could be and it is for this reason that we don't find applications using advanced 3D graphics & animations etc. (like we see in games) being built with JavaFX. It's just not possible when the node count reaches even a very small threshold. > > This is a topic I have tried to discuss numerous times and also believe that I can improve the performance of the scene graph rendering in a very tangible way. > > If things pan-out as they are being described and becoming & being a contributor is simplified to the extent where it justifies me devoting a large chunk of my time to OpenJFX, this is probably what I would want to work on first. > > ??Graciously, > > John-Val Rose > >> On 3 February 2018 at 14:07, Stephen Desofi wrote: >> I don?t understand why discussing new graphics capabilities such as gaming or WebGPU, etc is so off limits. Can you explain that? >> >> Steve Desofi >> >> Sent from my iPhone >> >> > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth wrote: >> > >> > Looks like we have some good discussion so far. >> > >> > I see a few themes emerging (build/test, sandbox on GitHub, ease of filing bugs, etc) along with some discussion on graphics performance (which is fine as long as the discussion doesn't veer too far into discussing specific graphics features). >> > >> > I'll let more folks chime in before I reply to anything specifically (and I'll be offline over the weekend anyway). >> > >> > Thanks! >> > >> > -- Kevin >> > > From bourges.laurent at gmail.com Sat Feb 3 17:07:49 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 3 Feb 2018 18:07:49 +0100 Subject: More community participation in JavaFX In-Reply-To: References: <5A73A220.7030706@oracle.com> <2866034b02b2dace60f510815d1b995a.squirrel@excalibur.xssl.net> Message-ID: Hi Chris, I'm more than happy to keep the community JavaFX build server at chriswhocodes.com running and host JDK 8/9/10/n + FX builds there. At the moment it's mostly used by the Raspberry Pi community to grab JavaFX overlays for JDK8 on ARM. I can also build and host OSX and Windows builds there once the build instructions are updated. Excellent but we should discuss with adoptopenjdk or you how to build & provide OpenJFX release more widely... I would definitely love having an openjfx github mirror and use any CI (travis ?) to submit patches & obtain build & test results. Graal compiler is already on github, why not openjfx ? At least to prepare openjfx patches and broaden the community contributions. However you are focused on jdk8, so we could try providing MarlinFX too on jdk8 builds too if it may interest users. However we should avoid providing too many custom builds... users will be lost by the diversity: we should find a single place to host OpenJFX EA builds. Lastly I'd also be interested in profiling and contributing performance enhancements to the FX Java source code based on JIT analysis. IMO it would be useful if the OpenJFX team would make a statement on what kind of contributions fit with their overall vision (e.g. increasing performance vs bug fixing desktop widgets). Please go on, any perf improvement is great (and help saving our planet) ! PS: big thanks for JITWatch ! Kindly regards, Laurent From johnvalrose at gmail.com Sat Feb 3 20:08:45 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Sun, 4 Feb 2018 07:08:45 +1100 Subject: More community participation in JavaFX In-Reply-To: <7B21C534-2B56-4CBB-B32F-E91249B6AD44@icloud.com> References: <5A73A220.7030706@oracle.com> <5A751596.9090001@oracle.com> <37E192A9-6349-40E6-B481-2AFF728D52C3@icloud.com> <7B21C534-2B56-4CBB-B32F-E91249B6AD44@icloud.com> Message-ID: <8EB72F5B-8845-47C9-97AB-DF61F7ECC44A@gmail.com> Stephen - I?m not quite following you. This thread is about improving the ease with which the community can contribute to JavaFX. I see no point in comparing JavaFX (a cross platform graphics toolkit for JVM languages) with a Swift (a general purpose programming language that runs on Apple hardware). > On 4 Feb 2018, at 00:18, Stephen Desofi wrote: > > This begs the question, why has the bar been set too low? I am new to this community and don?t know much history other than a couple weeks of bug fix messages flying by. > > I am not even clear of what our role and purpose is supposed to be. Are we here for only bug fixes, and follow the direction and flow that is already set, or as contributors would we be allowed to contribute to the goals and direction of JavaFX? > > FX is a good platform with great potential, but it biggest deficiency is ?mind share?. People don?t see too many real world accomplishments that knock your socks off. Most people use web and phone to run apps. PC and Desktop apps are a small part of the market. > > Gluon has just recently released gluon VM and Gluon Mobile to allow FX on phones and tablets. > > The problem I see is once I can use FX on phones how will it compete with Swift? > > True that ?write once, run everywhere? is important and Java has a lead over Swift. But Swift has a lead on capability. > > In the end Swift will catch up with Java in the ?write once, run anywhere? mantra. Will FX catch up with Swift in graphics by then? > > Java has a lead in many areas, but if we look 10 years out, it seems clear to me that Java needs to raise the bar or face extinction as a client side development platform or forever be confined to the server. > > This is why I need some clarification as to what our role as contributors is going to be. I don?t believe an open source project can flourish if the contributors have no say or stake in the direction. > > Steve Desofi > > > > > > Sent from my iPhone > >> On Feb 2, 2018, at 11:55 PM, John-Val Rose wrote: >> >> I think Kevin outlined in his opening post what would be considered "out of scope". >> >> However, I agree with you on the basic premise that, in general, the bar has been set way too low as to the potential use cases and performance of JavaFX. In fact, I firmly believe that games & complex visualisations etc. *should* be possible with JavaFX given that most of the heavy lifting is being done by the GPU. It's just that, at the moment, the scene graph rendering pipeline is significantly slower than it could be and it is for this reason that we don't find applications using advanced 3D graphics & animations etc. (like we see in games) being built with JavaFX. It's just not possible when the node count reaches even a very small threshold. >> >> This is a topic I have tried to discuss numerous times and also believe that I can improve the performance of the scene graph rendering in a very tangible way. >> >> If things pan-out as they are being described and becoming & being a contributor is simplified to the extent where it justifies me devoting a large chunk of my time to OpenJFX, this is probably what I would want to work on first. >> >> ??Graciously, >> >> John-Val Rose >> >>> On 3 February 2018 at 14:07, Stephen Desofi wrote: >>> I don?t understand why discussing new graphics capabilities such as gaming or WebGPU, etc is so off limits. Can you explain that? >>> >>> Steve Desofi >>> >>> Sent from my iPhone >>> >>> > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth wrote: >>> > >>> > Looks like we have some good discussion so far. >>> > >>> > I see a few themes emerging (build/test, sandbox on GitHub, ease of filing bugs, etc) along with some discussion on graphics performance (which is fine as long as the discussion doesn't veer too far into discussing specific graphics features). >>> > >>> > I'll let more folks chime in before I reply to anything specifically (and I'll be offline over the weekend anyway). >>> > >>> > Thanks! >>> > >>> > -- Kevin >>> > >> From sdesofi at icloud.com Sun Feb 4 01:58:01 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Sun, 04 Feb 2018 01:58:01 +0000 (GMT) Subject: More community participation in JavaFX Message-ID: <5d02482f-5ab0-49f1-a6d3-0fc4a3310a5b@me.com> John, ? ? ?The point I am making is that Swift is catching up as a cross platform toolkit and is available on: Mac and iOS, (Full Support) https://www.swift.org Android (early) https://academy.realm.io/posts/swift-on-android/ Linux: ?(early) https://itsfoss.com/use-swift-linux/ Windows: (early) https://www.infoworld.com/article/3067364/open-source-tools/swift-for-windows-arrives-at-last-but-as-an-unofficial-port.html Browser: ?(very Preliminary) https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly Server Side: ?(Mac and Linux) https://www.swift.org So my point is that soon Swift will steal the Cross Platform Mantra from Java. ? It is happening very quickly and Swift has great graphics and gaming capabilities as well. Why would a new developer start with?Java? ? ?If we are looking 10 years out, I think Apple is coming head on. Also when you say this thread is about the ease with which the community can contribute to JavaFX, it begs the question "what kinds of contribution?". ? ?Are we here to push the platform forward and contribute new ideas or just do bug fixes? Swift is a real threat to Java being the cross platform development King. ? ?Java can hold on to that story for only a couple more years. ?It surely won't last. Dart also runs on Android and iOS via Flutter, has Server side Dart option, runs in the Browser very well today with full support for SVG and Canvas -- and if WebGPU becomes a Web standard, Google will most certainly support it. Looking toward the future, if Java doesn't run in the browser, doesn't support games on any platform, and only works on iOS and Android via Gluon VM, and does it with only limited graphics capability, ?then I think JavaFX?will be a tough sell in the future. ? Even tougher than it is today.? If the point of the discussion is to build the developer community, I think we first need a compelling story as to why developers should join and contribute. The fact that I am using Dart and JavaFX, and I am seriously considering?if I should switch to Dart everywhere, or to Dart and Swift (instead of Dart and FX)?means JavaFX doesn't have the lead we think it does. ? ?I love JavaFX and would love to contribute, but it's hard when I myself am looking at other options mainly because I also want my software to be here 10 years from now, and I am seriously questioning if JavaFX will keep up. I think there is a small window of opportunity for JavaFX to make a stand before it is permanently relegated to a Server side language. ? This cross platform story won't fly too much longer, especially when Swift starts to run everywhere and in the browser too, and if Google does the same thing with Dart, and they?both support games, where will Java be? If we are looking 10 years out?then surely this will happen. ? The big question is what will we do, and where will JavaFX be? Steve Desofi On Feb 03, 2018, at 03:09 PM, John-Val Rose wrote: Stephen - I?m not quite following you. This thread is about improving the ease with which the community can contribute to JavaFX. I see no point in comparing JavaFX (a cross platform graphics toolkit for JVM languages) with a Swift (a general purpose programming language that runs on Apple hardware). On 4 Feb 2018, at 00:18, Stephen Desofi wrote: This begs the question, ?why has the bar been set too low? ? I am new to this community and don?t know much history other than a couple weeks of bug fix messages flying by. ?? I am not even clear of what our role and purpose is supposed to be. ? Are we here for only bug fixes, and follow the direction and flow that is already set, or as contributors would we be allowed to contribute to the goals and direction of JavaFX? FX is a good platform with great potential, but it biggest deficiency is ?mind share?. ?People don?t see too many real world accomplishments that knock your socks off. ? Most people use web and phone to run apps. ?PC and Desktop apps are a small part of the market. ?? Gluon has just recently released gluon VM and Gluon Mobile to allow FX on phones and tablets. ?? The problem I see is once I can use FX on phones how will it compete with Swift? True that ?write once, run everywhere? is important and Java has a lead over Swift. ?But Swift has a lead on capability. In the end Swift will catch up with Java in the ?write once, run anywhere? mantra. ? Will FX catch up with Swift in graphics by then?? Java has a lead in many areas, but if we look 10 years out, it seems clear to me that Java needs to raise the bar or face extinction as a client side development platform or forever be confined to the server. ? This is why I need some clarification as to what our role as contributors is going to be. ? I don?t believe an open source project can flourish if the contributors have no say or stake in the direction. Steve Desofi Sent from my iPhone On Feb 2, 2018, at 11:55 PM, John-Val Rose wrote: I think Kevin outlined in his opening post what would be considered "out of scope". However, I agree with you on the basic premise that, in general, the bar has been set way too low as to the potential use cases and performance of JavaFX.? In fact, I firmly believe that games & complex visualisations etc. *should* be possible with JavaFX given that most of the heavy lifting is being done by the GPU.? It's just that, at the moment, the scene graph rendering pipeline is significantly slower than it could be and it is for this reason that we don't find applications using advanced 3D graphics & animations etc. (like we see in games) being built with JavaFX.? It's just not possible when the node count reaches even a very small threshold. This is a topic I have tried to discuss numerous times and also believe that I can improve the performance of the scene graph rendering in a very tangible way. If things pan-out as they are being described and becoming & being a contributor is simplified to the extent where it justifies me devoting a large chunk of my time to OpenJFX, this is probably what I would want to work on first. ??Graciously, John-Val Rose On 3 February 2018 at 14:07, Stephen Desofi wrote: I don?t understand why discussing new graphics capabilities such as gaming or WebGPU, etc is so off limits.? Can you explain that? Steve Desofi Sent from my iPhone > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth wrote: > > Looks like we have some good discussion so far. > > I see a few themes emerging (build/test, sandbox on GitHub, ease of filing bugs, etc) along with some discussion on graphics performance (which is fine as long as the discussion doesn't veer too far into discussing specific graphics features). > > I'll let more folks chime in before I reply to anything specifically (and I'll be offline over the weekend anyway). > > Thanks! > > -- Kevin > From johnvalrose at gmail.com Sun Feb 4 02:13:58 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Sun, 4 Feb 2018 13:13:58 +1100 Subject: More community participation in JavaFX In-Reply-To: <5d02482f-5ab0-49f1-a6d3-0fc4a3310a5b@me.com> References: <5d02482f-5ab0-49f1-a6d3-0fc4a3310a5b@me.com> Message-ID: Stephen, 1. Swift and your "crystal ball" view of its spectacular success in the future has nothing whatsoever to do with making contributing to JavaFX easier. 2. Like everyone else who already wants to contribute to JavaFX, we don't need someone to provide us with "a compelling story as to why developers should join and contribute". 3. TL;DR John-Val Rose ? (trying to be polite)? On 4 February 2018 at 12:58, Stephen Desofi wrote: > John, > > The point I am making is that Swift is catching up as a cross > platform toolkit and is available on: > > Mac and iOS, (Full Support) > https://www.swift.org > > Android (early) > > https://academy.realm.io/posts/swift-on-android/ > > > Linux: (early) > > https://itsfoss.com/use-swift-linux/ > > > Windows: (early) > > https://www.infoworld.com/article/3067364/open-source- > tools/swift-for-windows-arrives-at-last-but-as-an-unofficial-port.html > > > > Browser: (very Preliminary) > > > https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly > > Server Side: (Mac and Linux) > https://www.swift.org > > > So my point is that soon Swift will steal the Cross Platform Mantra from > Java. It is happening very quickly and Swift has great graphics and > gaming capabilities as well. > > > Why would a new developer start with Java? If we are looking 10 years > out, I think Apple is coming head on. > > > Also when you say this thread is about the ease with which the community > can contribute to JavaFX, it begs the question "what kinds of > contribution?". Are we here to push the platform forward and contribute > new ideas or just do bug fixes? > > > Swift is a real threat to Java being the cross platform development King. > Java can hold on to that story for only a couple more years. It surely > won't last. > > > Dart also runs on Android and iOS via Flutter, has Server side Dart > option, runs in the Browser very well today with full support for SVG and > Canvas -- and if WebGPU becomes a Web standard, Google will most certainly > support it. > > > Looking toward the future, if Java doesn't run in the browser, doesn't > support games on any platform, and only works on iOS and Android via Gluon > VM, and does it with only limited graphics capability, then I think > JavaFX will be a tough sell in the future. Even tougher than it is today. > > > If the point of the discussion is to build the developer community, I > think we first need a compelling story as to why developers should join and > contribute. > > > The fact that I am using Dart and JavaFX, and I am seriously > considering if I should switch to Dart everywhere, or to Dart and Swift > (instead of Dart and FX) means JavaFX doesn't have the lead we think it > does. I love JavaFX and would love to contribute, but it's hard when I > myself am looking at other options mainly because I also want my software > to be here 10 years from now, and I am seriously questioning if JavaFX will > keep up. > > > I think there is a small window of opportunity for JavaFX to make a stand > before it is permanently relegated to a Server side language. This cross > platform story won't fly too much longer, especially when Swift starts to > run everywhere and in the browser too, and if Google does the same thing > with Dart, and they both support games, where will Java be? > > > If we are looking 10 years out then surely this will happen. The big > question is what will we do, and where will JavaFX be? > > > Steve Desofi > > > > > On Feb 03, 2018, at 03:09 PM, John-Val Rose wrote: > > > Stephen - I?m not quite following you. > > This thread is about improving the ease with which the community can > contribute to JavaFX. > > I see no point in comparing JavaFX (a cross platform graphics toolkit for > JVM languages) with a Swift (a general purpose programming language that > runs on Apple hardware). > > On 4 Feb 2018, at 00:18, Stephen Desofi wrote: > > This begs the question, why has the bar been set too low? I am new to > this community and don?t know much history other than a couple weeks of bug > fix messages flying by. > > I am not even clear of what our role and purpose is supposed to be. Are > we here for only bug fixes, and follow the direction and flow that is > already set, or as contributors would we be allowed to contribute to the > goals and direction of JavaFX? > > FX is a good platform with great potential, but it biggest deficiency is > ?mind share?. People don?t see too many real world accomplishments that > knock your socks off. Most people use web and phone to run apps. PC and > Desktop apps are a small part of the market. > > Gluon has just recently released gluon VM and Gluon Mobile to allow FX on > phones and tablets. > > The problem I see is once I can use FX on phones how will it compete with > Swift? > > True that ?write once, run everywhere? is important and Java has a lead > over Swift. But Swift has a lead on capability. > > In the end Swift will catch up with Java in the ?write once, run anywhere? > mantra. Will FX catch up with Swift in graphics by then? > > Java has a lead in many areas, but if we look 10 years out, it seems clear > to me that Java needs to raise the bar or face extinction as a client side > development platform or forever be confined to the server. > > This is why I need some clarification as to what our role as contributors > is going to be. I don?t believe an open source project can flourish if > the contributors have no say or stake in the direction. > > Steve Desofi > > > > > > Sent from my iPhone > > On Feb 2, 2018, at 11:55 PM, John-Val Rose wrote: > > I think Kevin outlined in his opening post what would be considered "out > of scope". > > However, I agree with you on the basic premise that, in general, the bar > has been set way too low as to the potential use cases and performance of > JavaFX. In fact, I firmly believe that games & complex visualisations etc. > *should* be possible with JavaFX given that most of the heavy lifting is > being done by the GPU. It's just that, at the moment, the scene graph > rendering pipeline is significantly slower than it could be and it is for > this reason that we don't find applications using advanced 3D graphics & > animations etc. (like we see in games) being built with JavaFX. It's just > not possible when the node count reaches even a very small threshold. > > This is a topic I have tried to discuss numerous times and also believe > that I can improve the performance of the scene graph rendering in a very > tangible way. > > If things pan-out as they are being described and becoming & being a > contributor is simplified to the extent where it justifies me devoting a > large chunk of my time to OpenJFX, this is probably what I would want to > work on first. > > ?? > Graciously, > > John-Val Rose > > On 3 February 2018 at 14:07, Stephen Desofi wrote: > >> I don?t understand why discussing new graphics capabilities such as >> gaming or WebGPU, etc is so off limits. Can you explain that? >> >> Steve Desofi >> >> Sent from my iPhone >> >> > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth >> wrote: >> > >> > Looks like we have some good discussion so far. >> > >> > I see a few themes emerging (build/test, sandbox on GitHub, ease of >> filing bugs, etc) along with some discussion on graphics performance (which >> is fine as long as the discussion doesn't veer too far into discussing >> specific graphics features). >> > >> > I'll let more folks chime in before I reply to anything specifically >> (and I'll be offline over the weekend anyway). >> > >> > Thanks! >> > >> > -- Kevin >> > >> > > From sdesofi at icloud.com Sun Feb 4 02:29:00 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Sun, 04 Feb 2018 02:29:00 +0000 (GMT) Subject: More community participation in JavaFX Message-ID: John, ? ? ?I think you and I are thinking on two different levels. ? ?You are talking about the mechanics of making contributing to JavaFX easier. ? ?I am talking about making the motivations of contributing to JavaFX easier. Steve Sent from iCloud On Feb 03, 2018, at 09:14 PM, John-Val Rose wrote: Stephen, 1. Swift and your "crystal ball" view of its spectacular success in the future has nothing whatsoever to do with making contributing to JavaFX easier. 2. Like everyone else who already wants to contribute to JavaFX, we don't need someone to provide us with "a compelling story as to why developers should join and contribute". 3. TL;DR John-Val Rose? (trying to be polite)? On 4 February 2018 at 12:58, Stephen Desofi wrote: John, ? ? ?The point I am making is that Swift is catching up as a cross platform toolkit and is available on: Mac and iOS, (Full Support) https://www.swift.org Android (early) https://academy.realm.io/posts/swift-on-android/ Linux: ?(early) https://itsfoss.com/use-swift-linux/ Windows: (early) https://www.infoworld.com/article/3067364/open-source-tools/swift-for-windows-arrives-at-last-but-as-an-unofficial-port.html Browser: ?(very Preliminary) https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly Server Side: ?(Mac and Linux) https://www.swift.org So my point is that soon Swift will steal the Cross Platform Mantra from Java. ? It is happening very quickly and Swift has great graphics and gaming capabilities as well. Why would a new developer start with?Java? ? ?If we are looking 10 years out, I think Apple is coming head on. Also when you say this thread is about the ease with which the community can contribute to JavaFX, it begs the question "what kinds of contribution?". ? ?Are we here to push the platform forward and contribute new ideas or just do bug fixes? Swift is a real threat to Java being the cross platform development King. ? ?Java can hold on to that story for only a couple more years.? It surely won't last. Dart also runs on Android and iOS via Flutter, has Server side Dart option, runs in the Browser very well today with full support for SVG and Canvas -- and if WebGPU becomes a Web standard, Google will most certainly support it. Looking toward the future, if Java doesn't run in the browser, doesn't support games on any platform, and only works on iOS and Android via Gluon VM, and does it with only limited graphics capability, ?then I think JavaFX?will be a tough sell in the future. ? Even tougher than it is today.? If the point of the discussion is to build the developer community, I think we first need a compelling story as to why developers should join and contribute. The fact that I am using Dart and JavaFX, and I am seriously considering?if I should switch to Dart everywhere, or to Dart and Swift (instead of Dart and FX)?means JavaFX doesn't have the lead we think it does. ? ?I love JavaFX and would love to contribute, but it's hard when I myself am looking at other options mainly because I also want my software to be here 10 years from now, and I am seriously questioning if JavaFX will keep up. I think there is a small window of opportunity for JavaFX to make a stand before it is permanently relegated to a Server side language. ? This cross platform story won't fly too much longer, especially when Swift starts to run everywhere and in the browser too, and if Google does the same thing with Dart, and they?both support games, where will Java be? If we are looking 10 years out?then surely this will happen. ? The big question is what will we do, and where will JavaFX be? Steve Desofi On Feb 03, 2018, at 03:09 PM, John-Val Rose wrote: Stephen - I?m not quite following you. This thread is about improving the ease with which the community can contribute to JavaFX. I see no point in comparing JavaFX (a cross platform graphics toolkit for JVM languages) with a Swift (a general purpose programming language that runs on Apple hardware). On 4 Feb 2018, at 00:18, Stephen Desofi wrote: This begs the question, ?why has the bar been set too low? ? I am new to this community and don?t know much history other than a couple weeks of bug fix messages flying by. ?? I am not even clear of what our role and purpose is supposed to be. ? Are we here for only bug fixes, and follow the direction and flow that is already set, or as contributors would we be allowed to contribute to the goals and direction of JavaFX? FX is a good platform with great potential, but it biggest deficiency is ?mind share?.? People don?t see too many real world accomplishments that knock your socks off. ? Most people use web and phone to run apps.? PC and Desktop apps are a small part of the market. ?? Gluon has just recently released gluon VM and Gluon Mobile to allow FX on phones and tablets. ?? The problem I see is once I can use FX on phones how will it compete with Swift? True that ?write once, run everywhere? is important and Java has a lead over Swift.? But Swift has a lead on capability. In the end Swift will catch up with Java in the ?write once, run anywhere? mantra. ? Will FX catch up with Swift in graphics by then?? Java has a lead in many areas, but if we look 10 years out, it seems clear to me that Java needs to raise the bar or face extinction as a client side development platform or forever be confined to the server. ? This is why I need some clarification as to what our role as contributors is going to be. ? I don?t believe an open source project can flourish if the contributors have no say or stake in the direction. Steve Desofi Sent from my iPhone On Feb 2, 2018, at 11:55 PM, John-Val Rose wrote: I think Kevin outlined in his opening post what would be considered "out of scope". However, I agree with you on the basic premise that, in general, the bar has been set way too low as to the potential use cases and performance of JavaFX.? In fact, I firmly believe that games & complex visualisations etc. *should* be possible with JavaFX given that most of the heavy lifting is being done by the GPU.? It's just that, at the moment, the scene graph rendering pipeline is significantly slower than it could be and it is for this reason that we don't find applications using advanced 3D graphics & animations etc. (like we see in games) being built with JavaFX.? It's just not possible when the node count reaches even a very small threshold. This is a topic I have tried to discuss numerous times and also believe that I can improve the performance of the scene graph rendering in a very tangible way. If things pan-out as they are being described and becoming & being a contributor is simplified to the extent where it justifies me devoting a large chunk of my time to OpenJFX, this is probably what I would want to work on first. ??Graciously, John-Val Rose On 3 February 2018 at 14:07, Stephen Desofi wrote: I don?t understand why discussing new graphics capabilities such as gaming or WebGPU, etc is so off limits.? Can you explain that? Steve Desofi Sent from my iPhone > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth wrote: > > Looks like we have some good discussion so far. > > I see a few themes emerging (build/test, sandbox on GitHub, ease of filing bugs, etc) along with some discussion on graphics performance (which is fine as long as the discussion doesn't veer too far into discussing specific graphics features). > > I'll let more folks chime in before I reply to anything specifically (and I'll be offline over the weekend anyway). > > Thanks! > > -- Kevin > From johnvalrose at gmail.com Sun Feb 4 02:34:59 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Sun, 4 Feb 2018 13:34:59 +1100 Subject: More community participation in JavaFX In-Reply-To: References: Message-ID: Well, then one of us is "off topic"... Kevin Rushforth: "We are specifically looking to discuss ideas around the following areas: * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) * Code review policies * API / feature review policies * Code review tools (we currently use webrev, but that isn't set in stone)" On 4 February 2018 at 13:29, Stephen Desofi wrote: > John, > > I think you and I are thinking on two different levels. You are > talking about the mechanics of making contributing to JavaFX easier. I > am talking about making the motivations of contributing to JavaFX easier. > > Steve > > Sent from iCloud > > On Feb 03, 2018, at 09:14 PM, John-Val Rose wrote: > > Stephen, > > 1. Swift and your "crystal ball" view of its spectacular success in the > future has nothing whatsoever to do with making contributing to JavaFX > easier. > > 2. Like everyone else who already wants to contribute to JavaFX, we don't > need someone to provide us with "a compelling story as to why developers > should join and contribute". > > 3. TL;DR > > John-Val Rose > ? (trying to be polite)? > > On 4 February 2018 at 12:58, Stephen Desofi wrote: > >> John, >> >> The point I am making is that Swift is catching up as a cross >> platform toolkit and is available on: >> >> Mac and iOS, (Full Support) >> https://www.swift.org >> >> Android (early) >> >> https://academy.realm.io/posts/swift-on-android/ >> >> >> Linux: (early) >> >> >> https://itsfoss.com/use-swift-linux/ >> >> >> Windows: (early) >> >> >> https://www.infoworld.com/article/3067364/open-source-tools/ >> swift-for-windows-arrives-at-last-but-as-an-unofficial-port.html >> >> >> >> Browser: (very Preliminary) >> >> >> >> https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly >> >> Server Side: (Mac and Linux) >> https://www.swift.org >> >> >> So my point is that soon Swift will steal the Cross Platform Mantra from >> Java. It is happening very quickly and Swift has great graphics and >> gaming capabilities as well. >> >> >> Why would a new developer start with Java? If we are looking 10 years >> out, I think Apple is coming head on. >> >> >> Also when you say this thread is about the ease with which the community >> can contribute to JavaFX, it begs the question "what kinds of >> contribution?". Are we here to push the platform forward and contribute >> new ideas or just do bug fixes? >> >> >> Swift is a real threat to Java being the cross platform development King. >> Java can hold on to that story for only a couple more years. It surely >> won't last. >> >> >> Dart also runs on Android and iOS via Flutter, has Server side Dart >> option, runs in the Browser very well today with full support for SVG and >> Canvas -- and if WebGPU becomes a Web standard, Google will most certainly >> support it. >> >> >> Looking toward the future, if Java doesn't run in the browser, doesn't >> support games on any platform, and only works on iOS and Android via Gluon >> VM, and does it with only limited graphics capability, then I think >> JavaFX will be a tough sell in the future. Even tougher than it is today. >> >> >> If the point of the discussion is to build the developer community, I >> think we first need a compelling story as to why developers should join and >> contribute. >> >> >> The fact that I am using Dart and JavaFX, and I am seriously >> considering if I should switch to Dart everywhere, or to Dart and Swift >> (instead of Dart and FX) means JavaFX doesn't have the lead we think it >> does. I love JavaFX and would love to contribute, but it's hard when I >> myself am looking at other options mainly because I also want my software >> to be here 10 years from now, and I am seriously questioning if JavaFX will >> keep up. >> >> >> I think there is a small window of opportunity for JavaFX to make a stand >> before it is permanently relegated to a Server side language. This cross >> platform story won't fly too much longer, especially when Swift starts to >> run everywhere and in the browser too, and if Google does the same thing >> with Dart, and they both support games, where will Java be? >> >> >> If we are looking 10 years out then surely this will happen. The big >> question is what will we do, and where will JavaFX be? >> >> >> Steve Desofi >> >> >> >> >> On Feb 03, 2018, at 03:09 PM, John-Val Rose >> wrote: >> >> >> Stephen - I?m not quite following you. >> >> This thread is about improving the ease with which the community can >> contribute to JavaFX. >> >> I see no point in comparing JavaFX (a cross platform graphics toolkit for >> JVM languages) with a Swift (a general purpose programming language that >> runs on Apple hardware). >> >> On 4 Feb 2018, at 00:18, Stephen Desofi wrote: >> >> This begs the question, why has the bar been set too low? I am new to >> this community and don?t know much history other than a couple weeks of bug >> fix messages flying by. >> >> I am not even clear of what our role and purpose is supposed to be. Are >> we here for only bug fixes, and follow the direction and flow that is >> already set, or as contributors would we be allowed to contribute to the >> goals and direction of JavaFX? >> >> FX is a good platform with great potential, but it biggest deficiency is >> ?mind share?. People don?t see too many real world accomplishments that >> knock your socks off. Most people use web and phone to run apps. PC and >> Desktop apps are a small part of the market. >> >> Gluon has just recently released gluon VM and Gluon Mobile to allow FX on >> phones and tablets. >> >> The problem I see is once I can use FX on phones how will it compete with >> Swift? >> >> True that ?write once, run everywhere? is important and Java has a lead >> over Swift. But Swift has a lead on capability. >> >> In the end Swift will catch up with Java in the ?write once, run >> anywhere? mantra. Will FX catch up with Swift in graphics by then? >> >> Java has a lead in many areas, but if we look 10 years out, it seems >> clear to me that Java needs to raise the bar or face extinction as a client >> side development platform or forever be confined to the server. >> >> This is why I need some clarification as to what our role as contributors >> is going to be. I don?t believe an open source project can flourish if >> the contributors have no say or stake in the direction. >> >> Steve Desofi >> >> >> >> >> >> Sent from my iPhone >> >> On Feb 2, 2018, at 11:55 PM, John-Val Rose wrote: >> >> I think Kevin outlined in his opening post what would be considered "out >> of scope". >> >> However, I agree with you on the basic premise that, in general, the bar >> has been set way too low as to the potential use cases and performance of >> JavaFX. In fact, I firmly believe that games & complex visualisations etc. >> *should* be possible with JavaFX given that most of the heavy lifting is >> being done by the GPU. It's just that, at the moment, the scene graph >> rendering pipeline is significantly slower than it could be and it is for >> this reason that we don't find applications using advanced 3D graphics & >> animations etc. (like we see in games) being built with JavaFX. It's just >> not possible when the node count reaches even a very small threshold. >> >> This is a topic I have tried to discuss numerous times and also believe >> that I can improve the performance of the scene graph rendering in a very >> tangible way. >> >> If things pan-out as they are being described and becoming & being a >> contributor is simplified to the extent where it justifies me devoting a >> large chunk of my time to OpenJFX, this is probably what I would want to >> work on first. >> >> ?? >> Graciously, >> >> John-Val Rose >> >> On 3 February 2018 at 14:07, Stephen Desofi wrote: >> >>> I don?t understand why discussing new graphics capabilities such as >>> gaming or WebGPU, etc is so off limits. Can you explain that? >>> >>> Steve Desofi >>> >>> Sent from my iPhone >>> >>> > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> > >>> > Looks like we have some good discussion so far. >>> > >>> > I see a few themes emerging (build/test, sandbox on GitHub, ease of >>> filing bugs, etc) along with some discussion on graphics performance (which >>> is fine as long as the discussion doesn't veer too far into discussing >>> specific graphics features). >>> > >>> > I'll let more folks chime in before I reply to anything specifically >>> (and I'll be offline over the weekend anyway). >>> > >>> > Thanks! >>> > >>> > -- Kevin >>> > >>> >> >> > From sdesofi at icloud.com Sun Feb 4 02:37:09 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Sun, 04 Feb 2018 02:37:09 +0000 (GMT) Subject: More community participation in JavaFX Message-ID: <70b144c4-32e5-4a57-a0c6-7465559957ed@me.com> Yes, ?probably me. Sent from iCloud On Feb 03, 2018, at 09:35 PM, John-Val Rose wrote: Well, then one of us is "off topic"... Kevin Rushforth: "We are specifically looking to discuss ideas around the following areas: * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) * Code review policies * API / feature review policies * Code review tools (we currently use webrev, but that isn't set in stone)" On 4 February 2018 at 13:29, Stephen Desofi wrote: John, ? ? ?I think you and I are thinking on two different levels. ? ?You are talking about the mechanics of making contributing to JavaFX easier. ? ?I am talking about making the motivations of contributing to JavaFX easier. Steve Sent from iCloud On Feb 03, 2018, at 09:14 PM, John-Val Rose wrote: Stephen, 1. Swift and your "crystal ball" view of its spectacular success in the future has nothing whatsoever to do with making contributing to JavaFX easier. 2. Like everyone else who already wants to contribute to JavaFX, we don't need someone to provide us with "a compelling story as to why developers should join and contribute". 3. TL;DR John-Val Rose? (trying to be polite)? On 4 February 2018 at 12:58, Stephen Desofi wrote: John, ? ? ?The point I am making is that Swift is catching up as a cross platform toolkit and is available on: Mac and iOS, (Full Support) https://www.swift.org Android (early) https://academy.realm.io/posts/swift-on-android/ Linux: ?(early) https://itsfoss.com/use-swift-linux/ Windows: (early) https://www.infoworld.com/article/3067364/open-source-tools/swift-for-windows-arrives-at-last-but-as-an-unofficial-port.html Browser: ?(very Preliminary) https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly Server Side: ?(Mac and Linux) https://www.swift.org So my point is that soon Swift will steal the Cross Platform Mantra from Java. ? It is happening very quickly and Swift has great graphics and gaming capabilities as well. Why would a new developer start with?Java? ? ?If we are looking 10 years out, I think Apple is coming head on. Also when you say this thread is about the ease with which the community can contribute to JavaFX, it begs the question "what kinds of contribution?". ? ?Are we here to push the platform forward and contribute new ideas or just do bug fixes? Swift is a real threat to Java being the cross platform development King. ? ?Java can hold on to that story for only a couple more years.? It surely won't last. Dart also runs on Android and iOS via Flutter, has Server side Dart option, runs in the Browser very well today with full support for SVG and Canvas -- and if WebGPU becomes a Web standard, Google will most certainly support it. Looking toward the future, if Java doesn't run in the browser, doesn't support games on any platform, and only works on iOS and Android via Gluon VM, and does it with only limited graphics capability, ?then I think JavaFX?will be a tough sell in the future. ? Even tougher than it is today.? If the point of the discussion is to build the developer community, I think we first need a compelling story as to why developers should join and contribute. The fact that I am using Dart and JavaFX, and I am seriously considering?if I should switch to Dart everywhere, or to Dart and Swift (instead of Dart and FX)?means JavaFX doesn't have the lead we think it does. ? ?I love JavaFX and would love to contribute, but it's hard when I myself am looking at other options mainly because I also want my software to be here 10 years from now, and I am seriously questioning if JavaFX will keep up. I think there is a small window of opportunity for JavaFX to make a stand before it is permanently relegated to a Server side language. ? This cross platform story won't fly too much longer, especially when Swift starts to run everywhere and in the browser too, and if Google does the same thing with Dart, and they?both support games, where will Java be? If we are looking 10 years out?then surely this will happen. ? The big question is what will we do, and where will JavaFX be? Steve Desofi On Feb 03, 2018, at 03:09 PM, John-Val Rose wrote: Stephen - I?m not quite following you. This thread is about improving the ease with which the community can contribute to JavaFX. I see no point in comparing JavaFX (a cross platform graphics toolkit for JVM languages) with a Swift (a general purpose programming language that runs on Apple hardware). On 4 Feb 2018, at 00:18, Stephen Desofi wrote: This begs the question, ?why has the bar been set too low? ? I am new to this community and don?t know much history other than a couple weeks of bug fix messages flying by. ?? I am not even clear of what our role and purpose is supposed to be. ? Are we here for only bug fixes, and follow the direction and flow that is already set, or as contributors would we be allowed to contribute to the goals and direction of JavaFX? FX is a good platform with great potential, but it biggest deficiency is ?mind share?.? People don?t see too many real world accomplishments that knock your socks off. ? Most people use web and phone to run apps.? PC and Desktop apps are a small part of the market. ?? Gluon has just recently released gluon VM and Gluon Mobile to allow FX on phones and tablets. ?? The problem I see is once I can use FX on phones how will it compete with Swift? True that ?write once, run everywhere? is important and Java has a lead over Swift.? But Swift has a lead on capability. In the end Swift will catch up with Java in the ?write once, run anywhere? mantra. ? Will FX catch up with Swift in graphics by then?? Java has a lead in many areas, but if we look 10 years out, it seems clear to me that Java needs to raise the bar or face extinction as a client side development platform or forever be confined to the server. ? This is why I need some clarification as to what our role as contributors is going to be. ? I don?t believe an open source project can flourish if the contributors have no say or stake in the direction. Steve Desofi Sent from my iPhone On Feb 2, 2018, at 11:55 PM, John-Val Rose wrote: I think Kevin outlined in his opening post what would be considered "out of scope". However, I agree with you on the basic premise that, in general, the bar has been set way too low as to the potential use cases and performance of JavaFX.? In fact, I firmly believe that games & complex visualisations etc. *should* be possible with JavaFX given that most of the heavy lifting is being done by the GPU.? It's just that, at the moment, the scene graph rendering pipeline is significantly slower than it could be and it is for this reason that we don't find applications using advanced 3D graphics & animations etc. (like we see in games) being built with JavaFX.? It's just not possible when the node count reaches even a very small threshold. This is a topic I have tried to discuss numerous times and also believe that I can improve the performance of the scene graph rendering in a very tangible way. If things pan-out as they are being described and becoming & being a contributor is simplified to the extent where it justifies me devoting a large chunk of my time to OpenJFX, this is probably what I would want to work on first. ??Graciously, John-Val Rose On 3 February 2018 at 14:07, Stephen Desofi wrote: I don?t understand why discussing new graphics capabilities such as gaming or WebGPU, etc is so off limits.? Can you explain that? Steve Desofi Sent from my iPhone > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth wrote: > > Looks like we have some good discussion so far. > > I see a few themes emerging (build/test, sandbox on GitHub, ease of filing bugs, etc) along with some discussion on graphics performance (which is fine as long as the discussion doesn't veer too far into discussing specific graphics features). > > I'll let more folks chime in before I reply to anything specifically (and I'll be offline over the weekend anyway). > > Thanks! > > -- Kevin > From johnvalrose at gmail.com Sun Feb 4 05:06:16 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Sun, 4 Feb 2018 16:06:16 +1100 Subject: More community participation in JavaFX In-Reply-To: <70b144c4-32e5-4a57-a0c6-7465559957ed@me.com> References: <70b144c4-32e5-4a57-a0c6-7465559957ed@me.com> Message-ID: Well, if your interest is mainly in the future ?cross platform king? of languages, you might just want to have a look at Kotlin and Kotlin/Native. Oh, and I have heard you can develop JavaFX apps with Kotlin too! > On 4 Feb 2018, at 13:37, Stephen Desofi wrote: > > Yes, probably me. > > Sent from iCloud > >> On Feb 03, 2018, at 09:35 PM, John-Val Rose wrote: >> > >> Well, then one of us is "off topic"... >> >> >> Kevin Rushforth: >> >> "We are specifically looking to discuss ideas around the following areas: >> * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) >> * Code review policies >> * API / feature review policies >> * Code review tools (we currently use webrev, but that isn't set in stone)" >> >>> On 4 February 2018 at 13:29, Stephen Desofi wrote: >> >>> John, >>> >>> I think you and I are thinking on two different levels. You are talking about the mechanics of making contributing to JavaFX easier. I am talking about making the motivations of contributing to JavaFX easier. >>> >>> Steve >>> >>> Sent from iCloud >>> >>>> On Feb 03, 2018, at 09:14 PM, John-Val Rose wrote: >>>> >>> >>>> Stephen, >>>> >>>> 1. Swift and your "crystal ball" view of its spectacular success in the future has nothing whatsoever to do with making contributing to JavaFX easier. >>>> >>>> 2. Like everyone else who already wants to contribute to JavaFX, we don't need someone to provide us with "a compelling story as to why developers should join and contribute". >>>> >>>> 3. TL;DR >>>> >>>> John-Val Rose? (trying to be polite)? >>>> >>>>> On 4 February 2018 at 12:58, Stephen Desofi wrote: >>>>> John, >>>>> >>>>> The point I am making is that Swift is catching up as a cross platform toolkit and is available on: >>>>> >>>>> Mac and iOS, (Full Support) >>>>> https://www.swift.org >>>>> >>>>> Android (early) >>>>> https://academy.realm.io/posts/swift-on-android/ >>>>> >>>>> Linux: (early) >>>>> >>>>> https://itsfoss.com/use-swift-linux/ >>>>> >>>>> Windows: (early) >>>>> >>>>> https://www.infoworld.com/article/3067364/open-source-tools/swift-for-windows-arrives-at-last-but-as-an-unofficial-port.html >>>>> >>>>> >>>>> Browser: (very Preliminary) >>>>> >>>>> https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly >>>>> >>>>> Server Side: (Mac and Linux) >>>>> https://www.swift.org >>>>> >>>>> >>>>> So my point is that soon Swift will steal the Cross Platform Mantra from Java. It is happening very quickly and Swift has great graphics and gaming capabilities as well. >>>>> >>>>> Why would a new developer start with Java? If we are looking 10 years out, I think Apple is coming head on. >>>>> >>>>> Also when you say this thread is about the ease with which the community can contribute to JavaFX, it begs the question "what kinds of contribution?". Are we here to push the platform forward and contribute new ideas or just do bug fixes? >>>>> >>>>> Swift is a real threat to Java being the cross platform development King. Java can hold on to that story for only a couple more years. It surely won't last. >>>>> >>>>> Dart also runs on Android and iOS via Flutter, has Server side Dart option, runs in the Browser very well today with full support for SVG and Canvas -- and if WebGPU becomes a Web standard, Google will most certainly support it. >>>>> >>>>> Looking toward the future, if Java doesn't run in the browser, doesn't support games on any platform, and only works on iOS and Android via Gluon VM, and does it with only limited graphics capability, then I think JavaFX will be a tough sell in the future. Even tougher than it is today. >>>>> >>>>> If the point of the discussion is to build the developer community, I think we first need a compelling story as to why developers should join and contribute. >>>>> >>>>> The fact that I am using Dart and JavaFX, and I am seriously considering if I should switch to Dart everywhere, or to Dart and Swift (instead of Dart and FX) means JavaFX doesn't have the lead we think it does. I love JavaFX and would love to contribute, but it's hard when I myself am looking at other options mainly because I also want my software to be here 10 years from now, and I am seriously questioning if JavaFX will keep up. >>>>> >>>>> I think there is a small window of opportunity for JavaFX to make a stand before it is permanently relegated to a Server side language. This cross platform story won't fly too much longer, especially when Swift starts to run everywhere and in the browser too, and if Google does the same thing with Dart, and they both support games, where will Java be? >>>>> >>>>> If we are looking 10 years out then surely this will happen. The big question is what will we do, and where will JavaFX be? >>>>> >>>>> Steve Desofi >>>>> >>>>> >>>>> >>>>>> On Feb 03, 2018, at 03:09 PM, John-Val Rose wrote: >>>>>> >>>>> >>>>>> >>>>>> Stephen - I?m not quite following you. >>>>>> >>>>>> This thread is about improving the ease with which the community can contribute to JavaFX. >>>>>> >>>>>> I see no point in comparing JavaFX (a cross platform graphics toolkit for JVM languages) with a Swift (a general purpose programming language that runs on Apple hardware). >>>>>> >>>>>>> On 4 Feb 2018, at 00:18, Stephen Desofi wrote: >>>>>>> >>>>>>> This begs the question, why has the bar been set too low? I am new to this community and don?t know much history other than a couple weeks of bug fix messages flying by. >>>>>>> >>>>>>> I am not even clear of what our role and purpose is supposed to be. Are we here for only bug fixes, and follow the direction and flow that is already set, or as contributors would we be allowed to contribute to the goals and direction of JavaFX? >>>>>>> >>>>>>> FX is a good platform with great potential, but it biggest deficiency is ?mind share?. People don?t see too many real world accomplishments that knock your socks off. Most people use web and phone to run apps. PC and Desktop apps are a small part of the market. >>>>>>> >>>>>>> Gluon has just recently released gluon VM and Gluon Mobile to allow FX on phones and tablets. >>>>>>> >>>>>>> The problem I see is once I can use FX on phones how will it compete with Swift? >>>>>>> >>>>>>> True that ?write once, run everywhere? is important and Java has a lead over Swift. But Swift has a lead on capability. >>>>>>> >>>>>>> In the end Swift will catch up with Java in the ?write once, run anywhere? mantra. Will FX catch up with Swift in graphics by then? >>>>>>> >>>>>>> Java has a lead in many areas, but if we look 10 years out, it seems clear to me that Java needs to raise the bar or face extinction as a client side development platform or forever be confined to the server. >>>>>>> >>>>>>> This is why I need some clarification as to what our role as contributors is going to be. I don?t believe an open source project can flourish if the contributors have no say or stake in the direction. >>>>>>> >>>>>>> Steve Desofi >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On Feb 2, 2018, at 11:55 PM, John-Val Rose wrote: >>>>>>>> >>>>>>>> I think Kevin outlined in his opening post what would be considered "out of scope". >>>>>>>> >>>>>>>> However, I agree with you on the basic premise that, in general, the bar has been set way too low as to the potential use cases and performance of JavaFX. In fact, I firmly believe that games & complex visualisations etc. *should* be possible with JavaFX given that most of the heavy lifting is being done by the GPU. It's just that, at the moment, the scene graph rendering pipeline is significantly slower than it could be and it is for this reason that we don't find applications using advanced 3D graphics & animations etc. (like we see in games) being built with JavaFX. It's just not possible when the node count reaches even a very small threshold. >>>>>>>> >>>>>>>> This is a topic I have tried to discuss numerous times and also believe that I can improve the performance of the scene graph rendering in a very tangible way. >>>>>>>> >>>>>>>> If things pan-out as they are being described and becoming & being a contributor is simplified to the extent where it justifies me devoting a large chunk of my time to OpenJFX, this is probably what I would want to work on first. >>>>>>>> >>>>>>>> ??Graciously, >>>>>>>> >>>>>>>> John-Val Rose >>>>>>>> >>>>>>>>> On 3 February 2018 at 14:07, Stephen Desofi wrote: >>>>>>>>> I don?t understand why discussing new graphics capabilities such as gaming or WebGPU, etc is so off limits. Can you explain that? >>>>>>>>> >>>>>>>>> Steve Desofi >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>> > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth wrote: >>>>>>>>> > >>>>>>>>> > Looks like we have some good discussion so far. >>>>>>>>> > >>>>>>>>> > I see a few themes emerging (build/test, sandbox on GitHub, ease of filing bugs, etc) along with some discussion on graphics performance (which is fine as long as the discussion doesn't veer too far into discussing specific graphics features). >>>>>>>>> > >>>>>>>>> > I'll let more folks chime in before I reply to anything specifically (and I'll be offline over the weekend anyway). >>>>>>>>> > >>>>>>>>> > Thanks! >>>>>>>>> > >>>>>>>>> > -- Kevin >>>>>>>>> > >>>>>>>> >>>> >> From sdesofi at icloud.com Sun Feb 4 16:03:21 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Sun, 04 Feb 2018 11:03:21 -0500 Subject: More community participation in JavaFX In-Reply-To: References: <70b144c4-32e5-4a57-a0c6-7465559957ed@me.com> Message-ID: <0EE66251-5E5A-4149-AA16-2BD1388DCDE1@icloud.com> I looked up progress in Kotlin and Kotlin/native and you are right, they are doing most of the things I had suggested for JavaFX. Thanks, Steve Sent from my iPhone > On Feb 4, 2018, at 12:06 AM, John-Val Rose wrote: > > Well, if your interest is mainly in the future ?cross platform king? of languages, you might just want to have a look at Kotlin and Kotlin/Native. > > Oh, and I have heard you can develop JavaFX apps with Kotlin too! > >> On 4 Feb 2018, at 13:37, Stephen Desofi wrote: >> >> Yes, probably me. >> >> Sent from iCloud >> >>> On Feb 03, 2018, at 09:35 PM, John-Val Rose wrote: >>> >> >>> Well, then one of us is "off topic"... >>> >>> >>> Kevin Rushforth: >>> >>> "We are specifically looking to discuss ideas around the following areas: >>> * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) >>> * Code review policies >>> * API / feature review policies >>> * Code review tools (we currently use webrev, but that isn't set in stone)" >>> >>>> On 4 February 2018 at 13:29, Stephen Desofi wrote: >>> >>>> John, >>>> >>>> I think you and I are thinking on two different levels. You are talking about the mechanics of making contributing to JavaFX easier. I am talking about making the motivations of contributing to JavaFX easier. >>>> >>>> Steve >>>> >>>> Sent from iCloud >>>> >>>>> On Feb 03, 2018, at 09:14 PM, John-Val Rose wrote: >>>>> >>>> >>>>> Stephen, >>>>> >>>>> 1. Swift and your "crystal ball" view of its spectacular success in the future has nothing whatsoever to do with making contributing to JavaFX easier. >>>>> >>>>> 2. Like everyone else who already wants to contribute to JavaFX, we don't need someone to provide us with "a compelling story as to why developers should join and contribute". >>>>> >>>>> 3. TL;DR >>>>> >>>>> John-Val Rose? (trying to be polite)? >>>>> >>>>>> On 4 February 2018 at 12:58, Stephen Desofi wrote: >>>>>> John, >>>>>> >>>>>> The point I am making is that Swift is catching up as a cross platform toolkit and is available on: >>>>>> >>>>>> Mac and iOS, (Full Support) >>>>>> https://www.swift.org >>>>>> >>>>>> Android (early) >>>>>> https://academy.realm.io/posts/swift-on-android/ >>>>>> >>>>>> Linux: (early) >>>>>> >>>>>> https://itsfoss.com/use-swift-linux/ >>>>>> >>>>>> Windows: (early) >>>>>> >>>>>> https://www.infoworld.com/article/3067364/open-source-tools/swift-for-windows-arrives-at-last-but-as-an-unofficial-port.html >>>>>> >>>>>> >>>>>> Browser: (very Preliminary) >>>>>> >>>>>> https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly >>>>>> >>>>>> Server Side: (Mac and Linux) >>>>>> https://www.swift.org >>>>>> >>>>>> >>>>>> So my point is that soon Swift will steal the Cross Platform Mantra from Java. It is happening very quickly and Swift has great graphics and gaming capabilities as well. >>>>>> >>>>>> Why would a new developer start with Java? If we are looking 10 years out, I think Apple is coming head on. >>>>>> >>>>>> Also when you say this thread is about the ease with which the community can contribute to JavaFX, it begs the question "what kinds of contribution?". Are we here to push the platform forward and contribute new ideas or just do bug fixes? >>>>>> >>>>>> Swift is a real threat to Java being the cross platform development King. Java can hold on to that story for only a couple more years. It surely won't last. >>>>>> >>>>>> Dart also runs on Android and iOS via Flutter, has Server side Dart option, runs in the Browser very well today with full support for SVG and Canvas -- and if WebGPU becomes a Web standard, Google will most certainly support it. >>>>>> >>>>>> Looking toward the future, if Java doesn't run in the browser, doesn't support games on any platform, and only works on iOS and Android via Gluon VM, and does it with only limited graphics capability, then I think JavaFX will be a tough sell in the future. Even tougher than it is today. >>>>>> >>>>>> If the point of the discussion is to build the developer community, I think we first need a compelling story as to why developers should join and contribute. >>>>>> >>>>>> The fact that I am using Dart and JavaFX, and I am seriously considering if I should switch to Dart everywhere, or to Dart and Swift (instead of Dart and FX) means JavaFX doesn't have the lead we think it does. I love JavaFX and would love to contribute, but it's hard when I myself am looking at other options mainly because I also want my software to be here 10 years from now, and I am seriously questioning if JavaFX will keep up. >>>>>> >>>>>> I think there is a small window of opportunity for JavaFX to make a stand before it is permanently relegated to a Server side language. This cross platform story won't fly too much longer, especially when Swift starts to run everywhere and in the browser too, and if Google does the same thing with Dart, and they both support games, where will Java be? >>>>>> >>>>>> If we are looking 10 years out then surely this will happen. The big question is what will we do, and where will JavaFX be? >>>>>> >>>>>> Steve Desofi >>>>>> >>>>>> >>>>>> >>>>>>> On Feb 03, 2018, at 03:09 PM, John-Val Rose wrote: >>>>>>> >>>>>> >>>>>>> >>>>>>> Stephen - I?m not quite following you. >>>>>>> >>>>>>> This thread is about improving the ease with which the community can contribute to JavaFX. >>>>>>> >>>>>>> I see no point in comparing JavaFX (a cross platform graphics toolkit for JVM languages) with a Swift (a general purpose programming language that runs on Apple hardware). >>>>>>> >>>>>>>> On 4 Feb 2018, at 00:18, Stephen Desofi wrote: >>>>>>>> >>>>>>>> This begs the question, why has the bar been set too low? I am new to this community and don?t know much history other than a couple weeks of bug fix messages flying by. >>>>>>>> >>>>>>>> I am not even clear of what our role and purpose is supposed to be. Are we here for only bug fixes, and follow the direction and flow that is already set, or as contributors would we be allowed to contribute to the goals and direction of JavaFX? >>>>>>>> >>>>>>>> FX is a good platform with great potential, but it biggest deficiency is ?mind share?. People don?t see too many real world accomplishments that knock your socks off. Most people use web and phone to run apps. PC and Desktop apps are a small part of the market. >>>>>>>> >>>>>>>> Gluon has just recently released gluon VM and Gluon Mobile to allow FX on phones and tablets. >>>>>>>> >>>>>>>> The problem I see is once I can use FX on phones how will it compete with Swift? >>>>>>>> >>>>>>>> True that ?write once, run everywhere? is important and Java has a lead over Swift. But Swift has a lead on capability. >>>>>>>> >>>>>>>> In the end Swift will catch up with Java in the ?write once, run anywhere? mantra. Will FX catch up with Swift in graphics by then? >>>>>>>> >>>>>>>> Java has a lead in many areas, but if we look 10 years out, it seems clear to me that Java needs to raise the bar or face extinction as a client side development platform or forever be confined to the server. >>>>>>>> >>>>>>>> This is why I need some clarification as to what our role as contributors is going to be. I don?t believe an open source project can flourish if the contributors have no say or stake in the direction. >>>>>>>> >>>>>>>> Steve Desofi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>>> On Feb 2, 2018, at 11:55 PM, John-Val Rose wrote: >>>>>>>>> >>>>>>>>> I think Kevin outlined in his opening post what would be considered "out of scope". >>>>>>>>> >>>>>>>>> However, I agree with you on the basic premise that, in general, the bar has been set way too low as to the potential use cases and performance of JavaFX. In fact, I firmly believe that games & complex visualisations etc. *should* be possible with JavaFX given that most of the heavy lifting is being done by the GPU. It's just that, at the moment, the scene graph rendering pipeline is significantly slower than it could be and it is for this reason that we don't find applications using advanced 3D graphics & animations etc. (like we see in games) being built with JavaFX. It's just not possible when the node count reaches even a very small threshold. >>>>>>>>> >>>>>>>>> This is a topic I have tried to discuss numerous times and also believe that I can improve the performance of the scene graph rendering in a very tangible way. >>>>>>>>> >>>>>>>>> If things pan-out as they are being described and becoming & being a contributor is simplified to the extent where it justifies me devoting a large chunk of my time to OpenJFX, this is probably what I would want to work on first. >>>>>>>>> >>>>>>>>> ??Graciously, >>>>>>>>> >>>>>>>>> John-Val Rose >>>>>>>>> >>>>>>>>>> On 3 February 2018 at 14:07, Stephen Desofi wrote: >>>>>>>>>> I don?t understand why discussing new graphics capabilities such as gaming or WebGPU, etc is so off limits. Can you explain that? >>>>>>>>>> >>>>>>>>>> Steve Desofi >>>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>> > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth wrote: >>>>>>>>>> > >>>>>>>>>> > Looks like we have some good discussion so far. >>>>>>>>>> > >>>>>>>>>> > I see a few themes emerging (build/test, sandbox on GitHub, ease of filing bugs, etc) along with some discussion on graphics performance (which is fine as long as the discussion doesn't veer too far into discussing specific graphics features). >>>>>>>>>> > >>>>>>>>>> > I'll let more folks chime in before I reply to anything specifically (and I'll be offline over the weekend anyway). >>>>>>>>>> > >>>>>>>>>> > Thanks! >>>>>>>>>> > >>>>>>>>>> > -- Kevin >>>>>>>>>> > >>>>>>>>> >>>>> >>> From nlisker at gmail.com Mon Feb 5 00:29:18 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 5 Feb 2018 02:29:18 +0200 Subject: More community participation in JavaFX Message-ID: Hello, As someone who has recently made the climb and managed to build OpenJFX with OpenJDK on Win 10 I might have some relevant input. --- Building OpenJFX --- * With the recently updated instructions on the Wiki, building OpenJFX is not that hard. Having to build OpenJDK for that was a real headache because their instructions and build tools are not up to date ( https://bugs.openjdk.java.net/browse/JDK-8194645). * The above doesn't mean that the process shouldn't be made easier. Ideally, it would be the as easy as working on most open source projects on Github (not advocating git over hg): clone into the IDE and start working; when a fix is ready, submit a PR. Don't know if it's technically possible in this case, but it's a target. * The repository needs a good cleanup before contributors start cloning ( bugs.openjdk.java.net/browse/JDK-8196198). --- Working on OpenJFX --- * It should be clear which tests need to run for a specific patch. Changes can be made anywhere from the documentation level to native code level and there's no reason to run the same tests for all of these. If the process can be automate it's even better. * The Webrev tool seems archaic to me (and part of its output is broken as far as I could tell). An IDE can create diff patches with a couple of clicks. * The Jcheck tool seems archaic to me. It should be ported to IDE formatters which are to be distributed with the source. No reason to run a tool that tells me which whitespaces I need to go back and change when something like Ctrl+Shift+F in an IDE finishes the job. --- Wiki --- * The Wiki could be open sourced as well (like other Wikis). I could definitely update a page or 2 there and so would other developers as they gain knowledge. I don't know yet how permissions for that should be handled. * Code conventions should be clearly listed. * Separate sections with instructions should be made for: (1) cloning and building, (2) modifying, (3) running tests, (4) submitting, and (5) reviewing. * Old sections should be cleaned up (I don't think Discussions is useful anymore). --- Review policy --- * I have no experience with review policies or project roles so I can't help here much (maybe after a discussion starts). * One thing I do know is that reviewers should be extremely knowledgeable, which means that there aren't many qualified. Because of this, if it becomes "too" easy to contribute to OpenJFX, careful measures need to be taken as to not to swamp the few reviewers with many patches (though some would say this is an ideal situation). Some sort of review queue might help with organization instead of the current email system. I have no concrete solution for this. - Nir Message: 1 > Date: Thu, 01 Feb 2018 15:26:24 -0800 > From: Kevin Rushforth > To: "openjfx-dev at openjdk.java.net" > Subject: More community participation in JavaFX > Message-ID: <5A73A220.7030706 at oracle.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > To: OpenJFX Developers > > We are looking to grow the community of contributors to the OpenJFX > project, especially serious contributors who will stick around long > enough to become reviewers, to help us keep the platform vibrant. To > this end we are looking at ways to encourage more participation and make > it easier for interested folks to contribute. > > We are specifically looking to discuss ideas around the following areas: > > * Easing barriers to contribution (e.g., making JavaFX easier to build, > better documentation, making it easier to test changes) > > * Code review policies > > * API / feature review policies > > * Code review tools (we currently use webrev, but that isn't set in stone) > > > To keep this thread productive, the following are explicitly out of scope: > > * Discussion of specific features or bugs that you would like to > implement (or wish someone else would) > > * Discussion about platform support > > * Discussion about version control systems (e.g., hg versus git), > hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus > github), etc...at least for now. We are aware of the potential benefits > of such changes, but we'd like to focus our efforts on higher-leverage > things we can do in the short term. > > * Discussion about the requirement of a signed OCA to become a contributor > > * Off-topic or tangential commentary about OpenJFX that isn't directly > related to the topic at hand > > > As a starting point for discussion, here are some areas I think need > improvement; I'm sure there are others: > > I. Helping contributors get started > > It isn?t as easy to get started with OpenJFX as it should be. We want to > make it easier for potential OpenJFX contributors to get started. Here > are some ideas that I think might help: > > * Improve the build instructions / Wiki (I made a first start, but there > is much more to be done) > > * Make the build itself more resilient where possible, and provide > better error messages, specifically when dealing with native compilers > and libraries > > * Add an option to skip building all native code and use prebuilt > binaries (like we do already for media and webkit); this is tracked by > JDK-8092279, but it hasn?t been looked at recently > > * Make it easier to build / test your local OpenJFX build using an > OpenJDK build (currently the only way to do this is to build OpenJDK > locally, after using configure to point to your just-built javafx.* > modules). > > * Provide step-by-step instructions for how to make a contribution, > including testing requirements; a lot of the pieces are there, but are > out of date or scattered in several places. As part of this, we could > have a section on how to contribute docs, samples or tests, since that > is often a good place to start. > > * Provide a sandbox environment where contributors can discuss and test > ideas. For example, an OpenJFX mirror on github, potentially connected > to AdoptOpenJDK. > > > II. Code reviews and API reviews > > Code reviews are important to maintain high-quality contributions, but > we recognize that not every type of change needs the same level of > review. Without lowering our standards of quality, we want to make it > easier to get low-impact changes (simple bug fixes) accepted. > > There are three categories of changes, each of which might merit a > different review standard: > > 1. Low-impact bug fixes. These are typically isolated bug fixes with > little or no impact beyond fixing the bug in question; included in this > category are test fixes (including new tests) doc fixes, and fixes to > sample applications (including new samples). > > 2. Higher impact bug fixes or RFEs. These include changes to the > implementation that potentially have a performance or behavioral impact, > or are otherwise broad in scope. Some larger bug fixes will fall into > this category, as will fixes in high-risk areas (e.g., CSS). > > 3. New features / API additions. In addition to reviewing the > implementation, we will need a separate approval process for the new API > / feature (such as the CSR, which is what we use now, or a similar > process). > > We take compatibility seriously, so anything that adds new API needs to > be done with an eye towards supporting it for at least 10 years. We > don't want to add new public API without that level of commitment. Every > new feature forecloses on alternate future features. Significant effort > must be taken to think about "if we did this, what could it interact > with in the future?" Also, anything with a large potential impact on > performance or behavioral compatibility needs to be looked at carefully. > > Put another way, we want to encourage thinking about new features or new > API in terms of a design / stewardship process; to think in terms of > questions like "what's the right thing for JavaFX in the next 10+ years" > rather than "here's some code that solves my problem, please take it". > > > As a stake in the ground, I might suggest the following: > > * All changes need at least one reviewer other than the person making > the change who can evaluate the change for correctness and consistency. > For simple bug fixes, a single reviewer may be sufficient. Of course, > one of our big challenges in all this is: "how do we grow more > reviewers?", by which I mean "how do we facilitate getting contributors > with enough expertise in a given area to eventually be able to > effectively review contributions from others?" > > * We need clear criteria for the other two categories that balance > process efficiency with the desire to maintain compatibility and > stability. API changes need to be approved by a lead. My thought is to > combine the last two into a single category for purposes of reviewing > the implementation. Anything that affects public API or behavioral > compatibility will require CSR or similar approval, over and above the > implementation review, which seems sufficient. > > * I recommend that we formalize the concept of reviewers, using the > OpenJDK Reviewer role for the Project. We might also consider if we want > to make any changes to the criteria used by the JDK Project for becoming > an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK bylaws > allow projects a fair degree of latitude to define these criteria, so we > might consider making some modifications. For example, we might make it > somewhat easier for a Contributor to become an Author, or for a > Committer to become a Reviewer. I have some thoughts on this, but want > to hear from others first. > > > I look forward to feedback on this proposal, and hope it will spark a > productive discussion. > > -- Kevin Rushforth, OpenJFX Project Lead > From mike.ennen at gmail.com Mon Feb 5 00:40:38 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Sun, 4 Feb 2018 17:40:38 -0700 Subject: More community participation in JavaFX In-Reply-To: References: Message-ID: Great points, Nir. We share the same hopes. I just wanted to piggy-back on the wiki thing: " * The Wiki could be open sourced as well (like other Wikis). I could definitely update a page or 2 there and so would other developers as they gain knowledge. I don't know yet how permissions for that should be handled." This is another thing that we could use the GitHub staging repository for. The staging repository could have a wiki (projects on GitHub can have one) that is editable by all, and then maybe once a month or so someone with permissions to edit to official wiki can sync with the new, reviewed changes (the once-a-month time constraint is very flexible). I am just trying to explain how the GitHub repository "one-way mirror" (potentially linked with/managed by Adopt an OpenJDK) can act as a staging ground for all kinds of contributions to OpenJFX. By the way, I am trying to cleanup the groundwork I did on getting Appveyor builds to run for openjfx, if indeed it is decided to setup such a staging repository. You can see my efforts here: https://raw.githubusercontent.com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057/appveyor.yml If the GitHub repository was setup, changes such as these to add CI infrastructure would never be adopted by upstream OpenJFX, but would allow for developer's to get good feedback on test results for all supported platforms when they open a PR. Merging a PR on the public GitHub repository means, in my opinion, that it is ready to be opened as an upstream bug/feature request. Automating the process with patch sets, webrevs, formatting/lint results, etc. would be the most ideal situation and I would be happy to contribute to these efforts. Regards, Michael Ennen On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker wrote: > Hello, > > As someone who has recently made the climb and managed to build OpenJFX > with OpenJDK on Win 10 I might have some relevant input. > > --- Building OpenJFX --- > > * With the recently updated instructions on the Wiki, building OpenJFX is > not that hard. Having to build OpenJDK for that was a real headache because > their instructions and build tools are not up to date ( > https://bugs.openjdk.java.net/browse/JDK-8194645). > * The above doesn't mean that the process shouldn't be made easier. > Ideally, it would be the as easy as working on most open source projects on > Github (not advocating git over hg): clone into the IDE and start working; > when a fix is ready, submit a PR. Don't know if it's technically possible > in this case, but it's a target. > * The repository needs a good cleanup before contributors start cloning ( > bugs.openjdk.java.net/browse/JDK-8196198). > > --- Working on OpenJFX --- > > * It should be clear which tests need to run for a specific patch. Changes > can be made anywhere from the documentation level to native code level and > there's no reason to run the same tests for all of these. If the process > can be automate it's even better. > * The Webrev tool seems archaic to me (and part of its output is broken as > far as I could tell). An IDE can create diff patches with a couple of > clicks. > * The Jcheck tool seems archaic to me. It should be ported to IDE > formatters which are to be distributed with the source. No reason to run a > tool that tells me which whitespaces I need to go back and change when > something like Ctrl+Shift+F in an IDE finishes the job. > > --- Wiki --- > > * The Wiki could be open sourced as well (like other Wikis). I could > definitely update a page or 2 there and so would other developers as they > gain knowledge. I don't know yet how permissions for that should be > handled. > * Code conventions should be clearly listed. > * Separate sections with instructions should be made for: (1) cloning and > building, (2) modifying, (3) running tests, (4) submitting, and (5) > reviewing. > * Old sections should be cleaned up (I don't think Discussions is useful > anymore). > > --- Review policy --- > > * I have no experience with review policies or project roles so I can't > help here much (maybe after a discussion starts). > * One thing I do know is that reviewers should be extremely knowledgeable, > which means that there aren't many qualified. Because of this, if it > becomes "too" easy to contribute to OpenJFX, careful measures need to be > taken as to not to swamp the few reviewers with many patches (though some > would say this is an ideal situation). Some sort of review queue might help > with organization instead of the current email system. I have no concrete > solution for this. > > - Nir > > > Message: 1 > > Date: Thu, 01 Feb 2018 15:26:24 -0800 > > From: Kevin Rushforth > > To: "openjfx-dev at openjdk.java.net" > > Subject: More community participation in JavaFX > > Message-ID: <5A73A220.7030706 at oracle.com> > > Content-Type: text/plain; charset=windows-1252; format=flowed > > > > To: OpenJFX Developers > > > > We are looking to grow the community of contributors to the OpenJFX > > project, especially serious contributors who will stick around long > > enough to become reviewers, to help us keep the platform vibrant. To > > this end we are looking at ways to encourage more participation and make > > it easier for interested folks to contribute. > > > > We are specifically looking to discuss ideas around the following areas: > > > > * Easing barriers to contribution (e.g., making JavaFX easier to build, > > better documentation, making it easier to test changes) > > > > * Code review policies > > > > * API / feature review policies > > > > * Code review tools (we currently use webrev, but that isn't set in > stone) > > > > > > To keep this thread productive, the following are explicitly out of > scope: > > > > * Discussion of specific features or bugs that you would like to > > implement (or wish someone else would) > > > > * Discussion about platform support > > > > * Discussion about version control systems (e.g., hg versus git), > > hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus > > github), etc...at least for now. We are aware of the potential benefits > > of such changes, but we'd like to focus our efforts on higher-leverage > > things we can do in the short term. > > > > * Discussion about the requirement of a signed OCA to become a > contributor > > > > * Off-topic or tangential commentary about OpenJFX that isn't directly > > related to the topic at hand > > > > > > As a starting point for discussion, here are some areas I think need > > improvement; I'm sure there are others: > > > > I. Helping contributors get started > > > > It isn?t as easy to get started with OpenJFX as it should be. We want to > > make it easier for potential OpenJFX contributors to get started. Here > > are some ideas that I think might help: > > > > * Improve the build instructions / Wiki (I made a first start, but there > > is much more to be done) > > > > * Make the build itself more resilient where possible, and provide > > better error messages, specifically when dealing with native compilers > > and libraries > > > > * Add an option to skip building all native code and use prebuilt > > binaries (like we do already for media and webkit); this is tracked by > > JDK-8092279, but it hasn?t been looked at recently > > > > * Make it easier to build / test your local OpenJFX build using an > > OpenJDK build (currently the only way to do this is to build OpenJDK > > locally, after using configure to point to your just-built javafx.* > > modules). > > > > * Provide step-by-step instructions for how to make a contribution, > > including testing requirements; a lot of the pieces are there, but are > > out of date or scattered in several places. As part of this, we could > > have a section on how to contribute docs, samples or tests, since that > > is often a good place to start. > > > > * Provide a sandbox environment where contributors can discuss and test > > ideas. For example, an OpenJFX mirror on github, potentially connected > > to AdoptOpenJDK. > > > > > > II. Code reviews and API reviews > > > > Code reviews are important to maintain high-quality contributions, but > > we recognize that not every type of change needs the same level of > > review. Without lowering our standards of quality, we want to make it > > easier to get low-impact changes (simple bug fixes) accepted. > > > > There are three categories of changes, each of which might merit a > > different review standard: > > > > 1. Low-impact bug fixes. These are typically isolated bug fixes with > > little or no impact beyond fixing the bug in question; included in this > > category are test fixes (including new tests) doc fixes, and fixes to > > sample applications (including new samples). > > > > 2. Higher impact bug fixes or RFEs. These include changes to the > > implementation that potentially have a performance or behavioral impact, > > or are otherwise broad in scope. Some larger bug fixes will fall into > > this category, as will fixes in high-risk areas (e.g., CSS). > > > > 3. New features / API additions. In addition to reviewing the > > implementation, we will need a separate approval process for the new API > > / feature (such as the CSR, which is what we use now, or a similar > > process). > > > > We take compatibility seriously, so anything that adds new API needs to > > be done with an eye towards supporting it for at least 10 years. We > > don't want to add new public API without that level of commitment. Every > > new feature forecloses on alternate future features. Significant effort > > must be taken to think about "if we did this, what could it interact > > with in the future?" Also, anything with a large potential impact on > > performance or behavioral compatibility needs to be looked at carefully. > > > > Put another way, we want to encourage thinking about new features or new > > API in terms of a design / stewardship process; to think in terms of > > questions like "what's the right thing for JavaFX in the next 10+ years" > > rather than "here's some code that solves my problem, please take it". > > > > > > As a stake in the ground, I might suggest the following: > > > > * All changes need at least one reviewer other than the person making > > the change who can evaluate the change for correctness and consistency. > > For simple bug fixes, a single reviewer may be sufficient. Of course, > > one of our big challenges in all this is: "how do we grow more > > reviewers?", by which I mean "how do we facilitate getting contributors > > with enough expertise in a given area to eventually be able to > > effectively review contributions from others?" > > > > * We need clear criteria for the other two categories that balance > > process efficiency with the desire to maintain compatibility and > > stability. API changes need to be approved by a lead. My thought is to > > combine the last two into a single category for purposes of reviewing > > the implementation. Anything that affects public API or behavioral > > compatibility will require CSR or similar approval, over and above the > > implementation review, which seems sufficient. > > > > * I recommend that we formalize the concept of reviewers, using the > > OpenJDK Reviewer role for the Project. We might also consider if we want > > to make any changes to the criteria used by the JDK Project for becoming > > an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK bylaws > > allow projects a fair degree of latitude to define these criteria, so we > > might consider making some modifications. For example, we might make it > > somewhat easier for a Contributor to become an Author, or for a > > Committer to become a Reviewer. I have some thoughts on this, but want > > to hear from others first. > > > > > > I look forward to feedback on this proposal, and hope it will spark a > > productive discussion. > > > > -- Kevin Rushforth, OpenJFX Project Lead > > > From nlisker at gmail.com Mon Feb 5 01:21:22 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 5 Feb 2018 03:21:22 +0200 Subject: More community participation in JavaFX In-Reply-To: References: Message-ID: So if a community ran GitHub is used for staging, who will approve PRs for the code and the Wiki of the GitHub repo? On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen wrote: > Great points, Nir. We share the same hopes. I just wanted to piggy-back on > the > wiki thing: > > " * The Wiki could be open sourced as well (like other Wikis). I could > definitely update a page or 2 there and so would other developers as they > gain knowledge. I don't know yet how permissions for that should be > handled." > > This is another thing that we could use the GitHub staging repository for. > The staging repository could have a wiki (projects on GitHub can have one) > that is editable by all, and then maybe once a month or so someone with > permissions > to edit to official wiki can sync with the new, reviewed changes (the > once-a-month > time constraint is very flexible). > > I am just trying to explain how the GitHub repository "one-way mirror" > (potentially linked > with/managed by Adopt an OpenJDK) can act as a staging ground for all > kinds of contributions to > OpenJFX. > > By the way, I am trying to cleanup the groundwork I did on getting > Appveyor builds to > run for openjfx, if indeed it is decided to setup such a staging > repository. You can > see my efforts here: https://raw.githubusercontent.com/brcolow/openjfx/ > f1b8978849fc371683b40931c17020421acc0057/appveyor.yml > > If the GitHub repository was setup, changes such as these to add CI > infrastructure would > never be adopted by upstream OpenJFX, but would allow for developer's to > get good > feedback on test results for all supported platforms when they open a PR. > Merging a PR > on the public GitHub repository means, in my opinion, that it is ready to > be opened as > an upstream bug/feature request. Automating the process with patch sets, > webrevs, formatting/lint > results, etc. would be the most ideal situation and I would be happy to > contribute to these > efforts. > > Regards, > > Michael Ennen > > > > On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker wrote: > >> Hello, >> >> As someone who has recently made the climb and managed to build OpenJFX >> with OpenJDK on Win 10 I might have some relevant input. >> >> --- Building OpenJFX --- >> >> * With the recently updated instructions on the Wiki, building OpenJFX is >> not that hard. Having to build OpenJDK for that was a real headache >> because >> their instructions and build tools are not up to date ( >> https://bugs.openjdk.java.net/browse/JDK-8194645). >> * The above doesn't mean that the process shouldn't be made easier. >> Ideally, it would be the as easy as working on most open source projects >> on >> Github (not advocating git over hg): clone into the IDE and start working; >> when a fix is ready, submit a PR. Don't know if it's technically possible >> in this case, but it's a target. >> * The repository needs a good cleanup before contributors start cloning ( >> bugs.openjdk.java.net/browse/JDK-8196198). >> >> --- Working on OpenJFX --- >> >> * It should be clear which tests need to run for a specific patch. Changes >> can be made anywhere from the documentation level to native code level and >> there's no reason to run the same tests for all of these. If the process >> can be automate it's even better. >> * The Webrev tool seems archaic to me (and part of its output is broken as >> far as I could tell). An IDE can create diff patches with a couple of >> clicks. >> * The Jcheck tool seems archaic to me. It should be ported to IDE >> formatters which are to be distributed with the source. No reason to run a >> tool that tells me which whitespaces I need to go back and change when >> something like Ctrl+Shift+F in an IDE finishes the job. >> >> --- Wiki --- >> >> * The Wiki could be open sourced as well (like other Wikis). I could >> definitely update a page or 2 there and so would other developers as they >> gain knowledge. I don't know yet how permissions for that should be >> handled. >> * Code conventions should be clearly listed. >> * Separate sections with instructions should be made for: (1) cloning and >> building, (2) modifying, (3) running tests, (4) submitting, and (5) >> reviewing. >> * Old sections should be cleaned up (I don't think Discussions is useful >> anymore). >> >> --- Review policy --- >> >> * I have no experience with review policies or project roles so I can't >> help here much (maybe after a discussion starts). >> * One thing I do know is that reviewers should be extremely knowledgeable, >> which means that there aren't many qualified. Because of this, if it >> becomes "too" easy to contribute to OpenJFX, careful measures need to be >> taken as to not to swamp the few reviewers with many patches (though some >> would say this is an ideal situation). Some sort of review queue might >> help >> with organization instead of the current email system. I have no concrete >> solution for this. >> >> - Nir >> >> >> Message: 1 >> > Date: Thu, 01 Feb 2018 15:26:24 -0800 >> > From: Kevin Rushforth >> > To: "openjfx-dev at openjdk.java.net" >> > Subject: More community participation in JavaFX >> > Message-ID: <5A73A220.7030706 at oracle.com> >> > Content-Type: text/plain; charset=windows-1252; format=flowed >> > >> > To: OpenJFX Developers >> > >> > We are looking to grow the community of contributors to the OpenJFX >> > project, especially serious contributors who will stick around long >> > enough to become reviewers, to help us keep the platform vibrant. To >> > this end we are looking at ways to encourage more participation and make >> > it easier for interested folks to contribute. >> > >> > We are specifically looking to discuss ideas around the following areas: >> > >> > * Easing barriers to contribution (e.g., making JavaFX easier to build, >> > better documentation, making it easier to test changes) >> > >> > * Code review policies >> > >> > * API / feature review policies >> > >> > * Code review tools (we currently use webrev, but that isn't set in >> stone) >> > >> > >> > To keep this thread productive, the following are explicitly out of >> scope: >> > >> > * Discussion of specific features or bugs that you would like to >> > implement (or wish someone else would) >> > >> > * Discussion about platform support >> > >> > * Discussion about version control systems (e.g., hg versus git), >> > hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus >> > github), etc...at least for now. We are aware of the potential benefits >> > of such changes, but we'd like to focus our efforts on higher-leverage >> > things we can do in the short term. >> > >> > * Discussion about the requirement of a signed OCA to become a >> contributor >> > >> > * Off-topic or tangential commentary about OpenJFX that isn't directly >> > related to the topic at hand >> > >> > >> > As a starting point for discussion, here are some areas I think need >> > improvement; I'm sure there are others: >> > >> > I. Helping contributors get started >> > >> > It isn?t as easy to get started with OpenJFX as it should be. We want to >> > make it easier for potential OpenJFX contributors to get started. Here >> > are some ideas that I think might help: >> > >> > * Improve the build instructions / Wiki (I made a first start, but there >> > is much more to be done) >> > >> > * Make the build itself more resilient where possible, and provide >> > better error messages, specifically when dealing with native compilers >> > and libraries >> > >> > * Add an option to skip building all native code and use prebuilt >> > binaries (like we do already for media and webkit); this is tracked by >> > JDK-8092279, but it hasn?t been looked at recently >> > >> > * Make it easier to build / test your local OpenJFX build using an >> > OpenJDK build (currently the only way to do this is to build OpenJDK >> > locally, after using configure to point to your just-built javafx.* >> > modules). >> > >> > * Provide step-by-step instructions for how to make a contribution, >> > including testing requirements; a lot of the pieces are there, but are >> > out of date or scattered in several places. As part of this, we could >> > have a section on how to contribute docs, samples or tests, since that >> > is often a good place to start. >> > >> > * Provide a sandbox environment where contributors can discuss and test >> > ideas. For example, an OpenJFX mirror on github, potentially connected >> > to AdoptOpenJDK. >> > >> > >> > II. Code reviews and API reviews >> > >> > Code reviews are important to maintain high-quality contributions, but >> > we recognize that not every type of change needs the same level of >> > review. Without lowering our standards of quality, we want to make it >> > easier to get low-impact changes (simple bug fixes) accepted. >> > >> > There are three categories of changes, each of which might merit a >> > different review standard: >> > >> > 1. Low-impact bug fixes. These are typically isolated bug fixes with >> > little or no impact beyond fixing the bug in question; included in this >> > category are test fixes (including new tests) doc fixes, and fixes to >> > sample applications (including new samples). >> > >> > 2. Higher impact bug fixes or RFEs. These include changes to the >> > implementation that potentially have a performance or behavioral impact, >> > or are otherwise broad in scope. Some larger bug fixes will fall into >> > this category, as will fixes in high-risk areas (e.g., CSS). >> > >> > 3. New features / API additions. In addition to reviewing the >> > implementation, we will need a separate approval process for the new API >> > / feature (such as the CSR, which is what we use now, or a similar >> > process). >> > >> > We take compatibility seriously, so anything that adds new API needs to >> > be done with an eye towards supporting it for at least 10 years. We >> > don't want to add new public API without that level of commitment. Every >> > new feature forecloses on alternate future features. Significant effort >> > must be taken to think about "if we did this, what could it interact >> > with in the future?" Also, anything with a large potential impact on >> > performance or behavioral compatibility needs to be looked at carefully. >> > >> > Put another way, we want to encourage thinking about new features or new >> > API in terms of a design / stewardship process; to think in terms of >> > questions like "what's the right thing for JavaFX in the next 10+ years" >> > rather than "here's some code that solves my problem, please take it". >> > >> > >> > As a stake in the ground, I might suggest the following: >> > >> > * All changes need at least one reviewer other than the person making >> > the change who can evaluate the change for correctness and consistency. >> > For simple bug fixes, a single reviewer may be sufficient. Of course, >> > one of our big challenges in all this is: "how do we grow more >> > reviewers?", by which I mean "how do we facilitate getting contributors >> > with enough expertise in a given area to eventually be able to >> > effectively review contributions from others?" >> > >> > * We need clear criteria for the other two categories that balance >> > process efficiency with the desire to maintain compatibility and >> > stability. API changes need to be approved by a lead. My thought is to >> > combine the last two into a single category for purposes of reviewing >> > the implementation. Anything that affects public API or behavioral >> > compatibility will require CSR or similar approval, over and above the >> > implementation review, which seems sufficient. >> > >> > * I recommend that we formalize the concept of reviewers, using the >> > OpenJDK Reviewer role for the Project. We might also consider if we want >> > to make any changes to the criteria used by the JDK Project for becoming >> > an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK bylaws >> > allow projects a fair degree of latitude to define these criteria, so we >> > might consider making some modifications. For example, we might make it >> > somewhat easier for a Contributor to become an Author, or for a >> > Committer to become a Reviewer. I have some thoughts on this, but want >> > to hear from others first. >> > >> > >> > I look forward to feedback on this proposal, and hope it will spark a >> > productive discussion. >> > >> > -- Kevin Rushforth, OpenJFX Project Lead >> > >> > > From mike.ennen at gmail.com Mon Feb 5 02:46:56 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Sun, 4 Feb 2018 19:46:56 -0700 Subject: More community participation in JavaFX In-Reply-To: References: Message-ID: Those are great questions, and I think with Kevin/Oracle/other OpenJFX devs help we can figure something out. My thinking is that the PR would be reviewed by basically anyone who has free time. I think that, at first, only OpenJFX committers will be able to merge PRs. They would do the final review/merge to the staging repo after it has been reviewed by the "wider audience" which includes people without commit rights (people like us). Then, as this thing evolves, based on the pool of people who are contributing both pull requests and PR reviews, the committers will be able to grant commit privileges to some people in that pool. I can't think of any way that would make it so the changes are as likely to be merged upstream as possible other than having the current OpenJFX committers paving the way. Hopefully this vision is aligned with Kevin's and hopefully these concrete details can be worked out. Regards, Michael On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker wrote: > So if a community ran GitHub is used for staging, who will approve PRs for > the code and the Wiki of the GitHub repo? > > On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen > wrote: > >> Great points, Nir. We share the same hopes. I just wanted to piggy-back >> on the >> wiki thing: >> >> " * The Wiki could be open sourced as well (like other Wikis). I could >> definitely update a page or 2 there and so would other developers as they >> gain knowledge. I don't know yet how permissions for that should be >> handled." >> >> This is another thing that we could use the GitHub staging repository for. >> The staging repository could have a wiki (projects on GitHub can have one) >> that is editable by all, and then maybe once a month or so someone with >> permissions >> to edit to official wiki can sync with the new, reviewed changes (the >> once-a-month >> time constraint is very flexible). >> >> I am just trying to explain how the GitHub repository "one-way mirror" >> (potentially linked >> with/managed by Adopt an OpenJDK) can act as a staging ground for all >> kinds of contributions to >> OpenJFX. >> >> By the way, I am trying to cleanup the groundwork I did on getting >> Appveyor builds to >> run for openjfx, if indeed it is decided to setup such a staging >> repository. You can >> see my efforts here: https://raw.githubusercontent. >> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057/appveyor.yml >> >> If the GitHub repository was setup, changes such as these to add CI >> infrastructure would >> never be adopted by upstream OpenJFX, but would allow for developer's to >> get good >> feedback on test results for all supported platforms when they open a PR. >> Merging a PR >> on the public GitHub repository means, in my opinion, that it is ready to >> be opened as >> an upstream bug/feature request. Automating the process with patch sets, >> webrevs, formatting/lint >> results, etc. would be the most ideal situation and I would be happy to >> contribute to these >> efforts. >> >> Regards, >> >> Michael Ennen >> >> >> >> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker wrote: >> >>> Hello, >>> >>> As someone who has recently made the climb and managed to build OpenJFX >>> with OpenJDK on Win 10 I might have some relevant input. >>> >>> --- Building OpenJFX --- >>> >>> * With the recently updated instructions on the Wiki, building OpenJFX is >>> not that hard. Having to build OpenJDK for that was a real headache >>> because >>> their instructions and build tools are not up to date ( >>> https://bugs.openjdk.java.net/browse/JDK-8194645). >>> * The above doesn't mean that the process shouldn't be made easier. >>> Ideally, it would be the as easy as working on most open source projects >>> on >>> Github (not advocating git over hg): clone into the IDE and start >>> working; >>> when a fix is ready, submit a PR. Don't know if it's technically possible >>> in this case, but it's a target. >>> * The repository needs a good cleanup before contributors start cloning ( >>> bugs.openjdk.java.net/browse/JDK-8196198). >>> >>> --- Working on OpenJFX --- >>> >>> * It should be clear which tests need to run for a specific patch. >>> Changes >>> can be made anywhere from the documentation level to native code level >>> and >>> there's no reason to run the same tests for all of these. If the process >>> can be automate it's even better. >>> * The Webrev tool seems archaic to me (and part of its output is broken >>> as >>> far as I could tell). An IDE can create diff patches with a couple of >>> clicks. >>> * The Jcheck tool seems archaic to me. It should be ported to IDE >>> formatters which are to be distributed with the source. No reason to run >>> a >>> tool that tells me which whitespaces I need to go back and change when >>> something like Ctrl+Shift+F in an IDE finishes the job. >>> >>> --- Wiki --- >>> >>> * The Wiki could be open sourced as well (like other Wikis). I could >>> definitely update a page or 2 there and so would other developers as they >>> gain knowledge. I don't know yet how permissions for that should be >>> handled. >>> * Code conventions should be clearly listed. >>> * Separate sections with instructions should be made for: (1) cloning and >>> building, (2) modifying, (3) running tests, (4) submitting, and (5) >>> reviewing. >>> * Old sections should be cleaned up (I don't think Discussions is useful >>> anymore). >>> >>> --- Review policy --- >>> >>> * I have no experience with review policies or project roles so I can't >>> help here much (maybe after a discussion starts). >>> * One thing I do know is that reviewers should be extremely >>> knowledgeable, >>> which means that there aren't many qualified. Because of this, if it >>> becomes "too" easy to contribute to OpenJFX, careful measures need to be >>> taken as to not to swamp the few reviewers with many patches (though some >>> would say this is an ideal situation). Some sort of review queue might >>> help >>> with organization instead of the current email system. I have no concrete >>> solution for this. >>> >>> - Nir >>> >>> >>> Message: 1 >>> > Date: Thu, 01 Feb 2018 15:26:24 -0800 >>> > From: Kevin Rushforth >>> > To: "openjfx-dev at openjdk.java.net" >>> > Subject: More community participation in JavaFX >>> > Message-ID: <5A73A220.7030706 at oracle.com> >>> > Content-Type: text/plain; charset=windows-1252; format=flowed >>> > >>> > To: OpenJFX Developers >>> > >>> > We are looking to grow the community of contributors to the OpenJFX >>> > project, especially serious contributors who will stick around long >>> > enough to become reviewers, to help us keep the platform vibrant. To >>> > this end we are looking at ways to encourage more participation and >>> make >>> > it easier for interested folks to contribute. >>> > >>> > We are specifically looking to discuss ideas around the following >>> areas: >>> > >>> > * Easing barriers to contribution (e.g., making JavaFX easier to build, >>> > better documentation, making it easier to test changes) >>> > >>> > * Code review policies >>> > >>> > * API / feature review policies >>> > >>> > * Code review tools (we currently use webrev, but that isn't set in >>> stone) >>> > >>> > >>> > To keep this thread productive, the following are explicitly out of >>> scope: >>> > >>> > * Discussion of specific features or bugs that you would like to >>> > implement (or wish someone else would) >>> > >>> > * Discussion about platform support >>> > >>> > * Discussion about version control systems (e.g., hg versus git), >>> > hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus >>> > github), etc...at least for now. We are aware of the potential benefits >>> > of such changes, but we'd like to focus our efforts on higher-leverage >>> > things we can do in the short term. >>> > >>> > * Discussion about the requirement of a signed OCA to become a >>> contributor >>> > >>> > * Off-topic or tangential commentary about OpenJFX that isn't directly >>> > related to the topic at hand >>> > >>> > >>> > As a starting point for discussion, here are some areas I think need >>> > improvement; I'm sure there are others: >>> > >>> > I. Helping contributors get started >>> > >>> > It isn?t as easy to get started with OpenJFX as it should be. We want >>> to >>> > make it easier for potential OpenJFX contributors to get started. Here >>> > are some ideas that I think might help: >>> > >>> > * Improve the build instructions / Wiki (I made a first start, but >>> there >>> > is much more to be done) >>> > >>> > * Make the build itself more resilient where possible, and provide >>> > better error messages, specifically when dealing with native compilers >>> > and libraries >>> > >>> > * Add an option to skip building all native code and use prebuilt >>> > binaries (like we do already for media and webkit); this is tracked by >>> > JDK-8092279, but it hasn?t been looked at recently >>> > >>> > * Make it easier to build / test your local OpenJFX build using an >>> > OpenJDK build (currently the only way to do this is to build OpenJDK >>> > locally, after using configure to point to your just-built javafx.* >>> > modules). >>> > >>> > * Provide step-by-step instructions for how to make a contribution, >>> > including testing requirements; a lot of the pieces are there, but are >>> > out of date or scattered in several places. As part of this, we could >>> > have a section on how to contribute docs, samples or tests, since that >>> > is often a good place to start. >>> > >>> > * Provide a sandbox environment where contributors can discuss and test >>> > ideas. For example, an OpenJFX mirror on github, potentially connected >>> > to AdoptOpenJDK. >>> > >>> > >>> > II. Code reviews and API reviews >>> > >>> > Code reviews are important to maintain high-quality contributions, but >>> > we recognize that not every type of change needs the same level of >>> > review. Without lowering our standards of quality, we want to make it >>> > easier to get low-impact changes (simple bug fixes) accepted. >>> > >>> > There are three categories of changes, each of which might merit a >>> > different review standard: >>> > >>> > 1. Low-impact bug fixes. These are typically isolated bug fixes with >>> > little or no impact beyond fixing the bug in question; included in this >>> > category are test fixes (including new tests) doc fixes, and fixes to >>> > sample applications (including new samples). >>> > >>> > 2. Higher impact bug fixes or RFEs. These include changes to the >>> > implementation that potentially have a performance or behavioral >>> impact, >>> > or are otherwise broad in scope. Some larger bug fixes will fall into >>> > this category, as will fixes in high-risk areas (e.g., CSS). >>> > >>> > 3. New features / API additions. In addition to reviewing the >>> > implementation, we will need a separate approval process for the new >>> API >>> > / feature (such as the CSR, which is what we use now, or a similar >>> > process). >>> > >>> > We take compatibility seriously, so anything that adds new API needs to >>> > be done with an eye towards supporting it for at least 10 years. We >>> > don't want to add new public API without that level of commitment. >>> Every >>> > new feature forecloses on alternate future features. Significant effort >>> > must be taken to think about "if we did this, what could it interact >>> > with in the future?" Also, anything with a large potential impact on >>> > performance or behavioral compatibility needs to be looked at >>> carefully. >>> > >>> > Put another way, we want to encourage thinking about new features or >>> new >>> > API in terms of a design / stewardship process; to think in terms of >>> > questions like "what's the right thing for JavaFX in the next 10+ >>> years" >>> > rather than "here's some code that solves my problem, please take it". >>> > >>> > >>> > As a stake in the ground, I might suggest the following: >>> > >>> > * All changes need at least one reviewer other than the person making >>> > the change who can evaluate the change for correctness and consistency. >>> > For simple bug fixes, a single reviewer may be sufficient. Of course, >>> > one of our big challenges in all this is: "how do we grow more >>> > reviewers?", by which I mean "how do we facilitate getting contributors >>> > with enough expertise in a given area to eventually be able to >>> > effectively review contributions from others?" >>> > >>> > * We need clear criteria for the other two categories that balance >>> > process efficiency with the desire to maintain compatibility and >>> > stability. API changes need to be approved by a lead. My thought is to >>> > combine the last two into a single category for purposes of reviewing >>> > the implementation. Anything that affects public API or behavioral >>> > compatibility will require CSR or similar approval, over and above the >>> > implementation review, which seems sufficient. >>> > >>> > * I recommend that we formalize the concept of reviewers, using the >>> > OpenJDK Reviewer role for the Project. We might also consider if we >>> want >>> > to make any changes to the criteria used by the JDK Project for >>> becoming >>> > an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK bylaws >>> > allow projects a fair degree of latitude to define these criteria, so >>> we >>> > might consider making some modifications. For example, we might make it >>> > somewhat easier for a Contributor to become an Author, or for a >>> > Committer to become a Reviewer. I have some thoughts on this, but want >>> > to hear from others first. >>> > >>> > >>> > I look forward to feedback on this proposal, and hope it will spark a >>> > productive discussion. >>> > >>> > -- Kevin Rushforth, OpenJFX Project Lead >>> > >>> >> >> > From alexander at nyssen.org Mon Feb 5 07:11:05 2018 From: alexander at nyssen.org (=?utf-8?Q?Alexander_Ny=C3=9Fen?=) Date: Mon, 5 Feb 2018 08:11:05 +0100 Subject: More community participation in JavaFX In-Reply-To: <5A73A220.7030706@oracle.com> References: <5A73A220.7030706@oracle.com> Message-ID: <3C5EF409-A1A6-40DE-A810-6D8D63FB4450@nyssen.org> Hi Kevin, the issue tracker is usually the first contact point for any future contributor. Making it publicly accessible would IMHO be an important first step. Be aware that before being appointed as author, one is not even allowed to reply to questions related to those issues one has created via the web interface. In my eyes that?s at least an unnecessary hurdle, maybe even a deterrent. Regards, Alexander Von meinem iPhone gesendet > Am 02.02.2018 um 00:26 schrieb Kevin Rushforth : > > To: OpenJFX Developers > > We are looking to grow the community of contributors to the OpenJFX project, especially serious contributors who will stick around long enough to become reviewers, to help us keep the platform vibrant. To this end we are looking at ways to encourage more participation and make it easier for interested folks to contribute. > > We are specifically looking to discuss ideas around the following areas: > > * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) > > * Code review policies > > * API / feature review policies > > * Code review tools (we currently use webrev, but that isn't set in stone) > > > To keep this thread productive, the following are explicitly out of scope: > > * Discussion of specific features or bugs that you would like to implement (or wish someone else would) > > * Discussion about platform support > > * Discussion about version control systems (e.g., hg versus git), hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus github), etc...at least for now. We are aware of the potential benefits of such changes, but we'd like to focus our efforts on higher-leverage things we can do in the short term. > > * Discussion about the requirement of a signed OCA to become a contributor > > * Off-topic or tangential commentary about OpenJFX that isn't directly related to the topic at hand > > > As a starting point for discussion, here are some areas I think need improvement; I'm sure there are others: > > I. Helping contributors get started > > It isn?t as easy to get started with OpenJFX as it should be. We want to make it easier for potential OpenJFX contributors to get started. Here are some ideas that I think might help: > > * Improve the build instructions / Wiki (I made a first start, but there is much more to be done) > > * Make the build itself more resilient where possible, and provide better error messages, specifically when dealing with native compilers and libraries > > * Add an option to skip building all native code and use prebuilt binaries (like we do already for media and webkit); this is tracked by JDK-8092279, but it hasn?t been looked at recently > > * Make it easier to build / test your local OpenJFX build using an OpenJDK build (currently the only way to do this is to build OpenJDK locally, after using configure to point to your just-built javafx.* modules). > > * Provide step-by-step instructions for how to make a contribution, including testing requirements; a lot of the pieces are there, but are out of date or scattered in several places. As part of this, we could have a section on how to contribute docs, samples or tests, since that is often a good place to start. > > * Provide a sandbox environment where contributors can discuss and test ideas. For example, an OpenJFX mirror on github, potentially connected to AdoptOpenJDK. > > > II. Code reviews and API reviews > > Code reviews are important to maintain high-quality contributions, but we recognize that not every type of change needs the same level of review. Without lowering our standards of quality, we want to make it easier to get low-impact changes (simple bug fixes) accepted. > > There are three categories of changes, each of which might merit a different review standard: > > 1. Low-impact bug fixes. These are typically isolated bug fixes with little or no impact beyond fixing the bug in question; included in this category are test fixes (including new tests) doc fixes, and fixes to sample applications (including new samples). > > 2. Higher impact bug fixes or RFEs. These include changes to the implementation that potentially have a performance or behavioral impact, or are otherwise broad in scope. Some larger bug fixes will fall into this category, as will fixes in high-risk areas (e.g., CSS). > > 3. New features / API additions. In addition to reviewing the implementation, we will need a separate approval process for the new API / feature (such as the CSR, which is what we use now, or a similar process). > > We take compatibility seriously, so anything that adds new API needs to be done with an eye towards supporting it for at least 10 years. We don't want to add new public API without that level of commitment. Every new feature forecloses on alternate future features. Significant effort must be taken to think about "if we did this, what could it interact with in the future?" Also, anything with a large potential impact on performance or behavioral compatibility needs to be looked at carefully. > > Put another way, we want to encourage thinking about new features or new API in terms of a design / stewardship process; to think in terms of questions like "what's the right thing for JavaFX in the next 10+ years" rather than "here's some code that solves my problem, please take it". > > > As a stake in the ground, I might suggest the following: > > * All changes need at least one reviewer other than the person making the change who can evaluate the change for correctness and consistency. For simple bug fixes, a single reviewer may be sufficient. Of course, one of our big challenges in all this is: "how do we grow more reviewers?", by which I mean "how do we facilitate getting contributors with enough expertise in a given area to eventually be able to effectively review contributions from others?" > > * We need clear criteria for the other two categories that balance process efficiency with the desire to maintain compatibility and stability. API changes need to be approved by a lead. My thought is to combine the last two into a single category for purposes of reviewing the implementation. Anything that affects public API or behavioral compatibility will require CSR or similar approval, over and above the implementation review, which seems sufficient. > > * I recommend that we formalize the concept of reviewers, using the OpenJDK Reviewer role for the Project. We might also consider if we want to make any changes to the criteria used by the JDK Project for becoming an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK bylaws allow projects a fair degree of latitude to define these criteria, so we might consider making some modifications. For example, we might make it somewhat easier for a Contributor to become an Author, or for a Committer to become a Reviewer. I have some thoughts on this, but want to hear from others first. > > > I look forward to feedback on this proposal, and hope it will spark a productive discussion. > > -- Kevin Rushforth, OpenJFX Project Lead > From johan.vos at gluonhq.com Mon Feb 5 09:23:16 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 05 Feb 2018 09:23:16 +0000 Subject: More community participation in JavaFX In-Reply-To: References: Message-ID: Hi Michael, This proposal is very much in line with my thinking as well. The problem is not that we don't have a github clone of OpenJFX. We have a number of them (e.g. I created https://github.com/javafxports/jfx-dev some months ago). We just need a single one that is updated constantly from mainstream, and standardize on that. Let's call that "sandbox" (I would be ok with staging as well, but sandbox is imho more inviting to people who want to try something drastic, e.g. support for Vulkan) The main issue is how to get contributions, review them, and eventually send them upstream. The PR review process is extremely important. If we lower that bar, we loose quality. If the bar is too high, great PR's won't be accepted upstream as there is not enough review time to review it. I agree giving the current OpenJFX committers merge rights for the "sandbox" repository makes sense. Once a public contribution is merged by one of those committers, that same committer can send it upstream to the existing OpenJFX repository. Additional checks will be performed there, mainly in order to make sure the overall "Feel of Java" is preserved. To that purpose, it would help to have a closer alignment with the OpenJDK community. We have to be aware that this will increase the workload of the current committers and reviewers. That is the price we pay for standardization. Rather than everyone creating his own forks of a UI framework in Java, we invest a lot in creating a single, generally agreed one. So in summary, I'm +1 on a 2-phase approach: "open" commits allowed in staging. OpenJFX committers accept PR's (if they are of good quality) and prepare upstream commits for OpenJFX. We hope there will be more contributors who become committers and reviewers in the medium term. - Johan On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen wrote: > Those are great questions, and I think with Kevin/Oracle/other OpenJFX devs > help we > can figure something out. > > My thinking is that the PR would be reviewed by basically anyone who has > free time. > I think that, at first, only OpenJFX committers will be able to merge PRs. > They would > do the final review/merge to the staging repo after it has been reviewed by > the "wider audience" > which includes people without commit rights (people like us). Then, as this > thing evolves, > based on the pool of people who are contributing both pull requests and PR > reviews, > the committers will be able to grant commit privileges to some people in > that pool. > > I can't think of any way that would make it so the changes are as likely to > be > merged upstream as possible other than having the current OpenJFX > committers paving the > way. Hopefully this vision is aligned with Kevin's and hopefully these > concrete details > can be worked out. > > Regards, > Michael > > On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker wrote: > > > So if a community ran GitHub is used for staging, who will approve PRs > for > > the code and the Wiki of the GitHub repo? > > > > On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen > > wrote: > > > >> Great points, Nir. We share the same hopes. I just wanted to piggy-back > >> on the > >> wiki thing: > >> > >> " * The Wiki could be open sourced as well (like other Wikis). I could > >> definitely update a page or 2 there and so would other developers as > they > >> gain knowledge. I don't know yet how permissions for that should be > >> handled." > >> > >> This is another thing that we could use the GitHub staging repository > for. > >> The staging repository could have a wiki (projects on GitHub can have > one) > >> that is editable by all, and then maybe once a month or so someone with > >> permissions > >> to edit to official wiki can sync with the new, reviewed changes (the > >> once-a-month > >> time constraint is very flexible). > >> > >> I am just trying to explain how the GitHub repository "one-way mirror" > >> (potentially linked > >> with/managed by Adopt an OpenJDK) can act as a staging ground for all > >> kinds of contributions to > >> OpenJFX. > >> > >> By the way, I am trying to cleanup the groundwork I did on getting > >> Appveyor builds to > >> run for openjfx, if indeed it is decided to setup such a staging > >> repository. You can > >> see my efforts here: https://raw.githubusercontent. > >> > com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057/appveyor.yml > >> > >> If the GitHub repository was setup, changes such as these to add CI > >> infrastructure would > >> never be adopted by upstream OpenJFX, but would allow for developer's to > >> get good > >> feedback on test results for all supported platforms when they open a > PR. > >> Merging a PR > >> on the public GitHub repository means, in my opinion, that it is ready > to > >> be opened as > >> an upstream bug/feature request. Automating the process with patch sets, > >> webrevs, formatting/lint > >> results, etc. would be the most ideal situation and I would be happy to > >> contribute to these > >> efforts. > >> > >> Regards, > >> > >> Michael Ennen > >> > >> > >> > >> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker wrote: > >> > >>> Hello, > >>> > >>> As someone who has recently made the climb and managed to build OpenJFX > >>> with OpenJDK on Win 10 I might have some relevant input. > >>> > >>> --- Building OpenJFX --- > >>> > >>> * With the recently updated instructions on the Wiki, building OpenJFX > is > >>> not that hard. Having to build OpenJDK for that was a real headache > >>> because > >>> their instructions and build tools are not up to date ( > >>> https://bugs.openjdk.java.net/browse/JDK-8194645). > >>> * The above doesn't mean that the process shouldn't be made easier. > >>> Ideally, it would be the as easy as working on most open source > projects > >>> on > >>> Github (not advocating git over hg): clone into the IDE and start > >>> working; > >>> when a fix is ready, submit a PR. Don't know if it's technically > possible > >>> in this case, but it's a target. > >>> * The repository needs a good cleanup before contributors start > cloning ( > >>> bugs.openjdk.java.net/browse/JDK-8196198). > >>> > >>> --- Working on OpenJFX --- > >>> > >>> * It should be clear which tests need to run for a specific patch. > >>> Changes > >>> can be made anywhere from the documentation level to native code level > >>> and > >>> there's no reason to run the same tests for all of these. If the > process > >>> can be automate it's even better. > >>> * The Webrev tool seems archaic to me (and part of its output is broken > >>> as > >>> far as I could tell). An IDE can create diff patches with a couple of > >>> clicks. > >>> * The Jcheck tool seems archaic to me. It should be ported to IDE > >>> formatters which are to be distributed with the source. No reason to > run > >>> a > >>> tool that tells me which whitespaces I need to go back and change when > >>> something like Ctrl+Shift+F in an IDE finishes the job. > >>> > >>> --- Wiki --- > >>> > >>> * The Wiki could be open sourced as well (like other Wikis). I could > >>> definitely update a page or 2 there and so would other developers as > they > >>> gain knowledge. I don't know yet how permissions for that should be > >>> handled. > >>> * Code conventions should be clearly listed. > >>> * Separate sections with instructions should be made for: (1) cloning > and > >>> building, (2) modifying, (3) running tests, (4) submitting, and (5) > >>> reviewing. > >>> * Old sections should be cleaned up (I don't think Discussions is > useful > >>> anymore). > >>> > >>> --- Review policy --- > >>> > >>> * I have no experience with review policies or project roles so I can't > >>> help here much (maybe after a discussion starts). > >>> * One thing I do know is that reviewers should be extremely > >>> knowledgeable, > >>> which means that there aren't many qualified. Because of this, if it > >>> becomes "too" easy to contribute to OpenJFX, careful measures need to > be > >>> taken as to not to swamp the few reviewers with many patches (though > some > >>> would say this is an ideal situation). Some sort of review queue might > >>> help > >>> with organization instead of the current email system. I have no > concrete > >>> solution for this. > >>> > >>> - Nir > >>> > >>> > >>> Message: 1 > >>> > Date: Thu, 01 Feb 2018 15:26:24 -0800 > >>> > From: Kevin Rushforth > >>> > To: "openjfx-dev at openjdk.java.net" > >>> > Subject: More community participation in JavaFX > >>> > Message-ID: <5A73A220.7030706 at oracle.com> > >>> > Content-Type: text/plain; charset=windows-1252; format=flowed > >>> > > >>> > To: OpenJFX Developers > >>> > > >>> > We are looking to grow the community of contributors to the OpenJFX > >>> > project, especially serious contributors who will stick around long > >>> > enough to become reviewers, to help us keep the platform vibrant. To > >>> > this end we are looking at ways to encourage more participation and > >>> make > >>> > it easier for interested folks to contribute. > >>> > > >>> > We are specifically looking to discuss ideas around the following > >>> areas: > >>> > > >>> > * Easing barriers to contribution (e.g., making JavaFX easier to > build, > >>> > better documentation, making it easier to test changes) > >>> > > >>> > * Code review policies > >>> > > >>> > * API / feature review policies > >>> > > >>> > * Code review tools (we currently use webrev, but that isn't set in > >>> stone) > >>> > > >>> > > >>> > To keep this thread productive, the following are explicitly out of > >>> scope: > >>> > > >>> > * Discussion of specific features or bugs that you would like to > >>> > implement (or wish someone else would) > >>> > > >>> > * Discussion about platform support > >>> > > >>> > * Discussion about version control systems (e.g., hg versus git), > >>> > hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus > >>> > github), etc...at least for now. We are aware of the potential > benefits > >>> > of such changes, but we'd like to focus our efforts on > higher-leverage > >>> > things we can do in the short term. > >>> > > >>> > * Discussion about the requirement of a signed OCA to become a > >>> contributor > >>> > > >>> > * Off-topic or tangential commentary about OpenJFX that isn't > directly > >>> > related to the topic at hand > >>> > > >>> > > >>> > As a starting point for discussion, here are some areas I think need > >>> > improvement; I'm sure there are others: > >>> > > >>> > I. Helping contributors get started > >>> > > >>> > It isn?t as easy to get started with OpenJFX as it should be. We want > >>> to > >>> > make it easier for potential OpenJFX contributors to get started. > Here > >>> > are some ideas that I think might help: > >>> > > >>> > * Improve the build instructions / Wiki (I made a first start, but > >>> there > >>> > is much more to be done) > >>> > > >>> > * Make the build itself more resilient where possible, and provide > >>> > better error messages, specifically when dealing with native > compilers > >>> > and libraries > >>> > > >>> > * Add an option to skip building all native code and use prebuilt > >>> > binaries (like we do already for media and webkit); this is tracked > by > >>> > JDK-8092279, but it hasn?t been looked at recently > >>> > > >>> > * Make it easier to build / test your local OpenJFX build using an > >>> > OpenJDK build (currently the only way to do this is to build OpenJDK > >>> > locally, after using configure to point to your just-built javafx.* > >>> > modules). > >>> > > >>> > * Provide step-by-step instructions for how to make a contribution, > >>> > including testing requirements; a lot of the pieces are there, but > are > >>> > out of date or scattered in several places. As part of this, we could > >>> > have a section on how to contribute docs, samples or tests, since > that > >>> > is often a good place to start. > >>> > > >>> > * Provide a sandbox environment where contributors can discuss and > test > >>> > ideas. For example, an OpenJFX mirror on github, potentially > connected > >>> > to AdoptOpenJDK. > >>> > > >>> > > >>> > II. Code reviews and API reviews > >>> > > >>> > Code reviews are important to maintain high-quality contributions, > but > >>> > we recognize that not every type of change needs the same level of > >>> > review. Without lowering our standards of quality, we want to make it > >>> > easier to get low-impact changes (simple bug fixes) accepted. > >>> > > >>> > There are three categories of changes, each of which might merit a > >>> > different review standard: > >>> > > >>> > 1. Low-impact bug fixes. These are typically isolated bug fixes with > >>> > little or no impact beyond fixing the bug in question; included in > this > >>> > category are test fixes (including new tests) doc fixes, and fixes to > >>> > sample applications (including new samples). > >>> > > >>> > 2. Higher impact bug fixes or RFEs. These include changes to the > >>> > implementation that potentially have a performance or behavioral > >>> impact, > >>> > or are otherwise broad in scope. Some larger bug fixes will fall into > >>> > this category, as will fixes in high-risk areas (e.g., CSS). > >>> > > >>> > 3. New features / API additions. In addition to reviewing the > >>> > implementation, we will need a separate approval process for the new > >>> API > >>> > / feature (such as the CSR, which is what we use now, or a similar > >>> > process). > >>> > > >>> > We take compatibility seriously, so anything that adds new API needs > to > >>> > be done with an eye towards supporting it for at least 10 years. We > >>> > don't want to add new public API without that level of commitment. > >>> Every > >>> > new feature forecloses on alternate future features. Significant > effort > >>> > must be taken to think about "if we did this, what could it interact > >>> > with in the future?" Also, anything with a large potential impact on > >>> > performance or behavioral compatibility needs to be looked at > >>> carefully. > >>> > > >>> > Put another way, we want to encourage thinking about new features or > >>> new > >>> > API in terms of a design / stewardship process; to think in terms of > >>> > questions like "what's the right thing for JavaFX in the next 10+ > >>> years" > >>> > rather than "here's some code that solves my problem, please take > it". > >>> > > >>> > > >>> > As a stake in the ground, I might suggest the following: > >>> > > >>> > * All changes need at least one reviewer other than the person making > >>> > the change who can evaluate the change for correctness and > consistency. > >>> > For simple bug fixes, a single reviewer may be sufficient. Of course, > >>> > one of our big challenges in all this is: "how do we grow more > >>> > reviewers?", by which I mean "how do we facilitate getting > contributors > >>> > with enough expertise in a given area to eventually be able to > >>> > effectively review contributions from others?" > >>> > > >>> > * We need clear criteria for the other two categories that balance > >>> > process efficiency with the desire to maintain compatibility and > >>> > stability. API changes need to be approved by a lead. My thought is > to > >>> > combine the last two into a single category for purposes of reviewing > >>> > the implementation. Anything that affects public API or behavioral > >>> > compatibility will require CSR or similar approval, over and above > the > >>> > implementation review, which seems sufficient. > >>> > > >>> > * I recommend that we formalize the concept of reviewers, using the > >>> > OpenJDK Reviewer role for the Project. We might also consider if we > >>> want > >>> > to make any changes to the criteria used by the JDK Project for > >>> becoming > >>> > an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK > bylaws > >>> > allow projects a fair degree of latitude to define these criteria, so > >>> we > >>> > might consider making some modifications. For example, we might make > it > >>> > somewhat easier for a Contributor to become an Author, or for a > >>> > Committer to become a Reviewer. I have some thoughts on this, but > want > >>> > to hear from others first. > >>> > > >>> > > >>> > I look forward to feedback on this proposal, and hope it will spark a > >>> > productive discussion. > >>> > > >>> > -- Kevin Rushforth, OpenJFX Project Lead > >>> > > >>> > >> > >> > > > From kevin.rushforth at oracle.com Mon Feb 5 14:41:54 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 05 Feb 2018 20:11:54 +0530 Subject: More community participation in JavaFX In-Reply-To: References: Message-ID: <5A786D32.6050600@oracle.com> Yes, this sounds like a good step in the right direction. This would give anyone (with a signed OCA) the ability to create their own branch, commit changes to it, submit a PR, etc. I presume there will be a branch that is an exact mirror of the jfx-dev repo on OpenJDK in addition to the development branch in the sandbox? The only thing to consider is whether it should be Committers or Reviewers that have rights to merge into the sandbox development branch. There are pros / cons of each. I'd probably lean towards having it be Committers, with the idea that a Committer needs to sponsor the patch anyway and would then be able to "take it the rest of the way". The only downside I see is that you could end up with a few patches that get accepted into the sandbox dev branch, but never make it to the upstream jfx-dev repo (or not without significant change). I doubt this will be a big problem in practice. Either way, this could also provide a good alternative to webrev when reviewing the final changes. -- Kevin Johan Vos wrote: > Hi Michael, > > This proposal is very much in line with my thinking as well. > The problem is not that we don't have a github clone of OpenJFX. We have a > number of them (e.g. I created https://github.com/javafxports/jfx-dev some > months ago). We just need a single one that is updated constantly from > mainstream, and standardize on that. Let's call that "sandbox" (I would be > ok with staging as well, but sandbox is imho more inviting to people who > want to try something drastic, e.g. support for Vulkan) > > The main issue is how to get contributions, review them, and eventually > send them upstream. > > The PR review process is extremely important. If we lower that bar, we > loose quality. If the bar is too high, great PR's won't be accepted > upstream as there is not enough review time to review it. > > I agree giving the current OpenJFX committers merge rights for the > "sandbox" repository makes sense. Once a public contribution is merged by > one of those committers, that same committer can send it upstream to the > existing OpenJFX repository. Additional checks will be performed there, > mainly in order to make sure the overall "Feel of Java" is preserved. To > that purpose, it would help to have a closer alignment with the OpenJDK > community. > > We have to be aware that this will increase the workload of the current > committers and reviewers. That is the price we pay for standardization. > Rather than everyone creating his own forks of a UI framework in Java, we > invest a lot in creating a single, generally agreed one. > > So in summary, I'm +1 on a 2-phase approach: "open" commits allowed in > staging. OpenJFX committers accept PR's (if they are of good quality) and > prepare upstream commits for OpenJFX. We hope there will be more > contributors who become committers and reviewers in the medium term. > > - Johan > > On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen wrote: > > >> Those are great questions, and I think with Kevin/Oracle/other OpenJFX devs >> help we >> can figure something out. >> >> My thinking is that the PR would be reviewed by basically anyone who has >> free time. >> I think that, at first, only OpenJFX committers will be able to merge PRs. >> They would >> do the final review/merge to the staging repo after it has been reviewed by >> the "wider audience" >> which includes people without commit rights (people like us). Then, as this >> thing evolves, >> based on the pool of people who are contributing both pull requests and PR >> reviews, >> the committers will be able to grant commit privileges to some people in >> that pool. >> >> I can't think of any way that would make it so the changes are as likely to >> be >> merged upstream as possible other than having the current OpenJFX >> committers paving the >> way. Hopefully this vision is aligned with Kevin's and hopefully these >> concrete details >> can be worked out. >> >> Regards, >> Michael >> >> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker wrote: >> >> >>> So if a community ran GitHub is used for staging, who will approve PRs >>> >> for >> >>> the code and the Wiki of the GitHub repo? >>> >>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen >>> wrote: >>> >>> >>>> Great points, Nir. We share the same hopes. I just wanted to piggy-back >>>> on the >>>> wiki thing: >>>> >>>> " * The Wiki could be open sourced as well (like other Wikis). I could >>>> definitely update a page or 2 there and so would other developers as >>>> >> they >> >>>> gain knowledge. I don't know yet how permissions for that should be >>>> handled." >>>> >>>> This is another thing that we could use the GitHub staging repository >>>> >> for. >> >>>> The staging repository could have a wiki (projects on GitHub can have >>>> >> one) >> >>>> that is editable by all, and then maybe once a month or so someone with >>>> permissions >>>> to edit to official wiki can sync with the new, reviewed changes (the >>>> once-a-month >>>> time constraint is very flexible). >>>> >>>> I am just trying to explain how the GitHub repository "one-way mirror" >>>> (potentially linked >>>> with/managed by Adopt an OpenJDK) can act as a staging ground for all >>>> kinds of contributions to >>>> OpenJFX. >>>> >>>> By the way, I am trying to cleanup the groundwork I did on getting >>>> Appveyor builds to >>>> run for openjfx, if indeed it is decided to setup such a staging >>>> repository. You can >>>> see my efforts here: https://raw.githubusercontent. >>>> >>>> >> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057/appveyor.yml >> >>>> If the GitHub repository was setup, changes such as these to add CI >>>> infrastructure would >>>> never be adopted by upstream OpenJFX, but would allow for developer's to >>>> get good >>>> feedback on test results for all supported platforms when they open a >>>> >> PR. >> >>>> Merging a PR >>>> on the public GitHub repository means, in my opinion, that it is ready >>>> >> to >> >>>> be opened as >>>> an upstream bug/feature request. Automating the process with patch sets, >>>> webrevs, formatting/lint >>>> results, etc. would be the most ideal situation and I would be happy to >>>> contribute to these >>>> efforts. >>>> >>>> Regards, >>>> >>>> Michael Ennen >>>> >>>> >>>> >>>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> As someone who has recently made the climb and managed to build OpenJFX >>>>> with OpenJDK on Win 10 I might have some relevant input. >>>>> >>>>> --- Building OpenJFX --- >>>>> >>>>> * With the recently updated instructions on the Wiki, building OpenJFX >>>>> >> is >> >>>>> not that hard. Having to build OpenJDK for that was a real headache >>>>> because >>>>> their instructions and build tools are not up to date ( >>>>> https://bugs.openjdk.java.net/browse/JDK-8194645). >>>>> * The above doesn't mean that the process shouldn't be made easier. >>>>> Ideally, it would be the as easy as working on most open source >>>>> >> projects >> >>>>> on >>>>> Github (not advocating git over hg): clone into the IDE and start >>>>> working; >>>>> when a fix is ready, submit a PR. Don't know if it's technically >>>>> >> possible >> >>>>> in this case, but it's a target. >>>>> * The repository needs a good cleanup before contributors start >>>>> >> cloning ( >> >>>>> bugs.openjdk.java.net/browse/JDK-8196198). >>>>> >>>>> --- Working on OpenJFX --- >>>>> >>>>> * It should be clear which tests need to run for a specific patch. >>>>> Changes >>>>> can be made anywhere from the documentation level to native code level >>>>> and >>>>> there's no reason to run the same tests for all of these. If the >>>>> >> process >> >>>>> can be automate it's even better. >>>>> * The Webrev tool seems archaic to me (and part of its output is broken >>>>> as >>>>> far as I could tell). An IDE can create diff patches with a couple of >>>>> clicks. >>>>> * The Jcheck tool seems archaic to me. It should be ported to IDE >>>>> formatters which are to be distributed with the source. No reason to >>>>> >> run >> >>>>> a >>>>> tool that tells me which whitespaces I need to go back and change when >>>>> something like Ctrl+Shift+F in an IDE finishes the job. >>>>> >>>>> --- Wiki --- >>>>> >>>>> * The Wiki could be open sourced as well (like other Wikis). I could >>>>> definitely update a page or 2 there and so would other developers as >>>>> >> they >> >>>>> gain knowledge. I don't know yet how permissions for that should be >>>>> handled. >>>>> * Code conventions should be clearly listed. >>>>> * Separate sections with instructions should be made for: (1) cloning >>>>> >> and >> >>>>> building, (2) modifying, (3) running tests, (4) submitting, and (5) >>>>> reviewing. >>>>> * Old sections should be cleaned up (I don't think Discussions is >>>>> >> useful >> >>>>> anymore). >>>>> >>>>> --- Review policy --- >>>>> >>>>> * I have no experience with review policies or project roles so I can't >>>>> help here much (maybe after a discussion starts). >>>>> * One thing I do know is that reviewers should be extremely >>>>> knowledgeable, >>>>> which means that there aren't many qualified. Because of this, if it >>>>> becomes "too" easy to contribute to OpenJFX, careful measures need to >>>>> >> be >> >>>>> taken as to not to swamp the few reviewers with many patches (though >>>>> >> some >> >>>>> would say this is an ideal situation). Some sort of review queue might >>>>> help >>>>> with organization instead of the current email system. I have no >>>>> >> concrete >> >>>>> solution for this. >>>>> >>>>> - Nir >>>>> >>>>> >>>>> Message: 1 >>>>> >>>>>> Date: Thu, 01 Feb 2018 15:26:24 -0800 >>>>>> From: Kevin Rushforth >>>>>> To: "openjfx-dev at openjdk.java.net" >>>>>> Subject: More community participation in JavaFX >>>>>> Message-ID: <5A73A220.7030706 at oracle.com> >>>>>> Content-Type: text/plain; charset=windows-1252; format=flowed >>>>>> >>>>>> To: OpenJFX Developers >>>>>> >>>>>> We are looking to grow the community of contributors to the OpenJFX >>>>>> project, especially serious contributors who will stick around long >>>>>> enough to become reviewers, to help us keep the platform vibrant. To >>>>>> this end we are looking at ways to encourage more participation and >>>>>> >>>>> make >>>>> >>>>>> it easier for interested folks to contribute. >>>>>> >>>>>> We are specifically looking to discuss ideas around the following >>>>>> >>>>> areas: >>>>> >>>>>> * Easing barriers to contribution (e.g., making JavaFX easier to >>>>>> >> build, >> >>>>>> better documentation, making it easier to test changes) >>>>>> >>>>>> * Code review policies >>>>>> >>>>>> * API / feature review policies >>>>>> >>>>>> * Code review tools (we currently use webrev, but that isn't set in >>>>>> >>>>> stone) >>>>> >>>>>> To keep this thread productive, the following are explicitly out of >>>>>> >>>>> scope: >>>>> >>>>>> * Discussion of specific features or bugs that you would like to >>>>>> implement (or wish someone else would) >>>>>> >>>>>> * Discussion about platform support >>>>>> >>>>>> * Discussion about version control systems (e.g., hg versus git), >>>>>> hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus >>>>>> github), etc...at least for now. We are aware of the potential >>>>>> >> benefits >> >>>>>> of such changes, but we'd like to focus our efforts on >>>>>> >> higher-leverage >> >>>>>> things we can do in the short term. >>>>>> >>>>>> * Discussion about the requirement of a signed OCA to become a >>>>>> >>>>> contributor >>>>> >>>>>> * Off-topic or tangential commentary about OpenJFX that isn't >>>>>> >> directly >> >>>>>> related to the topic at hand >>>>>> >>>>>> >>>>>> As a starting point for discussion, here are some areas I think need >>>>>> improvement; I'm sure there are others: >>>>>> >>>>>> I. Helping contributors get started >>>>>> >>>>>> It isn?t as easy to get started with OpenJFX as it should be. We want >>>>>> >>>>> to >>>>> >>>>>> make it easier for potential OpenJFX contributors to get started. >>>>>> >> Here >> >>>>>> are some ideas that I think might help: >>>>>> >>>>>> * Improve the build instructions / Wiki (I made a first start, but >>>>>> >>>>> there >>>>> >>>>>> is much more to be done) >>>>>> >>>>>> * Make the build itself more resilient where possible, and provide >>>>>> better error messages, specifically when dealing with native >>>>>> >> compilers >> >>>>>> and libraries >>>>>> >>>>>> * Add an option to skip building all native code and use prebuilt >>>>>> binaries (like we do already for media and webkit); this is tracked >>>>>> >> by >> >>>>>> JDK-8092279, but it hasn?t been looked at recently >>>>>> >>>>>> * Make it easier to build / test your local OpenJFX build using an >>>>>> OpenJDK build (currently the only way to do this is to build OpenJDK >>>>>> locally, after using configure to point to your just-built javafx.* >>>>>> modules). >>>>>> >>>>>> * Provide step-by-step instructions for how to make a contribution, >>>>>> including testing requirements; a lot of the pieces are there, but >>>>>> >> are >> >>>>>> out of date or scattered in several places. As part of this, we could >>>>>> have a section on how to contribute docs, samples or tests, since >>>>>> >> that >> >>>>>> is often a good place to start. >>>>>> >>>>>> * Provide a sandbox environment where contributors can discuss and >>>>>> >> test >> >>>>>> ideas. For example, an OpenJFX mirror on github, potentially >>>>>> >> connected >> >>>>>> to AdoptOpenJDK. >>>>>> >>>>>> >>>>>> II. Code reviews and API reviews >>>>>> >>>>>> Code reviews are important to maintain high-quality contributions, >>>>>> >> but >> >>>>>> we recognize that not every type of change needs the same level of >>>>>> review. Without lowering our standards of quality, we want to make it >>>>>> easier to get low-impact changes (simple bug fixes) accepted. >>>>>> >>>>>> There are three categories of changes, each of which might merit a >>>>>> different review standard: >>>>>> >>>>>> 1. Low-impact bug fixes. These are typically isolated bug fixes with >>>>>> little or no impact beyond fixing the bug in question; included in >>>>>> >> this >> >>>>>> category are test fixes (including new tests) doc fixes, and fixes to >>>>>> sample applications (including new samples). >>>>>> >>>>>> 2. Higher impact bug fixes or RFEs. These include changes to the >>>>>> implementation that potentially have a performance or behavioral >>>>>> >>>>> impact, >>>>> >>>>>> or are otherwise broad in scope. Some larger bug fixes will fall into >>>>>> this category, as will fixes in high-risk areas (e.g., CSS). >>>>>> >>>>>> 3. New features / API additions. In addition to reviewing the >>>>>> implementation, we will need a separate approval process for the new >>>>>> >>>>> API >>>>> >>>>>> / feature (such as the CSR, which is what we use now, or a similar >>>>>> process). >>>>>> >>>>>> We take compatibility seriously, so anything that adds new API needs >>>>>> >> to >> >>>>>> be done with an eye towards supporting it for at least 10 years. We >>>>>> don't want to add new public API without that level of commitment. >>>>>> >>>>> Every >>>>> >>>>>> new feature forecloses on alternate future features. Significant >>>>>> >> effort >> >>>>>> must be taken to think about "if we did this, what could it interact >>>>>> with in the future?" Also, anything with a large potential impact on >>>>>> performance or behavioral compatibility needs to be looked at >>>>>> >>>>> carefully. >>>>> >>>>>> Put another way, we want to encourage thinking about new features or >>>>>> >>>>> new >>>>> >>>>>> API in terms of a design / stewardship process; to think in terms of >>>>>> questions like "what's the right thing for JavaFX in the next 10+ >>>>>> >>>>> years" >>>>> >>>>>> rather than "here's some code that solves my problem, please take >>>>>> >> it". >> >>>>>> As a stake in the ground, I might suggest the following: >>>>>> >>>>>> * All changes need at least one reviewer other than the person making >>>>>> the change who can evaluate the change for correctness and >>>>>> >> consistency. >> >>>>>> For simple bug fixes, a single reviewer may be sufficient. Of course, >>>>>> one of our big challenges in all this is: "how do we grow more >>>>>> reviewers?", by which I mean "how do we facilitate getting >>>>>> >> contributors >> >>>>>> with enough expertise in a given area to eventually be able to >>>>>> effectively review contributions from others?" >>>>>> >>>>>> * We need clear criteria for the other two categories that balance >>>>>> process efficiency with the desire to maintain compatibility and >>>>>> stability. API changes need to be approved by a lead. My thought is >>>>>> >> to >> >>>>>> combine the last two into a single category for purposes of reviewing >>>>>> the implementation. Anything that affects public API or behavioral >>>>>> compatibility will require CSR or similar approval, over and above >>>>>> >> the >> >>>>>> implementation review, which seems sufficient. >>>>>> >>>>>> * I recommend that we formalize the concept of reviewers, using the >>>>>> OpenJDK Reviewer role for the Project. We might also consider if we >>>>>> >>>>> want >>>>> >>>>>> to make any changes to the criteria used by the JDK Project for >>>>>> >>>>> becoming >>>>> >>>>>> an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK >>>>>> >> bylaws >> >>>>>> allow projects a fair degree of latitude to define these criteria, so >>>>>> >>>>> we >>>>> >>>>>> might consider making some modifications. For example, we might make >>>>>> >> it >> >>>>>> somewhat easier for a Contributor to become an Author, or for a >>>>>> Committer to become a Reviewer. I have some thoughts on this, but >>>>>> >> want >> >>>>>> to hear from others first. >>>>>> >>>>>> >>>>>> I look forward to feedback on this proposal, and hope it will spark a >>>>>> productive discussion. >>>>>> >>>>>> -- Kevin Rushforth, OpenJFX Project Lead >>>>>> >>>>>> >>>> From kevin.rushforth at oracle.com Mon Feb 5 14:43:06 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 05 Feb 2018 20:13:06 +0530 Subject: More community participation in JavaFX In-Reply-To: <70b144c4-32e5-4a57-a0c6-7465559957ed@me.com> References: <70b144c4-32e5-4a57-a0c6-7465559957ed@me.com> Message-ID: <5A786D7A.7080509@oracle.com> I think a discussion on "where we should take the platform" is a good one to have...just not as part of this thread. -- Kevin Stephen Desofi wrote: > Yes, probably me. > > Sent from iCloud > > On Feb 03, 2018, at 09:35 PM, John-Val Rose wrote: > >> Well, then one of us is "off topic"... >> >> >> Kevin Rushforth: >> >> "We are specifically looking to discuss ideas around the following areas: >> * Easing barriers to contribution (e.g., making JavaFX easier to >> build, better documentation, making it easier to test changes) >> * Code review policies >> * API / feature review policies >> * Code review tools (we currently use webrev, but that isn't set in >> stone)" >> >> On 4 February 2018 at 13:29, Stephen Desofi > > wrote: >> >> John, >> >> I think you and I are thinking on two different levels. >> You are talking about the mechanics of making contributing to >> JavaFX easier. I am talking about making the motivations of >> contributing to JavaFX easier. >> >> Steve >> >> Sent from iCloud >> >> On Feb 03, 2018, at 09:14 PM, John-Val Rose >> > wrote: >> >>> Stephen, >>> >>> 1. Swift and your "crystal ball" view of its spectacular success >>> in the future has nothing whatsoever to do with making >>> contributing to JavaFX easier. >>> >>> 2. Like everyone else who already wants to contribute to JavaFX, >>> we don't need someone to provide us with "a compelling story as >>> to why developers should join and contribute". >>> >>> 3. TL;DR >>> >>> John-Val Rose >>> ? (trying to be polite)? >>> >>> On 4 February 2018 at 12:58, Stephen Desofi >> > wrote: >>> >>> John, >>> >>> The point I am making is that Swift is catching up as a >>> cross platform toolkit and is available on: >>> >>> Mac and iOS, (Full Support) >>> https://www.swift.org >>> >>> Android (early) >>> >>> https://academy.realm.io/posts/swift-on-android/ >>> >>> >>> >>> Linux: (early) >>> >>> >>> https://itsfoss.com/use-swift-linux/ >>> >>> >>> >>> Windows: (early) >>> >>> >>> https://www.infoworld.com/article/3067364/open-source-tools/swift-for-windows-arrives-at-last-but-as-an-unofficial-port.html >>> >>> >>> >>> >>> Browser: (very Preliminary) >>> >>> >>> https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly >>> >>> >>> Server Side: (Mac and Linux) >>> https://www.swift.org >>> >>> >>> So my point is that soon Swift will steal the Cross Platform >>> Mantra from Java. It is happening very quickly and Swift >>> has great graphics and gaming capabilities as well. >>> >>> >>> Why would a new developer start with Java? If we are >>> looking 10 years out, I think Apple is coming head on. >>> >>> >>> Also when you say this thread is about the ease with which >>> the community can contribute to JavaFX, it begs the question >>> "what kinds of contribution?". Are we here to push the >>> platform forward and contribute new ideas or just do bug fixes? >>> >>> >>> Swift is a real threat to Java being the cross platform >>> development King. Java can hold on to that story for only >>> a couple more years. It surely won't last. >>> >>> >>> Dart also runs on Android and iOS via Flutter, has Server >>> side Dart option, runs in the Browser very well today with >>> full support for SVG and Canvas -- and if WebGPU becomes a >>> Web standard, Google will most certainly support it. >>> >>> >>> Looking toward the future, if Java doesn't run in the >>> browser, doesn't support games on any platform, and only >>> works on iOS and Android via Gluon VM, and does it with only >>> limited graphics capability, then I think JavaFX will be a >>> tough sell in the future. Even tougher than it is today. >>> >>> >>> If the point of the discussion is to build the developer >>> community, I think we first need a compelling story as to >>> why developers should join and contribute. >>> >>> >>> The fact that I am using Dart and JavaFX, and I am seriously >>> considering if I should switch to Dart everywhere, or to >>> Dart and Swift (instead of Dart and FX) means JavaFX doesn't >>> have the lead we think it does. I love JavaFX and would >>> love to contribute, but it's hard when I myself am looking >>> at other options mainly because I also want my software to >>> be here 10 years from now, and I am seriously questioning if >>> JavaFX will keep up. >>> >>> >>> I think there is a small window of opportunity for JavaFX to >>> make a stand before it is permanently relegated to a Server >>> side language. This cross platform story won't fly too >>> much longer, especially when Swift starts to run everywhere >>> and in the browser too, and if Google does the same thing >>> with Dart, and they both support games, where will Java be? >>> >>> >>> If we are looking 10 years out then surely this will happen. >>> The big question is what will we do, and where will JavaFX be? >>> >>> >>> Steve Desofi >>> >>> >>> >>> >>> On Feb 03, 2018, at 03:09 PM, John-Val Rose >>> > wrote: >>> >>>> >>>> Stephen - I?m not quite following you. >>>> >>>> This thread is about improving the ease with which the >>>> community can contribute to JavaFX. >>>> >>>> I see no point in comparing JavaFX (a cross platform >>>> graphics toolkit for JVM languages) with a Swift (a general >>>> purpose programming language that runs on Apple hardware). >>>> >>>> On 4 Feb 2018, at 00:18, Stephen Desofi >>> > wrote: >>>> >>>>> This begs the question, why has the bar been set too low? >>>>> I am new to this community and don?t know much history >>>>> other than a couple weeks of bug fix messages flying by. >>>>> >>>>> I am not even clear of what our role and purpose is >>>>> supposed to be. Are we here for only bug fixes, and >>>>> follow the direction and flow that is already set, or as >>>>> contributors would we be allowed to contribute to the >>>>> goals and direction of JavaFX? >>>>> >>>>> FX is a good platform with great potential, but it biggest >>>>> deficiency is ?mind share?. People don?t see too many >>>>> real world accomplishments that knock your socks off. >>>>> Most people use web and phone to run apps. PC and Desktop >>>>> apps are a small part of the market. >>>>> >>>>> Gluon has just recently released gluon VM and Gluon Mobile >>>>> to allow FX on phones and tablets. >>>>> >>>>> The problem I see is once I can use FX on phones how will >>>>> it compete with Swift? >>>>> >>>>> True that ?write once, run everywhere? is important and >>>>> Java has a lead over Swift. But Swift has a lead on >>>>> capability. >>>>> >>>>> In the end Swift will catch up with Java in the ?write >>>>> once, run anywhere? mantra. Will FX catch up with Swift >>>>> in graphics by then? >>>>> >>>>> Java has a lead in many areas, but if we look 10 years >>>>> out, it seems clear to me that Java needs to raise the bar >>>>> or face extinction as a client side development platform >>>>> or forever be confined to the server. >>>>> >>>>> This is why I need some clarification as to what our role >>>>> as contributors is going to be. I don?t believe an open >>>>> source project can flourish if the contributors have no >>>>> say or stake in the direction. >>>>> >>>>> Steve Desofi >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Feb 2, 2018, at 11:55 PM, John-Val Rose >>>>> > wrote: >>>>> >>>>>> I think Kevin outlined in his opening post what would be >>>>>> considered "out of scope". >>>>>> >>>>>> However, I agree with you on the basic premise that, in >>>>>> general, the bar has been set way too low as to the >>>>>> potential use cases and performance of JavaFX. In fact, >>>>>> I firmly believe that games & complex visualisations etc. >>>>>> *should* be possible with JavaFX given that most of the >>>>>> heavy lifting is being done by the GPU. It's just that, >>>>>> at the moment, the scene graph rendering pipeline is >>>>>> significantly slower than it could be and it is for this >>>>>> reason that we don't find applications using advanced 3D >>>>>> graphics & animations etc. (like we see in games) being >>>>>> built with JavaFX. It's just not possible when the node >>>>>> count reaches even a very small threshold. >>>>>> >>>>>> This is a topic I have tried to discuss numerous times >>>>>> and also believe that I can improve the performance of >>>>>> the scene graph rendering in a very tangible way. >>>>>> >>>>>> If things pan-out as they are being described and >>>>>> becoming & being a contributor is simplified to the >>>>>> extent where it justifies me devoting a large chunk of my >>>>>> time to OpenJFX, this is probably what I would want to >>>>>> work on first. >>>>>> >>>>>> ? ? >>>>>> Graciously, >>>>>> >>>>>> John-Val Rose >>>>>> >>>>>> On 3 February 2018 at 14:07, Stephen Desofi >>>>>> > wrote: >>>>>> >>>>>> I don?t understand why discussing new graphics >>>>>> capabilities such as gaming or WebGPU, etc is so off >>>>>> limits. Can you explain that? >>>>>> >>>>>> Steve Desofi >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth >>>>>> >>>>> > wrote: >>>>>> > >>>>>> > Looks like we have some good discussion so far. >>>>>> > >>>>>> > I see a few themes emerging (build/test, sandbox on >>>>>> GitHub, ease of filing bugs, etc) along with some >>>>>> discussion on graphics performance (which is fine as >>>>>> long as the discussion doesn't veer too far into >>>>>> discussing specific graphics features). >>>>>> > >>>>>> > I'll let more folks chime in before I reply to >>>>>> anything specifically (and I'll be offline over the >>>>>> weekend anyway). >>>>>> > >>>>>> > Thanks! >>>>>> > >>>>>> > -- Kevin >>>>>> > >>>>>> >>>>>> >>> >> From paulrussell70 at gmail.com Mon Feb 5 14:48:41 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Mon, 5 Feb 2018 14:48:41 +0000 Subject: More community participation in JavaFX Message-ID: "I think a discussion on "where we should take the platform" is a good one to have...just not as part of this thread. " I'm looking forwards to the new thread :) From johnvalrose at gmail.com Mon Feb 5 14:58:21 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Tue, 6 Feb 2018 01:58:21 +1100 Subject: More community participation in JavaFX In-Reply-To: References: Message-ID: <932EB931-F532-43DE-9957-A6F8F1367526@gmail.com> Yes, me too. I think it?s logical to establish *how* to make contributions first (and it?s great to see a lot of progress with this so far) but then there clearly needs to be a discussion of exactly *what* those contributions are, who decides which ones are important or permitted and how are they prioritised. I have no experience in the ?how? aspect of all this but I certainly have a large ?wish list? of potential contributions :-) > On 6 Feb 2018, at 01:48, Paul Ray Russell wrote: > > "I think a discussion on "where we should take the platform" is a good > one to have...just not as part of this thread. " > > I'm looking forwards to the new thread :) From johan.vos at gluonhq.com Mon Feb 5 17:07:02 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 05 Feb 2018 17:07:02 +0000 Subject: future content of OpenJFX Message-ID: In order to separate the "What" from the "How" (discussed in another thread), I would like to start a discussion about what people think should be considered for future JavaFX work. I'd like to start with what I think is an important note on the context. If I want feature X in JavaFX, I ask myself two questions: 1. Do I want to contribute time and do it (at least for a large part) myself? 2. Do I want to spend money on it? If that sounds too economic or commercial, I recommend reading the excellent blog entry by David Blevins about funding Java EE development (more than 4 years old and still very relevant): http://www.tomitribe.com/blog/2013/11/feed-the-fish/ Actually, this is a model we've been using at Gluon for a number of customers. When people ask us about a specific feature, we ask if they are willing to pay us for the development, AND if they are ok with us donating it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX, JavaFXports, Gluon Charm Down, Gluon Maps,...). As a consequence, the features we are working on are all relevant to (at least a part of) the industry. Some companies doubt there is business value in JavaFX, we prove the opposite while making the Open Source community better. I think by now it should be clear to all that there is no free lunch (anymore). If your business depends on a feature being added to JavaFX, how much (time/money) are you willing to contribute? If the answer is "nothing", you can still hope that others want to do it, and in many cases that will eventually happen -- but you don't control the timeline. This principle is a bit a simplification though. In many practical cases, people want to have feature X and are willing to contribute "something" (e.g. they want to work on it in spare-time, or fund 20% of a developer) but not enough to do everything. I think in this case it's a matter of gathering enough interest in this community. Once enough developers are interested in that same feature, and agree to spend resources on it, the burden can be shared. Having a sandbox repositories with forks will make this easier. Areas that I personally want to see on the roadmap: * more alignment with mobile * a clean and lean low-level rendering pipeline API that would allow easier plugability with upcoming low-level rendering systems * extensions for Chart API - Johan From sverre.moe at gmail.com Mon Feb 5 21:25:23 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Mon, 5 Feb 2018 22:25:23 +0100 Subject: More community participation in JavaFX Message-ID: > Date: Mon, 5 Feb 2018 08:11:05 +0100 > From: Alexander Ny?en > To: Kevin Rushforth > Cc: "openjfx-dev at openjdk.java.net" > Subject: Re: More community participation in JavaFX > Message-ID: <3C5EF409-A1A6-40DE-A810-6D8D63FB4450 at nyssen.org> > Content-Type: text/plain; charset=utf-8 > > Hi Kevin, > > the issue tracker is usually the first contact point for any future contributor. Making it publicly accessible would IMHO be an important first step. Be aware that before being appointed as author, one is not even allowed to reply to questions related to those issues one has created via the web interface. In my eyes that?s at least an unnecessary hurdle, maybe even a deterrent. > > Regards, > Alexander Most definitely. Perhaps by opening up the OpenJDK JIRA issue tracker a bit. I myself have submitted a few bugs, but could not contribute further because I don't have access. I found contribution to Jenkins much easier because it was easy to create a user account on their JIRA issue tracker. Regards, Sverre From nlisker at gmail.com Mon Feb 5 23:08:39 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 6 Feb 2018 01:08:39 +0200 Subject: Updating class javafx.beans.binding.When Message-ID: Hi, I was looking at https://bugs.openjdk.java.net/browse/JDK-8089579, which prompted me to have a look at When. There are a few points I would like to address: * StringConditionBuilder#otherwise(ObservableStringValue) does not check for null as other condition builders do. This results in a deeper NPE when StringCondition tries to register a listener to the ObservableStringValue. * I would like a (re)evaluation on the above bug ticket and thoughts on the proposal of "on demand evaluation" using a Supplier or a similar method. The behavior of the intended implementation would be to evaluate 'then' and 'otherwise' whenever their condition is met, and only then. * The class can benefit from some small refactoring, such as using Objects.requireNonNull for null checks and some code reuse to reduce the chance of bugs such as the missing null check of StringConditionBuilder. * There are a few Javadoc corrections and some clarifications of the current behavior could be beneficial as well. I can work on all of the above. How to proceed? - Nir From sdesofi at icloud.com Tue Feb 6 00:23:58 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Tue, 06 Feb 2018 00:23:58 +0000 (GMT) Subject: future content of OpenJFX Message-ID: <27d7049f-64d3-42d2-8eb7-af8fd92b6b55@me.com> Hi Johan, ? ? ?I read the article you linked to (http://www.tomitribe.com/blog/2013/11/feed-the-fish/) and it raises some very good points indeed. ? ? ? I also spent a little time thinking over your list of interests: * more alignment with mobile * a clean and lean low-level rendering pipeline API that would allow easier plugability with upcoming low-level rendering systems * extensions for Chart API Those would be high on my list as well, but there is something else I'd like to throw into the equation. ? If somebody can contribute money to fund the development of their wishlist, fine, ?that's the easy part,?but asking people to contribute time is a bit more complicated. ?For example, ?I may want "more alignment with?mobile", but I may be better qualified to contribute ?"extensions for the Chart API" even though that isn't my primary motivator. Often the reason we want something is because we?haven't the skills to do it ourself, but we have skills to do other things. ?How can situations such as this?be factored into the equation? ? It seems like we need a way to "trade". ? Steve Sent from iCloud On Feb 05, 2018, at 12:07 PM, Johan Vos wrote: In order to separate the "What" from the "How" (discussed in another thread), I would like to start a discussion about what people think should be considered for future JavaFX work. I'd like to start with what I think is an important note on the context. If I want feature X in JavaFX, I ask myself two questions: 1. Do I want to contribute time and do it (at least for a large part) myself? 2. Do I want to spend money on it? If that sounds too economic or commercial, I recommend reading the excellent blog entry by David Blevins about funding Java EE development (more than 4 years old and still very relevant): http://www.tomitribe.com/blog/2013/11/feed-the-fish/ Actually, this is a model we've been using at Gluon for a number of customers. When people ask us about a specific feature, we ask if they are willing to pay us for the development, AND if they are ok with us donating it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX, JavaFXports, Gluon Charm Down, Gluon Maps,...). As a consequence, the features we are working on are all relevant to (at least a part of) the industry. Some companies doubt there is business value in JavaFX, we prove the opposite while making the Open Source community better. I think by now it should be clear to all that there is no free lunch (anymore). If your business depends on a feature being added to JavaFX, how much (time/money) are you willing to contribute? If the answer is "nothing", you can still hope that others want to do it, and in many cases that will eventually happen -- but you don't control the timeline. This principle is a bit a simplification though. In many practical cases, people want to have feature X and are willing to contribute "something" (e.g. they want to work on it in spare-time, or fund 20% of a developer) but not enough to do everything. I think in this case it's a matter of gathering enough interest in this community. Once enough developers are interested in that same feature, and agree to spend resources on it, the burden can be shared. Having a sandbox repositories with forks will make this easier. Areas that I personally want to see on the roadmap: * more alignment with mobile * a clean and lean low-level rendering pipeline API that would allow easier plugability with upcoming low-level rendering systems * extensions for Chart API - Johan From arunprasad.rajkumar at oracle.com Tue Feb 6 02:17:39 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 6 Feb 2018 07:47:39 +0530 Subject: [11] Review request: 8196677: Cherry pick GTK WebKit 2.18.6 changes References: <4BEB3020-D2B2-4F73-B1D0-DCBAD3277C49@oracle.com> Message-ID: Hi, Please review the following fix, Bug: https://bugs.openjdk.java.net/browse/JDK-8196677 Patch: http://cr.openjdk.java.net/~arajkumar/8196677/webrev Thanks, Arun From johnvalrose at gmail.com Tue Feb 6 04:14:56 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Tue, 6 Feb 2018 15:14:56 +1100 Subject: future content of OpenJFX In-Reply-To: <27d7049f-64d3-42d2-8eb7-af8fd92b6b55@me.com> References: <27d7049f-64d3-42d2-8eb7-af8fd92b6b55@me.com> Message-ID: <07B463FC-F501-4A14-A78B-0681528D4601@gmail.com> I think there?s a small matter that is being overlooked here. The size of the ?talent pool?. I?m just pulling numbers out of thin air here but first I?m guessing that the vast majority of JavaFX users do *not* read this list. Then, out of those who do, only some *care* enough to contribute. Out of those, only some are *competent* enough to contribute. And then, out of that much smaller set, only an even smaller subset are in a situation that *permits* them to contribute, either because they have well-paid jobs and a bit of spare time or they really need a feature added for their own use. Given that I don?t know what the ?starting? number is (the total number of JavaFX users) and neither do I know what fraction to apply to each smaller subset, the end result (the talent pool) is potentially only a handful of people. I?m simply mentioning this because in every discussion we have here regarding innovation, community participation or plans for new features, it looks like the same group of people get involved - and it?s not exactly a ?crowd?. Does this mean that we don?t have a ?critical mass? or is it possible that there are lots and lots of ?observers? or ?lurkers? out there just waiting until all the hard work of setting-up the physical and formal infrastructure to enable community contribution has been finalised before they?ll put their hands up? Maybe we could take a poll to see how many members of the community would be willing AND able to contribute, knowing that they may not necessarily end up working on features they are interested in AND who are prepared for their contribution itself & the value it adds to JavaFX to be their only tangible reward? > On 6 Feb 2018, at 11:23, Stephen Desofi wrote: > > Hi Johan, > > I read the article you linked to (http://www.tomitribe.com/blog/2013/11/feed-the-fish/) and it raises some very good points indeed. > > I also spent a little time thinking over your list of interests: > * more alignment with mobile > * a clean and lean low-level rendering pipeline API that would allow easier > plugability with upcoming low-level rendering systems > * extensions for Chart API > > Those would be high on my list as well, but there is something else I'd like to throw into the equation. > > If somebody can contribute money to fund the development of their wishlist, fine, that's the easy part, but asking people to contribute time is a bit more complicated. For example, I may want "more alignment with mobile", but I may be better qualified to contribute "extensions for the Chart API" even though that isn't my primary motivator. > > Often the reason we want something is because we haven't the skills to do it ourself, but we have skills to do other things. How can situations such as this be factored into the equation? It seems like we need a way to "trade". > > Steve > > > > Sent from iCloud > > On Feb 05, 2018, at 12:07 PM, Johan Vos wrote: > > In order to separate the "What" from the "How" (discussed in another > thread), I would like to start a discussion about what people think should > be considered for future JavaFX work. > > I'd like to start with what I think is an important note on the context. > If I want feature X in JavaFX, I ask myself two questions: > 1. Do I want to contribute time and do it (at least for a large part) > myself? > 2. Do I want to spend money on it? > > If that sounds too economic or commercial, I recommend reading the > excellent blog entry by David Blevins about funding Java EE development > (more than 4 years old and still very relevant): > http://www.tomitribe.com/blog/2013/11/feed-the-fish/ > > Actually, this is a model we've been using at Gluon for a number of > customers. When people ask us about a specific feature, we ask if they are > willing to pay us for the development, AND if they are ok with us donating > it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX, > JavaFXports, Gluon Charm Down, Gluon Maps,...). > As a consequence, the features we are working on are all relevant to (at > least a part of) the industry. Some companies doubt there is business value > in JavaFX, we prove the opposite while making the Open Source community > better. > > I think by now it should be clear to all that there is no free lunch > (anymore). If your business depends on a feature being added to JavaFX, how > much (time/money) are you willing to contribute? If the answer is > "nothing", you can still hope that others want to do it, and in many cases > that will eventually happen -- but you don't control the timeline. > > This principle is a bit a simplification though. In many practical cases, > people want to have feature X and are willing to contribute "something" > (e.g. they want to work on it in spare-time, or fund 20% of a developer) > but not enough to do everything. > I think in this case it's a matter of gathering enough interest in this > community. Once enough developers are interested in that same feature, and > agree to spend resources on it, the burden can be shared. Having a sandbox > repositories with forks will make this easier. > > Areas that I personally want to see on the roadmap: > * more alignment with mobile > * a clean and lean low-level rendering pipeline API that would allow easier > plugability with upcoming low-level rendering systems > * extensions for Chart API > > - Johan > From paulrussell70 at gmail.com Tue Feb 6 09:00:18 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Tue, 6 Feb 2018 09:00:18 +0000 Subject: future content of OpenJFX Message-ID: +1 * more alignment with mobile * a clean and lean low-level rendering pipeline API that would allow easier plugability with upcoming low-level rendering systems I would like to add a higher level desire * a consensus that JavaFX will continue to open itself more to integration. It has a rumour for being closed to integration. I recall the folks at JOGL concluded this when they tried to integrate, but mostly, I have in mind the might of JMagick, which could be easily integrated to provide all the image manipulation that JavaFX so lacks currently. Perhaps a forum poll would ease a vote? From sdesofi at icloud.com Tue Feb 6 11:01:29 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Tue, 06 Feb 2018 06:01:29 -0500 Subject: future content of OpenJFX In-Reply-To: References: Message-ID: <0CEB7CC1-20D4-4122-9E27-CBDFCDD46C96@icloud.com> Another one high on my list would be browser support via WebAssembly. Access to the DOM would be secondary, or not important at all. If we had the ability to draw then we don?t need the DOM. IMHO. Sent from my iPhone > On Feb 6, 2018, at 4:00 AM, Paul Ray Russell wrote: > > +1 > > * more alignment with mobile > * a clean and lean low-level rendering pipeline API that would allow easier > plugability with upcoming low-level rendering systems > > I would like to add a higher level desire > > * a consensus that JavaFX will continue to open itself more to integration. > It has a rumour for being closed to integration. I recall the folks at JOGL > concluded this when they tried to integrate, but mostly, I have in mind the > might of JMagick, which could be easily integrated to provide all the image > manipulation that JavaFX so lacks currently. > > Perhaps a forum poll would ease a vote? From johnvalrose at gmail.com Tue Feb 6 11:04:48 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Tue, 6 Feb 2018 22:04:48 +1100 Subject: future content of OpenJFX In-Reply-To: <0CEB7CC1-20D4-4122-9E27-CBDFCDD46C96@icloud.com> References: <0CEB7CC1-20D4-4122-9E27-CBDFCDD46C96@icloud.com> Message-ID: <4FFAE3E5-51E7-45DA-9407-307912525F61@gmail.com> Yes - I agree. WASM would be great. And I believe the folks at JPro are working on just that... > On 6 Feb 2018, at 22:01, Stephen Desofi wrote: > > Another one high on my list would be browser support via WebAssembly. Access to the DOM would be secondary, or not important at all. If we had the ability to draw then we don?t need the DOM. IMHO. > > > Sent from my iPhone > >> On Feb 6, 2018, at 4:00 AM, Paul Ray Russell wrote: >> >> +1 >> >> * more alignment with mobile >> * a clean and lean low-level rendering pipeline API that would allow easier >> plugability with upcoming low-level rendering systems >> >> I would like to add a higher level desire >> >> * a consensus that JavaFX will continue to open itself more to integration. >> It has a rumour for being closed to integration. I recall the folks at JOGL >> concluded this when they tried to integrate, but mostly, I have in mind the >> might of JMagick, which could be easily integrated to provide all the image >> manipulation that JavaFX so lacks currently. >> >> Perhaps a forum poll would ease a vote? From sdesofi at icloud.com Tue Feb 6 11:12:33 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Tue, 06 Feb 2018 06:12:33 -0500 Subject: future content of OpenJFX In-Reply-To: <07B463FC-F501-4A14-A78B-0681528D4601@gmail.com> References: <27d7049f-64d3-42d2-8eb7-af8fd92b6b55@me.com> <07B463FC-F501-4A14-A78B-0681528D4601@gmail.com> Message-ID: A poll would definitely be useful because we may find ourselves another subset. The subset of people who even want to go ?off road? to begin with. Most people only consider going places where the road already leads?and that might be about 99%. Sent from my iPhone > On Feb 5, 2018, at 11:14 PM, John-Val Rose wrote: > > I think there?s a small matter that is being overlooked here. > > The size of the ?talent pool?. > > I?m just pulling numbers out of thin air here but first I?m guessing that the vast majority of JavaFX users do *not* read this list. > > Then, out of those who do, only some *care* enough to contribute. > > Out of those, only some are *competent* enough to contribute. > > And then, out of that much smaller set, only an even smaller subset are in a situation that *permits* them to contribute, either because they have well-paid jobs and a bit of spare time or they really need a feature added for their own use. > > Given that I don?t know what the ?starting? number is (the total number of JavaFX users) and neither do I know what fraction to apply to each smaller subset, the end result (the talent pool) is potentially only a handful of people. > > I?m simply mentioning this because in every discussion we have here regarding innovation, community participation or plans for new features, it looks like the same group of people get involved - and it?s not exactly a ?crowd?. > > Does this mean that we don?t have a ?critical mass? or is it possible that there are lots and lots of ?observers? or ?lurkers? out there just waiting until all the hard work of setting-up the physical and formal infrastructure to enable community contribution has been finalised before they?ll put their hands up? > > Maybe we could take a poll to see how many members of the community would be willing AND able to contribute, knowing that they may not necessarily end up working on features they are interested in AND who are prepared for their contribution itself & the value it adds to JavaFX to be their only tangible reward? > >> On 6 Feb 2018, at 11:23, Stephen Desofi wrote: >> >> Hi Johan, >> >> I read the article you linked to (http://www.tomitribe.com/blog/2013/11/feed-the-fish/) and it raises some very good points indeed. >> >> I also spent a little time thinking over your list of interests: >> * more alignment with mobile >> * a clean and lean low-level rendering pipeline API that would allow easier >> plugability with upcoming low-level rendering systems >> * extensions for Chart API >> >> Those would be high on my list as well, but there is something else I'd like to throw into the equation. >> >> If somebody can contribute money to fund the development of their wishlist, fine, that's the easy part, but asking people to contribute time is a bit more complicated. For example, I may want "more alignment with mobile", but I may be better qualified to contribute "extensions for the Chart API" even though that isn't my primary motivator. >> >> Often the reason we want something is because we haven't the skills to do it ourself, but we have skills to do other things. How can situations such as this be factored into the equation? It seems like we need a way to "trade". >> >> Steve >> >> >> >> Sent from iCloud >> >> On Feb 05, 2018, at 12:07 PM, Johan Vos wrote: >> >> In order to separate the "What" from the "How" (discussed in another >> thread), I would like to start a discussion about what people think should >> be considered for future JavaFX work. >> >> I'd like to start with what I think is an important note on the context. >> If I want feature X in JavaFX, I ask myself two questions: >> 1. Do I want to contribute time and do it (at least for a large part) >> myself? >> 2. Do I want to spend money on it? >> >> If that sounds too economic or commercial, I recommend reading the >> excellent blog entry by David Blevins about funding Java EE development >> (more than 4 years old and still very relevant): >> http://www.tomitribe.com/blog/2013/11/feed-the-fish/ >> >> Actually, this is a model we've been using at Gluon for a number of >> customers. When people ask us about a specific feature, we ask if they are >> willing to pay us for the development, AND if they are ok with us donating >> it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX, >> JavaFXports, Gluon Charm Down, Gluon Maps,...). >> As a consequence, the features we are working on are all relevant to (at >> least a part of) the industry. Some companies doubt there is business value >> in JavaFX, we prove the opposite while making the Open Source community >> better. >> >> I think by now it should be clear to all that there is no free lunch >> (anymore). If your business depends on a feature being added to JavaFX, how >> much (time/money) are you willing to contribute? If the answer is >> "nothing", you can still hope that others want to do it, and in many cases >> that will eventually happen -- but you don't control the timeline. >> >> This principle is a bit a simplification though. In many practical cases, >> people want to have feature X and are willing to contribute "something" >> (e.g. they want to work on it in spare-time, or fund 20% of a developer) >> but not enough to do everything. >> I think in this case it's a matter of gathering enough interest in this >> community. Once enough developers are interested in that same feature, and >> agree to spend resources on it, the burden can be shared. Having a sandbox >> repositories with forks will make this easier. >> >> Areas that I personally want to see on the roadmap: >> * more alignment with mobile >> * a clean and lean low-level rendering pipeline API that would allow easier >> plugability with upcoming low-level rendering systems >> * extensions for Chart API >> >> - Johan >> From johnvalrose at gmail.com Tue Feb 6 11:41:29 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Tue, 6 Feb 2018 22:41:29 +1100 Subject: future content of OpenJFX In-Reply-To: References: <27d7049f-64d3-42d2-8eb7-af8fd92b6b55@me.com> <07B463FC-F501-4A14-A78B-0681528D4601@gmail.com> Message-ID: Maybe Kevin could request that anyone who is seriously both willing and capable to contribute to OpenJFX email him privately so that the list doesn?t get to ?see? anyone who wants to fly under the radar. Kevin could then post the approximate number of resources actually available. I realise of course that some people may not wish to even let Kevin know of their interest and availability initially but at least we would have a ballpark figure as to the size of the ?talent pool?. I think we need to have some handle on this number before any significant set-up work is undertaken (just in case the number is only 2 or 3 for example instead of 20 or so). > On 6 Feb 2018, at 22:12, Stephen Desofi wrote: > > A poll would definitely be useful because we may find ourselves another subset. > > The subset of people who even want to go ?off road? to begin with. Most people only consider going places where the road already leads?and that might be about 99%. > > > > Sent from my iPhone > >> On Feb 5, 2018, at 11:14 PM, John-Val Rose wrote: >> >> I think there?s a small matter that is being overlooked here. >> >> The size of the ?talent pool?. >> >> I?m just pulling numbers out of thin air here but first I?m guessing that the vast majority of JavaFX users do *not* read this list. >> >> Then, out of those who do, only some *care* enough to contribute. >> >> Out of those, only some are *competent* enough to contribute. >> >> And then, out of that much smaller set, only an even smaller subset are in a situation that *permits* them to contribute, either because they have well-paid jobs and a bit of spare time or they really need a feature added for their own use. >> >> Given that I don?t know what the ?starting? number is (the total number of JavaFX users) and neither do I know what fraction to apply to each smaller subset, the end result (the talent pool) is potentially only a handful of people. >> >> I?m simply mentioning this because in every discussion we have here regarding innovation, community participation or plans for new features, it looks like the same group of people get involved - and it?s not exactly a ?crowd?. >> >> Does this mean that we don?t have a ?critical mass? or is it possible that there are lots and lots of ?observers? or ?lurkers? out there just waiting until all the hard work of setting-up the physical and formal infrastructure to enable community contribution has been finalised before they?ll put their hands up? >> >> Maybe we could take a poll to see how many members of the community would be willing AND able to contribute, knowing that they may not necessarily end up working on features they are interested in AND who are prepared for their contribution itself & the value it adds to JavaFX to be their only tangible reward? >> >>> On 6 Feb 2018, at 11:23, Stephen Desofi wrote: >>> >>> Hi Johan, >>> >>> I read the article you linked to (http://www.tomitribe.com/blog/2013/11/feed-the-fish/) and it raises some very good points indeed. >>> >>> I also spent a little time thinking over your list of interests: >>> * more alignment with mobile >>> * a clean and lean low-level rendering pipeline API that would allow easier >>> plugability with upcoming low-level rendering systems >>> * extensions for Chart API >>> >>> Those would be high on my list as well, but there is something else I'd like to throw into the equation. >>> >>> If somebody can contribute money to fund the development of their wishlist, fine, that's the easy part, but asking people to contribute time is a bit more complicated. For example, I may want "more alignment with mobile", but I may be better qualified to contribute "extensions for the Chart API" even though that isn't my primary motivator. >>> >>> Often the reason we want something is because we haven't the skills to do it ourself, but we have skills to do other things. How can situations such as this be factored into the equation? It seems like we need a way to "trade". >>> >>> Steve >>> >>> >>> >>> Sent from iCloud >>> >>> On Feb 05, 2018, at 12:07 PM, Johan Vos wrote: >>> >>> In order to separate the "What" from the "How" (discussed in another >>> thread), I would like to start a discussion about what people think should >>> be considered for future JavaFX work. >>> >>> I'd like to start with what I think is an important note on the context. >>> If I want feature X in JavaFX, I ask myself two questions: >>> 1. Do I want to contribute time and do it (at least for a large part) >>> myself? >>> 2. Do I want to spend money on it? >>> >>> If that sounds too economic or commercial, I recommend reading the >>> excellent blog entry by David Blevins about funding Java EE development >>> (more than 4 years old and still very relevant): >>> http://www.tomitribe.com/blog/2013/11/feed-the-fish/ >>> >>> Actually, this is a model we've been using at Gluon for a number of >>> customers. When people ask us about a specific feature, we ask if they are >>> willing to pay us for the development, AND if they are ok with us donating >>> it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX, >>> JavaFXports, Gluon Charm Down, Gluon Maps,...). >>> As a consequence, the features we are working on are all relevant to (at >>> least a part of) the industry. Some companies doubt there is business value >>> in JavaFX, we prove the opposite while making the Open Source community >>> better. >>> >>> I think by now it should be clear to all that there is no free lunch >>> (anymore). If your business depends on a feature being added to JavaFX, how >>> much (time/money) are you willing to contribute? If the answer is >>> "nothing", you can still hope that others want to do it, and in many cases >>> that will eventually happen -- but you don't control the timeline. >>> >>> This principle is a bit a simplification though. In many practical cases, >>> people want to have feature X and are willing to contribute "something" >>> (e.g. they want to work on it in spare-time, or fund 20% of a developer) >>> but not enough to do everything. >>> I think in this case it's a matter of gathering enough interest in this >>> community. Once enough developers are interested in that same feature, and >>> agree to spend resources on it, the burden can be shared. Having a sandbox >>> repositories with forks will make this easier. >>> >>> Areas that I personally want to see on the roadmap: >>> * more alignment with mobile >>> * a clean and lean low-level rendering pipeline API that would allow easier >>> plugability with upcoming low-level rendering systems >>> * extensions for Chart API >>> >>> - Johan >>> From dalibor.topic at oracle.com Tue Feb 6 12:48:15 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 6 Feb 2018 13:48:15 +0100 Subject: More community participation in JavaFX In-Reply-To: <5A786D32.6050600@oracle.com> References: <5A786D32.6050600@oracle.com> Message-ID: <1453a93e-0f34-194e-c8c6-9ab57b9c3f42@oracle.com> On 05.02.2018 15:41, Kevin Rushforth wrote: > Yes, this sounds like a good step in the right direction. This would > give anyone (with a signed OCA) the ability to create their own branch, > commit changes to it, submit a PR, etc. One non-obvious point to keep in mind is that you do need to make sure that all contributors (to a PR, wiki entry, etc.) have signed the OCA, or the change can't be integrated back into the OpenJFX upstream. I don't think that GitHub offers programmatic, conditional access to its functionality fo contributors, so enforcing that kind of requirement can be a source of frustration. Not enforcing it, on the other hand, creates long term frustration as well. [0] cheers, dalibor topic [0] The implosion of the TeamFX repo is a good example. -- 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From info at michaelhoffer.de Tue Feb 6 12:59:31 2018 From: info at michaelhoffer.de (Michael Hoffer) Date: Tue, 6 Feb 2018 13:59:31 +0100 Subject: Fwd: More community participation in JavaFX In-Reply-To: References: <5A786D32.6050600@oracle.com> <1453a93e-0f34-194e-c8c6-9ab57b9c3f42@oracle.com> Message-ID: I don't kow if it is sufficient. But there's a CLA assistant for GitHub repositories: https://github.com/cla-assistant/cla-assistant Regards, Michael -- Michael Hoffer Twitter: @mihosoft Webpage: www.mihosoft.eu Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) Goethe-Universit?t Kettenhofweg 139 60325 Frankfurt am Main phone: +49 69 798 25254 <+49%2069%2079825254> info at michaelhoffer.de 2018-02-06 13:48 GMT+01:00 dalibor topic : > > > On 05.02.2018 15:41, Kevin Rushforth wrote: > >> Yes, this sounds like a good step in the right direction. This would give >> anyone (with a signed OCA) the ability to create their own branch, commit >> changes to it, submit a PR, etc. >> > > One non-obvious point to keep in mind is that you do need to make sure > that all contributors (to a PR, wiki entry, etc.) have signed the OCA, or > the change can't be integrated back into the OpenJFX upstream. > > I don't think that GitHub offers programmatic, conditional access to its > functionality fo contributors, so enforcing that kind of requirement can be > a source of frustration. Not enforcing it, on the other hand, creates long > term frustration as well. [0] > > cheers, > dalibor topic > > [0] The implosion of the TeamFX repo is a good example. > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 H > > amburg > > 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, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From kevin.rushforth at oracle.com Tue Feb 6 13:01:09 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Feb 2018 18:31:09 +0530 Subject: future content of OpenJFX In-Reply-To: References: Message-ID: <5A79A715.7030709@oracle.com> I think this is a great way to frame the discussion. To add to the part about developers sometimes being willing to contribute part of the cost for feature X, I would say that in some (many?) cases, those developers might even think that they are doing the entire job by implementing feature X. It's been my experience, that contributors to an open source project often don't realize that the "total cost" of a new feature includes making sure that the design and interfaces are solid, that it is well documented, that it fits in with the existing features, that the interactions with other components in the system have been fully explored and addressed, that the implementation is both testable and has tests (preferably automated) that verify correct operation, fixing bugs for a period of time (no significantly large feature is completely bug free), etc. Additionally, there is the time and effort needed to review the work for correctness, security, maintainability, etc. Not to mention that the larger and more intrusive a feature is, the more carefully it will need to be reviewed by people who know the areas of code in question. -- Kevin Johan Vos wrote: > In order to separate the "What" from the "How" (discussed in another > thread), I would like to start a discussion about what people think should > be considered for future JavaFX work. > > I'd like to start with what I think is an important note on the context. > If I want feature X in JavaFX, I ask myself two questions: > 1. Do I want to contribute time and do it (at least for a large part) > myself? > 2. Do I want to spend money on it? > > If that sounds too economic or commercial, I recommend reading the > excellent blog entry by David Blevins about funding Java EE development > (more than 4 years old and still very relevant): > http://www.tomitribe.com/blog/2013/11/feed-the-fish/ > > Actually, this is a model we've been using at Gluon for a number of > customers. When people ask us about a specific feature, we ask if they are > willing to pay us for the development, AND if they are ok with us donating > it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX, > JavaFXports, Gluon Charm Down, Gluon Maps,...). > As a consequence, the features we are working on are all relevant to (at > least a part of) the industry. Some companies doubt there is business value > in JavaFX, we prove the opposite while making the Open Source community > better. > > I think by now it should be clear to all that there is no free lunch > (anymore). If your business depends on a feature being added to JavaFX, how > much (time/money) are you willing to contribute? If the answer is > "nothing", you can still hope that others want to do it, and in many cases > that will eventually happen -- but you don't control the timeline. > > This principle is a bit a simplification though. In many practical cases, > people want to have feature X and are willing to contribute "something" > (e.g. they want to work on it in spare-time, or fund 20% of a developer) > but not enough to do everything. > I think in this case it's a matter of gathering enough interest in this > community. Once enough developers are interested in that same feature, and > agree to spend resources on it, the burden can be shared. Having a sandbox > repositories with forks will make this easier. > > Areas that I personally want to see on the roadmap: > * more alignment with mobile > * a clean and lean low-level rendering pipeline API that would allow easier > plugability with upcoming low-level rendering systems > * extensions for Chart API > > - Johan > From tom.schindl at bestsolution.at Tue Feb 6 13:05:22 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 6 Feb 2018 14:05:22 +0100 Subject: More community participation in JavaFX In-Reply-To: <1453a93e-0f34-194e-c8c6-9ab57b9c3f42@oracle.com> References: <5A786D32.6050600@oracle.com> <1453a93e-0f34-194e-c8c6-9ab57b9c3f42@oracle.com> Message-ID: Hi, Well Eclipse.org repositories at Github have support to track if you signed a CLA with the Eclipse Foundation and I'm unable to merge PRs if that check fails. Tom On 06.02.18 13:48, dalibor topic wrote: > > > On 05.02.2018 15:41, Kevin Rushforth wrote: >> Yes, this sounds like a good step in the right direction. This would >> give anyone (with a signed OCA) the ability to create their own >> branch, commit changes to it, submit a PR, etc. > > One non-obvious point to keep in mind is that you do need to make sure > that all contributors (to a PR, wiki entry, etc.) have signed the OCA, > or the change can't be integrated back into the OpenJFX upstream. > > I don't think that GitHub offers programmatic, conditional access to its > functionality fo contributors, so enforcing that kind of requirement can > be a source of frustration. Not enforcing it, on the other hand, creates > long term frustration as well. [0] > > cheers, > dalibor topic > > [0] The implosion of the TeamFX repo is a good example. From paulrussell70 at gmail.com Tue Feb 6 13:11:20 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Tue, 6 Feb 2018 13:11:20 +0000 Subject: future content of OpenJFX Message-ID: I think ref: numbers of developers, the willingness of Oracle to open JavaFX up to the community has not reached significant numbers. There are a lot of people who've lost interest in following the framework a long time ago. If we are going to improve the low level rendering API, (I've a great deal to say on this - in another thread), and we can improve scene graph speed etc. Then I think some posts in relevant forums should promote this. The java game dev. forum would be one such place. http://www.java-gaming.org/ From kevin.rushforth at oracle.com Tue Feb 6 13:26:30 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Feb 2018 18:56:30 +0530 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> <5A70C18E.30805@oracle.com> <5A71D0FF.1040004@oracle.com> <5A736F19.30503@oracle.com> Message-ID: <5A79AD06.8030907@oracle.com> It looks fine to me, although the files should be change back to have UNIX-style line endings to minimize diffs (I can easily do that when I push the change for you). As for the javafx.web failures, you likely won't get any different results when building webkit. To fix these failures, you might need to add the following directory: modules/javafx.web/src/main/native/Source/WebCore/bindings/java/dom3/java/ -- Kevin Nir Lisker wrote: > Attached webrev for .classpath changes for all javafx.xxx projects > under /modules (though 2 of them are not modules). > > Change details: > - The files were completely rewritten for Eclipse's current modular > support, version 4.8M5, which is pre-release. > - Some projects also need to change module-info.java for test code to > identify imports properly due to bugs in Eclipse. These changes are > excluded from the Webrev. > - Since I didn't build Webkit, the web module has extra errors which I > couldn't address, so the fix does not guarantee that this module will > compile even with Webkit. > - The swt project has external org.eclipse.swt imports which weren't > addressed. > > Let's call this round 1. Next rounds will be when Eclipse fixes some > bugs and when the source repo is cleaned from unused projects. > > - Nir > > On Fri, Feb 2, 2018 at 6:52 PM, Nir Lisker > wrote: > > Alright, got most of them ready. > > About buildSrc: > - What is > "rt\buildSrc\build\generated-src\antlr\com\sun\scenario\effect\compiler" > supposed to be? It is listed as a source folder but it's empty. > - The project lists dependencies such as > "build/libs/swt-debug.jar", JUnit and a JRE/JDK, but doesn't need > any of them (from Eclipse's point of view). I see the base module > listing this project as a dependency, but it's not used. Where is > it located in the dependency chain? > > On Thu, Feb 1, 2018 at 9:48 PM, Kevin Rushforth > > > wrote: > > It probably makes sense to submit what you have now as a > partially working solution. > > As for Eclipse making any changes, I'm not sure there is a > spec you could point to ... we do some of the same magic that > I'm sure other projects have had to do w.r.t running tests: > > * We have test "shims" for white-box testing that we add into > our modules when running tests (this requires copying all of > the class files for our modules and adding the shim classes on > top of that) > > * We build the tests separately (the tests are in a separate > source set in gradle) without a module-info so that they run > in the unnamed module. This allows them to access JUnit, etc., > as well as any public package of any module in the system. As > such we need to explicitly list any internal packages that > they use from the module they are testing. These are listed in > src/test/addExports > > > -- Kevin > > > Nir Lisker wrote: >> Looks like I understood the problem. Eclipse does not support >> (yet) multiple modules per project. Do you know any >> specifications I can point them to to fix this properly? >> >> The current workaround would be to add 'requires' for all the >> modules which are used in tests as well. This change is local >> and would be excluded from webrevs. >> >> At this point I can either submit the partially fixed Eclipse >> files, which work with main code fully and with test code >> only if the above fix is used; or wait until Eclipse sorts it >> out. >> >> On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth >> > > wrote: >> >> >> >> Nir Lisker wrote: >>> >>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>> rt/modules/javafx.base/src/main/java/ >>> >>> >>> Why not rely on source first? >> >> Yes, that might work...you could try switching the order. >> >> >>> >>> Another question as I move along: there are imports >>> from java.util.logging in base module, but the >>> module-info doesn't require java.logging. How do I give >>> access to these imports? >> >> The only references to java.util.logging are in the >> javafx.base unit tests, which are compiled and run in the >> unnamed modules (no module-info.java for the unit tests). >> >> -- Kevin >> >> >> >>> On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth >>> >> > wrote: >>> >>> Oh, I see. You are pointing to the exploded modules >>> for the JDK in build/XXXXX/jdk rather than the JDK >>> image in build/XXXXX/images/jdk. >>> >>> Yes, I think it would be preferable to both reverse >>> the order and also add in the location of the built >>> class files. So the following order seems best: >>> >>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>> rt/modules/javafx.base/src/main/java/ >>> jdk/modules/javafx.base >>> >>> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>>> This is what I mean: In the >>>> type /base/src/test/java/test/com/sun/javafx/collections/ListListenerHelperTest.java >>>> there are these imports: >>>> >>>> import test.javafx.collections.MockListObserver; >>>> import java.util.BitSet; >>>> import javafx.beans.Observable; >>>> >>>> The first one is the one in >>>> FX: rt\modules\javafx.base\src\test\java\test\javafx\collections\MockListObserver.java >>>> The second one is in the referenced JDK which was >>>> built with >>>> FX: jdk\modules\java.base\java\util\BitSet.class >>>> The third one exists in both: >>>> - in JFX it's in: >>>> rt\modules\javafx.base\src\main\java\javafx\beans\Observable.java >>>> - in the JDK it's >>>> in: jdk\modules\javafx.base\javafx\beans\Observable.class >>>> >>>> Does the question make sense now? >>>> >>>> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth >>>> >>> > wrote: >>>> >>>> >>>>> one in >>>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>>> or the one in >>>>> "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? >>>> >>>> Not sure I get what you mean. There isn't a >>>> jdk/modules/ directory created by the build. >>>> Perhaps this is an Eclipse construct that it >>>> uses to indicate the modules that are in the >>>> JDK that you are using? The FX build puts the >>>> class files in: >>>> >>>> rt/build/modular_sdk/modules/javafx.base/... >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Nir Lisker wrote: >>>>> Another question: do imports of javafx.* >>>>> packages point to the javafx source or to the >>>>> jdk compilation? >>>>> >>>>> For example, in the base module, the type >>>>> test.javafx.beans.InvalidationListenerMock >>>>> imports javafx.beans.InvalidationListener >>>>> (twice, by the way, along with Observable). >>>>> Should the imported class be the one in >>>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>>> or the one in >>>>> "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? >>>>> >>>>> Currently, the way it is in the Eclipse files >>>>> is that the jdk .class files are imported >>>>> first[1], but it seemed odd to me - if I work >>>>> on 2 files which depend on each other they >>>>> should see the changes in each other at once. >>>>> >>>>> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d127c6ed5/modules/javafx.base/.classpath >>>>> >>>>> ("JRE_CONTAINER" is before "src/main/java"), >>>>> >>>>> - Nir >>>>> >>>>> On Fri, Jan 26, 2018 at 9:20 PM, Kevin >>>>> Rushforth >>>> > wrote: >>>>> >>>>> inline >>>>> >>>>> Nir Lisker wrote: >>>>>> Alright, cleaned that part. fxpackager >>>>>> build fails with an internal NPE in >>>>>> Eclipse, so I'm going to leave that alone >>>>>> and all of the projects that depends on it. >>>>>> >>>>>> Now that projects can be built there are >>>>>> errors in deeper levels: >>>>>> >>>>>> 1. All org.junit imports cannot be >>>>>> resolved. This causes tons of errors in >>>>>> various test folders obviously. All the >>>>>> .classpath files use >>>>>> >>>>>> >>>>> path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/> >>>>>> >>>>>> which is a jar distributed with Eclipse >>>>>> (in the plugins folder) with version >>>>>> 4.12.0. Is this really where the imports >>>>>> are supposed to come from? How does it >>>>>> work in Netbeans or IntelliJ? >>>>> >>>>> For NetBeans we use their internal version >>>>> of JUnit. I don't know about IntelliJ >>>>> (maybe someone else on the list can answer >>>>> that). >>>>> >>>>>> 2. In the 'base' module, in >>>>>> "/src/main/java-jfr/com/sun/javafx/logging" >>>>>> there are imports of >>>>>> com.oracle.jrockit.jfr that can't be >>>>>> resolved. Where are these located? >>>>> >>>>> These classes used to be part of the JFR >>>>> commercial feature in the Oracle JDK. The >>>>> java-jfr sources are obsolete and no >>>>> longer built (and no longer buildable), so >>>>> you can safely remove it from your IDE >>>>> files. I also still see references to it >>>>> in the netbeans/base project. I will file >>>>> a bug to remove this obsolete code and fix >>>>> the NetBeans references at the same time. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin >>>>>> Rushforth >>>>> > wrote: >>>>>> >>>>>> Ah, I see. Then yes, just removing >>>>>> the old ones is fine. >>>>>> >>>>>> As for the larger question, unless >>>>>> there are dependencies on apps, you >>>>>> can assume that the only ones you >>>>>> care about are the ones created by >>>>>> "gradle sdk". >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Nir Lisker wrote: >>>>>>> So this is why I was asking about >>>>>>> the optional stuff: 'graphics' >>>>>>> module has BOTH >>>>>>> >>>>>>> build/resources/jsl-decora >>>>>>> build/resources/jsl-prism >>>>>>> >>>>>>> and >>>>>>> >>>>>>> build/gensrc/jsl-decora >>>>>>> build/gensrc/jsl-prism >>>>>>> >>>>>>> That led me to think that when the >>>>>>> new dependencies were added the old >>>>>>> ones weren't removed. Those that >>>>>>> weren't optional (like the >>>>>>> /resources ones, which I removed) >>>>>>> were easy to catch and we could have >>>>>>> finished here. Those that are >>>>>>> optional are not causing trouble >>>>>>> even when missing because they are >>>>>>> optional. >>>>>>> >>>>>>> gradle sdk does not create the ones >>>>>>> which are marked optional that Iv'e >>>>>>> surveyed, but I don't know if that's >>>>>>> the only way they can be created. If >>>>>>> I compare solely with gradle sdk >>>>>>> then I can just remove whatever is >>>>>>> missing on grounds that it's left over. >>>>>>> >>>>>>> - Nir >>>>>>> >>>>>>> On Thu, Jan 25, 2018 at 4:06 PM, >>>>>>> Kevin Rushforth >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> One more thing about the >>>>>>> specific path you mentioned as >>>>>>> not being there. >>>>>>> >>>>>>> >>>>>> exported="true" >>>>>>> path="build/resources/jsl-decora"/> >>>>>>> >>>>>> exported="true" >>>>>>> path="build/resources/jsl-prism"/> >>>>>>> >>>>>>> These are still being created by >>>>>>> 'gradle sdk', but the path is >>>>>>> wrong (the files moved in JDK 9) >>>>>>> and should be: >>>>>>> >>>>>>> build/gensrc/jsl-decora >>>>>>> build/gensrc/jsl-prism >>>>>>> >>>>>>> You might want to take that into >>>>>>> account. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Kevin Rushforth wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Nir Lisker wrote: >>>>>>> >>>>>>> Iv'e removed all the >>>>>>> classpath dependencies >>>>>>> that were causing >>>>>>> errors. I don't mind >>>>>>> sorting out the rest of >>>>>>> the files while at it, >>>>>>> though for that there >>>>>>> are a few things I'm not >>>>>>> sure about: >>>>>>> >>>>>>> 1. Some dependencies are >>>>>>> marked as optional and >>>>>>> as such they don't cause >>>>>>> errors, but they are >>>>>>> still missing. Is it >>>>>>> safe to remove them or >>>>>>> is it possible that they >>>>>>> will be created as some >>>>>>> point? >>>>>>> >>>>>>> >>>>>>> Some of them might be >>>>>>> created...not sure without >>>>>>> checking. I recommend >>>>>>> running "gradle sdk" and >>>>>>> then seeing if the >>>>>>> dependencies are there. >>>>>>> >>>>>>> Examples are the 'base' >>>>>>> module with >>>>>>> "src/test/resources" and >>>>>>> "src/main/resources" >>>>>>> optional dependencies, >>>>>>> and 'controls' module >>>>>>> has the optional >>>>>>> dependency >>>>>>> "src/main/resources" >>>>>>> commented out. >>>>>>> >>>>>>> >>>>>>> I see. You might as well >>>>>>> leave them, but it probably >>>>>>> doesn't matter. >>>>>>> >>>>>>> 2. Can I assume that all >>>>>>> other dependencies are >>>>>>> really needed? (Eclipse >>>>>>> won't complain about >>>>>>> unused ones as far as I >>>>>>> know.) >>>>>>> >>>>>>> >>>>>>> That seems best. >>>>>>> >>>>>>> 3. What are the >>>>>>> formatting standards for >>>>>>> XML (indentation, line >>>>>>> length...)? From a quick >>>>>>> look I see different >>>>>>> styles in different files. >>>>>>> >>>>>>> >>>>>>> For IDE files, we don't >>>>>>> worry about formatting. In >>>>>>> many cases they are >>>>>>> auto-generated anyway. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> - Nir >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > From dalibor.topic at oracle.com Tue Feb 6 13:29:46 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 6 Feb 2018 14:29:46 +0100 Subject: More community participation in JavaFX In-Reply-To: <5A73A220.7030706@oracle.com> References: <5A73A220.7030706@oracle.com> Message-ID: <88be1dd3-08d4-8feb-1fe7-7a111c3d9348@oracle.com> On 02.02.2018 00:26, Kevin Rushforth wrote: > We are specifically looking to discuss ideas around the following areas: > > * Easing barriers to contribution (e.g., making JavaFX easier to build, > better documentation, making it easier to test changes) I'd suggest explicitly asking for feedback from the maintainers of downstream builds, such as https://www.archlinux.org/packages/extra/x86_64/java-openjfx/ https://packages.debian.org/source/sid/openjfx https://admin.fedoraproject.org/pkgdb/package/rpms/openjfx/ https://www.freshports.org/java/openjfx8-devel In the case of the JDK, downstream builders of OpenJDK tend to provide very useful first hand feedback of barriers to building & contribution, and often end up becoming regular contributors themselves, due to the hard, fundamental nature of (build) problems one needs to resolve to be able to provide a working build for one's own operating system. 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From nlisker at gmail.com Mon Feb 5 02:40:38 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 5 Feb 2018 04:40:38 +0200 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> <5A70C18E.30805@oracle.com> <5A71D0FF.1040004@oracle.com> <5A736F19.30503@oracle.com> Message-ID: Attached webrev for .classpath changes for all javafx.xxx projects under /modules (though 2 of them are not modules). Change details: - The files were completely rewritten for Eclipse's current modular support, version 4.8M5, which is pre-release. - Some projects also need to change module-info.java for test code to identify imports properly due to bugs in Eclipse. These changes are excluded from the Webrev. - Since I didn't build Webkit, the web module has extra errors which I couldn't address, so the fix does not guarantee that this module will compile even with Webkit. - The swt project has external org.eclipse.swt imports which weren't addressed. Let's call this round 1. Next rounds will be when Eclipse fixes some bugs and when the source repo is cleaned from unused projects. - Nir On Fri, Feb 2, 2018 at 6:52 PM, Nir Lisker wrote: > Alright, got most of them ready. > > About buildSrc: > - What is "rt\buildSrc\build\generated-src\antlr\com\sun\scenario\effect\compiler" > supposed to be? It is listed as a source folder but it's empty. > - The project lists dependencies such as "build/libs/swt-debug.jar", JUnit > and a JRE/JDK, but doesn't need any of them (from Eclipse's point of view). > I see the base module listing this project as a dependency, but it's not > used. Where is it located in the dependency chain? > > On Thu, Feb 1, 2018 at 9:48 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> It probably makes sense to submit what you have now as a partially >> working solution. >> >> As for Eclipse making any changes, I'm not sure there is a spec you could >> point to ... we do some of the same magic that I'm sure other projects have >> had to do w.r.t running tests: >> >> * We have test "shims" for white-box testing that we add into our modules >> when running tests (this requires copying all of the class files for our >> modules and adding the shim classes on top of that) >> >> * We build the tests separately (the tests are in a separate source set >> in gradle) without a module-info so that they run in the unnamed module. >> This allows them to access JUnit, etc., as well as any public package of >> any module in the system. As such we need to explicitly list any internal >> packages that they use from the module they are testing. These are listed >> in src/test/addExports >> >> >> -- Kevin >> >> >> Nir Lisker wrote: >> >> Looks like I understood the problem. Eclipse does not support (yet) >> multiple modules per project. Do you know any specifications I can point >> them to to fix this properly? >> >> The current workaround would be to add 'requires' for all the modules >> which are used in tests as well. This change is local and would be excluded >> from webrevs. >> >> At this point I can either submit the partially fixed Eclipse files, >> which work with main code fully and with test code only if the above fix is >> used; or wait until Eclipse sorts it out. >> >> On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> >>> >>> Nir Lisker wrote: >>> >>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>>> rt/modules/javafx.base/src/main/java/ >>> >>> >>> Why not rely on source first? >>> >>> >>> Yes, that might work...you could try switching the order. >>> >>> >>> >>> Another question as I move along: there are imports >>> from java.util.logging in base module, but the module-info doesn't >>> require java.logging. How do I give access to these imports? >>> >>> >>> The only references to java.util.logging are in the javafx.base unit >>> tests, which are compiled and run in the unnamed modules (no >>> module-info.java for the unit tests). >>> >>> -- Kevin >>> >>> >>> >>> On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> Oh, I see. You are pointing to the exploded modules for the JDK in >>>> build/XXXXX/jdk rather than the JDK image in build/XXXXX/images/jdk. >>>> >>>> Yes, I think it would be preferable to both reverse the order and also >>>> add in the location of the built class files. So the following order seems >>>> best: >>>> >>>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>>> rt/modules/javafx.base/src/main/java/ >>>> jdk/modules/javafx.base >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Nir Lisker wrote: >>>> >>>> This is what I mean: In the type /base/src/test/java/test/ >>>> com/sun/javafx/collections/ListListenerHelperTest.java there are these >>>> imports: >>>> >>>> import test.javafx.collections.MockListObserver; >>>> import java.util.BitSet; >>>> import javafx.beans.Observable; >>>> >>>> The first one is the one in FX: rt\modules\javafx.base\src >>>> \test\java\test\javafx\collections\MockListObserver.java >>>> The second one is in the referenced JDK which was built with >>>> FX: jdk\modules\java.base\java\util\BitSet.class >>>> The third one exists in both: >>>> - in JFX it's in: rt\modules\javafx.base\src\mai >>>> n\java\javafx\beans\Observable.java >>>> - in the JDK it's in: jdk\modules\javafx.base\ja >>>> vafx\beans\Observable.class >>>> >>>> Does the question make sense now? >>>> >>>> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> >>>>> one in "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>>> or the one in "jdk\modules\javafx.base\javaf >>>>> x\beans\InvalidationListener.class"? >>>>> >>>>> >>>>> Not sure I get what you mean. There isn't a jdk/modules/ directory >>>>> created by the build. Perhaps this is an Eclipse construct that it uses to >>>>> indicate the modules that are in the JDK that you are using? The FX build >>>>> puts the class files in: >>>>> >>>>> rt/build/modular_sdk/modules/javafx.base/... >>>>> >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Nir Lisker wrote: >>>>> >>>>> Another question: do imports of javafx.* packages point to the javafx >>>>> source or to the jdk compilation? >>>>> >>>>> For example, in the base module, the type >>>>> test.javafx.beans.InvalidationListenerMock >>>>> imports javafx.beans.InvalidationListener (twice, by the way, along >>>>> with Observable). Should the imported class be the one in >>>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>>> or the one in "jdk\modules\javafx.base\javaf >>>>> x\beans\InvalidationListener.class"? >>>>> >>>>> Currently, the way it is in the Eclipse files is that the jdk .class >>>>> files are imported first[1], but it seemed odd to me - if I work on 2 files >>>>> which depend on each other they should see the changes in each other at >>>>> once. >>>>> >>>>> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d12 >>>>> 7c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before >>>>> "src/main/java"), >>>>> >>>>> - Nir >>>>> >>>>> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> inline >>>>>> >>>>>> Nir Lisker wrote: >>>>>> >>>>>> Alright, cleaned that part. fxpackager build fails with an internal >>>>>> NPE in Eclipse, so I'm going to leave that alone and all of the projects >>>>>> that depends on it. >>>>>> >>>>>> Now that projects can be built there are errors in deeper levels: >>>>>> >>>>>> 1. All org.junit imports cannot be resolved. This causes tons of >>>>>> errors in various test folders obviously. All the .classpath files use >>>>>> >>>>>> >>>>>> >>>>>> which is a jar distributed with Eclipse (in the plugins folder) with >>>>>> version 4.12.0. Is this really where the imports are supposed to come from? >>>>>> How does it work in Netbeans or IntelliJ? >>>>>> >>>>>> >>>>>> For NetBeans we use their internal version of JUnit. I don't know >>>>>> about IntelliJ (maybe someone else on the list can answer that). >>>>>> >>>>>> 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging" >>>>>> there are imports of com.oracle.jrockit.jfr that can't be resolved. Where >>>>>> are these located? >>>>>> >>>>>> >>>>>> These classes used to be part of the JFR commercial feature in the >>>>>> Oracle JDK. The java-jfr sources are obsolete and no longer built (and no >>>>>> longer buildable), so you can safely remove it from your IDE files. I also >>>>>> still see references to it in the netbeans/base project. I will file a bug >>>>>> to remove this obsolete code and fix the NetBeans references at the same >>>>>> time. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth < >>>>>> kevin.rushforth at oracle.com> wrote: >>>>>> >>>>>>> Ah, I see. Then yes, just removing the old ones is fine. >>>>>>> >>>>>>> As for the larger question, unless there are dependencies on apps, >>>>>>> you can assume that the only ones you care about are the ones created by >>>>>>> "gradle sdk". >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Nir Lisker wrote: >>>>>>> >>>>>>> So this is why I was asking about the optional stuff: 'graphics' >>>>>>> module has BOTH >>>>>>> >>>>>>> build/resources/jsl-decora >>>>>>> build/resources/jsl-prism >>>>>>> >>>>>>> and >>>>>>> >>>>>>> build/gensrc/jsl-decora >>>>>>> build/gensrc/jsl-prism >>>>>>> >>>>>>> That led me to think that when the new dependencies were added the >>>>>>> old ones weren't removed. Those that weren't optional (like the /resources >>>>>>> ones, which I removed) were easy to catch and we could have finished here. >>>>>>> Those that are optional are not causing trouble even when missing because >>>>>>> they are optional. >>>>>>> >>>>>>> gradle sdk does not create the ones which are marked optional that >>>>>>> Iv'e surveyed, but I don't know if that's the only way they can be created. >>>>>>> If I compare solely with gradle sdk then I can just remove whatever is >>>>>>> missing on grounds that it's left over. >>>>>>> >>>>>>> - Nir >>>>>>> >>>>>>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth < >>>>>>> kevin.rushforth at oracle.com> wrote: >>>>>>> >>>>>>>> One more thing about the specific path you mentioned as not being >>>>>>>> there. >>>>>>>> >>>>>>>> >>>>>>> path="build/resources/jsl-decora"/> >>>>>>>> >>>>>>> path="build/resources/jsl-prism"/> >>>>>>>> >>>>>>>> These are still being created by 'gradle sdk', but the path is >>>>>>>> wrong (the files moved in JDK 9) and should be: >>>>>>>> >>>>>>>> build/gensrc/jsl-decora >>>>>>>> build/gensrc/jsl-prism >>>>>>>> >>>>>>>> You might want to take that into account. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Kevin Rushforth wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Nir Lisker wrote: >>>>>>>>> >>>>>>>>>> Iv'e removed all the classpath dependencies that were causing >>>>>>>>>> errors. I don't mind sorting out the rest of the files while at it, though >>>>>>>>>> for that there are a few things I'm not sure about: >>>>>>>>>> >>>>>>>>>> 1. Some dependencies are marked as optional and as such they >>>>>>>>>> don't cause errors, but they are still missing. Is it safe to remove them >>>>>>>>>> or is it possible that they will be created as some point? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Some of them might be created...not sure without checking. I >>>>>>>>> recommend running "gradle sdk" and then seeing if the dependencies are >>>>>>>>> there. >>>>>>>>> >>>>>>>>> Examples are the 'base' module with "src/test/resources" and >>>>>>>>>> "src/main/resources" optional dependencies, and 'controls' module has the >>>>>>>>>> optional dependency "src/main/resources" commented out. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I see. You might as well leave them, but it probably doesn't >>>>>>>>> matter. >>>>>>>>> >>>>>>>>> 2. Can I assume that all other dependencies are really needed? >>>>>>>>>> (Eclipse won't complain about unused ones as far as I know.) >>>>>>>>>> >>>>>>>>> >>>>>>>>> That seems best. >>>>>>>>> >>>>>>>>> 3. What are the formatting standards for XML (indentation, line >>>>>>>>>> length...)? From a quick look I see different styles in different files. >>>>>>>>>> >>>>>>>>> >>>>>>>>> For IDE files, we don't worry about formatting. In many cases they >>>>>>>>> are auto-generated anyway. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>>> - Nir >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From nlisker at gmail.com Tue Feb 6 14:11:46 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 6 Feb 2018 16:11:46 +0200 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: <5A79AD06.8030907@oracle.com> References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> <5A70C18E.30805@oracle.com> <5A71D0FF.1040004@oracle.com> <5A736F19.30503@oracle.com> <5A79AD06.8030907@oracle.com> Message-ID: Attached updated webrev. Changed line endings. If something is still wrong you can change it. You were right about the missing web source folder. Project now builds without errors. On Tue, Feb 6, 2018 at 3:26 PM, Kevin Rushforth wrote: > It looks fine to me, although the files should be change back to have > UNIX-style line endings to minimize diffs (I can easily do that when I push > the change for you). > > As for the javafx.web failures, you likely won't get any different results > when building webkit. To fix these failures, you might need to add the > following directory: > > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/dom3/java/ > > > -- Kevin > > > Nir Lisker wrote: > > Attached webrev for .classpath changes for all javafx.xxx projects under > /modules (though 2 of them are not modules). > > Change details: > - The files were completely rewritten for Eclipse's current modular > support, version 4.8M5, which is pre-release. > - Some projects also need to change module-info.java for test code to > identify imports properly due to bugs in Eclipse. These changes are > excluded from the Webrev. > - Since I didn't build Webkit, the web module has extra errors which I > couldn't address, so the fix does not guarantee that this module will > compile even with Webkit. > - The swt project has external org.eclipse.swt imports which weren't > addressed. > > Let's call this round 1. Next rounds will be when Eclipse fixes some bugs > and when the source repo is cleaned from unused projects. > > - Nir > > On Fri, Feb 2, 2018 at 6:52 PM, Nir Lisker wrote: > >> Alright, got most of them ready. >> >> About buildSrc: >> - What is "rt\buildSrc\build\generated-src\antlr\com\sun\scenario\effect\compiler" >> supposed to be? It is listed as a source folder but it's empty. >> - The project lists dependencies such as "build/libs/swt-debug.jar", >> JUnit and a JRE/JDK, but doesn't need any of them (from Eclipse's point of >> view). I see the base module listing this project as a dependency, but it's >> not used. Where is it located in the dependency chain? >> >> On Thu, Feb 1, 2018 at 9:48 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> It probably makes sense to submit what you have now as a partially >>> working solution. >>> >>> As for Eclipse making any changes, I'm not sure there is a spec you >>> could point to ... we do some of the same magic that I'm sure other >>> projects have had to do w.r.t running tests: >>> >>> * We have test "shims" for white-box testing that we add into our >>> modules when running tests (this requires copying all of the class files >>> for our modules and adding the shim classes on top of that) >>> >>> * We build the tests separately (the tests are in a separate source set >>> in gradle) without a module-info so that they run in the unnamed module. >>> This allows them to access JUnit, etc., as well as any public package of >>> any module in the system. As such we need to explicitly list any internal >>> packages that they use from the module they are testing. These are listed >>> in src/test/addExports >>> >>> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>> >>> Looks like I understood the problem. Eclipse does not support (yet) >>> multiple modules per project. Do you know any specifications I can point >>> them to to fix this properly? >>> >>> The current workaround would be to add 'requires' for all the modules >>> which are used in tests as well. This change is local and would be excluded >>> from webrevs. >>> >>> At this point I can either submit the partially fixed Eclipse files, >>> which work with main code fully and with test code only if the above fix is >>> used; or wait until Eclipse sorts it out. >>> >>> On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> >>>> >>>> Nir Lisker wrote: >>>> >>>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>>>> rt/modules/javafx.base/src/main/java/ >>>> >>>> >>>> Why not rely on source first? >>>> >>>> >>>> Yes, that might work...you could try switching the order. >>>> >>>> >>>> >>>> Another question as I move along: there are imports >>>> from java.util.logging in base module, but the module-info doesn't >>>> require java.logging. How do I give access to these imports? >>>> >>>> >>>> The only references to java.util.logging are in the javafx.base unit >>>> tests, which are compiled and run in the unnamed modules (no >>>> module-info.java for the unit tests). >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> Oh, I see. You are pointing to the exploded modules for the JDK in >>>>> build/XXXXX/jdk rather than the JDK image in build/XXXXX/images/jdk. >>>>> >>>>> Yes, I think it would be preferable to both reverse the order and also >>>>> add in the location of the built class files. So the following order seems >>>>> best: >>>>> >>>>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>>>> rt/modules/javafx.base/src/main/java/ >>>>> jdk/modules/javafx.base >>>>> >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Nir Lisker wrote: >>>>> >>>>> This is what I mean: In the type /base/src/test/java/test/ >>>>> com/sun/javafx/collections/ListListenerHelperTest.java there are >>>>> these imports: >>>>> >>>>> import test.javafx.collections.MockListObserver; >>>>> import java.util.BitSet; >>>>> import javafx.beans.Observable; >>>>> >>>>> The first one is the one in FX: rt\modules\javafx.base\src >>>>> \test\java\test\javafx\collections\MockListObserver.java >>>>> The second one is in the referenced JDK which was built with >>>>> FX: jdk\modules\java.base\java\util\BitSet.class >>>>> The third one exists in both: >>>>> - in JFX it's in: rt\modules\javafx.base\src\mai >>>>> n\java\javafx\beans\Observable.java >>>>> - in the JDK it's in: jdk\modules\javafx.base\ja >>>>> vafx\beans\Observable.class >>>>> >>>>> Does the question make sense now? >>>>> >>>>> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> >>>>>> one in "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>>>> or the one in "jdk\modules\javafx.base\javaf >>>>>> x\beans\InvalidationListener.class"? >>>>>> >>>>>> >>>>>> Not sure I get what you mean. There isn't a jdk/modules/ directory >>>>>> created by the build. Perhaps this is an Eclipse construct that it uses to >>>>>> indicate the modules that are in the JDK that you are using? The FX build >>>>>> puts the class files in: >>>>>> >>>>>> rt/build/modular_sdk/modules/javafx.base/... >>>>>> >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Nir Lisker wrote: >>>>>> >>>>>> Another question: do imports of javafx.* packages point to the javafx >>>>>> source or to the jdk compilation? >>>>>> >>>>>> For example, in the base module, the type >>>>>> test.javafx.beans.InvalidationListenerMock >>>>>> imports javafx.beans.InvalidationListener (twice, by the way, along >>>>>> with Observable). Should the imported class be the one in >>>>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>>>> or the one in "jdk\modules\javafx.base\javaf >>>>>> x\beans\InvalidationListener.class"? >>>>>> >>>>>> Currently, the way it is in the Eclipse files is that the jdk .class >>>>>> files are imported first[1], but it seemed odd to me - if I work on 2 files >>>>>> which depend on each other they should see the changes in each other at >>>>>> once. >>>>>> >>>>>> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d12 >>>>>> 7c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before >>>>>> "src/main/java"), >>>>>> >>>>>> - Nir >>>>>> >>>>>> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth < >>>>>> kevin.rushforth at oracle.com> wrote: >>>>>> >>>>>>> inline >>>>>>> >>>>>>> Nir Lisker wrote: >>>>>>> >>>>>>> Alright, cleaned that part. fxpackager build fails with an internal >>>>>>> NPE in Eclipse, so I'm going to leave that alone and all of the projects >>>>>>> that depends on it. >>>>>>> >>>>>>> Now that projects can be built there are errors in deeper levels: >>>>>>> >>>>>>> 1. All org.junit imports cannot be resolved. This causes tons of >>>>>>> errors in various test folders obviously. All the .classpath files use >>>>>>> >>>>>>> >>>>>>> >>>>>>> which is a jar distributed with Eclipse (in the plugins folder) with >>>>>>> version 4.12.0. Is this really where the imports are supposed to come from? >>>>>>> How does it work in Netbeans or IntelliJ? >>>>>>> >>>>>>> >>>>>>> For NetBeans we use their internal version of JUnit. I don't know >>>>>>> about IntelliJ (maybe someone else on the list can answer that). >>>>>>> >>>>>>> 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging" >>>>>>> there are imports of com.oracle.jrockit.jfr that can't be resolved. Where >>>>>>> are these located? >>>>>>> >>>>>>> >>>>>>> These classes used to be part of the JFR commercial feature in the >>>>>>> Oracle JDK. The java-jfr sources are obsolete and no longer built (and no >>>>>>> longer buildable), so you can safely remove it from your IDE files. I also >>>>>>> still see references to it in the netbeans/base project. I will file a bug >>>>>>> to remove this obsolete code and fix the NetBeans references at the same >>>>>>> time. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth < >>>>>>> kevin.rushforth at oracle.com> wrote: >>>>>>> >>>>>>>> Ah, I see. Then yes, just removing the old ones is fine. >>>>>>>> >>>>>>>> As for the larger question, unless there are dependencies on apps, >>>>>>>> you can assume that the only ones you care about are the ones created by >>>>>>>> "gradle sdk". >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Nir Lisker wrote: >>>>>>>> >>>>>>>> So this is why I was asking about the optional stuff: 'graphics' >>>>>>>> module has BOTH >>>>>>>> >>>>>>>> build/resources/jsl-decora >>>>>>>> build/resources/jsl-prism >>>>>>>> >>>>>>>> and >>>>>>>> >>>>>>>> build/gensrc/jsl-decora >>>>>>>> build/gensrc/jsl-prism >>>>>>>> >>>>>>>> That led me to think that when the new dependencies were added the >>>>>>>> old ones weren't removed. Those that weren't optional (like the /resources >>>>>>>> ones, which I removed) were easy to catch and we could have finished here. >>>>>>>> Those that are optional are not causing trouble even when missing because >>>>>>>> they are optional. >>>>>>>> >>>>>>>> gradle sdk does not create the ones which are marked optional that >>>>>>>> Iv'e surveyed, but I don't know if that's the only way they can be created. >>>>>>>> If I compare solely with gradle sdk then I can just remove whatever is >>>>>>>> missing on grounds that it's left over. >>>>>>>> >>>>>>>> - Nir >>>>>>>> >>>>>>>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth < >>>>>>>> kevin.rushforth at oracle.com> wrote: >>>>>>>> >>>>>>>>> One more thing about the specific path you mentioned as not being >>>>>>>>> there. >>>>>>>>> >>>>>>>>> >>>>>>>> path="build/resources/jsl-decora"/> >>>>>>>>> >>>>>>>> path="build/resources/jsl-prism"/> >>>>>>>>> >>>>>>>>> These are still being created by 'gradle sdk', but the path is >>>>>>>>> wrong (the files moved in JDK 9) and should be: >>>>>>>>> >>>>>>>>> build/gensrc/jsl-decora >>>>>>>>> build/gensrc/jsl-prism >>>>>>>>> >>>>>>>>> You might want to take that into account. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Kevin Rushforth wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Nir Lisker wrote: >>>>>>>>>> >>>>>>>>>>> Iv'e removed all the classpath dependencies that were causing >>>>>>>>>>> errors. I don't mind sorting out the rest of the files while at it, though >>>>>>>>>>> for that there are a few things I'm not sure about: >>>>>>>>>>> >>>>>>>>>>> 1. Some dependencies are marked as optional and as such they >>>>>>>>>>> don't cause errors, but they are still missing. Is it safe to remove them >>>>>>>>>>> or is it possible that they will be created as some point? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Some of them might be created...not sure without checking. I >>>>>>>>>> recommend running "gradle sdk" and then seeing if the dependencies are >>>>>>>>>> there. >>>>>>>>>> >>>>>>>>>> Examples are the 'base' module with "src/test/resources" and >>>>>>>>>>> "src/main/resources" optional dependencies, and 'controls' module has the >>>>>>>>>>> optional dependency "src/main/resources" commented out. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I see. You might as well leave them, but it probably doesn't >>>>>>>>>> matter. >>>>>>>>>> >>>>>>>>>> 2. Can I assume that all other dependencies are really needed? >>>>>>>>>>> (Eclipse won't complain about unused ones as far as I know.) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That seems best. >>>>>>>>>> >>>>>>>>>> 3. What are the formatting standards for XML (indentation, line >>>>>>>>>>> length...)? From a quick look I see different styles in different files. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> For IDE files, we don't worry about formatting. In many cases >>>>>>>>>> they are auto-generated anyway. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> - Nir >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From murali.billa at oracle.com Tue Feb 6 17:11:56 2018 From: murali.billa at oracle.com (Murali Billa) Date: Tue, 6 Feb 2018 09:11:56 -0800 (PST) Subject: [11] Review request for 8196592: Mark unstable tests so they will be skipped until fixed Message-ID: ? Hi Kevin, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8196592 ? webrev: http://cr.openjdk.java.net/~mbilla/8196592/webrev.00/ Thanks, Murali From john at status6.com Tue Feb 6 20:49:26 2018 From: john at status6.com (John Neffenger) Date: Tue, 6 Feb 2018 12:49:26 -0800 Subject: future content of OpenJFX In-Reply-To: <07B463FC-F501-4A14-A78B-0681528D4601@gmail.com> References: <27d7049f-64d3-42d2-8eb7-af8fd92b6b55@me.com> <07B463FC-F501-4A14-A78B-0681528D4601@gmail.com> Message-ID: <4bbb243b-8a12-d3d2-fc36-b44bb4b62173@status6.com> On 02/05/2018 08:14 PM, John-Val Rose wrote: > ... is it possible that there are lots and lots of ?observers? or ?lurkers? out there just waiting until all the hard work of setting-up the physical and formal infrastructure to enable community contribution has been finalised before they?ll put their hands up? That's what this lurker is waiting for. :-) I really like the idea of having a staging repository and an open issue tracker at either GitHub or Bitbucket or GitLab. We'll find out how many people can contribute only after it's easy. John From johnvalrose at gmail.com Tue Feb 6 21:04:52 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Wed, 7 Feb 2018 08:04:52 +1100 Subject: future content of OpenJFX In-Reply-To: <4bbb243b-8a12-d3d2-fc36-b44bb4b62173@status6.com> References: <27d7049f-64d3-42d2-8eb7-af8fd92b6b55@me.com> <07B463FC-F501-4A14-A78B-0681528D4601@gmail.com> <4bbb243b-8a12-d3d2-fc36-b44bb4b62173@status6.com> Message-ID: Thanks for confirming my ?theory? :-) And just for clarity, I wasn?t referring to ?observers? or ?lurkers? in a derogatory fashion. In fact, it makes complete sense to only get involved when it enables you to make the most efficient use of your time. Who knows, the size of the ?talent pool? may be much bigger than I thought, which would be great!!! > On 7 Feb 2018, at 07:49, John Neffenger wrote: > >> On 02/05/2018 08:14 PM, John-Val Rose wrote: >> ... is it possible that there are lots and lots of ?observers? or ?lurkers? out there just waiting until all the hard work of setting-up the physical and formal infrastructure to enable community contribution has been finalised before they?ll put their hands up? > > That's what this lurker is waiting for. :-) I really like the idea of having a staging repository and an open issue tracker at either GitHub or Bitbucket or GitLab. > > We'll find out how many people can contribute only after it's easy. > > John From nlisker at gmail.com Tue Feb 6 21:46:29 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 6 Feb 2018 23:46:29 +0200 Subject: More community participation in JavaFX In-Reply-To: <5A786D32.6050600@oracle.com> References: <5A786D32.6050600@oracle.com> Message-ID: Another thing to be careful about with the sandbox/staging idea is the confusion that will arise with duplication. There will be 2 issue trackers (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and maybe 2 discussion lists. For those "in the know" this will be a simple matter, but for a potential contributor this can be a gamebreaker if not handled appropriately. Dalibor Topic's suggestion of contacting other mirrors can be instrumental in solving these problems. - Nir On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth wrote: > Yes, this sounds like a good step in the right direction. This would give > anyone (with a signed OCA) the ability to create their own branch, commit > changes to it, submit a PR, etc. > > I presume there will be a branch that is an exact mirror of the jfx-dev > repo on OpenJDK in addition to the development branch in the sandbox? > > The only thing to consider is whether it should be Committers or Reviewers > that have rights to merge into the sandbox development branch. There are > pros / cons of each. I'd probably lean towards having it be Committers, > with the idea that a Committer needs to sponsor the patch anyway and would > then be able to "take it the rest of the way". The only downside I see is > that you could end up with a few patches that get accepted into the sandbox > dev branch, but never make it to the upstream jfx-dev repo (or not without > significant change). I doubt this will be a big problem in practice. > > Either way, this could also provide a good alternative to webrev when > reviewing the final changes. > > -- Kevin > > > > Johan Vos wrote: > >> Hi Michael, >> >> This proposal is very much in line with my thinking as well. >> The problem is not that we don't have a github clone of OpenJFX. We have a >> number of them (e.g. I created https://github.com/javafxports/jfx-dev >> some >> months ago). We just need a single one that is updated constantly from >> mainstream, and standardize on that. Let's call that "sandbox" (I would be >> ok with staging as well, but sandbox is imho more inviting to people who >> want to try something drastic, e.g. support for Vulkan) >> >> The main issue is how to get contributions, review them, and eventually >> send them upstream. >> >> The PR review process is extremely important. If we lower that bar, we >> loose quality. If the bar is too high, great PR's won't be accepted >> upstream as there is not enough review time to review it. >> >> I agree giving the current OpenJFX committers merge rights for the >> "sandbox" repository makes sense. Once a public contribution is merged by >> one of those committers, that same committer can send it upstream to the >> existing OpenJFX repository. Additional checks will be performed there, >> mainly in order to make sure the overall "Feel of Java" is preserved. To >> that purpose, it would help to have a closer alignment with the OpenJDK >> community. >> >> We have to be aware that this will increase the workload of the current >> committers and reviewers. That is the price we pay for standardization. >> Rather than everyone creating his own forks of a UI framework in Java, we >> invest a lot in creating a single, generally agreed one. >> >> So in summary, I'm +1 on a 2-phase approach: "open" commits allowed in >> staging. OpenJFX committers accept PR's (if they are of good quality) and >> prepare upstream commits for OpenJFX. We hope there will be more >> contributors who become committers and reviewers in the medium term. >> >> - Johan >> >> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen >> wrote: >> >> >> >>> Those are great questions, and I think with Kevin/Oracle/other OpenJFX >>> devs >>> help we >>> can figure something out. >>> >>> My thinking is that the PR would be reviewed by basically anyone who has >>> free time. >>> I think that, at first, only OpenJFX committers will be able to merge >>> PRs. >>> They would >>> do the final review/merge to the staging repo after it has been reviewed >>> by >>> the "wider audience" >>> which includes people without commit rights (people like us). Then, as >>> this >>> thing evolves, >>> based on the pool of people who are contributing both pull requests and >>> PR >>> reviews, >>> the committers will be able to grant commit privileges to some people in >>> that pool. >>> >>> I can't think of any way that would make it so the changes are as likely >>> to >>> be >>> merged upstream as possible other than having the current OpenJFX >>> committers paving the >>> way. Hopefully this vision is aligned with Kevin's and hopefully these >>> concrete details >>> can be worked out. >>> >>> Regards, >>> Michael >>> >>> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker wrote: >>> >>> >>> >>>> So if a community ran GitHub is used for staging, who will approve PRs >>>> >>>> >>> for >>> >>> >>>> the code and the Wiki of the GitHub repo? >>>> >>>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen >>>> wrote: >>>> >>>> >>>> >>>>> Great points, Nir. We share the same hopes. I just wanted to piggy-back >>>>> on the >>>>> wiki thing: >>>>> >>>>> " * The Wiki could be open sourced as well (like other Wikis). I could >>>>> definitely update a page or 2 there and so would other developers as >>>>> >>>>> >>>> they >>> >>> >>>> gain knowledge. I don't know yet how permissions for that should be >>>>> handled." >>>>> >>>>> This is another thing that we could use the GitHub staging repository >>>>> >>>>> >>>> for. >>> >>> >>>> The staging repository could have a wiki (projects on GitHub can have >>>>> >>>>> >>>> one) >>> >>> >>>> that is editable by all, and then maybe once a month or so someone with >>>>> permissions >>>>> to edit to official wiki can sync with the new, reviewed changes (the >>>>> once-a-month >>>>> time constraint is very flexible). >>>>> >>>>> I am just trying to explain how the GitHub repository "one-way mirror" >>>>> (potentially linked >>>>> with/managed by Adopt an OpenJDK) can act as a staging ground for all >>>>> kinds of contributions to >>>>> OpenJFX. >>>>> >>>>> By the way, I am trying to cleanup the groundwork I did on getting >>>>> Appveyor builds to >>>>> run for openjfx, if indeed it is decided to setup such a staging >>>>> repository. You can >>>>> see my efforts here: https://raw.githubusercontent. >>>>> >>>>> >>>>> >>>> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057 >>> /appveyor.yml >>> >>> >>>> If the GitHub repository was setup, changes such as these to add CI >>>>> infrastructure would >>>>> never be adopted by upstream OpenJFX, but would allow for developer's >>>>> to >>>>> get good >>>>> feedback on test results for all supported platforms when they open a >>>>> >>>>> >>>> PR. >>> >>> >>>> Merging a PR >>>>> on the public GitHub repository means, in my opinion, that it is ready >>>>> >>>>> >>>> to >>> >>> >>>> be opened as >>>>> an upstream bug/feature request. Automating the process with patch >>>>> sets, >>>>> webrevs, formatting/lint >>>>> results, etc. would be the most ideal situation and I would be happy to >>>>> contribute to these >>>>> efforts. >>>>> >>>>> Regards, >>>>> >>>>> Michael Ennen >>>>> >>>>> >>>>> >>>>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker wrote: >>>>> >>>>> >>>>> >>>>>> Hello, >>>>>> >>>>>> As someone who has recently made the climb and managed to build >>>>>> OpenJFX >>>>>> with OpenJDK on Win 10 I might have some relevant input. >>>>>> >>>>>> --- Building OpenJFX --- >>>>>> >>>>>> * With the recently updated instructions on the Wiki, building OpenJFX >>>>>> >>>>>> >>>>> is >>> >>> >>>> not that hard. Having to build OpenJDK for that was a real headache >>>>>> because >>>>>> their instructions and build tools are not up to date ( >>>>>> https://bugs.openjdk.java.net/browse/JDK-8194645). >>>>>> * The above doesn't mean that the process shouldn't be made easier. >>>>>> Ideally, it would be the as easy as working on most open source >>>>>> >>>>>> >>>>> projects >>> >>> >>>> on >>>>>> Github (not advocating git over hg): clone into the IDE and start >>>>>> working; >>>>>> when a fix is ready, submit a PR. Don't know if it's technically >>>>>> >>>>>> >>>>> possible >>> >>> >>>> in this case, but it's a target. >>>>>> * The repository needs a good cleanup before contributors start >>>>>> >>>>>> >>>>> cloning ( >>> >>> >>>> bugs.openjdk.java.net/browse/JDK-8196198). >>>>>> >>>>>> --- Working on OpenJFX --- >>>>>> >>>>>> * It should be clear which tests need to run for a specific patch. >>>>>> Changes >>>>>> can be made anywhere from the documentation level to native code level >>>>>> and >>>>>> there's no reason to run the same tests for all of these. If the >>>>>> >>>>>> >>>>> process >>> >>> >>>> can be automate it's even better. >>>>>> * The Webrev tool seems archaic to me (and part of its output is >>>>>> broken >>>>>> as >>>>>> far as I could tell). An IDE can create diff patches with a couple of >>>>>> clicks. >>>>>> * The Jcheck tool seems archaic to me. It should be ported to IDE >>>>>> formatters which are to be distributed with the source. No reason to >>>>>> >>>>>> >>>>> run >>> >>> >>>> a >>>>>> tool that tells me which whitespaces I need to go back and change when >>>>>> something like Ctrl+Shift+F in an IDE finishes the job. >>>>>> >>>>>> --- Wiki --- >>>>>> >>>>>> * The Wiki could be open sourced as well (like other Wikis). I could >>>>>> definitely update a page or 2 there and so would other developers as >>>>>> >>>>>> >>>>> they >>> >>> >>>> gain knowledge. I don't know yet how permissions for that should be >>>>>> handled. >>>>>> * Code conventions should be clearly listed. >>>>>> * Separate sections with instructions should be made for: (1) cloning >>>>>> >>>>>> >>>>> and >>> >>> >>>> building, (2) modifying, (3) running tests, (4) submitting, and (5) >>>>>> reviewing. >>>>>> * Old sections should be cleaned up (I don't think Discussions is >>>>>> >>>>>> >>>>> useful >>> >>> >>>> anymore). >>>>>> >>>>>> --- Review policy --- >>>>>> >>>>>> * I have no experience with review policies or project roles so I >>>>>> can't >>>>>> help here much (maybe after a discussion starts). >>>>>> * One thing I do know is that reviewers should be extremely >>>>>> knowledgeable, >>>>>> which means that there aren't many qualified. Because of this, if it >>>>>> becomes "too" easy to contribute to OpenJFX, careful measures need to >>>>>> >>>>>> >>>>> be >>> >>> >>>> taken as to not to swamp the few reviewers with many patches (though >>>>>> >>>>>> >>>>> some >>> >>> >>>> would say this is an ideal situation). Some sort of review queue might >>>>>> help >>>>>> with organization instead of the current email system. I have no >>>>>> >>>>>> >>>>> concrete >>> >>> >>>> solution for this. >>>>>> >>>>>> - Nir >>>>>> >>>>>> >>>>>> Message: 1 >>>>>> >>>>>> >>>>>>> Date: Thu, 01 Feb 2018 15:26:24 -0800 >>>>>>> From: Kevin Rushforth >>>>>>> To: "openjfx-dev at openjdk.java.net" >>>>>>> Subject: More community participation in JavaFX >>>>>>> Message-ID: <5A73A220.7030706 at oracle.com> >>>>>>> Content-Type: text/plain; charset=windows-1252; format=flowed >>>>>>> >>>>>>> To: OpenJFX Developers >>>>>>> >>>>>>> We are looking to grow the community of contributors to the OpenJFX >>>>>>> project, especially serious contributors who will stick around long >>>>>>> enough to become reviewers, to help us keep the platform vibrant. To >>>>>>> this end we are looking at ways to encourage more participation and >>>>>>> >>>>>>> >>>>>> make >>>>>> >>>>>> >>>>>>> it easier for interested folks to contribute. >>>>>>> >>>>>>> We are specifically looking to discuss ideas around the following >>>>>>> >>>>>>> >>>>>> areas: >>>>>> >>>>>> >>>>>>> * Easing barriers to contribution (e.g., making JavaFX easier to >>>>>>> >>>>>>> >>>>>> build, >>> >>> >>>> better documentation, making it easier to test changes) >>>>>>> >>>>>>> * Code review policies >>>>>>> >>>>>>> * API / feature review policies >>>>>>> >>>>>>> * Code review tools (we currently use webrev, but that isn't set in >>>>>>> >>>>>>> >>>>>> stone) >>>>>> >>>>>> >>>>>>> To keep this thread productive, the following are explicitly out of >>>>>>> >>>>>>> >>>>>> scope: >>>>>> >>>>>> >>>>>>> * Discussion of specific features or bugs that you would like to >>>>>>> implement (or wish someone else would) >>>>>>> >>>>>>> * Discussion about platform support >>>>>>> >>>>>>> * Discussion about version control systems (e.g., hg versus git), >>>>>>> hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus >>>>>>> github), etc...at least for now. We are aware of the potential >>>>>>> >>>>>>> >>>>>> benefits >>> >>> >>>> of such changes, but we'd like to focus our efforts on >>>>>>> >>>>>>> >>>>>> higher-leverage >>> >>> >>>> things we can do in the short term. >>>>>>> >>>>>>> * Discussion about the requirement of a signed OCA to become a >>>>>>> >>>>>>> >>>>>> contributor >>>>>> >>>>>> >>>>>>> * Off-topic or tangential commentary about OpenJFX that isn't >>>>>>> >>>>>>> >>>>>> directly >>> >>> >>>> related to the topic at hand >>>>>>> >>>>>>> >>>>>>> As a starting point for discussion, here are some areas I think need >>>>>>> improvement; I'm sure there are others: >>>>>>> >>>>>>> I. Helping contributors get started >>>>>>> >>>>>>> It isn?t as easy to get started with OpenJFX as it should be. We want >>>>>>> >>>>>>> >>>>>> to >>>>>> >>>>>> >>>>>>> make it easier for potential OpenJFX contributors to get started. >>>>>>> >>>>>>> >>>>>> Here >>> >>> >>>> are some ideas that I think might help: >>>>>>> >>>>>>> * Improve the build instructions / Wiki (I made a first start, but >>>>>>> >>>>>>> >>>>>> there >>>>>> >>>>>> >>>>>>> is much more to be done) >>>>>>> >>>>>>> * Make the build itself more resilient where possible, and provide >>>>>>> better error messages, specifically when dealing with native >>>>>>> >>>>>>> >>>>>> compilers >>> >>> >>>> and libraries >>>>>>> >>>>>>> * Add an option to skip building all native code and use prebuilt >>>>>>> binaries (like we do already for media and webkit); this is tracked >>>>>>> >>>>>>> >>>>>> by >>> >>> >>>> JDK-8092279, but it hasn?t been looked at recently >>>>>>> >>>>>>> * Make it easier to build / test your local OpenJFX build using an >>>>>>> OpenJDK build (currently the only way to do this is to build OpenJDK >>>>>>> locally, after using configure to point to your just-built javafx.* >>>>>>> modules). >>>>>>> >>>>>>> * Provide step-by-step instructions for how to make a contribution, >>>>>>> including testing requirements; a lot of the pieces are there, but >>>>>>> >>>>>>> >>>>>> are >>> >>> >>>> out of date or scattered in several places. As part of this, we could >>>>>>> have a section on how to contribute docs, samples or tests, since >>>>>>> >>>>>>> >>>>>> that >>> >>> >>>> is often a good place to start. >>>>>>> >>>>>>> * Provide a sandbox environment where contributors can discuss and >>>>>>> >>>>>>> >>>>>> test >>> >>> >>>> ideas. For example, an OpenJFX mirror on github, potentially >>>>>>> >>>>>>> >>>>>> connected >>> >>> >>>> to AdoptOpenJDK. >>>>>>> >>>>>>> >>>>>>> II. Code reviews and API reviews >>>>>>> >>>>>>> Code reviews are important to maintain high-quality contributions, >>>>>>> >>>>>>> >>>>>> but >>> >>> >>>> we recognize that not every type of change needs the same level of >>>>>>> review. Without lowering our standards of quality, we want to make it >>>>>>> easier to get low-impact changes (simple bug fixes) accepted. >>>>>>> >>>>>>> There are three categories of changes, each of which might merit a >>>>>>> different review standard: >>>>>>> >>>>>>> 1. Low-impact bug fixes. These are typically isolated bug fixes with >>>>>>> little or no impact beyond fixing the bug in question; included in >>>>>>> >>>>>>> >>>>>> this >>> >>> >>>> category are test fixes (including new tests) doc fixes, and fixes to >>>>>>> sample applications (including new samples). >>>>>>> >>>>>>> 2. Higher impact bug fixes or RFEs. These include changes to the >>>>>>> implementation that potentially have a performance or behavioral >>>>>>> >>>>>>> >>>>>> impact, >>>>>> >>>>>> >>>>>>> or are otherwise broad in scope. Some larger bug fixes will fall into >>>>>>> this category, as will fixes in high-risk areas (e.g., CSS). >>>>>>> >>>>>>> 3. New features / API additions. In addition to reviewing the >>>>>>> implementation, we will need a separate approval process for the new >>>>>>> >>>>>>> >>>>>> API >>>>>> >>>>>> >>>>>>> / feature (such as the CSR, which is what we use now, or a similar >>>>>>> process). >>>>>>> >>>>>>> We take compatibility seriously, so anything that adds new API needs >>>>>>> >>>>>>> >>>>>> to >>> >>> >>>> be done with an eye towards supporting it for at least 10 years. We >>>>>>> don't want to add new public API without that level of commitment. >>>>>>> >>>>>>> >>>>>> Every >>>>>> >>>>>> >>>>>>> new feature forecloses on alternate future features. Significant >>>>>>> >>>>>>> >>>>>> effort >>> >>> >>>> must be taken to think about "if we did this, what could it interact >>>>>>> with in the future?" Also, anything with a large potential impact on >>>>>>> performance or behavioral compatibility needs to be looked at >>>>>>> >>>>>>> >>>>>> carefully. >>>>>> >>>>>> >>>>>>> Put another way, we want to encourage thinking about new features or >>>>>>> >>>>>>> >>>>>> new >>>>>> >>>>>> >>>>>>> API in terms of a design / stewardship process; to think in terms of >>>>>>> questions like "what's the right thing for JavaFX in the next 10+ >>>>>>> >>>>>>> >>>>>> years" >>>>>> >>>>>> >>>>>>> rather than "here's some code that solves my problem, please take >>>>>>> >>>>>>> >>>>>> it". >>> >>> >>>> As a stake in the ground, I might suggest the following: >>>>>>> >>>>>>> * All changes need at least one reviewer other than the person making >>>>>>> the change who can evaluate the change for correctness and >>>>>>> >>>>>>> >>>>>> consistency. >>> >>> >>>> For simple bug fixes, a single reviewer may be sufficient. Of course, >>>>>>> one of our big challenges in all this is: "how do we grow more >>>>>>> reviewers?", by which I mean "how do we facilitate getting >>>>>>> >>>>>>> >>>>>> contributors >>> >>> >>>> with enough expertise in a given area to eventually be able to >>>>>>> effectively review contributions from others?" >>>>>>> >>>>>>> * We need clear criteria for the other two categories that balance >>>>>>> process efficiency with the desire to maintain compatibility and >>>>>>> stability. API changes need to be approved by a lead. My thought is >>>>>>> >>>>>>> >>>>>> to >>> >>> >>>> combine the last two into a single category for purposes of reviewing >>>>>>> the implementation. Anything that affects public API or behavioral >>>>>>> compatibility will require CSR or similar approval, over and above >>>>>>> >>>>>>> >>>>>> the >>> >>> >>>> implementation review, which seems sufficient. >>>>>>> >>>>>>> * I recommend that we formalize the concept of reviewers, using the >>>>>>> OpenJDK Reviewer role for the Project. We might also consider if we >>>>>>> >>>>>>> >>>>>> want >>>>>> >>>>>> >>>>>>> to make any changes to the criteria used by the JDK Project for >>>>>>> >>>>>>> >>>>>> becoming >>>>>> >>>>>> >>>>>>> an OpenJFX Project Author, Committer, and Reviewer. The OpenJDK >>>>>>> >>>>>>> >>>>>> bylaws >>> >>> >>>> allow projects a fair degree of latitude to define these criteria, so >>>>>>> >>>>>>> >>>>>> we >>>>>> >>>>>> >>>>>>> might consider making some modifications. For example, we might make >>>>>>> >>>>>>> >>>>>> it >>> >>> >>>> somewhat easier for a Contributor to become an Author, or for a >>>>>>> Committer to become a Reviewer. I have some thoughts on this, but >>>>>>> >>>>>>> >>>>>> want >>> >>> >>>> to hear from others first. >>>>>>> >>>>>>> >>>>>>> I look forward to feedback on this proposal, and hope it will spark a >>>>>>> productive discussion. >>>>>>> >>>>>>> -- Kevin Rushforth, OpenJFX Project Lead >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> From sverre.moe at gmail.com Tue Feb 6 22:55:05 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Tue, 6 Feb 2018 23:55:05 +0100 Subject: More community participation in JavaFX Message-ID: >> 2018-02-06 14:29 GMT+01:00 dalibor topic : >>> >>> >>> >>> On 02.02.2018 00:26, Kevin Rushforth wrote: >>>> >>>> >>>> We are specifically looking to discuss ideas around the following areas: >>>> >>>> * Easing barriers to contribution (e.g., making JavaFX easier to build, >>>> better documentation, making it easier to test changes) >>> >>> >>> >>> I'd suggest explicitly asking for feedback from the maintainers of >>> downstream builds, such as >>> >>> https://www.archlinux.org/packages/extra/x86_64/java-openjfx/ >>> https://packages.debian.org/source/sid/openjfx >>> https://admin.fedoraproject.org/pkgdb/package/rpms/openjfx/ >>> https://www.freshports.org/java/openjfx8-devel >>> >>> In the case of the JDK, downstream builders of OpenJDK tend to provide >>> very >>> useful first hand feedback of barriers to building & contribution, and >>> often >>> end up becoming regular contributors themselves, due to the hard, >>> fundamental nature of (build) problems one needs to resolve to be able to >>> provide a working build for one's own operating system. >>> >>> cheers, >>> dalibor topic >> >> >> I wanted to see OpenSUSE among those, but sadly there is no official >> maintainers for OpenJFX there like there are for OpenJDK. >> https://build.opensuse.org/package/show/openSUSE%3AFactory/java-9-openjdk >> >> There is however several users who has built OpenJFX for OpenSUSE: >> https://software.opensuse.org/package/java-1_8_0-openjfx >> >> Sadly though none have tried or provided java-9-openjfx builds at SUSE >> OBS. Perhaps making JavaFX easier to build and provide better >> documentation could remedy that shortcoming. >> I was thinking of trying to build java-9-openjfx on OpenSUSE and SLES. >> If successful perhaps it could be picked up by official SUSE >> maintainers. >> >> /Sverre >> > > 2018-02-06 23:38 GMT+01:00 dalibor topic : > Yeah, there was a bug in the SUSE tracker for it. See > https://bugzilla.opensuse.org/show_bug.cgi?id=991307 for details. ;) > > cheers, > dalibor topic > > Reading the comments there seems it is not an easy feat to build OpenJFX. Also there are some mention of SUSE does not build OpenJDK, but IcedTea which OpenJFX will not build with. Perhaps the solution is to build the "correct" OpenJDK on SUSE, then OpenJFX. Building both OpenJDK and OpenJFX should be so easy that IceadTea no longer would be necessary. /Sverre From sdesofi at icloud.com Wed Feb 7 00:24:43 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Wed, 07 Feb 2018 00:24:43 +0000 (GMT) Subject: future content of OpenJFX Message-ID: <09a2b76c-c11b-474e-b4d9-a3bf36386424@me.com> +1 This makes sense. ? ?Having a list of who might be willing to contribute and in what areas they are willing to contribute dictates where we can go. ? ?As Rumsfeld once said "You go to war with the army have, not the one you want". Steve Sent from iCloud On Feb 06, 2018, at 06:41 AM, John-Val Rose wrote: Maybe Kevin could request that anyone who is seriously both willing and capable to contribute to OpenJFX email him privately so that the list doesn?t get to ?see? anyone who wants to fly under the radar. Kevin could then post the approximate number of resources actually available. I realise of course that some people may not wish to even let Kevin know of their interest and availability initially but at least we would have a ballpark figure as to the size of the ?talent pool?. I think we need to have some handle on this number before any significant set-up work is undertaken (just in case the number is only 2 or 3 for example instead of 20 or so). On 6 Feb 2018, at 22:12, Stephen Desofi wrote: A poll would definitely be useful because we may find ourselves another subset. The subset of people who even want to go ?off road? to begin with. Most people only consider going places where the road already leads?and that might be about 99%. Sent from my iPhone On Feb 5, 2018, at 11:14 PM, John-Val Rose wrote: I think there?s a small matter that is being overlooked here. The size of the ?talent pool?. I?m just pulling numbers out of thin air here but first I?m guessing that the vast majority of JavaFX users do *not* read this list. Then, out of those who do, only some *care* enough to contribute. Out of those, only some are *competent* enough to contribute. And then, out of that much smaller set, only an even smaller subset are in a situation that *permits* them to contribute, either because they have well-paid jobs and a bit of spare time or they really need a feature added for their own use. Given that I don?t know what the ?starting? number is (the total number of JavaFX users) and neither do I know what fraction to apply to each smaller subset, the end result (the talent pool) is potentially only a handful of people. I?m simply mentioning this because in every discussion we have here regarding innovation, community participation or plans for new features, it looks like the same group of people get involved - and it?s not exactly a ?crowd?. Does this mean that we don?t have a ?critical mass? or is it possible that there are lots and lots of ?observers? or ?lurkers? out there just waiting until all the hard work of setting-up the physical and formal infrastructure to enable community contribution has been finalised before they?ll put their hands up? Maybe we could take a poll to see how many members of the community would be willing AND able to contribute, knowing that they may not necessarily end up working on features they are interested in AND who are prepared for their contribution itself & the value it adds to JavaFX to be their only tangible reward? On 6 Feb 2018, at 11:23, Stephen Desofi wrote: Hi Johan, I read the article you linked to (http://www.tomitribe.com/blog/2013/11/feed-the-fish/) and it raises some very good points indeed. I also spent a little time thinking over your list of interests: * more alignment with mobile * a clean and lean low-level rendering pipeline API that would allow easier plugability with upcoming low-level rendering systems * extensions for Chart API Those would be high on my list as well, but there is something else I'd like to throw into the equation. If somebody can contribute money to fund the development of their wishlist, fine, that's the easy part, but asking people to contribute time is a bit more complicated. For example, I may want "more alignment with mobile", but I may be better qualified to contribute "extensions for the Chart API" even though that isn't my primary motivator. Often the reason we want something is because we haven't the skills to do it ourself, but we have skills to do other things. How can situations such as this be factored into the equation? It seems like we need a way to "trade". Steve Sent from iCloud On Feb 05, 2018, at 12:07 PM, Johan Vos wrote: In order to separate the "What" from the "How" (discussed in another thread), I would like to start a discussion about what people think should be considered for future JavaFX work. I'd like to start with what I think is an important note on the context. If I want feature X in JavaFX, I ask myself two questions: 1. Do I want to contribute time and do it (at least for a large part) myself? 2. Do I want to spend money on it? If that sounds too economic or commercial, I recommend reading the excellent blog entry by David Blevins about funding Java EE development (more than 4 years old and still very relevant): http://www.tomitribe.com/blog/2013/11/feed-the-fish/ Actually, this is a model we've been using at Gluon for a number of customers. When people ask us about a specific feature, we ask if they are willing to pay us for the development, AND if they are ok with us donating it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX, JavaFXports, Gluon Charm Down, Gluon Maps,...). As a consequence, the features we are working on are all relevant to (at least a part of) the industry. Some companies doubt there is business value in JavaFX, we prove the opposite while making the Open Source community better. I think by now it should be clear to all that there is no free lunch (anymore). If your business depends on a feature being added to JavaFX, how much (time/money) are you willing to contribute? If the answer is "nothing", you can still hope that others want to do it, and in many cases that will eventually happen -- but you don't control the timeline. This principle is a bit a simplification though. In many practical cases, people want to have feature X and are willing to contribute "something" (e.g. they want to work on it in spare-time, or fund 20% of a developer) but not enough to do everything. I think in this case it's a matter of gathering enough interest in this community. Once enough developers are interested in that same feature, and agree to spend resources on it, the burden can be shared. Having a sandbox repositories with forks will make this easier. Areas that I personally want to see on the roadmap: * more alignment with mobile * a clean and lean low-level rendering pipeline API that would allow easier plugability with upcoming low-level rendering systems * extensions for Chart API - Johan From kevin.rushforth at oracle.com Wed Feb 7 02:16:40 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 07 Feb 2018 07:46:40 +0530 Subject: More community participation in JavaFX In-Reply-To: References: <5A786D32.6050600@oracle.com> Message-ID: <5A7A6188.2090608@oracle.com> I would recommend against having a separate issue tracker or mailing list associated with the sandbox. That will create more confusion than any benefit you might have. -- Kevin Nir Lisker wrote: > Another thing to be careful about with the sandbox/staging idea is the > confusion that will arise with duplication. There will be 2 issue > trackers (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, > and maybe 2 discussion lists. For those "in the know" this will be a > simple matter, but for a potential contributor this can be a > gamebreaker if not handled appropriately. > > Dalibor Topic's suggestion of contacting other mirrors can be > instrumental in solving these problems. > > - Nir > > On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth > > wrote: > > Yes, this sounds like a good step in the right direction. This > would give anyone (with a signed OCA) the ability to create their > own branch, commit changes to it, submit a PR, etc. > > I presume there will be a branch that is an exact mirror of the > jfx-dev repo on OpenJDK in addition to the development branch in > the sandbox? > > The only thing to consider is whether it should be Committers or > Reviewers that have rights to merge into the sandbox development > branch. There are pros / cons of each. I'd probably lean towards > having it be Committers, with the idea that a Committer needs to > sponsor the patch anyway and would then be able to "take it the > rest of the way". The only downside I see is that you could end up > with a few patches that get accepted into the sandbox dev branch, > but never make it to the upstream jfx-dev repo (or not without > significant change). I doubt this will be a big problem in practice. > > Either way, this could also provide a good alternative to webrev > when reviewing the final changes. > > -- Kevin > > > > Johan Vos wrote: > > Hi Michael, > > This proposal is very much in line with my thinking as well. > The problem is not that we don't have a github clone of > OpenJFX. We have a > number of them (e.g. I created > https://github.com/javafxports/jfx-dev > some > months ago). We just need a single one that is updated > constantly from > mainstream, and standardize on that. Let's call that "sandbox" > (I would be > ok with staging as well, but sandbox is imho more inviting to > people who > want to try something drastic, e.g. support for Vulkan) > > The main issue is how to get contributions, review them, and > eventually > send them upstream. > > The PR review process is extremely important. If we lower that > bar, we > loose quality. If the bar is too high, great PR's won't be > accepted > upstream as there is not enough review time to review it. > > I agree giving the current OpenJFX committers merge rights for the > "sandbox" repository makes sense. Once a public contribution > is merged by > one of those committers, that same committer can send it > upstream to the > existing OpenJFX repository. Additional checks will be > performed there, > mainly in order to make sure the overall "Feel of Java" is > preserved. To > that purpose, it would help to have a closer alignment with > the OpenJDK > community. > > We have to be aware that this will increase the workload of > the current > committers and reviewers. That is the price we pay for > standardization. > Rather than everyone creating his own forks of a UI framework > in Java, we > invest a lot in creating a single, generally agreed one. > > So in summary, I'm +1 on a 2-phase approach: "open" commits > allowed in > staging. OpenJFX committers accept PR's (if they are of good > quality) and > prepare upstream commits for OpenJFX. We hope there will be more > contributors who become committers and reviewers in the medium > term. > > - Johan > > On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen > > wrote: > > > > Those are great questions, and I think with > Kevin/Oracle/other OpenJFX devs > help we > can figure something out. > > My thinking is that the PR would be reviewed by basically > anyone who has > free time. > I think that, at first, only OpenJFX committers will be > able to merge PRs. > They would > do the final review/merge to the staging repo after it has > been reviewed by > the "wider audience" > which includes people without commit rights (people like > us). Then, as this > thing evolves, > based on the pool of people who are contributing both pull > requests and PR > reviews, > the committers will be able to grant commit privileges to > some people in > that pool. > > I can't think of any way that would make it so the changes > are as likely to > be > merged upstream as possible other than having the current > OpenJFX > committers paving the > way. Hopefully this vision is aligned with Kevin's and > hopefully these > concrete details > can be worked out. > > Regards, > Michael > > On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker > > wrote: > > > > So if a community ran GitHub is used for staging, who > will approve PRs > > > for > > > the code and the Wiki of the GitHub repo? > > On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen > > > wrote: > > > > Great points, Nir. We share the same hopes. I just > wanted to piggy-back > on the > wiki thing: > > " * The Wiki could be open sourced as well (like > other Wikis). I could > definitely update a page or 2 there and so would > other developers as > > > they > > > gain knowledge. I don't know yet how permissions > for that should be > handled." > > This is another thing that we could use the GitHub > staging repository > > > for. > > > The staging repository could have a wiki (projects > on GitHub can have > > > one) > > > that is editable by all, and then maybe once a > month or so someone with > permissions > to edit to official wiki can sync with the new, > reviewed changes (the > once-a-month > time constraint is very flexible). > > I am just trying to explain how the GitHub > repository "one-way mirror" > (potentially linked > with/managed by Adopt an OpenJDK) can act as a > staging ground for all > kinds of contributions to > OpenJFX. > > By the way, I am trying to cleanup the groundwork > I did on getting > Appveyor builds to > run for openjfx, if indeed it is decided to setup > such a staging > repository. You can > see my efforts here: https://raw.githubusercontent. > > > > com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057/appveyor.yml > > > If the GitHub repository was setup, changes such > as these to add CI > infrastructure would > never be adopted by upstream OpenJFX, but would > allow for developer's to > get good > feedback on test results for all supported > platforms when they open a > > > PR. > > > Merging a PR > on the public GitHub repository means, in my > opinion, that it is ready > > > to > > > be opened as > an upstream bug/feature request. Automating the > process with patch sets, > webrevs, formatting/lint > results, etc. would be the most ideal situation > and I would be happy to > contribute to these > efforts. > > Regards, > > Michael Ennen > > > > On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker > > wrote: > > > > Hello, > > As someone who has recently made the climb and > managed to build OpenJFX > with OpenJDK on Win 10 I might have some > relevant input. > > --- Building OpenJFX --- > > * With the recently updated instructions on > the Wiki, building OpenJFX > > > is > > > not that hard. Having to build OpenJDK for > that was a real headache > because > their instructions and build tools are not up > to date ( > https://bugs.openjdk.java.net/browse/JDK-8194645 > ). > * The above doesn't mean that the process > shouldn't be made easier. > Ideally, it would be the as easy as working on > most open source > > > projects > > > on > Github (not advocating git over hg): clone > into the IDE and start > working; > when a fix is ready, submit a PR. Don't know > if it's technically > > > possible > > > in this case, but it's a target. > * The repository needs a good cleanup before > contributors start > > > cloning ( > > > bugs.openjdk.java.net/browse/JDK-8196198 > ). > > --- Working on OpenJFX --- > > * It should be clear which tests need to run > for a specific patch. > Changes > can be made anywhere from the documentation > level to native code level > and > there's no reason to run the same tests for > all of these. If the > > > process > > > can be automate it's even better. > * The Webrev tool seems archaic to me (and > part of its output is broken > as > far as I could tell). An IDE can create diff > patches with a couple of > clicks. > * The Jcheck tool seems archaic to me. It > should be ported to IDE > formatters which are to be distributed with > the source. No reason to > > > run > > > a > tool that tells me which whitespaces I need to > go back and change when > something like Ctrl+Shift+F in an IDE finishes > the job. > > --- Wiki --- > > * The Wiki could be open sourced as well (like > other Wikis). I could > definitely update a page or 2 there and so > would other developers as > > > they > > > gain knowledge. I don't know yet how > permissions for that should be > handled. > * Code conventions should be clearly listed. > * Separate sections with instructions should > be made for: (1) cloning > > > and > > > building, (2) modifying, (3) running tests, > (4) submitting, and (5) > reviewing. > * Old sections should be cleaned up (I don't > think Discussions is > > > useful > > > anymore). > > --- Review policy --- > > * I have no experience with review policies or > project roles so I can't > help here much (maybe after a discussion starts). > * One thing I do know is that reviewers should > be extremely > knowledgeable, > which means that there aren't many qualified. > Because of this, if it > becomes "too" easy to contribute to OpenJFX, > careful measures need to > > > be > > > taken as to not to swamp the few reviewers > with many patches (though > > > some > > > would say this is an ideal situation). Some > sort of review queue might > help > with organization instead of the current email > system. I have no > > > concrete > > > solution for this. > > - Nir > > > Message: 1 > > > Date: Thu, 01 Feb 2018 15:26:24 -0800 > From: Kevin Rushforth > > > To: "openjfx-dev at openjdk.java.net > " > > > Subject: More community participation in > JavaFX > Message-ID: <5A73A220.7030706 at oracle.com > > > Content-Type: text/plain; > charset=windows-1252; format=flowed > > To: OpenJFX Developers > > We are looking to grow the community of > contributors to the OpenJFX > project, especially serious contributors > who will stick around long > enough to become reviewers, to help us > keep the platform vibrant. To > this end we are looking at ways to > encourage more participation and > > > make > > > it easier for interested folks to contribute. > > We are specifically looking to discuss > ideas around the following > > > areas: > > > * Easing barriers to contribution (e.g., > making JavaFX easier to > > > build, > > > better documentation, making it easier to > test changes) > > * Code review policies > > * API / feature review policies > > * Code review tools (we currently use > webrev, but that isn't set in > > > stone) > > > To keep this thread productive, the > following are explicitly out of > > > scope: > > > * Discussion of specific features or bugs > that you would like to > implement (or wish someone else would) > > * Discussion about platform support > > * Discussion about version control systems > (e.g., hg versus git), > hosting of the OpenJFX repos and bug > database (e.g., OpenJDK versus > github), etc...at least for now. We are > aware of the potential > > > benefits > > > of such changes, but we'd like to focus > our efforts on > > > higher-leverage > > > things we can do in the short term. > > * Discussion about the requirement of a > signed OCA to become a > > > contributor > > > * Off-topic or tangential commentary about > OpenJFX that isn't > > > directly > > > related to the topic at hand > > > As a starting point for discussion, here > are some areas I think need > improvement; I'm sure there are others: > > I. Helping contributors get started > > It isn?t as easy to get started with > OpenJFX as it should be. We want > > > to > > > make it easier for potential OpenJFX > contributors to get started. > > > Here > > > are some ideas that I think might help: > > * Improve the build instructions / Wiki (I > made a first start, but > > > there > > > is much more to be done) > > * Make the build itself more resilient > where possible, and provide > better error messages, specifically when > dealing with native > > > compilers > > > and libraries > > * Add an option to skip building all > native code and use prebuilt > binaries (like we do already for media and > webkit); this is tracked > > > by > > > JDK-8092279, but it hasn?t been looked at > recently > > * Make it easier to build / test your > local OpenJFX build using an > OpenJDK build (currently the only way to > do this is to build OpenJDK > locally, after using configure to point to > your just-built javafx.* > modules). > > * Provide step-by-step instructions for > how to make a contribution, > including testing requirements; a lot of > the pieces are there, but > > > are > > > out of date or scattered in several > places. As part of this, we could > have a section on how to contribute docs, > samples or tests, since > > > that > > > is often a good place to start. > > * Provide a sandbox environment where > contributors can discuss and > > > test > > > ideas. For example, an OpenJFX mirror on > github, potentially > > > connected > > > to AdoptOpenJDK. > > > II. Code reviews and API reviews > > Code reviews are important to maintain > high-quality contributions, > > > but > > > we recognize that not every type of change > needs the same level of > review. Without lowering our standards of > quality, we want to make it > easier to get low-impact changes (simple > bug fixes) accepted. > > There are three categories of changes, > each of which might merit a > different review standard: > > 1. Low-impact bug fixes. These are > typically isolated bug fixes with > little or no impact beyond fixing the bug > in question; included in > > > this > > > category are test fixes (including new > tests) doc fixes, and fixes to > sample applications (including new samples). > > 2. Higher impact bug fixes or RFEs. These > include changes to the > implementation that potentially have a > performance or behavioral > > > impact, > > > or are otherwise broad in scope. Some > larger bug fixes will fall into > this category, as will fixes in high-risk > areas (e.g., CSS). > > 3. New features / API additions. In > addition to reviewing the > implementation, we will need a separate > approval process for the new > > > API > > > / feature (such as the CSR, which is what > we use now, or a similar > process). > > We take compatibility seriously, so > anything that adds new API needs > > > to > > > be done with an eye towards supporting it > for at least 10 years. We > don't want to add new public API without > that level of commitment. > > > Every > > > new feature forecloses on alternate future > features. Significant > > > effort > > > must be taken to think about "if we did > this, what could it interact > with in the future?" Also, anything with a > large potential impact on > performance or behavioral compatibility > needs to be looked at > > > carefully. > > > Put another way, we want to encourage > thinking about new features or > > > new > > > API in terms of a design / stewardship > process; to think in terms of > questions like "what's the right thing for > JavaFX in the next 10+ > > > years" > > > rather than "here's some code that solves > my problem, please take > > > it". > > > As a stake in the ground, I might suggest > the following: > > * All changes need at least one reviewer > other than the person making > the change who can evaluate the change for > correctness and > > > consistency. > > > For simple bug fixes, a single reviewer > may be sufficient. Of course, > one of our big challenges in all this is: > "how do we grow more > reviewers?", by which I mean "how do we > facilitate getting > > > contributors > > > with enough expertise in a given area to > eventually be able to > effectively review contributions from others?" > > * We need clear criteria for the other two > categories that balance > process efficiency with the desire to > maintain compatibility and > stability. API changes need to be approved > by a lead. My thought is > > > to > > > combine the last two into a single > category for purposes of reviewing > the implementation. Anything that affects > public API or behavioral > compatibility will require CSR or similar > approval, over and above > > > the > > > implementation review, which seems sufficient. > > * I recommend that we formalize the > concept of reviewers, using the > OpenJDK Reviewer role for the Project. We > might also consider if we > > > want > > > to make any changes to the criteria used > by the JDK Project for > > > becoming > > > an OpenJFX Project Author, Committer, and > Reviewer. The OpenJDK > > > bylaws > > > allow projects a fair degree of latitude > to define these criteria, so > > > we > > > might consider making some modifications. > For example, we might make > > > it > > > somewhat easier for a Contributor to > become an Author, or for a > Committer to become a Reviewer. I have > some thoughts on this, but > > > want > > > to hear from others first. > > > I look forward to feedback on this > proposal, and hope it will spark a > productive discussion. > > -- Kevin Rushforth, OpenJFX Project Lead > > > > > > From kevin.rushforth at oracle.com Wed Feb 7 03:15:23 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 07 Feb 2018 08:45:23 +0530 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> <5A70C18E.30805@oracle.com> <5A71D0FF.1040004@oracle.com> <5A736F19.30503@oracle.com> <5A79AD06.8030907@oracle.com> Message-ID: <5A7A6F4B.6060302@oracle.com> Looks good. -- Kevin Nir Lisker wrote: > Attached updated webrev. > > Changed line endings. If something is still wrong you can change it. > > You were right about the missing web source folder. Project now builds > without errors. > > On Tue, Feb 6, 2018 at 3:26 PM, Kevin Rushforth > > wrote: > > It looks fine to me, although the files should be change back to > have UNIX-style line endings to minimize diffs (I can easily do > that when I push the change for you). > > As for the javafx.web failures, you likely won't get any different > results when building webkit. To fix these failures, you might > need to add the following directory: > > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/dom3/java/ > > > > -- Kevin > > > Nir Lisker wrote: >> Attached webrev for .classpath changes for all javafx.xxx >> projects under /modules (though 2 of them are not modules). >> >> Change details: >> - The files were completely rewritten for Eclipse's current >> modular support, version 4.8M5, which is pre-release. >> - Some projects also need to change module-info.java for test >> code to identify imports properly due to bugs in Eclipse. These >> changes are excluded from the Webrev. >> - Since I didn't build Webkit, the web module has extra errors >> which I couldn't address, so the fix does not guarantee that this >> module will compile even with Webkit. >> - The swt project has external org.eclipse.swt imports which >> weren't addressed. >> >> Let's call this round 1. Next rounds will be when Eclipse fixes >> some bugs and when the source repo is cleaned from unused projects. >> >> - Nir >> >> On Fri, Feb 2, 2018 at 6:52 PM, Nir Lisker > > wrote: >> >> Alright, got most of them ready. >> >> About buildSrc: >> - What is >> "rt\buildSrc\build\generated-src\antlr\com\sun\scenario\effect\compiler" >> supposed to be? It is listed as a source folder but it's empty. >> - The project lists dependencies such as >> "build/libs/swt-debug.jar", JUnit and a JRE/JDK, but doesn't >> need any of them (from Eclipse's point of view). I see the >> base module listing this project as a dependency, but it's >> not used. Where is it located in the dependency chain? >> >> On Thu, Feb 1, 2018 at 9:48 PM, Kevin Rushforth >> > > wrote: >> >> It probably makes sense to submit what you have now as a >> partially working solution. >> >> As for Eclipse making any changes, I'm not sure there is >> a spec you could point to ... we do some of the same >> magic that I'm sure other projects have had to do w.r.t >> running tests: >> >> * We have test "shims" for white-box testing that we add >> into our modules when running tests (this requires >> copying all of the class files for our modules and adding >> the shim classes on top of that) >> >> * We build the tests separately (the tests are in a >> separate source set in gradle) without a module-info so >> that they run in the unnamed module. This allows them to >> access JUnit, etc., as well as any public package of any >> module in the system. As such we need to explicitly list >> any internal packages that they use from the module they >> are testing. These are listed in src/test/addExports >> >> >> -- Kevin >> >> >> Nir Lisker wrote: >>> Looks like I understood the problem. Eclipse does not >>> support (yet) multiple modules per project. Do you know >>> any specifications I can point them to to fix this >>> properly? >>> >>> The current workaround would be to add 'requires' for >>> all the modules which are used in tests as well. This >>> change is local and would be excluded from webrevs. >>> >>> At this point I can either submit the partially fixed >>> Eclipse files, which work with main code fully and with >>> test code only if the above fix is used; or wait until >>> Eclipse sorts it out. >>> >>> On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth >>> >> > wrote: >>> >>> >>> >>> Nir Lisker wrote: >>>> >>>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>>> rt/modules/javafx.base/src/main/java/ >>>> >>>> >>>> Why not rely on source first? >>> >>> Yes, that might work...you could try switching the >>> order. >>> >>> >>>> >>>> Another question as I move along: there are imports >>>> from java.util.logging in base module, but the >>>> module-info doesn't require java.logging. How do I >>>> give access to these imports? >>> >>> The only references to java.util.logging are in the >>> javafx.base unit tests, which are compiled and run >>> in the unnamed modules (no module-info.java for the >>> unit tests). >>> >>> -- Kevin >>> >>> >>> >>>> On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth >>>> >>> > wrote: >>>> >>>> Oh, I see. You are pointing to the exploded >>>> modules for the JDK in build/XXXXX/jdk rather >>>> than the JDK image in build/XXXXX/images/jdk. >>>> >>>> Yes, I think it would be preferable to both >>>> reverse the order and also add in the location >>>> of the built class files. So the following >>>> order seems best: >>>> >>>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>>> rt/modules/javafx.base/src/main/java/ >>>> jdk/modules/javafx.base >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Nir Lisker wrote: >>>>> This is what I mean: In the >>>>> type /base/src/test/java/test/com/sun/javafx/collections/ListListenerHelperTest.java >>>>> there are these imports: >>>>> >>>>> import test.javafx.collections.MockListObserver; >>>>> import java.util.BitSet; >>>>> import javafx.beans.Observable; >>>>> >>>>> The first one is the one in >>>>> FX: rt\modules\javafx.base\src\test\java\test\javafx\collections\MockListObserver.java >>>>> The second one is in the referenced JDK which >>>>> was built with >>>>> FX: jdk\modules\java.base\java\util\BitSet.class >>>>> The third one exists in both: >>>>> - in JFX it's in: >>>>> rt\modules\javafx.base\src\main\java\javafx\beans\Observable.java >>>>> - in the JDK it's >>>>> in: jdk\modules\javafx.base\javafx\beans\Observable.class >>>>> >>>>> Does the question make sense now? >>>>> >>>>> On Tue, Jan 30, 2018 at 5:04 AM, Kevin >>>>> Rushforth >>>> > wrote: >>>>> >>>>> >>>>>> one in >>>>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>>>> or the one in >>>>>> "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? >>>>> >>>>> Not sure I get what you mean. There isn't >>>>> a jdk/modules/ directory created by the >>>>> build. Perhaps this is an Eclipse >>>>> construct that it uses to indicate the >>>>> modules that are in the JDK that you are >>>>> using? The FX build puts the class files in: >>>>> >>>>> rt/build/modular_sdk/modules/javafx.base/... >>>>> >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Nir Lisker wrote: >>>>>> Another question: do imports of javafx.* >>>>>> packages point to the javafx source or to >>>>>> the jdk compilation? >>>>>> >>>>>> For example, in the base module, the type >>>>>> test.javafx.beans.InvalidationListenerMock >>>>>> imports javafx.beans.InvalidationListener >>>>>> (twice, by the way, along with >>>>>> Observable). Should the imported class be >>>>>> the one in >>>>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>>>>> or the one in >>>>>> "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? >>>>>> >>>>>> Currently, the way it is in the Eclipse >>>>>> files is that the jdk .class files are >>>>>> imported first[1], but it seemed odd to >>>>>> me - if I work on 2 files which depend on >>>>>> each other they should see the changes in >>>>>> each other at once. >>>>>> >>>>>> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d127c6ed5/modules/javafx.base/.classpath >>>>>> >>>>>> ("JRE_CONTAINER" is before "src/main/java"), >>>>>> >>>>>> - Nir >>>>>> >>>>>> On Fri, Jan 26, 2018 at 9:20 PM, Kevin >>>>>> Rushforth >>>>> > wrote: >>>>>> >>>>>> inline >>>>>> >>>>>> Nir Lisker wrote: >>>>>>> Alright, cleaned that part. >>>>>>> fxpackager build fails with an >>>>>>> internal NPE in Eclipse, so I'm >>>>>>> going to leave that alone and all of >>>>>>> the projects that depends on it. >>>>>>> >>>>>>> Now that projects can be built there >>>>>>> are errors in deeper levels: >>>>>>> >>>>>>> 1. All org.junit imports cannot be >>>>>>> resolved. This causes tons of errors >>>>>>> in various test folders obviously. >>>>>>> All the .classpath files use >>>>>>> >>>>>>> >>>>>> path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/> >>>>>>> >>>>>>> which is a jar distributed with >>>>>>> Eclipse (in the plugins folder) with >>>>>>> version 4.12.0. Is this really where >>>>>>> the imports are supposed to come >>>>>>> from? How does it work in Netbeans >>>>>>> or IntelliJ? >>>>>> >>>>>> For NetBeans we use their internal >>>>>> version of JUnit. I don't know about >>>>>> IntelliJ (maybe someone else on the >>>>>> list can answer that). >>>>>> >>>>>>> 2. In the 'base' module, in >>>>>>> "/src/main/java-jfr/com/sun/javafx/logging" >>>>>>> there are imports of >>>>>>> com.oracle.jrockit.jfr that can't be >>>>>>> resolved. Where are these located? >>>>>> >>>>>> These classes used to be part of the >>>>>> JFR commercial feature in the Oracle >>>>>> JDK. The java-jfr sources are >>>>>> obsolete and no longer built (and no >>>>>> longer buildable), so you can safely >>>>>> remove it from your IDE files. I also >>>>>> still see references to it in the >>>>>> netbeans/base project. I will file a >>>>>> bug to remove this obsolete code and >>>>>> fix the NetBeans references at the >>>>>> same time. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>>> On Thu, Jan 25, 2018 at 5:24 PM, >>>>>>> Kevin Rushforth >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Ah, I see. Then yes, just >>>>>>> removing the old ones is fine. >>>>>>> >>>>>>> As for the larger question, >>>>>>> unless there are dependencies on >>>>>>> apps, you can assume that the >>>>>>> only ones you care about are the >>>>>>> ones created by "gradle sdk". >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Nir Lisker wrote: >>>>>>>> So this is why I was asking >>>>>>>> about the optional stuff: >>>>>>>> 'graphics' module has BOTH >>>>>>>> >>>>>>>> build/resources/jsl-decora >>>>>>>> build/resources/jsl-prism >>>>>>>> >>>>>>>> and >>>>>>>> >>>>>>>> build/gensrc/jsl-decora >>>>>>>> build/gensrc/jsl-prism >>>>>>>> >>>>>>>> That led me to think that when >>>>>>>> the new dependencies were added >>>>>>>> the old ones weren't removed. >>>>>>>> Those that weren't optional >>>>>>>> (like the /resources ones, >>>>>>>> which I removed) were easy to >>>>>>>> catch and we could have >>>>>>>> finished here. Those that are >>>>>>>> optional are not causing >>>>>>>> trouble even when missing >>>>>>>> because they are optional. >>>>>>>> >>>>>>>> gradle sdk does not create the >>>>>>>> ones which are marked optional >>>>>>>> that Iv'e surveyed, but I don't >>>>>>>> know if that's the only way >>>>>>>> they can be created. If I >>>>>>>> compare solely with gradle sdk >>>>>>>> then I can just remove whatever >>>>>>>> is missing on grounds that it's >>>>>>>> left over. >>>>>>>> >>>>>>>> - Nir >>>>>>>> >>>>>>>> On Thu, Jan 25, 2018 at 4:06 >>>>>>>> PM, Kevin Rushforth >>>>>>>> >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> One more thing about the >>>>>>>> specific path you mentioned >>>>>>>> as not being there. >>>>>>>> >>>>>>>> >>>>>>> exported="true" >>>>>>>> path="build/resources/jsl-decora"/> >>>>>>>> >>>>>>> exported="true" >>>>>>>> path="build/resources/jsl-prism"/> >>>>>>>> >>>>>>>> These are still being >>>>>>>> created by 'gradle sdk', >>>>>>>> but the path is wrong (the >>>>>>>> files moved in JDK 9) and >>>>>>>> should be: >>>>>>>> >>>>>>>> build/gensrc/jsl-decora >>>>>>>> build/gensrc/jsl-prism >>>>>>>> >>>>>>>> You might want to take that >>>>>>>> into account. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Kevin Rushforth wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Nir Lisker wrote: >>>>>>>> >>>>>>>> Iv'e removed all >>>>>>>> the classpath >>>>>>>> dependencies that >>>>>>>> were causing >>>>>>>> errors. I don't >>>>>>>> mind sorting out >>>>>>>> the rest of the >>>>>>>> files while at it, >>>>>>>> though for that >>>>>>>> there are a few >>>>>>>> things I'm not sure >>>>>>>> about: >>>>>>>> >>>>>>>> 1. Some >>>>>>>> dependencies are >>>>>>>> marked as optional >>>>>>>> and as such they >>>>>>>> don't cause errors, >>>>>>>> but they are still >>>>>>>> missing. Is it safe >>>>>>>> to remove them or >>>>>>>> is it possible that >>>>>>>> they will be >>>>>>>> created as some point? >>>>>>>> >>>>>>>> >>>>>>>> Some of them might be >>>>>>>> created...not sure >>>>>>>> without checking. I >>>>>>>> recommend running >>>>>>>> "gradle sdk" and then >>>>>>>> seeing if the >>>>>>>> dependencies are there. >>>>>>>> >>>>>>>> Examples are the >>>>>>>> 'base' module with >>>>>>>> "src/test/resources" >>>>>>>> and >>>>>>>> "src/main/resources" >>>>>>>> optional >>>>>>>> dependencies, and >>>>>>>> 'controls' module >>>>>>>> has the optional >>>>>>>> dependency >>>>>>>> "src/main/resources" >>>>>>>> commented out. >>>>>>>> >>>>>>>> >>>>>>>> I see. You might as >>>>>>>> well leave them, but it >>>>>>>> probably doesn't matter. >>>>>>>> >>>>>>>> 2. Can I assume >>>>>>>> that all other >>>>>>>> dependencies are >>>>>>>> really needed? >>>>>>>> (Eclipse won't >>>>>>>> complain about >>>>>>>> unused ones as far >>>>>>>> as I know.) >>>>>>>> >>>>>>>> >>>>>>>> That seems best. >>>>>>>> >>>>>>>> 3. What are the >>>>>>>> formatting >>>>>>>> standards for XML >>>>>>>> (indentation, line >>>>>>>> length...)? From a >>>>>>>> quick look I see >>>>>>>> different styles in >>>>>>>> different files. >>>>>>>> >>>>>>>> >>>>>>>> For IDE files, we don't >>>>>>>> worry about formatting. >>>>>>>> In many cases they are >>>>>>>> auto-generated anyway. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> - Nir >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > From tbee at tbee.org Wed Feb 7 07:05:44 2018 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 7 Feb 2018 08:05:44 +0100 Subject: More community participation in JavaFX In-Reply-To: <5A7A6188.2090608@oracle.com> References: <5A786D32.6050600@oracle.com> <5A7A6188.2090608@oracle.com> Message-ID: <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> Many years ago I had a discussion with Jonathan Giles about if the things that were being made in JFXtras would eventually become part of the JavaFX core. In the end I decided that, for me personally, I could do the things I wanted to perfectly in a separate project. The rigid structure that Java(FX) has to adhere to, would be a big downside. What I want to say with that is that all the external projects are also contributions to JavaFX. It does not matter whether for example a control is part of the core distribution or of a side project; it is just another module users can add to the mix. So reflecting back I still stand by that choice. But having a few more people in the project (just like in JavaFX ;-) ) would be nice, but OTOH it forces me to deal with (and learn about) annoying stuff like Gradle build scripts and Java 9 migration. But because of that progress is not as fast as I would like it to be. Could it be that there is a decline in people willing to work for open source projects? Or is it just that this tech, JavaFX, is no longer appealing? Tom On 7-2-2018 03:16, Kevin Rushforth wrote: > I would recommend against having a separate issue tracker or mailing list associated with the sandbox. That will create more confusion than any benefit you might have. > > -- Kevin > > > Nir Lisker wrote: >> Another thing to be careful about with the sandbox/staging idea is the confusion that will arise with duplication. There will be 2 issue trackers (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and maybe 2 discussion lists. For those "in the know" this will be a simple matter, but for a potential contributor this can be a gamebreaker if not handled appropriately. >> >> Dalibor Topic's suggestion of contacting other mirrors can be instrumental in solving these problems. >> >> - Nir >> >> On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth > wrote: >> >> ??? Yes, this sounds like a good step in the right direction. This >> ??? would give anyone (with a signed OCA) the ability to create their >> ??? own branch, commit changes to it, submit a PR, etc. >> >> ??? I presume there will be a branch that is an exact mirror of the >> ??? jfx-dev repo on OpenJDK in addition to the development branch in >> ??? the sandbox? >> >> ??? The only thing to consider is whether it should be Committers or >> ??? Reviewers that have rights to merge into the sandbox development >> ??? branch. There are pros / cons of each. I'd probably lean towards >> ??? having it be Committers, with the idea that a Committer needs to >> ??? sponsor the patch anyway and would then be able to "take it the >> ??? rest of the way". The only downside I see is that you could end up >> ??? with a few patches that get accepted into the sandbox dev branch, >> ??? but never make it to the upstream jfx-dev repo (or not without >> ??? significant change). I doubt this will be a big problem in practice. >> >> ??? Either way, this could also provide a good alternative to webrev >> ??? when reviewing the final changes. >> >> ??? -- Kevin >> >> >> >> ??? Johan Vos wrote: >> >> ??????? Hi Michael, >> >> ??????? This proposal is very much in line with my thinking as well. >> ??????? The problem is not that we don't have a github clone of >> ??????? OpenJFX. We have a >> ??????? number of them (e.g. I created >> ??????? https://github.com/javafxports/jfx-dev >> ??????? some >> ??????? months ago). We just need a single one that is updated >> ??????? constantly from >> ??????? mainstream, and standardize on that. Let's call that "sandbox" >> ??????? (I would be >> ??????? ok with staging as well, but sandbox is imho more inviting to >> ??????? people who >> ??????? want to try something drastic, e.g. support for Vulkan) >> >> ??????? The main issue is how to get contributions, review them, and >> ??????? eventually >> ??????? send them upstream. >> >> ??????? The PR review process is extremely important. If we lower that >> ??????? bar, we >> ??????? loose quality. If the bar is too high, great PR's won't be >> ??????? accepted >> ??????? upstream as there is not enough review time to review it. >> >> ??????? I agree giving the current OpenJFX committers merge rights for the >> ??????? "sandbox" repository makes sense. Once a public contribution >> ??????? is merged by >> ??????? one of those committers, that same committer can send it >> ??????? upstream to the >> ??????? existing OpenJFX repository. Additional checks will be >> ??????? performed there, >> ??????? mainly in order to make sure the overall "Feel of Java" is >> ??????? preserved. To >> ??????? that purpose, it would help to have a closer alignment with >> ??????? the OpenJDK >> ??????? community. >> >> ??????? We have to be aware that this will increase the workload of >> ??????? the current >> ??????? committers and reviewers. That is the price we pay for >> ??????? standardization. >> ??????? Rather than everyone creating his own forks of a UI framework >> ??????? in Java, we >> ??????? invest a lot in creating a single, generally agreed one. >> >> ??????? So in summary, I'm +1 on a 2-phase approach: "open" commits >> ??????? allowed in >> ??????? staging. OpenJFX committers accept PR's (if they are of good >> ??????? quality) and >> ??????? prepare upstream commits for OpenJFX. We hope there will be more >> ??????? contributors who become committers and reviewers in the medium >> ??????? term. >> >> ??????? - Johan >> >> ??????? On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen >> ??????? > wrote: >> >> >> ??????????? Those are great questions, and I think with >> ??????????? Kevin/Oracle/other OpenJFX devs >> ??????????? help we >> ??????????? can figure something out. >> >> ??????????? My thinking is that the PR would be reviewed by basically >> ??????????? anyone who has >> ??????????? free time. >> ??????????? I think that, at first, only OpenJFX committers will be >> ??????????? able to merge PRs. >> ??????????? They would >> ??????????? do the final review/merge to the staging repo after it has >> ??????????? been reviewed by >> ??????????? the "wider audience" >> ??????????? which includes people without commit rights (people like >> ??????????? us). Then, as this >> ??????????? thing evolves, >> ??????????? based on the pool of people who are contributing both pull >> ??????????? requests and PR >> ??????????? reviews, >> ??????????? the committers will be able to grant commit privileges to >> ??????????? some people in >> ??????????? that pool. >> >> ??????????? I can't think of any way that would make it so the changes >> ??????????? are as likely to >> ??????????? be >> ??????????? merged upstream as possible other than having the current >> ??????????? OpenJFX >> ??????????? committers paving the >> ??????????? way. Hopefully this vision is aligned with Kevin's and >> ??????????? hopefully these >> ??????????? concrete details >> ??????????? can be worked out. >> >> ??????????? Regards, >> ??????????? Michael >> >> ??????????? On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker >> ??????????? > wrote: >> >> >> ??????????????? So if a community ran GitHub is used for staging, who >> ??????????????? will approve PRs >> >> ??????????? for >> >> ??????????????? the code and the Wiki of the GitHub repo? >> >> ??????????????? On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen >> ??????????????? > >> ??????????????? wrote: >> >> >> ??????????????????? Great points, Nir. We share the same hopes. I just >> ??????????????????? wanted to piggy-back >> ??????????????????? on the >> ??????????????????? wiki thing: >> >> ??????????????????? " * The Wiki could be open sourced as well (like >> ??????????????????? other Wikis). I could >> ??????????????????? definitely update a page or 2 there and so would >> ??????????????????? other developers as >> >> ??????????? they >> >> ??????????????????? gain knowledge. I don't know yet how permissions >> ??????????????????? for that should be >> ??????????????????? handled." >> >> ??????????????????? This is another thing that we could use the GitHub >> ??????????????????? staging repository >> >> ??????????? for. >> >> ??????????????????? The staging repository could have a wiki (projects >> ??????????????????? on GitHub can have >> >> ??????????? one) >> >> ??????????????????? that is editable by all, and then maybe once a >> ??????????????????? month or so someone with >> ??????????????????? permissions >> ??????????????????? to edit to official wiki can sync with the new, >> ??????????????????? reviewed changes (the >> ??????????????????? once-a-month >> ??????????????????? time constraint is very flexible). >> >> ??????????????????? I am just trying to explain how the GitHub >> ??????????????????? repository "one-way mirror" >> ??????????????????? (potentially linked >> ??????????????????? with/managed by Adopt an OpenJDK) can act as a >> ??????????????????? staging ground for all >> ??????????????????? kinds of contributions to >> ??????????????????? OpenJFX. >> >> ??????????????????? By the way, I am trying to cleanup the groundwork >> ??????????????????? I did on getting >> ??????????????????? Appveyor builds to >> ??????????????????? run for openjfx, if indeed it is decided to setup >> ??????????????????? such a staging >> ??????????????????? repository. You can >> ??????????????????? see my efforts here: https://raw.githubusercontent. >> >> >> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057/appveyor.yml >> >> ??????????????????? If the GitHub repository was setup, changes such >> ??????????????????? as these to add CI >> ??????????????????? infrastructure would >> ??????????????????? never be adopted by upstream OpenJFX, but would >> ??????????????????? allow for developer's to >> ??????????????????? get good >> ??????????????????? feedback on test results for all supported >> ??????????????????? platforms when they open a >> >> ??????????? PR. >> >> ??????????????????? Merging a PR >> ??????????????????? on the public GitHub repository means, in my >> ??????????????????? opinion, that it is ready >> >> ??????????? to >> >> ??????????????????? be opened as >> ??????????????????? an upstream bug/feature request. Automating the >> ??????????????????? process with patch sets, >> ??????????????????? webrevs, formatting/lint >> ??????????????????? results, etc. would be the most ideal situation >> ??????????????????? and I would be happy to >> ??????????????????? contribute to these >> ??????????????????? efforts. >> >> ??????????????????? Regards, >> >> ??????????????????? Michael Ennen >> >> >> >> ??????????????????? On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker >> ??????????????????? > wrote: >> >> >> ???????????????????????? Hello, >> >> ??????????????????????? As someone who has recently made the climb and >> ??????????????????????? managed to build OpenJFX >> ??????????????????????? with OpenJDK on Win 10 I might have some >> ??????????????????????? relevant input. >> >> ??????????????????????? --- Building OpenJFX --- >> >> ??????????????????????? * With the recently updated instructions on >> ??????????????????????? the Wiki, building OpenJFX >> >> ??????????? is >> >> ??????????????????????? not that hard. Having to build OpenJDK for >> ??????????????????????? that was a real headache >> ??????????????????????? because >> ??????????????????????? their instructions and build tools are not up >> ??????????????????????? to date ( >> https://bugs.openjdk.java.net/browse/JDK-8194645 >> ). >> ??????????????????????? * The above doesn't mean that the process >> ??????????????????????? shouldn't be made easier. >> ??????????????????????? Ideally, it would be the as easy as working on >> ??????????????????????? most open source >> >> ??????????? projects >> >> ??????????????????????? on >> ??????????????????????? Github (not advocating git over hg): clone >> ??????????????????????? into the IDE and start >> ??????????????????????? working; >> ??????????????????????? when a fix is ready, submit a PR. Don't know >> ??????????????????????? if it's technically >> >> ??????????? possible >> >> ??????????????????????? in this case, but it's a target. >> ??????????????????????? * The repository needs a good cleanup before >> ??????????????????????? contributors start >> >> ??????????? cloning ( >> >> ??????????????????????? bugs.openjdk.java.net/browse/JDK-8196198 >> ). >> >> ??????????????????????? --- Working on OpenJFX --- >> >> ??????????????????????? * It should be clear which tests need to run >> ??????????????????????? for a specific patch. >> ??????????????????????? Changes >> ??????????????????????? can be made anywhere from the documentation >> ??????????????????????? level to native code level >> ??????????????????????? and >> ??????????????????????? there's no reason to run the same tests for >> ??????????????????????? all of these. If the >> >> ??????????? process >> >> ??????????????????????? can be automate it's even better. >> ??????????????????????? * The Webrev tool seems archaic to me (and >> ??????????????????????? part of its output is broken >> ??????????????????????? as >> ??????????????????????? far as I could tell). An IDE can create diff >> ??????????????????????? patches with a couple of >> ??????????????????????? clicks. >> ??????????????????????? * The Jcheck tool seems archaic to me. It >> ??????????????????????? should be ported to IDE >> ??????????????????????? formatters which are to be distributed with >> ??????????????????????? the source. No reason to >> >> ??????????? run >> >> ??????????????????????? a >> ??????????????????????? tool that tells me which whitespaces I need to >> ??????????????????????? go back and change when >> ??????????????????????? something like Ctrl+Shift+F in an IDE finishes >> ??????????????????????? the job. >> >> ??????????????????????? --- Wiki --- >> >> ??????????????????????? * The Wiki could be open sourced as well (like >> ??????????????????????? other Wikis). I could >> ??????????????????????? definitely update a page or 2 there and so >> ??????????????????????? would other developers as >> >> ??????????? they >> >> ??????????????????????? gain knowledge. I don't know yet how >> ??????????????????????? permissions for that should be >> ??????????????????????? handled. >> ??????????????????????? * Code conventions should be clearly listed. >> ??????????????????????? * Separate sections with instructions should >> ??????????????????????? be made for: (1) cloning >> >> ??????????? and >> >> ??????????????????????? building, (2) modifying, (3) running tests, >> ??????????????????????? (4) submitting, and (5) >> ??????????????????????? reviewing. >> ??????????????????????? * Old sections should be cleaned up (I don't >> ??????????????????????? think Discussions is >> >> ??????????? useful >> >> ??????????????????????? anymore). >> >> ??????????????????????? --- Review policy --- >> >> ??????????????????????? * I have no experience with review policies or >> ??????????????????????? project roles so I can't >> ??????????????????????? help here much (maybe after a discussion starts). >> ??????????????????????? * One thing I do know is that reviewers should >> ??????????????????????? be extremely >> ??????????????????????? knowledgeable, >> ??????????????????????? which means that there aren't many qualified. >> ??????????????????????? Because of this, if it >> ??????????????????????? becomes "too" easy to contribute to OpenJFX, >> ??????????????????????? careful measures need to >> >> ??????????? be >> >> ??????????????????????? taken as to not to swamp the few reviewers >> ??????????????????????? with many patches (though >> >> ??????????? some >> >> ??????????????????????? would say this is an ideal situation). Some >> ??????????????????????? sort of review queue might >> ??????????????????????? help >> ??????????????????????? with organization instead of the current email >> ??????????????????????? system. I have no >> >> ??????????? concrete >> >> ??????????????????????? solution for this. >> >> ??????????????????????? - Nir >> >> >> ??????????????????????? Message: 1 >> >> ??????????????????????????? Date: Thu, 01 Feb 2018 15:26:24 -0800 >> ??????????????????????????? From: Kevin Rushforth >> ??????????????????????????? > > >> ??????????????????????????? To: "openjfx-dev at openjdk.java.net >> " >> ??????????????????????????? > > >> ??????????????????????????? Subject: More community participation in >> ??????????????????????????? JavaFX >> ??????????????????????????? Message-ID: <5A73A220.7030706 at oracle.com >> > >> ??????????????????????????? Content-Type: text/plain; >> ??????????????????????????? charset=windows-1252; format=flowed >> >> ??????????????????????????? To: OpenJFX Developers >> >> ??????????????????????????? We are looking to grow the community of >> ??????????????????????????? contributors to the OpenJFX >> ??????????????????????????? project, especially serious contributors >> ??????????????????????????? who will stick around long >> ??????????????????????????? enough to become reviewers, to help us >> ??????????????????????????? keep the platform vibrant. To >> ??????????????????????????? this end we are looking at ways to >> ??????????????????????????? encourage more participation and >> >> ??????????????????????? make >> >> ??????????????????????????? it easier for interested folks to contribute. >> >> ??????????????????????????? We are specifically looking to discuss >> ??????????????????????????? ideas around the following >> >> ??????????????????????? areas: >> >> ??????????????????????????? * Easing barriers to contribution (e.g., >> ??????????????????????????? making JavaFX easier to >> >> ??????????? build, >> >> ??????????????????????????? better documentation, making it easier to >> ??????????????????????????? test changes) >> >> ??????????????????????????? * Code review policies >> >> ??????????????????????????? * API / feature review policies >> >> ??????????????????????????? * Code review tools (we currently use >> ??????????????????????????? webrev, but that isn't set in >> >> ??????????????????????? stone) >> >> ??????????????????????????? To keep this thread productive, the >> ??????????????????????????? following are explicitly out of >> >> ??????????????????????? scope: >> >> ??????????????????????????? * Discussion of specific features or bugs >> ??????????????????????????? that you would like to >> ??????????????????????????? implement (or wish someone else would) >> >> ??????????????????????????? * Discussion about platform support >> >> ??????????????????????????? * Discussion about version control systems >> ??????????????????????????? (e.g., hg versus git), >> ??????????????????????????? hosting of the OpenJFX repos and bug >> ??????????????????????????? database (e.g., OpenJDK versus >> ??????????????????????????? github), etc...at least for now. We are >> ??????????????????????????? aware of the potential >> >> ??????????? benefits >> >> ??????????????????????????? of such changes, but we'd like to focus >> ??????????????????????????? our efforts on >> >> ??????????? higher-leverage >> >> ??????????????????????????? things we can do in the short term. >> >> ??????????????????????????? * Discussion about the requirement of a >> ??????????????????????????? signed OCA to become a >> >> ??????????????????????? contributor >> >> ??????????????????????????? * Off-topic or tangential commentary about >> ??????????????????????????? OpenJFX that isn't >> >> ??????????? directly >> >> ??????????????????????????? related to the topic at hand >> >> >> ??????????????????????????? As a starting point for discussion, here >> ??????????????????????????? are some areas I think need >> ??????????????????????????? improvement; I'm sure there are others: >> >> ??????????????????????????? I. Helping contributors get started >> >> ??????????????????????????? It isn?t as easy to get started with >> ??????????????????????????? OpenJFX as it should be. We want >> >> ??????????????????????? to >> >> ??????????????????????????? make it easier for potential OpenJFX >> ??????????????????????????? contributors to get started. >> >> ??????????? Here >> >> ??????????????????????????? are some ideas that I think might help: >> >> ??????????????????????????? * Improve the build instructions / Wiki (I >> ??????????????????????????? made a first start, but >> >> ??????????????????????? there >> >> ??????????????????????????? is much more to be done) >> >> ??????????????????????????? * Make the build itself more resilient >> ??????????????????????????? where possible, and provide >> ??????????????????????????? better error messages, specifically when >> ??????????????????????????? dealing with native >> >> ??????????? compilers >> >> ??????????????????????????? and libraries >> >> ??????????????????????????? * Add an option to skip building all >> ??????????????????????????? native code and use prebuilt >> ??????????????????????????? binaries (like we do already for media and >> ??????????????????????????? webkit); this is tracked >> >> ??????????? by >> >> ??????????????????????????? JDK-8092279, but it hasn?t been looked at >> ??????????????????????????? recently >> >> ??????????????????????????? * Make it easier to build / test your >> ??????????????????????????? local OpenJFX build using an >> ??????????????????????????? OpenJDK build (currently the only way to >> ??????????????????????????? do this is to build OpenJDK >> ??????????????????????????? locally, after using configure to point to >> ??????????????????????????? your just-built javafx.* >> ??????????????????????????? modules). >> >> ??????????????????????????? * Provide step-by-step instructions for >> ??????????????????????????? how to make a contribution, >> ??????????????????????????? including testing requirements; a lot of >> ??????????????????????????? the pieces are there, but >> >> ??????????? are >> >> ??????????????????????????? out of date or scattered in several >> ??????????????????????????? places. As part of this, we could >> ??????????????????????????? have a section on how to contribute docs, >> ??????????????????????????? samples or tests, since >> >> ??????????? that >> >> ??????????????????????????? is often a good place to start. >> >> ??????????????????????????? * Provide a sandbox environment where >> ??????????????????????????? contributors can discuss and >> >> ??????????? test >> >> ??????????????????????????? ideas. For example, an OpenJFX mirror on >> ??????????????????????????? github, potentially >> >> ??????????? connected >> >> ??????????????????????????? to AdoptOpenJDK. >> >> >> ??????????????????????????? II. Code reviews and API reviews >> >> ??????????????????????????? Code reviews are important to maintain >> ??????????????????????????? high-quality contributions, >> >> ??????????? but >> >> ??????????????????????????? we recognize that not every type of change >> ??????????????????????????? needs the same level of >> ??????????????????????????? review. Without lowering our standards of >> ??????????????????????????? quality, we want to make it >> ??????????????????????????? easier to get low-impact changes (simple >> ??????????????????????????? bug fixes) accepted. >> >> ??????????????????????????? There are three categories of changes, >> ??????????????????????????? each of which might merit a >> ??????????????????????????? different review standard: >> >> ??????????????????????????? 1. Low-impact bug fixes. These are >> ??????????????????????????? typically isolated bug fixes with >> ??????????????????????????? little or no impact beyond fixing the bug >> ??????????????????????????? in question; included in >> >> ??????????? this >> >> ??????????????????????????? category are test fixes (including new >> ??????????????????????????? tests) doc fixes, and fixes to >> ??????????????????????????? sample applications (including new samples). >> >> ??????????????????????????? 2. Higher impact bug fixes or RFEs. These >> ??????????????????????????? include changes to the >> ??????????????????????????? implementation that potentially have a >> ??????????????????????????? performance or behavioral >> >> ??????????????????????? impact, >> >> ??????????????????????????? or are otherwise broad in scope. Some >> ??????????????????????????? larger bug fixes will fall into >> ??????????????????????????? this category, as will fixes in high-risk >> ??????????????????????????? areas (e.g., CSS). >> >> ??????????????????????????? 3. New features / API additions. In >> ??????????????????????????? addition to reviewing the >> ??????????????????????????? implementation, we will need a separate >> ??????????????????????????? approval process for the new >> >> ??????????????????????? API >> >> ??????????????????????????? / feature (such as the CSR, which is what >> ??????????????????????????? we use now, or a similar >> ??????????????????????????? process). >> >> ??????????????????????????? We take compatibility seriously, so >> ??????????????????????????? anything that adds new API needs >> >> ??????????? to >> >> ??????????????????????????? be done with an eye towards supporting it >> ??????????????????????????? for at least 10 years. We >> ??????????????????????????? don't want to add new public API without >> ??????????????????????????? that level of commitment. >> >> ??????????????????????? Every >> >> ??????????????????????????? new feature forecloses on alternate future >> ??????????????????????????? features. Significant >> >> ??????????? effort >> >> ??????????????????????????? must be taken to think about "if we did >> ??????????????????????????? this, what could it interact >> ??????????????????????????? with in the future?" Also, anything with a >> ??????????????????????????? large potential impact on >> ??????????????????????????? performance or behavioral compatibility >> ??????????????????????????? needs to be looked at >> >> ??????????????????????? carefully. >> >> ??????????????????????????? Put another way, we want to encourage >> ??????????????????????????? thinking about new features or >> >> ??????????????????????? new >> >> ??????????????????????????? API in terms of a design / stewardship >> ??????????????????????????? process; to think in terms of >> ??????????????????????????? questions like "what's the right thing for >> ??????????????????????????? JavaFX in the next 10+ >> >> ??????????????????????? years" >> >> ??????????????????????????? rather than "here's some code that solves >> ??????????????????????????? my problem, please take >> >> ??????????? it". >> >> ??????????????????????????? As a stake in the ground, I might suggest >> ??????????????????????????? the following: >> >> ??????????????????????????? * All changes need at least one reviewer >> ??????????????????????????? other than the person making >> ??????????????????????????? the change who can evaluate the change for >> ??????????????????????????? correctness and >> >> ??????????? consistency. >> >> ??????????????????????????? For simple bug fixes, a single reviewer >> ??????????????????????????? may be sufficient. Of course, >> ??????????????????????????? one of our big challenges in all this is: >> ??????????????????????????? "how do we grow more >> ??????????????????????????? reviewers?", by which I mean "how do we >> ??????????????????????????? facilitate getting >> >> ??????????? contributors >> >> ??????????????????????????? with enough expertise in a given area to >> ??????????????????????????? eventually be able to >> ??????????????????????????? effectively review contributions from others?" >> >> ??????????????????????????? * We need clear criteria for the other two >> ??????????????????????????? categories that balance >> ??????????????????????????? process efficiency with the desire to >> ??????????????????????????? maintain compatibility and >> ??????????????????????????? stability. API changes need to be approved >> ??????????????????????????? by a lead. My thought is >> >> ??????????? to >> >> ??????????????????????????? combine the last two into a single >> ??????????????????????????? category for purposes of reviewing >> ??????????????????????????? the implementation. Anything that affects >> ??????????????????????????? public API or behavioral >> ??????????????????????????? compatibility will require CSR or similar >> ??????????????????????????? approval, over and above >> >> ??????????? the >> >> ??????????????????????????? implementation review, which seems sufficient. >> >> ??????????????????????????? * I recommend that we formalize the >> ??????????????????????????? concept of reviewers, using the >> ??????????????????????????? OpenJDK Reviewer role for the Project. We >> ??????????????????????????? might also consider if we >> >> ??????????????????????? want >> >> ??????????????????????????? to make any changes to the criteria used >> ??????????????????????????? by the JDK Project for >> >> ??????????????????????? becoming >> >> ??????????????????????????? an OpenJFX Project Author, Committer, and >> ??????????????????????????? Reviewer. The OpenJDK >> >> ??????????? bylaws >> >> ??????????????????????????? allow projects a fair degree of latitude >> ??????????????????????????? to define these criteria, so >> >> ??????????????????????? we >> >> ??????????????????????????? might consider making some modifications. >> ??????????????????????????? For example, we might make >> >> ??????????? it >> >> ??????????????????????????? somewhat easier for a Contributor to >> ??????????????????????????? become an Author, or for a >> ??????????????????????????? Committer to become a Reviewer. I have >> ??????????????????????????? some thoughts on this, but >> >> ??????????? want >> >> ??????????????????????????? to hear from others first. >> >> >> ??????????????????????????? I look forward to feedback on this >> ??????????????????????????? proposal, and hope it will spark a >> ??????????????????????????? productive discussion. >> >> ??????????????????????????? -- Kevin Rushforth, OpenJFX Project Lead >> >> >> >> From jonathan at jonathangiles.net Wed Feb 7 07:16:26 2018 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Wed, 7 Feb 2018 15:16:26 +0800 Subject: More community participation in JavaFX In-Reply-To: <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> References: <5A786D32.6050600@oracle.com> <5A7A6188.2090608@oracle.com> <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> Message-ID: Obviously everyone is at ControlsFX instead ;-) Part of the drop I would suggest is simply that many of the itches people want to scratch are now scratched. Alternatively, the remaining itches are either in more complex controls (*cough* docking frameworks *cough*) or in areas beneath the controls APIs - performance, webview, etc - which are more challenging and require greater levels of dedication. However, more generally, your point is well made - contribution to JavaFX does not need to be synonymous with contribution to OpenJFX. People who find the challenges of the current OpenJFX requirements too great should be encouraged to involve themselves in projects such as JFXtras, etc. -- Jonathan On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: > Many years ago I had a discussion with Jonathan Giles about if the things > that were being made in JFXtras would eventually become part of the JavaFX > core. In the end I decided that, for me personally, I could do the things I > wanted to perfectly in a separate project. The rigid structure that > Java(FX) has to adhere to, would be a big downside. > > What I want to say with that is that all the external projects are also > contributions to JavaFX. It does not matter whether for example a control > is part of the core distribution or of a side project; it is just another > module users can add to the mix. > > So reflecting back I still stand by that choice. But having a few more > people in the project (just like in JavaFX ;-) ) would be nice, but OTOH it > forces me to deal with (and learn about) annoying stuff like Gradle build > scripts and Java 9 migration. But because of that progress is not as fast > as I would like it to be. Could it be that there is a decline in people > willing to work for open source projects? Or is it just that this tech, > JavaFX, is no longer appealing? > > Tom > > > > On 7-2-2018 03:16, Kevin Rushforth wrote: > >> I would recommend against having a separate issue tracker or mailing list >> associated with the sandbox. That will create more confusion than any >> benefit you might have. >> >> -- Kevin >> >> >> Nir Lisker wrote: >> >>> Another thing to be careful about with the sandbox/staging idea is the >>> confusion that will arise with duplication. There will be 2 issue trackers >>> (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and maybe 2 >>> discussion lists. For those "in the know" this will be a simple matter, but >>> for a potential contributor this can be a gamebreaker if not handled >>> appropriately. >>> >>> Dalibor Topic's suggestion of contacting other mirrors can be >>> instrumental in solving these problems. >>> >>> - Nir >>> >>> On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com > wrote: >>> >>> Yes, this sounds like a good step in the right direction. This >>> would give anyone (with a signed OCA) the ability to create their >>> own branch, commit changes to it, submit a PR, etc. >>> >>> I presume there will be a branch that is an exact mirror of the >>> jfx-dev repo on OpenJDK in addition to the development branch in >>> the sandbox? >>> >>> The only thing to consider is whether it should be Committers or >>> Reviewers that have rights to merge into the sandbox development >>> branch. There are pros / cons of each. I'd probably lean towards >>> having it be Committers, with the idea that a Committer needs to >>> sponsor the patch anyway and would then be able to "take it the >>> rest of the way". The only downside I see is that you could end up >>> with a few patches that get accepted into the sandbox dev branch, >>> but never make it to the upstream jfx-dev repo (or not without >>> significant change). I doubt this will be a big problem in practice. >>> >>> Either way, this could also provide a good alternative to webrev >>> when reviewing the final changes. >>> >>> -- Kevin >>> >>> >>> >>> Johan Vos wrote: >>> >>> Hi Michael, >>> >>> This proposal is very much in line with my thinking as well. >>> The problem is not that we don't have a github clone of >>> OpenJFX. We have a >>> number of them (e.g. I created >>> https://github.com/javafxports/jfx-dev >>> some >>> months ago). We just need a single one that is updated >>> constantly from >>> mainstream, and standardize on that. Let's call that "sandbox" >>> (I would be >>> ok with staging as well, but sandbox is imho more inviting to >>> people who >>> want to try something drastic, e.g. support for Vulkan) >>> >>> The main issue is how to get contributions, review them, and >>> eventually >>> send them upstream. >>> >>> The PR review process is extremely important. If we lower that >>> bar, we >>> loose quality. If the bar is too high, great PR's won't be >>> accepted >>> upstream as there is not enough review time to review it. >>> >>> I agree giving the current OpenJFX committers merge rights for >>> the >>> "sandbox" repository makes sense. Once a public contribution >>> is merged by >>> one of those committers, that same committer can send it >>> upstream to the >>> existing OpenJFX repository. Additional checks will be >>> performed there, >>> mainly in order to make sure the overall "Feel of Java" is >>> preserved. To >>> that purpose, it would help to have a closer alignment with >>> the OpenJDK >>> community. >>> >>> We have to be aware that this will increase the workload of >>> the current >>> committers and reviewers. That is the price we pay for >>> standardization. >>> Rather than everyone creating his own forks of a UI framework >>> in Java, we >>> invest a lot in creating a single, generally agreed one. >>> >>> So in summary, I'm +1 on a 2-phase approach: "open" commits >>> allowed in >>> staging. OpenJFX committers accept PR's (if they are of good >>> quality) and >>> prepare upstream commits for OpenJFX. We hope there will be more >>> contributors who become committers and reviewers in the medium >>> term. >>> >>> - Johan >>> >>> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen >>> > wrote: >>> >>> >>> Those are great questions, and I think with >>> Kevin/Oracle/other OpenJFX devs >>> help we >>> can figure something out. >>> >>> My thinking is that the PR would be reviewed by basically >>> anyone who has >>> free time. >>> I think that, at first, only OpenJFX committers will be >>> able to merge PRs. >>> They would >>> do the final review/merge to the staging repo after it has >>> been reviewed by >>> the "wider audience" >>> which includes people without commit rights (people like >>> us). Then, as this >>> thing evolves, >>> based on the pool of people who are contributing both pull >>> requests and PR >>> reviews, >>> the committers will be able to grant commit privileges to >>> some people in >>> that pool. >>> >>> I can't think of any way that would make it so the changes >>> are as likely to >>> be >>> merged upstream as possible other than having the current >>> OpenJFX >>> committers paving the >>> way. Hopefully this vision is aligned with Kevin's and >>> hopefully these >>> concrete details >>> can be worked out. >>> >>> Regards, >>> Michael >>> >>> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker >>> > wrote: >>> >>> >>> So if a community ran GitHub is used for staging, who >>> will approve PRs >>> >>> for >>> >>> the code and the Wiki of the GitHub repo? >>> >>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen >>> > >>> wrote: >>> >>> >>> Great points, Nir. We share the same hopes. I just >>> wanted to piggy-back >>> on the >>> wiki thing: >>> >>> " * The Wiki could be open sourced as well (like >>> other Wikis). I could >>> definitely update a page or 2 there and so would >>> other developers as >>> >>> they >>> >>> gain knowledge. I don't know yet how permissions >>> for that should be >>> handled." >>> >>> This is another thing that we could use the GitHub >>> staging repository >>> >>> for. >>> >>> The staging repository could have a wiki (projects >>> on GitHub can have >>> >>> one) >>> >>> that is editable by all, and then maybe once a >>> month or so someone with >>> permissions >>> to edit to official wiki can sync with the new, >>> reviewed changes (the >>> once-a-month >>> time constraint is very flexible). >>> >>> I am just trying to explain how the GitHub >>> repository "one-way mirror" >>> (potentially linked >>> with/managed by Adopt an OpenJDK) can act as a >>> staging ground for all >>> kinds of contributions to >>> OpenJFX. >>> >>> By the way, I am trying to cleanup the groundwork >>> I did on getting >>> Appveyor builds to >>> run for openjfx, if indeed it is decided to setup >>> such a staging >>> repository. You can >>> see my efforts here: https://raw.githubusercontent. >>> >>> >>> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057 >>> /appveyor.yml >>> >>> If the GitHub repository was setup, changes such >>> as these to add CI >>> infrastructure would >>> never be adopted by upstream OpenJFX, but would >>> allow for developer's to >>> get good >>> feedback on test results for all supported >>> platforms when they open a >>> >>> PR. >>> >>> Merging a PR >>> on the public GitHub repository means, in my >>> opinion, that it is ready >>> >>> to >>> >>> be opened as >>> an upstream bug/feature request. Automating the >>> process with patch sets, >>> webrevs, formatting/lint >>> results, etc. would be the most ideal situation >>> and I would be happy to >>> contribute to these >>> efforts. >>> >>> Regards, >>> >>> Michael Ennen >>> >>> >>> >>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker >>> > >>> wrote: >>> >>> >>> Hello, >>> >>> As someone who has recently made the climb and >>> managed to build OpenJFX >>> with OpenJDK on Win 10 I might have some >>> relevant input. >>> >>> --- Building OpenJFX --- >>> >>> * With the recently updated instructions on >>> the Wiki, building OpenJFX >>> >>> is >>> >>> not that hard. Having to build OpenJDK for >>> that was a real headache >>> because >>> their instructions and build tools are not up >>> to date ( >>> https://bugs.openjdk.java.net/browse/JDK-8194645 >>> ). >>> * The above doesn't mean that the process >>> shouldn't be made easier. >>> Ideally, it would be the as easy as working on >>> most open source >>> >>> projects >>> >>> on >>> Github (not advocating git over hg): clone >>> into the IDE and start >>> working; >>> when a fix is ready, submit a PR. Don't know >>> if it's technically >>> >>> possible >>> >>> in this case, but it's a target. >>> * The repository needs a good cleanup before >>> contributors start >>> >>> cloning ( >>> >>> bugs.openjdk.java.net/browse/JDK-8196198 >>> ). >>> >>> --- Working on OpenJFX --- >>> >>> * It should be clear which tests need to run >>> for a specific patch. >>> Changes >>> can be made anywhere from the documentation >>> level to native code level >>> and >>> there's no reason to run the same tests for >>> all of these. If the >>> >>> process >>> >>> can be automate it's even better. >>> * The Webrev tool seems archaic to me (and >>> part of its output is broken >>> as >>> far as I could tell). An IDE can create diff >>> patches with a couple of >>> clicks. >>> * The Jcheck tool seems archaic to me. It >>> should be ported to IDE >>> formatters which are to be distributed with >>> the source. No reason to >>> >>> run >>> >>> a >>> tool that tells me which whitespaces I need to >>> go back and change when >>> something like Ctrl+Shift+F in an IDE finishes >>> the job. >>> >>> --- Wiki --- >>> >>> * The Wiki could be open sourced as well (like >>> other Wikis). I could >>> definitely update a page or 2 there and so >>> would other developers as >>> >>> they >>> >>> gain knowledge. I don't know yet how >>> permissions for that should be >>> handled. >>> * Code conventions should be clearly listed. >>> * Separate sections with instructions should >>> be made for: (1) cloning >>> >>> and >>> >>> building, (2) modifying, (3) running tests, >>> (4) submitting, and (5) >>> reviewing. >>> * Old sections should be cleaned up (I don't >>> think Discussions is >>> >>> useful >>> >>> anymore). >>> >>> --- Review policy --- >>> >>> * I have no experience with review policies or >>> project roles so I can't >>> help here much (maybe after a discussion starts). >>> * One thing I do know is that reviewers should >>> be extremely >>> knowledgeable, >>> which means that there aren't many qualified. >>> Because of this, if it >>> becomes "too" easy to contribute to OpenJFX, >>> careful measures need to >>> >>> be >>> >>> taken as to not to swamp the few reviewers >>> with many patches (though >>> >>> some >>> >>> would say this is an ideal situation). Some >>> sort of review queue might >>> help >>> with organization instead of the current email >>> system. I have no >>> >>> concrete >>> >>> solution for this. >>> >>> - Nir >>> >>> >>> Message: 1 >>> >>> Date: Thu, 01 Feb 2018 15:26:24 -0800 >>> From: Kevin Rushforth >>> >> > >>> To: "openjfx-dev at openjdk.java.net >>> " >>> >> > >>> Subject: More community participation in >>> JavaFX >>> Message-ID: <5A73A220.7030706 at oracle.com >>> > >>> Content-Type: text/plain; >>> charset=windows-1252; format=flowed >>> >>> To: OpenJFX Developers >>> >>> We are looking to grow the community of >>> contributors to the OpenJFX >>> project, especially serious contributors >>> who will stick around long >>> enough to become reviewers, to help us >>> keep the platform vibrant. To >>> this end we are looking at ways to >>> encourage more participation and >>> >>> make >>> >>> it easier for interested folks to contribute. >>> >>> We are specifically looking to discuss >>> ideas around the following >>> >>> areas: >>> >>> * Easing barriers to contribution (e.g., >>> making JavaFX easier to >>> >>> build, >>> >>> better documentation, making it easier to >>> test changes) >>> >>> * Code review policies >>> >>> * API / feature review policies >>> >>> * Code review tools (we currently use >>> webrev, but that isn't set in >>> >>> stone) >>> >>> To keep this thread productive, the >>> following are explicitly out of >>> >>> scope: >>> >>> * Discussion of specific features or bugs >>> that you would like to >>> implement (or wish someone else would) >>> >>> * Discussion about platform support >>> >>> * Discussion about version control systems >>> (e.g., hg versus git), >>> hosting of the OpenJFX repos and bug >>> database (e.g., OpenJDK versus >>> github), etc...at least for now. We are >>> aware of the potential >>> >>> benefits >>> >>> of such changes, but we'd like to focus >>> our efforts on >>> >>> higher-leverage >>> >>> things we can do in the short term. >>> >>> * Discussion about the requirement of a >>> signed OCA to become a >>> >>> contributor >>> >>> * Off-topic or tangential commentary about >>> OpenJFX that isn't >>> >>> directly >>> >>> related to the topic at hand >>> >>> >>> As a starting point for discussion, here >>> are some areas I think need >>> improvement; I'm sure there are others: >>> >>> I. Helping contributors get started >>> >>> It isn?t as easy to get started with >>> OpenJFX as it should be. We want >>> >>> to >>> >>> make it easier for potential OpenJFX >>> contributors to get started. >>> >>> Here >>> >>> are some ideas that I think might help: >>> >>> * Improve the build instructions / Wiki (I >>> made a first start, but >>> >>> there >>> >>> is much more to be done) >>> >>> * Make the build itself more resilient >>> where possible, and provide >>> better error messages, specifically when >>> dealing with native >>> >>> compilers >>> >>> and libraries >>> >>> * Add an option to skip building all >>> native code and use prebuilt >>> binaries (like we do already for media and >>> webkit); this is tracked >>> >>> by >>> >>> JDK-8092279, but it hasn?t been looked at >>> recently >>> >>> * Make it easier to build / test your >>> local OpenJFX build using an >>> OpenJDK build (currently the only way to >>> do this is to build OpenJDK >>> locally, after using configure to point to >>> your just-built javafx.* >>> modules). >>> >>> * Provide step-by-step instructions for >>> how to make a contribution, >>> including testing requirements; a lot of >>> the pieces are there, but >>> >>> are >>> >>> out of date or scattered in several >>> places. As part of this, we could >>> have a section on how to contribute docs, >>> samples or tests, since >>> >>> that >>> >>> is often a good place to start. >>> >>> * Provide a sandbox environment where >>> contributors can discuss and >>> >>> test >>> >>> ideas. For example, an OpenJFX mirror on >>> github, potentially >>> >>> connected >>> >>> to AdoptOpenJDK. >>> >>> >>> II. Code reviews and API reviews >>> >>> Code reviews are important to maintain >>> high-quality contributions, >>> >>> but >>> >>> we recognize that not every type of change >>> needs the same level of >>> review. Without lowering our standards of >>> quality, we want to make it >>> easier to get low-impact changes (simple >>> bug fixes) accepted. >>> >>> There are three categories of changes, >>> each of which might merit a >>> different review standard: >>> >>> 1. Low-impact bug fixes. These are >>> typically isolated bug fixes with >>> little or no impact beyond fixing the bug >>> in question; included in >>> >>> this >>> >>> category are test fixes (including new >>> tests) doc fixes, and fixes to >>> sample applications (including new samples). >>> >>> 2. Higher impact bug fixes or RFEs. These >>> include changes to the >>> implementation that potentially have a >>> performance or behavioral >>> >>> impact, >>> >>> or are otherwise broad in scope. Some >>> larger bug fixes will fall into >>> this category, as will fixes in high-risk >>> areas (e.g., CSS). >>> >>> 3. New features / API additions. In >>> addition to reviewing the >>> implementation, we will need a separate >>> approval process for the new >>> >>> API >>> >>> / feature (such as the CSR, which is what >>> we use now, or a similar >>> process). >>> >>> We take compatibility seriously, so >>> anything that adds new API needs >>> >>> to >>> >>> be done with an eye towards supporting it >>> for at least 10 years. We >>> don't want to add new public API without >>> that level of commitment. >>> >>> Every >>> >>> new feature forecloses on alternate future >>> features. Significant >>> >>> effort >>> >>> must be taken to think about "if we did >>> this, what could it interact >>> with in the future?" Also, anything with a >>> large potential impact on >>> performance or behavioral compatibility >>> needs to be looked at >>> >>> carefully. >>> >>> Put another way, we want to encourage >>> thinking about new features or >>> >>> new >>> >>> API in terms of a design / stewardship >>> process; to think in terms of >>> questions like "what's the right thing for >>> JavaFX in the next 10+ >>> >>> years" >>> >>> rather than "here's some code that solves >>> my problem, please take >>> >>> it". >>> >>> As a stake in the ground, I might suggest >>> the following: >>> >>> * All changes need at least one reviewer >>> other than the person making >>> the change who can evaluate the change for >>> correctness and >>> >>> consistency. >>> >>> For simple bug fixes, a single reviewer >>> may be sufficient. Of course, >>> one of our big challenges in all this is: >>> "how do we grow more >>> reviewers?", by which I mean "how do we >>> facilitate getting >>> >>> contributors >>> >>> with enough expertise in a given area to >>> eventually be able to >>> effectively review contributions from >>> others?" >>> >>> * We need clear criteria for the other two >>> categories that balance >>> process efficiency with the desire to >>> maintain compatibility and >>> stability. API changes need to be approved >>> by a lead. My thought is >>> >>> to >>> >>> combine the last two into a single >>> category for purposes of reviewing >>> the implementation. Anything that affects >>> public API or behavioral >>> compatibility will require CSR or similar >>> approval, over and above >>> >>> the >>> >>> implementation review, which seems >>> sufficient. >>> >>> * I recommend that we formalize the >>> concept of reviewers, using the >>> OpenJDK Reviewer role for the Project. We >>> might also consider if we >>> >>> want >>> >>> to make any changes to the criteria used >>> by the JDK Project for >>> >>> becoming >>> >>> an OpenJFX Project Author, Committer, and >>> Reviewer. The OpenJDK >>> >>> bylaws >>> >>> allow projects a fair degree of latitude >>> to define these criteria, so >>> >>> we >>> >>> might consider making some modifications. >>> For example, we might make >>> >>> it >>> >>> somewhat easier for a Contributor to >>> become an Author, or for a >>> Committer to become a Reviewer. I have >>> some thoughts on this, but >>> >>> want >>> >>> to hear from others first. >>> >>> >>> I look forward to feedback on this >>> proposal, and hope it will spark a >>> productive discussion. >>> >>> -- Kevin Rushforth, OpenJFX Project Lead >>> >>> >>> >>> >>> > From johan at lodgon.com Wed Feb 7 07:24:20 2018 From: johan at lodgon.com (Johan Vos) Date: Wed, 07 Feb 2018 07:24:20 +0000 Subject: More community participation in JavaFX In-Reply-To: <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> References: <5A786D32.6050600@oracle.com> <5A7A6188.2090608@oracle.com> <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> Message-ID: Hi Tom, I think that is a very relevant question, and a good observation. The JavaFX ecosystem is very wide, and many people and companies contribute. I'm working on non-OpenJFX stuff as well like Gluon Maps etc, and that is not intended to end in the JavaFX core. That is something we absolutely have to encourage. The JavaFX core needs to stay stable, grow in maturity and so on, but I hope and expect to see more libraries (e.g. JFXtras) that provide value beyond the core. So by no means we now have to force everyone to drop his project and help with the OpenJFX core which is indeed more difficult to contribute to, for a variety of reasons. As for open-source: I can go on about that for a very long time. Basically, I think Open Source suffers from its popularity. Marketing people realised it can be a catchy slogan, and created false impressions. As a consequence, many people in the industry now want "Open Source" and they personally blame developers for bugs or things that aren't going fast enough. I'm still all in favour of Open Source, but it should be sustainable. And that is why I gave the example of Gluon, where we try to find customers that are funding "enhancements" etc and that are ok with us donating the result back to Open Source projects. - Johan Op wo 7 feb. 2018 om 08:06 schreef Tom Eugelink : > Many years ago I had a discussion with Jonathan Giles about if the things > that were being made in JFXtras would eventually become part of the JavaFX > core. In the end I decided that, for me personally, I could do the things I > wanted to perfectly in a separate project. The rigid structure that > Java(FX) has to adhere to, would be a big downside. > > What I want to say with that is that all the external projects are also > contributions to JavaFX. It does not matter whether for example a control > is part of the core distribution or of a side project; it is just another > module users can add to the mix. > > So reflecting back I still stand by that choice. But having a few more > people in the project (just like in JavaFX ;-) ) would be nice, but OTOH it > forces me to deal with (and learn about) annoying stuff like Gradle build > scripts and Java 9 migration. But because of that progress is not as fast > as I would like it to be. Could it be that there is a decline in people > willing to work for open source projects? Or is it just that this tech, > JavaFX, is no longer appealing? > > Tom > > > On 7-2-2018 03:16, Kevin Rushforth wrote: > > I would recommend against having a separate issue tracker or mailing > list associated with the sandbox. That will create more confusion than any > benefit you might have. > > > > -- Kevin > > > > > > Nir Lisker wrote: > >> Another thing to be careful about with the sandbox/staging idea is the > confusion that will arise with duplication. There will be 2 issue trackers > (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and maybe 2 > discussion lists. For those "in the know" this will be a simple matter, but > for a potential contributor this can be a gamebreaker if not handled > appropriately. > >> > >> Dalibor Topic's suggestion of contacting other mirrors can be > instrumental in solving these problems. > >> > >> - Nir > >> > >> On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth < > kevin.rushforth at oracle.com > wrote: > >> > >> Yes, this sounds like a good step in the right direction. This > >> would give anyone (with a signed OCA) the ability to create their > >> own branch, commit changes to it, submit a PR, etc. > >> > >> I presume there will be a branch that is an exact mirror of the > >> jfx-dev repo on OpenJDK in addition to the development branch in > >> the sandbox? > >> > >> The only thing to consider is whether it should be Committers or > >> Reviewers that have rights to merge into the sandbox development > >> branch. There are pros / cons of each. I'd probably lean towards > >> having it be Committers, with the idea that a Committer needs to > >> sponsor the patch anyway and would then be able to "take it the > >> rest of the way". The only downside I see is that you could end up > >> with a few patches that get accepted into the sandbox dev branch, > >> but never make it to the upstream jfx-dev repo (or not without > >> significant change). I doubt this will be a big problem in practice. > >> > >> Either way, this could also provide a good alternative to webrev > >> when reviewing the final changes. > >> > >> -- Kevin > >> > >> > >> > >> Johan Vos wrote: > >> > >> Hi Michael, > >> > >> This proposal is very much in line with my thinking as well. > >> The problem is not that we don't have a github clone of > >> OpenJFX. We have a > >> number of them (e.g. I created > >> https://github.com/javafxports/jfx-dev > >> some > >> months ago). We just need a single one that is updated > >> constantly from > >> mainstream, and standardize on that. Let's call that "sandbox" > >> (I would be > >> ok with staging as well, but sandbox is imho more inviting to > >> people who > >> want to try something drastic, e.g. support for Vulkan) > >> > >> The main issue is how to get contributions, review them, and > >> eventually > >> send them upstream. > >> > >> The PR review process is extremely important. If we lower that > >> bar, we > >> loose quality. If the bar is too high, great PR's won't be > >> accepted > >> upstream as there is not enough review time to review it. > >> > >> I agree giving the current OpenJFX committers merge rights for > the > >> "sandbox" repository makes sense. Once a public contribution > >> is merged by > >> one of those committers, that same committer can send it > >> upstream to the > >> existing OpenJFX repository. Additional checks will be > >> performed there, > >> mainly in order to make sure the overall "Feel of Java" is > >> preserved. To > >> that purpose, it would help to have a closer alignment with > >> the OpenJDK > >> community. > >> > >> We have to be aware that this will increase the workload of > >> the current > >> committers and reviewers. That is the price we pay for > >> standardization. > >> Rather than everyone creating his own forks of a UI framework > >> in Java, we > >> invest a lot in creating a single, generally agreed one. > >> > >> So in summary, I'm +1 on a 2-phase approach: "open" commits > >> allowed in > >> staging. OpenJFX committers accept PR's (if they are of good > >> quality) and > >> prepare upstream commits for OpenJFX. We hope there will be more > >> contributors who become committers and reviewers in the medium > >> term. > >> > >> - Johan > >> > >> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen > >> > wrote: > >> > >> > >> Those are great questions, and I think with > >> Kevin/Oracle/other OpenJFX devs > >> help we > >> can figure something out. > >> > >> My thinking is that the PR would be reviewed by basically > >> anyone who has > >> free time. > >> I think that, at first, only OpenJFX committers will be > >> able to merge PRs. > >> They would > >> do the final review/merge to the staging repo after it has > >> been reviewed by > >> the "wider audience" > >> which includes people without commit rights (people like > >> us). Then, as this > >> thing evolves, > >> based on the pool of people who are contributing both pull > >> requests and PR > >> reviews, > >> the committers will be able to grant commit privileges to > >> some people in > >> that pool. > >> > >> I can't think of any way that would make it so the changes > >> are as likely to > >> be > >> merged upstream as possible other than having the current > >> OpenJFX > >> committers paving the > >> way. Hopefully this vision is aligned with Kevin's and > >> hopefully these > >> concrete details > >> can be worked out. > >> > >> Regards, > >> Michael > >> > >> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker > >> > wrote: > >> > >> > >> So if a community ran GitHub is used for staging, who > >> will approve PRs > >> > >> for > >> > >> the code and the Wiki of the GitHub repo? > >> > >> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen > >> > > >> wrote: > >> > >> > >> Great points, Nir. We share the same hopes. I just > >> wanted to piggy-back > >> on the > >> wiki thing: > >> > >> " * The Wiki could be open sourced as well (like > >> other Wikis). I could > >> definitely update a page or 2 there and so would > >> other developers as > >> > >> they > >> > >> gain knowledge. I don't know yet how permissions > >> for that should be > >> handled." > >> > >> This is another thing that we could use the GitHub > >> staging repository > >> > >> for. > >> > >> The staging repository could have a wiki (projects > >> on GitHub can have > >> > >> one) > >> > >> that is editable by all, and then maybe once a > >> month or so someone with > >> permissions > >> to edit to official wiki can sync with the new, > >> reviewed changes (the > >> once-a-month > >> time constraint is very flexible). > >> > >> I am just trying to explain how the GitHub > >> repository "one-way mirror" > >> (potentially linked > >> with/managed by Adopt an OpenJDK) can act as a > >> staging ground for all > >> kinds of contributions to > >> OpenJFX. > >> > >> By the way, I am trying to cleanup the groundwork > >> I did on getting > >> Appveyor builds to > >> run for openjfx, if indeed it is decided to setup > >> such a staging > >> repository. You can > >> see my efforts here: https://raw.githubusercontent. > >> > >> > >> > com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057/appveyor.yml > >> > >> If the GitHub repository was setup, changes such > >> as these to add CI > >> infrastructure would > >> never be adopted by upstream OpenJFX, but would > >> allow for developer's to > >> get good > >> feedback on test results for all supported > >> platforms when they open a > >> > >> PR. > >> > >> Merging a PR > >> on the public GitHub repository means, in my > >> opinion, that it is ready > >> > >> to > >> > >> be opened as > >> an upstream bug/feature request. Automating the > >> process with patch sets, > >> webrevs, formatting/lint > >> results, etc. would be the most ideal situation > >> and I would be happy to > >> contribute to these > >> efforts. > >> > >> Regards, > >> > >> Michael Ennen > >> > >> > >> > >> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker > >> > > wrote: > >> > >> > >> Hello, > >> > >> As someone who has recently made the climb and > >> managed to build OpenJFX > >> with OpenJDK on Win 10 I might have some > >> relevant input. > >> > >> --- Building OpenJFX --- > >> > >> * With the recently updated instructions on > >> the Wiki, building OpenJFX > >> > >> is > >> > >> not that hard. Having to build OpenJDK for > >> that was a real headache > >> because > >> their instructions and build tools are not up > >> to date ( > >> https://bugs.openjdk.java.net/browse/JDK-8194645 > >> ). > >> * The above doesn't mean that the process > >> shouldn't be made easier. > >> Ideally, it would be the as easy as working on > >> most open source > >> > >> projects > >> > >> on > >> Github (not advocating git over hg): clone > >> into the IDE and start > >> working; > >> when a fix is ready, submit a PR. Don't know > >> if it's technically > >> > >> possible > >> > >> in this case, but it's a target. > >> * The repository needs a good cleanup before > >> contributors start > >> > >> cloning ( > >> > >> bugs.openjdk.java.net/browse/JDK-8196198 > >> ). > >> > >> --- Working on OpenJFX --- > >> > >> * It should be clear which tests need to run > >> for a specific patch. > >> Changes > >> can be made anywhere from the documentation > >> level to native code level > >> and > >> there's no reason to run the same tests for > >> all of these. If the > >> > >> process > >> > >> can be automate it's even better. > >> * The Webrev tool seems archaic to me (and > >> part of its output is broken > >> as > >> far as I could tell). An IDE can create diff > >> patches with a couple of > >> clicks. > >> * The Jcheck tool seems archaic to me. It > >> should be ported to IDE > >> formatters which are to be distributed with > >> the source. No reason to > >> > >> run > >> > >> a > >> tool that tells me which whitespaces I need to > >> go back and change when > >> something like Ctrl+Shift+F in an IDE finishes > >> the job. > >> > >> --- Wiki --- > >> > >> * The Wiki could be open sourced as well (like > >> other Wikis). I could > >> definitely update a page or 2 there and so > >> would other developers as > >> > >> they > >> > >> gain knowledge. I don't know yet how > >> permissions for that should be > >> handled. > >> * Code conventions should be clearly listed. > >> * Separate sections with instructions should > >> be made for: (1) cloning > >> > >> and > >> > >> building, (2) modifying, (3) running tests, > >> (4) submitting, and (5) > >> reviewing. > >> * Old sections should be cleaned up (I don't > >> think Discussions is > >> > >> useful > >> > >> anymore). > >> > >> --- Review policy --- > >> > >> * I have no experience with review policies or > >> project roles so I can't > >> help here much (maybe after a discussion > starts). > >> * One thing I do know is that reviewers should > >> be extremely > >> knowledgeable, > >> which means that there aren't many qualified. > >> Because of this, if it > >> becomes "too" easy to contribute to OpenJFX, > >> careful measures need to > >> > >> be > >> > >> taken as to not to swamp the few reviewers > >> with many patches (though > >> > >> some > >> > >> would say this is an ideal situation). Some > >> sort of review queue might > >> help > >> with organization instead of the current email > >> system. I have no > >> > >> concrete > >> > >> solution for this. > >> > >> - Nir > >> > >> > >> Message: 1 > >> > >> Date: Thu, 01 Feb 2018 15:26:24 -0800 > >> From: Kevin Rushforth > >> >> > > >> To: "openjfx-dev at openjdk.java.net > >> " > >> >> > > >> Subject: More community participation in > >> JavaFX > >> Message-ID: <5A73A220.7030706 at oracle.com > >> > > >> Content-Type: text/plain; > >> charset=windows-1252; format=flowed > >> > >> To: OpenJFX Developers > >> > >> We are looking to grow the community of > >> contributors to the OpenJFX > >> project, especially serious contributors > >> who will stick around long > >> enough to become reviewers, to help us > >> keep the platform vibrant. To > >> this end we are looking at ways to > >> encourage more participation and > >> > >> make > >> > >> it easier for interested folks to > contribute. > >> > >> We are specifically looking to discuss > >> ideas around the following > >> > >> areas: > >> > >> * Easing barriers to contribution (e.g., > >> making JavaFX easier to > >> > >> build, > >> > >> better documentation, making it easier to > >> test changes) > >> > >> * Code review policies > >> > >> * API / feature review policies > >> > >> * Code review tools (we currently use > >> webrev, but that isn't set in > >> > >> stone) > >> > >> To keep this thread productive, the > >> following are explicitly out of > >> > >> scope: > >> > >> * Discussion of specific features or bugs > >> that you would like to > >> implement (or wish someone else would) > >> > >> * Discussion about platform support > >> > >> * Discussion about version control systems > >> (e.g., hg versus git), > >> hosting of the OpenJFX repos and bug > >> database (e.g., OpenJDK versus > >> github), etc...at least for now. We are > >> aware of the potential > >> > >> benefits > >> > >> of such changes, but we'd like to focus > >> our efforts on > >> > >> higher-leverage > >> > >> things we can do in the short term. > >> > >> * Discussion about the requirement of a > >> signed OCA to become a > >> > >> contributor > >> > >> * Off-topic or tangential commentary about > >> OpenJFX that isn't > >> > >> directly > >> > >> related to the topic at hand > >> > >> > >> As a starting point for discussion, here > >> are some areas I think need > >> improvement; I'm sure there are others: > >> > >> I. Helping contributors get started > >> > >> It isn?t as easy to get started with > >> OpenJFX as it should be. We want > >> > >> to > >> > >> make it easier for potential OpenJFX > >> contributors to get started. > >> > >> Here > >> > >> are some ideas that I think might help: > >> > >> * Improve the build instructions / Wiki (I > >> made a first start, but > >> > >> there > >> > >> is much more to be done) > >> > >> * Make the build itself more resilient > >> where possible, and provide > >> better error messages, specifically when > >> dealing with native > >> > >> compilers > >> > >> and libraries > >> > >> * Add an option to skip building all > >> native code and use prebuilt > >> binaries (like we do already for media and > >> webkit); this is tracked > >> > >> by > >> > >> JDK-8092279, but it hasn?t been looked at > >> recently > >> > >> * Make it easier to build / test your > >> local OpenJFX build using an > >> OpenJDK build (currently the only way to > >> do this is to build OpenJDK > >> locally, after using configure to point to > >> your just-built javafx.* > >> modules). > >> > >> * Provide step-by-step instructions for > >> how to make a contribution, > >> including testing requirements; a lot of > >> the pieces are there, but > >> > >> are > >> > >> out of date or scattered in several > >> places. As part of this, we could > >> have a section on how to contribute docs, > >> samples or tests, since > >> > >> that > >> > >> is often a good place to start. > >> > >> * Provide a sandbox environment where > >> contributors can discuss and > >> > >> test > >> > >> ideas. For example, an OpenJFX mirror on > >> github, potentially > >> > >> connected > >> > >> to AdoptOpenJDK. > >> > >> > >> II. Code reviews and API reviews > >> > >> Code reviews are important to maintain > >> high-quality contributions, > >> > >> but > >> > >> we recognize that not every type of change > >> needs the same level of > >> review. Without lowering our standards of > >> quality, we want to make it > >> easier to get low-impact changes (simple > >> bug fixes) accepted. > >> > >> There are three categories of changes, > >> each of which might merit a > >> different review standard: > >> > >> 1. Low-impact bug fixes. These are > >> typically isolated bug fixes with > >> little or no impact beyond fixing the bug > >> in question; included in > >> > >> this > >> > >> category are test fixes (including new > >> tests) doc fixes, and fixes to > >> sample applications (including new samples). > >> > >> 2. Higher impact bug fixes or RFEs. These > >> include changes to the > >> implementation that potentially have a > >> performance or behavioral > >> > >> impact, > >> > >> or are otherwise broad in scope. Some > >> larger bug fixes will fall into > >> this category, as will fixes in high-risk > >> areas (e.g., CSS). > >> > >> 3. New features / API additions. In > >> addition to reviewing the > >> implementation, we will need a separate > >> approval process for the new > >> > >> API > >> > >> / feature (such as the CSR, which is what > >> we use now, or a similar > >> process). > >> > >> We take compatibility seriously, so > >> anything that adds new API needs > >> > >> to > >> > >> be done with an eye towards supporting it > >> for at least 10 years. We > >> don't want to add new public API without > >> that level of commitment. > >> > >> Every > >> > >> new feature forecloses on alternate future > >> features. Significant > >> > >> effort > >> > >> must be taken to think about "if we did > >> this, what could it interact > >> with in the future?" Also, anything with a > >> large potential impact on > >> performance or behavioral compatibility > >> needs to be looked at > >> > >> carefully. > >> > >> Put another way, we want to encourage > >> thinking about new features or > >> > >> new > >> > >> API in terms of a design / stewardship > >> process; to think in terms of > >> questions like "what's the right thing for > >> JavaFX in the next 10+ > >> > >> years" > >> > >> rather than "here's some code that solves > >> my problem, please take > >> > >> it". > >> > >> As a stake in the ground, I might suggest > >> the following: > >> > >> * All changes need at least one reviewer > >> other than the person making > >> the change who can evaluate the change for > >> correctness and > >> > >> consistency. > >> > >> For simple bug fixes, a single reviewer > >> may be sufficient. Of course, > >> one of our big challenges in all this is: > >> "how do we grow more > >> reviewers?", by which I mean "how do we > >> facilitate getting > >> > >> contributors > >> > >> with enough expertise in a given area to > >> eventually be able to > >> effectively review contributions from > others?" > >> > >> * We need clear criteria for the other two > >> categories that balance > >> process efficiency with the desire to > >> maintain compatibility and > >> stability. API changes need to be approved > >> by a lead. My thought is > >> > >> to > >> > >> combine the last two into a single > >> category for purposes of reviewing > >> the implementation. Anything that affects > >> public API or behavioral > >> compatibility will require CSR or similar > >> approval, over and above > >> > >> the > >> > >> implementation review, which seems > sufficient. > >> > >> * I recommend that we formalize the > >> concept of reviewers, using the > >> OpenJDK Reviewer role for the Project. We > >> might also consider if we > >> > >> want > >> > >> to make any changes to the criteria used > >> by the JDK Project for > >> > >> becoming > >> > >> an OpenJFX Project Author, Committer, and > >> Reviewer. The OpenJDK > >> > >> bylaws > >> > >> allow projects a fair degree of latitude > >> to define these criteria, so > >> > >> we > >> > >> might consider making some modifications. > >> For example, we might make > >> > >> it > >> > >> somewhat easier for a Contributor to > >> become an Author, or for a > >> Committer to become a Reviewer. I have > >> some thoughts on this, but > >> > >> want > >> > >> to hear from others first. > >> > >> > >> I look forward to feedback on this > >> proposal, and hope it will spark a > >> productive discussion. > >> > >> -- Kevin Rushforth, OpenJFX Project Lead > >> > >> > >> > >> > > From johnvalrose at gmail.com Wed Feb 7 07:37:45 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Wed, 7 Feb 2018 18:37:45 +1100 Subject: More community participation in JavaFX In-Reply-To: References: <5A786D32.6050600@oracle.com> <5A7A6188.2090608@oracle.com> <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> Message-ID: Jonathan - why do you *cough* at ideas like more complex controls and docking frameworks? I think that a docking framework especially would be a great addition to JavaFX. Am I missing something? > On 7 Feb 2018, at 18:16, Jonathan Giles wrote: > > Obviously everyone is at ControlsFX instead ;-) > > Part of the drop I would suggest is simply that many of the itches people > want to scratch are now scratched. Alternatively, the remaining itches are > either in more complex controls (*cough* docking frameworks *cough*) or in > areas beneath the controls APIs - performance, webview, etc - which are > more challenging and require greater levels of dedication. > > However, more generally, your point is well made - contribution to JavaFX > does not need to be synonymous with contribution to OpenJFX. People who > find the challenges of the current OpenJFX requirements too great should be > encouraged to involve themselves in projects such as JFXtras, etc. > > -- Jonathan > >> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >> >> Many years ago I had a discussion with Jonathan Giles about if the things >> that were being made in JFXtras would eventually become part of the JavaFX >> core. In the end I decided that, for me personally, I could do the things I >> wanted to perfectly in a separate project. The rigid structure that >> Java(FX) has to adhere to, would be a big downside. >> >> What I want to say with that is that all the external projects are also >> contributions to JavaFX. It does not matter whether for example a control >> is part of the core distribution or of a side project; it is just another >> module users can add to the mix. >> >> So reflecting back I still stand by that choice. But having a few more >> people in the project (just like in JavaFX ;-) ) would be nice, but OTOH it >> forces me to deal with (and learn about) annoying stuff like Gradle build >> scripts and Java 9 migration. But because of that progress is not as fast >> as I would like it to be. Could it be that there is a decline in people >> willing to work for open source projects? Or is it just that this tech, >> JavaFX, is no longer appealing? >> >> Tom >> >> >> > Obviously everyone is at ControlsFX instead ;-) > > Part of the drop I would suggest is simply that many of the itches people > want to scratch are now scratched. Alternatively, the remaining itches are > either in more complex controls (*cough* docking frameworks *cough*) or in > areas beneath the controls APIs - performance, webview, etc - which are > more challenging and require greater levels of dedication. > > However, more generally, your point is well made - contribution to JavaFX > does not need to be synonymous with contribution to OpenJFX. People who > find the challenges of the current OpenJFX requirements too great should be > encouraged to involve themselves in projects such as JFXtras, etc. > > -- Jonathan > >> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >> >> Many years ago I had a discussion with Jonathan Giles about if the things >> that were being made in JFXtras would eventually become part of the JavaFX >> core. In the end I decided that, for me personally, I could do the things I >> wanted to perfectly in a separate project. The rigid structure that >> Java(FX) has to adhere to, would be a big downside. >> >> What I want to say with that is that all the external projects are also >> contributions to JavaFX. It does not matter whether for example a control >> is part of the core distribution or of a side project; it is just another >> module users can add to the mix. >> >> So reflecting back I still stand by that choice. But having a few more >> people in the project (just like in JavaFX ;-) ) would be nice, but OTOH it >> forces me to deal with (and learn about) annoying stuff like Gradle build >> scripts and Java 9 migration. But because of that progress is not as fast >> as I would like it to be. Could it be that there is a decline in people >> willing to work for open source projects? Or is it just that this tech, >> JavaFX, is no longer appealing? >> >> Tom >> >> >> >>> On 7-2-2018 03:16, Kevin Rushforth wrote: >>> >>> I would recommend against having a separate issue tracker or mailing list >>> associated with the sandbox. That will create more confusion than any >>> benefit you might have. >>> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>> >>>> Another thing to be careful about with the sandbox/staging idea is the >>>> confusion that will arise with duplication. There will be 2 issue trackers >>>> (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and maybe 2 >>>> discussion lists. For those "in the know" this will be a simple matter, but >>>> for a potential contributor this can be a gamebreaker if not handled >>>> appropriately. >>>> >>>> Dalibor Topic's suggestion of contacting other mirrors can be >>>> instrumental in solving these problems. >>>> >>>> - Nir >>>> >>>> On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com > wrote: >>>> >>>> Yes, this sounds like a good step in the right direction. This >>>> would give anyone (with a signed OCA) the ability to create their >>>> own branch, commit changes to it, submit a PR, etc. >>>> >>>> I presume there will be a branch that is an exact mirror of the >>>> jfx-dev repo on OpenJDK in addition to the development branch in >>>> the sandbox? >>>> >>>> The only thing to consider is whether it should be Committers or >>>> Reviewers that have rights to merge into the sandbox development >>>> branch. There are pros / cons of each. I'd probably lean towards >>>> having it be Committers, with the idea that a Committer needs to >>>> sponsor the patch anyway and would then be able to "take it the >>>> rest of the way". The only downside I see is that you could end up >>>> with a few patches that get accepted into the sandbox dev branch, >>>> but never make it to the upstream jfx-dev repo (or not without >>>> significant change). I doubt this will be a big problem in practice. >>>> >>>> Either way, this could also provide a good alternative to webrev >>>> when reviewing the final changes. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Johan Vos wrote: >>>> >>>> Hi Michael, >>>> >>>> This proposal is very much in line with my thinking as well. >>>> The problem is not that we don't have a github clone of >>>> OpenJFX. We have a >>>> number of them (e.g. I created >>>> https://github.com/javafxports/jfx-dev >>>> some >>>> months ago). We just need a single one that is updated >>>> constantly from >>>> mainstream, and standardize on that. Let's call that "sandbox" >>>> (I would be >>>> ok with staging as well, but sandbox is imho more inviting to >>>> people who >>>> want to try something drastic, e.g. support for Vulkan) >>>> >>>> The main issue is how to get contributions, review them, and >>>> eventually >>>> send them upstream. >>>> >>>> The PR review process is extremely important. If we lower that >>>> bar, we >>>> loose quality. If the bar is too high, great PR's won't be >>>> accepted >>>> upstream as there is not enough review time to review it. >>>> >>>> I agree giving the current OpenJFX committers merge rights for >>>> the >>>> "sandbox" repository makes sense. Once a public contribution >>>> is merged by >>>> one of those committers, that same committer can send it >>>> upstream to the >>>> existing OpenJFX repository. Additional checks will be >>>> performed there, >>>> mainly in order to make sure the overall "Feel of Java" is >>>> preserved. To >>>> that purpose, it would help to have a closer alignment with >>>> the OpenJDK >>>> community. >>>> >>>> We have to be aware that this will increase the workload of >>>> the current >>>> committers and reviewers. That is the price we pay for >>>> standardization. >>>> Rather than everyone creating his own forks of a UI framework >>>> in Java, we >>>> invest a lot in creating a single, generally agreed one. >>>> >>>> So in summary, I'm +1 on a 2-phase approach: "open" commits >>>> allowed in >>>> staging. OpenJFX committers accept PR's (if they are of good >>>> quality) and >>>> prepare upstream commits for OpenJFX. We hope there will be more >>>> contributors who become committers and reviewers in the medium >>>> term. >>>> >>>> - Johan >>>> >>>> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen >>>> > wrote: >>>> >>>> >>>> Those are great questions, and I think with >>>> Kevin/Oracle/other OpenJFX devs >>>> help we >>>> can figure something out. >>>> >>>> My thinking is that the PR would be reviewed by basically >>>> anyone who has >>>> free time. >>>> I think that, at first, only OpenJFX committers will be >>>> able to merge PRs. >>>> They would >>>> do the final review/merge to the staging repo after it has >>>> been reviewed by >>>> the "wider audience" >>>> which includes people without commit rights (people like >>>> us). Then, as this >>>> thing evolves, >>>> based on the pool of people who are contributing both pull >>>> requests and PR >>>> reviews, >>>> the committers will be able to grant commit privileges to >>>> some people in >>>> that pool. >>>> >>>> I can't think of any way that would make it so the changes >>>> are as likely to >>>> be >>>> merged upstream as possible other than having the current >>>> OpenJFX >>>> committers paving the >>>> way. Hopefully this vision is aligned with Kevin's and >>>> hopefully these >>>> concrete details >>>> can be worked out. >>>> >>>> Regards, >>>> Michael >>>> >>>> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker >>>> > wrote: >>>> >>>> >>>> So if a community ran GitHub is used for staging, who >>>> will approve PRs >>>> >>>> for >>>> >>>> the code and the Wiki of the GitHub repo? >>>> >>>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen >>>> > >>>> wrote: >>>> >>>> >>>> Great points, Nir. We share the same hopes. I just >>>> wanted to piggy-back >>>> on the >>>> wiki thing: >>>> >>>> " * The Wiki could be open sourced as well (like >>>> other Wikis). I could >>>> definitely update a page or 2 there and so would >>>> other developers as >>>> >>>> they >>>> >>>> gain knowledge. I don't know yet how permissions >>>> for that should be >>>> handled." >>>> >>>> This is another thing that we could use the GitHub >>>> staging repository >>>> >>>> for. >>>> >>>> The staging repository could have a wiki (projects >>>> on GitHub can have >>>> >>>> one) >>>> >>>> that is editable by all, and then maybe once a >>>> month or so someone with >>>> permissions >>>> to edit to official wiki can sync with the new, >>>> reviewed changes (the >>>> once-a-month >>>> time constraint is very flexible). >>>> >>>> I am just trying to explain how the GitHub >>>> repository "one-way mirror" >>>> (potentially linked >>>> with/managed by Adopt an OpenJDK) can act as a >>>> staging ground for all >>>> kinds of contributions to >>>> OpenJFX. >>>> >>>> By the way, I am trying to cleanup the groundwork >>>> I did on getting >>>> Appveyor builds to >>>> run for openjfx, if indeed it is decided to setup >>>> such a staging >>>> repository. You can >>>> see my efforts here: https://raw.githubusercontent. >>>> >>>> >>>> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057 >>>> /appveyor.yml >>>> >>>> If the GitHub repository was setup, changes such >>>> as these to add CI >>>> infrastructure would >>>> never be adopted by upstream OpenJFX, but would >>>> allow for developer's to >>>> get good >>>> feedback on test results for all supported >>>> platforms when they open a >>>> >>>> PR. >>>> >>>> Merging a PR >>>> on the public GitHub repository means, in my >>>> opinion, that it is ready >>>> >>>> to >>>> >>>> be opened as >>>> an upstream bug/feature request. Automating the >>>> process with patch sets, >>>> webrevs, formatting/lint >>>> results, etc. would be the most ideal situation >>>> and I would be happy to >>>> contribute to these >>>> efforts. >>>> >>>> Regards, >>>> >>>> Michael Ennen >>>> >>>> >>>> >>>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker >>>> > >>>> wrote: >>>> >>>> >>>> Hello, >>>> >>>> As someone who has recently made the climb and >>>> managed to build OpenJFX >>>> with OpenJDK on Win 10 I might have some >>>> relevant input. >>>> >>>> --- Building OpenJFX --- >>>> >>>> * With the recently updated instructions on >>>> the Wiki, building OpenJFX >>>> >>>> is >>>> >>>> not that hard. Having to build OpenJDK for >>>> that was a real headache >>>> because >>>> their instructions and build tools are not up >>>> to date ( >>>> https://bugs.openjdk.java.net/browse/JDK-8194645 >>>> ). >>>> * The above doesn't mean that the process >>>> shouldn't be made easier. >>>> Ideally, it would be the as easy as working on >>>> most open source >>>> >>>> projects >>>> >>>> on >>>> Github (not advocating git over hg): clone >>>> into the IDE and start >>>> working; >>>> when a fix is ready, submit a PR. Don't know >>>> if it's technically >>>> >>>> possible >>>> >>>> in this case, but it's a target. >>>> * The repository needs a good cleanup before >>>> contributors start >>>> >>>> cloning ( >>>> >>>> bugs.openjdk.java.net/browse/JDK-8196198 >>>> ). >>>> >>>> --- Working on OpenJFX --- >>>> >>>> * It should be clear which tests need to run >>>> for a specific patch. >>>> Changes >>>> can be made anywhere from the documentation >>>> level to native code level >>>> and >>>> there's no reason to run the same tests for >>>> all of these. If the >>>> >>>> process >>>> >>>> can be automate it's even better. >>>> * The Webrev tool seems archaic to me (and >>>> part of its output is broken >>>> as >>>> far as I could tell). An IDE can create diff >>>> patches with a couple of >>>> clicks. >>>> * The Jcheck tool seems archaic to me. It >>>> should be ported to IDE >>>> formatters which are to be distributed with >>>> the source. No reason to >>>> >>>> run >>>> >>>> a >>>> tool that tells me which whitespaces I need to >>>> go back and change when >>>> something like Ctrl+Shift+F in an IDE finishes >>>> the job. >>>> >>>> --- Wiki --- >>>> >>>> * The Wiki could be open sourced as well (like >>>> other Wikis). I could >>>> definitely update a page or 2 there and so >>>> would other developers as >>>> >>>> they >>>> >>>> gain knowledge. I don't know yet how >>>> permissions for that should be >>>> handled. >>>> * Code conventions should be clearly listed. >>>> * Separate sections with instructions should >>>> be made for: (1) cloning >>>> >>>> and >>>> >>>> building, (2) modifying, (3) running tests, >>>> (4) submitting, and (5) >>>> reviewing. >>>> * Old sections should be cleaned up (I don't >>>> think Discussions is >>>> >>>> useful >>>> >>>> anymore). >>>> >>>> --- Review policy --- >>>> >>>> * I have no experience with review policies or >>>> project roles so I can't >>>> help here much (maybe after a discussion starts). >>>> * One thing I do know is that reviewers should >>>> be extremely >>>> knowledgeable, >>>> which means that there aren't many qualified. >>>> Because of this, if it >>>> becomes "too" easy to contribute to OpenJFX, >>>> careful measures need to >>>> >>>> be >>>> >>>> taken as to not to swamp the few reviewers >>>> with many patches (though >>>> >>>> some >>>> >>>> would say this is an ideal situation). Some >>>> sort of review queue might >>>> help >>>> with organization instead of the current email >>>> system. I have no >>>> >>>> concrete >>>> >>>> solution for this. >>>> >>>> - Nir >>>> >>>> >>>> Message: 1 >>>> >>>> Date: Thu, 01 Feb 2018 15:26:24 -0800 >>>> From: Kevin Rushforth >>>> >>> > >>>> To: "openjfx-dev at openjdk.java.net >>>> " >>>> >>> > >>>> Subject: More community participation in >>>> JavaFX >>>> Message-ID: <5A73A220.7030706 at oracle.com >>>> > >>>> Content-Type: text/plain; >>>> charset=windows-1252; format=flowed >>>> >>>> To: OpenJFX Developers >>>> >>>> We are looking to grow the community of >>>> contributors to the OpenJFX >>>> project, especially serious contributors >>>> who will stick around long >>>> enough to become reviewers, to help us >>>> keep the platform vibrant. To >>>> this end we are looking at ways to >>>> encourage more participation and >>>> >>>> make >>>> >>>> it easier for interested folks to contribute. >>>> >>>> We are specifically looking to discuss >>>> ideas around the following >>>> >>>> areas: >>>> >>>> * Easing barriers to contribution (e.g., >>>> making JavaFX easier to >>>> >>>> build, >>>> >>>> better documentation, making it easier to >>>> test changes) >>>> >>>> * Code review policies >>>> >>>> * API / feature review policies >>>> >>>> * Code review tools (we currently use >>>> webrev, but that isn't set in >>>> >>>> stone) >>>> >>>> To keep this thread productive, the >>>> following are explicitly out of >>>> >>>> scope: >>>> >>>> * Discussion of specific features or bugs >>>> that you would like to >>>> implement (or wish someone else would) >>>> >>>> * Discussion about platform support >>>> >>>> * Discussion about version control systems >>>> (e.g., hg versus git), >>>> hosting of the OpenJFX repos and bug >>>> database (e.g., OpenJDK versus >>>> github), etc...at least for now. We are >>>> aware of the potential >>>> >>>> benefits >>>> >>>> of such changes, but we'd like to focus >>>> our efforts on >>>> >>>> higher-leverage >>>> >>>> things we can do in the short term. >>>> >>>> * Discussion about the requirement of a >>>> signed OCA to become a >>>> >>>> contributor >>>> >>>> * Off-topic or tangential commentary about >>>> OpenJFX that isn't >>>> >>>> directly >>>> >>>> related to the topic at hand >>>> >>>> >>>> As a starting point for discussion, here >>>> are some areas I think need >>>> improvement; I'm sure there are others: >>>> >>>> I. Helping contributors get started >>>> >>>> It isn?t as easy to get started with >>>> OpenJFX as it should be. We want >>>> >>>> to >>>> >>>> make it easier for potential OpenJFX >>>> contributors to get started. >>>> >>>> Here >>>> >>>> are some ideas that I think might help: >>>> >>>> * Improve the build instructions / Wiki (I >>>> made a first start, but >>>> >>>> there >>>> >>>> is much more to be done) >>>> >>>> * Make the build itself more resilient >>>> where possible, and provide >>>> better error messages, specifically when >>>> dealing with native >>>> >>>> compilers >>>> >>>> and libraries >>>> >>>> * Add an option to skip building all >>>> native code and use prebuilt >>>> binaries (like we do already for media and >>>> webkit); this is tracked >>>> >>>> by >>>> >>>> JDK-8092279, but it hasn?t been looked at >>>> recently >>>> >>>> * Make it easier to build / test your >>>> local OpenJFX build using an >>>> OpenJDK build (currently the only way to >>>> do this is to build OpenJDK >>>> locally, after using configure to point to >>>> your just-built javafx.* >>>> modules). >>>> >>>> * Provide step-by-step instructions for >>>> how to make a contribution, >>>> including testing requirements; a lot of >>>> the pieces are there, but >>>> >>>> are >>>> >>>> out of date or scattered in several >>>> places. As part of this, we could >>>> have a section on how to contribute docs, >>>> samples or tests, since >>>> >>>> that >>>> >>>> is often a good place to start. >>>> >>>> * Provide a sandbox environment where >>>> contributors can discuss and >>>> >>>> test >>>> >>>> ideas. For example, an OpenJFX mirror on >>>> github, potentially >>>> >>>> connected >>>> >>>> to AdoptOpenJDK. >>>> >>>> >>>> II. Code reviews and API reviews >>>> >>>> Code reviews are important to maintain >>>> high-quality contributions, >>>> >>>> but >>>> >>>> we recognize that not every type of change >>>> needs the same level of >>>> review. Without lowering our standards of >>>> quality, we want to make it >>>> easier to get low-impact changes (simple >>>> bug fixes) accepted. >>>> >>>> There are three categories of changes, >>>> each of which might merit a >>>> different review standard: >>>> >>>> 1. Low-impact bug fixes. These are >>>> typically isolated bug fixes with >>>> little or no impact beyond fixing the bug >>>> in question; included in >>>> >>>> this >>>> >>>> category are test fixes (including new >>>> tests) doc fixes, and fixes to >>>> sample applications (including new samples). >>>> >>>> 2. Higher impact bug fixes or RFEs. These >>>> include changes to the >>>> implementation that potentially have a >>>> performance or behavioral >>>> >>>> impact, >>>> >>>> or are otherwise broad in scope. Some >>>> larger bug fixes will fall into >>>> this category, as will fixes in high-risk >>>> areas (e.g., CSS). >>>> >>>> 3. New features / API additions. In >>>> addition to reviewing the >>>> implementation, we will need a separate >>>> approval process for the new >>>> >>>> API >>>> >>>> / feature (such as the CSR, which is what >>>> we use now, or a similar >>>> process). >>>> >>>> We take compatibility seriously, so >>>> anything that adds new API needs >>>> >>>> to >>>> >>>> be done with an eye towards supporting it >>>> for at least 10 years. We >>>> don't want to add new public API without >>>> that level of commitment. >>>> >>>> Every >>>> >>>> new feature forecloses on alternate future >>>> features. Significant >>>> >>>> effort >>>> >>>> must be taken to think about "if we did >>>> this, what could it interact >>>> with in the future?" Also, anything with a >>>> large potential impact on >>>> performance or behavioral compatibility >>>> needs to be looked at >>>> >>>> carefully. >>>> >>>> Put another way, we want to encourage >>>> thinking about new features or >>>> >>>> new >>>> >>>> API in terms of a design / stewardship >>>> process; to think in terms of >>>> questions like "what's the right thing for >>>> JavaFX in the next 10+ >>>> >>>> years" >>>> >>>> rather than "here's some code that solves >>>> my problem, please take >>>> >>>> it". >>>> >>>> As a stake in the ground, I might suggest >>>> the following: >>>> >>>> * All changes need at least one reviewer >>>> other than the person making >>>> the change who can evaluate the change for >>>> correctness and >>>> >>>> consistency. >>>> >>>> For simple bug fixes, a single reviewer >>>> may be sufficient. Of course, >>>> one of our big challenges in all this is: >>>> "how do we grow more >>>> reviewers?", by which I mean "how do we >>>> facilitate getting >>>> >>>> contributors >>>> >>>> with enough expertise in a given area to >>>> eventually be able to >>>> effectively review contributions from >>>> others?" >>>> >>>> * We need clear criteria for the other two >>>> categories that balance >>>> process efficiency with the desire to >>>> maintain compatibility and >>>> stability. API changes need to be approved >>>> by a lead. My thought is >>>> >>>> to >>>> >>>> combine the last two into a single >>>> category for purposes of reviewing >>>> the implementation. Anything that affects >>>> public API or behavioral >>>> compatibility will require CSR or similar >>>> approval, over and above >>>> >>>> the >>>> >>>> implementation review, which seems >>>> sufficient. >>>> >>>> * I recommend that we formalize the >>>> concept of reviewers, using the >>>> OpenJDK Reviewer role for the Project. We >>>> might also consider if we >>>> >>>> want >>>> >>>> to make any changes to the criteria used >>>> by the JDK Project for >>>> >>>> becoming >>>> >>>> an OpenJFX Project Author, Committer, and >>>> Reviewer. The OpenJDK >>>> >>>> bylaws >>>> >>>> allow projects a fair degree of latitude >>>> to define these criteria, so >>>> >>>> we >>>> >>>> might consider making some modifications. >>>> For example, we might make >>>> >>>> it >>>> >>>> somewhat easier for a Contributor to >>>> become an Author, or for a >>>> Committer to become a Reviewer. I have >>>> some thoughts on this, but >>>> >>>> want >>>> >>>> to hear from others first. >>>> >>>> >>>> I look forward to feedback on this >>>> proposal, and hope it will spark a >>>> productive discussion. >>>> >>>> -- Kevin Rushforth, OpenJFX Project Lead >>>> >>>> >>>> >>>> >>>> >> From johan.vos at gluonhq.com Wed Feb 7 07:47:55 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 07 Feb 2018 07:47:55 +0000 Subject: future content of OpenJFX In-Reply-To: <09a2b76c-c11b-474e-b4d9-a3bf36386424@me.com> References: <09a2b76c-c11b-474e-b4d9-a3bf36386424@me.com> Message-ID: While it's good to know who is interested in what areas, I think it's hard to create a list of interested or capable people as that depends on motivations. There are many developers who used to work on the JavaFX team who are now working elsewhere. That means there is plenty of knowledge and potential in the world. I don't see a problem there. I hate to sound like a business-first person, but I think the question is rather how many business is there in JavaFX? We can all do some things in our spare time (and most of us do), but in the end moving the platform forward requires more than this. It requires people working full-time on it, hence being paid to do this. Now, all indications show that there is a big interest in JavaFX. For example, we see the download numbers of Scene Builder still increasing (about 30K downloads/month). JavaFX is much more popular on Google Trends now than Swing. One of the main problems is that JavaFX is used in "hidden" areas (see http://gluonhq.com/javafx-hidden-economy/) If only 1% of the money spent by companies on JavaFX could be used to maintain the core, we would be in a good shape, I believe. But moving back to "the future content": rather than guessing "I'ld like to have that" it would be interesting to know what companies want to pay for. The hard thing is then that most of the work on the OpenJFX core is beyond the surface of what companies see, so translating those business requirements into technical ones is not always trivial. Enough business talk for now, back to development :) - Johan On Wed, Feb 7, 2018 at 1:24 AM Stephen Desofi wrote: > +1 > > This makes sense. Having a list of who might be willing to contribute > and in what areas they are willing to contribute dictates where we can go. > As Rumsfeld once said "You go to war with the army have, not the one you > want". > > Steve > > Sent from iCloud > > On Feb 06, 2018, at 06:41 AM, John-Val Rose wrote: > > Maybe Kevin could request that anyone who is seriously both willing and > capable to contribute to OpenJFX email him privately so that the list > doesn?t get to ?see? anyone who wants to fly under the radar. > > Kevin could then post the approximate number of resources actually > available. > > I realise of course that some people may not wish to even let Kevin know > of their interest and availability initially but at least we would have a > ballpark figure as to the size of the ?talent pool?. > > I think we need to have some handle on this number before any significant > set-up work is undertaken (just in case the number is only 2 or 3 for > example instead of 20 or so). > > On 6 Feb 2018, at 22:12, Stephen Desofi wrote: > > > A poll would definitely be useful because we may find ourselves another > subset. > > > The subset of people who even want to go ?off road? to begin with. Most > people only consider going places where the road already leads?and that > might be about 99%. > > > > > Sent from my iPhone > > > On Feb 5, 2018, at 11:14 PM, John-Val Rose wrote: > > > I think there?s a small matter that is being overlooked here. > > > The size of the ?talent pool?. > > > I?m just pulling numbers out of thin air here but first I?m guessing that > the vast majority of JavaFX users do *not* read this list. > > > Then, out of those who do, only some *care* enough to contribute. > > > Out of those, only some are *competent* enough to contribute. > > > And then, out of that much smaller set, only an even smaller subset are in > a situation that *permits* them to contribute, either because they have > well-paid jobs and a bit of spare time or they really need a feature added > for their own use. > > > Given that I don?t know what the ?starting? number is (the total number of > JavaFX users) and neither do I know what fraction to apply to each smaller > subset, the end result (the talent pool) is potentially only a handful of > people. > > > I?m simply mentioning this because in every discussion we have here > regarding innovation, community participation or plans for new features, it > looks like the same group of people get involved - and it?s not exactly a > ?crowd?. > > > Does this mean that we don?t have a ?critical mass? or is it possible that > there are lots and lots of ?observers? or ?lurkers? out there just waiting > until all the hard work of setting-up the physical and formal > infrastructure to enable community contribution has been finalised before > they?ll put their hands up? > > > Maybe we could take a poll to see how many members of the community would > be willing AND able to contribute, knowing that they may not necessarily > end up working on features they are interested in AND who are prepared for > their contribution itself & the value it adds to JavaFX to be their only > tangible reward? > > > On 6 Feb 2018, at 11:23, Stephen Desofi wrote: > > > Hi Johan, > > > I read the article you linked to ( > http://www.tomitribe.com/blog/2013/11/feed-the-fish/) and it raises some > very good points indeed. > > > I also spent a little time thinking over your list of interests: > > * more alignment with mobile > > * a clean and lean low-level rendering pipeline API that would allow easier > > plugability with upcoming low-level rendering systems > > * extensions for Chart API > > > Those would be high on my list as well, but there is something else I'd > like to throw into the equation. > > > If somebody can contribute money to fund the development of their > wishlist, fine, that's the easy part, but asking people to contribute time > is a bit more complicated. For example, I may want "more alignment with > mobile", but I may be better qualified to contribute "extensions for the > Chart API" even though that isn't my primary motivator. > > > Often the reason we want something is because we haven't the skills to do > it ourself, but we have skills to do other things. How can situations such > as this be factored into the equation? It seems like we need a way to > "trade". > > > Steve > > > > > Sent from iCloud > > > On Feb 05, 2018, at 12:07 PM, Johan Vos wrote: > > > In order to separate the "What" from the "How" (discussed in another > > thread), I would like to start a discussion about what people think should > > be considered for future JavaFX work. > > > I'd like to start with what I think is an important note on the context. > > If I want feature X in JavaFX, I ask myself two questions: > > 1. Do I want to contribute time and do it (at least for a large part) > > myself? > > 2. Do I want to spend money on it? > > > If that sounds too economic or commercial, I recommend reading the > > excellent blog entry by David Blevins about funding Java EE development > > (more than 4 years old and still very relevant): > > http://www.tomitribe.com/blog/2013/11/feed-the-fish/ > > > Actually, this is a model we've been using at Gluon for a number of > > customers. When people ask us about a specific feature, we ask if they are > > willing to pay us for the development, AND if they are ok with us donating > > it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX, > > JavaFXports, Gluon Charm Down, Gluon Maps,...). > > As a consequence, the features we are working on are all relevant to (at > > least a part of) the industry. Some companies doubt there is business value > > in JavaFX, we prove the opposite while making the Open Source community > > better. > > > I think by now it should be clear to all that there is no free lunch > > (anymore). If your business depends on a feature being added to JavaFX, how > > much (time/money) are you willing to contribute? If the answer is > > "nothing", you can still hope that others want to do it, and in many cases > > that will eventually happen -- but you don't control the timeline. > > > This principle is a bit a simplification though. In many practical cases, > > people want to have feature X and are willing to contribute "something" > > (e.g. they want to work on it in spare-time, or fund 20% of a developer) > > but not enough to do everything. > > I think in this case it's a matter of gathering enough interest in this > > community. Once enough developers are interested in that same feature, and > > agree to spend resources on it, the burden can be shared. Having a sandbox > > repositories with forks will make this easier. > > > Areas that I personally want to see on the roadmap: > > * more alignment with mobile > > * a clean and lean low-level rendering pipeline API that would allow easier > > plugability with upcoming low-level rendering systems > > * extensions for Chart API > > > - Johan > > > From bourges.laurent at gmail.com Wed Feb 7 08:08:10 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 7 Feb 2018 09:08:10 +0100 Subject: More community participation in JavaFX In-Reply-To: References: <5A786D32.6050600@oracle.com> <5A7A6188.2090608@oracle.com> <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> Message-ID: Hi folks, Please respect the 2 threads with different scopes: - this one on how to simplify external contributions (infrastructure, review policies...) - the other one on javafx features... Please stay in the scope & being constructive... I personally improved the prism shape rasterizer (marlinfx @ github) on my own time... integrated in jfx9+ as it is its real place (javafx.graphics module). I totally agree Jonathan & Johan that new features should be first developped externally in third party libraries... and could be merged in JavaFX core if it is worthful or required (low level API or module encapsulation issue ?). Finally I can help on graphics performance so we could create a small perf team. Moreover, funding FOS projects need clients or creating sponsorship programs (grant, awards) but it is another challenge. Cheers, Laurent Le 7 f?vr. 2018 8:38 AM, "John-Val Rose" a ?crit : > Jonathan - why do you *cough* at ideas like more complex controls and > docking frameworks? > > I think that a docking framework especially would be a great addition to > JavaFX. > > Am I missing something? > > > On 7 Feb 2018, at 18:16, Jonathan Giles > wrote: > > > > Obviously everyone is at ControlsFX instead ;-) > > > > Part of the drop I would suggest is simply that many of the itches people > > want to scratch are now scratched. Alternatively, the remaining itches > are > > either in more complex controls (*cough* docking frameworks *cough*) or > in > > areas beneath the controls APIs - performance, webview, etc - which are > > more challenging and require greater levels of dedication. > > > > However, more generally, your point is well made - contribution to JavaFX > > does not need to be synonymous with contribution to OpenJFX. People who > > find the challenges of the current OpenJFX requirements too great should > be > > encouraged to involve themselves in projects such as JFXtras, etc. > > > > -- Jonathan > > > >> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: > >> > >> Many years ago I had a discussion with Jonathan Giles about if the > things > >> that were being made in JFXtras would eventually become part of the > JavaFX > >> core. In the end I decided that, for me personally, I could do the > things I > >> wanted to perfectly in a separate project. The rigid structure that > >> Java(FX) has to adhere to, would be a big downside. > >> > >> What I want to say with that is that all the external projects are also > >> contributions to JavaFX. It does not matter whether for example a > control > >> is part of the core distribution or of a side project; it is just > another > >> module users can add to the mix. > >> > >> So reflecting back I still stand by that choice. But having a few more > >> people in the project (just like in JavaFX ;-) ) would be nice, but > OTOH it > >> forces me to deal with (and learn about) annoying stuff like Gradle > build > >> scripts and Java 9 migration. But because of that progress is not as > fast > >> as I would like it to be. Could it be that there is a decline in people > >> willing to work for open source projects? Or is it just that this tech, > >> JavaFX, is no longer appealing? > >> > >> Tom > >> > >> > >> > > Obviously everyone is at ControlsFX instead ;-) > > > > Part of the drop I would suggest is simply that many of the itches people > > want to scratch are now scratched. Alternatively, the remaining itches > are > > either in more complex controls (*cough* docking frameworks *cough*) or > in > > areas beneath the controls APIs - performance, webview, etc - which are > > more challenging and require greater levels of dedication. > > > > However, more generally, your point is well made - contribution to JavaFX > > does not need to be synonymous with contribution to OpenJFX. People who > > find the challenges of the current OpenJFX requirements too great should > be > > encouraged to involve themselves in projects such as JFXtras, etc. > > > > -- Jonathan > > > >> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: > >> > >> Many years ago I had a discussion with Jonathan Giles about if the > things > >> that were being made in JFXtras would eventually become part of the > JavaFX > >> core. In the end I decided that, for me personally, I could do the > things I > >> wanted to perfectly in a separate project. The rigid structure that > >> Java(FX) has to adhere to, would be a big downside. > >> > >> What I want to say with that is that all the external projects are also > >> contributions to JavaFX. It does not matter whether for example a > control > >> is part of the core distribution or of a side project; it is just > another > >> module users can add to the mix. > >> > >> So reflecting back I still stand by that choice. But having a few more > >> people in the project (just like in JavaFX ;-) ) would be nice, but > OTOH it > >> forces me to deal with (and learn about) annoying stuff like Gradle > build > >> scripts and Java 9 migration. But because of that progress is not as > fast > >> as I would like it to be. Could it be that there is a decline in people > >> willing to work for open source projects? Or is it just that this tech, > >> JavaFX, is no longer appealing? > >> > >> Tom > >> > >> > >> > >>> On 7-2-2018 03:16, Kevin Rushforth wrote: > >>> > >>> I would recommend against having a separate issue tracker or mailing > list > >>> associated with the sandbox. That will create more confusion than any > >>> benefit you might have. > >>> > >>> -- Kevin > >>> > >>> > >>> Nir Lisker wrote: > >>> > >>>> Another thing to be careful about with the sandbox/staging idea is the > >>>> confusion that will arise with duplication. There will be 2 issue > trackers > >>>> (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and > maybe 2 > >>>> discussion lists. For those "in the know" this will be a simple > matter, but > >>>> for a potential contributor this can be a gamebreaker if not handled > >>>> appropriately. > >>>> > >>>> Dalibor Topic's suggestion of contacting other mirrors can be > >>>> instrumental in solving these problems. > >>>> > >>>> - Nir > >>>> > >>>> On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth < > >>>> kevin.rushforth at oracle.com > > wrote: > >>>> > >>>> Yes, this sounds like a good step in the right direction. This > >>>> would give anyone (with a signed OCA) the ability to create their > >>>> own branch, commit changes to it, submit a PR, etc. > >>>> > >>>> I presume there will be a branch that is an exact mirror of the > >>>> jfx-dev repo on OpenJDK in addition to the development branch in > >>>> the sandbox? > >>>> > >>>> The only thing to consider is whether it should be Committers or > >>>> Reviewers that have rights to merge into the sandbox development > >>>> branch. There are pros / cons of each. I'd probably lean towards > >>>> having it be Committers, with the idea that a Committer needs to > >>>> sponsor the patch anyway and would then be able to "take it the > >>>> rest of the way". The only downside I see is that you could end up > >>>> with a few patches that get accepted into the sandbox dev branch, > >>>> but never make it to the upstream jfx-dev repo (or not without > >>>> significant change). I doubt this will be a big problem in > practice. > >>>> > >>>> Either way, this could also provide a good alternative to webrev > >>>> when reviewing the final changes. > >>>> > >>>> -- Kevin > >>>> > >>>> > >>>> > >>>> Johan Vos wrote: > >>>> > >>>> Hi Michael, > >>>> > >>>> This proposal is very much in line with my thinking as well. > >>>> The problem is not that we don't have a github clone of > >>>> OpenJFX. We have a > >>>> number of them (e.g. I created > >>>> https://github.com/javafxports/jfx-dev > >>>> some > >>>> months ago). We just need a single one that is updated > >>>> constantly from > >>>> mainstream, and standardize on that. Let's call that "sandbox" > >>>> (I would be > >>>> ok with staging as well, but sandbox is imho more inviting to > >>>> people who > >>>> want to try something drastic, e.g. support for Vulkan) > >>>> > >>>> The main issue is how to get contributions, review them, and > >>>> eventually > >>>> send them upstream. > >>>> > >>>> The PR review process is extremely important. If we lower that > >>>> bar, we > >>>> loose quality. If the bar is too high, great PR's won't be > >>>> accepted > >>>> upstream as there is not enough review time to review it. > >>>> > >>>> I agree giving the current OpenJFX committers merge rights for > >>>> the > >>>> "sandbox" repository makes sense. Once a public contribution > >>>> is merged by > >>>> one of those committers, that same committer can send it > >>>> upstream to the > >>>> existing OpenJFX repository. Additional checks will be > >>>> performed there, > >>>> mainly in order to make sure the overall "Feel of Java" is > >>>> preserved. To > >>>> that purpose, it would help to have a closer alignment with > >>>> the OpenJDK > >>>> community. > >>>> > >>>> We have to be aware that this will increase the workload of > >>>> the current > >>>> committers and reviewers. That is the price we pay for > >>>> standardization. > >>>> Rather than everyone creating his own forks of a UI framework > >>>> in Java, we > >>>> invest a lot in creating a single, generally agreed one. > >>>> > >>>> So in summary, I'm +1 on a 2-phase approach: "open" commits > >>>> allowed in > >>>> staging. OpenJFX committers accept PR's (if they are of good > >>>> quality) and > >>>> prepare upstream commits for OpenJFX. We hope there will be > more > >>>> contributors who become committers and reviewers in the medium > >>>> term. > >>>> > >>>> - Johan > >>>> > >>>> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen > >>>> > wrote: > >>>> > >>>> > >>>> Those are great questions, and I think with > >>>> Kevin/Oracle/other OpenJFX devs > >>>> help we > >>>> can figure something out. > >>>> > >>>> My thinking is that the PR would be reviewed by basically > >>>> anyone who has > >>>> free time. > >>>> I think that, at first, only OpenJFX committers will be > >>>> able to merge PRs. > >>>> They would > >>>> do the final review/merge to the staging repo after it has > >>>> been reviewed by > >>>> the "wider audience" > >>>> which includes people without commit rights (people like > >>>> us). Then, as this > >>>> thing evolves, > >>>> based on the pool of people who are contributing both pull > >>>> requests and PR > >>>> reviews, > >>>> the committers will be able to grant commit privileges to > >>>> some people in > >>>> that pool. > >>>> > >>>> I can't think of any way that would make it so the changes > >>>> are as likely to > >>>> be > >>>> merged upstream as possible other than having the current > >>>> OpenJFX > >>>> committers paving the > >>>> way. Hopefully this vision is aligned with Kevin's and > >>>> hopefully these > >>>> concrete details > >>>> can be worked out. > >>>> > >>>> Regards, > >>>> Michael > >>>> > >>>> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker > >>>> > wrote: > >>>> > >>>> > >>>> So if a community ran GitHub is used for staging, who > >>>> will approve PRs > >>>> > >>>> for > >>>> > >>>> the code and the Wiki of the GitHub repo? > >>>> > >>>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen > >>>> > > >>>> wrote: > >>>> > >>>> > >>>> Great points, Nir. We share the same hopes. I just > >>>> wanted to piggy-back > >>>> on the > >>>> wiki thing: > >>>> > >>>> " * The Wiki could be open sourced as well (like > >>>> other Wikis). I could > >>>> definitely update a page or 2 there and so would > >>>> other developers as > >>>> > >>>> they > >>>> > >>>> gain knowledge. I don't know yet how permissions > >>>> for that should be > >>>> handled." > >>>> > >>>> This is another thing that we could use the GitHub > >>>> staging repository > >>>> > >>>> for. > >>>> > >>>> The staging repository could have a wiki (projects > >>>> on GitHub can have > >>>> > >>>> one) > >>>> > >>>> that is editable by all, and then maybe once a > >>>> month or so someone with > >>>> permissions > >>>> to edit to official wiki can sync with the new, > >>>> reviewed changes (the > >>>> once-a-month > >>>> time constraint is very flexible). > >>>> > >>>> I am just trying to explain how the GitHub > >>>> repository "one-way mirror" > >>>> (potentially linked > >>>> with/managed by Adopt an OpenJDK) can act as a > >>>> staging ground for all > >>>> kinds of contributions to > >>>> OpenJFX. > >>>> > >>>> By the way, I am trying to cleanup the groundwork > >>>> I did on getting > >>>> Appveyor builds to > >>>> run for openjfx, if indeed it is decided to setup > >>>> such a staging > >>>> repository. You can > >>>> see my efforts here: https://raw.githubusercontent > . > >>>> > >>>> > >>>> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057 > >>>> /appveyor.yml > >>>> > >>>> If the GitHub repository was setup, changes such > >>>> as these to add CI > >>>> infrastructure would > >>>> never be adopted by upstream OpenJFX, but would > >>>> allow for developer's to > >>>> get good > >>>> feedback on test results for all supported > >>>> platforms when they open a > >>>> > >>>> PR. > >>>> > >>>> Merging a PR > >>>> on the public GitHub repository means, in my > >>>> opinion, that it is ready > >>>> > >>>> to > >>>> > >>>> be opened as > >>>> an upstream bug/feature request. Automating the > >>>> process with patch sets, > >>>> webrevs, formatting/lint > >>>> results, etc. would be the most ideal situation > >>>> and I would be happy to > >>>> contribute to these > >>>> efforts. > >>>> > >>>> Regards, > >>>> > >>>> Michael Ennen > >>>> > >>>> > >>>> > >>>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker > >>>> > > >>>> wrote: > >>>> > >>>> > >>>> Hello, > >>>> > >>>> As someone who has recently made the climb and > >>>> managed to build OpenJFX > >>>> with OpenJDK on Win 10 I might have some > >>>> relevant input. > >>>> > >>>> --- Building OpenJFX --- > >>>> > >>>> * With the recently updated instructions on > >>>> the Wiki, building OpenJFX > >>>> > >>>> is > >>>> > >>>> not that hard. Having to build OpenJDK for > >>>> that was a real headache > >>>> because > >>>> their instructions and build tools are not up > >>>> to date ( > >>>> https://bugs.openjdk.java.net/browse/JDK-8194645 > >>>> ). > >>>> * The above doesn't mean that the process > >>>> shouldn't be made easier. > >>>> Ideally, it would be the as easy as working on > >>>> most open source > >>>> > >>>> projects > >>>> > >>>> on > >>>> Github (not advocating git over hg): clone > >>>> into the IDE and start > >>>> working; > >>>> when a fix is ready, submit a PR. Don't know > >>>> if it's technically > >>>> > >>>> possible > >>>> > >>>> in this case, but it's a target. > >>>> * The repository needs a good cleanup before > >>>> contributors start > >>>> > >>>> cloning ( > >>>> > >>>> bugs.openjdk.java.net/browse/JDK-8196198 > >>>> ). > >>>> > >>>> --- Working on OpenJFX --- > >>>> > >>>> * It should be clear which tests need to run > >>>> for a specific patch. > >>>> Changes > >>>> can be made anywhere from the documentation > >>>> level to native code level > >>>> and > >>>> there's no reason to run the same tests for > >>>> all of these. If the > >>>> > >>>> process > >>>> > >>>> can be automate it's even better. > >>>> * The Webrev tool seems archaic to me (and > >>>> part of its output is broken > >>>> as > >>>> far as I could tell). An IDE can create diff > >>>> patches with a couple of > >>>> clicks. > >>>> * The Jcheck tool seems archaic to me. It > >>>> should be ported to IDE > >>>> formatters which are to be distributed with > >>>> the source. No reason to > >>>> > >>>> run > >>>> > >>>> a > >>>> tool that tells me which whitespaces I need to > >>>> go back and change when > >>>> something like Ctrl+Shift+F in an IDE finishes > >>>> the job. > >>>> > >>>> --- Wiki --- > >>>> > >>>> * The Wiki could be open sourced as well (like > >>>> other Wikis). I could > >>>> definitely update a page or 2 there and so > >>>> would other developers as > >>>> > >>>> they > >>>> > >>>> gain knowledge. I don't know yet how > >>>> permissions for that should be > >>>> handled. > >>>> * Code conventions should be clearly listed. > >>>> * Separate sections with instructions should > >>>> be made for: (1) cloning > >>>> > >>>> and > >>>> > >>>> building, (2) modifying, (3) running tests, > >>>> (4) submitting, and (5) > >>>> reviewing. > >>>> * Old sections should be cleaned up (I don't > >>>> think Discussions is > >>>> > >>>> useful > >>>> > >>>> anymore). > >>>> > >>>> --- Review policy --- > >>>> > >>>> * I have no experience with review policies or > >>>> project roles so I can't > >>>> help here much (maybe after a discussion > starts). > >>>> * One thing I do know is that reviewers should > >>>> be extremely > >>>> knowledgeable, > >>>> which means that there aren't many qualified. > >>>> Because of this, if it > >>>> becomes "too" easy to contribute to OpenJFX, > >>>> careful measures need to > >>>> > >>>> be > >>>> > >>>> taken as to not to swamp the few reviewers > >>>> with many patches (though > >>>> > >>>> some > >>>> > >>>> would say this is an ideal situation). Some > >>>> sort of review queue might > >>>> help > >>>> with organization instead of the current email > >>>> system. I have no > >>>> > >>>> concrete > >>>> > >>>> solution for this. > >>>> > >>>> - Nir > >>>> > >>>> > >>>> Message: 1 > >>>> > >>>> Date: Thu, 01 Feb 2018 15:26:24 -0800 > >>>> From: Kevin Rushforth > >>>> >>>> > > >>>> To: "openjfx-dev at openjdk.java.net > >>>> " > >>>> >>>> > > >>>> Subject: More community participation in > >>>> JavaFX > >>>> Message-ID: <5A73A220.7030706 at oracle.com > >>>> > > >>>> Content-Type: text/plain; > >>>> charset=windows-1252; format=flowed > >>>> > >>>> To: OpenJFX Developers > >>>> > >>>> We are looking to grow the community of > >>>> contributors to the OpenJFX > >>>> project, especially serious contributors > >>>> who will stick around long > >>>> enough to become reviewers, to help us > >>>> keep the platform vibrant. To > >>>> this end we are looking at ways to > >>>> encourage more participation and > >>>> > >>>> make > >>>> > >>>> it easier for interested folks to > contribute. > >>>> > >>>> We are specifically looking to discuss > >>>> ideas around the following > >>>> > >>>> areas: > >>>> > >>>> * Easing barriers to contribution (e.g., > >>>> making JavaFX easier to > >>>> > >>>> build, > >>>> > >>>> better documentation, making it easier to > >>>> test changes) > >>>> > >>>> * Code review policies > >>>> > >>>> * API / feature review policies > >>>> > >>>> * Code review tools (we currently use > >>>> webrev, but that isn't set in > >>>> > >>>> stone) > >>>> > >>>> To keep this thread productive, the > >>>> following are explicitly out of > >>>> > >>>> scope: > >>>> > >>>> * Discussion of specific features or bugs > >>>> that you would like to > >>>> implement (or wish someone else would) > >>>> > >>>> * Discussion about platform support > >>>> > >>>> * Discussion about version control systems > >>>> (e.g., hg versus git), > >>>> hosting of the OpenJFX repos and bug > >>>> database (e.g., OpenJDK versus > >>>> github), etc...at least for now. We are > >>>> aware of the potential > >>>> > >>>> benefits > >>>> > >>>> of such changes, but we'd like to focus > >>>> our efforts on > >>>> > >>>> higher-leverage > >>>> > >>>> things we can do in the short term. > >>>> > >>>> * Discussion about the requirement of a > >>>> signed OCA to become a > >>>> > >>>> contributor > >>>> > >>>> * Off-topic or tangential commentary about > >>>> OpenJFX that isn't > >>>> > >>>> directly > >>>> > >>>> related to the topic at hand > >>>> > >>>> > >>>> As a starting point for discussion, here > >>>> are some areas I think need > >>>> improvement; I'm sure there are others: > >>>> > >>>> I. Helping contributors get started > >>>> > >>>> It isn?t as easy to get started with > >>>> OpenJFX as it should be. We want > >>>> > >>>> to > >>>> > >>>> make it easier for potential OpenJFX > >>>> contributors to get started. > >>>> > >>>> Here > >>>> > >>>> are some ideas that I think might help: > >>>> > >>>> * Improve the build instructions / Wiki (I > >>>> made a first start, but > >>>> > >>>> there > >>>> > >>>> is much more to be done) > >>>> > >>>> * Make the build itself more resilient > >>>> where possible, and provide > >>>> better error messages, specifically when > >>>> dealing with native > >>>> > >>>> compilers > >>>> > >>>> and libraries > >>>> > >>>> * Add an option to skip building all > >>>> native code and use prebuilt > >>>> binaries (like we do already for media and > >>>> webkit); this is tracked > >>>> > >>>> by > >>>> > >>>> JDK-8092279, but it hasn?t been looked at > >>>> recently > >>>> > >>>> * Make it easier to build / test your > >>>> local OpenJFX build using an > >>>> OpenJDK build (currently the only way to > >>>> do this is to build OpenJDK > >>>> locally, after using configure to point to > >>>> your just-built javafx.* > >>>> modules). > >>>> > >>>> * Provide step-by-step instructions for > >>>> how to make a contribution, > >>>> including testing requirements; a lot of > >>>> the pieces are there, but > >>>> > >>>> are > >>>> > >>>> out of date or scattered in several > >>>> places. As part of this, we could > >>>> have a section on how to contribute docs, > >>>> samples or tests, since > >>>> > >>>> that > >>>> > >>>> is often a good place to start. > >>>> > >>>> * Provide a sandbox environment where > >>>> contributors can discuss and > >>>> > >>>> test > >>>> > >>>> ideas. For example, an OpenJFX mirror on > >>>> github, potentially > >>>> > >>>> connected > >>>> > >>>> to AdoptOpenJDK. > >>>> > >>>> > >>>> II. Code reviews and API reviews > >>>> > >>>> Code reviews are important to maintain > >>>> high-quality contributions, > >>>> > >>>> but > >>>> > >>>> we recognize that not every type of change > >>>> needs the same level of > >>>> review. Without lowering our standards of > >>>> quality, we want to make it > >>>> easier to get low-impact changes (simple > >>>> bug fixes) accepted. > >>>> > >>>> There are three categories of changes, > >>>> each of which might merit a > >>>> different review standard: > >>>> > >>>> 1. Low-impact bug fixes. These are > >>>> typically isolated bug fixes with > >>>> little or no impact beyond fixing the bug > >>>> in question; included in > >>>> > >>>> this > >>>> > >>>> category are test fixes (including new > >>>> tests) doc fixes, and fixes to > >>>> sample applications (including new > samples). > >>>> > >>>> 2. Higher impact bug fixes or RFEs. These > >>>> include changes to the > >>>> implementation that potentially have a > >>>> performance or behavioral > >>>> > >>>> impact, > >>>> > >>>> or are otherwise broad in scope. Some > >>>> larger bug fixes will fall into > >>>> this category, as will fixes in high-risk > >>>> areas (e.g., CSS). > >>>> > >>>> 3. New features / API additions. In > >>>> addition to reviewing the > >>>> implementation, we will need a separate > >>>> approval process for the new > >>>> > >>>> API > >>>> > >>>> / feature (such as the CSR, which is what > >>>> we use now, or a similar > >>>> process). > >>>> > >>>> We take compatibility seriously, so > >>>> anything that adds new API needs > >>>> > >>>> to > >>>> > >>>> be done with an eye towards supporting it > >>>> for at least 10 years. We > >>>> don't want to add new public API without > >>>> that level of commitment. > >>>> > >>>> Every > >>>> > >>>> new feature forecloses on alternate future > >>>> features. Significant > >>>> > >>>> effort > >>>> > >>>> must be taken to think about "if we did > >>>> this, what could it interact > >>>> with in the future?" Also, anything with a > >>>> large potential impact on > >>>> performance or behavioral compatibility > >>>> needs to be looked at > >>>> > >>>> carefully. > >>>> > >>>> Put another way, we want to encourage > >>>> thinking about new features or > >>>> > >>>> new > >>>> > >>>> API in terms of a design / stewardship > >>>> process; to think in terms of > >>>> questions like "what's the right thing for > >>>> JavaFX in the next 10+ > >>>> > >>>> years" > >>>> > >>>> rather than "here's some code that solves > >>>> my problem, please take > >>>> > >>>> it". > >>>> > >>>> As a stake in the ground, I might suggest > >>>> the following: > >>>> > >>>> * All changes need at least one reviewer > >>>> other than the person making > >>>> the change who can evaluate the change for > >>>> correctness and > >>>> > >>>> consistency. > >>>> > >>>> For simple bug fixes, a single reviewer > >>>> may be sufficient. Of course, > >>>> one of our big challenges in all this is: > >>>> "how do we grow more > >>>> reviewers?", by which I mean "how do we > >>>> facilitate getting > >>>> > >>>> contributors > >>>> > >>>> with enough expertise in a given area to > >>>> eventually be able to > >>>> effectively review contributions from > >>>> others?" > >>>> > >>>> * We need clear criteria for the other two > >>>> categories that balance > >>>> process efficiency with the desire to > >>>> maintain compatibility and > >>>> stability. API changes need to be approved > >>>> by a lead. My thought is > >>>> > >>>> to > >>>> > >>>> combine the last two into a single > >>>> category for purposes of reviewing > >>>> the implementation. Anything that affects > >>>> public API or behavioral > >>>> compatibility will require CSR or similar > >>>> approval, over and above > >>>> > >>>> the > >>>> > >>>> implementation review, which seems > >>>> sufficient. > >>>> > >>>> * I recommend that we formalize the > >>>> concept of reviewers, using the > >>>> OpenJDK Reviewer role for the Project. We > >>>> might also consider if we > >>>> > >>>> want > >>>> > >>>> to make any changes to the criteria used > >>>> by the JDK Project for > >>>> > >>>> becoming > >>>> > >>>> an OpenJFX Project Author, Committer, and > >>>> Reviewer. The OpenJDK > >>>> > >>>> bylaws > >>>> > >>>> allow projects a fair degree of latitude > >>>> to define these criteria, so > >>>> > >>>> we > >>>> > >>>> might consider making some modifications. > >>>> For example, we might make > >>>> > >>>> it > >>>> > >>>> somewhat easier for a Contributor to > >>>> become an Author, or for a > >>>> Committer to become a Reviewer. I have > >>>> some thoughts on this, but > >>>> > >>>> want > >>>> > >>>> to hear from others first. > >>>> > >>>> > >>>> I look forward to feedback on this > >>>> proposal, and hope it will spark a > >>>> productive discussion. > >>>> > >>>> -- Kevin Rushforth, OpenJFX Project Lead > >>>> > >>>> > >>>> > >>>> > >>>> > >> > From tbee at tbee.org Wed Feb 7 08:25:20 2018 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 7 Feb 2018 09:25:20 +0100 Subject: More community participation in JavaFX In-Reply-To: References: <5A786D32.6050600@oracle.com> <5A7A6188.2090608@oracle.com> <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> Message-ID: <90b3cb55e88375f048b1c4eb8f883d8d.squirrel@54.sslprotected.nl> Well, I believe he was hinting at that a docking framework is considered more complex, there was no negative sentiment in that. Although I do not think a docking framework is that complex, but maybe I'm wrong. And yes, ALMOST everyone is at ControlFX ;-) > Jonathan - why do you *cough* at ideas like more complex controls and > docking frameworks? > > I think that a docking framework especially would be a great addition to > JavaFX. > > Am I missing something? > >> On 7 Feb 2018, at 18:16, Jonathan Giles >> wrote: >> >> Obviously everyone is at ControlsFX instead ;-) >> >> Part of the drop I would suggest is simply that many of the itches >> people >> want to scratch are now scratched. Alternatively, the remaining itches >> are >> either in more complex controls (*cough* docking frameworks *cough*) or >> in >> areas beneath the controls APIs - performance, webview, etc - which are >> more challenging and require greater levels of dedication. >> >> However, more generally, your point is well made - contribution to >> JavaFX >> does not need to be synonymous with contribution to OpenJFX. People who >> find the challenges of the current OpenJFX requirements too great should >> be >> encouraged to involve themselves in projects such as JFXtras, etc. >> >> -- Jonathan >> >>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >>> >>> Many years ago I had a discussion with Jonathan Giles about if the >>> things >>> that were being made in JFXtras would eventually become part of the >>> JavaFX >>> core. In the end I decided that, for me personally, I could do the >>> things I >>> wanted to perfectly in a separate project. The rigid structure that >>> Java(FX) has to adhere to, would be a big downside. >>> >>> What I want to say with that is that all the external projects are also >>> contributions to JavaFX. It does not matter whether for example a >>> control >>> is part of the core distribution or of a side project; it is just >>> another >>> module users can add to the mix. >>> >>> So reflecting back I still stand by that choice. But having a few more >>> people in the project (just like in JavaFX ;-) ) would be nice, but >>> OTOH it >>> forces me to deal with (and learn about) annoying stuff like Gradle >>> build >>> scripts and Java 9 migration. But because of that progress is not as >>> fast >>> as I would like it to be. Could it be that there is a decline in people >>> willing to work for open source projects? Or is it just that this tech, >>> JavaFX, is no longer appealing? >>> >>> Tom >>> >>> >>> >> Obviously everyone is at ControlsFX instead ;-) >> >> Part of the drop I would suggest is simply that many of the itches >> people >> want to scratch are now scratched. Alternatively, the remaining itches >> are >> either in more complex controls (*cough* docking frameworks *cough*) or >> in >> areas beneath the controls APIs - performance, webview, etc - which are >> more challenging and require greater levels of dedication. >> >> However, more generally, your point is well made - contribution to >> JavaFX >> does not need to be synonymous with contribution to OpenJFX. People who >> find the challenges of the current OpenJFX requirements too great should >> be >> encouraged to involve themselves in projects such as JFXtras, etc. >> >> -- Jonathan >> >>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >>> >>> Many years ago I had a discussion with Jonathan Giles about if the >>> things >>> that were being made in JFXtras would eventually become part of the >>> JavaFX >>> core. In the end I decided that, for me personally, I could do the >>> things I >>> wanted to perfectly in a separate project. The rigid structure that >>> Java(FX) has to adhere to, would be a big downside. >>> >>> What I want to say with that is that all the external projects are also >>> contributions to JavaFX. It does not matter whether for example a >>> control >>> is part of the core distribution or of a side project; it is just >>> another >>> module users can add to the mix. >>> >>> So reflecting back I still stand by that choice. But having a few more >>> people in the project (just like in JavaFX ;-) ) would be nice, but >>> OTOH it >>> forces me to deal with (and learn about) annoying stuff like Gradle >>> build >>> scripts and Java 9 migration. But because of that progress is not as >>> fast >>> as I would like it to be. Could it be that there is a decline in people >>> willing to work for open source projects? Or is it just that this tech, >>> JavaFX, is no longer appealing? >>> >>> Tom >>> >>> >>> >>>> On 7-2-2018 03:16, Kevin Rushforth wrote: >>>> >>>> I would recommend against having a separate issue tracker or mailing >>>> list >>>> associated with the sandbox. That will create more confusion than any >>>> benefit you might have. >>>> >>>> -- Kevin >>>> >>>> >>>> Nir Lisker wrote: >>>> >>>>> Another thing to be careful about with the sandbox/staging idea is >>>>> the >>>>> confusion that will arise with duplication. There will be 2 issue >>>>> trackers >>>>> (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and >>>>> maybe 2 >>>>> discussion lists. For those "in the know" this will be a simple >>>>> matter, but >>>>> for a potential contributor this can be a gamebreaker if not handled >>>>> appropriately. >>>>> >>>>> Dalibor Topic's suggestion of contacting other mirrors can be >>>>> instrumental in solving these problems. >>>>> >>>>> - Nir >>>>> >>>>> On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com > >>>>> wrote: >>>>> >>>>> Yes, this sounds like a good step in the right direction. This >>>>> would give anyone (with a signed OCA) the ability to create their >>>>> own branch, commit changes to it, submit a PR, etc. >>>>> >>>>> I presume there will be a branch that is an exact mirror of the >>>>> jfx-dev repo on OpenJDK in addition to the development branch in >>>>> the sandbox? >>>>> >>>>> The only thing to consider is whether it should be Committers or >>>>> Reviewers that have rights to merge into the sandbox development >>>>> branch. There are pros / cons of each. I'd probably lean towards >>>>> having it be Committers, with the idea that a Committer needs to >>>>> sponsor the patch anyway and would then be able to "take it the >>>>> rest of the way". The only downside I see is that you could end up >>>>> with a few patches that get accepted into the sandbox dev branch, >>>>> but never make it to the upstream jfx-dev repo (or not without >>>>> significant change). I doubt this will be a big problem in >>>>> practice. >>>>> >>>>> Either way, this could also provide a good alternative to webrev >>>>> when reviewing the final changes. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Johan Vos wrote: >>>>> >>>>> Hi Michael, >>>>> >>>>> This proposal is very much in line with my thinking as well. >>>>> The problem is not that we don't have a github clone of >>>>> OpenJFX. We have a >>>>> number of them (e.g. I created >>>>> https://github.com/javafxports/jfx-dev >>>>> some >>>>> months ago). We just need a single one that is updated >>>>> constantly from >>>>> mainstream, and standardize on that. Let's call that "sandbox" >>>>> (I would be >>>>> ok with staging as well, but sandbox is imho more inviting to >>>>> people who >>>>> want to try something drastic, e.g. support for Vulkan) >>>>> >>>>> The main issue is how to get contributions, review them, and >>>>> eventually >>>>> send them upstream. >>>>> >>>>> The PR review process is extremely important. If we lower that >>>>> bar, we >>>>> loose quality. If the bar is too high, great PR's won't be >>>>> accepted >>>>> upstream as there is not enough review time to review it. >>>>> >>>>> I agree giving the current OpenJFX committers merge rights for >>>>> the >>>>> "sandbox" repository makes sense. Once a public contribution >>>>> is merged by >>>>> one of those committers, that same committer can send it >>>>> upstream to the >>>>> existing OpenJFX repository. Additional checks will be >>>>> performed there, >>>>> mainly in order to make sure the overall "Feel of Java" is >>>>> preserved. To >>>>> that purpose, it would help to have a closer alignment with >>>>> the OpenJDK >>>>> community. >>>>> >>>>> We have to be aware that this will increase the workload of >>>>> the current >>>>> committers and reviewers. That is the price we pay for >>>>> standardization. >>>>> Rather than everyone creating his own forks of a UI framework >>>>> in Java, we >>>>> invest a lot in creating a single, generally agreed one. >>>>> >>>>> So in summary, I'm +1 on a 2-phase approach: "open" commits >>>>> allowed in >>>>> staging. OpenJFX committers accept PR's (if they are of good >>>>> quality) and >>>>> prepare upstream commits for OpenJFX. We hope there will be >>>>> more >>>>> contributors who become committers and reviewers in the medium >>>>> term. >>>>> >>>>> - Johan >>>>> >>>>> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen >>>>> > wrote: >>>>> >>>>> >>>>> Those are great questions, and I think with >>>>> Kevin/Oracle/other OpenJFX devs >>>>> help we >>>>> can figure something out. >>>>> >>>>> My thinking is that the PR would be reviewed by basically >>>>> anyone who has >>>>> free time. >>>>> I think that, at first, only OpenJFX committers will be >>>>> able to merge PRs. >>>>> They would >>>>> do the final review/merge to the staging repo after it has >>>>> been reviewed by >>>>> the "wider audience" >>>>> which includes people without commit rights (people like >>>>> us). Then, as this >>>>> thing evolves, >>>>> based on the pool of people who are contributing both pull >>>>> requests and PR >>>>> reviews, >>>>> the committers will be able to grant commit privileges to >>>>> some people in >>>>> that pool. >>>>> >>>>> I can't think of any way that would make it so the changes >>>>> are as likely to >>>>> be >>>>> merged upstream as possible other than having the current >>>>> OpenJFX >>>>> committers paving the >>>>> way. Hopefully this vision is aligned with Kevin's and >>>>> hopefully these >>>>> concrete details >>>>> can be worked out. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker >>>>> > wrote: >>>>> >>>>> >>>>> So if a community ran GitHub is used for staging, who >>>>> will approve PRs >>>>> >>>>> for >>>>> >>>>> the code and the Wiki of the GitHub repo? >>>>> >>>>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen >>>>> > >>>>> wrote: >>>>> >>>>> >>>>> Great points, Nir. We share the same hopes. I just >>>>> wanted to piggy-back >>>>> on the >>>>> wiki thing: >>>>> >>>>> " * The Wiki could be open sourced as well (like >>>>> other Wikis). I could >>>>> definitely update a page or 2 there and so would >>>>> other developers as >>>>> >>>>> they >>>>> >>>>> gain knowledge. I don't know yet how permissions >>>>> for that should be >>>>> handled." >>>>> >>>>> This is another thing that we could use the GitHub >>>>> staging repository >>>>> >>>>> for. >>>>> >>>>> The staging repository could have a wiki (projects >>>>> on GitHub can have >>>>> >>>>> one) >>>>> >>>>> that is editable by all, and then maybe once a >>>>> month or so someone with >>>>> permissions >>>>> to edit to official wiki can sync with the new, >>>>> reviewed changes (the >>>>> once-a-month >>>>> time constraint is very flexible). >>>>> >>>>> I am just trying to explain how the GitHub >>>>> repository "one-way mirror" >>>>> (potentially linked >>>>> with/managed by Adopt an OpenJDK) can act as a >>>>> staging ground for all >>>>> kinds of contributions to >>>>> OpenJFX. >>>>> >>>>> By the way, I am trying to cleanup the groundwork >>>>> I did on getting >>>>> Appveyor builds to >>>>> run for openjfx, if indeed it is decided to setup >>>>> such a staging >>>>> repository. You can >>>>> see my efforts here: >>>>> https://raw.githubusercontent. >>>>> >>>>> >>>>> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057 >>>>> /appveyor.yml >>>>> >>>>> If the GitHub repository was setup, changes such >>>>> as these to add CI >>>>> infrastructure would >>>>> never be adopted by upstream OpenJFX, but would >>>>> allow for developer's to >>>>> get good >>>>> feedback on test results for all supported >>>>> platforms when they open a >>>>> >>>>> PR. >>>>> >>>>> Merging a PR >>>>> on the public GitHub repository means, in my >>>>> opinion, that it is ready >>>>> >>>>> to >>>>> >>>>> be opened as >>>>> an upstream bug/feature request. Automating the >>>>> process with patch sets, >>>>> webrevs, formatting/lint >>>>> results, etc. would be the most ideal situation >>>>> and I would be happy to >>>>> contribute to these >>>>> efforts. >>>>> >>>>> Regards, >>>>> >>>>> Michael Ennen >>>>> >>>>> >>>>> >>>>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker >>>>> > >>>>> wrote: >>>>> >>>>> >>>>> Hello, >>>>> >>>>> As someone who has recently made the climb and >>>>> managed to build OpenJFX >>>>> with OpenJDK on Win 10 I might have some >>>>> relevant input. >>>>> >>>>> --- Building OpenJFX --- >>>>> >>>>> * With the recently updated instructions on >>>>> the Wiki, building OpenJFX >>>>> >>>>> is >>>>> >>>>> not that hard. Having to build OpenJDK for >>>>> that was a real headache >>>>> because >>>>> their instructions and build tools are not up >>>>> to date ( >>>>> https://bugs.openjdk.java.net/browse/JDK-8194645 >>>>> ). >>>>> * The above doesn't mean that the process >>>>> shouldn't be made easier. >>>>> Ideally, it would be the as easy as working on >>>>> most open source >>>>> >>>>> projects >>>>> >>>>> on >>>>> Github (not advocating git over hg): clone >>>>> into the IDE and start >>>>> working; >>>>> when a fix is ready, submit a PR. Don't know >>>>> if it's technically >>>>> >>>>> possible >>>>> >>>>> in this case, but it's a target. >>>>> * The repository needs a good cleanup before >>>>> contributors start >>>>> >>>>> cloning ( >>>>> >>>>> bugs.openjdk.java.net/browse/JDK-8196198 >>>>> ). >>>>> >>>>> --- Working on OpenJFX --- >>>>> >>>>> * It should be clear which tests need to run >>>>> for a specific patch. >>>>> Changes >>>>> can be made anywhere from the documentation >>>>> level to native code level >>>>> and >>>>> there's no reason to run the same tests for >>>>> all of these. If the >>>>> >>>>> process >>>>> >>>>> can be automate it's even better. >>>>> * The Webrev tool seems archaic to me (and >>>>> part of its output is broken >>>>> as >>>>> far as I could tell). An IDE can create diff >>>>> patches with a couple of >>>>> clicks. >>>>> * The Jcheck tool seems archaic to me. It >>>>> should be ported to IDE >>>>> formatters which are to be distributed with >>>>> the source. No reason to >>>>> >>>>> run >>>>> >>>>> a >>>>> tool that tells me which whitespaces I need to >>>>> go back and change when >>>>> something like Ctrl+Shift+F in an IDE finishes >>>>> the job. >>>>> >>>>> --- Wiki --- >>>>> >>>>> * The Wiki could be open sourced as well (like >>>>> other Wikis). I could >>>>> definitely update a page or 2 there and so >>>>> would other developers as >>>>> >>>>> they >>>>> >>>>> gain knowledge. I don't know yet how >>>>> permissions for that should be >>>>> handled. >>>>> * Code conventions should be clearly listed. >>>>> * Separate sections with instructions should >>>>> be made for: (1) cloning >>>>> >>>>> and >>>>> >>>>> building, (2) modifying, (3) running tests, >>>>> (4) submitting, and (5) >>>>> reviewing. >>>>> * Old sections should be cleaned up (I don't >>>>> think Discussions is >>>>> >>>>> useful >>>>> >>>>> anymore). >>>>> >>>>> --- Review policy --- >>>>> >>>>> * I have no experience with review policies or >>>>> project roles so I can't >>>>> help here much (maybe after a discussion >>>>> starts). >>>>> * One thing I do know is that reviewers should >>>>> be extremely >>>>> knowledgeable, >>>>> which means that there aren't many qualified. >>>>> Because of this, if it >>>>> becomes "too" easy to contribute to OpenJFX, >>>>> careful measures need to >>>>> >>>>> be >>>>> >>>>> taken as to not to swamp the few reviewers >>>>> with many patches (though >>>>> >>>>> some >>>>> >>>>> would say this is an ideal situation). Some >>>>> sort of review queue might >>>>> help >>>>> with organization instead of the current email >>>>> system. I have no >>>>> >>>>> concrete >>>>> >>>>> solution for this. >>>>> >>>>> - Nir >>>>> >>>>> >>>>> Message: 1 >>>>> >>>>> Date: Thu, 01 Feb 2018 15:26:24 -0800 >>>>> From: Kevin Rushforth >>>>> >>>> > >>>>> To: "openjfx-dev at openjdk.java.net >>>>> " >>>>> >>>> > >>>>> Subject: More community participation in >>>>> JavaFX >>>>> Message-ID: <5A73A220.7030706 at oracle.com >>>>> > >>>>> Content-Type: text/plain; >>>>> charset=windows-1252; format=flowed >>>>> >>>>> To: OpenJFX Developers >>>>> >>>>> We are looking to grow the community of >>>>> contributors to the OpenJFX >>>>> project, especially serious contributors >>>>> who will stick around long >>>>> enough to become reviewers, to help us >>>>> keep the platform vibrant. To >>>>> this end we are looking at ways to >>>>> encourage more participation and >>>>> >>>>> make >>>>> >>>>> it easier for interested folks to >>>>> contribute. >>>>> >>>>> We are specifically looking to discuss >>>>> ideas around the following >>>>> >>>>> areas: >>>>> >>>>> * Easing barriers to contribution (e.g., >>>>> making JavaFX easier to >>>>> >>>>> build, >>>>> >>>>> better documentation, making it easier to >>>>> test changes) >>>>> >>>>> * Code review policies >>>>> >>>>> * API / feature review policies >>>>> >>>>> * Code review tools (we currently use >>>>> webrev, but that isn't set in >>>>> >>>>> stone) >>>>> >>>>> To keep this thread productive, the >>>>> following are explicitly out of >>>>> >>>>> scope: >>>>> >>>>> * Discussion of specific features or bugs >>>>> that you would like to >>>>> implement (or wish someone else would) >>>>> >>>>> * Discussion about platform support >>>>> >>>>> * Discussion about version control systems >>>>> (e.g., hg versus git), >>>>> hosting of the OpenJFX repos and bug >>>>> database (e.g., OpenJDK versus >>>>> github), etc...at least for now. We are >>>>> aware of the potential >>>>> >>>>> benefits >>>>> >>>>> of such changes, but we'd like to focus >>>>> our efforts on >>>>> >>>>> higher-leverage >>>>> >>>>> things we can do in the short term. >>>>> >>>>> * Discussion about the requirement of a >>>>> signed OCA to become a >>>>> >>>>> contributor >>>>> >>>>> * Off-topic or tangential commentary about >>>>> OpenJFX that isn't >>>>> >>>>> directly >>>>> >>>>> related to the topic at hand >>>>> >>>>> >>>>> As a starting point for discussion, here >>>>> are some areas I think need >>>>> improvement; I'm sure there are others: >>>>> >>>>> I. Helping contributors get started >>>>> >>>>> It isn?t as easy to get started with >>>>> OpenJFX as it should be. We want >>>>> >>>>> to >>>>> >>>>> make it easier for potential OpenJFX >>>>> contributors to get started. >>>>> >>>>> Here >>>>> >>>>> are some ideas that I think might help: >>>>> >>>>> * Improve the build instructions / Wiki (I >>>>> made a first start, but >>>>> >>>>> there >>>>> >>>>> is much more to be done) >>>>> >>>>> * Make the build itself more resilient >>>>> where possible, and provide >>>>> better error messages, specifically when >>>>> dealing with native >>>>> >>>>> compilers >>>>> >>>>> and libraries >>>>> >>>>> * Add an option to skip building all >>>>> native code and use prebuilt >>>>> binaries (like we do already for media and >>>>> webkit); this is tracked >>>>> >>>>> by >>>>> >>>>> JDK-8092279, but it hasn?t been looked at >>>>> recently >>>>> >>>>> * Make it easier to build / test your >>>>> local OpenJFX build using an >>>>> OpenJDK build (currently the only way to >>>>> do this is to build OpenJDK >>>>> locally, after using configure to point to >>>>> your just-built javafx.* >>>>> modules). >>>>> >>>>> * Provide step-by-step instructions for >>>>> how to make a contribution, >>>>> including testing requirements; a lot of >>>>> the pieces are there, but >>>>> >>>>> are >>>>> >>>>> out of date or scattered in several >>>>> places. As part of this, we could >>>>> have a section on how to contribute docs, >>>>> samples or tests, since >>>>> >>>>> that >>>>> >>>>> is often a good place to start. >>>>> >>>>> * Provide a sandbox environment where >>>>> contributors can discuss and >>>>> >>>>> test >>>>> >>>>> ideas. For example, an OpenJFX mirror on >>>>> github, potentially >>>>> >>>>> connected >>>>> >>>>> to AdoptOpenJDK. >>>>> >>>>> >>>>> II. Code reviews and API reviews >>>>> >>>>> Code reviews are important to maintain >>>>> high-quality contributions, >>>>> >>>>> but >>>>> >>>>> we recognize that not every type of change >>>>> needs the same level of >>>>> review. Without lowering our standards of >>>>> quality, we want to make it >>>>> easier to get low-impact changes (simple >>>>> bug fixes) accepted. >>>>> >>>>> There are three categories of changes, >>>>> each of which might merit a >>>>> different review standard: >>>>> >>>>> 1. Low-impact bug fixes. These are >>>>> typically isolated bug fixes with >>>>> little or no impact beyond fixing the bug >>>>> in question; included in >>>>> >>>>> this >>>>> >>>>> category are test fixes (including new >>>>> tests) doc fixes, and fixes to >>>>> sample applications (including new >>>>> samples). >>>>> >>>>> 2. Higher impact bug fixes or RFEs. These >>>>> include changes to the >>>>> implementation that potentially have a >>>>> performance or behavioral >>>>> >>>>> impact, >>>>> >>>>> or are otherwise broad in scope. Some >>>>> larger bug fixes will fall into >>>>> this category, as will fixes in high-risk >>>>> areas (e.g., CSS). >>>>> >>>>> 3. New features / API additions. In >>>>> addition to reviewing the >>>>> implementation, we will need a separate >>>>> approval process for the new >>>>> >>>>> API >>>>> >>>>> / feature (such as the CSR, which is what >>>>> we use now, or a similar >>>>> process). >>>>> >>>>> We take compatibility seriously, so >>>>> anything that adds new API needs >>>>> >>>>> to >>>>> >>>>> be done with an eye towards supporting it >>>>> for at least 10 years. We >>>>> don't want to add new public API without >>>>> that level of commitment. >>>>> >>>>> Every >>>>> >>>>> new feature forecloses on alternate future >>>>> features. Significant >>>>> >>>>> effort >>>>> >>>>> must be taken to think about "if we did >>>>> this, what could it interact >>>>> with in the future?" Also, anything with a >>>>> large potential impact on >>>>> performance or behavioral compatibility >>>>> needs to be looked at >>>>> >>>>> carefully. >>>>> >>>>> Put another way, we want to encourage >>>>> thinking about new features or >>>>> >>>>> new >>>>> >>>>> API in terms of a design / stewardship >>>>> process; to think in terms of >>>>> questions like "what's the right thing for >>>>> JavaFX in the next 10+ >>>>> >>>>> years" >>>>> >>>>> rather than "here's some code that solves >>>>> my problem, please take >>>>> >>>>> it". >>>>> >>>>> As a stake in the ground, I might suggest >>>>> the following: >>>>> >>>>> * All changes need at least one reviewer >>>>> other than the person making >>>>> the change who can evaluate the change for >>>>> correctness and >>>>> >>>>> consistency. >>>>> >>>>> For simple bug fixes, a single reviewer >>>>> may be sufficient. Of course, >>>>> one of our big challenges in all this is: >>>>> "how do we grow more >>>>> reviewers?", by which I mean "how do we >>>>> facilitate getting >>>>> >>>>> contributors >>>>> >>>>> with enough expertise in a given area to >>>>> eventually be able to >>>>> effectively review contributions from >>>>> others?" >>>>> >>>>> * We need clear criteria for the other two >>>>> categories that balance >>>>> process efficiency with the desire to >>>>> maintain compatibility and >>>>> stability. API changes need to be approved >>>>> by a lead. My thought is >>>>> >>>>> to >>>>> >>>>> combine the last two into a single >>>>> category for purposes of reviewing >>>>> the implementation. Anything that affects >>>>> public API or behavioral >>>>> compatibility will require CSR or similar >>>>> approval, over and above >>>>> >>>>> the >>>>> >>>>> implementation review, which seems >>>>> sufficient. >>>>> >>>>> * I recommend that we formalize the >>>>> concept of reviewers, using the >>>>> OpenJDK Reviewer role for the Project. We >>>>> might also consider if we >>>>> >>>>> want >>>>> >>>>> to make any changes to the criteria used >>>>> by the JDK Project for >>>>> >>>>> becoming >>>>> >>>>> an OpenJFX Project Author, Committer, and >>>>> Reviewer. The OpenJDK >>>>> >>>>> bylaws >>>>> >>>>> allow projects a fair degree of latitude >>>>> to define these criteria, so >>>>> >>>>> we >>>>> >>>>> might consider making some modifications. >>>>> For example, we might make >>>>> >>>>> it >>>>> >>>>> somewhat easier for a Contributor to >>>>> become an Author, or for a >>>>> Committer to become a Reviewer. I have >>>>> some thoughts on this, but >>>>> >>>>> want >>>>> >>>>> to hear from others first. >>>>> >>>>> >>>>> I look forward to feedback on this >>>>> proposal, and hope it will spark a >>>>> productive discussion. >>>>> >>>>> -- Kevin Rushforth, OpenJFX Project Lead >>>>> >>>>> >>>>> >>>>> >>>>> >>> > From johnvalrose at gmail.com Wed Feb 7 09:52:28 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Wed, 7 Feb 2018 20:52:28 +1100 Subject: More community participation in JavaFX In-Reply-To: <90b3cb55e88375f048b1c4eb8f883d8d.squirrel@54.sslprotected.nl> References: <5A786D32.6050600@oracle.com> <5A7A6188.2090608@oracle.com> <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> <90b3cb55e88375f048b1c4eb8f883d8d.squirrel@54.sslprotected.nl> Message-ID: Well, not only do I think that a docking framework is *that* complex, I see it as an essential part of any serious graphics toolkit. In general, I don?t understand all the limitations that people keep imposing on JavaFX as if we have to ?settle? for what is basically a 2nd class citizen compared with toolkits in other languages. Why can?t we just make JavaFX so compelling that developers from other languages are enticed by the feature set itself? There is no reason (other than a lack of effort) why JavaFX cannot be on par with Qt or Xamarin in terms of features, performance, tooling and adoption. Am I the only one that believes the world?s most popular and amazing programming language, platform and the JVM deserves a first class graphics toolkit? I understand the constraints imposed on Oracle staff but isn?t there anyone else out there in the community who shares my vision for JavaFX? It seems the general attitude is that JavaFX just needs to be a ?better Swing?. Forget about this nonsense of ?thinking outside the box?. There is NO BOX! JavaFX can and should be the best that we as a community can make it. And then we just keep making it better... If we don?t adopt such a vision and attitude then what is the point of doing anything at all? Just leave JavaFX to rot into oblivion and relegate Java to a server-side language only. > On 7 Feb 2018, at 19:25, Tom Eugelink wrote: > > Well, I believe he was hinting at that a docking framework is considered > more complex, there was no negative sentiment in that. Although I do not > think a docking framework is that complex, but maybe I'm wrong. > > And yes, ALMOST everyone is at ControlFX ;-) > > > >> Jonathan - why do you *cough* at ideas like more complex controls and >> docking frameworks? >> >> I think that a docking framework especially would be a great addition to >> JavaFX. >> >> Am I missing something? >> >>> On 7 Feb 2018, at 18:16, Jonathan Giles >>> wrote: >>> >>> Obviously everyone is at ControlsFX instead ;-) >>> >>> Part of the drop I would suggest is simply that many of the itches >>> people >>> want to scratch are now scratched. Alternatively, the remaining itches >>> are >>> either in more complex controls (*cough* docking frameworks *cough*) or >>> in >>> areas beneath the controls APIs - performance, webview, etc - which are >>> more challenging and require greater levels of dedication. >>> >>> However, more generally, your point is well made - contribution to >>> JavaFX >>> does not need to be synonymous with contribution to OpenJFX. People who >>> find the challenges of the current OpenJFX requirements too great should >>> be >>> encouraged to involve themselves in projects such as JFXtras, etc. >>> >>> -- Jonathan >>> >>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >>>> >>>> Many years ago I had a discussion with Jonathan Giles about if the >>>> things >>>> that were being made in JFXtras would eventually become part of the >>>> JavaFX >>>> core. In the end I decided that, for me personally, I could do the >>>> things I >>>> wanted to perfectly in a separate project. The rigid structure that >>>> Java(FX) has to adhere to, would be a big downside. >>>> >>>> What I want to say with that is that all the external projects are also >>>> contributions to JavaFX. It does not matter whether for example a >>>> control >>>> is part of the core distribution or of a side project; it is just >>>> another >>>> module users can add to the mix. >>>> >>>> So reflecting back I still stand by that choice. But having a few more >>>> people in the project (just like in JavaFX ;-) ) would be nice, but >>>> OTOH it >>>> forces me to deal with (and learn about) annoying stuff like Gradle >>>> build >>>> scripts and Java 9 migration. But because of that progress is not as >>>> fast >>>> as I would like it to be. Could it be that there is a decline in people >>>> willing to work for open source projects? Or is it just that this tech, >>>> JavaFX, is no longer appealing? >>>> >>>> Tom >>>> >>>> >>>> >>> Obviously everyone is at ControlsFX instead ;-) >>> >>> Part of the drop I would suggest is simply that many of the itches >>> people >>> want to scratch are now scratched. Alternatively, the remaining itches >>> are >>> either in more complex controls (*cough* docking frameworks *cough*) or >>> in >>> areas beneath the controls APIs - performance, webview, etc - which are >>> more challenging and require greater levels of dedication. >>> >>> However, more generally, your point is well made - contribution to >>> JavaFX >>> does not need to be synonymous with contribution to OpenJFX. People who >>> find the challenges of the current OpenJFX requirements too great should >>> be >>> encouraged to involve themselves in projects such as JFXtras, etc. >>> >>> -- Jonathan >>> >>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >>>> >>>> Many years ago I had a discussion with Jonathan Giles about if the >>>> things >>>> that were being made in JFXtras would eventually become part of the >>>> JavaFX >>>> core. In the end I decided that, for me personally, I could do the >>>> things I >>>> wanted to perfectly in a separate project. The rigid structure that >>>> Java(FX) has to adhere to, would be a big downside. >>>> >>>> What I want to say with that is that all the external projects are also >>>> contributions to JavaFX. It does not matter whether for example a >>>> control >>>> is part of the core distribution or of a side project; it is just >>>> another >>>> module users can add to the mix. >>>> >>>> So reflecting back I still stand by that choice. But having a few more >>>> people in the project (just like in JavaFX ;-) ) would be nice, but >>>> OTOH it >>>> forces me to deal with (and learn about) annoying stuff like Gradle >>>> build >>>> scripts and Java 9 migration. But because of that progress is not as >>>> fast >>>> as I would like it to be. Could it be that there is a decline in people >>>> willing to work for open source projects? Or is it just that this tech, >>>> JavaFX, is no longer appealing? >>>> >>>> Tom >>>> >>>> >>>> >>>>> On 7-2-2018 03:16, Kevin Rushforth wrote: >>>>> >>>>> I would recommend against having a separate issue tracker or mailing >>>>> list >>>>> associated with the sandbox. That will create more confusion than any >>>>> benefit you might have. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Nir Lisker wrote: >>>>> >>>>>> Another thing to be careful about with the sandbox/staging idea is >>>>>> the >>>>>> confusion that will arise with duplication. There will be 2 issue >>>>>> trackers >>>>>> (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and >>>>>> maybe 2 >>>>>> discussion lists. For those "in the know" this will be a simple >>>>>> matter, but >>>>>> for a potential contributor this can be a gamebreaker if not handled >>>>>> appropriately. >>>>>> >>>>>> Dalibor Topic's suggestion of contacting other mirrors can be >>>>>> instrumental in solving these problems. >>>>>> >>>>>> - Nir >>>>>> >>>>>> On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth < >>>>>> kevin.rushforth at oracle.com > >>>>>> wrote: >>>>>> >>>>>> Yes, this sounds like a good step in the right direction. This >>>>>> would give anyone (with a signed OCA) the ability to create their >>>>>> own branch, commit changes to it, submit a PR, etc. >>>>>> >>>>>> I presume there will be a branch that is an exact mirror of the >>>>>> jfx-dev repo on OpenJDK in addition to the development branch in >>>>>> the sandbox? >>>>>> >>>>>> The only thing to consider is whether it should be Committers or >>>>>> Reviewers that have rights to merge into the sandbox development >>>>>> branch. There are pros / cons of each. I'd probably lean towards >>>>>> having it be Committers, with the idea that a Committer needs to >>>>>> sponsor the patch anyway and would then be able to "take it the >>>>>> rest of the way". The only downside I see is that you could end up >>>>>> with a few patches that get accepted into the sandbox dev branch, >>>>>> but never make it to the upstream jfx-dev repo (or not without >>>>>> significant change). I doubt this will be a big problem in >>>>>> practice. >>>>>> >>>>>> Either way, this could also provide a good alternative to webrev >>>>>> when reviewing the final changes. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Johan Vos wrote: >>>>>> >>>>>> Hi Michael, >>>>>> >>>>>> This proposal is very much in line with my thinking as well. >>>>>> The problem is not that we don't have a github clone of >>>>>> OpenJFX. We have a >>>>>> number of them (e.g. I created >>>>>> https://github.com/javafxports/jfx-dev >>>>>> some >>>>>> months ago). We just need a single one that is updated >>>>>> constantly from >>>>>> mainstream, and standardize on that. Let's call that "sandbox" >>>>>> (I would be >>>>>> ok with staging as well, but sandbox is imho more inviting to >>>>>> people who >>>>>> want to try something drastic, e.g. support for Vulkan) >>>>>> >>>>>> The main issue is how to get contributions, review them, and >>>>>> eventually >>>>>> send them upstream. >>>>>> >>>>>> The PR review process is extremely important. If we lower that >>>>>> bar, we >>>>>> loose quality. If the bar is too high, great PR's won't be >>>>>> accepted >>>>>> upstream as there is not enough review time to review it. >>>>>> >>>>>> I agree giving the current OpenJFX committers merge rights for >>>>>> the >>>>>> "sandbox" repository makes sense. Once a public contribution >>>>>> is merged by >>>>>> one of those committers, that same committer can send it >>>>>> upstream to the >>>>>> existing OpenJFX repository. Additional checks will be >>>>>> performed there, >>>>>> mainly in order to make sure the overall "Feel of Java" is >>>>>> preserved. To >>>>>> that purpose, it would help to have a closer alignment with >>>>>> the OpenJDK >>>>>> community. >>>>>> >>>>>> We have to be aware that this will increase the workload of >>>>>> the current >>>>>> committers and reviewers. That is the price we pay for >>>>>> standardization. >>>>>> Rather than everyone creating his own forks of a UI framework >>>>>> in Java, we >>>>>> invest a lot in creating a single, generally agreed one. >>>>>> >>>>>> So in summary, I'm +1 on a 2-phase approach: "open" commits >>>>>> allowed in >>>>>> staging. OpenJFX committers accept PR's (if they are of good >>>>>> quality) and >>>>>> prepare upstream commits for OpenJFX. We hope there will be >>>>>> more >>>>>> contributors who become committers and reviewers in the medium >>>>>> term. >>>>>> >>>>>> - Johan >>>>>> >>>>>> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen >>>>>> > wrote: >>>>>> >>>>>> >>>>>> Those are great questions, and I think with >>>>>> Kevin/Oracle/other OpenJFX devs >>>>>> help we >>>>>> can figure something out. >>>>>> >>>>>> My thinking is that the PR would be reviewed by basically >>>>>> anyone who has >>>>>> free time. >>>>>> I think that, at first, only OpenJFX committers will be >>>>>> able to merge PRs. >>>>>> They would >>>>>> do the final review/merge to the staging repo after it has >>>>>> been reviewed by >>>>>> the "wider audience" >>>>>> which includes people without commit rights (people like >>>>>> us). Then, as this >>>>>> thing evolves, >>>>>> based on the pool of people who are contributing both pull >>>>>> requests and PR >>>>>> reviews, >>>>>> the committers will be able to grant commit privileges to >>>>>> some people in >>>>>> that pool. >>>>>> >>>>>> I can't think of any way that would make it so the changes >>>>>> are as likely to >>>>>> be >>>>>> merged upstream as possible other than having the current >>>>>> OpenJFX >>>>>> committers paving the >>>>>> way. Hopefully this vision is aligned with Kevin's and >>>>>> hopefully these >>>>>> concrete details >>>>>> can be worked out. >>>>>> >>>>>> Regards, >>>>>> Michael >>>>>> >>>>>> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker >>>>>> > wrote: >>>>>> >>>>>> >>>>>> So if a community ran GitHub is used for staging, who >>>>>> will approve PRs >>>>>> >>>>>> for >>>>>> >>>>>> the code and the Wiki of the GitHub repo? >>>>>> >>>>>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen >>>>>> > >>>>>> wrote: >>>>>> >>>>>> >>>>>> Great points, Nir. We share the same hopes. I just >>>>>> wanted to piggy-back >>>>>> on the >>>>>> wiki thing: >>>>>> >>>>>> " * The Wiki could be open sourced as well (like >>>>>> other Wikis). I could >>>>>> definitely update a page or 2 there and so would >>>>>> other developers as >>>>>> >>>>>> they >>>>>> >>>>>> gain knowledge. I don't know yet how permissions >>>>>> for that should be >>>>>> handled." >>>>>> >>>>>> This is another thing that we could use the GitHub >>>>>> staging repository >>>>>> >>>>>> for. >>>>>> >>>>>> The staging repository could have a wiki (projects >>>>>> on GitHub can have >>>>>> >>>>>> one) >>>>>> >>>>>> that is editable by all, and then maybe once a >>>>>> month or so someone with >>>>>> permissions >>>>>> to edit to official wiki can sync with the new, >>>>>> reviewed changes (the >>>>>> once-a-month >>>>>> time constraint is very flexible). >>>>>> >>>>>> I am just trying to explain how the GitHub >>>>>> repository "one-way mirror" >>>>>> (potentially linked >>>>>> with/managed by Adopt an OpenJDK) can act as a >>>>>> staging ground for all >>>>>> kinds of contributions to >>>>>> OpenJFX. >>>>>> >>>>>> By the way, I am trying to cleanup the groundwork >>>>>> I did on getting >>>>>> Appveyor builds to >>>>>> run for openjfx, if indeed it is decided to setup >>>>>> such a staging >>>>>> repository. You can >>>>>> see my efforts here: >>>>>> https://raw.githubusercontent. >>>>>> >>>>>> >>>>>> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057 >>>>>> /appveyor.yml >>>>>> >>>>>> If the GitHub repository was setup, changes such >>>>>> as these to add CI >>>>>> infrastructure would >>>>>> never be adopted by upstream OpenJFX, but would >>>>>> allow for developer's to >>>>>> get good >>>>>> feedback on test results for all supported >>>>>> platforms when they open a >>>>>> >>>>>> PR. >>>>>> >>>>>> Merging a PR >>>>>> on the public GitHub repository means, in my >>>>>> opinion, that it is ready >>>>>> >>>>>> to >>>>>> >>>>>> be opened as >>>>>> an upstream bug/feature request. Automating the >>>>>> process with patch sets, >>>>>> webrevs, formatting/lint >>>>>> results, etc. would be the most ideal situation >>>>>> and I would be happy to >>>>>> contribute to these >>>>>> efforts. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Michael Ennen >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker >>>>>> > >>>>>> wrote: >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> As someone who has recently made the climb and >>>>>> managed to build OpenJFX >>>>>> with OpenJDK on Win 10 I might have some >>>>>> relevant input. >>>>>> >>>>>> --- Building OpenJFX --- >>>>>> >>>>>> * With the recently updated instructions on >>>>>> the Wiki, building OpenJFX >>>>>> >>>>>> is >>>>>> >>>>>> not that hard. Having to build OpenJDK for >>>>>> that was a real headache >>>>>> because >>>>>> their instructions and build tools are not up >>>>>> to date ( >>>>>> https://bugs.openjdk.java.net/browse/JDK-8194645 >>>>>> ). >>>>>> * The above doesn't mean that the process >>>>>> shouldn't be made easier. >>>>>> Ideally, it would be the as easy as working on >>>>>> most open source >>>>>> >>>>>> projects >>>>>> >>>>>> on >>>>>> Github (not advocating git over hg): clone >>>>>> into the IDE and start >>>>>> working; >>>>>> when a fix is ready, submit a PR. Don't know >>>>>> if it's technically >>>>>> >>>>>> possible >>>>>> >>>>>> in this case, but it's a target. >>>>>> * The repository needs a good cleanup before >>>>>> contributors start >>>>>> >>>>>> cloning ( >>>>>> >>>>>> bugs.openjdk.java.net/browse/JDK-8196198 >>>>>> ). >>>>>> >>>>>> --- Working on OpenJFX --- >>>>>> >>>>>> * It should be clear which tests need to run >>>>>> for a specific patch. >>>>>> Changes >>>>>> can be made anywhere from the documentation >>>>>> level to native code level >>>>>> and >>>>>> there's no reason to run the same tests for >>>>>> all of these. If the >>>>>> >>>>>> process >>>>>> >>>>>> can be automate it's even better. >>>>>> * The Webrev tool seems archaic to me (and >>>>>> part of its output is broken >>>>>> as >>>>>> far as I could tell). An IDE can create diff >>>>>> patches with a couple of >>>>>> clicks. >>>>>> * The Jcheck tool seems archaic to me. It >>>>>> should be ported to IDE >>>>>> formatters which are to be distributed with >>>>>> the source. No reason to >>>>>> >>>>>> run >>>>>> >>>>>> a >>>>>> tool that tells me which whitespaces I need to >>>>>> go back and change when >>>>>> something like Ctrl+Shift+F in an IDE finishes >>>>>> the job. >>>>>> >>>>>> --- Wiki --- >>>>>> >>>>>> * The Wiki could be open sourced as well (like >>>>>> other Wikis). I could >>>>>> definitely update a page or 2 there and so >>>>>> would other developers as >>>>>> >>>>>> they >>>>>> >>>>>> gain knowledge. I don't know yet how >>>>>> permissions for that should be >>>>>> handled. >>>>>> * Code conventions should be clearly listed. >>>>>> * Separate sections with instructions should >>>>>> be made for: (1) cloning >>>>>> >>>>>> and >>>>>> >>>>>> building, (2) modifying, (3) running tests, >>>>>> (4) submitting, and (5) >>>>>> reviewing. >>>>>> * Old sections should be cleaned up (I don't >>>>>> think Discussions is >>>>>> >>>>>> useful >>>>>> >>>>>> anymore). >>>>>> >>>>>> --- Review policy --- >>>>>> >>>>>> * I have no experience with review policies or >>>>>> project roles so I can't >>>>>> help here much (maybe after a discussion >>>>>> starts). >>>>>> * One thing I do know is that reviewers should >>>>>> be extremely >>>>>> knowledgeable, >>>>>> which means that there aren't many qualified. >>>>>> Because of this, if it >>>>>> becomes "too" easy to contribute to OpenJFX, >>>>>> careful measures need to >>>>>> >>>>>> be >>>>>> >>>>>> taken as to not to swamp the few reviewers >>>>>> with many patches (though >>>>>> >>>>>> some >>>>>> >>>>>> would say this is an ideal situation). Some >>>>>> sort of review queue might >>>>>> help >>>>>> with organization instead of the current email >>>>>> system. I have no >>>>>> >>>>>> concrete >>>>>> >>>>>> solution for this. >>>>>> >>>>>> - Nir >>>>>> >>>>>> >>>>>> Message: 1 >>>>>> >>>>>> Date: Thu, 01 Feb 2018 15:26:24 -0800 >>>>>> From: Kevin Rushforth >>>>>> >>>>> > >>>>>> To: "openjfx-dev at openjdk.java.net >>>>>> " >>>>>> >>>>> > >>>>>> Subject: More community participation in >>>>>> JavaFX >>>>>> Message-ID: <5A73A220.7030706 at oracle.com >>>>>> > >>>>>> Content-Type: text/plain; >>>>>> charset=windows-1252; format=flowed >>>>>> >>>>>> To: OpenJFX Developers >>>>>> >>>>>> We are looking to grow the community of >>>>>> contributors to the OpenJFX >>>>>> project, especially serious contributors >>>>>> who will stick around long >>>>>> enough to become reviewers, to help us >>>>>> keep the platform vibrant. To >>>>>> this end we are looking at ways to >>>>>> encourage more participation and >>>>>> >>>>>> make >>>>>> >>>>>> it easier for interested folks to >>>>>> contribute. >>>>>> >>>>>> We are specifically looking to discuss >>>>>> ideas around the following >>>>>> >>>>>> areas: >>>>>> >>>>>> * Easing barriers to contribution (e.g., >>>>>> making JavaFX easier to >>>>>> >>>>>> build, >>>>>> >>>>>> better documentation, making it easier to >>>>>> test changes) >>>>>> >>>>>> * Code review policies >>>>>> >>>>>> * API / feature review policies >>>>>> >>>>>> * Code review tools (we currently use >>>>>> webrev, but that isn't set in >>>>>> >>>>>> stone) >>>>>> >>>>>> To keep this thread productive, the >>>>>> following are explicitly out of >>>>>> >>>>>> scope: >>>>>> >>>>>> * Discussion of specific features or bugs >>>>>> that you would like to >>>>>> implement (or wish someone else would) >>>>>> >>>>>> * Discussion about platform support >>>>>> >>>>>> * Discussion about version control systems >>>>>> (e.g., hg versus git), >>>>>> hosting of the OpenJFX repos and bug >>>>>> database (e.g., OpenJDK versus >>>>>> github), etc...at least for now. We are >>>>>> aware of the potential >>>>>> >>>>>> benefits >>>>>> >>>>>> of such changes, but we'd like to focus >>>>>> our efforts on >>>>>> >>>>>> higher-leverage >>>>>> >>>>>> things we can do in the short term. >>>>>> >>>>>> * Discussion about the requirement of a >>>>>> signed OCA to become a >>>>>> >>>>>> contributor >>>>>> >>>>>> * Off-topic or tangential commentary about >>>>>> OpenJFX that isn't >>>>>> >>>>>> directly >>>>>> >>>>>> related to the topic at hand >>>>>> >>>>>> >>>>>> As a starting point for discussion, here >>>>>> are some areas I think need >>>>>> improvement; I'm sure there are others: >>>>>> >>>>>> I. Helping contributors get started >>>>>> >>>>>> It isn?t as easy to get started with >>>>>> OpenJFX as it should be. We want >>>>>> >>>>>> to >>>>>> >>>>>> make it easier for potential OpenJFX >>>>>> contributors to get started. >>>>>> >>>>>> Here >>>>>> >>>>>> are some ideas that I think might help: >>>>>> >>>>>> * Improve the build instructions / Wiki (I >>>>>> made a first start, but >>>>>> >>>>>> there >>>>>> >>>>>> is much more to be done) >>>>>> >>>>>> * Make the build itself more resilient >>>>>> where possible, and provide >>>>>> better error messages, specifically when >>>>>> dealing with native >>>>>> >>>>>> compilers >>>>>> >>>>>> and libraries >>>>>> >>>>>> * Add an option to skip building all >>>>>> native code and use prebuilt >>>>>> binaries (like we do already for media and >>>>>> webkit); this is tracked >>>>>> >>>>>> by >>>>>> >>>>>> JDK-8092279, but it hasn?t been looked at >>>>>> recently >>>>>> >>>>>> * Make it easier to build / test your >>>>>> local OpenJFX build using an >>>>>> OpenJDK build (currently the only way to >>>>>> do this is to build OpenJDK >>>>>> locally, after using configure to point to >>>>>> your just-built javafx.* >>>>>> modules). >>>>>> >>>>>> * Provide step-by-step instructions for >>>>>> how to make a contribution, >>>>>> including testing requirements; a lot of >>>>>> the pieces are there, but >>>>>> >>>>>> are >>>>>> >>>>>> out of date or scattered in several >>>>>> places. As part of this, we could >>>>>> have a section on how to contribute docs, >>>>>> samples or tests, since >>>>>> >>>>>> that >>>>>> >>>>>> is often a good place to start. >>>>>> >>>>>> * Provide a sandbox environment where >>>>>> contributors can discuss and >>>>>> >>>>>> test >>>>>> >>>>>> ideas. For example, an OpenJFX mirror on >>>>>> github, potentially >>>>>> >>>>>> connected >>>>>> >>>>>> to AdoptOpenJDK. >>>>>> >>>>>> >>>>>> II. Code reviews and API reviews >>>>>> >>>>>> Code reviews are important to maintain >>>>>> high-quality contributions, >>>>>> >>>>>> but >>>>>> >>>>>> we recognize that not every type of change >>>>>> needs the same level of >>>>>> review. Without lowering our standards of >>>>>> quality, we want to make it >>>>>> easier to get low-impact changes (simple >>>>>> bug fixes) accepted. >>>>>> >>>>>> There are three categories of changes, >>>>>> each of which might merit a >>>>>> different review standard: >>>>>> >>>>>> 1. Low-impact bug fixes. These are >>>>>> typically isolated bug fixes with >>>>>> little or no impact beyond fixing the bug >>>>>> in question; included in >>>>>> >>>>>> this >>>>>> >>>>>> category are test fixes (including new >>>>>> tests) doc fixes, and fixes to >>>>>> sample applications (including new >>>>>> samples). >>>>>> >>>>>> 2. Higher impact bug fixes or RFEs. These >>>>>> include changes to the >>>>>> implementation that potentially have a >>>>>> performance or behavioral >>>>>> >>>>>> impact, >>>>>> >>>>>> or are otherwise broad in scope. Some >>>>>> larger bug fixes will fall into >>>>>> this category, as will fixes in high-risk >>>>>> areas (e.g., CSS). >>>>>> >>>>>> 3. New features / API additions. In >>>>>> addition to reviewing the >>>>>> implementation, we will need a separate >>>>>> approval process for the new >>>>>> >>>>>> API >>>>>> >>>>>> / feature (such as the CSR, which is what >>>>>> we use now, or a similar >>>>>> process). >>>>>> >>>>>> We take compatibility seriously, so >>>>>> anything that adds new API needs >>>>>> >>>>>> to >>>>>> >>>>>> be done with an eye towards supporting it >>>>>> for at least 10 years. We >>>>>> don't want to add new public API without >>>>>> that level of commitment. >>>>>> >>>>>> Every >>>>>> >>>>>> new feature forecloses on alternate future >>>>>> features. Significant >>>>>> >>>>>> effort >>>>>> >>>>>> must be taken to think about "if we did >>>>>> this, what could it interact >>>>>> with in the future?" Also, anything with a >>>>>> large potential impact on >>>>>> performance or behavioral compatibility >>>>>> needs to be looked at >>>>>> >>>>>> carefully. >>>>>> >>>>>> Put another way, we want to encourage >>>>>> thinking about new features or >>>>>> >>>>>> new >>>>>> >>>>>> API in terms of a design / stewardship >>>>>> process; to think in terms of >>>>>> questions like "what's the right thing for >>>>>> JavaFX in the next 10+ >>>>>> >>>>>> years" >>>>>> >>>>>> rather than "here's some code that solves >>>>>> my problem, please take >>>>>> >>>>>> it". >>>>>> >>>>>> As a stake in the ground, I might suggest >>>>>> the following: >>>>>> >>>>>> * All changes need at least one reviewer >>>>>> other than the person making >>>>>> the change who can evaluate the change for >>>>>> correctness and >>>>>> >>>>>> consistency. >>>>>> >>>>>> For simple bug fixes, a single reviewer >>>>>> may be sufficient. Of course, >>>>>> one of our big challenges in all this is: >>>>>> "how do we grow more >>>>>> reviewers?", by which I mean "how do we >>>>>> facilitate getting >>>>>> >>>>>> contributors >>>>>> >>>>>> with enough expertise in a given area to >>>>>> eventually be able to >>>>>> effectively review contributions from >>>>>> others?" >>>>>> >>>>>> * We need clear criteria for the other two >>>>>> categories that balance >>>>>> process efficiency with the desire to >>>>>> maintain compatibility and >>>>>> stability. API changes need to be approved >>>>>> by a lead. My thought is >>>>>> >>>>>> to >>>>>> >>>>>> combine the last two into a single >>>>>> category for purposes of reviewing >>>>>> the implementation. Anything that affects >>>>>> public API or behavioral >>>>>> compatibility will require CSR or similar >>>>>> approval, over and above >>>>>> >>>>>> the >>>>>> >>>>>> implementation review, which seems >>>>>> sufficient. >>>>>> >>>>>> * I recommend that we formalize the >>>>>> concept of reviewers, using the >>>>>> OpenJDK Reviewer role for the Project. We >>>>>> might also consider if we >>>>>> >>>>>> want >>>>>> >>>>>> to make any changes to the criteria used >>>>>> by the JDK Project for >>>>>> >>>>>> becoming >>>>>> >>>>>> an OpenJFX Project Author, Committer, and >>>>>> Reviewer. The OpenJDK >>>>>> >>>>>> bylaws >>>>>> >>>>>> allow projects a fair degree of latitude >>>>>> to define these criteria, so >>>>>> >>>>>> we >>>>>> >>>>>> might consider making some modifications. >>>>>> For example, we might make >>>>>> >>>>>> it >>>>>> >>>>>> somewhat easier for a Contributor to >>>>>> become an Author, or for a >>>>>> Committer to become a Reviewer. I have >>>>>> some thoughts on this, but >>>>>> >>>>>> want >>>>>> >>>>>> to hear from others first. >>>>>> >>>>>> >>>>>> I look forward to feedback on this >>>>>> proposal, and hope it will spark a >>>>>> productive discussion. >>>>>> >>>>>> -- Kevin Rushforth, OpenJFX Project Lead >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> > From herve.girod at gmail.com Wed Feb 7 10:47:00 2018 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Wed, 7 Feb 2018 11:47:00 +0100 Subject: More community participation in JavaFX In-Reply-To: References: <5A786D32.6050600@oracle.com> <5A7A6188.2090608@oracle.com> <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> <90b3cb55e88375f048b1c4eb8f883d8d.squirrel@54.sslprotected.nl> Message-ID: I have coded such a framework in one of my open source projects. I can extract this code and setup a github project for it if people are interested. Herv? Sent from my iPhone > On Feb 7, 2018, at 10:52, John-Val Rose wrote: > > > > Well, not only do I think that a docking framework is *that* complex, I see it as an essential part of any serious graphics toolkit. > > In general, I don?t understand all the limitations that people keep imposing on JavaFX as if we have to ?settle? for what is basically a 2nd class citizen compared with toolkits in other languages. > > Why can?t we just make JavaFX so compelling that developers from other languages are enticed by the feature set itself? There is no reason (other than a lack of effort) why JavaFX cannot be on par with Qt or Xamarin in terms of features, performance, tooling and adoption. > > Am I the only one that believes the world?s most popular and amazing programming language, platform and the JVM deserves a first class graphics toolkit? > > I understand the constraints imposed on Oracle staff but isn?t there anyone else out there in the community who shares my vision for JavaFX? > > It seems the general attitude is that JavaFX just needs to be a ?better Swing?. > > Forget about this nonsense of ?thinking outside the box?. > > There is NO BOX! > > JavaFX can and should be the best that we as a community can make it. > > And then we just keep making it better... > > If we don?t adopt such a vision and attitude then what is the point of doing anything at all? Just leave JavaFX to rot into oblivion and relegate Java to a server-side language only. > > > >> On 7 Feb 2018, at 19:25, Tom Eugelink wrote: >> >> Well, I believe he was hinting at that a docking framework is considered >> more complex, there was no negative sentiment in that. Although I do not >> think a docking framework is that complex, but maybe I'm wrong. >> >> And yes, ALMOST everyone is at ControlFX ;-) >> >> >> >>> Jonathan - why do you *cough* at ideas like more complex controls and >>> docking frameworks? >>> >>> I think that a docking framework especially would be a great addition to >>> JavaFX. >>> >>> Am I missing something? >>> >>>> On 7 Feb 2018, at 18:16, Jonathan Giles >>>> wrote: >>>> >>>> Obviously everyone is at ControlsFX instead ;-) >>>> >>>> Part of the drop I would suggest is simply that many of the itches >>>> people >>>> want to scratch are now scratched. Alternatively, the remaining itches >>>> are >>>> either in more complex controls (*cough* docking frameworks *cough*) or >>>> in >>>> areas beneath the controls APIs - performance, webview, etc - which are >>>> more challenging and require greater levels of dedication. >>>> >>>> However, more generally, your point is well made - contribution to >>>> JavaFX >>>> does not need to be synonymous with contribution to OpenJFX. People who >>>> find the challenges of the current OpenJFX requirements too great should >>>> be >>>> encouraged to involve themselves in projects such as JFXtras, etc. >>>> >>>> -- Jonathan >>>> >>>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >>>>> >>>>> Many years ago I had a discussion with Jonathan Giles about if the >>>>> things >>>>> that were being made in JFXtras would eventually become part of the >>>>> JavaFX >>>>> core. In the end I decided that, for me personally, I could do the >>>>> things I >>>>> wanted to perfectly in a separate project. The rigid structure that >>>>> Java(FX) has to adhere to, would be a big downside. >>>>> >>>>> What I want to say with that is that all the external projects are also >>>>> contributions to JavaFX. It does not matter whether for example a >>>>> control >>>>> is part of the core distribution or of a side project; it is just >>>>> another >>>>> module users can add to the mix. >>>>> >>>>> So reflecting back I still stand by that choice. But having a few more >>>>> people in the project (just like in JavaFX ;-) ) would be nice, but >>>>> OTOH it >>>>> forces me to deal with (and learn about) annoying stuff like Gradle >>>>> build >>>>> scripts and Java 9 migration. But because of that progress is not as >>>>> fast >>>>> as I would like it to be. Could it be that there is a decline in people >>>>> willing to work for open source projects? Or is it just that this tech, >>>>> JavaFX, is no longer appealing? >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>> Obviously everyone is at ControlsFX instead ;-) >>>> >>>> Part of the drop I would suggest is simply that many of the itches >>>> people >>>> want to scratch are now scratched. Alternatively, the remaining itches >>>> are >>>> either in more complex controls (*cough* docking frameworks *cough*) or >>>> in >>>> areas beneath the controls APIs - performance, webview, etc - which are >>>> more challenging and require greater levels of dedication. >>>> >>>> However, more generally, your point is well made - contribution to >>>> JavaFX >>>> does not need to be synonymous with contribution to OpenJFX. People who >>>> find the challenges of the current OpenJFX requirements too great should >>>> be >>>> encouraged to involve themselves in projects such as JFXtras, etc. >>>> >>>> -- Jonathan >>>> >>>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >>>>> >>>>> Many years ago I had a discussion with Jonathan Giles about if the >>>>> things >>>>> that were being made in JFXtras would eventually become part of the >>>>> JavaFX >>>>> core. In the end I decided that, for me personally, I could do the >>>>> things I >>>>> wanted to perfectly in a separate project. The rigid structure that >>>>> Java(FX) has to adhere to, would be a big downside. >>>>> >>>>> What I want to say with that is that all the external projects are also >>>>> contributions to JavaFX. It does not matter whether for example a >>>>> control >>>>> is part of the core distribution or of a side project; it is just >>>>> another >>>>> module users can add to the mix. >>>>> >>>>> So reflecting back I still stand by that choice. But having a few more >>>>> people in the project (just like in JavaFX ;-) ) would be nice, but >>>>> OTOH it >>>>> forces me to deal with (and learn about) annoying stuff like Gradle >>>>> build >>>>> scripts and Java 9 migration. But because of that progress is not as >>>>> fast >>>>> as I would like it to be. Could it be that there is a decline in people >>>>> willing to work for open source projects? Or is it just that this tech, >>>>> JavaFX, is no longer appealing? >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>>>> On 7-2-2018 03:16, Kevin Rushforth wrote: >>>>>> >>>>>> I would recommend against having a separate issue tracker or mailing >>>>>> list >>>>>> associated with the sandbox. That will create more confusion than any >>>>>> benefit you might have. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Nir Lisker wrote: >>>>>> >>>>>>> Another thing to be careful about with the sandbox/staging idea is >>>>>>> the >>>>>>> confusion that will arise with duplication. There will be 2 issue >>>>>>> trackers >>>>>>> (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and >>>>>>> maybe 2 >>>>>>> discussion lists. For those "in the know" this will be a simple >>>>>>> matter, but >>>>>>> for a potential contributor this can be a gamebreaker if not handled >>>>>>> appropriately. >>>>>>> >>>>>>> Dalibor Topic's suggestion of contacting other mirrors can be >>>>>>> instrumental in solving these problems. >>>>>>> >>>>>>> - Nir >>>>>>> >>>>>>> On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth < >>>>>>> kevin.rushforth at oracle.com > >>>>>>> wrote: >>>>>>> >>>>>>> Yes, this sounds like a good step in the right direction. This >>>>>>> would give anyone (with a signed OCA) the ability to create their >>>>>>> own branch, commit changes to it, submit a PR, etc. >>>>>>> >>>>>>> I presume there will be a branch that is an exact mirror of the >>>>>>> jfx-dev repo on OpenJDK in addition to the development branch in >>>>>>> the sandbox? >>>>>>> >>>>>>> The only thing to consider is whether it should be Committers or >>>>>>> Reviewers that have rights to merge into the sandbox development >>>>>>> branch. There are pros / cons of each. I'd probably lean towards >>>>>>> having it be Committers, with the idea that a Committer needs to >>>>>>> sponsor the patch anyway and would then be able to "take it the >>>>>>> rest of the way". The only downside I see is that you could end up >>>>>>> with a few patches that get accepted into the sandbox dev branch, >>>>>>> but never make it to the upstream jfx-dev repo (or not without >>>>>>> significant change). I doubt this will be a big problem in >>>>>>> practice. >>>>>>> >>>>>>> Either way, this could also provide a good alternative to webrev >>>>>>> when reviewing the final changes. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Johan Vos wrote: >>>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>> This proposal is very much in line with my thinking as well. >>>>>>> The problem is not that we don't have a github clone of >>>>>>> OpenJFX. We have a >>>>>>> number of them (e.g. I created >>>>>>> https://github.com/javafxports/jfx-dev >>>>>>> some >>>>>>> months ago). We just need a single one that is updated >>>>>>> constantly from >>>>>>> mainstream, and standardize on that. Let's call that "sandbox" >>>>>>> (I would be >>>>>>> ok with staging as well, but sandbox is imho more inviting to >>>>>>> people who >>>>>>> want to try something drastic, e.g. support for Vulkan) >>>>>>> >>>>>>> The main issue is how to get contributions, review them, and >>>>>>> eventually >>>>>>> send them upstream. >>>>>>> >>>>>>> The PR review process is extremely important. If we lower that >>>>>>> bar, we >>>>>>> loose quality. If the bar is too high, great PR's won't be >>>>>>> accepted >>>>>>> upstream as there is not enough review time to review it. >>>>>>> >>>>>>> I agree giving the current OpenJFX committers merge rights for >>>>>>> the >>>>>>> "sandbox" repository makes sense. Once a public contribution >>>>>>> is merged by >>>>>>> one of those committers, that same committer can send it >>>>>>> upstream to the >>>>>>> existing OpenJFX repository. Additional checks will be >>>>>>> performed there, >>>>>>> mainly in order to make sure the overall "Feel of Java" is >>>>>>> preserved. To >>>>>>> that purpose, it would help to have a closer alignment with >>>>>>> the OpenJDK >>>>>>> community. >>>>>>> >>>>>>> We have to be aware that this will increase the workload of >>>>>>> the current >>>>>>> committers and reviewers. That is the price we pay for >>>>>>> standardization. >>>>>>> Rather than everyone creating his own forks of a UI framework >>>>>>> in Java, we >>>>>>> invest a lot in creating a single, generally agreed one. >>>>>>> >>>>>>> So in summary, I'm +1 on a 2-phase approach: "open" commits >>>>>>> allowed in >>>>>>> staging. OpenJFX committers accept PR's (if they are of good >>>>>>> quality) and >>>>>>> prepare upstream commits for OpenJFX. We hope there will be >>>>>>> more >>>>>>> contributors who become committers and reviewers in the medium >>>>>>> term. >>>>>>> >>>>>>> - Johan >>>>>>> >>>>>>> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen >>>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> Those are great questions, and I think with >>>>>>> Kevin/Oracle/other OpenJFX devs >>>>>>> help we >>>>>>> can figure something out. >>>>>>> >>>>>>> My thinking is that the PR would be reviewed by basically >>>>>>> anyone who has >>>>>>> free time. >>>>>>> I think that, at first, only OpenJFX committers will be >>>>>>> able to merge PRs. >>>>>>> They would >>>>>>> do the final review/merge to the staging repo after it has >>>>>>> been reviewed by >>>>>>> the "wider audience" >>>>>>> which includes people without commit rights (people like >>>>>>> us). Then, as this >>>>>>> thing evolves, >>>>>>> based on the pool of people who are contributing both pull >>>>>>> requests and PR >>>>>>> reviews, >>>>>>> the committers will be able to grant commit privileges to >>>>>>> some people in >>>>>>> that pool. >>>>>>> >>>>>>> I can't think of any way that would make it so the changes >>>>>>> are as likely to >>>>>>> be >>>>>>> merged upstream as possible other than having the current >>>>>>> OpenJFX >>>>>>> committers paving the >>>>>>> way. Hopefully this vision is aligned with Kevin's and >>>>>>> hopefully these >>>>>>> concrete details >>>>>>> can be worked out. >>>>>>> >>>>>>> Regards, >>>>>>> Michael >>>>>>> >>>>>>> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker >>>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> So if a community ran GitHub is used for staging, who >>>>>>> will approve PRs >>>>>>> >>>>>>> for >>>>>>> >>>>>>> the code and the Wiki of the GitHub repo? >>>>>>> >>>>>>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Great points, Nir. We share the same hopes. I just >>>>>>> wanted to piggy-back >>>>>>> on the >>>>>>> wiki thing: >>>>>>> >>>>>>> " * The Wiki could be open sourced as well (like >>>>>>> other Wikis). I could >>>>>>> definitely update a page or 2 there and so would >>>>>>> other developers as >>>>>>> >>>>>>> they >>>>>>> >>>>>>> gain knowledge. I don't know yet how permissions >>>>>>> for that should be >>>>>>> handled." >>>>>>> >>>>>>> This is another thing that we could use the GitHub >>>>>>> staging repository >>>>>>> >>>>>>> for. >>>>>>> >>>>>>> The staging repository could have a wiki (projects >>>>>>> on GitHub can have >>>>>>> >>>>>>> one) >>>>>>> >>>>>>> that is editable by all, and then maybe once a >>>>>>> month or so someone with >>>>>>> permissions >>>>>>> to edit to official wiki can sync with the new, >>>>>>> reviewed changes (the >>>>>>> once-a-month >>>>>>> time constraint is very flexible). >>>>>>> >>>>>>> I am just trying to explain how the GitHub >>>>>>> repository "one-way mirror" >>>>>>> (potentially linked >>>>>>> with/managed by Adopt an OpenJDK) can act as a >>>>>>> staging ground for all >>>>>>> kinds of contributions to >>>>>>> OpenJFX. >>>>>>> >>>>>>> By the way, I am trying to cleanup the groundwork >>>>>>> I did on getting >>>>>>> Appveyor builds to >>>>>>> run for openjfx, if indeed it is decided to setup >>>>>>> such a staging >>>>>>> repository. You can >>>>>>> see my efforts here: >>>>>>> https://raw.githubusercontent. >>>>>>> >>>>>>> >>>>>>> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057 >>>>>>> /appveyor.yml >>>>>>> >>>>>>> If the GitHub repository was setup, changes such >>>>>>> as these to add CI >>>>>>> infrastructure would >>>>>>> never be adopted by upstream OpenJFX, but would >>>>>>> allow for developer's to >>>>>>> get good >>>>>>> feedback on test results for all supported >>>>>>> platforms when they open a >>>>>>> >>>>>>> PR. >>>>>>> >>>>>>> Merging a PR >>>>>>> on the public GitHub repository means, in my >>>>>>> opinion, that it is ready >>>>>>> >>>>>>> to >>>>>>> >>>>>>> be opened as >>>>>>> an upstream bug/feature request. Automating the >>>>>>> process with patch sets, >>>>>>> webrevs, formatting/lint >>>>>>> results, etc. would be the most ideal situation >>>>>>> and I would be happy to >>>>>>> contribute to these >>>>>>> efforts. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> As someone who has recently made the climb and >>>>>>> managed to build OpenJFX >>>>>>> with OpenJDK on Win 10 I might have some >>>>>>> relevant input. >>>>>>> >>>>>>> --- Building OpenJFX --- >>>>>>> >>>>>>> * With the recently updated instructions on >>>>>>> the Wiki, building OpenJFX >>>>>>> >>>>>>> is >>>>>>> >>>>>>> not that hard. Having to build OpenJDK for >>>>>>> that was a real headache >>>>>>> because >>>>>>> their instructions and build tools are not up >>>>>>> to date ( >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8194645 >>>>>>> ). >>>>>>> * The above doesn't mean that the process >>>>>>> shouldn't be made easier. >>>>>>> Ideally, it would be the as easy as working on >>>>>>> most open source >>>>>>> >>>>>>> projects >>>>>>> >>>>>>> on >>>>>>> Github (not advocating git over hg): clone >>>>>>> into the IDE and start >>>>>>> working; >>>>>>> when a fix is ready, submit a PR. Don't know >>>>>>> if it's technically >>>>>>> >>>>>>> possible >>>>>>> >>>>>>> in this case, but it's a target. >>>>>>> * The repository needs a good cleanup before >>>>>>> contributors start >>>>>>> >>>>>>> cloning ( >>>>>>> >>>>>>> bugs.openjdk.java.net/browse/JDK-8196198 >>>>>>> ). >>>>>>> >>>>>>> --- Working on OpenJFX --- >>>>>>> >>>>>>> * It should be clear which tests need to run >>>>>>> for a specific patch. >>>>>>> Changes >>>>>>> can be made anywhere from the documentation >>>>>>> level to native code level >>>>>>> and >>>>>>> there's no reason to run the same tests for >>>>>>> all of these. If the >>>>>>> >>>>>>> process >>>>>>> >>>>>>> can be automate it's even better. >>>>>>> * The Webrev tool seems archaic to me (and >>>>>>> part of its output is broken >>>>>>> as >>>>>>> far as I could tell). An IDE can create diff >>>>>>> patches with a couple of >>>>>>> clicks. >>>>>>> * The Jcheck tool seems archaic to me. It >>>>>>> should be ported to IDE >>>>>>> formatters which are to be distributed with >>>>>>> the source. No reason to >>>>>>> >>>>>>> run >>>>>>> >>>>>>> a >>>>>>> tool that tells me which whitespaces I need to >>>>>>> go back and change when >>>>>>> something like Ctrl+Shift+F in an IDE finishes >>>>>>> the job. >>>>>>> >>>>>>> --- Wiki --- >>>>>>> >>>>>>> * The Wiki could be open sourced as well (like >>>>>>> other Wikis). I could >>>>>>> definitely update a page or 2 there and so >>>>>>> would other developers as >>>>>>> >>>>>>> they >>>>>>> >>>>>>> gain knowledge. I don't know yet how >>>>>>> permissions for that should be >>>>>>> handled. >>>>>>> * Code conventions should be clearly listed. >>>>>>> * Separate sections with instructions should >>>>>>> be made for: (1) cloning >>>>>>> >>>>>>> and >>>>>>> >>>>>>> building, (2) modifying, (3) running tests, >>>>>>> (4) submitting, and (5) >>>>>>> reviewing. >>>>>>> * Old sections should be cleaned up (I don't >>>>>>> think Discussions is >>>>>>> >>>>>>> useful >>>>>>> >>>>>>> anymore). >>>>>>> >>>>>>> --- Review policy --- >>>>>>> >>>>>>> * I have no experience with review policies or >>>>>>> project roles so I can't >>>>>>> help here much (maybe after a discussion >>>>>>> starts). >>>>>>> * One thing I do know is that reviewers should >>>>>>> be extremely >>>>>>> knowledgeable, >>>>>>> which means that there aren't many qualified. >>>>>>> Because of this, if it >>>>>>> becomes "too" easy to contribute to OpenJFX, >>>>>>> careful measures need to >>>>>>> >>>>>>> be >>>>>>> >>>>>>> taken as to not to swamp the few reviewers >>>>>>> with many patches (though >>>>>>> >>>>>>> some >>>>>>> >>>>>>> would say this is an ideal situation). Some >>>>>>> sort of review queue might >>>>>>> help >>>>>>> with organization instead of the current email >>>>>>> system. I have no >>>>>>> >>>>>>> concrete >>>>>>> >>>>>>> solution for this. >>>>>>> >>>>>>> - Nir >>>>>>> >>>>>>> >>>>>>> Message: 1 >>>>>>> >>>>>>> Date: Thu, 01 Feb 2018 15:26:24 -0800 >>>>>>> From: Kevin Rushforth >>>>>>> >>>>>> > >>>>>>> To: "openjfx-dev at openjdk.java.net >>>>>>> " >>>>>>> >>>>>> > >>>>>>> Subject: More community participation in >>>>>>> JavaFX >>>>>>> Message-ID: <5A73A220.7030706 at oracle.com >>>>>>> > >>>>>>> Content-Type: text/plain; >>>>>>> charset=windows-1252; format=flowed >>>>>>> >>>>>>> To: OpenJFX Developers >>>>>>> >>>>>>> We are looking to grow the community of >>>>>>> contributors to the OpenJFX >>>>>>> project, especially serious contributors >>>>>>> who will stick around long >>>>>>> enough to become reviewers, to help us >>>>>>> keep the platform vibrant. To >>>>>>> this end we are looking at ways to >>>>>>> encourage more participation and >>>>>>> >>>>>>> make >>>>>>> >>>>>>> it easier for interested folks to >>>>>>> contribute. >>>>>>> >>>>>>> We are specifically looking to discuss >>>>>>> ideas around the following >>>>>>> >>>>>>> areas: >>>>>>> >>>>>>> * Easing barriers to contribution (e.g., >>>>>>> making JavaFX easier to >>>>>>> >>>>>>> build, >>>>>>> >>>>>>> better documentation, making it easier to >>>>>>> test changes) >>>>>>> >>>>>>> * Code review policies >>>>>>> >>>>>>> * API / feature review policies >>>>>>> >>>>>>> * Code review tools (we currently use >>>>>>> webrev, but that isn't set in >>>>>>> >>>>>>> stone) >>>>>>> >>>>>>> To keep this thread productive, the >>>>>>> following are explicitly out of >>>>>>> >>>>>>> scope: >>>>>>> >>>>>>> * Discussion of specific features or bugs >>>>>>> that you would like to >>>>>>> implement (or wish someone else would) >>>>>>> >>>>>>> * Discussion about platform support >>>>>>> >>>>>>> * Discussion about version control systems >>>>>>> (e.g., hg versus git), >>>>>>> hosting of the OpenJFX repos and bug >>>>>>> database (e.g., OpenJDK versus >>>>>>> github), etc...at least for now. We are >>>>>>> aware of the potential >>>>>>> >>>>>>> benefits >>>>>>> >>>>>>> of such changes, but we'd like to focus >>>>>>> our efforts on >>>>>>> >>>>>>> higher-leverage >>>>>>> >>>>>>> things we can do in the short term. >>>>>>> >>>>>>> * Discussion about the requirement of a >>>>>>> signed OCA to become a >>>>>>> >>>>>>> contributor >>>>>>> >>>>>>> * Off-topic or tangential commentary about >>>>>>> OpenJFX that isn't >>>>>>> >>>>>>> directly >>>>>>> >>>>>>> related to the topic at hand >>>>>>> >>>>>>> >>>>>>> As a starting point for discussion, here >>>>>>> are some areas I think need >>>>>>> improvement; I'm sure there are others: >>>>>>> >>>>>>> I. Helping contributors get started >>>>>>> >>>>>>> It isn?t as easy to get started with >>>>>>> OpenJFX as it should be. We want >>>>>>> >>>>>>> to >>>>>>> >>>>>>> make it easier for potential OpenJFX >>>>>>> contributors to get started. >>>>>>> >>>>>>> Here >>>>>>> >>>>>>> are some ideas that I think might help: >>>>>>> >>>>>>> * Improve the build instructions / Wiki (I >>>>>>> made a first start, but >>>>>>> >>>>>>> there >>>>>>> >>>>>>> is much more to be done) >>>>>>> >>>>>>> * Make the build itself more resilient >>>>>>> where possible, and provide >>>>>>> better error messages, specifically when >>>>>>> dealing with native >>>>>>> >>>>>>> compilers >>>>>>> >>>>>>> and libraries >>>>>>> >>>>>>> * Add an option to skip building all >>>>>>> native code and use prebuilt >>>>>>> binaries (like we do already for media and >>>>>>> webkit); this is tracked >>>>>>> >>>>>>> by >>>>>>> >>>>>>> JDK-8092279, but it hasn?t been looked at >>>>>>> recently >>>>>>> >>>>>>> * Make it easier to build / test your >>>>>>> local OpenJFX build using an >>>>>>> OpenJDK build (currently the only way to >>>>>>> do this is to build OpenJDK >>>>>>> locally, after using configure to point to >>>>>>> your just-built javafx.* >>>>>>> modules). >>>>>>> >>>>>>> * Provide step-by-step instructions for >>>>>>> how to make a contribution, >>>>>>> including testing requirements; a lot of >>>>>>> the pieces are there, but >>>>>>> >>>>>>> are >>>>>>> >>>>>>> out of date or scattered in several >>>>>>> places. As part of this, we could >>>>>>> have a section on how to contribute docs, >>>>>>> samples or tests, since >>>>>>> >>>>>>> that >>>>>>> >>>>>>> is often a good place to start. >>>>>>> >>>>>>> * Provide a sandbox environment where >>>>>>> contributors can discuss and >>>>>>> >>>>>>> test >>>>>>> >>>>>>> ideas. For example, an OpenJFX mirror on >>>>>>> github, potentially >>>>>>> >>>>>>> connected >>>>>>> >>>>>>> to AdoptOpenJDK. >>>>>>> >>>>>>> >>>>>>> II. Code reviews and API reviews >>>>>>> >>>>>>> Code reviews are important to maintain >>>>>>> high-quality contributions, >>>>>>> >>>>>>> but >>>>>>> >>>>>>> we recognize that not every type of change >>>>>>> needs the same level of >>>>>>> review. Without lowering our standards of >>>>>>> quality, we want to make it >>>>>>> easier to get low-impact changes (simple >>>>>>> bug fixes) accepted. >>>>>>> >>>>>>> There are three categories of changes, >>>>>>> each of which might merit a >>>>>>> different review standard: >>>>>>> >>>>>>> 1. Low-impact bug fixes. These are >>>>>>> typically isolated bug fixes with >>>>>>> little or no impact beyond fixing the bug >>>>>>> in question; included in >>>>>>> >>>>>>> this >>>>>>> >>>>>>> category are test fixes (including new >>>>>>> tests) doc fixes, and fixes to >>>>>>> sample applications (including new >>>>>>> samples). >>>>>>> >>>>>>> 2. Higher impact bug fixes or RFEs. These >>>>>>> include changes to the >>>>>>> implementation that potentially have a >>>>>>> performance or behavioral >>>>>>> >>>>>>> impact, >>>>>>> >>>>>>> or are otherwise broad in scope. Some >>>>>>> larger bug fixes will fall into >>>>>>> this category, as will fixes in high-risk >>>>>>> areas (e.g., CSS). >>>>>>> >>>>>>> 3. New features / API additions. In >>>>>>> addition to reviewing the >>>>>>> implementation, we will need a separate >>>>>>> approval process for the new >>>>>>> >>>>>>> API >>>>>>> >>>>>>> / feature (such as the CSR, which is what >>>>>>> we use now, or a similar >>>>>>> process). >>>>>>> >>>>>>> We take compatibility seriously, so >>>>>>> anything that adds new API needs >>>>>>> >>>>>>> to >>>>>>> >>>>>>> be done with an eye towards supporting it >>>>>>> for at least 10 years. We >>>>>>> don't want to add new public API without >>>>>>> that level of commitment. >>>>>>> >>>>>>> Every >>>>>>> >>>>>>> new feature forecloses on alternate future >>>>>>> features. Significant >>>>>>> >>>>>>> effort >>>>>>> >>>>>>> must be taken to think about "if we did >>>>>>> this, what could it interact >>>>>>> with in the future?" Also, anything with a >>>>>>> large potential impact on >>>>>>> performance or behavioral compatibility >>>>>>> needs to be looked at >>>>>>> >>>>>>> carefully. >>>>>>> >>>>>>> Put another way, we want to encourage >>>>>>> thinking about new features or >>>>>>> >>>>>>> new >>>>>>> >>>>>>> API in terms of a design / stewardship >>>>>>> process; to think in terms of >>>>>>> questions like "what's the right thing for >>>>>>> JavaFX in the next 10+ >>>>>>> >>>>>>> years" >>>>>>> >>>>>>> rather than "here's some code that solves >>>>>>> my problem, please take >>>>>>> >>>>>>> it". >>>>>>> >>>>>>> As a stake in the ground, I might suggest >>>>>>> the following: >>>>>>> >>>>>>> * All changes need at least one reviewer >>>>>>> other than the person making >>>>>>> the change who can evaluate the change for >>>>>>> correctness and >>>>>>> >>>>>>> consistency. >>>>>>> >>>>>>> For simple bug fixes, a single reviewer >>>>>>> may be sufficient. Of course, >>>>>>> one of our big challenges in all this is: >>>>>>> "how do we grow more >>>>>>> reviewers?", by which I mean "how do we >>>>>>> facilitate getting >>>>>>> >>>>>>> contributors >>>>>>> >>>>>>> with enough expertise in a given area to >>>>>>> eventually be able to >>>>>>> effectively review contributions from >>>>>>> others?" >>>>>>> >>>>>>> * We need clear criteria for the other two >>>>>>> categories that balance >>>>>>> process efficiency with the desire to >>>>>>> maintain compatibility and >>>>>>> stability. API changes need to be approved >>>>>>> by a lead. My thought is >>>>>>> >>>>>>> to >>>>>>> >>>>>>> combine the last two into a single >>>>>>> category for purposes of reviewing >>>>>>> the implementation. Anything that affects >>>>>>> public API or behavioral >>>>>>> compatibility will require CSR or similar >>>>>>> approval, over and above >>>>>>> >>>>>>> the >>>>>>> >>>>>>> implementation review, which seems >>>>>>> sufficient. >>>>>>> >>>>>>> * I recommend that we formalize the >>>>>>> concept of reviewers, using the >>>>>>> OpenJDK Reviewer role for the Project. We >>>>>>> might also consider if we >>>>>>> >>>>>>> want >>>>>>> >>>>>>> to make any changes to the criteria used >>>>>>> by the JDK Project for >>>>>>> >>>>>>> becoming >>>>>>> >>>>>>> an OpenJFX Project Author, Committer, and >>>>>>> Reviewer. The OpenJDK >>>>>>> >>>>>>> bylaws >>>>>>> >>>>>>> allow projects a fair degree of latitude >>>>>>> to define these criteria, so >>>>>>> >>>>>>> we >>>>>>> >>>>>>> might consider making some modifications. >>>>>>> For example, we might make >>>>>>> >>>>>>> it >>>>>>> >>>>>>> somewhat easier for a Contributor to >>>>>>> become an Author, or for a >>>>>>> Committer to become a Reviewer. I have >>>>>>> some thoughts on this, but >>>>>>> >>>>>>> want >>>>>>> >>>>>>> to hear from others first. >>>>>>> >>>>>>> >>>>>>> I look forward to feedback on this >>>>>>> proposal, and hope it will spark a >>>>>>> productive discussion. >>>>>>> >>>>>>> -- Kevin Rushforth, OpenJFX Project Lead >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> >> From sdesofi at icloud.com Wed Feb 7 12:08:57 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Wed, 07 Feb 2018 07:08:57 -0500 Subject: future content of OpenJFX In-Reply-To: References: <09a2b76c-c11b-474e-b4d9-a3bf36386424@me.com> Message-ID: <0F0ECF45-A6E4-4E01-BDEA-DA863B24A4A1@icloud.com> Johan, I actually enjoy reading your ?business talk?. It?s very enlightening. I had no idea that the FX team was such a small band of gypsies. In fact I?m shocked that such a large industry can be powered by such a small team and not realize it themselves. But how could they know? I?m much closer this and care more than most and I didn?t know either. The lessons I?m learning right now I?m trying to wrap my head around because this team may be representative of most software teams everywhere. How could so few do so much for all of humanity on so many different levels and yet the whole world hasn?t got a clue. It deserves some thought. Steve Sent from my iPhone > On Feb 7, 2018, at 2:47 AM, Johan Vos wrote: > > While it's good to know who is interested in what areas, I think it's hard to create a list of interested or capable people as that depends on motivations. > There are many developers who used to work on the JavaFX team who are now working elsewhere. That means there is plenty of knowledge and potential in the world. I don't see a problem there. > > I hate to sound like a business-first person, but I think the question is rather how many business is there in JavaFX? We can all do some things in our spare time (and most of us do), but in the end moving the platform forward requires more than this. It requires people working full-time on it, hence being paid to do this. > > Now, all indications show that there is a big interest in JavaFX. For example, we see the download numbers of Scene Builder still increasing (about 30K downloads/month). JavaFX is much more popular on Google Trends now than Swing. > > One of the main problems is that JavaFX is used in "hidden" areas (see http://gluonhq.com/javafx-hidden-economy/) > If only 1% of the money spent by companies on JavaFX could be used to maintain the core, we would be in a good shape, I believe. > > But moving back to "the future content": rather than guessing "I'ld like to have that" it would be interesting to know what companies want to pay for. The hard thing is then that most of the work on the OpenJFX core is beyond the surface of what companies see, so translating those business requirements into technical ones is not always trivial. > > Enough business talk for now, back to development :) > > - Johan > > > > > > >> On Wed, Feb 7, 2018 at 1:24 AM Stephen Desofi wrote: >> +1 >> >> This makes sense. Having a list of who might be willing to contribute and in what areas they are willing to contribute dictates where we can go. As Rumsfeld once said "You go to war with the army have, not the one you want". >> >> Steve >> >> Sent from iCloud >> >>> On Feb 06, 2018, at 06:41 AM, John-Val Rose wrote: >>> >> >>> Maybe Kevin could request that anyone who is seriously both willing and capable to contribute to OpenJFX email him privately so that the list doesn?t get to ?see? anyone who wants to fly under the radar. >>> >>> Kevin could then post the approximate number of resources actually available. >>> >>> I realise of course that some people may not wish to even let Kevin know of their interest and availability initially but at least we would have a ballpark figure as to the size of the ?talent pool?. >>> >>> I think we need to have some handle on this number before any significant set-up work is undertaken (just in case the number is only 2 or 3 for example instead of 20 or so). >>> >>>> On 6 Feb 2018, at 22:12, Stephen Desofi wrote: >>>> >>>> A poll would definitely be useful because we may find ourselves another subset. >>>> >>>> The subset of people who even want to go ?off road? to begin with. Most people only consider going places where the road already leads?and that might be about 99%. >>>> >>>> >>>> >> >>>> Sent from my iPhone >>>> >> >>>>> On Feb 5, 2018, at 11:14 PM, John-Val Rose wrote: >>>>> >>>>> I think there?s a small matter that is being overlooked here. >>>>> >>>>> The size of the ?talent pool?. >>>>> >>>>> I?m just pulling numbers out of thin air here but first I?m guessing that the vast majority of JavaFX users do *not* read this list. >>>>> >>>>> Then, out of those who do, only some *care* enough to contribute. >>>>> >>>>> Out of those, only some are *competent* enough to contribute. >>>>> >>>>> And then, out of that much smaller set, only an even smaller subset are in a situation that *permits* them to contribute, either because they have well-paid jobs and a bit of spare time or they really need a feature added for their own use. >>>>> >>>>> Given that I don?t know what the ?starting? number is (the total number of JavaFX users) and neither do I know what fraction to apply to each smaller subset, the end result (the talent pool) is potentially only a handful of people. >>>>> >>>>> I?m simply mentioning this because in every discussion we have here regarding innovation, community participation or plans for new features, it looks like the same group of people get involved - and it?s not exactly a ?crowd?. >>>>> >>>>> Does this mean that we don?t have a ?critical mass? or is it possible that there are lots and lots of ?observers? or ?lurkers? out there just waiting until all the hard work of setting-up the physical and formal infrastructure to enable community contribution has been finalised before they?ll put their hands up? >>>>> >>>>> Maybe we could take a poll to see how many members of the community would be willing AND able to contribute, knowing that they may not necessarily end up working on features they are interested in AND who are prepared for their contribution itself & the value it adds to JavaFX to be their only tangible reward? >>>>> >>>>>> On 6 Feb 2018, at 11:23, Stephen Desofi wrote: >>>>>> >>>>>> Hi Johan, >>>>>> >>>>>> I read the article you linked to (http://www.tomitribe.com/blog/2013/11/feed-the-fish/) and it raises some very good points indeed. >>>>>> >>>>>> I also spent a little time thinking over your list of interests: >> >>>>>> * more alignment with mobile >> >>>>>> * a clean and lean low-level rendering pipeline API that would allow easier >>>>>> plugability with upcoming low-level rendering systems >>>>>> * extensions for Chart API >>>>>> >>>>>> Those would be high on my list as well, but there is something else I'd like to throw into the equation. >>>>>> >>>>>> If somebody can contribute money to fund the development of their wishlist, fine, that's the easy part, but asking people to contribute time is a bit more complicated. For example, I may want "more alignment with mobile", but I may be better qualified to contribute "extensions for the Chart API" even though that isn't my primary motivator. >>>>>> >>>>>> Often the reason we want something is because we haven't the skills to do it ourself, but we have skills to do other things. How can situations such as this be factored into the equation? It seems like we need a way to "trade". >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> >>>>>> Sent from iCloud >>>>>> >> >>>>>> On Feb 05, 2018, at 12:07 PM, Johan Vos wrote: >>>>>> >>>>>> In order to separate the "What" from the "How" (discussed in another >>>>>> thread), I would like to start a discussion about what people think should >>>>>> be considered for future JavaFX work. >>>>>> >>>>>> I'd like to start with what I think is an important note on the context. >>>>>> If I want feature X in JavaFX, I ask myself two questions: >>>>>> 1. Do I want to contribute time and do it (at least for a large part) >>>>>> myself? >>>>>> 2. Do I want to spend money on it? >>>>>> >>>>>> If that sounds too economic or commercial, I recommend reading the >>>>>> excellent blog entry by David Blevins about funding Java EE development >>>>>> (more than 4 years old and still very relevant): >>>>>> http://www.tomitribe.com/blog/2013/11/feed-the-fish/ >>>>>> >>>>>> Actually, this is a model we've been using at Gluon for a number of >>>>>> customers. When people ask us about a specific feature, we ask if they are >>>>>> willing to pay us for the development, AND if they are ok with us donating >>>>>> it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX, >>>>>> JavaFXports, Gluon Charm Down, Gluon Maps,...). >>>>>> As a consequence, the features we are working on are all relevant to (at >>>>>> least a part of) the industry. Some companies doubt there is business value >>>>>> in JavaFX, we prove the opposite while making the Open Source community >>>>>> better. >>>>>> >>>>>> I think by now it should be clear to all that there is no free lunch >>>>>> (anymore). If your business depends on a feature being added to JavaFX, how >>>>>> much (time/money) are you willing to contribute? If the answer is >>>>>> "nothing", you can still hope that others want to do it, and in many cases >>>>>> that will eventually happen -- but you don't control the timeline. >>>>>> >>>>>> This principle is a bit a simplification though. In many practical cases, >>>>>> people want to have feature X and are willing to contribute "something" >>>>>> (e.g. they want to work on it in spare-time, or fund 20% of a developer) >>>>>> but not enough to do everything. >>>>>> I think in this case it's a matter of gathering enough interest in this >>>>>> community. Once enough developers are interested in that same feature, and >>>>>> agree to spend resources on it, the burden can be shared. Having a sandbox >>>>>> repositories with forks will make this easier. >>>>>> >>>>>> Areas that I personally want to see on the roadmap: >>>>>> * more alignment with mobile >>>>>> * a clean and lean low-level rendering pipeline API that would allow easier >>>>>> plugability with upcoming low-level rendering systems >>>>>> * extensions for Chart API >>>>>> >>>>>> - Johan >>>>>> From johan.vos at gluonhq.com Wed Feb 7 12:33:26 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 07 Feb 2018 12:33:26 +0000 Subject: future content of OpenJFX In-Reply-To: <0F0ECF45-A6E4-4E01-BDEA-DA863B24A4A1@icloud.com> References: <09a2b76c-c11b-474e-b4d9-a3bf36386424@me.com> <0F0ECF45-A6E4-4E01-BDEA-DA863B24A4A1@icloud.com> Message-ID: It's off-topic but very relevant and indeed representative for many projects. Remember heartbleed? Almost the whole IT industry depends on OpenSSL yet didn't fund it. http://money.cnn.com/2014/04/18/technology/security/heartbleed-volunteers/ It it not easy to get funding for fundamental core technologies that empower more visual but less critical technologies. - Johan On Wed, Feb 7, 2018 at 1:09 PM Stephen Desofi wrote: > Johan, > > I actually enjoy reading your ?business talk?. It?s very enlightening. I > had no idea that the FX team was such a small band of gypsies. In fact > I?m shocked that such a large industry can be powered by such a small team > and not realize it themselves. > > But how could they know? I?m much closer this and care more than most > and I didn?t know either. > > The lessons I?m learning right now I?m trying to wrap my head around > because this team may be representative of most software teams everywhere. > > > How could so few do so much for all of humanity on so many different > levels and yet the whole world hasn?t got a clue. It deserves some > thought. > > Steve > > > > Sent from my iPhone > > On Feb 7, 2018, at 2:47 AM, Johan Vos wrote: > > While it's good to know who is interested in what areas, I think it's hard > to create a list of interested or capable people as that depends on > motivations. > There are many developers who used to work on the JavaFX team who are now > working elsewhere. That means there is plenty of knowledge and potential in > the world. I don't see a problem there. > > I hate to sound like a business-first person, but I think the question is > rather how many business is there in JavaFX? We can all do some things in > our spare time (and most of us do), but in the end moving the platform > forward requires more than this. It requires people working full-time on > it, hence being paid to do this. > > Now, all indications show that there is a big interest in JavaFX. For > example, we see the download numbers of Scene Builder still increasing > (about 30K downloads/month). JavaFX is much more popular on Google Trends > now than Swing. > > One of the main problems is that JavaFX is used in "hidden" areas (see > http://gluonhq.com/javafx-hidden-economy/) > If only 1% of the money spent by companies on JavaFX could be used to > maintain the core, we would be in a good shape, I believe. > > But moving back to "the future content": rather than guessing "I'ld like > to have that" it would be interesting to know what companies want to pay > for. The hard thing is then that most of the work on the OpenJFX core is > beyond the surface of what companies see, so translating those business > requirements into technical ones is not always trivial. > > Enough business talk for now, back to development :) > > - Johan > > > > > > > On Wed, Feb 7, 2018 at 1:24 AM Stephen Desofi wrote: > >> +1 >> >> This makes sense. Having a list of who might be willing to contribute >> and in what areas they are willing to contribute dictates where we can go. >> As Rumsfeld once said "You go to war with the army have, not the one you >> want". >> >> Steve >> >> Sent from iCloud >> >> On Feb 06, 2018, at 06:41 AM, John-Val Rose >> wrote: >> >> Maybe Kevin could request that anyone who is seriously both willing and >> capable to contribute to OpenJFX email him privately so that the list >> doesn?t get to ?see? anyone who wants to fly under the radar. >> >> Kevin could then post the approximate number of resources actually >> available. >> >> I realise of course that some people may not wish to even let Kevin know >> of their interest and availability initially but at least we would have a >> ballpark figure as to the size of the ?talent pool?. >> >> I think we need to have some handle on this number before any significant >> set-up work is undertaken (just in case the number is only 2 or 3 for >> example instead of 20 or so). >> >> On 6 Feb 2018, at 22:12, Stephen Desofi wrote: >> >> >> A poll would definitely be useful because we may find ourselves another >> subset. >> >> >> The subset of people who even want to go ?off road? to begin with. Most >> people only consider going places where the road already leads?and that >> might be about 99%. >> >> >> >> >> Sent from my iPhone >> >> >> On Feb 5, 2018, at 11:14 PM, John-Val Rose wrote: >> >> >> I think there?s a small matter that is being overlooked here. >> >> >> The size of the ?talent pool?. >> >> >> I?m just pulling numbers out of thin air here but first I?m guessing that >> the vast majority of JavaFX users do *not* read this list. >> >> >> Then, out of those who do, only some *care* enough to contribute. >> >> >> Out of those, only some are *competent* enough to contribute. >> >> >> And then, out of that much smaller set, only an even smaller subset are >> in a situation that *permits* them to contribute, either because they have >> well-paid jobs and a bit of spare time or they really need a feature added >> for their own use. >> >> >> Given that I don?t know what the ?starting? number is (the total number >> of JavaFX users) and neither do I know what fraction to apply to each >> smaller subset, the end result (the talent pool) is potentially only a >> handful of people. >> >> >> I?m simply mentioning this because in every discussion we have here >> regarding innovation, community participation or plans for new features, it >> looks like the same group of people get involved - and it?s not exactly a >> ?crowd?. >> >> >> Does this mean that we don?t have a ?critical mass? or is it possible >> that there are lots and lots of ?observers? or ?lurkers? out there just >> waiting until all the hard work of setting-up the physical and formal >> infrastructure to enable community contribution has been finalised before >> they?ll put their hands up? >> >> >> Maybe we could take a poll to see how many members of the community would >> be willing AND able to contribute, knowing that they may not necessarily >> end up working on features they are interested in AND who are prepared for >> their contribution itself & the value it adds to JavaFX to be their only >> tangible reward? >> >> >> On 6 Feb 2018, at 11:23, Stephen Desofi wrote: >> >> >> Hi Johan, >> >> >> I read the article you linked to ( >> http://www.tomitribe.com/blog/2013/11/feed-the-fish/) and it raises some >> very good points indeed. >> >> >> I also spent a little time thinking over your list of interests: >> >> * more alignment with mobile >> >> * a clean and lean low-level rendering pipeline API that would allow >> easier >> >> plugability with upcoming low-level rendering systems >> >> * extensions for Chart API >> >> >> Those would be high on my list as well, but there is something else I'd >> like to throw into the equation. >> >> >> If somebody can contribute money to fund the development of their >> wishlist, fine, that's the easy part, but asking people to contribute time >> is a bit more complicated. For example, I may want "more alignment with >> mobile", but I may be better qualified to contribute "extensions for the >> Chart API" even though that isn't my primary motivator. >> >> >> Often the reason we want something is because we haven't the skills to do >> it ourself, but we have skills to do other things. How can situations such >> as this be factored into the equation? It seems like we need a way to >> "trade". >> >> >> Steve >> >> >> >> >> Sent from iCloud >> >> >> On Feb 05, 2018, at 12:07 PM, Johan Vos wrote: >> >> >> In order to separate the "What" from the "How" (discussed in another >> >> thread), I would like to start a discussion about what people think should >> >> be considered for future JavaFX work. >> >> >> I'd like to start with what I think is an important note on the context. >> >> If I want feature X in JavaFX, I ask myself two questions: >> >> 1. Do I want to contribute time and do it (at least for a large part) >> >> myself? >> >> 2. Do I want to spend money on it? >> >> >> If that sounds too economic or commercial, I recommend reading the >> >> excellent blog entry by David Blevins about funding Java EE development >> >> (more than 4 years old and still very relevant): >> >> http://www.tomitribe.com/blog/2013/11/feed-the-fish/ >> >> >> Actually, this is a model we've been using at Gluon for a number of >> >> customers. When people ask us about a specific feature, we ask if they are >> >> willing to pay us for the development, AND if they are ok with us donating >> >> it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX, >> >> JavaFXports, Gluon Charm Down, Gluon Maps,...). >> >> As a consequence, the features we are working on are all relevant to (at >> >> least a part of) the industry. Some companies doubt there is business >> value >> >> in JavaFX, we prove the opposite while making the Open Source community >> >> better. >> >> >> I think by now it should be clear to all that there is no free lunch >> >> (anymore). If your business depends on a feature being added to JavaFX, >> how >> >> much (time/money) are you willing to contribute? If the answer is >> >> "nothing", you can still hope that others want to do it, and in many cases >> >> that will eventually happen -- but you don't control the timeline. >> >> >> This principle is a bit a simplification though. In many practical cases, >> >> people want to have feature X and are willing to contribute "something" >> >> (e.g. they want to work on it in spare-time, or fund 20% of a developer) >> >> but not enough to do everything. >> >> I think in this case it's a matter of gathering enough interest in this >> >> community. Once enough developers are interested in that same feature, and >> >> agree to spend resources on it, the burden can be shared. Having a sandbox >> >> repositories with forks will make this easier. >> >> >> Areas that I personally want to see on the roadmap: >> >> * more alignment with mobile >> >> * a clean and lean low-level rendering pipeline API that would allow >> easier >> >> plugability with upcoming low-level rendering systems >> >> * extensions for Chart API >> >> >> - Johan >> >> >> From openjfx at jyloo.com Wed Feb 7 13:07:45 2018 From: openjfx at jyloo.com (Wolfgang Zitzelsberger) Date: Wed, 7 Feb 2018 14:07:45 +0100 Subject: future content of OpenJFX In-Reply-To: References: Message-ID: <6e83a4ee-4dfd-da2f-692f-de27682d46b1@jyloo.com> As a vendor of third party controls it's finally time for a feedback. We create look and feels and controls mainly for Swing/JavaFX desktop business applications. For us the most important things are: * Bugfixing - and we've already reported a lot over the past years * Rock solid base controls * An extendable API * Behavior API Because of the API, in Java 9 for some methods the visibility changed from protected to package local - in conjunction with JPMS it's pretty hard to find proper workarounds. Some of our FX controls are pretty sophisticated (e.g. our Table control) but all the open bugs makes further work pretty expensive simply because it slows development extremely down. Even if we noticed some higher activity in bug fixing, many open bugs are moved from one release to the next without getting fixed. Another big issue is the bug fixing latency - when we post a bug today it will be possibly fixed in Java 11 or later. For us this means a new product feature can't be tested and released before Java 11 - time goes by and in the meantime other technologies win. Johan, JavaFX is much more popular on Google Trends now than Swing because some of you guys praised JavaFX as the "successor of Swing" and often followed the "Swing is dead" mantra. If you are looking for a competitor you should take a look at web technologies or other non-Java products. IMHO Swing is *not* a competitor it's simply the older brother. Anyway, this doesn't matter in this discussion. For us creating complex JavaFX controls is more complicated than in Swing - not because of JavaFX itself, it's mainly because the JavaFX API is currently too restricted (way too many final and package-only visible methods). We've already invested thousands of bucks in JavaFX development without any ROI. Not a problem at all but at some point this is quite frustrating. And we are far away from seeing a huge interest in JavaFX business products. BTW: Any number of downloads can be misleading if you know nothing about the user base - business, education, hobby, bot... Just my 2 cents. Cheers Wolfgang, CEO of Jyloo Software Germany From kevin.rushforth at oracle.com Wed Feb 7 16:42:54 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 07 Feb 2018 22:12:54 +0530 Subject: More community participation in JavaFX In-Reply-To: References: <5A786D32.6050600@oracle.com> <5A7A6188.2090608@oracle.com> <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> <90b3cb55e88375f048b1c4eb8f883d8d.squirrel@54.sslprotected.nl> Message-ID: <5A7B2C8E.6040001@oracle.com> This has now veered off topic for this thread. It would be a fine topic for the "future content of OpenJFX" thread. -- Kevin John-Val Rose wrote: > > > Well, not only do I think that a docking framework is *that* complex, I see it as an essential part of any serious graphics toolkit. > > In general, I don?t understand all the limitations that people keep imposing on JavaFX as if we have to ?settle? for what is basically a 2nd class citizen compared with toolkits in other languages. > > Why can?t we just make JavaFX so compelling that developers from other languages are enticed by the feature set itself? There is no reason (other than a lack of effort) why JavaFX cannot be on par with Qt or Xamarin in terms of features, performance, tooling and adoption. > > Am I the only one that believes the world?s most popular and amazing programming language, platform and the JVM deserves a first class graphics toolkit? > > I understand the constraints imposed on Oracle staff but isn?t there anyone else out there in the community who shares my vision for JavaFX? > > It seems the general attitude is that JavaFX just needs to be a ?better Swing?. > > Forget about this nonsense of ?thinking outside the box?. > > There is NO BOX! > > JavaFX can and should be the best that we as a community can make it. > > And then we just keep making it better... > > If we don?t adopt such a vision and attitude then what is the point of doing anything at all? Just leave JavaFX to rot into oblivion and relegate Java to a server-side language only. > > > > >> On 7 Feb 2018, at 19:25, Tom Eugelink wrote: >> >> Well, I believe he was hinting at that a docking framework is considered >> more complex, there was no negative sentiment in that. Although I do not >> think a docking framework is that complex, but maybe I'm wrong. >> >> And yes, ALMOST everyone is at ControlFX ;-) >> >> >> >> >>> Jonathan - why do you *cough* at ideas like more complex controls and >>> docking frameworks? >>> >>> I think that a docking framework especially would be a great addition to >>> JavaFX. >>> >>> Am I missing something? >>> >>> >>>> On 7 Feb 2018, at 18:16, Jonathan Giles >>>> wrote: >>>> >>>> Obviously everyone is at ControlsFX instead ;-) >>>> >>>> Part of the drop I would suggest is simply that many of the itches >>>> people >>>> want to scratch are now scratched. Alternatively, the remaining itches >>>> are >>>> either in more complex controls (*cough* docking frameworks *cough*) or >>>> in >>>> areas beneath the controls APIs - performance, webview, etc - which are >>>> more challenging and require greater levels of dedication. >>>> >>>> However, more generally, your point is well made - contribution to >>>> JavaFX >>>> does not need to be synonymous with contribution to OpenJFX. People who >>>> find the challenges of the current OpenJFX requirements too great should >>>> be >>>> encouraged to involve themselves in projects such as JFXtras, etc. >>>> >>>> -- Jonathan >>>> >>>> >>>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >>>>> >>>>> Many years ago I had a discussion with Jonathan Giles about if the >>>>> things >>>>> that were being made in JFXtras would eventually become part of the >>>>> JavaFX >>>>> core. In the end I decided that, for me personally, I could do the >>>>> things I >>>>> wanted to perfectly in a separate project. The rigid structure that >>>>> Java(FX) has to adhere to, would be a big downside. >>>>> >>>>> What I want to say with that is that all the external projects are also >>>>> contributions to JavaFX. It does not matter whether for example a >>>>> control >>>>> is part of the core distribution or of a side project; it is just >>>>> another >>>>> module users can add to the mix. >>>>> >>>>> So reflecting back I still stand by that choice. But having a few more >>>>> people in the project (just like in JavaFX ;-) ) would be nice, but >>>>> OTOH it >>>>> forces me to deal with (and learn about) annoying stuff like Gradle >>>>> build >>>>> scripts and Java 9 migration. But because of that progress is not as >>>>> fast >>>>> as I would like it to be. Could it be that there is a decline in people >>>>> willing to work for open source projects? Or is it just that this tech, >>>>> JavaFX, is no longer appealing? >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>>> >>>> Obviously everyone is at ControlsFX instead ;-) >>>> >>>> Part of the drop I would suggest is simply that many of the itches >>>> people >>>> want to scratch are now scratched. Alternatively, the remaining itches >>>> are >>>> either in more complex controls (*cough* docking frameworks *cough*) or >>>> in >>>> areas beneath the controls APIs - performance, webview, etc - which are >>>> more challenging and require greater levels of dedication. >>>> >>>> However, more generally, your point is well made - contribution to >>>> JavaFX >>>> does not need to be synonymous with contribution to OpenJFX. People who >>>> find the challenges of the current OpenJFX requirements too great should >>>> be >>>> encouraged to involve themselves in projects such as JFXtras, etc. >>>> >>>> -- Jonathan >>>> >>>> >>>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >>>>> >>>>> Many years ago I had a discussion with Jonathan Giles about if the >>>>> things >>>>> that were being made in JFXtras would eventually become part of the >>>>> JavaFX >>>>> core. In the end I decided that, for me personally, I could do the >>>>> things I >>>>> wanted to perfectly in a separate project. The rigid structure that >>>>> Java(FX) has to adhere to, would be a big downside. >>>>> >>>>> What I want to say with that is that all the external projects are also >>>>> contributions to JavaFX. It does not matter whether for example a >>>>> control >>>>> is part of the core distribution or of a side project; it is just >>>>> another >>>>> module users can add to the mix. >>>>> >>>>> So reflecting back I still stand by that choice. But having a few more >>>>> people in the project (just like in JavaFX ;-) ) would be nice, but >>>>> OTOH it >>>>> forces me to deal with (and learn about) annoying stuff like Gradle >>>>> build >>>>> scripts and Java 9 migration. But because of that progress is not as >>>>> fast >>>>> as I would like it to be. Could it be that there is a decline in people >>>>> willing to work for open source projects? Or is it just that this tech, >>>>> JavaFX, is no longer appealing? >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>>> >>>>>> On 7-2-2018 03:16, Kevin Rushforth wrote: >>>>>> >>>>>> I would recommend against having a separate issue tracker or mailing >>>>>> list >>>>>> associated with the sandbox. That will create more confusion than any >>>>>> benefit you might have. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Nir Lisker wrote: >>>>>> >>>>>> >>>>>>> Another thing to be careful about with the sandbox/staging idea is >>>>>>> the >>>>>>> confusion that will arise with duplication. There will be 2 issue >>>>>>> trackers >>>>>>> (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and >>>>>>> maybe 2 >>>>>>> discussion lists. For those "in the know" this will be a simple >>>>>>> matter, but >>>>>>> for a potential contributor this can be a gamebreaker if not handled >>>>>>> appropriately. >>>>>>> >>>>>>> Dalibor Topic's suggestion of contacting other mirrors can be >>>>>>> instrumental in solving these problems. >>>>>>> >>>>>>> - Nir >>>>>>> >>>>>>> On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth < >>>>>>> kevin.rushforth at oracle.com > >>>>>>> wrote: >>>>>>> >>>>>>> Yes, this sounds like a good step in the right direction. This >>>>>>> would give anyone (with a signed OCA) the ability to create their >>>>>>> own branch, commit changes to it, submit a PR, etc. >>>>>>> >>>>>>> I presume there will be a branch that is an exact mirror of the >>>>>>> jfx-dev repo on OpenJDK in addition to the development branch in >>>>>>> the sandbox? >>>>>>> >>>>>>> The only thing to consider is whether it should be Committers or >>>>>>> Reviewers that have rights to merge into the sandbox development >>>>>>> branch. There are pros / cons of each. I'd probably lean towards >>>>>>> having it be Committers, with the idea that a Committer needs to >>>>>>> sponsor the patch anyway and would then be able to "take it the >>>>>>> rest of the way". The only downside I see is that you could end up >>>>>>> with a few patches that get accepted into the sandbox dev branch, >>>>>>> but never make it to the upstream jfx-dev repo (or not without >>>>>>> significant change). I doubt this will be a big problem in >>>>>>> practice. >>>>>>> >>>>>>> Either way, this could also provide a good alternative to webrev >>>>>>> when reviewing the final changes. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Johan Vos wrote: >>>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>> This proposal is very much in line with my thinking as well. >>>>>>> The problem is not that we don't have a github clone of >>>>>>> OpenJFX. We have a >>>>>>> number of them (e.g. I created >>>>>>> https://github.com/javafxports/jfx-dev >>>>>>> some >>>>>>> months ago). We just need a single one that is updated >>>>>>> constantly from >>>>>>> mainstream, and standardize on that. Let's call that "sandbox" >>>>>>> (I would be >>>>>>> ok with staging as well, but sandbox is imho more inviting to >>>>>>> people who >>>>>>> want to try something drastic, e.g. support for Vulkan) >>>>>>> >>>>>>> The main issue is how to get contributions, review them, and >>>>>>> eventually >>>>>>> send them upstream. >>>>>>> >>>>>>> The PR review process is extremely important. If we lower that >>>>>>> bar, we >>>>>>> loose quality. If the bar is too high, great PR's won't be >>>>>>> accepted >>>>>>> upstream as there is not enough review time to review it. >>>>>>> >>>>>>> I agree giving the current OpenJFX committers merge rights for >>>>>>> the >>>>>>> "sandbox" repository makes sense. Once a public contribution >>>>>>> is merged by >>>>>>> one of those committers, that same committer can send it >>>>>>> upstream to the >>>>>>> existing OpenJFX repository. Additional checks will be >>>>>>> performed there, >>>>>>> mainly in order to make sure the overall "Feel of Java" is >>>>>>> preserved. To >>>>>>> that purpose, it would help to have a closer alignment with >>>>>>> the OpenJDK >>>>>>> community. >>>>>>> >>>>>>> We have to be aware that this will increase the workload of >>>>>>> the current >>>>>>> committers and reviewers. That is the price we pay for >>>>>>> standardization. >>>>>>> Rather than everyone creating his own forks of a UI framework >>>>>>> in Java, we >>>>>>> invest a lot in creating a single, generally agreed one. >>>>>>> >>>>>>> So in summary, I'm +1 on a 2-phase approach: "open" commits >>>>>>> allowed in >>>>>>> staging. OpenJFX committers accept PR's (if they are of good >>>>>>> quality) and >>>>>>> prepare upstream commits for OpenJFX. We hope there will be >>>>>>> more >>>>>>> contributors who become committers and reviewers in the medium >>>>>>> term. >>>>>>> >>>>>>> - Johan >>>>>>> >>>>>>> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen >>>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> Those are great questions, and I think with >>>>>>> Kevin/Oracle/other OpenJFX devs >>>>>>> help we >>>>>>> can figure something out. >>>>>>> >>>>>>> My thinking is that the PR would be reviewed by basically >>>>>>> anyone who has >>>>>>> free time. >>>>>>> I think that, at first, only OpenJFX committers will be >>>>>>> able to merge PRs. >>>>>>> They would >>>>>>> do the final review/merge to the staging repo after it has >>>>>>> been reviewed by >>>>>>> the "wider audience" >>>>>>> which includes people without commit rights (people like >>>>>>> us). Then, as this >>>>>>> thing evolves, >>>>>>> based on the pool of people who are contributing both pull >>>>>>> requests and PR >>>>>>> reviews, >>>>>>> the committers will be able to grant commit privileges to >>>>>>> some people in >>>>>>> that pool. >>>>>>> >>>>>>> I can't think of any way that would make it so the changes >>>>>>> are as likely to >>>>>>> be >>>>>>> merged upstream as possible other than having the current >>>>>>> OpenJFX >>>>>>> committers paving the >>>>>>> way. Hopefully this vision is aligned with Kevin's and >>>>>>> hopefully these >>>>>>> concrete details >>>>>>> can be worked out. >>>>>>> >>>>>>> Regards, >>>>>>> Michael >>>>>>> >>>>>>> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker >>>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> So if a community ran GitHub is used for staging, who >>>>>>> will approve PRs >>>>>>> >>>>>>> for >>>>>>> >>>>>>> the code and the Wiki of the GitHub repo? >>>>>>> >>>>>>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Great points, Nir. We share the same hopes. I just >>>>>>> wanted to piggy-back >>>>>>> on the >>>>>>> wiki thing: >>>>>>> >>>>>>> " * The Wiki could be open sourced as well (like >>>>>>> other Wikis). I could >>>>>>> definitely update a page or 2 there and so would >>>>>>> other developers as >>>>>>> >>>>>>> they >>>>>>> >>>>>>> gain knowledge. I don't know yet how permissions >>>>>>> for that should be >>>>>>> handled." >>>>>>> >>>>>>> This is another thing that we could use the GitHub >>>>>>> staging repository >>>>>>> >>>>>>> for. >>>>>>> >>>>>>> The staging repository could have a wiki (projects >>>>>>> on GitHub can have >>>>>>> >>>>>>> one) >>>>>>> >>>>>>> that is editable by all, and then maybe once a >>>>>>> month or so someone with >>>>>>> permissions >>>>>>> to edit to official wiki can sync with the new, >>>>>>> reviewed changes (the >>>>>>> once-a-month >>>>>>> time constraint is very flexible). >>>>>>> >>>>>>> I am just trying to explain how the GitHub >>>>>>> repository "one-way mirror" >>>>>>> (potentially linked >>>>>>> with/managed by Adopt an OpenJDK) can act as a >>>>>>> staging ground for all >>>>>>> kinds of contributions to >>>>>>> OpenJFX. >>>>>>> >>>>>>> By the way, I am trying to cleanup the groundwork >>>>>>> I did on getting >>>>>>> Appveyor builds to >>>>>>> run for openjfx, if indeed it is decided to setup >>>>>>> such a staging >>>>>>> repository. You can >>>>>>> see my efforts here: >>>>>>> https://raw.githubusercontent. >>>>>>> >>>>>>> >>>>>>> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057 >>>>>>> /appveyor.yml >>>>>>> >>>>>>> If the GitHub repository was setup, changes such >>>>>>> as these to add CI >>>>>>> infrastructure would >>>>>>> never be adopted by upstream OpenJFX, but would >>>>>>> allow for developer's to >>>>>>> get good >>>>>>> feedback on test results for all supported >>>>>>> platforms when they open a >>>>>>> >>>>>>> PR. >>>>>>> >>>>>>> Merging a PR >>>>>>> on the public GitHub repository means, in my >>>>>>> opinion, that it is ready >>>>>>> >>>>>>> to >>>>>>> >>>>>>> be opened as >>>>>>> an upstream bug/feature request. Automating the >>>>>>> process with patch sets, >>>>>>> webrevs, formatting/lint >>>>>>> results, etc. would be the most ideal situation >>>>>>> and I would be happy to >>>>>>> contribute to these >>>>>>> efforts. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> As someone who has recently made the climb and >>>>>>> managed to build OpenJFX >>>>>>> with OpenJDK on Win 10 I might have some >>>>>>> relevant input. >>>>>>> >>>>>>> --- Building OpenJFX --- >>>>>>> >>>>>>> * With the recently updated instructions on >>>>>>> the Wiki, building OpenJFX >>>>>>> >>>>>>> is >>>>>>> >>>>>>> not that hard. Having to build OpenJDK for >>>>>>> that was a real headache >>>>>>> because >>>>>>> their instructions and build tools are not up >>>>>>> to date ( >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8194645 >>>>>>> ). >>>>>>> * The above doesn't mean that the process >>>>>>> shouldn't be made easier. >>>>>>> Ideally, it would be the as easy as working on >>>>>>> most open source >>>>>>> >>>>>>> projects >>>>>>> >>>>>>> on >>>>>>> Github (not advocating git over hg): clone >>>>>>> into the IDE and start >>>>>>> working; >>>>>>> when a fix is ready, submit a PR. Don't know >>>>>>> if it's technically >>>>>>> >>>>>>> possible >>>>>>> >>>>>>> in this case, but it's a target. >>>>>>> * The repository needs a good cleanup before >>>>>>> contributors start >>>>>>> >>>>>>> cloning ( >>>>>>> >>>>>>> bugs.openjdk.java.net/browse/JDK-8196198 >>>>>>> ). >>>>>>> >>>>>>> --- Working on OpenJFX --- >>>>>>> >>>>>>> * It should be clear which tests need to run >>>>>>> for a specific patch. >>>>>>> Changes >>>>>>> can be made anywhere from the documentation >>>>>>> level to native code level >>>>>>> and >>>>>>> there's no reason to run the same tests for >>>>>>> all of these. If the >>>>>>> >>>>>>> process >>>>>>> >>>>>>> can be automate it's even better. >>>>>>> * The Webrev tool seems archaic to me (and >>>>>>> part of its output is broken >>>>>>> as >>>>>>> far as I could tell). An IDE can create diff >>>>>>> patches with a couple of >>>>>>> clicks. >>>>>>> * The Jcheck tool seems archaic to me. It >>>>>>> should be ported to IDE >>>>>>> formatters which are to be distributed with >>>>>>> the source. No reason to >>>>>>> >>>>>>> run >>>>>>> >>>>>>> a >>>>>>> tool that tells me which whitespaces I need to >>>>>>> go back and change when >>>>>>> something like Ctrl+Shift+F in an IDE finishes >>>>>>> the job. >>>>>>> >>>>>>> --- Wiki --- >>>>>>> >>>>>>> * The Wiki could be open sourced as well (like >>>>>>> other Wikis). I could >>>>>>> definitely update a page or 2 there and so >>>>>>> would other developers as >>>>>>> >>>>>>> they >>>>>>> >>>>>>> gain knowledge. I don't know yet how >>>>>>> permissions for that should be >>>>>>> handled. >>>>>>> * Code conventions should be clearly listed. >>>>>>> * Separate sections with instructions should >>>>>>> be made for: (1) cloning >>>>>>> >>>>>>> and >>>>>>> >>>>>>> building, (2) modifying, (3) running tests, >>>>>>> (4) submitting, and (5) >>>>>>> reviewing. >>>>>>> * Old sections should be cleaned up (I don't >>>>>>> think Discussions is >>>>>>> >>>>>>> useful >>>>>>> >>>>>>> anymore). >>>>>>> >>>>>>> --- Review policy --- >>>>>>> >>>>>>> * I have no experience with review policies or >>>>>>> project roles so I can't >>>>>>> help here much (maybe after a discussion >>>>>>> starts). >>>>>>> * One thing I do know is that reviewers should >>>>>>> be extremely >>>>>>> knowledgeable, >>>>>>> which means that there aren't many qualified. >>>>>>> Because of this, if it >>>>>>> becomes "too" easy to contribute to OpenJFX, >>>>>>> careful measures need to >>>>>>> >>>>>>> be >>>>>>> >>>>>>> taken as to not to swamp the few reviewers >>>>>>> with many patches (though >>>>>>> >>>>>>> some >>>>>>> >>>>>>> would say this is an ideal situation). Some >>>>>>> sort of review queue might >>>>>>> help >>>>>>> with organization instead of the current email >>>>>>> system. I have no >>>>>>> >>>>>>> concrete >>>>>>> >>>>>>> solution for this. >>>>>>> >>>>>>> - Nir >>>>>>> >>>>>>> >>>>>>> Message: 1 >>>>>>> >>>>>>> Date: Thu, 01 Feb 2018 15:26:24 -0800 >>>>>>> From: Kevin Rushforth >>>>>>> >>>>>> > >>>>>>> To: "openjfx-dev at openjdk.java.net >>>>>>> " >>>>>>> >>>>>> > >>>>>>> Subject: More community participation in >>>>>>> JavaFX >>>>>>> Message-ID: <5A73A220.7030706 at oracle.com >>>>>>> > >>>>>>> Content-Type: text/plain; >>>>>>> charset=windows-1252; format=flowed >>>>>>> >>>>>>> To: OpenJFX Developers >>>>>>> >>>>>>> We are looking to grow the community of >>>>>>> contributors to the OpenJFX >>>>>>> project, especially serious contributors >>>>>>> who will stick around long >>>>>>> enough to become reviewers, to help us >>>>>>> keep the platform vibrant. To >>>>>>> this end we are looking at ways to >>>>>>> encourage more participation and >>>>>>> >>>>>>> make >>>>>>> >>>>>>> it easier for interested folks to >>>>>>> contribute. >>>>>>> >>>>>>> We are specifically looking to discuss >>>>>>> ideas around the following >>>>>>> >>>>>>> areas: >>>>>>> >>>>>>> * Easing barriers to contribution (e.g., >>>>>>> making JavaFX easier to >>>>>>> >>>>>>> build, >>>>>>> >>>>>>> better documentation, making it easier to >>>>>>> test changes) >>>>>>> >>>>>>> * Code review policies >>>>>>> >>>>>>> * API / feature review policies >>>>>>> >>>>>>> * Code review tools (we currently use >>>>>>> webrev, but that isn't set in >>>>>>> >>>>>>> stone) >>>>>>> >>>>>>> To keep this thread productive, the >>>>>>> following are explicitly out of >>>>>>> >>>>>>> scope: >>>>>>> >>>>>>> * Discussion of specific features or bugs >>>>>>> that you would like to >>>>>>> implement (or wish someone else would) >>>>>>> >>>>>>> * Discussion about platform support >>>>>>> >>>>>>> * Discussion about version control systems >>>>>>> (e.g., hg versus git), >>>>>>> hosting of the OpenJFX repos and bug >>>>>>> database (e.g., OpenJDK versus >>>>>>> github), etc...at least for now. We are >>>>>>> aware of the potential >>>>>>> >>>>>>> benefits >>>>>>> >>>>>>> of such changes, but we'd like to focus >>>>>>> our efforts on >>>>>>> >>>>>>> higher-leverage >>>>>>> >>>>>>> things we can do in the short term. >>>>>>> >>>>>>> * Discussion about the requirement of a >>>>>>> signed OCA to become a >>>>>>> >>>>>>> contributor >>>>>>> >>>>>>> * Off-topic or tangential commentary about >>>>>>> OpenJFX that isn't >>>>>>> >>>>>>> directly >>>>>>> >>>>>>> related to the topic at hand >>>>>>> >>>>>>> >>>>>>> As a starting point for discussion, here >>>>>>> are some areas I think need >>>>>>> improvement; I'm sure there are others: >>>>>>> >>>>>>> I. Helping contributors get started >>>>>>> >>>>>>> It isn?t as easy to get started with >>>>>>> OpenJFX as it should be. We want >>>>>>> >>>>>>> to >>>>>>> >>>>>>> make it easier for potential OpenJFX >>>>>>> contributors to get started. >>>>>>> >>>>>>> Here >>>>>>> >>>>>>> are some ideas that I think might help: >>>>>>> >>>>>>> * Improve the build instructions / Wiki (I >>>>>>> made a first start, but >>>>>>> >>>>>>> there >>>>>>> >>>>>>> is much more to be done) >>>>>>> >>>>>>> * Make the build itself more resilient >>>>>>> where possible, and provide >>>>>>> better error messages, specifically when >>>>>>> dealing with native >>>>>>> >>>>>>> compilers >>>>>>> >>>>>>> and libraries >>>>>>> >>>>>>> * Add an option to skip building all >>>>>>> native code and use prebuilt >>>>>>> binaries (like we do already for media and >>>>>>> webkit); this is tracked >>>>>>> >>>>>>> by >>>>>>> >>>>>>> JDK-8092279, but it hasn?t been looked at >>>>>>> recently >>>>>>> >>>>>>> * Make it easier to build / test your >>>>>>> local OpenJFX build using an >>>>>>> OpenJDK build (currently the only way to >>>>>>> do this is to build OpenJDK >>>>>>> locally, after using configure to point to >>>>>>> your just-built javafx.* >>>>>>> modules). >>>>>>> >>>>>>> * Provide step-by-step instructions for >>>>>>> how to make a contribution, >>>>>>> including testing requirements; a lot of >>>>>>> the pieces are there, but >>>>>>> >>>>>>> are >>>>>>> >>>>>>> out of date or scattered in several >>>>>>> places. As part of this, we could >>>>>>> have a section on how to contribute docs, >>>>>>> samples or tests, since >>>>>>> >>>>>>> that >>>>>>> >>>>>>> is often a good place to start. >>>>>>> >>>>>>> * Provide a sandbox environment where >>>>>>> contributors can discuss and >>>>>>> >>>>>>> test >>>>>>> >>>>>>> ideas. For example, an OpenJFX mirror on >>>>>>> github, potentially >>>>>>> >>>>>>> connected >>>>>>> >>>>>>> to AdoptOpenJDK. >>>>>>> >>>>>>> >>>>>>> II. Code reviews and API reviews >>>>>>> >>>>>>> Code reviews are important to maintain >>>>>>> high-quality contributions, >>>>>>> >>>>>>> but >>>>>>> >>>>>>> we recognize that not every type of change >>>>>>> needs the same level of >>>>>>> review. Without lowering our standards of >>>>>>> quality, we want to make it >>>>>>> easier to get low-impact changes (simple >>>>>>> bug fixes) accepted. >>>>>>> >>>>>>> There are three categories of changes, >>>>>>> each of which might merit a >>>>>>> different review standard: >>>>>>> >>>>>>> 1. Low-impact bug fixes. These are >>>>>>> typically isolated bug fixes with >>>>>>> little or no impact beyond fixing the bug >>>>>>> in question; included in >>>>>>> >>>>>>> this >>>>>>> >>>>>>> category are test fixes (including new >>>>>>> tests) doc fixes, and fixes to >>>>>>> sample applications (including new >>>>>>> samples). >>>>>>> >>>>>>> 2. Higher impact bug fixes or RFEs. These >>>>>>> include changes to the >>>>>>> implementation that potentially have a >>>>>>> performance or behavioral >>>>>>> >>>>>>> impact, >>>>>>> >>>>>>> or are otherwise broad in scope. Some >>>>>>> larger bug fixes will fall into >>>>>>> this category, as will fixes in high-risk >>>>>>> areas (e.g., CSS). >>>>>>> >>>>>>> 3. New features / API additions. In >>>>>>> addition to reviewing the >>>>>>> implementation, we will need a separate >>>>>>> approval process for the new >>>>>>> >>>>>>> API >>>>>>> >>>>>>> / feature (such as the CSR, which is what >>>>>>> we use now, or a similar >>>>>>> process). >>>>>>> >>>>>>> We take compatibility seriously, so >>>>>>> anything that adds new API needs >>>>>>> >>>>>>> to >>>>>>> >>>>>>> be done with an eye towards supporting it >>>>>>> for at least 10 years. We >>>>>>> don't want to add new public API without >>>>>>> that level of commitment. >>>>>>> >>>>>>> Every >>>>>>> >>>>>>> new feature forecloses on alternate future >>>>>>> features. Significant >>>>>>> >>>>>>> effort >>>>>>> >>>>>>> must be taken to think about "if we did >>>>>>> this, what could it interact >>>>>>> with in the future?" Also, anything with a >>>>>>> large potential impact on >>>>>>> performance or behavioral compatibility >>>>>>> needs to be looked at >>>>>>> >>>>>>> carefully. >>>>>>> >>>>>>> Put another way, we want to encourage >>>>>>> thinking about new features or >>>>>>> >>>>>>> new >>>>>>> >>>>>>> API in terms of a design / stewardship >>>>>>> process; to think in terms of >>>>>>> questions like "what's the right thing for >>>>>>> JavaFX in the next 10+ >>>>>>> >>>>>>> years" >>>>>>> >>>>>>> rather than "here's some code that solves >>>>>>> my problem, please take >>>>>>> >>>>>>> it". >>>>>>> >>>>>>> As a stake in the ground, I might suggest >>>>>>> the following: >>>>>>> >>>>>>> * All changes need at least one reviewer >>>>>>> other than the person making >>>>>>> the change who can evaluate the change for >>>>>>> correctness and >>>>>>> >>>>>>> consistency. >>>>>>> >>>>>>> For simple bug fixes, a single reviewer >>>>>>> may be sufficient. Of course, >>>>>>> one of our big challenges in all this is: >>>>>>> "how do we grow more >>>>>>> reviewers?", by which I mean "how do we >>>>>>> facilitate getting >>>>>>> >>>>>>> contributors >>>>>>> >>>>>>> with enough expertise in a given area to >>>>>>> eventually be able to >>>>>>> effectively review contributions from >>>>>>> others?" >>>>>>> >>>>>>> * We need clear criteria for the other two >>>>>>> categories that balance >>>>>>> process efficiency with the desire to >>>>>>> maintain compatibility and >>>>>>> stability. API changes need to be approved >>>>>>> by a lead. My thought is >>>>>>> >>>>>>> to >>>>>>> >>>>>>> combine the last two into a single >>>>>>> category for purposes of reviewing >>>>>>> the implementation. Anything that affects >>>>>>> public API or behavioral >>>>>>> compatibility will require CSR or similar >>>>>>> approval, over and above >>>>>>> >>>>>>> the >>>>>>> >>>>>>> implementation review, which seems >>>>>>> sufficient. >>>>>>> >>>>>>> * I recommend that we formalize the >>>>>>> concept of reviewers, using the >>>>>>> OpenJDK Reviewer role for the Project. We >>>>>>> might also consider if we >>>>>>> >>>>>>> want >>>>>>> >>>>>>> to make any changes to the criteria used >>>>>>> by the JDK Project for >>>>>>> >>>>>>> becoming >>>>>>> >>>>>>> an OpenJFX Project Author, Committer, and >>>>>>> Reviewer. The OpenJDK >>>>>>> >>>>>>> bylaws >>>>>>> >>>>>>> allow projects a fair degree of latitude >>>>>>> to define these criteria, so >>>>>>> >>>>>>> we >>>>>>> >>>>>>> might consider making some modifications. >>>>>>> For example, we might make >>>>>>> >>>>>>> it >>>>>>> >>>>>>> somewhat easier for a Contributor to >>>>>>> become an Author, or for a >>>>>>> Committer to become a Reviewer. I have >>>>>>> some thoughts on this, but >>>>>>> >>>>>>> want >>>>>>> >>>>>>> to hear from others first. >>>>>>> >>>>>>> >>>>>>> I look forward to feedback on this >>>>>>> proposal, and hope it will spark a >>>>>>> productive discussion. >>>>>>> >>>>>>> -- Kevin Rushforth, OpenJFX Project Lead >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> From johnvalrose at gmail.com Wed Feb 7 18:09:00 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Thu, 8 Feb 2018 05:09:00 +1100 Subject: More community participation in JavaFX In-Reply-To: <5A7B2C8E.6040001@oracle.com> References: <5A786D32.6050600@oracle.com> <5A7A6188.2090608@oracle.com> <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> <90b3cb55e88375f048b1c4eb8f883d8d.squirrel@54.sslprotected.nl> <5A7B2C8E.6040001@oracle.com> Message-ID: Yes, I agree - sorry. I got a bit confused as to which thread I was ?in? (while reading messages from each of them simultaneously) and there?s definitely a degree of overlap between the two of them topic-wise. Anyway, I vented - just not in the right place. I still hope for some feedback on said venting... > On 8 Feb 2018, at 03:42, Kevin Rushforth wrote: > > This has now veered off topic for this thread. It would be a fine topic for the "future content of OpenJFX" thread. > > -- Kevin > > > John-Val Rose wrote: >> >> >> Well, not only do I think that a docking framework is *that* complex, I see it as an essential part of any serious graphics toolkit. >> >> In general, I don?t understand all the limitations that people keep imposing on JavaFX as if we have to ?settle? for what is basically a 2nd class citizen compared with toolkits in other languages. >> >> Why can?t we just make JavaFX so compelling that developers from other languages are enticed by the feature set itself? There is no reason (other than a lack of effort) why JavaFX cannot be on par with Qt or Xamarin in terms of features, performance, tooling and adoption. >> >> Am I the only one that believes the world?s most popular and amazing programming language, platform and the JVM deserves a first class graphics toolkit? >> >> I understand the constraints imposed on Oracle staff but isn?t there anyone else out there in the community who shares my vision for JavaFX? >> >> It seems the general attitude is that JavaFX just needs to be a ?better Swing?. >> >> Forget about this nonsense of ?thinking outside the box?. >> >> There is NO BOX! >> >> JavaFX can and should be the best that we as a community can make it. >> >> And then we just keep making it better... >> >> If we don?t adopt such a vision and attitude then what is the point of doing anything at all? Just leave JavaFX to rot into oblivion and relegate Java to a server-side language only. >> >> >> >> >>> On 7 Feb 2018, at 19:25, Tom Eugelink wrote: >>> >>> Well, I believe he was hinting at that a docking framework is considered >>> more complex, there was no negative sentiment in that. Although I do not >>> think a docking framework is that complex, but maybe I'm wrong. >>> >>> And yes, ALMOST everyone is at ControlFX ;-) >>> >>> >>> >>> >>>> Jonathan - why do you *cough* at ideas like more complex controls and >>>> docking frameworks? >>>> >>>> I think that a docking framework especially would be a great addition to >>>> JavaFX. >>>> >>>> Am I missing something? >>>> >>>> >>>>> On 7 Feb 2018, at 18:16, Jonathan Giles >>>>> wrote: >>>>> >>>>> Obviously everyone is at ControlsFX instead ;-) >>>>> >>>>> Part of the drop I would suggest is simply that many of the itches >>>>> people >>>>> want to scratch are now scratched. Alternatively, the remaining itches >>>>> are >>>>> either in more complex controls (*cough* docking frameworks *cough*) or >>>>> in >>>>> areas beneath the controls APIs - performance, webview, etc - which are >>>>> more challenging and require greater levels of dedication. >>>>> >>>>> However, more generally, your point is well made - contribution to >>>>> JavaFX >>>>> does not need to be synonymous with contribution to OpenJFX. People who >>>>> find the challenges of the current OpenJFX requirements too great should >>>>> be >>>>> encouraged to involve themselves in projects such as JFXtras, etc. >>>>> >>>>> -- Jonathan >>>>> >>>>> >>>>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >>>>>> >>>>>> Many years ago I had a discussion with Jonathan Giles about if the >>>>>> things >>>>>> that were being made in JFXtras would eventually become part of the >>>>>> JavaFX >>>>>> core. In the end I decided that, for me personally, I could do the >>>>>> things I >>>>>> wanted to perfectly in a separate project. The rigid structure that >>>>>> Java(FX) has to adhere to, would be a big downside. >>>>>> >>>>>> What I want to say with that is that all the external projects are also >>>>>> contributions to JavaFX. It does not matter whether for example a >>>>>> control >>>>>> is part of the core distribution or of a side project; it is just >>>>>> another >>>>>> module users can add to the mix. >>>>>> >>>>>> So reflecting back I still stand by that choice. But having a few more >>>>>> people in the project (just like in JavaFX ;-) ) would be nice, but >>>>>> OTOH it >>>>>> forces me to deal with (and learn about) annoying stuff like Gradle >>>>>> build >>>>>> scripts and Java 9 migration. But because of that progress is not as >>>>>> fast >>>>>> as I would like it to be. Could it be that there is a decline in people >>>>>> willing to work for open source projects? Or is it just that this tech, >>>>>> JavaFX, is no longer appealing? >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Obviously everyone is at ControlsFX instead ;-) >>>>> >>>>> Part of the drop I would suggest is simply that many of the itches >>>>> people >>>>> want to scratch are now scratched. Alternatively, the remaining itches >>>>> are >>>>> either in more complex controls (*cough* docking frameworks *cough*) or >>>>> in >>>>> areas beneath the controls APIs - performance, webview, etc - which are >>>>> more challenging and require greater levels of dedication. >>>>> >>>>> However, more generally, your point is well made - contribution to >>>>> JavaFX >>>>> does not need to be synonymous with contribution to OpenJFX. People who >>>>> find the challenges of the current OpenJFX requirements too great should >>>>> be >>>>> encouraged to involve themselves in projects such as JFXtras, etc. >>>>> >>>>> -- Jonathan >>>>> >>>>> >>>>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >>>>>> >>>>>> Many years ago I had a discussion with Jonathan Giles about if the >>>>>> things >>>>>> that were being made in JFXtras would eventually become part of the >>>>>> JavaFX >>>>>> core. In the end I decided that, for me personally, I could do the >>>>>> things I >>>>>> wanted to perfectly in a separate project. The rigid structure that >>>>>> Java(FX) has to adhere to, would be a big downside. >>>>>> >>>>>> What I want to say with that is that all the external projects are also >>>>>> contributions to JavaFX. It does not matter whether for example a >>>>>> control >>>>>> is part of the core distribution or of a side project; it is just >>>>>> another >>>>>> module users can add to the mix. >>>>>> >>>>>> So reflecting back I still stand by that choice. But having a few more >>>>>> people in the project (just like in JavaFX ;-) ) would be nice, but >>>>>> OTOH it >>>>>> forces me to deal with (and learn about) annoying stuff like Gradle >>>>>> build >>>>>> scripts and Java 9 migration. But because of that progress is not as >>>>>> fast >>>>>> as I would like it to be. Could it be that there is a decline in people >>>>>> willing to work for open source projects? Or is it just that this tech, >>>>>> JavaFX, is no longer appealing? >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 7-2-2018 03:16, Kevin Rushforth wrote: >>>>>>> >>>>>>> I would recommend against having a separate issue tracker or mailing >>>>>>> list >>>>>>> associated with the sandbox. That will create more confusion than any >>>>>>> benefit you might have. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Nir Lisker wrote: >>>>>>> >>>>>>> >>>>>>>> Another thing to be careful about with the sandbox/staging idea is >>>>>>>> the >>>>>>>> confusion that will arise with duplication. There will be 2 issue >>>>>>>> trackers >>>>>>>> (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and >>>>>>>> maybe 2 >>>>>>>> discussion lists. For those "in the know" this will be a simple >>>>>>>> matter, but >>>>>>>> for a potential contributor this can be a gamebreaker if not handled >>>>>>>> appropriately. >>>>>>>> >>>>>>>> Dalibor Topic's suggestion of contacting other mirrors can be >>>>>>>> instrumental in solving these problems. >>>>>>>> >>>>>>>> - Nir >>>>>>>> >>>>>>>> On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth < >>>>>>>> kevin.rushforth at oracle.com > >>>>>>>> wrote: >>>>>>>> >>>>>>>> Yes, this sounds like a good step in the right direction. This >>>>>>>> would give anyone (with a signed OCA) the ability to create their >>>>>>>> own branch, commit changes to it, submit a PR, etc. >>>>>>>> >>>>>>>> I presume there will be a branch that is an exact mirror of the >>>>>>>> jfx-dev repo on OpenJDK in addition to the development branch in >>>>>>>> the sandbox? >>>>>>>> >>>>>>>> The only thing to consider is whether it should be Committers or >>>>>>>> Reviewers that have rights to merge into the sandbox development >>>>>>>> branch. There are pros / cons of each. I'd probably lean towards >>>>>>>> having it be Committers, with the idea that a Committer needs to >>>>>>>> sponsor the patch anyway and would then be able to "take it the >>>>>>>> rest of the way". The only downside I see is that you could end up >>>>>>>> with a few patches that get accepted into the sandbox dev branch, >>>>>>>> but never make it to the upstream jfx-dev repo (or not without >>>>>>>> significant change). I doubt this will be a big problem in >>>>>>>> practice. >>>>>>>> >>>>>>>> Either way, this could also provide a good alternative to webrev >>>>>>>> when reviewing the final changes. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Johan Vos wrote: >>>>>>>> >>>>>>>> Hi Michael, >>>>>>>> >>>>>>>> This proposal is very much in line with my thinking as well. >>>>>>>> The problem is not that we don't have a github clone of >>>>>>>> OpenJFX. We have a >>>>>>>> number of them (e.g. I created >>>>>>>> https://github.com/javafxports/jfx-dev >>>>>>>> some >>>>>>>> months ago). We just need a single one that is updated >>>>>>>> constantly from >>>>>>>> mainstream, and standardize on that. Let's call that "sandbox" >>>>>>>> (I would be >>>>>>>> ok with staging as well, but sandbox is imho more inviting to >>>>>>>> people who >>>>>>>> want to try something drastic, e.g. support for Vulkan) >>>>>>>> >>>>>>>> The main issue is how to get contributions, review them, and >>>>>>>> eventually >>>>>>>> send them upstream. >>>>>>>> >>>>>>>> The PR review process is extremely important. If we lower that >>>>>>>> bar, we >>>>>>>> loose quality. If the bar is too high, great PR's won't be >>>>>>>> accepted >>>>>>>> upstream as there is not enough review time to review it. >>>>>>>> >>>>>>>> I agree giving the current OpenJFX committers merge rights for >>>>>>>> the >>>>>>>> "sandbox" repository makes sense. Once a public contribution >>>>>>>> is merged by >>>>>>>> one of those committers, that same committer can send it >>>>>>>> upstream to the >>>>>>>> existing OpenJFX repository. Additional checks will be >>>>>>>> performed there, >>>>>>>> mainly in order to make sure the overall "Feel of Java" is >>>>>>>> preserved. To >>>>>>>> that purpose, it would help to have a closer alignment with >>>>>>>> the OpenJDK >>>>>>>> community. >>>>>>>> >>>>>>>> We have to be aware that this will increase the workload of >>>>>>>> the current >>>>>>>> committers and reviewers. That is the price we pay for >>>>>>>> standardization. >>>>>>>> Rather than everyone creating his own forks of a UI framework >>>>>>>> in Java, we >>>>>>>> invest a lot in creating a single, generally agreed one. >>>>>>>> >>>>>>>> So in summary, I'm +1 on a 2-phase approach: "open" commits >>>>>>>> allowed in >>>>>>>> staging. OpenJFX committers accept PR's (if they are of good >>>>>>>> quality) and >>>>>>>> prepare upstream commits for OpenJFX. We hope there will be >>>>>>>> more >>>>>>>> contributors who become committers and reviewers in the medium >>>>>>>> term. >>>>>>>> >>>>>>>> - Johan >>>>>>>> >>>>>>>> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen >>>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>> Those are great questions, and I think with >>>>>>>> Kevin/Oracle/other OpenJFX devs >>>>>>>> help we >>>>>>>> can figure something out. >>>>>>>> >>>>>>>> My thinking is that the PR would be reviewed by basically >>>>>>>> anyone who has >>>>>>>> free time. >>>>>>>> I think that, at first, only OpenJFX committers will be >>>>>>>> able to merge PRs. >>>>>>>> They would >>>>>>>> do the final review/merge to the staging repo after it has >>>>>>>> been reviewed by >>>>>>>> the "wider audience" >>>>>>>> which includes people without commit rights (people like >>>>>>>> us). Then, as this >>>>>>>> thing evolves, >>>>>>>> based on the pool of people who are contributing both pull >>>>>>>> requests and PR >>>>>>>> reviews, >>>>>>>> the committers will be able to grant commit privileges to >>>>>>>> some people in >>>>>>>> that pool. >>>>>>>> >>>>>>>> I can't think of any way that would make it so the changes >>>>>>>> are as likely to >>>>>>>> be >>>>>>>> merged upstream as possible other than having the current >>>>>>>> OpenJFX >>>>>>>> committers paving the >>>>>>>> way. Hopefully this vision is aligned with Kevin's and >>>>>>>> hopefully these >>>>>>>> concrete details >>>>>>>> can be worked out. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Michael >>>>>>>> >>>>>>>> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker >>>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>> So if a community ran GitHub is used for staging, who >>>>>>>> will approve PRs >>>>>>>> >>>>>>>> for >>>>>>>> >>>>>>>> the code and the Wiki of the GitHub repo? >>>>>>>> >>>>>>>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Great points, Nir. We share the same hopes. I just >>>>>>>> wanted to piggy-back >>>>>>>> on the >>>>>>>> wiki thing: >>>>>>>> >>>>>>>> " * The Wiki could be open sourced as well (like >>>>>>>> other Wikis). I could >>>>>>>> definitely update a page or 2 there and so would >>>>>>>> other developers as >>>>>>>> >>>>>>>> they >>>>>>>> >>>>>>>> gain knowledge. I don't know yet how permissions >>>>>>>> for that should be >>>>>>>> handled." >>>>>>>> >>>>>>>> This is another thing that we could use the GitHub >>>>>>>> staging repository >>>>>>>> >>>>>>>> for. >>>>>>>> >>>>>>>> The staging repository could have a wiki (projects >>>>>>>> on GitHub can have >>>>>>>> >>>>>>>> one) >>>>>>>> >>>>>>>> that is editable by all, and then maybe once a >>>>>>>> month or so someone with >>>>>>>> permissions >>>>>>>> to edit to official wiki can sync with the new, >>>>>>>> reviewed changes (the >>>>>>>> once-a-month >>>>>>>> time constraint is very flexible). >>>>>>>> >>>>>>>> I am just trying to explain how the GitHub >>>>>>>> repository "one-way mirror" >>>>>>>> (potentially linked >>>>>>>> with/managed by Adopt an OpenJDK) can act as a >>>>>>>> staging ground for all >>>>>>>> kinds of contributions to >>>>>>>> OpenJFX. >>>>>>>> >>>>>>>> By the way, I am trying to cleanup the groundwork >>>>>>>> I did on getting >>>>>>>> Appveyor builds to >>>>>>>> run for openjfx, if indeed it is decided to setup >>>>>>>> such a staging >>>>>>>> repository. You can >>>>>>>> see my efforts here: >>>>>>>> https://raw.githubusercontent. >>>>>>>> >>>>>>>> >>>>>>>> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057 >>>>>>>> /appveyor.yml >>>>>>>> >>>>>>>> If the GitHub repository was setup, changes such >>>>>>>> as these to add CI >>>>>>>> infrastructure would >>>>>>>> never be adopted by upstream OpenJFX, but would >>>>>>>> allow for developer's to >>>>>>>> get good >>>>>>>> feedback on test results for all supported >>>>>>>> platforms when they open a >>>>>>>> >>>>>>>> PR. >>>>>>>> >>>>>>>> Merging a PR >>>>>>>> on the public GitHub repository means, in my >>>>>>>> opinion, that it is ready >>>>>>>> >>>>>>>> to >>>>>>>> >>>>>>>> be opened as >>>>>>>> an upstream bug/feature request. Automating the >>>>>>>> process with patch sets, >>>>>>>> webrevs, formatting/lint >>>>>>>> results, etc. would be the most ideal situation >>>>>>>> and I would be happy to >>>>>>>> contribute to these >>>>>>>> efforts. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Michael Ennen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> As someone who has recently made the climb and >>>>>>>> managed to build OpenJFX >>>>>>>> with OpenJDK on Win 10 I might have some >>>>>>>> relevant input. >>>>>>>> >>>>>>>> --- Building OpenJFX --- >>>>>>>> >>>>>>>> * With the recently updated instructions on >>>>>>>> the Wiki, building OpenJFX >>>>>>>> >>>>>>>> is >>>>>>>> >>>>>>>> not that hard. Having to build OpenJDK for >>>>>>>> that was a real headache >>>>>>>> because >>>>>>>> their instructions and build tools are not up >>>>>>>> to date ( >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8194645 >>>>>>>> ). >>>>>>>> * The above doesn't mean that the process >>>>>>>> shouldn't be made easier. >>>>>>>> Ideally, it would be the as easy as working on >>>>>>>> most open source >>>>>>>> >>>>>>>> projects >>>>>>>> >>>>>>>> on >>>>>>>> Github (not advocating git over hg): clone >>>>>>>> into the IDE and start >>>>>>>> working; >>>>>>>> when a fix is ready, submit a PR. Don't know >>>>>>>> if it's technically >>>>>>>> >>>>>>>> possible >>>>>>>> >>>>>>>> in this case, but it's a target. >>>>>>>> * The repository needs a good cleanup before >>>>>>>> contributors start >>>>>>>> >>>>>>>> cloning ( >>>>>>>> >>>>>>>> bugs.openjdk.java.net/browse/JDK-8196198 >>>>>>>> ). >>>>>>>> >>>>>>>> --- Working on OpenJFX --- >>>>>>>> >>>>>>>> * It should be clear which tests need to run >>>>>>>> for a specific patch. >>>>>>>> Changes >>>>>>>> can be made anywhere from the documentation >>>>>>>> level to native code level >>>>>>>> and >>>>>>>> there's no reason to run the same tests for >>>>>>>> all of these. If the >>>>>>>> >>>>>>>> process >>>>>>>> >>>>>>>> can be automate it's even better. >>>>>>>> * The Webrev tool seems archaic to me (and >>>>>>>> part of its output is broken >>>>>>>> as >>>>>>>> far as I could tell). An IDE can create diff >>>>>>>> patches with a couple of >>>>>>>> clicks. >>>>>>>> * The Jcheck tool seems archaic to me. It >>>>>>>> should be ported to IDE >>>>>>>> formatters which are to be distributed with >>>>>>>> the source. No reason to >>>>>>>> >>>>>>>> run >>>>>>>> >>>>>>>> a >>>>>>>> tool that tells me which whitespaces I need to >>>>>>>> go back and change when >>>>>>>> something like Ctrl+Shift+F in an IDE finishes >>>>>>>> the job. >>>>>>>> >>>>>>>> --- Wiki --- >>>>>>>> >>>>>>>> * The Wiki could be open sourced as well (like >>>>>>>> other Wikis). I could >>>>>>>> definitely update a page or 2 there and so >>>>>>>> would other developers as >>>>>>>> >>>>>>>> they >>>>>>>> >>>>>>>> gain knowledge. I don't know yet how >>>>>>>> permissions for that should be >>>>>>>> handled. >>>>>>>> * Code conventions should be clearly listed. >>>>>>>> * Separate sections with instructions should >>>>>>>> be made for: (1) cloning >>>>>>>> >>>>>>>> and >>>>>>>> >>>>>>>> building, (2) modifying, (3) running tests, >>>>>>>> (4) submitting, and (5) >>>>>>>> reviewing. >>>>>>>> * Old sections should be cleaned up (I don't >>>>>>>> think Discussions is >>>>>>>> >>>>>>>> useful >>>>>>>> >>>>>>>> anymore). >>>>>>>> >>>>>>>> --- Review policy --- >>>>>>>> >>>>>>>> * I have no experience with review policies or >>>>>>>> project roles so I can't >>>>>>>> help here much (maybe after a discussion >>>>>>>> starts). >>>>>>>> * One thing I do know is that reviewers should >>>>>>>> be extremely >>>>>>>> knowledgeable, >>>>>>>> which means that there aren't many qualified. >>>>>>>> Because of this, if it >>>>>>>> becomes "too" easy to contribute to OpenJFX, >>>>>>>> careful measures need to >>>>>>>> >>>>>>>> be >>>>>>>> >>>>>>>> taken as to not to swamp the few reviewers >>>>>>>> with many patches (though >>>>>>>> >>>>>>>> some >>>>>>>> >>>>>>>> would say this is an ideal situation). Some >>>>>>>> sort of review queue might >>>>>>>> help >>>>>>>> with organization instead of the current email >>>>>>>> system. I have no >>>>>>>> >>>>>>>> concrete >>>>>>>> >>>>>>>> solution for this. >>>>>>>> >>>>>>>> - Nir >>>>>>>> >>>>>>>> >>>>>>>> Message: 1 >>>>>>>> >>>>>>>> Date: Thu, 01 Feb 2018 15:26:24 -0800 >>>>>>>> From: Kevin Rushforth >>>>>>>> >>>>>>> > >>>>>>>> To: "openjfx-dev at openjdk.java.net >>>>>>>> " >>>>>>>> >>>>>>> > >>>>>>>> Subject: More community participation in >>>>>>>> JavaFX >>>>>>>> Message-ID: <5A73A220.7030706 at oracle.com >>>>>>>> > >>>>>>>> Content-Type: text/plain; >>>>>>>> charset=windows-1252; format=flowed >>>>>>>> >>>>>>>> To: OpenJFX Developers >>>>>>>> >>>>>>>> We are looking to grow the community of >>>>>>>> contributors to the OpenJFX >>>>>>>> project, especially serious contributors >>>>>>>> who will stick around long >>>>>>>> enough to become reviewers, to help us >>>>>>>> keep the platform vibrant. To >>>>>>>> this end we are looking at ways to >>>>>>>> encourage more participation and >>>>>>>> >>>>>>>> make >>>>>>>> >>>>>>>> it easier for interested folks to >>>>>>>> contribute. >>>>>>>> >>>>>>>> We are specifically looking to discuss >>>>>>>> ideas around the following >>>>>>>> >>>>>>>> areas: >>>>>>>> >>>>>>>> * Easing barriers to contribution (e.g., >>>>>>>> making JavaFX easier to >>>>>>>> >>>>>>>> build, >>>>>>>> >>>>>>>> better documentation, making it easier to >>>>>>>> test changes) >>>>>>>> >>>>>>>> * Code review policies >>>>>>>> >>>>>>>> * API / feature review policies >>>>>>>> >>>>>>>> * Code review tools (we currently use >>>>>>>> webrev, but that isn't set in >>>>>>>> >>>>>>>> stone) >>>>>>>> >>>>>>>> To keep this thread productive, the >>>>>>>> following are explicitly out of >>>>>>>> >>>>>>>> scope: >>>>>>>> >>>>>>>> * Discussion of specific features or bugs >>>>>>>> that you would like to >>>>>>>> implement (or wish someone else would) >>>>>>>> >>>>>>>> * Discussion about platform support >>>>>>>> >>>>>>>> * Discussion about version control systems >>>>>>>> (e.g., hg versus git), >>>>>>>> hosting of the OpenJFX repos and bug >>>>>>>> database (e.g., OpenJDK versus >>>>>>>> github), etc...at least for now. We are >>>>>>>> aware of the potential >>>>>>>> >>>>>>>> benefits >>>>>>>> >>>>>>>> of such changes, but we'd like to focus >>>>>>>> our efforts on >>>>>>>> >>>>>>>> higher-leverage >>>>>>>> >>>>>>>> things we can do in the short term. >>>>>>>> >>>>>>>> * Discussion about the requirement of a >>>>>>>> signed OCA to become a >>>>>>>> >>>>>>>> contributor >>>>>>>> >>>>>>>> * Off-topic or tangential commentary about >>>>>>>> OpenJFX that isn't >>>>>>>> >>>>>>>> directly >>>>>>>> >>>>>>>> related to the topic at hand >>>>>>>> >>>>>>>> >>>>>>>> As a starting point for discussion, here >>>>>>>> are some areas I think need >>>>>>>> improvement; I'm sure there are others: >>>>>>>> >>>>>>>> I. Helping contributors get started >>>>>>>> >>>>>>>> It isn?t as easy to get started with >>>>>>>> OpenJFX as it should be. We want >>>>>>>> >>>>>>>> to >>>>>>>> >>>>>>>> make it easier for potential OpenJFX >>>>>>>> contributors to get started. >>>>>>>> >>>>>>>> Here >>>>>>>> >>>>>>>> are some ideas that I think might help: >>>>>>>> >>>>>>>> * Improve the build instructions / Wiki (I >>>>>>>> made a first start, but >>>>>>>> >>>>>>>> there >>>>>>>> >>>>>>>> is much more to be done) >>>>>>>> >>>>>>>> * Make the build itself more resilient >>>>>>>> where possible, and provide >>>>>>>> better error messages, specifically when >>>>>>>> dealing with native >>>>>>>> >>>>>>>> compilers >>>>>>>> >>>>>>>> and libraries >>>>>>>> >>>>>>>> * Add an option to skip building all >>>>>>>> native code and use prebuilt >>>>>>>> binaries (like we do already for media and >>>>>>>> webkit); this is tracked >>>>>>>> >>>>>>>> by >>>>>>>> >>>>>>>> JDK-8092279, but it hasn?t been looked at >>>>>>>> recently >>>>>>>> >>>>>>>> * Make it easier to build / test your >>>>>>>> local OpenJFX build using an >>>>>>>> OpenJDK build (currently the only way to >>>>>>>> do this is to build OpenJDK >>>>>>>> locally, after using configure to point to >>>>>>>> your just-built javafx.* >>>>>>>> modules). >>>>>>>> >>>>>>>> * Provide step-by-step instructions for >>>>>>>> how to make a contribution, >>>>>>>> including testing requirements; a lot of >>>>>>>> the pieces are there, but >>>>>>>> >>>>>>>> are >>>>>>>> >>>>>>>> out of date or scattered in several >>>>>>>> places. As part of this, we could >>>>>>>> have a section on how to contribute docs, >>>>>>>> samples or tests, since >>>>>>>> >>>>>>>> that >>>>>>>> >>>>>>>> is often a good place to start. >>>>>>>> >>>>>>>> * Provide a sandbox environment where >>>>>>>> contributors can discuss and >>>>>>>> >>>>>>>> test >>>>>>>> >>>>>>>> ideas. For example, an OpenJFX mirror on >>>>>>>> github, potentially >>>>>>>> >>>>>>>> connected >>>>>>>> >>>>>>>> to AdoptOpenJDK. >>>>>>>> >>>>>>>> >>>>>>>> II. Code reviews and API reviews >>>>>>>> >>>>>>>> Code reviews are important to maintain >>>>>>>> high-quality contributions, >>>>>>>> >>>>>>>> but >>>>>>>> >>>>>>>> we recognize that not every type of change >>>>>>>> needs the same level of >>>>>>>> review. Without lowering our standards of >>>>>>>> quality, we want to make it >>>>>>>> easier to get low-impact changes (simple >>>>>>>> bug fixes) accepted. >>>>>>>> >>>>>>>> There are three categories of changes, >>>>>>>> each of which might merit a >>>>>>>> different review standard: >>>>>>>> >>>>>>>> 1. Low-impact bug fixes. These are >>>>>>>> typically isolated bug fixes with >>>>>>>> little or no impact beyond fixing the bug >>>>>>>> in question; included in >>>>>>>> >>>>>>>> this >>>>>>>> >>>>>>>> category are test fixes (including new >>>>>>>> tests) doc fixes, and fixes to >>>>>>>> sample applications (including new >>>>>>>> samples). >>>>>>>> >>>>>>>> 2. Higher impact bug fixes or RFEs. These >>>>>>>> include changes to the >>>>>>>> implementation that potentially have a >>>>>>>> performance or behavioral >>>>>>>> >>>>>>>> impact, >>>>>>>> >>>>>>>> or are otherwise broad in scope. Some >>>>>>>> larger bug fixes will fall into >>>>>>>> this category, as will fixes in high-risk >>>>>>>> areas (e.g., CSS). >>>>>>>> >>>>>>>> 3. New features / API additions. In >>>>>>>> addition to reviewing the >>>>>>>> implementation, we will need a separate >>>>>>>> approval process for the new >>>>>>>> >>>>>>>> API >>>>>>>> >>>>>>>> / feature (such as the CSR, which is what >>>>>>>> we use now, or a similar >>>>>>>> process). >>>>>>>> >>>>>>>> We take compatibility seriously, so >>>>>>>> anything that adds new API needs >>>>>>>> >>>>>>>> to >>>>>>>> >>>>>>>> be done with an eye towards supporting it >>>>>>>> for at least 10 years. We >>>>>>>> don't want to add new public API without >>>>>>>> that level of commitment. >>>>>>>> >>>>>>>> Every >>>>>>>> >>>>>>>> new feature forecloses on alternate future >>>>>>>> features. Significant >>>>>>>> >>>>>>>> effort >>>>>>>> >>>>>>>> must be taken to think about "if we did >>>>>>>> this, what could it interact >>>>>>>> with in the future?" Also, anything with a >>>>>>>> large potential impact on >>>>>>>> performance or behavioral compatibility >>>>>>>> needs to be looked at >>>>>>>> >>>>>>>> carefully. >>>>>>>> >>>>>>>> Put another way, we want to encourage >>>>>>>> thinking about new features or >>>>>>>> >>>>>>>> new >>>>>>>> >>>>>>>> API in terms of a design / stewardship >>>>>>>> process; to think in terms of >>>>>>>> questions like "what's the right thing for >>>>>>>> JavaFX in the next 10+ >>>>>>>> >>>>>>>> years" >>>>>>>> >>>>>>>> rather than "here's some code that solves >>>>>>>> my problem, please take >>>>>>>> >>>>>>>> it". >>>>>>>> >>>>>>>> As a stake in the ground, I might suggest >>>>>>>> the following: >>>>>>>> >>>>>>>> * All changes need at least one reviewer >>>>>>>> other than the person making >>>>>>>> the change who can evaluate the change for >>>>>>>> correctness and >>>>>>>> >>>>>>>> consistency. >>>>>>>> >>>>>>>> For simple bug fixes, a single reviewer >>>>>>>> may be sufficient. Of course, >>>>>>>> one of our big challenges in all this is: >>>>>>>> "how do we grow more >>>>>>>> reviewers?", by which I mean "how do we >>>>>>>> facilitate getting >>>>>>>> >>>>>>>> contributors >>>>>>>> >>>>>>>> with enough expertise in a given area to >>>>>>>> eventually be able to >>>>>>>> effectively review contributions from >>>>>>>> others?" >>>>>>>> >>>>>>>> * We need clear criteria for the other two >>>>>>>> categories that balance >>>>>>>> process efficiency with the desire to >>>>>>>> maintain compatibility and >>>>>>>> stability. API changes need to be approved >>>>>>>> by a lead. My thought is >>>>>>>> >>>>>>>> to >>>>>>>> >>>>>>>> combine the last two into a single >>>>>>>> category for purposes of reviewing >>>>>>>> the implementation. Anything that affects >>>>>>>> public API or behavioral >>>>>>>> compatibility will require CSR or similar >>>>>>>> approval, over and above >>>>>>>> >>>>>>>> the >>>>>>>> >>>>>>>> implementation review, which seems >>>>>>>> sufficient. >>>>>>>> >>>>>>>> * I recommend that we formalize the >>>>>>>> concept of reviewers, using the >>>>>>>> OpenJDK Reviewer role for the Project. We >>>>>>>> might also consider if we >>>>>>>> >>>>>>>> want >>>>>>>> >>>>>>>> to make any changes to the criteria used >>>>>>>> by the JDK Project for >>>>>>>> >>>>>>>> becoming >>>>>>>> >>>>>>>> an OpenJFX Project Author, Committer, and >>>>>>>> Reviewer. The OpenJDK >>>>>>>> >>>>>>>> bylaws >>>>>>>> >>>>>>>> allow projects a fair degree of latitude >>>>>>>> to define these criteria, so >>>>>>>> >>>>>>>> we >>>>>>>> >>>>>>>> might consider making some modifications. >>>>>>>> For example, we might make >>>>>>>> >>>>>>>> it >>>>>>>> >>>>>>>> somewhat easier for a Contributor to >>>>>>>> become an Author, or for a >>>>>>>> Committer to become a Reviewer. I have >>>>>>>> some thoughts on this, but >>>>>>>> >>>>>>>> want >>>>>>>> >>>>>>>> to hear from others first. >>>>>>>> >>>>>>>> >>>>>>>> I look forward to feedback on this >>>>>>>> proposal, and hope it will spark a >>>>>>>> productive discussion. >>>>>>>> >>>>>>>> -- Kevin Rushforth, OpenJFX Project Lead >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From johnvalrose at gmail.com Wed Feb 7 20:23:19 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Thu, 8 Feb 2018 07:23:19 +1100 Subject: future content of OpenJFX In-Reply-To: <6e83a4ee-4dfd-da2f-692f-de27682d46b1@jyloo.com> References: <6e83a4ee-4dfd-da2f-692f-de27682d46b1@jyloo.com> Message-ID: OK, after Wolfgang?s comments, I will unleash my rant again in the ?appropriate? thread as I feel that the lack of JavaFX adoption is very much due to the nature of the toolkit itself: Well, not only do I think that a docking framework is *that* complex, I see it as an essential part of any serious graphics toolkit. In general, I don?t understand all the limitations that people keep imposing on JavaFX as if we have to ?settle? for what is basically a 2nd class citizen compared with toolkits in other languages. Why can?t we just make JavaFX so compelling that developers from other languages are enticed by the feature set itself? There is no reason (other than a lack of effort) why JavaFX cannot be on par with Qt or Xamarin in terms of features, performance, tooling and adoption. Am I the only one that believes the world?s most popular and amazing programming language, platform and the JVM deserves a first class graphics toolkit? I understand the constraints imposed on Oracle staff but isn?t there anyone else out there in the community who shares my vision for JavaFX? It seems the general attitude is that JavaFX just needs to be a ?better Swing?. Forget about this nonsense of ?thinking outside the box?. There is NO BOX! JavaFX can and should be the best that we as a community can make it. And then we just keep making it better... If we don?t adopt such a vision and attitude then what is the point of doing anything at all? Just leave JavaFX to rot into oblivion and relegate Java to a server-side language only. I?m sure Jyloo and others would be much more successful and get real ROI on their investment in JavaFX if JavaFX itself was ?better? and more competitive. We don?t want developers in general to ask ?Hmm, so I need a graphics toolkit. I mostly know Java pretty well so I guess that means JavaFX will just have to do even though I?d use Qt if I knew C++ because it?s sooo much better?. What we want is ?Hmm, so I need a graphics toolkit. Let?s see what?s out there. Hey, this JavaFX thing looks awesome! It has all the features I need, performs really well, runs on most platforms and can be programmed by any JVM language! And there?s all those amazing IDEs and tools and Java developers are really easy to find. Yes, I think I?ll choose JavaFX for this new multi-million dollar system!? > On 8 Feb 2018, at 00:07, Wolfgang Zitzelsberger wrote: > > As a vendor of third party controls it's finally time for a feedback. We create look and feels and controls mainly for Swing/JavaFX desktop business applications. For us the most important things are: > > * Bugfixing - and we've already reported a lot over the past years > * Rock solid base controls > * An extendable API > * Behavior API > > Because of the API, in Java 9 for some methods the visibility changed from protected to package local - in conjunction with JPMS it's pretty hard to find proper workarounds. Some of our FX controls are pretty sophisticated (e.g. our Table control) but all the open bugs makes further work pretty expensive simply because it slows development extremely down. Even if we noticed some higher activity in bug fixing, many open bugs are moved from one release to the next without getting fixed. Another big issue is the bug fixing latency - when we post a bug today it will be possibly fixed in Java 11 or later. For us this means a new product feature can't be tested and released before Java 11 - time goes by and in the meantime other technologies win. > > Johan, JavaFX is much more popular on Google Trends now than Swing because some of you guys praised JavaFX as the "successor of Swing" and often followed the "Swing is dead" mantra. If you are looking for a competitor you should take a look at web technologies or other non-Java products. IMHO Swing is *not* a competitor it's simply the older brother. Anyway, this doesn't matter in this discussion. For us creating complex JavaFX controls is more complicated than in Swing - not because of JavaFX itself, it's mainly because the JavaFX API is currently too restricted (way too many final and package-only visible methods). > > We've already invested thousands of bucks in JavaFX development without any ROI. Not a problem at all but at some point this is quite frustrating. And we are far away from seeing a huge interest in JavaFX business products. BTW: Any number of downloads can be misleading if you know nothing about the user base - business, education, hobby, bot... > > Just my 2 cents. > > Cheers Wolfgang, > CEO of Jyloo Software > Germany > From dalibor.topic at oracle.com Thu Feb 8 12:20:16 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 8 Feb 2018 13:20:16 +0100 Subject: More community participation in JavaFX In-Reply-To: References: <5A786D32.6050600@oracle.com> <5A7A6188.2090608@oracle.com> <3937ac12-46f0-e324-f560-ec0571bbf80c@tbee.org> Message-ID: <0c772a24-5ca1-43c5-c18b-b422a2b21e34@oracle.com> On 07.02.2018 08:24, Johan Vos wrote: > I'm still all in favour of Open Source, but it should be sustainable. Meta: I'd recommend reading the "Why Modern Open Source Projects Fail" paper from last year at https://arxiv.org/pdf/1707.02327.pdf for a thorough, and very useful analysis (rather than collection of random anecdotal 'evidence', or rants as is customary in open source development ;) of modern, yet unsustainable open source projects. 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From nlisker at gmail.com Thu Feb 8 14:40:42 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 8 Feb 2018 16:40:42 +0200 Subject: Updating class javafx.beans.binding.When In-Reply-To: References: Message-ID: Iv'e managed to refactor a large portion of the class. About a 1/3 of the (repetitious) code was removed. On Tue, Feb 6, 2018 at 1:08 AM, Nir Lisker wrote: > Hi, > > I was looking at https://bugs.openjdk.java.net/browse/JDK-8089579, which > prompted me to have a look at When. There are a few points I would like to > address: > > * StringConditionBuilder#otherwise(ObservableStringValue) does not check > for null as other condition builders do. This results in a deeper NPE > when StringCondition tries to register a listener to the > ObservableStringValue. > > * I would like a (re)evaluation on the above bug ticket and thoughts on > the proposal of "on demand evaluation" using a Supplier or a similar > method. The behavior of the intended implementation would be to evaluate > 'then' and 'otherwise' whenever their condition is met, and only then. > > * The class can benefit from some small refactoring, such as using > Objects.requireNonNull for null checks and some code reuse to reduce the > chance of bugs such as the missing null check of StringConditionBuilder. > > * There are a few Javadoc corrections and some clarifications of the > current behavior could be beneficial as well. > > I can work on all of the above. How to proceed? > > - Nir > From org.openjdk at io7m.com Fri Feb 9 13:29:50 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Fri, 9 Feb 2018 13:29:50 +0000 Subject: The "javafx might not be present" problem Message-ID: <20180209132950.0502cb50@copperhead.int.arc7.info> Hello! I've been using Swing for many years. One of the things I like most about it is that it's essentially guaranteed to be present in any Java SE installation, and although it's a little outdated aesthetically, it works well and continues to work well. I've been exploring the possibility of migrating to JavaFX on and off, but the biggest showstopper for me is that JavaFX may not actually be present in any given user's installation. If someone installs the jre9-openjdk package on Arch Linux, for example, they don't get JavaFX. If they install the java-openjfx package, they do (although Arch only offers JavaFX 8 right now). I'm migrating to Java 9 modules, and all new projects will be fully modular projects. In the olden days (pre Java 9), it was possible to detect if JavaFX was present with a reflection hack: try { Class jfxPanel = classLoader.loadClass("javafx.embed.swing.JFXPanel"); isJavaFxAvailable = true; } catch (ClassNotFoundException e) { isJavaFxAvailable = false; } The idea being that you could at least display a friendly error message to the user explaining that they need to install JavaFX if they're using OpenJDK. But obviously in a Java 9 project, that's not going to work: You'd need to specify a "requires" clause on the JavaFX modules, and if they weren't present, the VM wouldn't even start up so the above check wouldn't get a chance to run. For applications, I could probably try to bundle JavaFX with them (although there may be licensing issues there). For libraries, I'm out of luck. The only apparent option there is for me to pick a set of Maven coordinates like "org.openjdk:javafx:8.0" and specify those in my libary's POM file (and assume that the user is smart enough to deploy JavaFX to a local repos to use it). I suppose what I'm really saying is: When (if ever) can I expect JavaFX to be present unconditionally with OpenJDK installs? I probably can't migrate to JavaFX until that day... -- Mark Raynsford | http://www.io7m.com From johan.vos at gluonhq.com Fri Feb 9 13:44:55 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 09 Feb 2018 13:44:55 +0000 Subject: The "javafx might not be present" problem In-Reply-To: <20180209132950.0502cb50@copperhead.int.arc7.info> References: <20180209132950.0502cb50@copperhead.int.arc7.info> Message-ID: Hi Mark, Is using jlink (https://docs.oracle.com/javase/9/tools/jlink.htm) packaging your app with the exact set of modules you need an option for you? That would eliminate the need for your users to have Java installed. Not only there is a (small) hurdle to install Java, but it needs to be the "correct" version of Java as well, and you would probably expect your users to update their JDK with security updates etc. I've been a long-time fan of the javapackager, and now that jlink allows you to create a custom runtime image, I think we have much better solutions than relying on the fact that an end-user installed an ok version of the JDK? But maybe I'm missing something, and is jlink not an option for you? - Johan On Fri, Feb 9, 2018 at 2:40 PM Mark Raynsford wrote: > Hello! > > I've been using Swing for many years. One of the things I like most > about it is that it's essentially guaranteed to be present in any Java > SE installation, and although it's a little outdated aesthetically, it > works well and continues to work well. > > I've been exploring the possibility of migrating to JavaFX on and off, > but the biggest showstopper for me is that JavaFX may not actually be > present in any given user's installation. If someone installs the > jre9-openjdk package on Arch Linux, for example, they don't get JavaFX. > If they install the java-openjfx package, they do (although Arch only > offers JavaFX 8 right now). > > I'm migrating to Java 9 modules, and all new projects will be fully > modular projects. In the olden days (pre Java 9), it was possible to > detect if JavaFX was present with a reflection hack: > > try { > Class jfxPanel = classLoader.loadClass("javafx.embed.swing.JFXPanel"); > isJavaFxAvailable = true; > } catch (ClassNotFoundException e) { > isJavaFxAvailable = false; > } > > The idea being that you could at least display a friendly error message > to the user explaining that they need to install JavaFX if they're > using OpenJDK. > > But obviously in a Java 9 project, that's not going to work: You'd need > to specify a "requires" clause on the JavaFX modules, and if they > weren't present, the VM wouldn't even start up so the above check > wouldn't get a chance to run. > > For applications, I could probably try to bundle JavaFX with them > (although there may be licensing issues there). For libraries, I'm out > of luck. The only apparent option there is for me to pick a set of > Maven coordinates like "org.openjdk:javafx:8.0" and specify those in my > libary's POM file (and assume that the user is smart enough to deploy > JavaFX to a local repos to use it). > > I suppose what I'm really saying is: When (if ever) can I expect JavaFX > to be present unconditionally with OpenJDK installs? I probably can't > migrate to JavaFX until that day... > > -- > Mark Raynsford | http://www.io7m.com > > From neugens at redhat.com Fri Feb 9 13:49:23 2018 From: neugens at redhat.com (Mario Torre) Date: Fri, 9 Feb 2018 14:49:23 +0100 Subject: The "javafx might not be present" problem In-Reply-To: <20180209132950.0502cb50@copperhead.int.arc7.info> References: <20180209132950.0502cb50@copperhead.int.arc7.info> Message-ID: On Fri, Feb 9, 2018 at 2:29 PM, Mark Raynsford wrote: > I suppose what I'm really saying is: When (if ever) can I expect JavaFX > to be present unconditionally with OpenJDK installs? I probably can't > migrate to JavaFX until that day... JavaFX is not part of the Java specifications for the JDK or its runtime, so the presence of the library in any distribution of OpenJDK pretty much depends on the vendor distributing you the binaries. There are some Linux distribution that started packaging a subset of OpenJFX (in most cases few notable missing bits are the audio codecs and the webview). I don't know if the same libraries will be bundled with the GPL binary from Oracle, that's probably a question somebody from Oracle may answer. The only way I can see JavaFX becoming included by default everywhere is if it becomes part of the spec. Cheers, Mario From mp at jugs.org Fri Feb 9 14:07:53 2018 From: mp at jugs.org (Michael Paus) Date: Fri, 9 Feb 2018 15:07:53 +0100 Subject: The "javafx might not be present" problem In-Reply-To: References: <20180209132950.0502cb50@copperhead.int.arc7.info> Message-ID: <13cc1400-0cb7-30b8-845b-e80a18bb45f0@jugs.org> Am 09.02.18 um 14:49 schrieb Mario Torre: > On Fri, Feb 9, 2018 at 2:29 PM, Mark Raynsford wrote: > >> I suppose what I'm really saying is: When (if ever) can I expect JavaFX >> to be present unconditionally with OpenJDK installs? I probably can't >> migrate to JavaFX until that day... > JavaFX is not part of the Java specifications for the JDK or its > runtime, so the presence of the library in any distribution of OpenJDK > pretty much depends on the vendor distributing you the binaries. > > There are some Linux distribution that started packaging a subset of > OpenJFX (in most cases few notable missing bits are the audio codecs > and the webview). I don't know if the same libraries will be bundled > with the GPL binary from Oracle, that's probably a question somebody > from Oracle may answer. > > The only way I can see JavaFX becoming included by default everywhere > is if it becomes part of the spec. In practice this is really a pain point and very bad advertising for JavaFX. Who defines that everything Open... can only contain what is included in "the spec"? Who keeps us from creating a product OpenJDKFX which we define to contain OpenJDK + OpenJFX. I'd like to see a complete and open version of Java but at the moment everybody seems to restrict themselves to only OpenJDK. Even Oracle at their EA download page deliver the open version of the JDK without JavaFX which I simply don't understand and which makes this version of the JDK completely useless to me. From sdesofi at icloud.com Fri Feb 9 14:20:37 2018 From: sdesofi at icloud.com (Stephen Desofi) Date: Fri, 09 Feb 2018 09:20:37 -0500 Subject: The "javafx might not be present" problem In-Reply-To: <13cc1400-0cb7-30b8-845b-e80a18bb45f0@jugs.org> References: <20180209132950.0502cb50@copperhead.int.arc7.info> <13cc1400-0cb7-30b8-845b-e80a18bb45f0@jugs.org> Message-ID: <7D96BC4C-F874-4BDC-91C0-0F0D08FE35E4@icloud.com> JEE is not part of the spec but is ?in addition to?. Maybe FX should be treated the same way with its own standards body. Maybe even with it?s own independent platform implementations based on a common spec just like JEE. Hmm. Thinking out loud here. Steve Sent from my iPhone > On Feb 9, 2018, at 9:07 AM, Michael Paus wrote: > >> Am 09.02.18 um 14:49 schrieb Mario Torre: >>> On Fri, Feb 9, 2018 at 2:29 PM, Mark Raynsford wrote: >>> >>> I suppose what I'm really saying is: When (if ever) can I expect JavaFX >>> to be present unconditionally with OpenJDK installs? I probably can't >>> migrate to JavaFX until that day... >> JavaFX is not part of the Java specifications for the JDK or its >> runtime, so the presence of the library in any distribution of OpenJDK >> pretty much depends on the vendor distributing you the binaries. >> >> There are some Linux distribution that started packaging a subset of >> OpenJFX (in most cases few notable missing bits are the audio codecs >> and the webview). I don't know if the same libraries will be bundled >> with the GPL binary from Oracle, that's probably a question somebody >> from Oracle may answer. >> >> The only way I can see JavaFX becoming included by default everywhere >> is if it becomes part of the spec. > In practice this is really a pain point and very bad advertising for JavaFX. > Who defines that everything Open... can only contain what is included in "the spec"? > Who keeps us from creating a product OpenJDKFX which we define to contain > OpenJDK + OpenJFX. I'd like to see a complete and open version of Java but > at the moment everybody seems to restrict themselves to only OpenJDK. > Even Oracle at their EA download page deliver the open version of the JDK > without JavaFX which I simply don't understand and which makes this version > of the JDK completely useless to me. > From org.openjdk at io7m.com Fri Feb 9 14:20:49 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Fri, 9 Feb 2018 14:20:49 +0000 Subject: The "javafx might not be present" problem In-Reply-To: References: <20180209132950.0502cb50@copperhead.int.arc7.info> Message-ID: <20180209142049.51fe5cfb@copperhead.int.arc7.info> On 2018-02-09T13:44:55 +0000 Johan Vos wrote: > Hi Mark, > > Is using jlink (https://docs.oracle.com/javase/9/tools/jlink.htm) packaging > your app with the exact set of modules you need an option for you? > That would eliminate the need for your users to have Java installed. Not > only there is a (small) hurdle to install Java, but it needs to be the > "correct" version of Java as well, and you would probably expect your users > to update their JDK with security updates etc. > > I've been a long-time fan of the javapackager, and now that jlink allows > you to create a custom runtime image, I think we have much better solutions > than relying on the fact that an end-user installed an ok version of the > JDK? > > But maybe I'm missing something, and is jlink not an option for you? 'Ello. Oh, it's certainly an option for applications - if you're willing to distribute separate platform-specific downloads for each platform. To date, I've not offered platform-specific downloads for any applications: Why would I when I can give all users the same platform-independent jar file? I'm still investigating coming up with a way to use (or possibly abuse) jlink to produce a multi-platform distribution so that I still only offer one single download for all platforms (with some magic scripts or wrappers that execute the correct included JRE for the platform). For libraries, it's obviously no help. For libraries, I'd need either a guarantee that OpenJFX is present wherever a particular version of Java is, or I'd need Maven coordinates so that the library can specify an accurate (and automatically resolvable) dependency on JavaFX. Personally, if a library isn't present on Maven Central, then I don't even consider depending on it. Being deployed to Maven Central is, for me, a basic indicator that the project in question is competently maintained. OpenJFX has elevated status in this regard in that it's not on Maven Central but I would still consider depending on it if distribution issues could be solved. -- Mark Raynsford | http://www.io7m.com From org.openjdk at io7m.com Fri Feb 9 14:22:45 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Fri, 9 Feb 2018 14:22:45 +0000 Subject: The "javafx might not be present" problem In-Reply-To: References: <20180209132950.0502cb50@copperhead.int.arc7.info> Message-ID: <20180209142245.7ff3ab80@copperhead.int.arc7.info> On 2018-02-09T14:49:23 +0100 Mario Torre wrote: > > JavaFX is not part of the Java specifications for the JDK or its > runtime, so the presence of the library in any distribution of OpenJDK > pretty much depends on the vendor distributing you the binaries. Ah, my mistake then. I thought it actually was part of SE now. I think I originally misread: "Starting with Java SE 7 Update 6, JavaFX is part of Oracle's Java SE implementation." https://www.java.com/en/javafx/ I misread that as "Starting with Java SE 7 Update 6, JavaFX is part of Oracle's Java SE specification." -- Mark Raynsford | http://www.io7m.com From neugens at redhat.com Fri Feb 9 14:22:16 2018 From: neugens at redhat.com (Mario Torre) Date: Fri, 9 Feb 2018 15:22:16 +0100 Subject: The "javafx might not be present" problem In-Reply-To: <13cc1400-0cb7-30b8-845b-e80a18bb45f0@jugs.org> References: <20180209132950.0502cb50@copperhead.int.arc7.info> <13cc1400-0cb7-30b8-845b-e80a18bb45f0@jugs.org> Message-ID: On Fri, Feb 9, 2018 at 3:07 PM, Michael Paus wrote: > Am 09.02.18 um 14:49 schrieb Mario Torre: >> >> On Fri, Feb 9, 2018 at 2:29 PM, Mark Raynsford >> wrote: >> >>> I suppose what I'm really saying is: When (if ever) can I expect JavaFX >>> to be present unconditionally with OpenJDK installs? I probably can't >>> migrate to JavaFX until that day... >> >> JavaFX is not part of the Java specifications for the JDK or its >> runtime, so the presence of the library in any distribution of OpenJDK >> pretty much depends on the vendor distributing you the binaries. >> >> There are some Linux distribution that started packaging a subset of >> OpenJFX (in most cases few notable missing bits are the audio codecs >> and the webview). I don't know if the same libraries will be bundled >> with the GPL binary from Oracle, that's probably a question somebody >> from Oracle may answer. >> >> The only way I can see JavaFX becoming included by default everywhere >> is if it becomes part of the spec. > > In practice this is really a pain point and very bad advertising for JavaFX. > Who defines that everything Open... can only contain what is included in > "the spec"? > Who keeps us from creating a product OpenJDKFX which we define to contain > OpenJDK + OpenJFX. I'd like to see a complete and open version of Java but > at the moment everybody seems to restrict themselves to only OpenJDK. > Even Oracle at their EA download page deliver the open version of the JDK > without JavaFX which I simply don't understand and which makes this version > of the JDK completely useless to me. You already have a complete, compliant and open version of Java. The Java spec and the TCK define what is and what is not Java, and it doesn't cover JavaFX. JavaFX can be included by downstream vendors, but that's entirely up to them, in that regard is not different than bundling Tomcat or maven with your JDK. I agree that would be nice to have everywhere, but again I can't see that happening until it becomes part of the spec. Cheers, Mario From mp at jugs.org Fri Feb 9 14:44:03 2018 From: mp at jugs.org (Michael Paus) Date: Fri, 9 Feb 2018 15:44:03 +0100 Subject: The "javafx might not be present" problem In-Reply-To: References: <20180209132950.0502cb50@copperhead.int.arc7.info> <13cc1400-0cb7-30b8-845b-e80a18bb45f0@jugs.org> Message-ID: Am 09.02.18 um 15:22 schrieb Mario Torre: > On Fri, Feb 9, 2018 at 3:07 PM, Michael Paus wrote: >> Am 09.02.18 um 14:49 schrieb Mario Torre: >>> On Fri, Feb 9, 2018 at 2:29 PM, Mark Raynsford >>> wrote: >>> >>>> I suppose what I'm really saying is: When (if ever) can I expect JavaFX >>>> to be present unconditionally with OpenJDK installs? I probably can't >>>> migrate to JavaFX until that day... >>> JavaFX is not part of the Java specifications for the JDK or its >>> runtime, so the presence of the library in any distribution of OpenJDK >>> pretty much depends on the vendor distributing you the binaries. >>> >>> There are some Linux distribution that started packaging a subset of >>> OpenJFX (in most cases few notable missing bits are the audio codecs >>> and the webview). I don't know if the same libraries will be bundled >>> with the GPL binary from Oracle, that's probably a question somebody >>> from Oracle may answer. >>> >>> The only way I can see JavaFX becoming included by default everywhere >>> is if it becomes part of the spec. >> In practice this is really a pain point and very bad advertising for JavaFX. >> Who defines that everything Open... can only contain what is included in >> "the spec"? >> Who keeps us from creating a product OpenJDKFX which we define to contain >> OpenJDK + OpenJFX. I'd like to see a complete and open version of Java but >> at the moment everybody seems to restrict themselves to only OpenJDK. >> Even Oracle at their EA download page deliver the open version of the JDK >> without JavaFX which I simply don't understand and which makes this version >> of the JDK completely useless to me. > You already have a complete, compliant and open version of Java. The > Java spec and the TCK define what is and what is not Java, and it > doesn't cover JavaFX. > > JavaFX can be included by downstream vendors, but that's entirely up > to them, in that regard is not different than bundling Tomcat or maven > with your JDK. There is a big difference because you just don't have to bundle all these other things with the JDK because you can add them later if you need them. This is different from the OpenJDK-OpenJFX combo which has to be built and distributed together for technical reasons. From dalibor.topic at oracle.com Fri Feb 9 17:52:55 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 9 Feb 2018 18:52:55 +0100 Subject: The "javafx might not be present" problem In-Reply-To: <13cc1400-0cb7-30b8-845b-e80a18bb45f0@jugs.org> References: <20180209132950.0502cb50@copperhead.int.arc7.info> <13cc1400-0cb7-30b8-845b-e80a18bb45f0@jugs.org> Message-ID: <9a1d6a3a-f71f-f92d-c598-a7322e3cf049@oracle.com> On 09.02.2018 15:07, Michael Paus wrote: > Who defines that everything Open... can only contain what is included in > "the spec"? http://openjdk.java.net/projects/jdk/ "The goal of this long-running Project is to produce a series of open-source reference implementations of the Java SE Platform, as specified by JSRs in the Java Community Process. " 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From john at status6.com Fri Feb 9 18:28:56 2018 From: john at status6.com (John Neffenger) Date: Fri, 9 Feb 2018 10:28:56 -0800 Subject: The "javafx might not be present" problem In-Reply-To: <20180209132950.0502cb50@copperhead.int.arc7.info> References: <20180209132950.0502cb50@copperhead.int.arc7.info> Message-ID: <45e43abd-53ef-99d9-eb37-0cee7752e4f7@status6.com> On 02/09/2018 05:29 AM, Mark Raynsford wrote: > I've been exploring the possibility of migrating to JavaFX on and off, > but the biggest showstopper for me is that JavaFX may not actually be > present in any given user's installation. If someone installs the > jre9-openjdk package on Arch Linux, for example, they don't get JavaFX. I reported the bug below to fix this same issue for Ubuntu: JavaFX support is in Oracle JDK 9 but missing in Ubuntu OpenJDK 9 https://bugs.launchpad.net/ubuntu/+source/openjdk-9/+bug/1721852 You can comment there if you're interested in seeing support for JavaFX be part of the default installation of OpenJDK 9 or 10 on Ubuntu. I'm hoping it can get included in time for the next Long Term Support release of Ubuntu 18.04 in April. John From org.openjdk at io7m.com Fri Feb 9 19:08:44 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Fri, 9 Feb 2018 19:08:44 +0000 Subject: The "javafx might not be present" problem In-Reply-To: <45e43abd-53ef-99d9-eb37-0cee7752e4f7@status6.com> References: <20180209132950.0502cb50@copperhead.int.arc7.info> <45e43abd-53ef-99d9-eb37-0cee7752e4f7@status6.com> Message-ID: <20180209190844.1ec72990@copperhead.int.arc7.info> On 2018-02-09T10:28:56 -0800 John Neffenger wrote: > > I reported the bug below to fix this same issue for Ubuntu: > > JavaFX support is in Oracle JDK 9 but missing in Ubuntu OpenJDK 9 > https://bugs.launchpad.net/ubuntu/+source/openjdk-9/+bug/1721852 > > You can comment there if you're interested in seeing support for JavaFX > be part of the default installation of OpenJDK 9 or 10 on Ubuntu. I'm > hoping it can get included in time for the next Long Term Support > release of Ubuntu 18.04 in April. I'll be commenting there as I would like to see it fixed. I'd like to reiterate though that it doesn't solve the problem of: * Depending on OpenJFX from library code: You can't specify a dependency on OpenJFX because it doesn't have Maven coordinates. OpenJFX occupies a grey area where it's sort of part of the JDK and sort of not. * Using OpenJFX from an application that hasn't been processed with jlink and is using Java 9 modules: You can't check reflectively for the existence of JavaFX without mentioning it in the module system. The above ticket just reduces the number of places where JavaFX might not be present by one. I'd prefer a more general solution to this problem. I am volunteering to help if there's any way that I can help. -- Mark Raynsford | http://www.io7m.com From sven.reimers at gmail.com Fri Feb 9 20:32:38 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 9 Feb 2018 21:32:38 +0100 Subject: The "javafx might not be present" problem In-Reply-To: <9a1d6a3a-f71f-f92d-c598-a7322e3cf049@oracle.com> References: <20180209132950.0502cb50@copperhead.int.arc7.info> <13cc1400-0cb7-30b8-845b-e80a18bb45f0@jugs.org> <9a1d6a3a-f71f-f92d-c598-a7322e3cf049@oracle.com> Message-ID: Hi, so we will need a JSR first and get it added to SE afterwards. That does not sound very feasible. Any comments? Sven Am 09.02.2018 18:53 schrieb "dalibor topic" : > On 09.02.2018 15:07, Michael Paus wrote: > >> Who defines that everything Open... can only contain what is included in >> "the spec"? >> > > http://openjdk.java.net/projects/jdk/ > > "The goal of this long-running Project is to produce a series of > open-source reference implementations of the Java SE Platform, as specified > by JSRs in the Java Community Process. " > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Ham > > burg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-8 > 0992 > 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, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From dalibor.topic at oracle.com Fri Feb 9 22:16:09 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 9 Feb 2018 23:16:09 +0100 Subject: The "javafx might not be present" problem In-Reply-To: <45e43abd-53ef-99d9-eb37-0cee7752e4f7@status6.com> References: <20180209132950.0502cb50@copperhead.int.arc7.info> <45e43abd-53ef-99d9-eb37-0cee7752e4f7@status6.com> Message-ID: <61875607-d1be-488d-d3da-88c0c45a5194@oracle.com> On 09.02.2018 19:28, John Neffenger wrote: > You can comment there if you're interested in seeing support for JavaFX > be part of the default installation of OpenJDK 9 or 10 on Ubuntu. I'm > hoping it can get included in time for the next Long Term Support > release of Ubuntu 18.04 in April. See https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule for the 18.04 release schedule. Feature freeze is coming up on March 1st. There won't be OpenJDK 9 in 18.04. See https://lists.ubuntu.com/archives/ubuntu-release/2018-February/004275.html for details. 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri Feb 9 23:00:44 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Sat, 10 Feb 2018 00:00:44 +0100 Subject: The "javafx might not be present" problem In-Reply-To: References: <20180209132950.0502cb50@copperhead.int.arc7.info> <13cc1400-0cb7-30b8-845b-e80a18bb45f0@jugs.org> <9a1d6a3a-f71f-f92d-c598-a7322e3cf049@oracle.com> Message-ID: <29e9e1b3-1245-13ef-2144-5c31410875fd@oracle.com> On 09.02.2018 21:32, Sven Reimers wrote: > Hi, > > so we will need a JSR first and get it added to SE afterwards. > > That does not sound very feasible. > > Any comments? JDK 10 is in rampdown phase 2, per http://openjdk.java.net/projects/jdk/10/ . No new features would be added at this phase. Java SE 11 JSR is well underway, too: https://jcp.org/en/jsr/detail?id=384 . With 6.5 months to go until September and the minimal timeline for a new JSR being around 8.5 months judging by https://jcp.org/images/resources/2_9gantt.gif adding a whole new JSR into JDK 11 might not be quite as simple as it may sound. Running a JSR for an open source library would not make a lot of sense if the sole purpose of that work was to add it to some JDK download. The module system already exists. cheers, dalibor topic > > Sven > > > > Am 09.02.2018 18:53 schrieb "dalibor topic" >: > > On 09.02.2018 15:07, Michael Paus wrote: > > Who defines that everything Open... can only contain what is > included in "the spec"? > > > http://openjdk.java.net/projects/jdk/ > > > "The goal of this long-running Project is to produce a series of > open-source reference implementations of the Java SE Platform, as > specified by JSRs in the Java Community Process. " > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 > | Mobile: +491737185961 > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Ham > burg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-8 > 0992 > 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, Jan Schultheiss, Val Maher > > > Oracle is committed to developing > practices and products that help protect the environment > -- 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From alexander.matveev at oracle.com Sat Feb 10 02:07:35 2018 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 9 Feb 2018 18:07:35 -0800 Subject: [11] Review request for 8195803: Eliminate use of sun.nio.ch.DirectBuffer in javafx.media Message-ID: <6aa41f3d-0b8d-7c58-1d54-e8aeb78d4eee@oracle.com> Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8195803 Removed dependency on sun.nio.ch.DirectBuffer. Thanks, Alexander From kevin.rushforth at oracle.com Mon Feb 12 22:02:28 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Feb 2018 14:02:28 -0800 Subject: CFV: New OpenJFX Committer: Rajath Kamath Message-ID: <5A820EF4.6020409@oracle.com> I hereby nominate Rajath Kamath [1] to OpenJFX Committer. Rajath is a member of JavaFX team at Oracle, who has contributed 11 changesets [2][3] to OpenJFX. Votes are due by February 26, 2018. Only current OpenJFX Committers [4] 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 [5]. Nomination to a project Committer is described in [6]. Thanks. -- Kevin [1] http://openjdk.java.net/census#rkamath [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28rkamath%29 [3] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=rajath.kamath [4] http://openjdk.java.net/census#openjfx [5] http://openjdk.java.net/bylaws#lazy-consensus [6] http://openjdk.java.net/projects#project-committer From kevin.rushforth at oracle.com Mon Feb 12 22:02:51 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Feb 2018 14:02:51 -0800 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5A820EF4.6020409@oracle.com> References: <5A820EF4.6020409@oracle.com> Message-ID: <5A820F0B.3000703@oracle.com> Vote: YES Kevin Rushforth wrote: > I hereby nominate Rajath Kamath [1] to OpenJFX Committer. > > Rajath is a member of JavaFX team at Oracle, who has contributed 11 > changesets [2][3] to OpenJFX. > > Votes are due by February 26, 2018. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a > project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#rkamath > > [2] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28rkamath%29 > > [3] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=rajath.kamath > > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > From philip.race at oracle.com Tue Feb 13 00:33:05 2018 From: philip.race at oracle.com (Philip Race) Date: Mon, 12 Feb 2018 16:33:05 -0800 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5A820EF4.6020409@oracle.com> References: <5A820EF4.6020409@oracle.com> Message-ID: <5A823241.8070600@oracle.com> Vote: yes -phil. From alexander.matveev at oracle.com Tue Feb 13 00:41:17 2018 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 12 Feb 2018 16:41:17 -0800 Subject: [11] Review request for 8194062: Remove support for libavcodec 53 and 55 Message-ID: Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8194062 Removed support for libav 53 and 55. Thanks, Alexander From murali.billa at oracle.com Tue Feb 13 06:02:29 2018 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 12 Feb 2018 22:02:29 -0800 (PST) Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5A820F0B.3000703@oracle.com> References: <5A820EF4.6020409@oracle.com> <5A820F0B.3000703@oracle.com> Message-ID: <33b53ce8-034e-4dff-909c-1188bf6b1112@default> Vote: YES Kevin Rushforth wrote: > I hereby nominate Rajath Kamath [1] to OpenJFX Committer. > > Rajath is a member of JavaFX team at Oracle, who has contributed 11 > changesets [2][3] to OpenJFX. > > Votes are due by February 26, 2018. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a > project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#rkamath > > [2] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=auth > or%28rkamath%29 > > [3] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=raja > th.kamath > > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > From arunprasad.rajkumar at oracle.com Tue Feb 13 06:06:09 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 13 Feb 2018 11:36:09 +0530 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5A820EF4.6020409@oracle.com> References: <5A820EF4.6020409@oracle.com> Message-ID: <26BAD605-3B43-445E-B4BE-6D05ED27A885@oracle.com> Vote: YES > On 13-Feb-2018, at 3:32 AM, Kevin Rushforth wrote: > > I hereby nominate Rajath Kamath [1] to OpenJFX Committer. > > Rajath is a member of JavaFX team at Oracle, who has contributed 11 changesets [2][3] to OpenJFX. > > Votes are due by February 26, 2018. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#rkamath > > [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28rkamath%29 > [3] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=rajath.kamath > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > From guru.hb at oracle.com Tue Feb 13 06:25:16 2018 From: guru.hb at oracle.com (Guru Prasad HB) Date: Mon, 12 Feb 2018 22:25:16 -0800 (PST) Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5A820EF4.6020409@oracle.com> References: <5A820EF4.6020409@oracle.com> Message-ID: Vote: Yes -----Original Message----- From: Kevin Rushforth Sent: Tuesday, February 13, 2018 3:32 AM To: Rajath Kamath ; openjfx-dev at openjdk.java.net Subject: CFV: New OpenJFX Committer: Rajath Kamath I hereby nominate Rajath Kamath [1] to OpenJFX Committer. Rajath is a member of JavaFX team at Oracle, who has contributed 11 changesets [2][3] to OpenJFX. Votes are due by February 26, 2018. Only current OpenJFX Committers [4] 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 [5]. Nomination to a project Committer is described in [6]. Thanks. -- Kevin [1] http://openjdk.java.net/census#rkamath [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28rkamath%29 [3] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=rajath.kamath [4] http://openjdk.java.net/census#openjfx [5] http://openjdk.java.net/bylaws#lazy-consensus [6] http://openjdk.java.net/projects#project-committer From semyon.sadetsky at oracle.com Tue Feb 13 16:05:56 2018 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 13 Feb 2018 08:05:56 -0800 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5A820EF4.6020409@oracle.com> References: <5A820EF4.6020409@oracle.com> Message-ID: <5bf68a5b-c62d-81e6-7851-27f5d175a300@oracle.com> Vote: yes --Semyon On 02/12/2018 02:02 PM, Kevin Rushforth wrote: > I hereby nominate Rajath Kamath [1] to OpenJFX Committer. > > Rajath is a member of JavaFX team at Oracle, who has contributed 11 > changesets [2][3] to OpenJFX. > > Votes are due by February 26, 2018. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a > project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#rkamath > > [2] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28rkamath%29 > [3] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=rajath.kamath > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > From kevin.rushforth at oracle.com Tue Feb 13 16:26:16 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Feb 2018 08:26:16 -0800 Subject: [11] Review request: 8196621: AABalanceTest fails on systems with small screen size Message-ID: <5A8311A8.5050905@oracle.com> Murali, Please review the following test fix: https://bugs.openjdk.java.net/browse/JDK-8196621 http://cr.openjdk.java.net/~kcr/8196621/webrev.00/ -- Kevin From arunprasad.rajkumar at oracle.com Tue Feb 13 19:31:21 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 14 Feb 2018 01:01:21 +0530 Subject: [10] Review request: 8197463: Update libxml2 to version 2.9.7 Message-ID: <21AD1844-BA72-4DE8-8505-F5A152B3A42F@oracle.com> Hi, Please review the following fix, Bug: https://bugs.openjdk.java.net/browse/JDK-8197463 Compressed changeset: http://cr.openjdk.java.net/~arajkumar/8197463/webrev.00/libxml2-2.9.7v3.diff.gz Cmake only changes for review: http://cr.openjdk.java.net/~arajkumar/8197463/webrev.00/cmake-changes Following are list of changes made as part of this bug: 1. Merged libxml2-2.9.7 changes from https://git.gnome.org/browse/libxml2/tag/?h=v2.9.7 2. Enabled libxml compilation on Linux and macOS 3. Enabled libxslt compilation on Linux and macOS Thanks, Arun From tom.schindl at bestsolution.at Tue Feb 13 20:05:47 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 13 Feb 2018 21:05:47 +0100 Subject: Packaging DMG with Ant fails on OS-X 10.13.3 Message-ID: <2df9369f-916c-fc6e-e235-ef93a8a4d200@bestsolution.at> Hi, It looks like the packaging of JavaFX-DMGs is broken on the latest OS-X System. Has anyone ancountered the same? Tom From steve at weblite.ca Tue Feb 13 21:34:40 2018 From: steve at weblite.ca (Steve Hannah) Date: Tue, 13 Feb 2018 13:34:40 -0800 Subject: Packaging DMG with Ant fails on OS-X 10.13.3 In-Reply-To: <2df9369f-916c-fc6e-e235-ef93a8a4d200@bestsolution.at> References: <2df9369f-916c-fc6e-e235-ef93a8a4d200@bestsolution.at> Message-ID: I ran into this bug a couple months ago with javafx packager on High Sierra. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190758 The problem is basically that hdiutil changed its default file system to APFS, which breaks many things. Ultimately I wasn't able to get javafx packager to work even with the workarounds listed on that bug so just generated the DMG using a 3rd party script ( https://github.com/andreyvit/create-dmg) to work around it. Steve On Tue, Feb 13, 2018 at 12:05 PM, Tom Schindl wrote: > Hi, > > It looks like the packaging of JavaFX-DMGs is broken on the latest OS-X > System. Has anyone ancountered the same? > > Tom > -- Steve Hannah Web Lite Solutions Corp. From kevin.rushforth at oracle.com Tue Feb 13 21:41:05 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Feb 2018 13:41:05 -0800 Subject: Packaging DMG with Ant fails on OS-X 10.13.3 In-Reply-To: References: <2df9369f-916c-fc6e-e235-ef93a8a4d200@bestsolution.at> Message-ID: <5A835B71.6010701@oracle.com> Have you tried with JDK 10 yet? The bug you reference is fixed in 10. -- Kevin Steve Hannah wrote: > I ran into this bug a couple months ago with javafx packager on High Sierra. > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190758 > > The problem is basically that hdiutil changed its default file system to > APFS, which breaks many things. Ultimately I wasn't able to get javafx > packager to work even with the workarounds listed on that bug so just > generated the DMG using a 3rd party script ( > https://github.com/andreyvit/create-dmg) to work around it. > > Steve > > On Tue, Feb 13, 2018 at 12:05 PM, Tom Schindl > wrote: > > >> Hi, >> >> It looks like the packaging of JavaFX-DMGs is broken on the latest OS-X >> System. Has anyone ancountered the same? >> >> Tom >> >> > > > > From steve at weblite.ca Tue Feb 13 21:43:18 2018 From: steve at weblite.ca (Steve Hannah) Date: Tue, 13 Feb 2018 13:43:18 -0800 Subject: Packaging DMG with Ant fails on OS-X 10.13.3 In-Reply-To: <5A835B71.6010701@oracle.com> References: <2df9369f-916c-fc6e-e235-ef93a8a4d200@bestsolution.at> <5A835B71.6010701@oracle.com> Message-ID: No, didn't try Java 10. It was a production server that is running Java 8 - and changing that would have been a can of worms I wasn't ready to open. On Tue, Feb 13, 2018 at 1:41 PM, Kevin Rushforth wrote: > Have you tried with JDK 10 yet? The bug you reference is fixed in 10. > > -- Kevin > > > Steve Hannah wrote: > > I ran into this bug a couple months ago with javafx packager on High Sierra.https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190758 > > The problem is basically that hdiutil changed its default file system to > APFS, which breaks many things. Ultimately I wasn't able to get javafx > packager to work even with the workarounds listed on that bug so just > generated the DMG using a 3rd party script (https://github.com/andreyvit/create-dmg) to work around it. > > Steve > > On Tue, Feb 13, 2018 at 12:05 PM, Tom Schindl > wrote: > > > > Hi, > > It looks like the packaging of JavaFX-DMGs is broken on the latest OS-X > System. Has anyone ancountered the same? > > Tom > > > > > > -- Steve Hannah Web Lite Solutions Corp. From kevin.rushforth at oracle.com Tue Feb 13 21:44:47 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Feb 2018 13:44:47 -0800 Subject: Packaging DMG with Ant fails on OS-X 10.13.3 In-Reply-To: References: <2df9369f-916c-fc6e-e235-ef93a8a4d200@bestsolution.at> <5A835B71.6010701@oracle.com> Message-ID: <5A835C4F.8050707@oracle.com> The bug is also fixed in the recently released JDK 8u162. -- Kevin Steve Hannah wrote: > No, didn't try Java 10. It was a production server that is running > Java 8 - and changing that would have been a can of worms I wasn't > ready to open. > > > On Tue, Feb 13, 2018 at 1:41 PM, Kevin Rushforth > > wrote: > > Have you tried with JDK 10 yet? The bug you reference is fixed in 10. > > -- Kevin > > > Steve Hannah wrote: >> I ran into this bug a couple months ago with javafx packager on High Sierra. >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190758 >> >> The problem is basically that hdiutil changed its default file system to >> APFS, which breaks many things. Ultimately I wasn't able to get javafx >> packager to work even with the workarounds listed on that bug so just >> generated the DMG using a 3rd party script ( >> https://github.com/andreyvit/create-dmg ) to work around it. >> >> Steve >> >> On Tue, Feb 13, 2018 at 12:05 PM, Tom Schindl >> wrote: >> >> >>> Hi, >>> >>> It looks like the packaging of JavaFX-DMGs is broken on the latest OS-X >>> System. Has anyone ancountered the same? >>> >>> Tom >>> >>> >> > > > > > -- > Steve Hannah > Web Lite Solutions Corp. From kevin.rushforth at oracle.com Tue Feb 13 21:50:42 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Feb 2018 13:50:42 -0800 Subject: The "javafx might not be present" problem In-Reply-To: References: <20180209132950.0502cb50@copperhead.int.arc7.info> <13cc1400-0cb7-30b8-845b-e80a18bb45f0@jugs.org> Message-ID: <5A835DB2.7020808@oracle.com> > There is a big difference because you just don't have to bundle all these > other things with the JDK because you can add them later if you need > them. > This is different from the OpenJDK-OpenJFX combo which has to be built > and distributed together for technical reasons. We are working to eliminate this dependency, to make it easier for OpenJFX to be used with OpenJDK builds that don't already contain javafx.* modules. -- Kevin Michael Paus wrote: > Am 09.02.18 um 15:22 schrieb Mario Torre: >> On Fri, Feb 9, 2018 at 3:07 PM, Michael Paus wrote: >>> Am 09.02.18 um 14:49 schrieb Mario Torre: >>>> On Fri, Feb 9, 2018 at 2:29 PM, Mark Raynsford >>>> wrote: >>>> >>>>> I suppose what I'm really saying is: When (if ever) can I expect >>>>> JavaFX >>>>> to be present unconditionally with OpenJDK installs? I probably can't >>>>> migrate to JavaFX until that day... >>>> JavaFX is not part of the Java specifications for the JDK or its >>>> runtime, so the presence of the library in any distribution of OpenJDK >>>> pretty much depends on the vendor distributing you the binaries. >>>> >>>> There are some Linux distribution that started packaging a subset of >>>> OpenJFX (in most cases few notable missing bits are the audio codecs >>>> and the webview). I don't know if the same libraries will be bundled >>>> with the GPL binary from Oracle, that's probably a question somebody >>>> from Oracle may answer. >>>> >>>> The only way I can see JavaFX becoming included by default everywhere >>>> is if it becomes part of the spec. >>> In practice this is really a pain point and very bad advertising for >>> JavaFX. >>> Who defines that everything Open... can only contain what is >>> included in >>> "the spec"? >>> Who keeps us from creating a product OpenJDKFX which we define to >>> contain >>> OpenJDK + OpenJFX. I'd like to see a complete and open version of >>> Java but >>> at the moment everybody seems to restrict themselves to only OpenJDK. >>> Even Oracle at their EA download page deliver the open version of >>> the JDK >>> without JavaFX which I simply don't understand and which makes this >>> version >>> of the JDK completely useless to me. >> You already have a complete, compliant and open version of Java. The >> Java spec and the TCK define what is and what is not Java, and it >> doesn't cover JavaFX. >> >> JavaFX can be included by downstream vendors, but that's entirely up >> to them, in that regard is not different than bundling Tomcat or maven >> with your JDK. > There is a big difference because you just don't have to bundle all these > other things with the JDK because you can add them later if you need > them. > This is different from the OpenJDK-OpenJFX combo which has to be built > and distributed together for technical reasons. > > From steve at weblite.ca Tue Feb 13 21:58:32 2018 From: steve at weblite.ca (Steve Hannah) Date: Tue, 13 Feb 2018 13:58:32 -0800 Subject: Packaging DMG with Ant fails on OS-X 10.13.3 In-Reply-To: <5A835C4F.8050707@oracle.com> References: <2df9369f-916c-fc6e-e235-ef93a8a4d200@bestsolution.at> <5A835B71.6010701@oracle.com> <5A835C4F.8050707@oracle.com> Message-ID: I tried that one, but it didn't seem to correct the problem for us. On Tue, Feb 13, 2018 at 1:44 PM, Kevin Rushforth wrote: > The bug is also fixed in the recently released JDK 8u162. > > -- Kevin > > > Steve Hannah wrote: > > No, didn't try Java 10. It was a production server that is running Java 8 > - and changing that would have been a can of worms I wasn't ready to open. > > > On Tue, Feb 13, 2018 at 1:41 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Have you tried with JDK 10 yet? The bug you reference is fixed in 10. >> >> -- Kevin >> >> >> Steve Hannah wrote: >> >> I ran into this bug a couple months ago with javafx packager on High Sierra.https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190758 >> >> The problem is basically that hdiutil changed its default file system to >> APFS, which breaks many things. Ultimately I wasn't able to get javafx >> packager to work even with the workarounds listed on that bug so just >> generated the DMG using a 3rd party script (https://github.com/andreyvit/create-dmg) to work around it. >> >> Steve >> >> On Tue, Feb 13, 2018 at 12:05 PM, Tom Schindl >> wrote: >> >> >> >> Hi, >> >> It looks like the packaging of JavaFX-DMGs is broken on the latest OS-X >> System. Has anyone ancountered the same? >> >> Tom >> >> >> >> > > > -- > Steve Hannah > Web Lite Solutions Corp. > > -- Steve Hannah Web Lite Solutions Corp. From mp at jugs.org Tue Feb 13 22:27:18 2018 From: mp at jugs.org (Michael Paus) Date: Tue, 13 Feb 2018 23:27:18 +0100 Subject: The "javafx might not be present" problem In-Reply-To: <5A835DB2.7020808@oracle.com> References: <20180209132950.0502cb50@copperhead.int.arc7.info> <13cc1400-0cb7-30b8-845b-e80a18bb45f0@jugs.org> <5A835DB2.7020808@oracle.com> Message-ID: That is good news and will probably make a lot of things easier. Michael Am 13.02.18 um 22:50 schrieb Kevin Rushforth: > >> There is a big difference because you just don't have to bundle all >> these >> other things with the JDK because you can add them later if you need >> them. >> This is different from the OpenJDK-OpenJFX combo which has to be built >> and distributed together for technical reasons. > > We are working to eliminate this dependency, to make it easier for > OpenJFX to be used with OpenJDK builds that don't already contain > javafx.* modules. > > -- Kevin > > > > Michael Paus wrote: >> Am 09.02.18 um 15:22 schrieb Mario Torre: >>> On Fri, Feb 9, 2018 at 3:07 PM, Michael Paus wrote: >>>> Am 09.02.18 um 14:49 schrieb Mario Torre: >>>>> On Fri, Feb 9, 2018 at 2:29 PM, Mark Raynsford >>>>> wrote: >>>>> >>>>>> I suppose what I'm really saying is: When (if ever) can I expect >>>>>> JavaFX >>>>>> to be present unconditionally with OpenJDK installs? I probably >>>>>> can't >>>>>> migrate to JavaFX until that day... >>>>> JavaFX is not part of the Java specifications for the JDK or its >>>>> runtime, so the presence of the library in any distribution of >>>>> OpenJDK >>>>> pretty much depends on the vendor distributing you the binaries. >>>>> >>>>> There are some Linux distribution that started packaging a subset of >>>>> OpenJFX (in most cases few notable missing bits are the audio codecs >>>>> and the webview). I don't know if the same libraries will be bundled >>>>> with the GPL binary from Oracle, that's probably a question somebody >>>>> from Oracle may answer. >>>>> >>>>> The only way I can see JavaFX becoming included by default everywhere >>>>> is if it becomes part of the spec. >>>> In practice this is really a pain point and very bad advertising >>>> for JavaFX. >>>> Who defines that everything Open... can only contain what is >>>> included in >>>> "the spec"? >>>> Who keeps us from creating a product OpenJDKFX which we define to >>>> contain >>>> OpenJDK + OpenJFX. I'd like to see a complete and open version of >>>> Java but >>>> at the moment everybody seems to restrict themselves to only OpenJDK. >>>> Even Oracle at their EA download page deliver the open version of >>>> the JDK >>>> without JavaFX which I simply don't understand and which makes this >>>> version >>>> of the JDK completely useless to me. >>> You already have a complete, compliant and open version of Java. The >>> Java spec and the TCK define what is and what is not Java, and it >>> doesn't cover JavaFX. >>> >>> JavaFX can be included by downstream vendors, but that's entirely up >>> to them, in that regard is not different than bundling Tomcat or maven >>> with your JDK. >> There is a big difference because you just don't have to bundle all >> these >> other things with the JDK because you can add them later if you need >> them. >> This is different from the OpenJDK-OpenJFX combo which has to be built >> and distributed together for technical reasons. >> >> From mp at jugs.org Tue Feb 13 22:36:43 2018 From: mp at jugs.org (Michael Paus) Date: Tue, 13 Feb 2018 23:36:43 +0100 Subject: Packaging DMG with Ant fails on OS-X 10.13.3 In-Reply-To: <5A835B71.6010701@oracle.com> References: <2df9369f-916c-fc6e-e235-ef93a8a4d200@bestsolution.at> <5A835B71.6010701@oracle.com> Message-ID: The bug you mentioned is indeed fixed in JDK 10 but since I upgraded my Mac to Hight Sierra there seems to be a new one. I always get something like: Exec failed with code 2 command [[/usr/bin/SetFile, -c, icnC, /var/folders/0q/r4k4hbd13_s0p0thlz2hs8b80000gn/T/fxbundler10792917345996316721/images/myApp/.VolumeIcon.icns] in unspecified directory My Mac now uses APFS and I wonder whether SetFile can cope with that. According to the docs it has long been deprecated and should not be used anymore anyway. The build as a whole succeeds though. It just cannot handle the volume icon although it exists and has always worked before. Michael Am 13.02.18 um 22:41 schrieb Kevin Rushforth: > Have you tried with JDK 10 yet? The bug you reference is fixed in 10. > > -- Kevin > > > Steve Hannah wrote: >> I ran into this bug a couple months ago with javafx packager on High >> Sierra. >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190758 >> >> The problem is basically that hdiutil changed its default file system to >> APFS, which breaks many things.?? Ultimately I wasn't able to get javafx >> packager to work even with the workarounds listed on that bug so just >> generated the DMG using a 3rd party script ( >> https://github.com/andreyvit/create-dmg) to work around it. >> >> Steve >> >> On Tue, Feb 13, 2018 at 12:05 PM, Tom Schindl >> >> wrote: >> >>> Hi, >>> >>> It looks like the packaging of JavaFX-DMGs is broken on the latest OS-X >>> System. Has anyone ancountered the same? >>> >>> Tom >>> >> >> >> From victor.drozdov at oracle.com Wed Feb 14 01:06:10 2018 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Tue, 13 Feb 2018 17:06:10 -0800 Subject: Packaging DMG with Ant fails on OS-X 10.13.3 In-Reply-To: References: <2df9369f-916c-fc6e-e235-ef93a8a4d200@bestsolution.at> <5A835B71.6010701@oracle.com> Message-ID: <44cbbc92-a660-f7f1-3a08-3c493af8d6d6@oracle.com> Hi, Michael. Could you provide more details about your system and steps to reproduce the problem(at least, a command line)? We will investigate this issue about SetFile failure. --Victor On 2/13/18 2:36 PM, Michael Paus wrote: > The bug you mentioned is indeed fixed in JDK 10 but since I upgraded my > Mac to Hight Sierra there seems to be a new one. I always get something > like: > > Exec failed with code 2 command [[/usr/bin/SetFile, -c, icnC, > /var/folders/0q/r4k4hbd13_s0p0thlz2hs8b80000gn/T/fxbundler10792917345996316721/images/myApp/.VolumeIcon.icns] > in unspecified directory > > My Mac now uses APFS and I wonder whether SetFile can cope with that. > According to the docs it has long been deprecated and should not be used > anymore anyway. The build as a whole succeeds though. It just cannot > handle the volume icon although it exists and has always worked before. > > Michael > > Am 13.02.18 um 22:41 schrieb Kevin Rushforth: >> Have you tried with JDK 10 yet? The bug you reference is fixed in 10. >> >> -- Kevin >> >> >> Steve Hannah wrote: >>> I ran into this bug a couple months ago with javafx packager on High >>> Sierra. >>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190758 >>> >>> The problem is basically that hdiutil changed its default file >>> system to >>> APFS, which breaks many things. Ultimately I wasn't able to get >>> javafx >>> packager to work even with the workarounds listed on that bug so just >>> generated the DMG using a 3rd party script ( >>> https://github.com/andreyvit/create-dmg) to work around it. >>> >>> Steve >>> >>> On Tue, Feb 13, 2018 at 12:05 PM, Tom Schindl >>> >>> wrote: >>> >>>> Hi, >>>> >>>> It looks like the packaging of JavaFX-DMGs is broken on the latest >>>> OS-X >>>> System. Has anyone ancountered the same? >>>> >>>> Tom >>>> >>> >>> >>> > From ajit.ghaisas at oracle.com Wed Feb 14 07:11:51 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 13 Feb 2018 23:11:51 -0800 (PST) Subject: [11] Review request : JDK-8195806 : Eliminate dependency on sun.font.lookup in javafx.graphics Message-ID: <86c4c19f-93cc-4804-a94d-430443c9d3fa@default> Hi Kevin, Phil, Request you to review following fix : Issue : https://bugs.openjdk.java.net/browse/JDK-8195806 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195806/webrev.0/ Regards, Ajit From philip.race at oracle.com Wed Feb 14 07:21:32 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 13 Feb 2018 23:21:32 -0800 Subject: [11] Review request : JDK-8195806 : Eliminate dependency on sun.font.lookup in javafx.graphics In-Reply-To: <86c4c19f-93cc-4804-a94d-430443c9d3fa@default> References: <86c4c19f-93cc-4804-a94d-430443c9d3fa@default> Message-ID: <5A83E37C.50600@oracle.com> Well that removes the dependency but how are you fixing the problem of how else to find the font ? There needs to be alternate code or you need to go back to see what would happen if some code tried to locate that font and how it would fail. -phil. On 2/13/18, 11:11 PM, Ajit Ghaisas wrote: > Hi Kevin, Phil, > > Request you to review following fix : > > Issue : https://bugs.openjdk.java.net/browse/JDK-8195806 > > Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195806/webrev.0/ > > Regards, > Ajit From mp at jugs.org Wed Feb 14 07:45:17 2018 From: mp at jugs.org (Michael Paus) Date: Wed, 14 Feb 2018 08:45:17 +0100 Subject: Packaging DMG with Ant fails on OS-X 10.13.3 In-Reply-To: <44cbbc92-a660-f7f1-3a08-3c493af8d6d6@oracle.com> References: <2df9369f-916c-fc6e-e235-ef93a8a4d200@bestsolution.at> <5A835B71.6010701@oracle.com> <44cbbc92-a660-f7f1-3a08-3c493af8d6d6@oracle.com> Message-ID: <2542a5b4-4229-d550-f14f-1409596cbc4d@jugs.org> Hi, I can reproduce this error with the example already given in https://bugs.openjdk.java.net/browse/JDK-8188763 But as I said, it does not break the build completely. Michael Am 14.02.18 um 02:06 schrieb victor.drozdov at oracle.com: > Hi, Michael. > > Could you provide more details about your system and steps to > reproduce the problem(at least, a command line)? We will investigate > this issue about SetFile failure. > > --Victor > > On 2/13/18 2:36 PM, Michael Paus wrote: >> The bug you mentioned is indeed fixed in JDK 10 but since I upgraded my >> Mac to Hight Sierra there seems to be a new one. I always get something >> like: >> >> Exec failed with code 2 command [[/usr/bin/SetFile, -c, icnC, >> /var/folders/0q/r4k4hbd13_s0p0thlz2hs8b80000gn/T/fxbundler10792917345996316721/images/myApp/.VolumeIcon.icns] >> in unspecified directory >> >> My Mac now uses APFS and I wonder whether SetFile can cope with that. >> According to the docs it has long been deprecated and should not be used >> anymore anyway. The build as a whole succeeds though. It just cannot >> handle the volume icon although it exists and has always worked before. >> >> Michael >> >> Am 13.02.18 um 22:41 schrieb Kevin Rushforth: >>> Have you tried with JDK 10 yet? The bug you reference is fixed in 10. >>> >>> -- Kevin >>> >>> >>> Steve Hannah wrote: >>>> I ran into this bug a couple months ago with javafx packager on >>>> High Sierra. >>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190758 >>>> >>>> The problem is basically that hdiutil changed its default file >>>> system to >>>> APFS, which breaks many things.?? Ultimately I wasn't able to get >>>> javafx >>>> packager to work even with the workarounds listed on that bug so just >>>> generated the DMG using a 3rd party script ( >>>> https://github.com/andreyvit/create-dmg) to work around it. >>>> >>>> Steve >>>> >>>> On Tue, Feb 13, 2018 at 12:05 PM, Tom Schindl >>>> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> It looks like the packaging of JavaFX-DMGs is broken on the latest >>>>> OS-X >>>>> System. Has anyone ancountered the same? >>>>> >>>>> Tom >>>>> >>>> >>>> >>>> >> > From tom.schindl at bestsolution.at Wed Feb 14 08:41:40 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 14 Feb 2018 09:41:40 +0100 Subject: Packaging DMG with Ant fails on OS-X 10.13.3 In-Reply-To: <2542a5b4-4229-d550-f14f-1409596cbc4d@jugs.org> References: <2df9369f-916c-fc6e-e235-ef93a8a4d200@bestsolution.at> <5A835B71.6010701@oracle.com> <44cbbc92-a660-f7f1-3a08-3c493af8d6d6@oracle.com> <2542a5b4-4229-d550-f14f-1409596cbc4d@jugs.org> Message-ID: <6e8b6790-cc50-0550-55fa-cea413e9bfb2@bestsolution.at> Hi, I'm on 162 and the process and I have an old machine without the latest OS-X version and running the build there works. Running the completely same bits on the latest and greatest OS-X and the same Java version on my main work machine it fails with exactly the line given by Michael. Tom On 14.02.18 08:45, Michael Paus wrote: > Hi, > I can reproduce this error with the example already given in > https://bugs.openjdk.java.net/browse/JDK-8188763 > But as I said, it does not break the build completely. > Michael > > Am 14.02.18 um 02:06 schrieb victor.drozdov at oracle.com: >> Hi, Michael. >> >> Could you provide more details about your system and steps to >> reproduce the problem(at least, a command line)? We will investigate >> this issue about SetFile failure. >> >> --Victor >> >> On 2/13/18 2:36 PM, Michael Paus wrote: >>> The bug you mentioned is indeed fixed in JDK 10 but since I upgraded my >>> Mac to Hight Sierra there seems to be a new one. I always get something >>> like: >>> >>> Exec failed with code 2 command [[/usr/bin/SetFile, -c, icnC, >>> /var/folders/0q/r4k4hbd13_s0p0thlz2hs8b80000gn/T/fxbundler10792917345996316721/images/myApp/.VolumeIcon.icns] >>> in unspecified directory >>> >>> My Mac now uses APFS and I wonder whether SetFile can cope with that. >>> According to the docs it has long been deprecated and should not be used >>> anymore anyway. The build as a whole succeeds though. It just cannot >>> handle the volume icon although it exists and has always worked before. >>> >>> Michael >>> >>> Am 13.02.18 um 22:41 schrieb Kevin Rushforth: >>>> Have you tried with JDK 10 yet? The bug you reference is fixed in 10. >>>> >>>> -- Kevin >>>> >>>> >>>> Steve Hannah wrote: >>>>> I ran into this bug a couple months ago with javafx packager on >>>>> High Sierra. >>>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190758 >>>>> >>>>> The problem is basically that hdiutil changed its default file >>>>> system to >>>>> APFS, which breaks many things.?? Ultimately I wasn't able to get >>>>> javafx >>>>> packager to work even with the workarounds listed on that bug so just >>>>> generated the DMG using a 3rd party script ( >>>>> https://github.com/andreyvit/create-dmg) to work around it. >>>>> >>>>> Steve >>>>> >>>>> On Tue, Feb 13, 2018 at 12:05 PM, Tom Schindl >>>>> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> It looks like the packaging of JavaFX-DMGs is broken on the latest >>>>>> OS-X >>>>>> System. Has anyone ancountered the same? >>>>>> >>>>>> Tom >>>>>> >>>>> >>>>> >>>>> >>> >> > From johan.vos at gluonhq.com Wed Feb 14 15:14:01 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 14 Feb 2018 15:14:01 +0000 Subject: Repositories, AdoptOpenJDK and github Message-ID: Hi, I did 2 things: * I talked to the fine and great people at AdoptOpenJDK ( https://adoptopenjdk.net/) and they are happy to have their build farm being used to create OpenJFX modules (including the native libraries). We are currently looking at the scripts that are being used for syncing and building OpenJDK, and the sync script is already in place. * While on the subject of syncing, I used a similar script to create and sync a mirror of OpenJFX at github. It is now available at https://github.com//javafxports/openjdk-jfx (planning to sync at least a few times a day, by pulling in the latest changes from OpenJFX). This is a sandbox repository, and it won't be used to automatically generate builds from. If you want to play with the source, add features, fix bugs, work on documentation, you can fork this repository. If you want to contribute, you can create PR's. The idea is that OpenJFX committers can merge PR's in this repository. That doesn't automatically upstream them to OpenJFX, but if an OpenJFX committer agrees with your PR, he can use the existing webrev system at OpenJFX to start the process of merging it into OpenJFX. Since a PR might be used to merge code in OpenJFX, it is required that you have an OCA (see http://www.oracle.com/technetwork/community/oca-486395.html for more info). In summary, the flow might look like this: 1. Developer forks the github repo, enhances it, and creates a PR. 2. He discusses it with a committer, and eventually the PR is accepted. 3. The committer creates a webrev and an OpenJFX Reviewer reviews. 4. If accepted, that code is merged into OpenJFX. 5. The AdoptOpenJFX build farm creates a build including that new code. Note that this creates additional work for the current OpenJFX committers (including myself). Please be patient and helpful if you raise a PR. I expect PR's to be well tested and documented. A PR is not just an idea with some code being thrown over the wall. JavaFX has been Open Source for a very long time. By having the code also as a github mirror, I hope we can attract more people, and get more attention to this great project, while preserving the high quality that is really needed to keep JavaFX aligned with the high standards that people expect from the Java platform. Thanks, - Johan From kevin.rushforth at oracle.com Wed Feb 14 17:01:56 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Feb 2018 09:01:56 -0800 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: Message-ID: <5A846B84.8050103@oracle.com> Nice! Thanks for your hard work on this, Johan. -- Kevin Johan Vos wrote: > Hi, > > I did 2 things: > * I talked to the fine and great people at AdoptOpenJDK ( > https://adoptopenjdk.net/) and they are happy to have their build farm > being used to create OpenJFX modules (including the native libraries). We > are currently looking at the scripts that are being used for syncing and > building OpenJDK, and the sync script is already in place. > > * While on the subject of syncing, I used a similar script to create and > sync a mirror of OpenJFX at github. It is now available at > https://github.com//javafxports/openjdk-jfx > (planning to sync at least a few times a day, by pulling in the latest > changes from OpenJFX). > > This is a sandbox repository, and it won't be used to automatically > generate builds from. > If you want to play with the source, add features, fix bugs, work on > documentation, you can fork this repository. If you want to contribute, you > can create PR's. The idea is that OpenJFX committers can merge PR's in this > repository. That doesn't automatically upstream them to OpenJFX, but if an > OpenJFX committer agrees with your PR, he can use the existing webrev > system at OpenJFX to start the process of merging it into OpenJFX. > Since a PR might be used to merge code in OpenJFX, it is required that you > have an OCA (see > http://www.oracle.com/technetwork/community/oca-486395.html for > more info). > > In summary, the flow might look like this: > 1. Developer forks the github repo, enhances it, and creates a PR. > 2. He discusses it with a committer, and eventually the PR is accepted. > 3. The committer creates a webrev and an OpenJFX Reviewer reviews. > 4. If accepted, that code is merged into OpenJFX. > 5. The AdoptOpenJFX build farm creates a build including that new code. > > Note that this creates additional work for the current OpenJFX committers > (including myself). Please be patient and helpful if you raise a PR. I > expect PR's to be well tested and documented. A PR is not just an idea with > some code being thrown over the wall. > > JavaFX has been Open Source for a very long time. By having the code also > as a github mirror, I hope we can attract more people, and get more > attention to this great project, while preserving the high quality that is > really needed to keep JavaFX aligned with the high standards that people > expect from the Java platform. > > Thanks, > > - Johan > From nlisker at gmail.com Wed Feb 14 19:54:21 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 14 Feb 2018 21:54:21 +0200 Subject: Additional info on JDK-8197536: TableView, ListView: unexpected scrolling behaviour on up/down keys Message-ID: I tested the issue. It is not present in 1.8.0_152-b16, but it is present in 9+181 and 10-ea+37. - Nir From han.solo at icloud.com Wed Feb 14 15:18:32 2018 From: han.solo at icloud.com (han.solo at icloud.com) Date: Wed, 14 Feb 2018 16:18:32 +0100 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: Message-ID: Johan, Thank?s so much for all the effort you?ve put into OpenJFX...it is highly appreciated ???? Keep up the great work, Cheers, Gerrit Gerrit Grunwald Westfalenstr. 93 48165 M?nster Germany tel: +49 (0)2501 24321 mob: +49 (0)171 1745350 web: http://www.harmonic-code.org Am 14. Feb. 2018, 16:14 +0100 schrieb Johan Vos : > Hi, > > I did 2 things: > * I talked to the fine and great people at AdoptOpenJDK ( > https://adoptopenjdk.net/) and they are happy to have their build farm > being used to create OpenJFX modules (including the native libraries). We > are currently looking at the scripts that are being used for syncing and > building OpenJDK, and the sync script is already in place. > > * While on the subject of syncing, I used a similar script to create and > sync a mirror of OpenJFX at github. It is now available at > https://github.com//javafxports/openjdk-jfx > (planning to sync at least a few times a day, by pulling in the latest > changes from OpenJFX). > > This is a sandbox repository, and it won't be used to automatically > generate builds from. > If you want to play with the source, add features, fix bugs, work on > documentation, you can fork this repository. If you want to contribute, you > can create PR's. The idea is that OpenJFX committers can merge PR's in this > repository. That doesn't automatically upstream them to OpenJFX, but if an > OpenJFX committer agrees with your PR, he can use the existing webrev > system at OpenJFX to start the process of merging it into OpenJFX. > Since a PR might be used to merge code in OpenJFX, it is required that you > have an OCA (see > http://www.oracle.com/technetwork/community/oca-486395.html for > more info). > > In summary, the flow might look like this: > 1. Developer forks the github repo, enhances it, and creates a PR. > 2. He discusses it with a committer, and eventually the PR is accepted. > 3. The committer creates a webrev and an OpenJFX Reviewer reviews. > 4. If accepted, that code is merged into OpenJFX. > 5. The AdoptOpenJFX build farm creates a build including that new code. > > Note that this creates additional work for the current OpenJFX committers > (including myself). Please be patient and helpful if you raise a PR. I > expect PR's to be well tested and documented. A PR is not just an idea with > some code being thrown over the wall. > > JavaFX has been Open Source for a very long time. By having the code also > as a github mirror, I hope we can attract more people, and get more > attention to this great project, while preserving the high quality that is > really needed to keep JavaFX aligned with the high standards that people > expect from the Java platform. > > Thanks, > > - Johan From mike.ennen at gmail.com Wed Feb 14 20:21:24 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 14 Feb 2018 13:21:24 -0700 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: Message-ID: Thanks for taking the initiative, Johan. I have opened two PRs that add support for Travis CI and Appveyor continuous integration (which can be used to build pull requests and the master branch after a merge (or using a cron-timer) automatically). This will allow sandboxers to test their code on all 3 major supported platforms: Linux, macOS, and Windows. Regards, Michael On Wed, Feb 14, 2018 at 8:14 AM, Johan Vos wrote: > Hi, > > I did 2 things: > * I talked to the fine and great people at AdoptOpenJDK ( > https://adoptopenjdk.net/) and they are happy to have their build farm > being used to create OpenJFX modules (including the native libraries). We > are currently looking at the scripts that are being used for syncing and > building OpenJDK, and the sync script is already in place. > > * While on the subject of syncing, I used a similar script to create and > sync a mirror of OpenJFX at github. It is now available at > https://github.com//javafxports/openjdk-jfx > (planning to sync at least a few times a day, by pulling in the latest > changes from OpenJFX). > > This is a sandbox repository, and it won't be used to automatically > generate builds from. > If you want to play with the source, add features, fix bugs, work on > documentation, you can fork this repository. If you want to contribute, you > can create PR's. The idea is that OpenJFX committers can merge PR's in this > repository. That doesn't automatically upstream them to OpenJFX, but if an > OpenJFX committer agrees with your PR, he can use the existing webrev > system at OpenJFX to start the process of merging it into OpenJFX. > Since a PR might be used to merge code in OpenJFX, it is required that you > have an OCA (see > http://www.oracle.com/technetwork/community/oca-486395.html for > more info). > > In summary, the flow might look like this: > 1. Developer forks the github repo, enhances it, and creates a PR. > 2. He discusses it with a committer, and eventually the PR is accepted. > 3. The committer creates a webrev and an OpenJFX Reviewer reviews. > 4. If accepted, that code is merged into OpenJFX. > 5. The AdoptOpenJFX build farm creates a build including that new code. > > Note that this creates additional work for the current OpenJFX committers > (including myself). Please be patient and helpful if you raise a PR. I > expect PR's to be well tested and documented. A PR is not just an idea with > some code being thrown over the wall. > > JavaFX has been Open Source for a very long time. By having the code also > as a github mirror, I hope we can attract more people, and get more > attention to this great project, while preserving the high quality that is > really needed to keep JavaFX aligned with the high standards that people > expect from the Java platform. > > Thanks, > > - Johan > From johan.vos at gluonhq.com Wed Feb 14 20:38:59 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 14 Feb 2018 20:38:59 +0000 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: Message-ID: Hi Michael, That is great! Using Travis CI will clearly help keeping the project in a good shape. I added a comment, and I hope others with more experience with Travis than me will jump in. Thanks, - Johan On Wed, Feb 14, 2018 at 9:21 PM Michael Ennen wrote: > Thanks for taking the initiative, Johan. > > I have opened two PRs that add support for Travis CI and Appveyor > continuous integration (which can be used to build pull requests and > the master branch after a merge (or using a cron-timer) automatically). > > This will allow sandboxers to test their code on all 3 major supported > platforms: Linux, macOS, and Windows. > > Regards, > Michael > > On Wed, Feb 14, 2018 at 8:14 AM, Johan Vos wrote: > >> Hi, >> >> I did 2 things: >> * I talked to the fine and great people at AdoptOpenJDK ( >> https://adoptopenjdk.net/) and they are happy to have their build farm >> being used to create OpenJFX modules (including the native libraries). We >> are currently looking at the scripts that are being used for syncing and >> building OpenJDK, and the sync script is already in place. >> >> * While on the subject of syncing, I used a similar script to create and >> sync a mirror of OpenJFX at github. It is now available at >> https://github.com//javafxports/openjdk-jfx >> (planning to sync at least a few times a day, by pulling in the latest >> changes from OpenJFX). >> >> This is a sandbox repository, and it won't be used to automatically >> generate builds from. >> If you want to play with the source, add features, fix bugs, work on >> documentation, you can fork this repository. If you want to contribute, >> you >> can create PR's. The idea is that OpenJFX committers can merge PR's in >> this >> repository. That doesn't automatically upstream them to OpenJFX, but if an >> OpenJFX committer agrees with your PR, he can use the existing webrev >> system at OpenJFX to start the process of merging it into OpenJFX. >> Since a PR might be used to merge code in OpenJFX, it is required that you >> have an OCA (see >> http://www.oracle.com/technetwork/community/oca-486395.html for >> more info). >> >> In summary, the flow might look like this: >> 1. Developer forks the github repo, enhances it, and creates a PR. >> 2. He discusses it with a committer, and eventually the PR is accepted. >> 3. The committer creates a webrev and an OpenJFX Reviewer reviews. >> 4. If accepted, that code is merged into OpenJFX. >> 5. The AdoptOpenJFX build farm creates a build including that new code. >> >> Note that this creates additional work for the current OpenJFX committers >> (including myself). Please be patient and helpful if you raise a PR. I >> expect PR's to be well tested and documented. A PR is not just an idea >> with >> some code being thrown over the wall. >> >> JavaFX has been Open Source for a very long time. By having the code also >> as a github mirror, I hope we can attract more people, and get more >> attention to this great project, while preserving the high quality that is >> really needed to keep JavaFX aligned with the high standards that people >> expect from the Java platform. >> >> Thanks, >> >> - Johan >> > > From nlisker at gmail.com Wed Feb 14 22:25:43 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 15 Feb 2018 00:25:43 +0200 Subject: Repositories, AdoptOpenJDK and github Message-ID: Thank you! My concerns (not complaints) and questions: 1. Developer forks the github repo, enhances it, and creates a PR. 2. He discusses it with a committer, and eventually the PR is accepted. As I said before, we need to be careful where the discussion is made. PRs on GitHub have their own thread and there's also the mailing list. Maybe someone from Oracle already has done work related to the PR, and this will only be known if a JBS issue is submitted or a mailing list thread is started. Isn't this supposed to happen before starting to work on a PR even (ideally)? If you want to contribute, you can create PR's. The idea is that OpenJFX > committers can merge PR's in this repository. Are these PRs linked/related in some way to JBS? Currently, one would submit a JIRA ticket, then work under that roof. Is that something the committer will do after the PR has been merged? How would you verify the identity of committers (or contributors for the purpose of OCA) for GitHub? If I become a committer, I wouldn't want someone to create an account with my name and ask you to give them committer rights. Generally, as a non-committer, is it intended that I'll be able to work through both Oracle's and GitHub's channels? For one issue I can submit a PR and have a committer handle the webrev in my name, and for another issue I can do it myself? - Nir From mike.ennen at gmail.com Wed Feb 14 22:31:27 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 14 Feb 2018 15:31:27 -0700 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: Message-ID: Having a bot that creates a webrev, verifies OCA is signed for the commit author, and a generates a JBS/java bug report template would be ideal IMO. We can use something like AWS Lambda that runs every X minutes and checks for PRs to the openjdk-jfx GitHub repository. If a new PR is seen, or a PR is updated, the webrev, OCA confirmation, and bug report template are auto-generated and the bot can, for example, post a comment on the PR or we could use the github PR status check feature. Just some ideas. - Michael On Wed, Feb 14, 2018 at 3:25 PM, Nir Lisker wrote: > Thank you! > > My concerns (not complaints) and questions: > > 1. Developer forks the github repo, enhances it, and creates a PR. > > 2. He discusses it with a committer, and eventually the PR is accepted. > > > As I said before, we need to be careful where the discussion is made. PRs > on GitHub have their own thread and there's also the mailing list. Maybe > someone from Oracle already has done work related to the PR, and this will > only be known if a JBS issue is submitted or a mailing list thread is > started. Isn't this supposed to happen before starting to work on a PR even > (ideally)? > > If you want to contribute, you can create PR's. The idea is that OpenJFX > > committers can merge PR's in this repository. > > > Are these PRs linked/related in some way to JBS? Currently, one would > submit a JIRA ticket, then work under that roof. Is that something the > committer will do after the PR has been merged? > > How would you verify the identity of committers (or contributors for the > purpose of OCA) for GitHub? If I become a committer, I wouldn't want > someone to create an account with my name and ask you to give them > committer rights. > > Generally, as a non-committer, is it intended that I'll be able to work > through both Oracle's and GitHub's channels? For one issue I can submit a > PR and have a committer handle the webrev in my name, and for another issue > I can do it myself? > > - Nir > From kevin.rushforth at oracle.com Wed Feb 14 23:03:18 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Feb 2018 15:03:18 -0800 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: Message-ID: <5A84C036.1040807@oracle.com> As far as the bug goes, I think it would be better to do it the other way around. If we adopt a policy that a PR should reference a bug in JBS, then that part of the problem will go away. I'm not convinced that merging a random PR, for what is essentially just "a good idea" if it isn't backed by a JBS bug, is all that useful. IBy having a bug in JBS before generating the PR, we are that much farther along towards getting it integrated. -- Kevin Michael Ennen wrote: > Having a bot that creates a webrev, verifies OCA is signed for the commit > author, > and a generates a JBS/java bug report template would be ideal IMO. > > We can use something like AWS Lambda that runs every X minutes and checks > for PRs to the openjdk-jfx GitHub repository. If a new PR is seen, or a PR > is updated, > the webrev, OCA confirmation, and bug report template are auto-generated > and the > bot can, for example, post a comment on the PR or we could use the github PR > status check feature. > > Just some ideas. > > - Michael > > On Wed, Feb 14, 2018 at 3:25 PM, Nir Lisker wrote: > > >> Thank you! >> >> My concerns (not complaints) and questions: >> >> 1. Developer forks the github repo, enhances it, and creates a PR. >> >> 2. He discusses it with a committer, and eventually the PR is accepted. >> >> >> As I said before, we need to be careful where the discussion is made. PRs >> on GitHub have their own thread and there's also the mailing list. Maybe >> someone from Oracle already has done work related to the PR, and this will >> only be known if a JBS issue is submitted or a mailing list thread is >> started. Isn't this supposed to happen before starting to work on a PR even >> (ideally)? >> >> If you want to contribute, you can create PR's. The idea is that OpenJFX >> >>> committers can merge PR's in this repository. >>> >> Are these PRs linked/related in some way to JBS? Currently, one would >> submit a JIRA ticket, then work under that roof. Is that something the >> committer will do after the PR has been merged? >> >> How would you verify the identity of committers (or contributors for the >> purpose of OCA) for GitHub? If I become a committer, I wouldn't want >> someone to create an account with my name and ask you to give them >> committer rights. >> >> Generally, as a non-committer, is it intended that I'll be able to work >> through both Oracle's and GitHub's channels? For one issue I can submit a >> PR and have a committer handle the webrev in my name, and for another issue >> I can do it myself? >> >> - Nir >> >> From kevin.rushforth at oracle.com Thu Feb 15 03:09:15 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Feb 2018 19:09:15 -0800 Subject: Additional info on JDK-8197536: TableView, ListView: unexpected scrolling behaviour on up/down keys In-Reply-To: References: Message-ID: <5A84F9DB.2090002@oracle.com> Thanks for the info. I update the bug report with this information, and marked it as a regression (introduced in 9). -- Kevin Nir Lisker wrote: > I tested the issue. It is not present in 1.8.0_152-b16, but it is present > in 9+181 and 10-ea+37. > > - Nir > From kevin.rushforth at oracle.com Thu Feb 15 03:04:18 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Feb 2018 19:04:18 -0800 Subject: Updating class javafx.beans.binding.When In-Reply-To: References: Message-ID: <5A84F8B2.3040703@oracle.com> Sorry for the delay in responding. I was traveling when this was sent and barely able to keep up with urgent email / tasks. Most of what you suggest below seems good. My only concern is whether the "on demand" evaluation will have any side effects. Conceptually, it seems like the right thing to do. The refactoring you propose is probably best done as a separate bug fix, so that we don't mix behavioral changes with refactoring, unless you think that the refactoring is intertwined with the fix. If you would like to work on a fix, that would be good. It will need to include new unit tests, plus ensuring that the existing unit tests pass. Thanks. -- Kevin Nir Lisker wrote: > Hi, > > I was looking at https://bugs.openjdk.java.net/browse/JDK-8089579, which > prompted me to have a look at When. There are a few points I would like to > address: > > * StringConditionBuilder#otherwise(ObservableStringValue) does not check > for null as other condition builders do. This results in a deeper NPE > when StringCondition tries to register a listener to the > ObservableStringValue. > > * I would like a (re)evaluation on the above bug ticket and thoughts on the > proposal of "on demand evaluation" using a Supplier or a similar method. > The behavior of the intended implementation would be to evaluate 'then' and > 'otherwise' whenever their condition is met, and only then. > > * The class can benefit from some small refactoring, such as using > Objects.requireNonNull for null checks and some code reuse to reduce the > chance of bugs such as the missing null check of StringConditionBuilder. > > * There are a few Javadoc corrections and some clarifications of the > current behavior could be beneficial as well. > > I can work on all of the above. How to proceed? > > - Nir > From kevin.rushforth at oracle.com Thu Feb 15 03:06:43 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Feb 2018 19:06:43 -0800 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: Message-ID: <5A84F943.6030206@oracle.com> > As I said before, we need to be careful where the discussion is made. PRs > on GitHub have their own thread and there's also the mailing list. Maybe > someone from Oracle already has done work related to the PR, and this will > only be known if a JBS issue is submitted or a mailing list thread is > started. Isn't this supposed to happen before starting to work on a PR even > (ideally)? Yes, which is why I propose that we start with a JBS bug ID. A note to the list along the lines of "Hi, I'd like to work on JDK-123456" would be a good idea too, to avoid duplication of effort, and to indicate to other developers that the bug is now being looked at. -- Kevin Nir Lisker wrote: > Thank you! > > My concerns (not complaints) and questions: > > 1. Developer forks the github repo, enhances it, and creates a PR. > > 2. He discusses it with a committer, and eventually the PR is accepted. > > > As I said before, we need to be careful where the discussion is made. PRs > on GitHub have their own thread and there's also the mailing list. Maybe > someone from Oracle already has done work related to the PR, and this will > only be known if a JBS issue is submitted or a mailing list thread is > started. Isn't this supposed to happen before starting to work on a PR even > (ideally)? > > If you want to contribute, you can create PR's. The idea is that OpenJFX > >> committers can merge PR's in this repository. >> > > > Are these PRs linked/related in some way to JBS? Currently, one would > submit a JIRA ticket, then work under that roof. Is that something the > committer will do after the PR has been merged? > > How would you verify the identity of committers (or contributors for the > purpose of OCA) for GitHub? If I become a committer, I wouldn't want > someone to create an account with my name and ask you to give them > committer rights. > > Generally, as a non-committer, is it intended that I'll be able to work > through both Oracle's and GitHub's channels? For one issue I can submit a > PR and have a committer handle the webrev in my name, and for another issue > I can do it myself? > > - Nir > From ajit.ghaisas at oracle.com Thu Feb 15 05:39:52 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 14 Feb 2018 21:39:52 -0800 (PST) Subject: [11] Review request : JDK-8195806 : Eliminate dependency on sun.font.lookup in javafx.graphics In-Reply-To: <5A83E37C.50600@oracle.com> References: <86c4c19f-93cc-4804-a94d-430443c9d3fa@default> <5A83E37C.50600@oracle.com> Message-ID: <7297b300-5853-4698-8065-9250ec45953f@default> Hi Phil, Thanks for having a look at the changes. I have little difficulty in understanding your question. Are you referring to the sun.font.SunFontManager initialization? I am asking as it is not evident from the code changes that I have done as part of this webrev. Request your guidance in this regard. Regards, Ajit -----Original Message----- From: Philip Race Sent: Wednesday, February 14, 2018 12:52 PM To: Ajit Ghaisas Cc: Kevin Rushforth; openjfx-dev at openjdk.java.net Subject: Re: [11] Review request : JDK-8195806 : Eliminate dependency on sun.font.lookup in javafx.graphics Well that removes the dependency but how are you fixing the problem of how else to find the font ? There needs to be alternate code or you need to go back to see what would happen if some code tried to locate that font and how it would fail. -phil. On 2/13/18, 11:11 PM, Ajit Ghaisas wrote: > Hi Kevin, Phil, > > Request you to review following fix : > > Issue : https://bugs.openjdk.java.net/browse/JDK-8195806 > > Fix : > http://cr.openjdk.java.net/~aghaisas/fx/8195806/webrev.0/ > > Regards, > Ajit From johan.vos at gluonhq.com Thu Feb 15 08:20:27 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 15 Feb 2018 08:20:27 +0000 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: <5A84F943.6030206@oracle.com> References: <5A84F943.6030206@oracle.com> Message-ID: On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth wrote: > > As I said before, we need to be careful where the discussion is made. PRs > on GitHub have their own thread and there's also the mailing list. Maybe > someone from Oracle already has done work related to the PR, and this will > only be known if a JBS issue is submitted or a mailing list thread is > started. Isn't this supposed to happen before starting to work on a PR even > (ideally)? > > > Yes, which is why I propose that we start with a JBS bug ID. A note to the > list along the lines of "Hi, I'd like to work on JDK-123456" would be a > good idea too, to avoid duplication of effort, and to indicate to other > developers that the bug is now being looked at. > A global reference in JBS would indeed be very good to track back the work in a PR to a real issue. It can also be very useful as there are many existing issues in JBS that can be referred to in future work. The only issue I see is that in order to create an issue in JBS, you need to have "author" status, so not everyone can do this? Given the idea that developers who want to create a PR also need to sign an OCA, it might make sense to somehow combine the administration? - Johan From fastegal at swingempire.de Thu Feb 15 10:51:47 2018 From: fastegal at swingempire.de (fastegal at swingempire.de) Date: Thu, 15 Feb 2018 11:51:47 +0100 Subject: Additional info on JDK-8197536: TableView, ListView: unexpected scrolling behaviour on up/down keys In-Reply-To: References: Message-ID: <20180215115147.Horde.5NO1frj9znjeNPDqbzch9Q1@webmail.df.eu> Seems to have happened right at the start of moving VirtualFlow into public scope (which included lots changes to the implementation plus some refactoring, codereader's brain cells need to be kept alert ;) see my comment at https://bugs.openjdk.java.net/browse/JDK-8197536 Zitat von Nir Lisker : > I tested the issue. It is not present in 1.8.0_152-b16, but it is present > in 9+181 and 10-ea+37. > > - Nir From philip.race at oracle.com Thu Feb 15 17:14:25 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 15 Feb 2018 09:14:25 -0800 Subject: [11] Review request : JDK-8195806 : Eliminate dependency on sun.font.lookup in javafx.graphics In-Reply-To: <7297b300-5853-4698-8065-9250ec45953f@default> References: <86c4c19f-93cc-4804-a94d-430443c9d3fa@default> <5A83E37C.50600@oracle.com> <7297b300-5853-4698-8065-9250ec45953f@default> Message-ID: <80a7e3a3-2cae-81aa-f5a5-d282f6799ac5@oracle.com> This part is probably as good as you can do + return System.getProperty("java.home","") + File.separator + + "lib" + File.separator + "fonts"; but if we want to support running against OpenJDK which does not have Lucida Sans then we need to look at the caller of getJDKFontDir() So going forward all of this .. private static final String jreDefaultFont = "Lucida Sans Regular"; private static final String jreDefaultFontLC = "lucida sans regular"; private static final String jreDefaultFontFile = "LucidaSansRegular.ttf"; .. is probably pointless. And if we can't find it then the first layer of fall back code is a bit dubious // Normally use the JRE default font as the last fallback. // If we can't find even that, use any platform font; for (String font : fontToFileMap.keySet()) { String file = findFile(font); // gets full path fontResource = createFontResource(jreDefaultFontLC, file); if (fontResource != null) { break; } It did not really matter in the past .. it was just to prevent NPE in an unlikely scenario .. But if it is to be the first class way of finding this font it probably should be using "System" instead ? But then you need to make sure we don't have a circularity in the case that we are using this in initialiasing System. -phil. On 02/14/2018 09:39 PM, Ajit Ghaisas wrote: > Hi Phil, > > Thanks for having a look at the changes. > > I have little difficulty in understanding your question. > Are you referring to the sun.font.SunFontManager initialization? > I am asking as it is not evident from the code changes that I have done as part of this webrev. > > Request your guidance in this regard. > > Regards, > Ajit > > > -----Original Message----- > From: Philip Race > Sent: Wednesday, February 14, 2018 12:52 PM > To: Ajit Ghaisas > Cc: Kevin Rushforth; openjfx-dev at openjdk.java.net > Subject: Re: [11] Review request : JDK-8195806 : Eliminate dependency on sun.font.lookup in javafx.graphics > > Well that removes the dependency but how are you fixing the problem of how else to find the font ? > There needs to be alternate code or you need to go back to see what would happen if some code tried to locate that font and how it would fail. > > -phil. > > On 2/13/18, 11:11 PM, Ajit Ghaisas wrote: >> Hi Kevin, Phil, >> >> Request you to review following fix : >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8195806 >> >> Fix : >> http://cr.openjdk.java.net/~aghaisas/fx/8195806/webrev.0/ >> >> Regards, >> Ajit From rajath.kamath at oracle.com Thu Feb 15 18:52:53 2018 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Thu, 15 Feb 2018 10:52:53 -0800 (PST) Subject: [11] Review Request - JDK-8196802: 3D unit tests listed as pass although they are actually skipped Message-ID: <25856662-f573-4e21-8078-5fb696e3cf03@default> Hi Kevin, Murali, Please review this fix for skipping tests those are not run(because of missing feature support), instead of incorrectly listing as pass. JBS : https://bugs.openjdk.java.net/browse/JDK-8196802 WebRev : http://cr.openjdk.java.net/~rkamath/8196802/webrev.01/ Thanks, Rajath From kevin.rushforth at oracle.com Thu Feb 15 23:14:57 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 15 Feb 2018 15:14:57 -0800 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: <5A84F943.6030206@oracle.com> Message-ID: <5A861471.8030208@oracle.com> Johan Vos wrote: > > > On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth > > wrote: > > A global reference in JBS would indeed be very good to track back the > work in a PR to a real issue. It can also be very useful as there are > many existing issues in JBS that can be referred to in future work. > > The only issue I see is that in order to create an issue in JBS, you > need to have "author" status, so not everyone can do this? Given the > idea that developers who want to create a PR also need to sign an OCA, > it might make sense to somehow combine the administration? I don't think we can combine this, but I hope to be able to relax the requirements to become an Author a little. The current guidelines are 2 sponsored contributions [1]. Pending appointment as an Author, it isn't hard to submit a bug via http://bugreport.java.com/ . If there is a test case, it usually gets moved to the JDK project within a day or so (and I can move them sooner, if needed). The bigger bother is that you can't comment in JBS on a bug you didn't create, but once the bug is there, you can work on it in GutHub and/or send email to the list. I'll also add any comments from contributors who are not yet Authors to any bug report. -- Kevin [1] http://openjdk.java.net/projects/#project-author > - Johan From nlisker at gmail.com Fri Feb 16 14:06:58 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 16 Feb 2018 16:06:58 +0200 Subject: Updating class javafx.beans.binding.When In-Reply-To: <5A84F8B2.3040703@oracle.com> References: <5A84F8B2.3040703@oracle.com> Message-ID: Let's start with the refactoring then. Before I submit a bug let's check that this plan makes sense. Attached webrev for discussion. Changes: * Main change was to the XxxCondition classes. Instead of having 4 combinations of primitives and observables I used the unification approach that NumberConditionBuilder took with wrapping the value in a constant observable. I also replaced these classes with a generic wrappers XxxConditionHolders which hold the binding part of the XxxCondition class. * I attempted to generify XxxConditionBuilders as well. The attempt is ConditionBuilder and an example implementation was done for boolean only - BooleanConditionBuilder2. I think that it doesn't gain much. * Added BooleanConstant class in internal API (it was missing for some reason). * The handling of Numbers in the original class is a bit weird in my eyes. The compile time return types are DoubleBinding if one or both values are double and NumberBinding otherwise [1]. On the other hand, the runtime return types takes special care to return a binding class based on widening conventions and the docs don't mention anything about that. In my change, the runtime type is always DoubleBinding (though I kept a placeholder if-else chain) and that saves some code. The user can always call floatValue() etc. anyway. Between backwards compatibility and limitations of generics this is the best I could come up with. Additional notes: * Running the tests from gradle causes some of the When tests to fail and I don't know why, it's hard to debug. I wrote my own ad-hoc test for one of the failed tests and it passes. * I noticed that StringConstant extends StringExpression while all the other classes just implement their respective ObservableXxxValue. Don't know why, but I can align these classes to one of those choices. [1] https://docs.oracle.com/javase/9/docs/api/javafx/beans/binding/When.NumberConditionBuilder.html On Thu, Feb 15, 2018 at 5:04 AM, Kevin Rushforth wrote: > Sorry for the delay in responding. I was traveling when this was sent and > barely able to keep up with urgent email / tasks. > > Most of what you suggest below seems good. My only concern is whether the > "on demand" evaluation will have any side effects. Conceptually, it seems > like the right thing to do. > > The refactoring you propose is probably best done as a separate bug fix, > so that we don't mix behavioral changes with refactoring, unless you think > that the refactoring is intertwined with the fix. > > If you would like to work on a fix, that would be good. It will need to > include new unit tests, plus ensuring that the existing unit tests pass. > > Thanks. > > -- Kevin > > > > Nir Lisker wrote: > >> Hi, >> >> I was looking at https://bugs.openjdk.java.net/browse/JDK-8089579, which >> prompted me to have a look at When. There are a few points I would like to >> address: >> >> * StringConditionBuilder#otherwise(ObservableStringValue) does not check >> for null as other condition builders do. This results in a deeper NPE >> when StringCondition tries to register a listener to the >> ObservableStringValue. >> >> * I would like a (re)evaluation on the above bug ticket and thoughts on >> the >> proposal of "on demand evaluation" using a Supplier or a similar method. >> The behavior of the intended implementation would be to evaluate 'then' >> and >> 'otherwise' whenever their condition is met, and only then. >> >> * The class can benefit from some small refactoring, such as using >> Objects.requireNonNull for null checks and some code reuse to reduce the >> chance of bugs such as the missing null check of StringConditionBuilder. >> >> * There are a few Javadoc corrections and some clarifications of the >> current behavior could be beneficial as well. >> >> I can work on all of the above. How to proceed? >> >> - Nir >> >> > From kevin.rushforth at oracle.com Fri Feb 16 21:46:33 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 16 Feb 2018 13:46:33 -0800 Subject: Updating class javafx.beans.binding.When In-Reply-To: References: <5A84F8B2.3040703@oracle.com> Message-ID: <5A875139.8000901@oracle.com> This will take me a bit more time to look at than I have right now (and Monday is a US holiday), so one quick comment for now: The refactoring must not alter any public API signatures for exported packagers, and must be behavior neutral. So if there are unit tests that pass without your fix and fail with your fix, then you will need to alter your fix, unless you can show that the tests are testing an implementation detail that would not affect an application that just uses public API. -- Kevin Nir Lisker wrote: > Let's start with the refactoring then. Before I submit a bug let's > check that this plan makes sense. Attached webrev for discussion. > > Changes: > * Main change was to the XxxCondition classes. Instead of having 4 > combinations of primitives and observables I used the unification > approach that NumberConditionBuilder took with wrapping the value in a > constant observable. I also replaced these classes with a generic > wrappers XxxConditionHolders which hold the binding part of the > XxxCondition class. > > * I attempted to generify XxxConditionBuilders as well. The attempt is > ConditionBuilder and an example implementation was done for boolean > only - BooleanConditionBuilder2. I think that it doesn't gain much. > > * Added BooleanConstant class in internal API (it was missing for some > reason). > > * The handling of Numbers in the original class is a bit weird in my > eyes. The compile time return types are DoubleBinding if one or both > values are double and NumberBinding otherwise [1]. On the other hand, > the runtime return types takes special care to return a binding class > based on widening conventions and the docs don't mention anything > about that. In my change, the runtime type is always DoubleBinding > (though I kept a placeholder if-else chain) and that saves some code. > The user can always call floatValue() etc. anyway. > > Between backwards compatibility and limitations of generics this is > the best I could come up with. > > Additional notes: > > * Running the tests from gradle causes some of the When tests to fail > and I don't know why, it's hard to debug. I wrote my own ad-hoc test > for one of the failed tests and it passes. > > * I noticed that StringConstant extends StringExpression while all the > other classes just implement their respective ObservableXxxValue. > Don't know why, but I can align these classes to one of those choices. > > [1] https://docs.oracle.com/javase/9/docs/api/javafx/beans/binding/When.NumberConditionBuilder.html > > On Thu, Feb 15, 2018 at 5:04 AM, Kevin Rushforth > > wrote: > > Sorry for the delay in responding. I was traveling when this was > sent and barely able to keep up with urgent email / tasks. > > Most of what you suggest below seems good. My only concern is > whether the "on demand" evaluation will have any side effects. > Conceptually, it seems like the right thing to do. > > The refactoring you propose is probably best done as a separate > bug fix, so that we don't mix behavioral changes with refactoring, > unless you think that the refactoring is intertwined with the fix. > > If you would like to work on a fix, that would be good. It will > need to include new unit tests, plus ensuring that the existing > unit tests pass. > > Thanks. > > -- Kevin > > > > Nir Lisker wrote: > > Hi, > > I was looking at > https://bugs.openjdk.java.net/browse/JDK-8089579 > , which > prompted me to have a look at When. There are a few points I > would like to > address: > > * StringConditionBuilder#otherwise(ObservableStringValue) does > not check > for null as other condition builders do. This results in a > deeper NPE > when StringCondition tries to register a listener to the > ObservableStringValue. > > * I would like a (re)evaluation on the above bug ticket and > thoughts on the > proposal of "on demand evaluation" using a Supplier or a > similar method. > The behavior of the intended implementation would be to > evaluate 'then' and > 'otherwise' whenever their condition is met, and only then. > > * The class can benefit from some small refactoring, such as using > Objects.requireNonNull for null checks and some code reuse to > reduce the > chance of bugs such as the missing null check of > StringConditionBuilder. > > * There are a few Javadoc corrections and some clarifications > of the > current behavior could be beneficial as well. > > I can work on all of the above. How to proceed? > > - Nir > > > From alexander.matveev at oracle.com Fri Feb 16 23:09:23 2018 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 16 Feb 2018 15:09:23 -0800 Subject: [11] Review request for 8198316: MediaPlayer crashes when playing m3u8 files on macOS High Sierra 10.13.2 Message-ID: <207b6801-9a1c-e1b9-c944-408066f20f89@oracle.com> Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8198316 Fixed crash with HLS streams on OS X 10.13. Thanks, Alexander From arunprasad.rajkumar at oracle.com Sat Feb 17 01:34:00 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Sat, 17 Feb 2018 07:04:00 +0530 Subject: [11] Review request: 8146672: [Windows] Support cmake ninja build Message-ID: <7860EDB1-30FB-4DB4-B217-43BE2BF6519E@oracle.com> Hi, Please review the simple fix to enable ninja build generation from cmake on Windows. Linux and macOS builds are already supports ninja build. JBS: https://bugs.openjdk.java.net/browse/JDK-8146672 Webrev: http://cr.openjdk.java.net/~arajkumar/8146672/webrev Thanks, Arun From nlisker at gmail.com Tue Feb 20 10:45:56 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 20 Feb 2018 12:45:56 +0200 Subject: Updating class javafx.beans.binding.When In-Reply-To: <5A875139.8000901@oracle.com> References: <5A84F8B2.3040703@oracle.com> <5A875139.8000901@oracle.com> Message-ID: OK, let's wait with this until I figure out if there's a problem with the test suit. On Fri, Feb 16, 2018 at 11:46 PM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > This will take me a bit more time to look at than I have right now (and > Monday is a US holiday), so one quick comment for now: > > The refactoring must not alter any public API signatures for exported > packagers, and must be behavior neutral. So if there are unit tests that > pass without your fix and fail with your fix, then you will need to alter > your fix, unless you can show that the tests are testing an implementation > detail that would not affect an application that just uses public API. > > > -- Kevin > > > Nir Lisker wrote: > > Let's start with the refactoring then. Before I submit a bug let's check > that this plan makes sense. Attached webrev for discussion. > > Changes: > * Main change was to the XxxCondition classes. Instead of having 4 > combinations of primitives and observables I used the unification approach > that NumberConditionBuilder took with wrapping the value in a constant > observable. I also replaced these classes with a generic wrappers > XxxConditionHolders which hold the binding part of the XxxCondition class. > > * I attempted to generify XxxConditionBuilders as well. The attempt is > ConditionBuilder and an example implementation was done for boolean only - > BooleanConditionBuilder2. I think that it doesn't gain much. > > * Added BooleanConstant class in internal API (it was missing for some > reason). > > * The handling of Numbers in the original class is a bit weird in my eyes. > The compile time return types are DoubleBinding if one or both values are > double and NumberBinding otherwise [1]. On the other hand, the runtime > return types takes special care to return a binding class based on widening > conventions and the docs don't mention anything about that. In my change, > the runtime type is always DoubleBinding (though I kept a placeholder > if-else chain) and that saves some code. The user can always call > floatValue() etc. anyway. > > Between backwards compatibility and limitations of generics this is the > best I could come up with. > > Additional notes: > > * Running the tests from gradle causes some of the When tests to fail and > I don't know why, it's hard to debug. I wrote my own ad-hoc test for one of > the failed tests and it passes. > > * I noticed that StringConstant extends StringExpression while all the > other classes just implement their respective ObservableXxxValue. Don't > know why, but I can align these classes to one of those choices. > > [1] https://docs.oracle.com/javase/9/docs/api/javafx/beans/binding/When. > NumberConditionBuilder.html > > On Thu, Feb 15, 2018 at 5:04 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Sorry for the delay in responding. I was traveling when this was sent and >> barely able to keep up with urgent email / tasks. >> >> Most of what you suggest below seems good. My only concern is whether the >> "on demand" evaluation will have any side effects. Conceptually, it seems >> like the right thing to do. >> >> The refactoring you propose is probably best done as a separate bug fix, >> so that we don't mix behavioral changes with refactoring, unless you think >> that the refactoring is intertwined with the fix. >> >> If you would like to work on a fix, that would be good. It will need to >> include new unit tests, plus ensuring that the existing unit tests pass. >> >> Thanks. >> >> -- Kevin >> >> >> >> Nir Lisker wrote: >> >>> Hi, >>> >>> I was looking at https://bugs.openjdk.java.net/browse/JDK-8089579, which >>> prompted me to have a look at When. There are a few points I would like >>> to >>> address: >>> >>> * StringConditionBuilder#otherwise(ObservableStringValue) does not check >>> for null as other condition builders do. This results in a deeper NPE >>> when StringCondition tries to register a listener to the >>> ObservableStringValue. >>> >>> * I would like a (re)evaluation on the above bug ticket and thoughts on >>> the >>> proposal of "on demand evaluation" using a Supplier or a similar method. >>> The behavior of the intended implementation would be to evaluate 'then' >>> and >>> 'otherwise' whenever their condition is met, and only then. >>> >>> * The class can benefit from some small refactoring, such as using >>> Objects.requireNonNull for null checks and some code reuse to reduce the >>> chance of bugs such as the missing null check of StringConditionBuilder. >>> >>> * There are a few Javadoc corrections and some clarifications of the >>> current behavior could be beneficial as well. >>> >>> I can work on all of the above. How to proceed? >>> >>> - Nir >>> >>> >> > From herve.girod at gmail.com Wed Feb 21 10:22:44 2018 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Wed, 21 Feb 2018 11:22:44 +0100 Subject: Regression in 1.8.0_102 Message-ID: <82EC404E-7ACA-468B-A935-757058EA7091@gmail.com> Hello, We discovered a regression seemingly in how css properties are applied for fonts in some cases beginning with 1.8.0_102. It was OK with 1.8.0_92 and it is also KO in 9.04. The problem are some fonts which are not rendered when applying a css style. In our case the background is black and the text should be white (specified through css) but it?s black so not visible on the background. I will try to create a simple test case, but our application is big, so it?s not so simple. Regards, Herv? Sent from my iPhone From rajath.kamath at oracle.com Wed Feb 21 10:32:51 2018 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Wed, 21 Feb 2018 02:32:51 -0800 (PST) Subject: [11] Review Request - JDK-8170026: Some tests in RegionBackgroundFillUITest fail with fractional window scale Message-ID: Hi Kevin, Murali, Please review this fix for skipping specific tests when run on systems with fractional scale factor set. JBS : https://bugs.openjdk.java.net/browse/JDK-8170026 WebRev : http://cr.openjdk.java.net/~rkamath/8170026/webrev.00/ Thanks, Rajath From ajit.ghaisas at oracle.com Wed Feb 21 11:53:00 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 21 Feb 2018 03:53:00 -0800 (PST) Subject: Regression in 1.8.0_102 In-Reply-To: <043b0d75-2345-4b16-9ea7-3afafffea581@default> References: <82EC404E-7ACA-468B-A935-757058EA7091@gmail.com> <043b0d75-2345-4b16-9ea7-3afafffea581@default> Message-ID: Hi Herv?, Going solely by the problem description, it is most likely due to reported issue - https://bugs.openjdk.java.net/browse/JDK-8183100 It has been resolved in upcoming JDK 10 & also in upcoming 8u172 update. You can try out early access builds at - http://jdk.java.net/ - and see if you still see the issue. Regards, Ajit -----Original Message----- From: Herv? Girod [mailto:herve.girod at gmail.com] Sent: Wednesday, February 21, 2018 3:53 PM To: openjfx-dev at openjdk.java.net Subject: Regression in 1.8.0_102 Hello, We discovered a regression seemingly in how css properties are applied for fonts in some cases beginning with 1.8.0_102. It was OK with 1.8.0_92 and it is also KO in 9.04. The problem are some fonts which are not rendered when applying a css style. In our case the background is black and the text should be white (specified through css) but it?s black so not visible on the background. I will try to create a simple test case, but our application is big, so it?s not so simple. Regards, Herv? Sent from my iPhone From herve.girod at gmail.com Wed Feb 21 13:11:21 2018 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Wed, 21 Feb 2018 14:11:21 +0100 Subject: Regression in 1.8.0_102 In-Reply-To: References: <82EC404E-7ACA-468B-A935-757058EA7091@gmail.com> <043b0d75-2345-4b16-9ea7-3afafffea581@default> Message-ID: <1590E2F4-70DC-4549-8CCF-A22BAF8C975F@gmail.com> We will check with these new versions ASAP, thanks!! Sent from my iPhone > On Feb 21, 2018, at 12:53, Ajit Ghaisas wrote: > > Hi Herv?, > > Going solely by the problem description, it is most likely due to reported issue - https://bugs.openjdk.java.net/browse/JDK-8183100 > It has been resolved in upcoming JDK 10 & also in upcoming 8u172 update. > You can try out early access builds at - http://jdk.java.net/ - and see if you still see the issue. > > Regards, > Ajit > > > -----Original Message----- > From: Herv? Girod [mailto:herve.girod at gmail.com] > Sent: Wednesday, February 21, 2018 3:53 PM > To: openjfx-dev at openjdk.java.net > Subject: Regression in 1.8.0_102 > > Hello, > > We discovered a regression seemingly in how css properties are applied for fonts in some cases beginning with 1.8.0_102. It was OK with 1.8.0_92 and it is also KO in 9.04. > > The problem are some fonts which are not rendered when applying a css style. In our case the background is black and the text should be white (specified through css) but it?s black so not visible on the background. > > I will try to create a simple test case, but our application is big, so it?s not so simple. > > Regards, > > Herv? > > Sent from my iPhone From adam at adamish.com Wed Feb 21 16:16:09 2018 From: adam at adamish.com (Adam Granger) Date: Wed, 21 Feb 2018 08:16:09 -0800 Subject: Psuedo-classes and weak references Message-ID: <3782c32bedc85549a560a7822ef9db06ec5b2ba9@webmail.adamish.com> Greetings, I've discovered the following code behaves differently in Java 8 vs 9, in Java 8 it produces change and invalidation events, in Java 9 nothing. I debugged this to the fact getPsuedoClassStates() returns a read-only wrapper, and that uses weak references therefore there is nothing to stop it garbage collected. I'm able to work around this by storing getPsuedoClassStates() as a field in my class but this feels horrible. What is the recommended way of listening to changes in Psuedo states? public class PsuedoEvents extends Application { public static void main ( String [] args ) { launch ( args ); } @Override public void start ( Stage stage ) throws Exception { Button horse = new Button ( "horse" ); horse . getPseudoClassStates (). addListener ( new InvalidationListener () { @Override public void invalidated ( Observable arg0 ) { System . out . println ( "invalidated " + arg0 ); } }); horse . getPseudoClassStates (). addListener ( new SetChangeListener <>() { @Override public void onChanged ( Change arg0 ) { System . out . println ( "changed " + arg0 ); } }); stage . setScene ( new Scene ( new HBox ( horse ), 300 , 300 )); PseudoClass fooClass = PseudoClass . getPseudoClass ( "foo" ); horse . setOnAction ( event -> { horse . pseudoClassStateChanged ( fooClass , ! horse . getPseudoClassStates (). contains ( fooClass )); System . out . println ( "Toggle state... " + horse . getPseudoClassStates ()); }); stage . show (); } } Work around private ObservableSet < PseudoClass > states ; // <=== strong ref @Override public void start ( Stage stage ) throws Exception { Button horse = new Button ( "horse" ); states = horse . getPseudoClassStates (); states . addListener ( new InvalidationListener () { @Override public void invalidated ( Observable arg0 ) { System . out . println ( "invalidated " + arg0 ); } }); From herve.girod at gmail.com Wed Feb 21 16:55:58 2018 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Wed, 21 Feb 2018 17:55:58 +0100 Subject: Regression in 1.8.0_102 In-Reply-To: References: <82EC404E-7ACA-468B-A935-757058EA7091@gmail.com> <043b0d75-2345-4b16-9ea7-3afafffea581@default> Message-ID: <85FCA3D5-7308-4D79-B848-E692736A20AB@gmail.com> Hello, You were right, this is fixed in 8u172b03. Regards, Herv? Sent from my iPhone > On Feb 21, 2018, at 12:53, Ajit Ghaisas wrote: > > Hi Herv?, > > Going solely by the problem description, it is most likely due to reported issue - https://bugs.openjdk.java.net/browse/JDK-8183100 > It has been resolved in upcoming JDK 10 & also in upcoming 8u172 update. > You can try out early access builds at - http://jdk.java.net/ - and see if you still see the issue. > > Regards, > Ajit > > > -----Original Message----- > From: Herv? Girod [mailto:herve.girod at gmail.com] > Sent: Wednesday, February 21, 2018 3:53 PM > To: openjfx-dev at openjdk.java.net > Subject: Regression in 1.8.0_102 > > Hello, > > We discovered a regression seemingly in how css properties are applied for fonts in some cases beginning with 1.8.0_102. It was OK with 1.8.0_92 and it is also KO in 9.04. > > The problem are some fonts which are not rendered when applying a css style. In our case the background is black and the text should be white (specified through css) but it?s black so not visible on the background. > > I will try to create a simple test case, but our application is big, so it?s not so simple. > > Regards, > > Herv? > > Sent from my iPhone From adam at adamish.com Fri Feb 23 09:50:08 2018 From: adam at adamish.com (Adam Granger) Date: Fri, 23 Feb 2018 01:50:08 -0800 Subject: Layout bug with SwingNode ? Message-ID: <5ba93bfe252e515bc79205097cd7328ef6b7706d@webmail.adamish.com> Greeting, (https://stackoverflow.com/questions/48937412/node-snapshot-causing-layout-issue) Using JavaFX 9.0.4 I'm embedding some 3rd party Swing content in a JavaFX app. The 3rd party content already has its own preferred size, so I'm wrapping it with a StackPane to stretch it out... However, when node.snapshot() is called this causes the SwingNode to jump back to its preferred size, manually resizing the window causes it to fill the window again. I've also identified this only occurs if the scene is first shown without content and the content is added later. Is this a bug? How can I work around it? The following example recreates the issue public class NodeSnapshotFunny extends Application { @Override public void start ( Stage stage ) throws Exception { SwingNode swingNode = new SwingNode (); Button button = new Button ( "Test" ); button . setOnAction ( event -> { WritableImage image = button . snapshot ( null , null ); }); StackPane stackPane = new StackPane ( swingNode ); Scene scene = new Scene ( stackPane ); stage . setScene ( scene ); stage . show (); stackPane . getChildren (). add ( button ); SwingUtilities . invokeLater (() -> { JPanel jPanel = new JPanel (); jPanel . setPreferredSize ( new Dimension ( 300 , 300 )); jPanel . setBackground ( Color . red ); swingNode . setContent ( jPanel ); }); } public static void main ( String [] args ) { launch ( args ); } } From murali.billa at oracle.com Fri Feb 23 11:59:46 2018 From: murali.billa at oracle.com (Murali Billa) Date: Fri, 23 Feb 2018 03:59:46 -0800 (PST) Subject: [11] Review request for 8193207: [TESTBUG] Unit test case to check user agent string Message-ID: ? Hi Kevin, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8193207 ? webrev: http://cr.openjdk.java.net/~mbilla/8193207/webrev.00/ Thanks, Murali From kevin.rushforth at oracle.com Fri Feb 23 13:42:50 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 23 Feb 2018 05:42:50 -0800 Subject: Layout bug with SwingNode ? In-Reply-To: <5ba93bfe252e515bc79205097cd7328ef6b7706d@webmail.adamish.com> References: <5ba93bfe252e515bc79205097cd7328ef6b7706d@webmail.adamish.com> Message-ID: <5A901A5A.9090603@oracle.com> This does sound like a bug. Can you file it at http://bugreport.java.com/ ? One possible workaround might be to set the size of the scene when you first create it: new Scene(root, WIDTH, HEIGHT) -- Kevin Adam Granger wrote: > Greeting, > > (https://stackoverflow.com/questions/48937412/node-snapshot-causing-layout-issue) > > Using JavaFX 9.0.4 I'm embedding some 3rd party Swing content in a > JavaFX app. The 3rd party content already has its own preferred size, > so I'm wrapping it with a StackPane to stretch it out... > > However, when node.snapshot() is called this causes the SwingNode to > jump back to its preferred size, manually resizing the window causes > it to fill the window again. > > I've also identified this only occurs if the scene is first shown > without content and the content is added later. > > Is this a bug? How can I work around it? > > The following example recreates the issue > > public > > class > > NodeSnapshotFunny > > extends > > Application > > { > > @Override > > public > > void > start > ( > Stage > stage > ) > > throws > > Exception > > { > > SwingNode > swingNode > = > > new > > SwingNode > (); > > Button > button > = > > new > > Button > ( > "Test" > ); > > button > . > setOnAction > ( > event > -> > > { > > WritableImage > image > = > button > . > snapshot > ( > null > , > > null > ); > > }); > > StackPane > stackPane > = > > new > > StackPane > ( > swingNode > ); > > Scene > scene > = > > new > > Scene > ( > stackPane > ); > > stage > . > setScene > ( > scene > ); > > stage > . > show > (); > > stackPane > . > getChildren > (). > add > ( > button > ); > > SwingUtilities > . > invokeLater > (() > > -> > > { > > JPanel > jPanel > = > > new > > JPanel > (); > > jPanel > . > setPreferredSize > ( > new > > Dimension > ( > 300 > , > > 300 > )); > > jPanel > . > setBackground > ( > Color > . > red > ); > > swingNode > . > setContent > ( > jPanel > ); > > }); > > } > > public > > static > > void > main > ( > String > [] > args > ) > > { > > launch > ( > args > ); > > } > > } > > > From mike.ennen at gmail.com Fri Feb 23 22:29:38 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 23 Feb 2018 15:29:38 -0700 Subject: Monocle Headless BufferOverflowException (Issue + Fix) Message-ID: Hello, When doing some testing with TestFX running in headless mode via Monocle I came across a BufferOverflowException. After some google searching it seems that someone has come across this before me and created a GitLab repository with the full issue details and a suggested fix! I was wondering if this has ever been brought to the attention of the JavaFX devs and if there was a corresponding bug in JBS. Here's the commit: https://gitlab.com/openjfxepd/jfxpatch/commit/f7c341775e5258e790a049f3fdce4a 956ef665c7 Here is the issue: https://gitlab.com/openjfxepd/jfxpatch/issues/1 Thanks to John Neffenger for taking the time to put this together! I wanted to make this work was known to Kevin and the team. Thanks very much, (P.S. When is ramp down phase 2 over? :) ). -- Michael Ennen From kevin.rushforth at oracle.com Fri Feb 23 22:36:19 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 23 Feb 2018 14:36:19 -0800 Subject: Monocle Headless BufferOverflowException (Issue + Fix) In-Reply-To: References: Message-ID: <5A909763.3070003@oracle.com> I haven't seen this bug, and I did a quick search and don't find it. Go ahead and file a bug, but unless it is a trivial fix, you will need to contact the author of the fix and ask him to sign the OCA before we could take it. > (P.S. When is ramp down phase 2 over? :) ). Oh, right. We're actually at GAC for JDK 10 now. I owe you a review of the Robot API... -- Kevin Michael Ennen wrote: > Hello, > > When doing some testing with TestFX running in headless mode > via Monocle I came across a BufferOverflowException. > > After some google searching it seems that someone has come > across this before me and created a GitLab repository with the > full issue details and a suggested fix! I was wondering if this > has ever been brought to the attention of the JavaFX devs and if > there was a corresponding bug in JBS. > > Here's the commit: > > https://gitlab.com/openjfxepd/jfxpatch/commit/f7c341775e5258e790a049f3fdce4a > 956ef665c7 > > Here is the issue: > > https://gitlab.com/openjfxepd/jfxpatch/issues/1 > > Thanks to John Neffenger for taking the time to put this together! I > wanted to make this work was known to Kevin and the team. > > Thanks very much, > > (P.S. When is ramp down phase 2 over? :) ). > > From mike.ennen at gmail.com Fri Feb 23 23:12:30 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 23 Feb 2018 16:12:30 -0700 Subject: Monocle Headless BufferOverflowException (Issue + Fix) In-Reply-To: <5A909763.3070003@oracle.com> References: <5A909763.3070003@oracle.com> Message-ID: Good point about the OCA, I have sent an email just now to John Neffenger. Hopefully he is still interested in this topic :). I will file the bug report after hopefully getting into contact with John. Thanks Kevin, And no rush on the Robot review, just didn't want you to totally forget - I know how it is, Michael On Fri, Feb 23, 2018 at 3:36 PM, Kevin Rushforth wrote: > I haven't seen this bug, and I did a quick search and don't find it. Go > ahead and file a bug, but unless it is a trivial fix, you will need to > contact the author of the fix and ask him to sign the OCA before we could > take it. > > > (P.S. When is ramp down phase 2 over? :) ). > > Oh, right. We're actually at GAC for JDK 10 now. I owe you a review of the > Robot API... > > -- Kevin > > > > > Michael Ennen wrote: > >> Hello, >> >> When doing some testing with TestFX running in headless mode >> via Monocle I came across a BufferOverflowException. >> >> After some google searching it seems that someone has come >> across this before me and created a GitLab repository with the >> full issue details and a suggested fix! I was wondering if this >> has ever been brought to the attention of the JavaFX devs and if >> there was a corresponding bug in JBS. >> >> Here's the commit: >> >> https://gitlab.com/openjfxepd/jfxpatch/commit/f7c341775e5258 >> e790a049f3fdce4a >> 956ef665c7 >> >> Here is the issue: >> >> https://gitlab.com/openjfxepd/jfxpatch/issues/1 >> >> Thanks to John Neffenger for taking the time to put this together! I >> wanted to make this work was known to Kevin and the team. >> >> Thanks very much, >> >> (P.S. When is ramp down phase 2 over? :) ). >> >> >> > From john at status6.com Fri Feb 23 23:32:13 2018 From: john at status6.com (John Neffenger) Date: Fri, 23 Feb 2018 15:32:13 -0800 Subject: Monocle Headless BufferOverflowException (Issue + Fix) In-Reply-To: References: Message-ID: On 02/23/2018 02:29 PM, Michael Ennen wrote: > Here is the issue: > > https://gitlab.com/openjfxepd/jfxpatch/issues/1 > > Thanks to John Neffenger for taking the time to put this together! I > wanted to make this work was known to Kevin and the team. I'm so glad you found it! I posted a link to the issue, along with two others, on this mailing list a year ago, but I think people were too busy with all the Java 9 changes happening at the time (rightfully so). I was reluctant to open the official bugs on the Oracle page before testing whether they still occur in the latest version. Actually, I haven't even had the time to check whether they still occur in the latest OpenJFX 8. In general, what should we do when we find bugs in version 8 but the latest development is happening on version 11? Open the bug, or test it against the latest version first? Thanks, John From kevin.rushforth at oracle.com Fri Feb 23 23:45:57 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 23 Feb 2018 15:45:57 -0800 Subject: Monocle Headless BufferOverflowException (Issue + Fix) In-Reply-To: References: Message-ID: <5A90A7B5.4020908@oracle.com> > In general, what should we do when we find bugs in version 8 but the > latest development is happening on version 11? Open the bug, or test > it against the latest version first? The latter is preferable if it is possible to test it on the latest version. Thanks. -- Kevin John Neffenger wrote: > On 02/23/2018 02:29 PM, Michael Ennen wrote: >> Here is the issue: >> >> https://gitlab.com/openjfxepd/jfxpatch/issues/1 >> >> Thanks to John Neffenger for taking the time to put this together! I >> wanted to make this work was known to Kevin and the team. > > I'm so glad you found it! I posted a link to the issue, along with two > others, on this mailing list a year ago, but I think people were too > busy with all the Java 9 changes happening at the time (rightfully so). > > I was reluctant to open the official bugs on the Oracle page before > testing whether they still occur in the latest version. Actually, I > haven't even had the time to check whether they still occur in the > latest OpenJFX 8. > > In general, what should we do when we find bugs in version 8 but the > latest development is happening on version 11? Open the bug, or test > it against the latest version first? > > Thanks, > John From mike.ennen at gmail.com Sat Feb 24 03:37:29 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 23 Feb 2018 20:37:29 -0700 Subject: Monocle Headless BufferOverflowException (Issue + Fix) In-Reply-To: <5A90A7B5.4020908@oracle.com> References: <5A90A7B5.4020908@oracle.com> Message-ID: >From my limited testing, the issue is still present in 8u172 b03 (early access) and 9.0.1+11 (that is, assuming it is the same bug which I am crossing my fingers about!). Thanks for taking this back up, John. On Fri, Feb 23, 2018 at 4:45 PM, Kevin Rushforth wrote: > > In general, what should we do when we find bugs in version 8 but the >> latest development is happening on version 11? Open the bug, or test it >> against the latest version first? >> > > The latter is preferable if it is possible to test it on the latest > version. > > Thanks. > > -- Kevin > > > > John Neffenger wrote: > >> On 02/23/2018 02:29 PM, Michael Ennen wrote: >> >>> Here is the issue: >>> >>> https://gitlab.com/openjfxepd/jfxpatch/issues/1 >>> >>> Thanks to John Neffenger for taking the time to put this together! I >>> wanted to make this work was known to Kevin and the team. >>> >> >> I'm so glad you found it! I posted a link to the issue, along with two >> others, on this mailing list a year ago, but I think people were too busy >> with all the Java 9 changes happening at the time (rightfully so). >> >> I was reluctant to open the official bugs on the Oracle page before >> testing whether they still occur in the latest version. Actually, I haven't >> even had the time to check whether they still occur in the latest OpenJFX 8. >> >> In general, what should we do when we find bugs in version 8 but the >> latest development is happening on version 11? Open the bug, or test it >> against the latest version first? >> >> Thanks, >> John >> > -- Michael Ennen From ank.cpp at gmail.com Sun Feb 25 21:00:23 2018 From: ank.cpp at gmail.com (ankit srivastav) Date: Mon, 26 Feb 2018 02:30:23 +0530 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5A820EF4.6020409@oracle.com> References: <5A820EF4.6020409@oracle.com> Message-ID: NO, Please go through the table, all the points accumulated are not even more then 7. I have given reasons for my points. *age* *author* *description* Points Reason 8 days ago rkamath 8196802: 3D unit tests listed as pass although they are actually skipped 0.5 Test file, not a direct impact-able code change in product. 10 days ago rkamath 8089454: [HTMLEditor] selection removes CENTER alignment 0.5 A very small change, why I?m saying so, as the file modified gets called directly from the APP written. No debugging/a little is required to make the change, which actually defies the purpose of getting knowledge of the product. 13 days ago rkamath 8196615: Skip 3D unit tests on system without 3D capability 0.5 Changes in Test file, not a direct impact-able code change in product. 4 weeks ago rkamath 8165459: HTMLEditor: clipboard toolbar buttons are disabled unexpectedly 0.5 A very small change, why I?m saying so, as the file modified gets called directly from the APP written. No debugging/a little is required to make the change, which actually defies the purpose of getting knowledge of the product. 7 weeks ago rkamath 8088925: Non opaque background cause NumberFormatException 0.5 A very small change, why I?m saying so, as the file modified gets called directly from the APP written. No debugging/a little is required to make the change, which actually defies the purpose of getting knowledge of the product. 2 months ago rkamath 8090011: 'tab' key makes control loose focus jdk-10+36 0.5 A very small change, why I?m saying so, as the file modified gets called directly from the APP written. No debugging/a little is required to make the change, which actually defies the purpose of getting knowledge of the product. *age* *author* *description* Points Reason 2 months ago mbilla 8187483: Update to 605.1 version of WebKit 0 Unless you directly point what changes you have made in the patch I will count it has 0. Most probably you have made changes for DRT, which even a tester can do. Moving DRT is a non technical task, requires no technical skills. 3 months ago mbilla 8187928: [WebView] Images copied from clipboard not written in source file format 1 4 months ago ghb 8178290: Intermittent test failure in test.com.sun.webkit.network.CookieTest jdk-10+29 0.5 Changes in Test file, not a direct impact-able code change in product. 4 months ago mbilla 8187726: [WebView] Copy and Paste of Image not resulting in expected behavior jdk-10+27 1 4 months ago mbilla 8187671: [WebView] Drag and Drop of text or html results in an image 1 5 months ago ghb 8089124: HTML5: Number input allows non-numeric input 0.5 Only setting value changes. For me this kind of change was not even get considered for Author status. 5 months ago ghb 8185314: Remove unused third-party python scripts from WebKit sources 0 No actual code change, you have only removed it.It seems it was not even getting called otherwise you must have change some other files which calls function from these files. Adding all the points, total sum = 7. So it's a NO for me. I think you have to solve at least 3 more issues to get to the committer status. *The whole idea behind becoming a committer is to get good solid product knowledge not the issue count.* *Quality matters over quantity.* Which one can only get after solving variety of issues with various level of difficulty level. Here I can see you have 3 checkins for file HTMLEditorSkin.java. This file basically gets I/P from APP written. No/little debugging skill is require to solve the issue in this file. For all the test changes I have awarded 0.5 as no direct impact on product. For DRT, moving DRT from one revision to another is just a side job. Anybody can do that. If I tell a 12th grader then even he can also do that. Also I'm not sure what's the actual contribution so awarded as 0. Removing a file, that's too unused, no code change so 0. *I have awarded proper points to proper code changes.* @Rajath: I know you must be under pressure (No idea from whom) to become committer, but I can see lots of potential in you. You should not not succumb to such pressure. Whole idea [as I have stated above ] to become committer is get sound product understanding, don't stop yourself to get that. *Solve issue to get knowledge not just to show counts to other people.* I can one more checkin from you, but that's too I guess in Test file i.e. 0.5 So It seems, you are very close to your destination. Let me now if anyone in the community has any objection. --Ankit On Tue, Feb 13, 2018 at 3:32 AM, Kevin Rushforth wrote: > I hereby nominate Rajath Kamath [1] to OpenJFX Committer. > > Rajath is a member of JavaFX team at Oracle, who has contributed 11 > changesets [2][3] to OpenJFX. > > Votes are due by February 26, 2018. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#rkamath > > [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount= > 20&rev=author%28rkamath%29 > [3] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount= > 20&rev=rajath.kamath > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > > From murali.billa at oracle.com Mon Feb 26 10:05:28 2018 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 26 Feb 2018 02:05:28 -0800 (PST) Subject: [11] Review request for 8198587: Increase test timeout values to make test suite more stable Message-ID: <22930d81-eb45-4678-80d6-4d6184a4b957@default> ? Hi Kevin, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8198587 ? webrev: http://cr.openjdk.java.net/~mbilla/8198587/webrev.00/ Thanks, Murali From murali.billa at oracle.com Mon Feb 26 13:22:27 2018 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 26 Feb 2018 05:22:27 -0800 (PST) Subject: [11] Review request for 8198610: [TestBug] test.javafx.scene.web.UserDataDirectoryTest logs on stderr Message-ID: ? Hi Kevin, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8198610 ? webrev: http://cr.openjdk.java.net/~mbilla/8198610/webrev.00/ Thanks, Murali From ajit.ghaisas at oracle.com Tue Feb 27 12:23:06 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 27 Feb 2018 04:23:06 -0800 (PST) Subject: [11] Review request : JDK-8195806 : Eliminate dependency on sun.font.lookup in javafx.graphics In-Reply-To: <80a7e3a3-2cae-81aa-f5a5-d282f6799ac5@oracle.com> References: <86c4c19f-93cc-4804-a94d-430443c9d3fa@default> <5A83E37C.50600@oracle.com> <7297b300-5853-4698-8065-9250ec45953f@default> <80a7e3a3-2cae-81aa-f5a5-d282f6799ac5@oracle.com> Message-ID: <9e7b1301-5c20-4fde-9754-8050c1e41077@default> Hi Phil, ? ?? All my webrev does is to replace the way of?obtaining name of JDK font directory ? and as rightly pointed by you below (first two lines of your last reply) ? it is what is needed to get rid of dependency on sun.font.lookup. ???I have tested it by running an OpenJDK build that doesn't contain a lib/fonts directory using Ensemble8 sample. ??? ????I got your point about Lucida Sans fonts being pointless with openJDK & the font finding fallback code is being little dubious. ??? I would like to address that separately. I have filed bug HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8198752"JDK-8198752 to handle that. ? Regards, Ajit ? From: Phil Race Sent: Thursday, February 15, 2018 10:44 PM To: Ajit Ghaisas Cc: Kevin Rushforth; openjfx-dev at openjdk.java.net Subject: Re: [11] Review request : JDK-8195806 : Eliminate dependency on sun.font.lookup in javafx.graphics ? This part is probably as good as you can do +??????? return System.getProperty("java.home","") + File.separator + +??????????????? "lib" + File.separator + "fonts"; but if we want to support running against OpenJDK which does not have Lucida Sans then we need to look at the caller of getJDKFontDir() So going forward all of this .. ??? private static final String jreDefaultFont?? = "Lucida Sans Regular"; ??? private static final String jreDefaultFontLC = "lucida sans regular"; ??? private static final String jreDefaultFontFile = "LucidaSansRegular.ttf"; .. is probably pointless. And if we can't find it then the first layer of fall back code is a bit dubious ??? // Normally use the JRE default font as the last fallback. ??????????????? // If we can't find even that, use any platform font; ??????????????? for (String font : fontToFileMap.keySet()) { ??????????????????? String file = findFile(font); // gets full path ???????????????????fontResource = createFontResource(jreDefaultFontLC, file); ??????????????????? if (fontResource != null) { ??????????????????????? break; ??????????????????? } ? It did not really matter in the past .. it was just to prevent NPE in an unlikely scenario .. But if it is to be the first class way of finding this font it probably should be using "System" instead ? But then you need to make sure we don't have a circularity in the case that we are using this in initialiasing System. ? -phil. ? On 02/14/2018 09:39 PM, Ajit Ghaisas wrote: Hi Phil, ? ?? Thanks for having a look at the changes. ?? ???I have little difficulty in understanding your question. ?? Are you referring to the sun.font.SunFontManager initialization? ?? I am asking as it is not evident from the code changes that I have done as part of this webrev. ? ?? Request your guidance in this regard. ????? Regards, Ajit?? ? ? -----Original Message----- From: Philip Race Sent: Wednesday, February 14, 2018 12:52 PM To: Ajit Ghaisas Cc: Kevin Rushforth; HYPERLINK "mailto:openjfx-dev at openjdk.java.net"openjfx-dev at openjdk.java.net Subject: Re: [11] Review request : JDK-8195806 : Eliminate dependency on sun.font.lookup in javafx.graphics ? Well that removes the dependency but how are you fixing the problem of how else to find the font ? There needs to be alternate code or you need to go back to see what would happen if some code tried to locate that font and how it would fail. ? -phil. ? On 2/13/18, 11:11 PM, Ajit Ghaisas wrote: Hi Kevin, Phil, ? ?????? Request you to review following fix : ? ?????? Issue :? https://bugs.openjdk.java.net/browse/JDK-8195806 ? ?????? Fix :? http://cr.openjdk.java.net/~aghaisas/fx/8195806/webrev.0/ ? Regards, Ajit ? From nlisker at gmail.com Tue Feb 27 14:31:48 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 27 Feb 2018 16:31:48 +0200 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: <5A861471.8030208@oracle.com> References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> Message-ID: Iv'e given the pipeline some thought. I'm purposely ignoring current role names (Author, Contributor...). My suggestions: Potential contributor wants to contribute... 1. Formal process a. If the issue is not in the JBS, they submit it via bugreport. b. They send an email on the mailing list regarding the issue (a plan, question on how to approach etc.) c. If the above effort is "deemed worthy" (whatever that means), and they have signed the OCA, and they then they get access to JBS. If they've given a GitHub account, they get access to GitHub PRs. d. Discussion from the mailing list is copied/linked to the JBS issue. Maybe if it's their issue (step a) then the Reporter field can change to them. This ensures that: * There's 1 entry point. * GitHub and JBS identities are linked (GitHub identity is verified). * Being able to comment on JBS is easier - instead of requiring 2 commits it requires good intentions(?) * Not every person on the planet has access to JBS. 2. Work process a. They fork the GitHub repo. b. They create a PR with a 2-way link to/from JBS (similar to current webrevs - JBS links). c. Discussion specifically on the patch should happen in the PR thread. General info on the bug (affected versions etc.) still happens in JBS. d. After the patch had been reviewed, it is committed to the Oracle repo. Since GitHub mirrors Oracle I don't think it matters if the patch is merged into GitHub. This ensures that: * It's easier to start working because the GiutHub repo is more convenient than the Oracle repo currently. * PRs and JBS issues are mutually aware. * The submit -> review -> commit process is streamlined. We pay a synchronization price for having 2 repos and 2 bug trackers. This is what I could come up with. - Nir On Fri, Feb 16, 2018 at 1:14 AM, Kevin Rushforth wrote: > > > Johan Vos wrote: > > > > On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > > A global reference in JBS would indeed be very good to track back the work > in a PR to a real issue. It can also be very useful as there are many > existing issues in JBS that can be referred to in future work. > > The only issue I see is that in order to create an issue in JBS, you need > to have "author" status, so not everyone can do this? Given the idea that > developers who want to create a PR also need to sign an OCA, it might make > sense to somehow combine the administration? > > > I don't think we can combine this, but I hope to be able to relax the > requirements to become an Author a little. The current guidelines are 2 > sponsored contributions [1]. > > Pending appointment as an Author, it isn't hard to submit a bug via > http://bugreport.java.com/ . If there is a test case, it usually gets > moved to the JDK project within a day or so (and I can move them sooner, if > needed). The bigger bother is that you can't comment in JBS on a bug you > didn't create, but once the bug is there, you can work on it in GutHub > and/or send email to the list. I'll also add any comments from contributors > who are not yet Authors to any bug report. > > -- Kevin > > [1] http://openjdk.java.net/projects/#project-author > > > - Johan > > From kevin.rushforth at oracle.com Tue Feb 27 20:36:18 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 27 Feb 2018 12:36:18 -0800 Subject: Result: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5A820EF4.6020409@oracle.com> References: <5A820EF4.6020409@oracle.com> Message-ID: <5A95C142.7040100@oracle.com> Voting for Rajath Kamath [1] to OpenJFX Committer [2] is now closed. Yes: 6 Veto: 1 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this nomination has failed. I didn't have a chance to respond to the Veto before the voting period ended, but will reply shortly. -- Kevin [1] http://openjdk.java.net/census#rkamath [2] mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021432.html From kevin.rushforth at oracle.com Tue Feb 27 20:53:42 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 27 Feb 2018 12:53:42 -0800 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: References: <5A820EF4.6020409@oracle.com> Message-ID: <5A95C556.7020503@oracle.com> Hi Ankit, In response to your veto, I took the opportunity to look at the the list of changes, and believe that my earlier nomination of Rajath to OpenJFX Project Committer was justified, if perhaps barely so. While there is no objective criteria by which one can say a particular changeset is worth 0.5 of a fix, we do often look at 2 to 4 trivial fixes or test-only fixes to "make up the difference" in case only 6 or 7 are deemed "significant". This is why we usually want 10 or 12 fixes before we nominate someone for Committer -- to avoid quibbling over whether one or two are worthy of being counted. Rather than respond to each of your comments individually (although I do have one point below), I will instead list the fixes I consider significant. In looking at the list of fixes again, I would consider the following 7 non-test fixes to be significant, even though several of them were only a few lines of product code changed: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/3d5c22069d1f http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/5a3cc1b5bb22 http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/674513271a88 http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dc2963c3f7d1 (see comment below) http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/9f43fb83e989 http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dedd5afd753e http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/cfa038af148b In all cases there needed to be an analysis, a fix, and testing to ensure that the bug was fixed without introducing a regression. As for your assertion about his part of the collaborative fix to upgrade WebKit to v605.1, JDK-8187483 (changeset dc2963c3f7d1), you make an unsubstantiated claim regarding his contribution. As he did contribute to that fix, I don't see any reason to question how significant it was. In addition to the above 7, and excluding JDK-8185314 (the removal of unused files, which I would agree does not count at all), the other three test fixes are in my opinion enough justify the nomination. I would finally point out that Rajath contributed three additional test fixes during the two week voting period, for a new total of 14 changesets (13 excluding the unused file removal). Please respond to the list as to whether you feel the additional three test fixes, along with my additional explanation, is enough to satisfy your concerns over this nomination, and if not, why not. I would like to put the nomination forward again for a vote once the objections are resolved. Thank you. -- Kevin ankit srivastav wrote: > NO, > > Please go through the table, all the points accumulated are not even > more then 7. > I have given reasons for my points. > > > *age* > > > > *author* > > > > *description* > > > > Points > > > > Reason > > 8 days ago > > > > rkamath > > > > 8196802: 3D unit tests listed as pass although they are actually > skipped > > > > > 0.5 > > > > Test file, not a direct impact-able code change in product. > > 10 days ago > > > > rkamath > > > > 8089454: [HTMLEditor] selection removes CENTER alignment > > > > > 0.5 > > > > A very small change, why I?m saying so, as the file modified gets > called directly from the APP written. No debugging/a little is > required to make the change, which actually defies the purpose of > getting knowledge of the product. > > 13 days ago > > > > rkamath > > > > 8196615: Skip 3D unit tests on system without 3D capability > > > > > 0.5 > > > > Changes in Test file, not a direct impact-able code change in product. > > 4 weeks ago > > > > rkamath > > > > 8165459: HTMLEditor: clipboard toolbar buttons are disabled > unexpectedly > > > > > 0.5 > > > > A very small change, why I?m saying so, as the file modified gets > called directly from the APP written. No debugging/a little is > required to make the change, which actually defies the purpose of > getting knowledge of the product. > > 7 weeks ago > > > > rkamath > > > > 8088925: Non opaque background cause NumberFormatException > > > > > 0.5 > > > > A very small change, why I?m saying so, as the file modified gets > called directly from the APP written. No debugging/a little is > required to make the change, which actually defies the purpose of > getting knowledge of the product. > > 2 months ago > > > > rkamath > > > > 8090011: 'tab' key makes control loose focus > jdk-10+36 > > > > 0.5 > > > > A very small change, why I?m saying so, as the file modified gets > called directly from the APP written. No debugging/a little is > required to make the change, which actually defies the purpose of > getting knowledge of the product. > > *age* > > > > *author* > > > > *description* > > > > Points > > > > Reason > > 2 months ago > > > > mbilla > > > > 8187483: Update to 605.1 version of WebKit > > > > > 0 > > > > Unless you directly point what changes you have made in the patch I > will count it has 0. Most probably you have made changes for DRT, > which even a tester can do. Moving DRT is a non technical task, > requires no technical skills. > > 3 months ago > > > > mbilla > > > > 8187928: [WebView] Images copied from clipboard not written in source > file format > > > > > 1 > > > > > 4 months ago > > > > ghb > > > > 8178290: Intermittent test failure in > test.com.sun.webkit.network.CookieTest > jdk-10+29 > > > > 0.5 > > > > Changes in Test file, not a direct impact-able code change in product. > > 4 months ago > > > > mbilla > > > > 8187726: [WebView] Copy and Paste of Image not resulting in expected > behavior > jdk-10+27 > > > > 1 > > > > > 4 months ago > > > > mbilla > > > > 8187671: [WebView] Drag and Drop of text or html results in an image > > > > > 1 > > > > > 5 months ago > > > > ghb > > > > 8089124: HTML5: Number input allows non-numeric input > > > > > 0.5 > > > > Only setting value changes. For me this kind of change was not even > get considered for Author status. > > 5 months ago > > > > ghb > > > > 8185314: Remove unused third-party python scripts from WebKit sources > > > > > 0 > > > > No actual code change, you have only removed it.It seems it was not > even getting called otherwise you must have change some other files > which calls function from these files. > > > > Adding all the points, total sum = 7. > So it's a NO for me. > I think you have to solve at least 3 more issues to get to the > committer status. > * > * > *The whole idea behind becoming a committer is to get good solid > product knowledge not the issue count.* > *Quality matters over quantity.* > > Which one can only get after solving variety of issues with various > level of difficulty level. > > Here I can see you have 3 checkins for file HTMLEditorSkin.java. > This file basically gets I/P from APP written. > No/little debugging skill is require to solve the issue in this file. > > For all the test changes I have awarded 0.5 as no direct impact on > product. > For DRT, moving DRT from one revision to another is just a side job. > Anybody can do that. > If I tell a 12th grader then even he can also do that. > Also I'm not sure what's the actual contribution so awarded as 0. > > Removing a file, that's too unused, no code change so 0. > > *I have awarded proper points to proper code changes.* > > @Rajath: > I know you must be under pressure (No idea from whom) to become > committer, but I can see lots of potential in you. > You should not not succumb to such pressure. > Whole idea [as I have stated above ] to become committer is get sound > product understanding, don't stop yourself to get that. > *Solve issue to get knowledge not just to show counts to other people.* > > I can one more checkin from you, but that's too I guess in Test file > i.e. 0.5 > So It seems, you are very close to your destination. > > Let me now if anyone in the community has any objection. > > --Ankit > > > > > On Tue, Feb 13, 2018 at 3:32 AM, Kevin Rushforth > > wrote: > > I hereby nominate Rajath Kamath [1] to OpenJFX Committer. > > Rajath is a member of JavaFX team at Oracle, who has contributed > 11 changesets [2][3] to OpenJFX. > > Votes are due by February 26, 2018. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a > project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#rkamath > > > [2] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28rkamath%29 > > [3] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=rajath.kamath > > > [4] http://openjdk.java.net/census#openjfx > > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > > [6] http://openjdk.java.net/projects#project-committer > > > From kevin.rushforth at oracle.com Tue Feb 27 21:21:56 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 27 Feb 2018 13:21:56 -0800 Subject: Update on enabling JavaFX to work with OpenJDK builds Message-ID: <5A95CBF4.3010603@oracle.com> One of the big challenges in running JavaFX with OpenJDK builds is that developers need to build OpenJDK locally themselves and include the JavaFX bits produced by a locally-built OpenJFX build. In an earlier email with the subject "javafx might not be present" [1], I mentioned our intention to make it easier for OpenJFX to be built, tested, and run with OpenJDK builds that don't already contain javafx.* modules. This will pave the way to allow a set of pre-built javafx modules to be distributed that will run on top of a pre-built OpenJDK. By way of update, this work is underway and can be tracked via the following two JBS issues: 1. Removing internal dependencies: JDK-8195798 [2] : Address dependencies in javafx.* modules on internal APIs of core modules The above is an umbrella task that points to several linked blocking bugs. All of these bugs are in progress and a few are already done (e.g., removing jdk.internal.Unsafe from Marlin). 2. Enabling the building, testing, and distribution as a set of separate modules JDK-8198329 [3] : Support FX build / test using JDK that doesn't include javafx.* modules This one depends on the first two, but can be started in parallel, so I plan to start on it in the next few days. Let me know if you have any questions on this. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021447.html [2] https://bugs.openjdk.java.net/browse/JDK-8195798 [3] https://bugs.openjdk.java.net/browse/JDK-8198329 From org.openjdk at io7m.com Tue Feb 27 21:32:00 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Tue, 27 Feb 2018 21:32:00 +0000 Subject: Update on enabling JavaFX to work with OpenJDK builds In-Reply-To: <5A95CBF4.3010603@oracle.com> References: <5A95CBF4.3010603@oracle.com> Message-ID: <20180227213200.674cb39b@copperhead.int.arc7.info> On 2018-02-27T13:21:56 -0800 Kevin Rushforth wrote: > > In an earlier email with the subject "javafx might not be present" [1], > I mentioned our intention to make it easier for OpenJFX to be built, > tested, and run with OpenJDK builds that don't already contain javafx.* > modules. This will pave the way to allow a set of pre-built javafx > modules to be distributed that will run on top of a pre-built OpenJDK. > > By way of update, this work is underway and can be tracked via the > following two JBS issues: This is good to hear, thank you! I'll keep an eye on this as it unfolds. -- Mark Raynsford | http://www.io7m.com From kevin.rushforth at oracle.com Tue Feb 27 22:25:45 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 27 Feb 2018 14:25:45 -0800 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> Message-ID: <5A95DAE9.9030809@oracle.com> This seems a good start in formalizing the process. It will need a little tweaking in a couple of areas. Regarding JBS access, even though I want to relax the requirement to become an Author (get a JBS account), it will likely end up somewhere between "an intention to contribute" and "two sponsored contributions, already reviewed and committed". Even without this, there will necessarily be a gap in time between "I want to work on a bug" and getting a JBS account. So there is value in encouraging people to clone the GitHub sandbox, "kick the tires", make a PR to get feedback, etc., before they can access JBS directly (or even while waiting for their OCA to be processed, but no PRs in that case). Something to take into account. Regarding review, we will need a bit more discussion on that. I like the idea of the PR being logged in JBS once it is ready to be reviewed. Johan's thinking was to allow Committers to approve the PR on GitHub -- meaning they could be merged on GitHub before an actual Review has happened. Are you proposing to change that? It might have some advantages, but it could also make it harder in other areas. I'd like to hear from Johan on this. This reminds me that we need to continue the discussion on the general "Review" policy, as it is relevant here. As for whether it is merged into GitHub, I don't have a strong opinion on that. As you say it will be pulled into the mirror anyway (along with changes from reviews happening in JBS that don't first go through the sandbox), so maybe it doesn't matter? On the other hand there might be advantages to getting it into the mainline of the sandbox early? Hard to say. -- Kevin Nir Lisker wrote: > Iv'e given the pipeline some thought. I'm purposely ignoring current > role names (Author, Contributor...). My suggestions: > > Potential contributor wants to contribute... > > 1. Formal process > a. If the issue is not in the JBS, they submit it via bugreport. > b. They send an email on the mailing list regarding the issue (a > plan, question on how to approach etc.) > c. If the above effort is "deemed worthy" (whatever that means), and > they have signed the OCA, and they then they get access to JBS. If > they've given a GitHub account, they get access to GitHub PRs. > d. Discussion from the mailing list is copied/linked to the JBS > issue. Maybe if it's their issue (step a) then the Reporter field can > change to them. > > This ensures that: > * There's 1 entry point. > * GitHub and JBS identities are linked (GitHub identity is verified). > * Being able to comment on JBS is easier - instead of requiring 2 > commits it requires good intentions(?) > * Not every person on the planet has access to JBS. > > 2. Work process > a. They fork the GitHub repo. > b. They create a PR with a 2-way link to/from JBS (similar > to current webrevs - JBS links). > c. Discussion specifically on the patch should happen in the PR > thread. General info on the bug (affected versions etc.) still happens > in JBS. > d. After the patch had been reviewed, it is committed to the Oracle > repo. Since GitHub mirrors Oracle I don't think it matters if the > patch is merged into GitHub. > > This ensures that: > * It's easier to start working because the GiutHub repo is more > convenient than the Oracle repo currently. > * PRs and JBS issues are mutually aware. > * The submit -> review -> commit process is streamlined. > > We pay a synchronization price for having 2 repos and 2 bug trackers. > This is what I could come up with. > > - Nir > > On Fri, Feb 16, 2018 at 1:14 AM, Kevin Rushforth > > wrote: > > > > Johan Vos wrote: >> >> >> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth >> > >> wrote: >> >> A global reference in JBS would indeed be very good to track back >> the work in a PR to a real issue. It can also be very useful as >> there are many existing issues in JBS that can be referred to in >> future work. >> >> The only issue I see is that in order to create an issue in JBS, >> you need to have "author" status, so not everyone can do this? >> Given the idea that developers who want to create a PR also need >> to sign an OCA, it might make sense to somehow combine the >> administration? > > I don't think we can combine this, but I hope to be able to relax > the requirements to become an Author a little. The current > guidelines are 2 sponsored contributions [1]. > > Pending appointment as an Author, it isn't hard to submit a bug > via http://bugreport.java.com/ . If there is a test case, it > usually gets moved to the JDK project within a day or so (and I > can move them sooner, if needed). The bigger bother is that you > can't comment in JBS on a bug you didn't create, but once the bug > is there, you can work on it in GutHub and/or send email to the > list. I'll also add any comments from contributors who are not yet > Authors to any bug report. > > -- Kevin > > [1] http://openjdk.java.net/projects/#project-author > > > >> - Johan > > From nlisker at gmail.com Tue Feb 27 23:38:47 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 28 Feb 2018 01:38:47 +0200 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: <5A95DAE9.9030809@oracle.com> References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> <5A95DAE9.9030809@oracle.com> Message-ID: > > Johan's thinking was to allow Committers to approve the PR on GitHub -- > meaning they could be merged on GitHub before an actual Review has > happened. Are you proposing to change that? What if the PR is rejected at review? We'll end up with conflicts between the repos. And supposed someone works on a different fix and uses the rejected PR code, how will that be committed? On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > This seems a good start in formalizing the process. It will need a little > tweaking in a couple of areas. > > Regarding JBS access, even though I want to relax the requirement to > become an Author (get a JBS account), it will likely end up somewhere > between "an intention to contribute" and "two sponsored contributions, > already reviewed and committed". Even without this, there will necessarily > be a gap in time between "I want to work on a bug" and getting a JBS > account. So there is value in encouraging people to clone the GitHub > sandbox, "kick the tires", make a PR to get feedback, etc., before they can > access JBS directly (or even while waiting for their OCA to be processed, > but no PRs in that case). Something to take into account. > > Regarding review, we will need a bit more discussion on that. I like the > idea of the PR being logged in JBS once it is ready to be reviewed. Johan's > thinking was to allow Committers to approve the PR on GitHub -- meaning > they could be merged on GitHub before an actual Review has happened. Are > you proposing to change that? It might have some advantages, but it could > also make it harder in other areas. I'd like to hear from Johan on this. > This reminds me that we need to continue the discussion on the general > "Review" policy, as it is relevant here. > > As for whether it is merged into GitHub, I don't have a strong opinion on > that. As you say it will be pulled into the mirror anyway (along with > changes from reviews happening in JBS that don't first go through the > sandbox), so maybe it doesn't matter? On the other hand there might be > advantages to getting it into the mainline of the sandbox early? Hard to > say. > > -- Kevin > > > Nir Lisker wrote: > > Iv'e given the pipeline some thought. I'm purposely ignoring current role > names (Author, Contributor...). My suggestions: > > Potential contributor wants to contribute... > > 1. Formal process > a. If the issue is not in the JBS, they submit it via bugreport. > b. They send an email on the mailing list regarding the issue (a plan, > question on how to approach etc.) > c. If the above effort is "deemed worthy" (whatever that means), and > they have signed the OCA, and they then they get access to JBS. If they've > given a GitHub account, they get access to GitHub PRs. > d. Discussion from the mailing list is copied/linked to the JBS issue. > Maybe if it's their issue (step a) then the Reporter field can change to > them. > > This ensures that: > * There's 1 entry point. > * GitHub and JBS identities are linked (GitHub identity is verified). > * Being able to comment on JBS is easier - instead of requiring 2 commits > it requires good intentions(?) > * Not every person on the planet has access to JBS. > > 2. Work process > a. They fork the GitHub repo. > b. They create a PR with a 2-way link to/from JBS (similar to current > webrevs - JBS links). > c. Discussion specifically on the patch should happen in the PR thread. > General info on the bug (affected versions etc.) still happens in JBS. > d. After the patch had been reviewed, it is committed to the Oracle > repo. Since GitHub mirrors Oracle I don't think it matters if the patch is > merged into GitHub. > > This ensures that: > * It's easier to start working because the GiutHub repo is more convenient > than the Oracle repo currently. > * PRs and JBS issues are mutually aware. > * The submit -> review -> commit process is streamlined. > > We pay a synchronization price for having 2 repos and 2 bug trackers. This > is what I could come up with. > > - Nir > > On Fri, Feb 16, 2018 at 1:14 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> >> >> Johan Vos wrote: >> >> >> >> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >> A global reference in JBS would indeed be very good to track back the >> work in a PR to a real issue. It can also be very useful as there are many >> existing issues in JBS that can be referred to in future work. >> >> The only issue I see is that in order to create an issue in JBS, you need >> to have "author" status, so not everyone can do this? Given the idea that >> developers who want to create a PR also need to sign an OCA, it might make >> sense to somehow combine the administration? >> >> >> I don't think we can combine this, but I hope to be able to relax the >> requirements to become an Author a little. The current guidelines are 2 >> sponsored contributions [1]. >> >> Pending appointment as an Author, it isn't hard to submit a bug via >> http://bugreport.java.com/ . If there is a test case, it usually gets >> moved to the JDK project within a day or so (and I can move them sooner, if >> needed). The bigger bother is that you can't comment in JBS on a bug you >> didn't create, but once the bug is there, you can work on it in GutHub >> and/or send email to the list. I'll also add any comments from contributors >> who are not yet Authors to any bug report. >> >> -- Kevin >> >> [1] http://openjdk.java.net/projects/#project-author >> >> >> - Johan >> >> > From kevin.rushforth at oracle.com Tue Feb 27 23:51:39 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 27 Feb 2018 15:51:39 -0800 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> <5A95DAE9.9030809@oracle.com> Message-ID: <5A95EF0B.3030901@oracle.com> Nir Lisker wrote: > > Johan's thinking was to allow Committers to approve the PR on > GitHub -- meaning they could be merged on GitHub before an actual > Review has happened. Are you proposing to change that? > > > What if the PR is rejected at review? We'll end up with conflicts > between the repos. And supposed someone works on a different fix and > uses the rejected PR code, how will that be committed? Good questions; maybe Johan has some thoughts as to how to mitigate this? -- Kevin > > On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth > > wrote: > > This seems a good start in formalizing the process. It will need a > little tweaking in a couple of areas. > > Regarding JBS access, even though I want to relax the requirement > to become an Author (get a JBS account), it will likely end up > somewhere between "an intention to contribute" and "two sponsored > contributions, already reviewed and committed". Even without this, > there will necessarily be a gap in time between "I want to work on > a bug" and getting a JBS account. So there is value in encouraging > people to clone the GitHub sandbox, "kick the tires", make a PR to > get feedback, etc., before they can access JBS directly (or even > while waiting for their OCA to be processed, but no PRs in that > case). Something to take into account. > > Regarding review, we will need a bit more discussion on that. I > like the idea of the PR being logged in JBS once it is ready to be > reviewed. Johan's thinking was to allow Committers to approve the > PR on GitHub -- meaning they could be merged on GitHub before an > actual Review has happened. Are you proposing to change that? It > might have some advantages, but it could also make it harder in > other areas. I'd like to hear from Johan on this. This reminds me > that we need to continue the discussion on the general "Review" > policy, as it is relevant here. > > As for whether it is merged into GitHub, I don't have a strong > opinion on that. As you say it will be pulled into the mirror > anyway (along with changes from reviews happening in JBS that > don't first go through the sandbox), so maybe it doesn't matter? > On the other hand there might be advantages to getting it into the > mainline of the sandbox early? Hard to say. > > -- Kevin > > > Nir Lisker wrote: >> Iv'e given the pipeline some thought. I'm purposely ignoring >> current role names (Author, Contributor...). My suggestions: >> >> Potential contributor wants to contribute... >> >> 1. Formal process >> a. If the issue is not in the JBS, they submit it via bugreport. >> b. They send an email on the mailing list regarding the issue >> (a plan, question on how to approach etc.) >> c. If the above effort is "deemed worthy" (whatever that >> means), and they have signed the OCA, and they then they get >> access to JBS. If they've given a GitHub account, they get access >> to GitHub PRs. >> d. Discussion from the mailing list is copied/linked to the JBS >> issue. Maybe if it's their issue (step a) then the Reporter field >> can change to them. >> >> This ensures that: >> * There's 1 entry point. >> * GitHub and JBS identities are linked (GitHub identity is verified). >> * Being able to comment on JBS is easier - instead of requiring 2 >> commits it requires good intentions(?) >> * Not every person on the planet has access to JBS. >> >> 2. Work process >> a. They fork the GitHub repo. >> b. They create a PR with a 2-way link to/from JBS (similar >> to current webrevs - JBS links). >> c. Discussion specifically on the patch should happen in the PR >> thread. General info on the bug (affected versions etc.) still >> happens in JBS. >> d. After the patch had been reviewed, it is committed to the >> Oracle repo. Since GitHub mirrors Oracle I don't think it matters >> if the patch is merged into GitHub. >> >> This ensures that: >> * It's easier to start working because the GiutHub repo is more >> convenient than the Oracle repo currently. >> * PRs and JBS issues are mutually aware. >> * The submit -> review -> commit process is streamlined. >> >> We pay a synchronization price for having 2 repos and 2 bug >> trackers. This is what I could come up with. >> >> - Nir >> >> On Fri, Feb 16, 2018 at 1:14 AM, Kevin Rushforth >> > >> wrote: >> >> >> >> Johan Vos wrote: >>> >>> >>> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth >>> >> > wrote: >>> >>> A global reference in JBS would indeed be very good to track >>> back the work in a PR to a real issue. It can also be very >>> useful as there are many existing issues in JBS that can be >>> referred to in future work. >>> >>> The only issue I see is that in order to create an issue in >>> JBS, you need to have "author" status, so not everyone can >>> do this? Given the idea that developers who want to create a >>> PR also need to sign an OCA, it might make sense to somehow >>> combine the administration? >> >> I don't think we can combine this, but I hope to be able to >> relax the requirements to become an Author a little. The >> current guidelines are 2 sponsored contributions [1]. >> >> Pending appointment as an Author, it isn't hard to submit a >> bug via http://bugreport.java.com/ . If there is a test case, >> it usually gets moved to the JDK project within a day or so >> (and I can move them sooner, if needed). The bigger bother is >> that you can't comment in JBS on a bug you didn't create, but >> once the bug is there, you can work on it in GutHub and/or >> send email to the list. I'll also add any comments from >> contributors who are not yet Authors to any bug report. >> >> -- Kevin >> >> [1] http://openjdk.java.net/projects/#project-author >> >> >> >>> - Johan >> >> > From kevin.rushforth at oracle.com Wed Feb 28 00:00:49 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 27 Feb 2018 16:00:49 -0800 Subject: [11] Review request : JDK-8195806 : Eliminate dependency on sun.font.lookup in javafx.graphics In-Reply-To: <9e7b1301-5c20-4fde-9754-8050c1e41077@default> References: <86c4c19f-93cc-4804-a94d-430443c9d3fa@default> <5A83E37C.50600@oracle.com> <7297b300-5853-4698-8065-9250ec45953f@default> <80a7e3a3-2cae-81aa-f5a5-d282f6799ac5@oracle.com> <9e7b1301-5c20-4fde-9754-8050c1e41077@default> Message-ID: <5A95F131.70502@oracle.com> This looks fine to me. Please add this info to JBS when you get a chance, and also link the new bug to this bug. The fix looks fine to me, although I was puzzled by the following: - return - System.getProperty("java.home","") + File.separator + - "lib" + File.separator + "fonts" + File.separator; + return System.getProperty("java.home","") + File.separator + + "lib" + File.separator + "fonts"; Your fix preserves existing behavior, given that the return value from the now-eliminated call to the JDKFontLookup class did not have the trailing File.separator, but I think that might be a bug given how the returned string from this method is used elsewhere in this file. Since this is preexisting, you might choose to address that as well in the follow-up bug (JDK-8198752). If so, please add a comment to that bug. +1 from me (you need a +1 from Phil as well) -- Kevin Ajit Ghaisas wrote: > > Hi Phil, > > > > All my webrev does is to replace the way of obtaining name of JDK > font directory ? and as rightly pointed by you below (first two lines > of your last reply) ? it is what is needed to get rid of dependency on > sun.font.lookup. > > I have tested it by running an OpenJDK build that doesn't contain a > lib/fonts directory using Ensemble8 sample. > > > > I got your point about Lucida Sans fonts being pointless with > openJDK & the font finding fallback code is being little dubious. > > I would like to address that separately. I have filed bug > JDK-8198752 to > handle that. > > > > Regards, > > Ajit > > > > *From:* Phil Race > *Sent:* Thursday, February 15, 2018 10:44 PM > *To:* Ajit Ghaisas > *Cc:* Kevin Rushforth; openjfx-dev at openjdk.java.net > *Subject:* Re: [11] Review request : JDK-8195806 : Eliminate > dependency on sun.font.lookup in javafx.graphics > > > > This part is probably as good as you can do > > + return System.getProperty("java.home","") + File.separator + > + "lib" + File.separator + "fonts"; > > > but if we want to support running against OpenJDK which does not have > Lucida Sans > then we need to look at the caller of getJDKFontDir() > > So going forward all of this .. > > private static final String jreDefaultFont = "Lucida Sans Regular"; > private static final String jreDefaultFontLC = "lucida sans regular"; > private static final String jreDefaultFontFile = "LucidaSansRegular.ttf"; > > .. is probably pointless. > > And if we can't find it then the first layer of fall back code is a > bit dubious > > // Normally use the JRE default font as the last fallback. > // If we can't find even that, use any platform font; > for (String font : fontToFileMap.keySet()) { > String file = findFile(font); // gets full path > fontResource = createFontResource(jreDefaultFontLC, file); > if (fontResource != null) { > break; > } > > It did not really matter in the past .. it was just to prevent NPE in an unlikely scenario .. > But if it is to be the first class way of finding this font it probably should be using > "System" instead ? But then you need to make sure we don't have a circularity in the case > that we are using this in initialiasing System. > > -phil. > > > > On 02/14/2018 09:39 PM, Ajit Ghaisas wrote: > > Hi Phil, > > > > Thanks for having a look at the changes. > > > > I have little difficulty in understanding your question. > > Are you referring to the sun.font.SunFontManager initialization? > > I am asking as it is not evident from the code changes that I have done as part of this webrev. > > > > Request your guidance in this regard. > > > > Regards, > > Ajit > > > > > > -----Original Message----- > > From: Philip Race > > Sent: Wednesday, February 14, 2018 12:52 PM > > To: Ajit Ghaisas > > Cc: Kevin Rushforth; openjfx-dev at openjdk.java.net > > Subject: Re: [11] Review request : JDK-8195806 : Eliminate dependency on sun.font.lookup in javafx.graphics > > > > Well that removes the dependency but how are you fixing the problem of how else to find the font ? > > There needs to be alternate code or you need to go back to see what would happen if some code tried to locate that font and how it would fail. > > > > -phil. > > > > On 2/13/18, 11:11 PM, Ajit Ghaisas wrote: > > Hi Kevin, Phil, > > > > Request you to review following fix : > > > > Issue : https://bugs.openjdk.java.net/browse/JDK-8195806 > > > > Fix : > > http://cr.openjdk.java.net/~aghaisas/fx/8195806/webrev.0/ > > > > Regards, > > Ajit > > > From ank.cpp at gmail.com Wed Feb 28 05:04:39 2018 From: ank.cpp at gmail.com (ankit srivastav) Date: Wed, 28 Feb 2018 10:34:39 +0530 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5A95C556.7020503@oracle.com> References: <5A820EF4.6020409@oracle.com> <5A95C556.7020503@oracle.com> Message-ID: Dear Kevin, I will get back to you on this shortly with substantial claims. --Ankit On 28 Feb 2018 2:23 a.m., "Kevin Rushforth" wrote: > Hi Ankit, > > In response to your veto, I took the opportunity to look at the the list > of changes, and believe that my earlier nomination of Rajath to OpenJFX > Project Committer was justified, if perhaps barely so. > > While there is no objective criteria by which one can say a particular > changeset is worth 0.5 of a fix, we do often look at 2 to 4 trivial fixes > or test-only fixes to "make up the difference" in case only 6 or 7 are > deemed "significant". This is why we usually want 10 or 12 fixes before we > nominate someone for Committer -- to avoid quibbling over whether one or > two are worthy of being counted. > > Rather than respond to each of your comments individually (although I do > have one point below), I will instead list the fixes I consider significant. > > In looking at the list of fixes again, I would consider the following 7 > non-test fixes to be significant, even though several of them were only a > few lines of product code changed: > > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/3d5c22069d1f > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/5a3cc1b5bb22 > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/674513271a88 > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dc2963c3f7d1 (see > comment below) > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/9f43fb83e989 > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dedd5afd753e > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/cfa038af148b > > In all cases there needed to be an analysis, a fix, and testing to ensure > that the bug was fixed without introducing a regression. As for your > assertion about his part of the collaborative fix to upgrade WebKit to > v605.1, JDK-8187483 (changeset dc2963c3f7d1), you make an unsubstantiated > claim regarding his contribution. As he did contribute to that fix, I don't > see any reason to question how significant it was. > > In addition to the above 7, and excluding JDK-8185314 (the removal of > unused files, which I would agree does not count at all), the other three > test fixes are in my opinion enough justify the nomination. > > I would finally point out that Rajath contributed three additional test > fixes during the two week voting period, for a new total of 14 changesets > (13 excluding the unused file removal). > > Please respond to the list as to whether you feel the additional three > test fixes, along with my additional explanation, is enough to satisfy your > concerns over this nomination, and if not, why not. I would like to put the > nomination forward again for a vote once the objections are resolved. > > Thank you. > > -- Kevin > > > ankit srivastav wrote: > > NO, > > Please go through the table, all the points accumulated are not even more > then 7. > I have given reasons for my points. > > > *age* > > *author* > > *description* > > Points > > Reason > > 8 days ago > > rkamath > > 8196802: 3D unit tests listed as pass although they are actually skipped > > > 0.5 > > Test file, not a direct impact-able code change in product. > > 10 days ago > > rkamath > > 8089454: [HTMLEditor] selection removes CENTER alignment > > > 0.5 > > A very small change, why I?m saying so, as the file modified gets called > directly from the APP written. No debugging/a little is required to make > the change, which actually defies the purpose of getting knowledge of the > product. > > 13 days ago > > rkamath > > 8196615: Skip 3D unit tests on system without 3D capability > > > 0.5 > > Changes in Test file, not a direct impact-able code change in product. > > 4 weeks ago > > rkamath > > 8165459: HTMLEditor: clipboard toolbar buttons are disabled unexpectedly > > > 0.5 > > A very small change, why I?m saying so, as the file modified gets called > directly from the APP written. No debugging/a little is required to make > the change, which actually defies the purpose of getting knowledge of the > product. > > 7 weeks ago > > rkamath > > 8088925: Non opaque background cause NumberFormatException > > > 0.5 > > A very small change, why I?m saying so, as the file modified gets called > directly from the APP written. No debugging/a little is required to make > the change, which actually defies the purpose of getting knowledge of the > product. > > 2 months ago > > rkamath > > 8090011: 'tab' key makes control loose focus > > jdk-10+36 > > 0.5 > > A very small change, why I?m saying so, as the file modified gets called > directly from the APP written. No debugging/a little is required to make > the change, which actually defies the purpose of getting knowledge of the > product. > > *age* > > *author* > > *description* > > Points > > Reason > > 2 months ago > > mbilla > > 8187483: Update to 605.1 version of WebKit > > > 0 > > Unless you directly point what changes you have made in the patch I will > count it has 0. Most probably you have made changes for DRT, which even a > tester can do. Moving DRT is a non technical task, requires no technical > skills. > > 3 months ago > > mbilla > > 8187928: [WebView] Images copied from clipboard not written in source file > format > > > 1 > > > 4 months ago > > ghb > > 8178290: Intermittent test failure in test.com.sun.webkit.network. > CookieTest > > jdk-10+29 > > 0.5 > > Changes in Test file, not a direct impact-able code change in product. > > 4 months ago > > mbilla > > 8187726: [WebView] Copy and Paste of Image not resulting in expected > behavior > > jdk-10+27 > > 1 > > > 4 months ago > > mbilla > > 8187671: [WebView] Drag and Drop of text or html results in an image > > > 1 > > > 5 months ago > > ghb > > 8089124: HTML5: Number input allows non-numeric input > > > 0.5 > > Only setting value changes. For me this kind of change was not even get > considered for Author status. > > 5 months ago > > ghb > > 8185314: Remove unused third-party python scripts from WebKit sources > > > 0 > > No actual code change, you have only removed it.It seems it was not even > getting called otherwise you must have change some other files which calls > function from these files. > > > Adding all the points, total sum = 7. > So it's a NO for me. > I think you have to solve at least 3 more issues to get to the committer > status. > > *The whole idea behind becoming a committer is to get good solid product > knowledge not the issue count.* > *Quality matters over quantity.* > > Which one can only get after solving variety of issues with various level > of difficulty level. > > Here I can see you have 3 checkins for file HTMLEditorSkin.java. > This file basically gets I/P from APP written. > No/little debugging skill is require to solve the issue in this file. > > For all the test changes I have awarded 0.5 as no direct impact on product. > For DRT, moving DRT from one revision to another is just a side job. > Anybody can do that. > If I tell a 12th grader then even he can also do that. > Also I'm not sure what's the actual contribution so awarded as 0. > > Removing a file, that's too unused, no code change so 0. > > *I have awarded proper points to proper code changes.* > > @Rajath: > I know you must be under pressure (No idea from whom) to become committer, > but I can see lots of potential in you. > You should not not succumb to such pressure. > Whole idea [as I have stated above ] to become committer is get sound > product understanding, don't stop yourself to get that. > *Solve issue to get knowledge not just to show counts to other people.* > > I can one more checkin from you, but that's too I guess in Test file i.e. > 0.5 > So It seems, you are very close to your destination. > > Let me now if anyone in the community has any objection. > > --Ankit > > > > > On Tue, Feb 13, 2018 at 3:32 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I hereby nominate Rajath Kamath [1] to OpenJFX Committer. >> >> Rajath is a member of JavaFX team at Oracle, who has contributed 11 >> changesets [2][3] to OpenJFX. >> >> Votes are due by February 26, 2018. >> >> Only current OpenJFX Committers [4] 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 [5]. Nomination to a project >> Committer is described in [6]. >> >> Thanks. >> >> -- Kevin >> >> [1] http://openjdk.java.net/census#rkamath >> >> [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=2 >> 0&rev=author%28rkamath%29 >> [3] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=2 >> 0&rev=rajath.kamath >> >> [4] http://openjdk.java.net/census#openjfx >> >> [5] http://openjdk.java.net/bylaws#lazy-consensus >> >> [6] http://openjdk.java.net/projects#project-committer >> >> > From johan.vos at gluonhq.com Wed Feb 28 07:44:20 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 28 Feb 2018 07:44:20 +0000 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: <5A95EF0B.3030901@oracle.com> References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> <5A95DAE9.9030809@oracle.com> <5A95EF0B.3030901@oracle.com> Message-ID: That is the difficult point indeed. But why would a PR to OpenJFX be rejected after it was approved in the github mirror? I would assume the main reason for this is because the PR did not what it was supposed to do. In that case, it makes sense to remove the commits from the github mirror as well. I think the main thing here is that we need to be very serious about reviewing and accepting PR's in the github mirror. Accepting a PR in github does not require the *formal* process of creating webrevs etc, but it requires discussion about the issue with reviewers of OpenJFX. We have to minimize the number of times an edge case occurs, in which the discussion was pro PR first, but after it got merged into "development" new arguments are brought up against the PR. I think it would be good to have sort of a post-mortem analysis in case this happens, in order to prevent it from happening again. But as I said, if it does happen, it probably has good reasons and in that case we have to remove it from the development branch as well. I think the more common case would be that an issue is fixed on the github mirror, but not yet accepted (nor rejected) in OpenJFX, so there will be some time lag between the PR acceptance and the integration in OpenJFX. But this should not be a problem, as long as the following scenario is the main flow: The github master branch is always synced with OpenJFX, and never gets modified by other commits. The github "development" branch is where we accept PR's, that can then be send upstream. Changes from "master" are regularly merged into "development". The moment an accepted PR makes it into OpenJFX, it will be synced into "master" and merged into "development" where the merge happens silently as there are no conflicts (since development already has this code). Does that make sense? - Johan On Wed, Feb 28, 2018 at 12:51 AM Kevin Rushforth wrote: > > > Nir Lisker wrote: > > Johan's thinking was to allow Committers to approve the PR on GitHub -- >> meaning they could be merged on GitHub before an actual Review has >> happened. Are you proposing to change that? > > > What if the PR is rejected at review? We'll end up with conflicts between > the repos. And supposed someone works on a different fix and uses the > rejected PR code, how will that be committed? > > > Good questions; maybe Johan has some thoughts as to how to mitigate this? > > > -- Kevin > > > > On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> This seems a good start in formalizing the process. It will need a little >> tweaking in a couple of areas. >> >> Regarding JBS access, even though I want to relax the requirement to >> become an Author (get a JBS account), it will likely end up somewhere >> between "an intention to contribute" and "two sponsored contributions, >> already reviewed and committed". Even without this, there will necessarily >> be a gap in time between "I want to work on a bug" and getting a JBS >> account. So there is value in encouraging people to clone the GitHub >> sandbox, "kick the tires", make a PR to get feedback, etc., before they can >> access JBS directly (or even while waiting for their OCA to be processed, >> but no PRs in that case). Something to take into account. >> >> Regarding review, we will need a bit more discussion on that. I like the >> idea of the PR being logged in JBS once it is ready to be reviewed. Johan's >> thinking was to allow Committers to approve the PR on GitHub -- meaning >> they could be merged on GitHub before an actual Review has happened. Are >> you proposing to change that? It might have some advantages, but it could >> also make it harder in other areas. I'd like to hear from Johan on this. >> This reminds me that we need to continue the discussion on the general >> "Review" policy, as it is relevant here. >> >> As for whether it is merged into GitHub, I don't have a strong opinion on >> that. As you say it will be pulled into the mirror anyway (along with >> changes from reviews happening in JBS that don't first go through the >> sandbox), so maybe it doesn't matter? On the other hand there might be >> advantages to getting it into the mainline of the sandbox early? Hard to >> say. >> >> -- Kevin >> >> >> Nir Lisker wrote: >> >> Iv'e given the pipeline some thought. I'm purposely ignoring current role >> names (Author, Contributor...). My suggestions: >> >> Potential contributor wants to contribute... >> >> 1. Formal process >> a. If the issue is not in the JBS, they submit it via bugreport. >> b. They send an email on the mailing list regarding the issue (a plan, >> question on how to approach etc.) >> c. If the above effort is "deemed worthy" (whatever that means), and >> they have signed the OCA, and they then they get access to JBS. If they've >> given a GitHub account, they get access to GitHub PRs. >> d. Discussion from the mailing list is copied/linked to the JBS issue. >> Maybe if it's their issue (step a) then the Reporter field can change to >> them. >> >> This ensures that: >> * There's 1 entry point. >> * GitHub and JBS identities are linked (GitHub identity is verified). >> * Being able to comment on JBS is easier - instead of requiring 2 commits >> it requires good intentions(?) >> * Not every person on the planet has access to JBS. >> >> 2. Work process >> a. They fork the GitHub repo. >> b. They create a PR with a 2-way link to/from JBS (similar to current >> webrevs - JBS links). >> c. Discussion specifically on the patch should happen in the PR thread. >> General info on the bug (affected versions etc.) still happens in JBS. >> d. After the patch had been reviewed, it is committed to the Oracle >> repo. Since GitHub mirrors Oracle I don't think it matters if the patch is >> merged into GitHub. >> >> This ensures that: >> * It's easier to start working because the GiutHub repo is more >> convenient than the Oracle repo currently. >> * PRs and JBS issues are mutually aware. >> * The submit -> review -> commit process is streamlined. >> >> We pay a synchronization price for having 2 repos and 2 bug trackers. >> This is what I could come up with. >> >> - Nir >> >> On Fri, Feb 16, 2018 at 1:14 AM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> >>> >>> Johan Vos wrote: >>> >>> >>> >>> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>> A global reference in JBS would indeed be very good to track back the >>> work in a PR to a real issue. It can also be very useful as there are many >>> existing issues in JBS that can be referred to in future work. >>> >>> The only issue I see is that in order to create an issue in JBS, you >>> need to have "author" status, so not everyone can do this? Given the idea >>> that developers who want to create a PR also need to sign an OCA, it might >>> make sense to somehow combine the administration? >>> >>> >>> I don't think we can combine this, but I hope to be able to relax the >>> requirements to become an Author a little. The current guidelines are 2 >>> sponsored contributions [1]. >>> >>> Pending appointment as an Author, it isn't hard to submit a bug via >>> http://bugreport.java.com/ . If there is a test case, it usually gets >>> moved to the JDK project within a day or so (and I can move them sooner, if >>> needed). The bigger bother is that you can't comment in JBS on a bug you >>> didn't create, but once the bug is there, you can work on it in GutHub >>> and/or send email to the list. I'll also add any comments from contributors >>> who are not yet Authors to any bug report. >>> >>> -- Kevin >>> >>> [1] http://openjdk.java.net/projects/#project-author >>> >>> >>> - Johan >>> >>> >> > From johan.vos at gluonhq.com Wed Feb 28 07:46:16 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 28 Feb 2018 07:46:16 +0000 Subject: github contributor guidelines Message-ID: We now have a Github mirror, and good github projects require clear guidelines. Eugene created the following proposal for guidelines, based on standard guidelines from other projects, but including the link to JBS: https://github.com/johanvos/openjfxorg/blob/master/CONTRIBUTING.md Comments welcome of course. - Johan From paulrussell70 at gmail.com Wed Feb 28 08:12:01 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Wed, 28 Feb 2018 08:12:01 +0000 Subject: Update on enabling JavaFX to work with OpenJDK builds Message-ID: "I mentioned our intention to make it easier for OpenJFX to be built, tested, and run with OpenJDK builds that don't already contain javafx.* modules." +1 Great From bourges.laurent at gmail.com Wed Feb 28 08:52:37 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 28 Feb 2018 09:52:37 +0100 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> <5A95DAE9.9030809@oracle.com> <5A95EF0B.3030901@oracle.com> Message-ID: Johan, I am following the long discussion and I mostly agree what was said. Maybe it is time to start working on github on few minor / trivial bugs... to test all the new process. I propose to extract few JBS bugs (small) with high ROI (agile /scrum approach) and create shadow copies into github issues (id, title, short description & JBS LINK) to be proposed to the jfx community. That would become our backlog that can be managed in a kanban board (github project). Moreover it would be awesome if such board would gather the activity of both oracle & community people on OpenJFX. Once somebody wants to work on one issue, just comment on the github issue and start working in your fork, make PR... Adopting this method, anybody will know publicly what's going on and it would reduce the risk of conflicts (code merge).... My 2 cents... Let's go on, "We are the champions..." Laurent Le 28 f?vr. 2018 9:15 AM, "Johan Vos" a ?crit : That is the difficult point indeed. But why would a PR to OpenJFX be rejected after it was approved in the github mirror? I would assume the main reason for this is because the PR did not what it was supposed to do. In that case, it makes sense to remove the commits from the github mirror as well. I think the main thing here is that we need to be very serious about reviewing and accepting PR's in the github mirror. Accepting a PR in github does not require the *formal* process of creating webrevs etc, but it requires discussion about the issue with reviewers of OpenJFX. We have to minimize the number of times an edge case occurs, in which the discussion was pro PR first, but after it got merged into "development" new arguments are brought up against the PR. I think it would be good to have sort of a post-mortem analysis in case this happens, in order to prevent it from happening again. But as I said, if it does happen, it probably has good reasons and in that case we have to remove it from the development branch as well. I think the more common case would be that an issue is fixed on the github mirror, but not yet accepted (nor rejected) in OpenJFX, so there will be some time lag between the PR acceptance and the integration in OpenJFX. But this should not be a problem, as long as the following scenario is the main flow: The github master branch is always synced with OpenJFX, and never gets modified by other commits. The github "development" branch is where we accept PR's, that can then be send upstream. Changes from "master" are regularly merged into "development". The moment an accepted PR makes it into OpenJFX, it will be synced into "master" and merged into "development" where the merge happens silently as there are no conflicts (since development already has this code). Does that make sense? - Johan On Wed, Feb 28, 2018 at 12:51 AM Kevin Rushforth wrote: > > > Nir Lisker wrote: > > Johan's thinking was to allow Committers to approve the PR on GitHub -- >> meaning they could be merged on GitHub before an actual Review has >> happened. Are you proposing to change that? > > > What if the PR is rejected at review? We'll end up with conflicts between > the repos. And supposed someone works on a different fix and uses the > rejected PR code, how will that be committed? > > > Good questions; maybe Johan has some thoughts as to how to mitigate this? > > > -- Kevin > > > > On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> This seems a good start in formalizing the process. It will need a little >> tweaking in a couple of areas. >> >> Regarding JBS access, even though I want to relax the requirement to >> become an Author (get a JBS account), it will likely end up somewhere >> between "an intention to contribute" and "two sponsored contributions, >> already reviewed and committed". Even without this, there will necessarily >> be a gap in time between "I want to work on a bug" and getting a JBS >> account. So there is value in encouraging people to clone the GitHub >> sandbox, "kick the tires", make a PR to get feedback, etc., before they can >> access JBS directly (or even while waiting for their OCA to be processed, >> but no PRs in that case). Something to take into account. >> >> Regarding review, we will need a bit more discussion on that. I like the >> idea of the PR being logged in JBS once it is ready to be reviewed. Johan's >> thinking was to allow Committers to approve the PR on GitHub -- meaning >> they could be merged on GitHub before an actual Review has happened. Are >> you proposing to change that? It might have some advantages, but it could >> also make it harder in other areas. I'd like to hear from Johan on this. >> This reminds me that we need to continue the discussion on the general >> "Review" policy, as it is relevant here. >> >> As for whether it is merged into GitHub, I don't have a strong opinion on >> that. As you say it will be pulled into the mirror anyway (along with >> changes from reviews happening in JBS that don't first go through the >> sandbox), so maybe it doesn't matter? On the other hand there might be >> advantages to getting it into the mainline of the sandbox early? Hard to >> say. >> >> -- Kevin >> >> >> Nir Lisker wrote: >> >> Iv'e given the pipeline some thought. I'm purposely ignoring current role >> names (Author, Contributor...). My suggestions: >> >> Potential contributor wants to contribute... >> >> 1. Formal process >> a. If the issue is not in the JBS, they submit it via bugreport. >> b. They send an email on the mailing list regarding the issue (a plan, >> question on how to approach etc.) >> c. If the above effort is "deemed worthy" (whatever that means), and >> they have signed the OCA, and they then they get access to JBS. If they've >> given a GitHub account, they get access to GitHub PRs. >> d. Discussion from the mailing list is copied/linked to the JBS issue. >> Maybe if it's their issue (step a) then the Reporter field can change to >> them. >> >> This ensures that: >> * There's 1 entry point. >> * GitHub and JBS identities are linked (GitHub identity is verified). >> * Being able to comment on JBS is easier - instead of requiring 2 commits >> it requires good intentions(?) >> * Not every person on the planet has access to JBS. >> >> 2. Work process >> a. They fork the GitHub repo. >> b. They create a PR with a 2-way link to/from JBS (similar to current >> webrevs - JBS links). >> c. Discussion specifically on the patch should happen in the PR thread. >> General info on the bug (affected versions etc.) still happens in JBS. >> d. After the patch had been reviewed, it is committed to the Oracle >> repo. Since GitHub mirrors Oracle I don't think it matters if the patch is >> merged into GitHub. >> >> This ensures that: >> * It's easier to start working because the GiutHub repo is more >> convenient than the Oracle repo currently. >> * PRs and JBS issues are mutually aware. >> * The submit -> review -> commit process is streamlined. >> >> We pay a synchronization price for having 2 repos and 2 bug trackers. >> This is what I could come up with. >> >> - Nir >> >> On Fri, Feb 16, 2018 at 1:14 AM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> >>> >>> Johan Vos wrote: >>> >>> >>> >>> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>> A global reference in JBS would indeed be very good to track back the >>> work in a PR to a real issue. It can also be very useful as there are many >>> existing issues in JBS that can be referred to in future work. >>> >>> The only issue I see is that in order to create an issue in JBS, you >>> need to have "author" status, so not everyone can do this? Given the idea >>> that developers who want to create a PR also need to sign an OCA, it might >>> make sense to somehow combine the administration? >>> >>> >>> I don't think we can combine this, but I hope to be able to relax the >>> requirements to become an Author a little. The current guidelines are 2 >>> sponsored contributions [1]. >>> >>> Pending appointment as an Author, it isn't hard to submit a bug via >>> http://bugreport.java.com/ . If there is a test case, it usually gets >>> moved to the JDK project within a day or so (and I can move them sooner, if >>> needed). The bigger bother is that you can't comment in JBS on a bug you >>> didn't create, but once the bug is there, you can work on it in GutHub >>> and/or send email to the list. I'll also add any comments from contributors >>> who are not yet Authors to any bug report. >>> >>> -- Kevin >>> >>> [1] http://openjdk.java.net/projects/#project-author >>> >>> >>> - Johan >>> >>> >> > From mp at jugs.org Wed Feb 28 09:28:54 2018 From: mp at jugs.org (Michael Paus) Date: Wed, 28 Feb 2018 10:28:54 +0100 Subject: Update on enabling JavaFX to work with OpenJDK builds In-Reply-To: <5A95CBF4.3010603@oracle.com> References: <5A95CBF4.3010603@oracle.com> Message-ID: <09a3462d-8574-0cc1-2847-5c2196079274@jugs.org> Hi Kevin, thank you for the update. I appreciate this work very much because I think it is utterly important for JavaFX. While reading the past messages again I was wondering whether this will also address the following two questions. 1. Will there be a way to determine at program start-up whether JavaFX is available or not in order to be able to give a user a clear and helpful error message in case it is not? 2. Might it even be possible to treat JavaFX as just another dependency in your Maven (or whatever) project? For me personally these questions are not so important because I prefer the approach of building a native installer which already contains everything needed, but for other people in other usage scenarios these questions might be important. --Michael Am 27.02.18 um 22:21 schrieb Kevin Rushforth: > One of the big challenges in running JavaFX with OpenJDK builds is > that developers need to build OpenJDK locally themselves and include > the JavaFX bits produced by a locally-built OpenJFX build. > > In an earlier email with the subject "javafx might not be present" > [1], I mentioned our intention to make it easier for OpenJFX to be > built, tested, and run with OpenJDK builds that don't already contain > javafx.* modules. This will pave the way to allow a set of pre-built > javafx modules to be distributed that will run on top of a pre-built > OpenJDK. > > By way of update, this work is underway and can be tracked via the > following two JBS issues: > > 1. Removing internal dependencies: > > JDK-8195798 [2] : Address dependencies in javafx.* modules on internal > APIs of core modules > > The above is an umbrella task that points to several linked blocking > bugs. All of these bugs are in progress and a few are already done > (e.g., removing jdk.internal.Unsafe from Marlin). > > > 2. Enabling the building, testing, and distribution as a set of > separate modules > > JDK-8198329 [3] : Support FX build / test using JDK that doesn't > include javafx.* modules > > This one depends on the first two, but can be started in parallel, so > I plan to start on it in the next few days. > > > Let me know if you have any questions on this. > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021447.html > > [2] https://bugs.openjdk.java.net/browse/JDK-8195798 > > [3] https://bugs.openjdk.java.net/browse/JDK-8198329 > From johan at lodgon.com Wed Feb 28 10:27:36 2018 From: johan at lodgon.com (Johan Vos) Date: Wed, 28 Feb 2018 10:27:36 +0000 Subject: Update on enabling JavaFX to work with OpenJDK builds In-Reply-To: <09a3462d-8574-0cc1-2847-5c2196079274@jugs.org> References: <5A95CBF4.3010603@oracle.com> <09a3462d-8574-0cc1-2847-5c2196079274@jugs.org> Message-ID: Hi Michael, The second question is what I think should be the default. This is similar to Java EE ^^^^^^^ EE4J ^^^^ Jakarta EE development: if you want to include (some) EE API's, you include them in maven/gradle/ant, or your IDE does that for you. Same, if you want to include JavaFX API's in your project, you declare that as a dependency in maven/gradle/ant (or your IDE does that for you) and they will get downloaded from Maven Central or jcenter (if you don't have them yet). - Johan Op wo 28 feb. 2018 om 10:29 schreef Michael Paus : > Hi Kevin, > thank you for the update. I appreciate this work very much because I > think it is utterly important for JavaFX. > While reading the past messages again I was wondering whether this will > also address the following > two questions. > 1. Will there be a way to determine at program start-up whether JavaFX > is available or not in order to be able > to give a user a clear and helpful error message in case it is not? > 2. Might it even be possible to treat JavaFX as just another dependency > in your Maven (or whatever) project? > For me personally these questions are not so important because I prefer > the approach of building a native > installer which already contains everything needed, but for other people > in other usage scenarios these > questions might be important. > --Michael > > Am 27.02.18 um 22:21 schrieb Kevin Rushforth: > > One of the big challenges in running JavaFX with OpenJDK builds is > > that developers need to build OpenJDK locally themselves and include > > the JavaFX bits produced by a locally-built OpenJFX build. > > > > In an earlier email with the subject "javafx might not be present" > > [1], I mentioned our intention to make it easier for OpenJFX to be > > built, tested, and run with OpenJDK builds that don't already contain > > javafx.* modules. This will pave the way to allow a set of pre-built > > javafx modules to be distributed that will run on top of a pre-built > > OpenJDK. > > > > By way of update, this work is underway and can be tracked via the > > following two JBS issues: > > > > 1. Removing internal dependencies: > > > > JDK-8195798 [2] : Address dependencies in javafx.* modules on internal > > APIs of core modules > > > > The above is an umbrella task that points to several linked blocking > > bugs. All of these bugs are in progress and a few are already done > > (e.g., removing jdk.internal.Unsafe from Marlin). > > > > > > 2. Enabling the building, testing, and distribution as a set of > > separate modules > > > > JDK-8198329 [3] : Support FX build / test using JDK that doesn't > > include javafx.* modules > > > > This one depends on the first two, but can be started in parallel, so > > I plan to start on it in the next few days. > > > > > > Let me know if you have any questions on this. > > > > -- Kevin > > > > [1] > > > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021447.html > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8195798 > > > > [3] https://bugs.openjdk.java.net/browse/JDK-8198329 > > > > From johan.vos at gluonhq.com Wed Feb 28 10:48:10 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 28 Feb 2018 10:48:10 +0000 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> <5A95DAE9.9030809@oracle.com> <5A95EF0B.3030901@oracle.com> Message-ID: I agree with this approach. Having a small number of JBS bugs that are low hanging fruit will be good to see how the flow works. Eugene created an easy one: https://bugs.openjdk.java.net/browse/JDK-8198795 - Johan On Wed, Feb 28, 2018 at 9:52 AM Laurent Bourg?s wrote: > Johan, > I am following the long discussion and I mostly agree what was said. > > Maybe it is time to start working on github on few minor / trivial bugs... > to test all the new process. > > I propose to extract few JBS bugs (small) with high ROI (agile /scrum > approach) and create shadow copies into github issues (id, title, short > description & JBS LINK) to be proposed to the jfx community. > > That would become our backlog that can be managed in a kanban board > (github project). Moreover it would be awesome if such board would gather > the activity of both oracle & community people on OpenJFX. > > Once somebody wants to work on one issue, just comment on the github issue > and start working in your fork, make PR... > > Adopting this method, anybody will know publicly what's going on and it > would reduce the risk of conflicts (code merge).... > > My 2 cents... > > Let's go on, > "We are the champions..." > > Laurent > > > Le 28 f?vr. 2018 9:15 AM, "Johan Vos" a ?crit : > > That is the difficult point indeed. > But why would a PR to OpenJFX be rejected after it was approved in the > github mirror? I would assume the main reason for this is because the PR > did not what it was supposed to do. In that case, it makes sense to remove > the commits from the github mirror as well. > > I think the main thing here is that we need to be very serious about > reviewing and accepting PR's in the github mirror. Accepting a PR in github > does not require the *formal* process of creating webrevs etc, but it > requires discussion about the issue with reviewers of OpenJFX. > We have to minimize the number of times an edge case occurs, in which the > discussion was pro PR first, but after it got merged into "development" new > arguments are brought up against the PR. > I think it would be good to have sort of a post-mortem analysis in case > this happens, in order to prevent it from happening again. But as I said, > if it does happen, it probably has good reasons and in that case we have to > remove it from the development branch as well. > > I think the more common case would be that an issue is fixed on the github > mirror, but not yet accepted (nor rejected) in OpenJFX, so there will be > some time lag between the PR acceptance and the integration in OpenJFX. But > this should not be a problem, as long as the following scenario is the main > flow: > > The github master branch is always synced with OpenJFX, and never gets > modified by other commits. > The github "development" branch is where we accept PR's, that can then be > send upstream. Changes from "master" are regularly merged into > "development". The moment an accepted PR makes it into OpenJFX, it will be > synced into "master" and merged into "development" where the merge happens > silently as there are no conflicts (since development already has this > code). > > Does that make sense? > > - Johan > > On Wed, Feb 28, 2018 at 12:51 AM Kevin Rushforth < > kevin.rushforth at oracle.com> > wrote: > > > > > > > Nir Lisker wrote: > > > > Johan's thinking was to allow Committers to approve the PR on GitHub -- > >> meaning they could be merged on GitHub before an actual Review has > >> happened. Are you proposing to change that? > > > > > > What if the PR is rejected at review? We'll end up with conflicts between > > the repos. And supposed someone works on a different fix and uses the > > rejected PR code, how will that be committed? > > > > > > Good questions; maybe Johan has some thoughts as to how to mitigate this? > > > > > > -- Kevin > > > > > > > > On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth < > > kevin.rushforth at oracle.com> wrote: > > > >> This seems a good start in formalizing the process. It will need a > little > >> tweaking in a couple of areas. > >> > >> Regarding JBS access, even though I want to relax the requirement to > >> become an Author (get a JBS account), it will likely end up somewhere > >> between "an intention to contribute" and "two sponsored contributions, > >> already reviewed and committed". Even without this, there will > necessarily > >> be a gap in time between "I want to work on a bug" and getting a JBS > >> account. So there is value in encouraging people to clone the GitHub > >> sandbox, "kick the tires", make a PR to get feedback, etc., before they > can > >> access JBS directly (or even while waiting for their OCA to be > processed, > >> but no PRs in that case). Something to take into account. > >> > >> Regarding review, we will need a bit more discussion on that. I like the > >> idea of the PR being logged in JBS once it is ready to be reviewed. > Johan's > >> thinking was to allow Committers to approve the PR on GitHub -- meaning > >> they could be merged on GitHub before an actual Review has happened. Are > >> you proposing to change that? It might have some advantages, but it > could > >> also make it harder in other areas. I'd like to hear from Johan on this. > >> This reminds me that we need to continue the discussion on the general > >> "Review" policy, as it is relevant here. > >> > >> As for whether it is merged into GitHub, I don't have a strong opinion > on > >> that. As you say it will be pulled into the mirror anyway (along with > >> changes from reviews happening in JBS that don't first go through the > >> sandbox), so maybe it doesn't matter? On the other hand there might be > >> advantages to getting it into the mainline of the sandbox early? Hard to > >> say. > >> > >> -- Kevin > >> > >> > >> Nir Lisker wrote: > >> > >> Iv'e given the pipeline some thought. I'm purposely ignoring current > role > >> names (Author, Contributor...). My suggestions: > >> > >> Potential contributor wants to contribute... > >> > >> 1. Formal process > >> a. If the issue is not in the JBS, they submit it via bugreport. > >> b. They send an email on the mailing list regarding the issue (a plan, > >> question on how to approach etc.) > >> c. If the above effort is "deemed worthy" (whatever that means), and > >> they have signed the OCA, and they then they get access to JBS. If > they've > >> given a GitHub account, they get access to GitHub PRs. > >> d. Discussion from the mailing list is copied/linked to the JBS issue. > >> Maybe if it's their issue (step a) then the Reporter field can change to > >> them. > >> > >> This ensures that: > >> * There's 1 entry point. > >> * GitHub and JBS identities are linked (GitHub identity is verified). > >> * Being able to comment on JBS is easier - instead of requiring 2 > commits > >> it requires good intentions(?) > >> * Not every person on the planet has access to JBS. > >> > >> 2. Work process > >> a. They fork the GitHub repo. > >> b. They create a PR with a 2-way link to/from JBS (similar to current > >> webrevs - JBS links). > >> c. Discussion specifically on the patch should happen in the PR > thread. > >> General info on the bug (affected versions etc.) still happens in JBS. > >> d. After the patch had been reviewed, it is committed to the Oracle > >> repo. Since GitHub mirrors Oracle I don't think it matters if the patch > is > >> merged into GitHub. > >> > >> This ensures that: > >> * It's easier to start working because the GiutHub repo is more > >> convenient than the Oracle repo currently. > >> * PRs and JBS issues are mutually aware. > >> * The submit -> review -> commit process is streamlined. > >> > >> We pay a synchronization price for having 2 repos and 2 bug trackers. > >> This is what I could come up with. > >> > >> - Nir > >> > >> On Fri, Feb 16, 2018 at 1:14 AM, Kevin Rushforth < > >> kevin.rushforth at oracle.com> wrote: > >> > >>> > >>> > >>> Johan Vos wrote: > >>> > >>> > >>> > >>> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth < > >>> kevin.rushforth at oracle.com> wrote: > >>> > >>> A global reference in JBS would indeed be very good to track back the > >>> work in a PR to a real issue. It can also be very useful as there are > many > >>> existing issues in JBS that can be referred to in future work. > >>> > >>> The only issue I see is that in order to create an issue in JBS, you > >>> need to have "author" status, so not everyone can do this? Given the > idea > >>> that developers who want to create a PR also need to sign an OCA, it > might > >>> make sense to somehow combine the administration? > >>> > >>> > >>> I don't think we can combine this, but I hope to be able to relax the > >>> requirements to become an Author a little. The current guidelines are 2 > >>> sponsored contributions [1]. > >>> > >>> Pending appointment as an Author, it isn't hard to submit a bug via > >>> http://bugreport.java.com/ . If there is a test case, it usually gets > >>> moved to the JDK project within a day or so (and I can move them > sooner, if > >>> needed). The bigger bother is that you can't comment in JBS on a bug > you > >>> didn't create, but once the bug is there, you can work on it in GutHub > >>> and/or send email to the list. I'll also add any comments from > contributors > >>> who are not yet Authors to any bug report. > >>> > >>> -- Kevin > >>> > >>> [1] http://openjdk.java.net/projects/#project-author > >>> > >>> > >>> - Johan > >>> > >>> > >> > > > > > From mp at jugs.org Wed Feb 28 12:04:22 2018 From: mp at jugs.org (Michael Paus) Date: Wed, 28 Feb 2018 13:04:22 +0100 Subject: Update on enabling JavaFX to work with OpenJDK builds In-Reply-To: References: <5A95CBF4.3010603@oracle.com> <09a3462d-8574-0cc1-2847-5c2196079274@jugs.org> Message-ID: I think this feature would be nice to have but I doubt that it is simple to achieve because JavaFX may or may not already be included in the JDK against which you build and on which your project later runs. There needs to be a strategy how to handle all the resulting corner cases. Am 28.02.18 um 11:27 schrieb Johan Vos: > Hi Michael, > > The second question is what I think should be the default. > This is similar to Java EE ^^^^^^^ EE4J ^^^^ Jakarta EE development: > if you want to include (some) EE API's, you include them in > maven/gradle/ant, or your IDE does that for you. > > Same, if you want to include JavaFX API's in your project, you declare > that as a dependency in maven/gradle/ant (or your IDE does that for > you) and they will get downloaded from Maven Central or jcenter (if > you don't have them yet). > > - Johan > > Op wo 28 feb. 2018 om 10:29 schreef Michael Paus >: > > Hi Kevin, > thank you for the update. I appreciate this work very much because I > think it is utterly important for JavaFX. > While reading the past messages again I was wondering whether this > will > also address the following > two questions. > 1. Will there be a way to determine at program start-up whether JavaFX > is available or not in order to be able > to give a user a clear and helpful error message in case it is not? > 2. Might it even be possible to treat JavaFX as just another > dependency > in your Maven (or whatever) project? > For me personally these questions are not so important because I > prefer > the approach of building a native > installer which already contains everything needed, but for other > people > in other usage scenarios these > questions might be important. > --Michael > > Am 27.02.18 um 22:21 schrieb Kevin Rushforth: > > One of the big challenges in running JavaFX with OpenJDK builds is > > that developers need to build OpenJDK locally themselves and include > > the JavaFX bits produced by a locally-built OpenJFX build. > > > > In an earlier email with the subject "javafx might not be present" > > [1], I mentioned our intention to make it easier for OpenJFX to be > > built, tested, and run with OpenJDK builds that don't already > contain > > javafx.* modules. This will pave the way to allow a set of pre-built > > javafx modules to be distributed that will run on top of a pre-built > > OpenJDK. > > > > By way of update, this work is underway and can be tracked via the > > following two JBS issues: > > > > 1. Removing internal dependencies: > > > > JDK-8195798 [2] : Address dependencies in javafx.* modules on > internal > > APIs of core modules > > > > The above is an umbrella task that points to several linked blocking > > bugs. All of these bugs are in progress and a few are already done > > (e.g., removing jdk.internal.Unsafe from Marlin). > > > > > > 2. Enabling the building, testing, and distribution as a set of > > separate modules > > > > JDK-8198329 [3] : Support FX build / test using JDK that doesn't > > include javafx.* modules > > > > This one depends on the first two, but can be started in > parallel, so > > I plan to start on it in the next few days. > > > > > > Let me know if you have any questions on this. > > > > -- Kevin > > > > [1] > > > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021447.html > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8195798 > > > > [3] https://bugs.openjdk.java.net/browse/JDK-8198329 > > > From kevin.rushforth at oracle.com Wed Feb 28 15:32:56 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 28 Feb 2018 07:32:56 -0800 Subject: Update on enabling JavaFX to work with OpenJDK builds In-Reply-To: References: <5A95CBF4.3010603@oracle.com> <09a3462d-8574-0cc1-2847-5c2196079274@jugs.org> Message-ID: <5A96CBA8.8090901@oracle.com> This seems reasonable to me as well: integrating the JavaFX modules into whatever dependency manager you are using seems like a good thing. -- Kevin Johan Vos wrote: > Hi Michael, > > The second question is what I think should be the default. > This is similar to Java EE ^^^^^^^ EE4J ^^^^ Jakarta EE development: if you > want to include (some) EE API's, you include them in maven/gradle/ant, or > your IDE does that for you. > > Same, if you want to include JavaFX API's in your project, you declare that > as a dependency in maven/gradle/ant (or your IDE does that for you) and > they will get downloaded from Maven Central or jcenter (if you don't have > them yet). > > - Johan > > Op wo 28 feb. 2018 om 10:29 schreef Michael Paus : > > >> Hi Kevin, >> thank you for the update. I appreciate this work very much because I >> think it is utterly important for JavaFX. >> While reading the past messages again I was wondering whether this will >> also address the following >> two questions. >> 1. Will there be a way to determine at program start-up whether JavaFX >> is available or not in order to be able >> to give a user a clear and helpful error message in case it is not? >> 2. Might it even be possible to treat JavaFX as just another dependency >> in your Maven (or whatever) project? >> For me personally these questions are not so important because I prefer >> the approach of building a native >> installer which already contains everything needed, but for other people >> in other usage scenarios these >> questions might be important. >> --Michael >> >> Am 27.02.18 um 22:21 schrieb Kevin Rushforth: >> >>> One of the big challenges in running JavaFX with OpenJDK builds is >>> that developers need to build OpenJDK locally themselves and include >>> the JavaFX bits produced by a locally-built OpenJFX build. >>> >>> In an earlier email with the subject "javafx might not be present" >>> [1], I mentioned our intention to make it easier for OpenJFX to be >>> built, tested, and run with OpenJDK builds that don't already contain >>> javafx.* modules. This will pave the way to allow a set of pre-built >>> javafx modules to be distributed that will run on top of a pre-built >>> OpenJDK. >>> >>> By way of update, this work is underway and can be tracked via the >>> following two JBS issues: >>> >>> 1. Removing internal dependencies: >>> >>> JDK-8195798 [2] : Address dependencies in javafx.* modules on internal >>> APIs of core modules >>> >>> The above is an umbrella task that points to several linked blocking >>> bugs. All of these bugs are in progress and a few are already done >>> (e.g., removing jdk.internal.Unsafe from Marlin). >>> >>> >>> 2. Enabling the building, testing, and distribution as a set of >>> separate modules >>> >>> JDK-8198329 [3] : Support FX build / test using JDK that doesn't >>> include javafx.* modules >>> >>> This one depends on the first two, but can be started in parallel, so >>> I plan to start on it in the next few days. >>> >>> >>> Let me know if you have any questions on this. >>> >>> -- Kevin >>> >>> [1] >>> >>> >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021447.html >> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8195798 >>> >>> [3] https://bugs.openjdk.java.net/browse/JDK-8198329 >>> >>> >> From kevin.rushforth at oracle.com Wed Feb 28 15:46:25 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 28 Feb 2018 07:46:25 -0800 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> <5A95DAE9.9030809@oracle.com> <5A95EF0B.3030901@oracle.com> Message-ID: <5A96CED1.2060801@oracle.com> Hi Johan, Your points all make sense to me. In that case, we need to make the policy for approving PRs such that it meets the code review criteria (which is still something we need to formalize) -- meaning that a "Reviewer" (or more in the case of larger changes) needs to review it and not just any "Committer". If we do that, then I there should be no cause for rejected reviews, since it will have already been "Reviewed". -- Kevin Johan Vos wrote: > That is the difficult point indeed. > But why would a PR to OpenJFX be rejected after it was approved in the > github mirror? I would assume the main reason for this is because the > PR did not what it was supposed to do. In that case, it makes sense to > remove the commits from the github mirror as well. > > I think the main thing here is that we need to be very serious about > reviewing and accepting PR's in the github mirror. Accepting a PR in > github does not require the *formal* process of creating webrevs etc, > but it requires discussion about the issue with reviewers of OpenJFX. > We have to minimize the number of times an edge case occurs, in which > the discussion was pro PR first, but after it got merged into > "development" new arguments are brought up against the PR. > I think it would be good to have sort of a post-mortem analysis in > case this happens, in order to prevent it from happening again. But as > I said, if it does happen, it probably has good reasons and in that > case we have to remove it from the development branch as well. > > I think the more common case would be that an issue is fixed on the > github mirror, but not yet accepted (nor rejected) in OpenJFX, so > there will be some time lag between the PR acceptance and the > integration in OpenJFX. But this should not be a problem, as long as > the following scenario is the main flow: > > The github master branch is always synced with OpenJFX, and never gets > modified by other commits. > The github "development" branch is where we accept PR's, that can then > be send upstream. Changes from "master" are regularly merged into > "development". The moment an accepted PR makes it into OpenJFX, it > will be synced into "master" and merged into "development" where the > merge happens silently as there are no conflicts (since development > already has this code). > > Does that make sense? > > - Johan > > On Wed, Feb 28, 2018 at 12:51 AM Kevin Rushforth > > wrote: > > > > Nir Lisker wrote: >> >> Johan's thinking was to allow Committers to approve the PR on >> GitHub -- meaning they could be merged on GitHub before an >> actual Review has happened. Are you proposing to change that? >> >> >> What if the PR is rejected at review? We'll end up with conflicts >> between the repos. And supposed someone works on a different fix >> and uses the rejected PR code, how will that be committed? > > Good questions; maybe Johan has some thoughts as to how to > mitigate this? > > > -- Kevin > > >> >> On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth >> > >> wrote: >> >> This seems a good start in formalizing the process. It will >> need a little tweaking in a couple of areas. >> >> Regarding JBS access, even though I want to relax the >> requirement to become an Author (get a JBS account), it will >> likely end up somewhere between "an intention to contribute" >> and "two sponsored contributions, already reviewed and >> committed". Even without this, there will necessarily be a >> gap in time between "I want to work on a bug" and getting a >> JBS account. So there is value in encouraging people to clone >> the GitHub sandbox, "kick the tires", make a PR to get >> feedback, etc., before they can access JBS directly (or even >> while waiting for their OCA to be processed, but no PRs in >> that case). Something to take into account. >> >> Regarding review, we will need a bit more discussion on that. >> I like the idea of the PR being logged in JBS once it is >> ready to be reviewed. Johan's thinking was to allow >> Committers to approve the PR on GitHub -- meaning they could >> be merged on GitHub before an actual Review has happened. Are >> you proposing to change that? It might have some advantages, >> but it could also make it harder in other areas. I'd like to >> hear from Johan on this. This reminds me that we need to >> continue the discussion on the general "Review" policy, as it >> is relevant here. >> >> As for whether it is merged into GitHub, I don't have a >> strong opinion on that. As you say it will be pulled into the >> mirror anyway (along with changes from reviews happening in >> JBS that don't first go through the sandbox), so maybe it >> doesn't matter? On the other hand there might be advantages >> to getting it into the mainline of the sandbox early? Hard to >> say. >> >> -- Kevin >> >> >> Nir Lisker wrote: >>> Iv'e given the pipeline some thought. I'm purposely ignoring >>> current role names (Author, Contributor...). My suggestions: >>> >>> Potential contributor wants to contribute... >>> >>> 1. Formal process >>> a. If the issue is not in the JBS, they submit it via >>> bugreport. >>> b. They send an email on the mailing list regarding the >>> issue (a plan, question on how to approach etc.) >>> c. If the above effort is "deemed worthy" (whatever that >>> means), and they have signed the OCA, and they then they get >>> access to JBS. If they've given a GitHub account, they get >>> access to GitHub PRs. >>> d. Discussion from the mailing list is copied/linked to >>> the JBS issue. Maybe if it's their issue (step a) then the >>> Reporter field can change to them. >>> >>> This ensures that: >>> * There's 1 entry point. >>> * GitHub and JBS identities are linked (GitHub identity is >>> verified). >>> * Being able to comment on JBS is easier - instead of >>> requiring 2 commits it requires good intentions(?) >>> * Not every person on the planet has access to JBS. >>> >>> 2. Work process >>> a. They fork the GitHub repo. >>> b. They create a PR with a 2-way link to/from JBS (similar >>> to current webrevs - JBS links). >>> c. Discussion specifically on the patch should happen in >>> the PR thread. General info on the bug (affected versions >>> etc.) still happens in JBS. >>> d. After the patch had been reviewed, it is committed to >>> the Oracle repo. Since GitHub mirrors Oracle I don't think >>> it matters if the patch is merged into GitHub. >>> >>> This ensures that: >>> * It's easier to start working because the GiutHub repo is >>> more convenient than the Oracle repo currently. >>> * PRs and JBS issues are mutually aware. >>> * The submit -> review -> commit process is streamlined. >>> >>> We pay a synchronization price for having 2 repos and 2 bug >>> trackers. This is what I could come up with. >>> >>> - Nir >>> >>> On Fri, Feb 16, 2018 at 1:14 AM, Kevin Rushforth >>> >> > wrote: >>> >>> >>> >>> Johan Vos wrote: >>>> >>>> >>>> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth >>>> >>> > wrote: >>>> >>>> A global reference in JBS would indeed be very good to >>>> track back the work in a PR to a real issue. It can >>>> also be very useful as there are many existing issues >>>> in JBS that can be referred to in future work. >>>> >>>> The only issue I see is that in order to create an >>>> issue in JBS, you need to have "author" status, so not >>>> everyone can do this? Given the idea that developers >>>> who want to create a PR also need to sign an OCA, it >>>> might make sense to somehow combine the administration? >>> >>> I don't think we can combine this, but I hope to be able >>> to relax the requirements to become an Author a little. >>> The current guidelines are 2 sponsored contributions [1]. >>> >>> Pending appointment as an Author, it isn't hard to >>> submit a bug via http://bugreport.java.com/ . If there >>> is a test case, it usually gets moved to the JDK project >>> within a day or so (and I can move them sooner, if >>> needed). The bigger bother is that you can't comment in >>> JBS on a bug you didn't create, but once the bug is >>> there, you can work on it in GutHub and/or send email to >>> the list. I'll also add any comments from contributors >>> who are not yet Authors to any bug report. >>> >>> -- Kevin >>> >>> [1] http://openjdk.java.net/projects/#project-author >>> >>> >>>> - Johan >>> >>> >> From kevin.rushforth at oracle.com Wed Feb 28 15:55:55 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 28 Feb 2018 07:55:55 -0800 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> <5A95DAE9.9030809@oracle.com> <5A95EF0B.3030901@oracle.com> Message-ID: <5A96D10B.2090301@oracle.com> > Eugene created an easy one: https://bugs.openjdk.java.net/browse/JDK-8198795 I pointed out some prerequisites for doing this in JBS (and Nir expressed concern as well), but yes, this might be a good one to start with. -- Kevin Johan Vos wrote: > I agree with this approach. > Having a small number of JBS bugs that are low hanging fruit will be > good to see how the flow works. > Eugene created an easy one: > https://bugs.openjdk.java.net/browse/JDK-8198795 > > - Johan > > On Wed, Feb 28, 2018 at 9:52 AM Laurent Bourg?s > > wrote: > > Johan, > I am following the long discussion and I mostly agree what was said. > > Maybe it is time to start working on github on few minor / trivial > bugs... to test all the new process. > > I propose to extract few JBS bugs (small) with high ROI (agile > /scrum approach) and create shadow copies into github issues (id, > title, short description & JBS LINK) to be proposed to the jfx > community. > > That would become our backlog that can be managed in a kanban > board (github project). Moreover it would be awesome if such board > would gather the activity of both oracle & community people on > OpenJFX. > > Once somebody wants to work on one issue, just comment on the > github issue and start working in your fork, make PR... > > Adopting this method, anybody will know publicly what's going on > and it would reduce the risk of conflicts (code merge).... > > My 2 cents... > > Let's go on, > "We are the champions..." > > Laurent > > > Le 28 f?vr. 2018 9:15 AM, "Johan Vos" > a ?crit : > > That is the difficult point indeed. > But why would a PR to OpenJFX be rejected after it was > approved in the > github mirror? I would assume the main reason for this is > because the PR > did not what it was supposed to do. In that case, it makes > sense to remove > the commits from the github mirror as well. > > I think the main thing here is that we need to be very serious > about > reviewing and accepting PR's in the github mirror. Accepting a > PR in github > does not require the *formal* process of creating webrevs etc, > but it > requires discussion about the issue with reviewers of OpenJFX. > We have to minimize the number of times an edge case occurs, > in which the > discussion was pro PR first, but after it got merged into > "development" new > arguments are brought up against the PR. > I think it would be good to have sort of a post-mortem > analysis in case > this happens, in order to prevent it from happening again. But > as I said, > if it does happen, it probably has good reasons and in that > case we have to > remove it from the development branch as well. > > I think the more common case would be that an issue is fixed > on the github > mirror, but not yet accepted (nor rejected) in OpenJFX, so > there will be > some time lag between the PR acceptance and the integration in > OpenJFX. But > this should not be a problem, as long as the following > scenario is the main > flow: > > The github master branch is always synced with OpenJFX, and > never gets > modified by other commits. > The github "development" branch is where we accept PR's, that > can then be > send upstream. Changes from "master" are regularly merged into > "development". The moment an accepted PR makes it into > OpenJFX, it will be > synced into "master" and merged into "development" where the > merge happens > silently as there are no conflicts (since development already > has this > code). > > Does that make sense? > > - Johan > > On Wed, Feb 28, 2018 at 12:51 AM Kevin Rushforth > > > wrote: > > > > > > > Nir Lisker wrote: > > > > Johan's thinking was to allow Committers to approve the PR > on GitHub -- > >> meaning they could be merged on GitHub before an actual > Review has > >> happened. Are you proposing to change that? > > > > > > What if the PR is rejected at review? We'll end up with > conflicts between > > the repos. And supposed someone works on a different fix and > uses the > > rejected PR code, how will that be committed? > > > > > > Good questions; maybe Johan has some thoughts as to how to > mitigate this? > > > > > > -- Kevin > > > > > > > > On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth < > > kevin.rushforth at oracle.com > > wrote: > > > >> This seems a good start in formalizing the process. It will > need a little > >> tweaking in a couple of areas. > >> > >> Regarding JBS access, even though I want to relax the > requirement to > >> become an Author (get a JBS account), it will likely end up > somewhere > >> between "an intention to contribute" and "two sponsored > contributions, > >> already reviewed and committed". Even without this, there > will necessarily > >> be a gap in time between "I want to work on a bug" and > getting a JBS > >> account. So there is value in encouraging people to clone > the GitHub > >> sandbox, "kick the tires", make a PR to get feedback, etc., > before they can > >> access JBS directly (or even while waiting for their OCA to > be processed, > >> but no PRs in that case). Something to take into account. > >> > >> Regarding review, we will need a bit more discussion on > that. I like the > >> idea of the PR being logged in JBS once it is ready to be > reviewed. Johan's > >> thinking was to allow Committers to approve the PR on > GitHub -- meaning > >> they could be merged on GitHub before an actual Review has > happened. Are > >> you proposing to change that? It might have some > advantages, but it could > >> also make it harder in other areas. I'd like to hear from > Johan on this. > >> This reminds me that we need to continue the discussion on > the general > >> "Review" policy, as it is relevant here. > >> > >> As for whether it is merged into GitHub, I don't have a > strong opinion on > >> that. As you say it will be pulled into the mirror anyway > (along with > >> changes from reviews happening in JBS that don't first go > through the > >> sandbox), so maybe it doesn't matter? On the other hand > there might be > >> advantages to getting it into the mainline of the sandbox > early? Hard to > >> say. > >> > >> -- Kevin > >> > >> > >> Nir Lisker wrote: > >> > >> Iv'e given the pipeline some thought. I'm purposely > ignoring current role > >> names (Author, Contributor...). My suggestions: > >> > >> Potential contributor wants to contribute... > >> > >> 1. Formal process > >> a. If the issue is not in the JBS, they submit it via > bugreport. > >> b. They send an email on the mailing list regarding the > issue (a plan, > >> question on how to approach etc.) > >> c. If the above effort is "deemed worthy" (whatever that > means), and > >> they have signed the OCA, and they then they get access to > JBS. If they've > >> given a GitHub account, they get access to GitHub PRs. > >> d. Discussion from the mailing list is copied/linked to > the JBS issue. > >> Maybe if it's their issue (step a) then the Reporter field > can change to > >> them. > >> > >> This ensures that: > >> * There's 1 entry point. > >> * GitHub and JBS identities are linked (GitHub identity is > verified). > >> * Being able to comment on JBS is easier - instead of > requiring 2 commits > >> it requires good intentions(?) > >> * Not every person on the planet has access to JBS. > >> > >> 2. Work process > >> a. They fork the GitHub repo. > >> b. They create a PR with a 2-way link to/from JBS > (similar to current > >> webrevs - JBS links). > >> c. Discussion specifically on the patch should happen in > the PR thread. > >> General info on the bug (affected versions etc.) still > happens in JBS. > >> d. After the patch had been reviewed, it is committed to > the Oracle > >> repo. Since GitHub mirrors Oracle I don't think it matters > if the patch is > >> merged into GitHub. > >> > >> This ensures that: > >> * It's easier to start working because the GiutHub repo is more > >> convenient than the Oracle repo currently. > >> * PRs and JBS issues are mutually aware. > >> * The submit -> review -> commit process is streamlined. > >> > >> We pay a synchronization price for having 2 repos and 2 bug > trackers. > >> This is what I could come up with. > >> > >> - Nir > >> > >> On Fri, Feb 16, 2018 at 1:14 AM, Kevin Rushforth < > >> kevin.rushforth at oracle.com > > wrote: > >> > >>> > >>> > >>> Johan Vos wrote: > >>> > >>> > >>> > >>> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth < > >>> kevin.rushforth at oracle.com > > wrote: > >>> > >>> A global reference in JBS would indeed be very good to > track back the > >>> work in a PR to a real issue. It can also be very useful > as there are many > >>> existing issues in JBS that can be referred to in future work. > >>> > >>> The only issue I see is that in order to create an issue > in JBS, you > >>> need to have "author" status, so not everyone can do this? > Given the idea > >>> that developers who want to create a PR also need to sign > an OCA, it might > >>> make sense to somehow combine the administration? > >>> > >>> > >>> I don't think we can combine this, but I hope to be able > to relax the > >>> requirements to become an Author a little. The current > guidelines are 2 > >>> sponsored contributions [1]. > >>> > >>> Pending appointment as an Author, it isn't hard to submit > a bug via > >>> http://bugreport.java.com/ . If there is a test case, it > usually gets > >>> moved to the JDK project within a day or so (and I can > move them sooner, if > >>> needed). The bigger bother is that you can't comment in > JBS on a bug you > >>> didn't create, but once the bug is there, you can work on > it in GutHub > >>> and/or send email to the list. I'll also add any comments > from contributors > >>> who are not yet Authors to any bug report. > >>> > >>> -- Kevin > >>> > >>> [1] http://openjdk.java.net/projects/#project-author > >>> > >>> > >>> - Johan > >>> > >>> > >> > > > > From akashche at redhat.com Wed Feb 28 18:18:25 2018 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 28 Feb 2018 18:18:25 +0000 Subject: [11] Review request: 8087581: Headless Monocle causes core dump when rendering javafx.scene.text.Text Message-ID: Hi OpenJFX developers, issue: https://bugs.openjdk.java.net/browse/JDK-8087581 webrev: http://cr.openjdk.java.net/~akasko/ojfx/8087581/webrev.01/ I am working on windows builds at Red Hat, and some time ago stumbled upon the windows-only font-related crash inside directwrite.cpp. Crash was 100% reproducible (but only with openjdk8+openjfx - not with Oracle jdk) with VocabHunter [1] project - running: gradlew :gui:test Problem appeared to be the same as logged in JDK-8087581. It was narrowed down to this call [2]. Creating COM object instance and immediately un-initializing COM seemed to be a wrong approach. Looking how COM is used in similar manner (singleton instance accessed from a single thread) in other projects [3][4], it appeared that there CoUninitialize either called on thread exit or not called at all. In the proposed patch CoUninitialize is tied to this cleanup call [5]. Please note some possible problems with this patch, that may prevent it from being accepted: - patch is tested only with openjdk-8u161 + openjfx-8u161 - I was unable to reproduce the problem with Oracle jdk - reproducer inside JDK-8087581 seems to be broken with recent jdk8 (something is wrong with headless monocle lib [6] ), I used only VocabHunter project as a reproducer - the latest openjfx build I have is from openjfx/10/rt/ repo - do not have 11 (or dev) builds yet - VocabHunter cannot be built with openjfx-10, so the gradle command above won't work with it - I bundled reproducer as a standalone JAR, but it is still not a real reproducer, as that JAR is 60MB (with guice and other libs inside) and won't run on openjfx-10 (again some headless monocle incompatibility) - fontFactory is changed to "protected" here [7], to call the dispose() on it directly from D3DPipeline; it may be better to call dispose() for any fontFactory from GraphicsPipeline (parent) , but in testing it appeared to be, that parent's dispose() is never called from D3DPipeline.dispose(), as nDispose() [8] call inside it never exits (process exits first); thus in patch fontFactory.dispose() is called before the nDispose() call [1] https://github.com/VocabHunter/VocabHunter [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/86a1b36090e4#l22.599 [3] https://hg.mozilla.org/mozilla-central/rev/a67425aa4728#l1.44 [4] https://github.com/Microsoft/Windows-driver-samples/blob/master/print/XpsRasFilter/src/BitmapHandler.cpp#L64 [5] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/375aedc5702a/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumRenderer.java#l127 [6] http://mvnrepository.com/artifact/org.testfx/openjfx-monocle [7] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/375aedc5702a/modules/javafx.graphics/src/main/java/com/sun/prism/GraphicsPipeline.java#l58 [8] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/375aedc5702a/modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DPipeline.java#l164 -- -Alex