I note that this isn't really the right forum for discussing the cost or
support model of JavaFX, but since the question has come up, I'll add my
2 cents.
The notion of requiring commercial vendors to pay to use the latest
feature release of JavaFX is impractical at best. As a community-driven
open-source project, one can take the sources and produce binaries from
the openjfx repo that can be distributed for free, so if someone started
charging for binaries built from those same sources, there would be no
incentive for anyone to buy them.
That leaves a support-based model, which seems more workable anyway. In
this model, using the JavaFX libraries would remain free, but
application vendors could pay for support from a commercial vendor
willing to offer it.
-- Kevin
On 9/21/2018 9:51 AM, jav...@use.startmail.com wrote:
Well a technical enforcement mechanism is impractical, it's true. What
would be involved is a commercial license- an electronic thing like
the agreement you clicked on when you downloaded the JDK from Oracle.
For people using it commercially, you just make a payment through the
usual payment processors. It's more or less an honor thing, right, but
we're an honorable lot, LOL.
I buy my IDE. I buy other tools. That's all so I can use JavaFX. It
makes no economic sense to think this manna is always going to just
fall from heaven. Let's just all pony up and put our own futures on a
financially secure footing. For us, it creates a huge amount of FUD
watching this technology stagger around from Sun to Oracle to
somewhere else because , financially, it is not perceived to pay for
its own development effort
If you need an enforcement mechanism then you could require that your
license GUID / license acknowledgment appear in your application along
with other such legal announcements. So that would be a
public-shame-based enforcement mechanism.
We have corporations, schools, research institutes, ISVs who would not
miss 50 bucks a year and it would mean everything to JavaFX.
Disregarding what each of us may think what OTHER people might think,
does anyone seriously personally object to some lightweight scheme
like this? I mean you personally- are you offended and likely to look
for an alternative on account of it? Serious question, not rhetoric
(email nukes nuances LOL).
I would feel good about it. I would be more involved, feel like I have
an ownership stake and if the resultant cash flow means we can hire
(back) some talent and ease the burden on what devs are left, then we
all benefit from fewer bugs and more features, which is what we all
want and where real money ultimately comes from, right?
Suggested donations have a less than 1% "compliance" rate.
On Friday, September 21, 2018 at 12:13 PM, Scott Palmer
<swpal...@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, jav...@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
<johnvalr...@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....@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
