[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Talk about OPENJFX's future
From:       Kevin Rushforth <kevin.rushforth () oracle ! com>
Date:       2018-09-21 22:22:19
Message-ID: e2d85488-9786-d0bc-a642-4ccd5c67f7f8 () oracle ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]