[11] Review Request - JDK-8196615: Skip 3D unit tests on system without 3D capability

[Rajath Kamath]

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

Re: More community participation in JavaFX

[John-Val Rose]

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
> >
>

Re: More community participation in JavaFX

[Stephen Desofi]

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
> 

Re: More community participation in JavaFX

[Kevin Rushforth]

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

Re: More community participation in JavaFX

[Stephen Desofi]

+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@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-requ...@openjdk.java.net

You can reach the person managing the list at
openjfx-dev-ow...@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)

JavaFX embed API

[Александр Бруй]

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?

Re: More community participation in JavaFX

[Michael Paus]

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

Re: More community participation in JavaFX

[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

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

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.rushfo...@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.rushfo...@oracle.com> wrote:
>>
>>> Oh, I see. You are pointing to the exploded modules  for the JDK in
>>> build/X/jdk rather than the JDK image in build/X/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.rushfo...@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 
 

[11] Review request for 8196605: Robot tests fail on Windows platforms if terminal windows are in the way

[Murali Billa]

 

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

Re: More community participation in JavaFX

[Chris Newland]

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.
...

Re: More community participation in JavaFX

[Paul Ray Russell]

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@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-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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@openjdk.java.net" 
> Subject: More community participation in JavaFX
> Message-ID: <5a73a220.7030...@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 

Re: More community participation in JavaFX

[John-Val Rose]

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 
>>