Talk about OPENJFX's future

[a***@163.com]

First, I call JavaFX/OpenJFX JFX here.

I'm not an expert at JFX, I just read half of a book about JFX and be amazed by it. Then I began to take some attention to JFX and be interested in it. JFX is separated from JDK, well the news sound not so bad actually. The fact is JFX isn't well-known, we sound little even noting about JFX in school and lots of books which just teach awt/swing. Thus, the "bad" news at least can let some guys notice what JFX is (*^_^*). And Here I can here only talk about the future of JFX.

Why we use a technology? The answer is simple, just the technology is useful in some application scenarios and better than the others.

What are JFX's application scenarios? It is written in https://github.com/javafxports/openjdk-jfx, the mirror of the OpenJFX repository:

OpenJFX is an open source, next-generation client application platform for desktop, mobile and embedded systems based on JavaSE. ....BALABALABALA


So JFX's scenarios are desktop, mobile, and embedded systems, let us analyze one-by-one.



1. Desktop:

competitors：QT，WebApp

advantages：Write once run everywhere(solve Why Linux haven't XXX?). Easy than QT, build beautiful client quickly. Because of desktop's hardware higher and higher. We can regard JFX'performance same as QT.

limitations：Well, nowadays WebApp are everywhere, a browser can solve almost all of the problem, the desktop market is smaller and smaller, though client app suite for some special scenarios, these scenarios are too small to feed many programmers.


2. Mobile:

competitors：ReactNative, Flutter

limitations：Though ReactNative own many denounce, it also own huge developers and full toolchain. Flutter is the other technology which bright me. With beautiful UI and handy language Dart( similar to java ). It is perfect in my eyes.

advantages：I haven't used JFX in mobile so I can't see what advantage JFX have. If JFX can perform well like Flutter, well, JFX would have a good future in Mobile.




3.Embedded systems:

competitors：QT

advantages：The embedded device is a big market, The car, all the screen in your home in the future(Internet of things(IoT)), the public service devices like the vending machine and other interactive devices, so embedded absolutely is a huge enough market which can feed many JFX programmers. Compare with QT, same as Desktop, JFX can quickly and easily write beautiful app although QT can write the beautiful app too, it needs higher technological level and more time.

limitations：Performance, the inherent shortage(VM) let JFX can't run at some performance sensitive scenarios like plant/workshop control system or spacecraft control system ~~~///(^v^)\\\~~~，but with the development of science and technology (hardware upgrade), lots of devices have higher performance, so It is highly feasible by using JFX to build for-civil-use/home application. 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

What are you think about? Let's talk about it and draw a brilliant future for JFX.

If this mail has no intention of offending someone, I hope you can forgive me.



Thank all those who contribute to JFX.

[Johan Vos]

Post by a***@163.com
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
http://youtu.be/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

[John-Val Rose]

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)...

Post by Johan Vos

Post by a***@163.com
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
http://youtu.be/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

[a***@163.com]

Well, it is happy hear that JavaFX perform well in embedded, my original intention isn’t condemn this video,

just for an example, though it is little ridiculous..
发件人: John-Val Rose
发送时间: 2018年9月21日 17:52
收件人: Johan Vos
抄送: ***@163.com; openjfx-***@openjdk.java.net
主题: Re: Talk about OPENJFX's future

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)...

Post by Johan Vos

Post by a***@163.com
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
http://youtu.be/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

[j***@use.startmail.com]

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
<***@gmail.com> wrote:
 

Post by John-Val Rose
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)...
 

Post by Johan Vos

Post by a***@163.com
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
http://youtu.be/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

[Scott Palmer]

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

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.

Post by John-Val Rose
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)...

Post by Johan Vos

Post by a***@163.com
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
http://youtu.be/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

[j***@use.startmail.com]

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
<***@gmail.com> wrote:
 

Post by Scott Palmer
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
 

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
 

Post by John-Val Rose
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)...
 

Post by Johan Vos

Post by a***@163.com
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
http://youtu.be/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

[Kevin Rushforth]

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

Post by j***@use.startmail.com
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

Post by Scott Palmer
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

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

Post by John-Val Rose
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)...

Post by Johan Vos

Post by a***@163.com
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
http://youtu.be/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

[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

Post by Scott Palmer
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

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 <

Post by John-Val Rose
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.

Post by John-Val Rose
I am certain I could post an almost identical comparison video where

the results would be the complete opposite.

Post by John-Val Rose
Yeah, good programmers can write slow code (especially if you have a

motive)...

Post by John-Val Rose

Post by Johan Vos

Post by a***@163.com
We can't defeat QT in performance, but we can defeat it at

applicability

Post by John-Val Rose

Post by Johan Vos

Post by a***@163.com
and just don't get too far behind QT in performance. (bad example
http://youtu.be/Kh6K-yEp_JY

That video demonstrates the creator has absolutely no development

skills in

Post by John-Val Rose

Post by Johan Vos
Java, or he intentionally misleads the viewer. I leave it to the

reader to

Post by John-Val Rose

Post by Johan Vos
judge what would be worst.
I am not going to make performance statements without numbers, but my

first

Post by John-Val Rose

Post by Johan Vos
observations using JavaFX 11 with the Bellsoft Liberica VM are very
encouraging (see

https://gluonhq.com/javafx-11-early-access-on-embedded/)

Post by John-Val Rose

Post by Johan Vos
- Johan

[Kevin Rushforth]

That seems like a very workable model to me.

-- Kevin

Post by 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

Post by Scott Palmer
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

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 <

Post by John-Val Rose
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.

Post by John-Val Rose
I am certain I could post an almost identical comparison video where

the results would be the complete opposite.

Post by John-Val Rose
Yeah, good programmers can write slow code (especially if you have a

motive)...

Post by John-Val Rose

Post by Johan Vos

Post by a***@163.com
We can't defeat QT in performance, but we can defeat it at

applicability

Post by John-Val Rose

Post by Johan Vos

Post by a***@163.com
and just don't get too far behind QT in performance. (bad example
http://youtu.be/Kh6K-yEp_JY

That video demonstrates the creator has absolutely no development

skills in

Post by John-Val Rose

Post by Johan Vos
Java, or he intentionally misleads the viewer. I leave it to the

reader to

Post by John-Val Rose

Post by Johan Vos
judge what would be worst.
I am not going to make performance statements without numbers, but my

first

Post by John-Val Rose

Post by Johan Vos
observations using JavaFX 11 with the Bellsoft Liberica VM are very
encouraging (see

https://gluonhq.com/javafx-11-early-access-on-embedded/)

Post by John-Val Rose

Post by Johan Vos
- Johan