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 <paulrussell70 at gmail.com> 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, <openjfx-dev-request at openjdk.java.net> wrote:

Send openjfx-dev mailing list submissions to
openjfx-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
or, via email, send a message with subject or body 'help' to
openjfx-dev-request at openjdk.java.net

You can reach the person managing the list at
openjfx-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openjfx-dev digest..."


Today's Topics:

1. 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 <kevin.rushforth at oracle.com>
To: "openjfx-dev at openjdk.java.net" <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 <mike.ennen at gmail.com>
To: Kevin Rushforth <kevin.rushforth at oracle.com>
Cc: "openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>
Subject: Re: More community participation in JavaFX
Message-ID:
<CAOTPd66cX4Fe-UOE-VM-BuQqDBRWDG11S3qP+54X-
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 <rsteiger at ensemblesoft.net>
To: openjfx-dev at openjdk.java.net
Subject: Re: More community participation in JavaFX
Message-ID: <feaca3e4-1cda-dd1d-4d13-18d4f7bca656 at ensemblesoft.net>
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
******************************************