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