Talk about OPENJFX's future

Kevin Rushforth kevin.rushforth at
Fri Sep 21 22:22:19 UTC 2018

That seems like a very workable model to me.

-- Kevin

On 9/21/2018 12:56 PM, Johan Vos wrote:
> Adding to #2: what we try to do with gluon is increasing adoption, allow
> free development and usage, while still getting revenues to fund the
> development.
> All builds created for the latest version of JavaFX are free to use (GPL +
> CPE) for private and commercial usage.
> With the Gluon JavaFX Enterprise support (see
>, we provide LTS
> to companies that don't want to jump to the latest versions with every
> release but still require updates.
> If you go from JavaFX 11 to 12, 13, 14,... you'll always get a free,
> high-quality, supported build. If for some reasons you need to stick with
> JavaFX 11 but still want critical updates, you can buy Gluon JavaFX
> Enterprise support and you will get builds including critical patches.
> This is similar to the Java SE support: if you follow the release cadence
> and use the latest and greatest version, you're totally fine. If you don't
> want to do that, that's fine. If you want to stay on an old version but
> still get regular high-quality updates, you can get commercial support.
> - Johan
> On Fri, Sep 21, 2018 at 9:43 PM Scott Palmer <swpalmer at> wrote:
>> I would focus on bug-free functionality and *performance* over new
>> features.  Layout and CSS issues still seem to have a significant drag on
>> JavaFX rendering.
>> Much of the new features I want are somewhat motivated by performance
>> anyway. E.g. getting native window handles… to handle performance issues
>> with 3D and video overlays.
>> I think #2, while cheap, will severely harm JavaFX adoption just from the
>> added nuisance alone.  Is there a precedent where this has worked out?
>> Regards,
>> Scott
>>> On Sep 21, 2018, at 12:04 PM, javafx at wrote:
>>> Two items  for us
>>> 1) focus on bug-free functionality over new features.
>>> 2) require a U.S. $50.00 a year fee per corporate entity for commercial
>> application usage. This is very reasonable and  would finally secure
>> JavaFX's future as a development platform.
>>> I feel without 2) above we will find ourselves wandering around
>> cyberspace hoping for a benefactor or the charity of volunteers and their
>> spare time.
>>> hth.
>>> On Friday, September 21, 2018 at 5:52 AM, John-Val Rose <
>> johnvalrose at> wrote:
>>>> That video is typical marketing “smoke and mirrors”.
>>>> With no access to the code of either app, it is simply unfair and
>> disingenuous to claim a performance advantage.
>>>> I am certain I could post an almost identical comparison video where
>> the results would be the complete opposite.
>>>> Yeah, good programmers can write slow code (especially if you have a
>> motive)...
>>>> On 21 Sep 2018, at 19:29, Johan Vos <johan.vos at> wrote:
>>>>>> We can't defeat QT in performance, but we can defeat it at
>> applicability
>>>>>> and just don't get too far behind QT in performance. (bad example
>>>>> That video demonstrates the creator has absolutely no development
>> skills in
>>>>> Java, or he intentionally misleads the viewer. I leave it to the
>> reader to
>>>>> judge what would be worst.
>>>>> I am not going to make performance statements without numbers, but my
>> first
>>>>> observations using JavaFX 11 with the Bellsoft Liberica VM are very
>>>>> encouraging (see
>>>>> - Johan

More information about the openjfx-dev mailing list