Talk about OPENJFX's future

[Johan Vos]

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
https://gluonhq.com/javafx-11-release-and-support-plans/), 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 gmail.com> 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 use.startmail.com 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 gmail.com> 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 gluonhq.com> 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
> >>>> https://www.youtube.com/watch?v=Kh6K-yEp_JY)
> >>>>
> >>> 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
> https://gluonhq.com/javafx-11-early-access-on-embedded/)
> >>> - Johan
>
>