Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Jaroslav Tulach <ja...@gmail.com>]

> "Oracle has begun conversations with interested parties in the Java

> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
>>>> referenced timeframes."
>>>>
>>>
>>
The official announcement is here and people are finally starting to
realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
will sponsor development of anything new for these technologies. Even if
they get transfered to their new owners, they will be in maintenance mode:
Bugfixes and little features. No bigger changes - no new rendering
pipelines using new nifty features of graphics cards. Just sustaining. I've
been explaining this would happen since 2012.

To help us out of this situation and save Java as a programming language I
dedicated my days to smoothing out interoperability between Java and
JavaScript with the goal to reuse the most flexible and portable rendering
system of these days: the browser. My work has already been donated to
Apache, see: https://github.com/apache/incubator-netbeans-html4j - let's
use it to build new features of NetBeans and other future Java desktop
applications. Get started by reading Javadoc at
http://bits.netbeans.org/html+java/

Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
care about Java, then your future should be Apache HTML/Java API!
-jt

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Gonzalo Ortiz Jaureguizar <go...@gmail.com>]

2018-03-12 18:21 GMT+01:00 Zoran Sevarac <se...@gmail.com>:

>
> I understood that the same way. Thats 8 yrs from now, and till that time
> JavaScript will hopefully die :)
>

Or maybe Panama finally reach the JDK and it is easy to use Qt

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Zoran Sevarac <se...@gmail.com>]

>
> as far as I can see, there's nothing about end of awt or swing support:
> "Oracle will continue developing Swing and AWT in Java SE 8 and Java SE 11
> (18.9 LTS). This means they will be supported by Oracle through at least
> 2026."
>

I understood that the same way. Thats 8 yrs from now, and till that time
JavaScript will hopefully die :)

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Peter Nabbefeld <pe...@gmx.de>]

Hi,

as far as I can see, there's nothing about end of awt or swing support:
"Oracle will continue developing Swing and AWT in Java SE 8 and Java SE 
11 (18.9 LTS). This means they will be supported by Oracle through at 
least 2026."

Kind regards
Peter



Am 12.03.2018 um 16:59 schrieb Jaroslav Tulach:
>> "Oracle has begun conversations with interested parties in the Java
>> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
>>>>> referenced timeframes."
>>>>>
> The official announcement is here and people are finally starting to
> realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
> will sponsor development of anything new for these technologies. Even if
> they get transfered to their new owners, they will be in maintenance mode:
> Bugfixes and little features. No bigger changes - no new rendering
> pipelines using new nifty features of graphics cards. Just sustaining. I've
> been explaining this would happen since 2012.
>
> To help us out of this situation and save Java as a programming language I
> dedicated my days to smoothing out interoperability between Java and
> JavaScript with the goal to reuse the most flexible and portable rendering
> system of these days: the browser. My work has already been donated to
> Apache, see: https://github.com/apache/incubator-netbeans-html4j - let's
> use it to build new features of NetBeans and other future Java desktop
> applications. Get started by reading Javadoc at
> http://bits.netbeans.org/html+java/
>
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> care about Java, then your future should be Apache HTML/Java API!
> -jt
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Eirik Bakke <eb...@ultorg.com>]

All of Minecraft<https://minecraft.net> (acquired by Microsoft in 2014 for 2.5 billion dollars<https://beta.techcrunch.com/2014/09/15/microsoft-has-acquired-minecraft>) is written in Java, using LWJGL<https://www.lwjgl.org/> to access OpenGL. So even if Swing and AWT dies completely in 10 years, you can still use Java for high-performance desktop graphics applications.

And in fact, AWT & Java2D just got a brand new rendering pipeline: https://bugs.openjdk.java.net/browse/JDK-8131760

-- Eirik

On 3/12/18, 2:22 PM, "Kenneth Fogel" <kf...@dawsoncollege.qc.ca>> wrote:

This is most distressing to me. You point out that "no new rendering pipelines using new nifty features of graphics cards". It implies that serious graphics application will need to be written in C/C++ and OpenGL. By my twisted logic it can also be said that EE is dead too because its been spun off to Eclipse.

Ken



-----Original Message-----
From: Jaroslav Tulach [mailto:jaroslav.tulach@gmail.com]
Sent: March 12, 2018 11:59 AM
To: Apache NetBeans <de...@netbeans.incubator.apache.org>>
Subject: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

"Oracle has begun conversations with interested parties in the Java

ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
referenced timeframes."



The official announcement is here and people are finally starting to realize the truth: There is no future for JavaFX, AWT and Swing. Nobody will sponsor development of anything new for these technologies. Even if they get transfered to their new owners, they will be in maintenance mode:
Bugfixes and little features. No bigger changes - no new rendering pipelines using new nifty features of graphics cards. Just sustaining. I've been explaining this would happen since 2012.

To help us out of this situation and save Java as a programming language I dedicated my days to smoothing out interoperability between Java and JavaScript with the goal to reuse the most flexible and portable rendering system of these days: the browser. My work has already been donated to Apache, see: https://github.com/apache/incubator-netbeans-html4j - let's use it to build new features of NetBeans and other future Java desktop applications. Get started by reading Javadoc at http://bits.netbeans.org/html+java/

Forget about AWT, Swing and JavaFX - the future is HTML. In case you still care about Java, then your future should be Apache HTML/Java API!
-jt

RE: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Kenneth Fogel <kf...@dawsoncollege.qc.ca>]

This is most distressing to me. You point out that "no new rendering pipelines using new nifty features of graphics cards". It implies that serious graphics application will need to be written in C/C++ and OpenGL. By my twisted logic it can also be said that EE is dead too because its been spun off to Eclipse. 

Ken

 


-----Original Message-----
From: Jaroslav Tulach [mailto:jaroslav.tulach@gmail.com] 
Sent: March 12, 2018 11:59 AM
To: Apache NetBeans <de...@netbeans.incubator.apache.org>
Subject: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

> "Oracle has begun conversations with interested parties in the Java

> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
>>>> referenced timeframes."
>>>>
>>>
>>
The official announcement is here and people are finally starting to realize the truth: There is no future for JavaFX, AWT and Swing. Nobody will sponsor development of anything new for these technologies. Even if they get transfered to their new owners, they will be in maintenance mode:
Bugfixes and little features. No bigger changes - no new rendering pipelines using new nifty features of graphics cards. Just sustaining. I've been explaining this would happen since 2012.

To help us out of this situation and save Java as a programming language I dedicated my days to smoothing out interoperability between Java and JavaScript with the goal to reuse the most flexible and portable rendering system of these days: the browser. My work has already been donated to Apache, see: https://github.com/apache/incubator-netbeans-html4j - let's use it to build new features of NetBeans and other future Java desktop applications. Get started by reading Javadoc at http://bits.netbeans.org/html+java/

Forget about AWT, Swing and JavaFX - the future is HTML. In case you still care about Java, then your future should be Apache HTML/Java API!
-jt

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Timon Veenstra <mo...@gmail.com>]

>
>
> To help us out of this situation and save Java as a programming language I
> dedicated my days to smoothing out interoperability between Java and
> JavaScript with the goal to reuse the most flexible and portable rendering
> system of these days: the browser. My work has already been donated to
> Apache, see: https://github.com/apache/incubator-netbeans-html4j - let's
> use it to build new features of NetBeans and other future Java desktop
> applications. Get started by reading Javadoc at
> http://bits.netbeans.org/html+java/
>
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> care about Java, then your future should be Apache HTML/Java API!
> -jt
>

It's a clear call.
We would benefit from stepping on the same boat, whichever boat it is.

Although I like all the discussion around here, it seems more about the
course of this boat rather then offering an alternative one.

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Peter Nabbefeld <pe...@gmx.de>]

Ouch - just answered to the thread, but used the wrong article to 
respond, sorry.


Regards
P.


Am 12.03.2018 um 18:12 schrieb Geertjan Wielenga:
> Well, when I read the blog below from Oracle's Donald Smith, in charge of
> all Java things, Swing isn't even mentioned, i.e., it is all about JavaFX:
>
> https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates
>
> That means for AWT and Swing, everything is as it always has been, i.e.,
> the status quo continues, which is fine, and then read the official PDF
> announcement...
>
> http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf
>
> ...which ends with these words:
>
> "Oracle will continue developing Swing and AWT in Java SE 8 and Java SE 11
> (18.9 LTS). This means they will be supported by Oracle through at least
> 2026."
>
> I really wouldn't be worried at all about something that will be supported
> "through at least 2026".
>
> Gj
>
>
>
> On Mon, Mar 12, 2018 at 6:06 PM, Matthias Bläsing <mblaesing@doppel-helix.eu
>> wrote:
>> Hey,
>>
>> Am Montag, den 12.03.2018, 16:59 +0100 schrieb Jaroslav Tulach:
>>>> "Oracle has begun conversations with interested parties in the Java
>>>> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the
>>>> above
>>>>>>> referenced timeframes."
>>>>>>>
>>> Forget about AWT, Swing and JavaFX - the future is HTML. In case you
>>> still
>>> care about Java, then your future should be Apache HTML/Java API!
>> Funfact: Without JavaFX you don't have a HTML5 renderer in the core
>> JDK. So the only thing that could run your HTML/Java API is removed by
>> Oracle.
>>
>> BTW: Swing was declared dead as often as Java itself. And just wonder
>> it is still here.
>>
>> If this path is followed, I'll reconsider the IDE that is build on-top
>> of SWT.
>>
>> Greetings
>>
>> Matthias
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Neil C Smith <ne...@apache.org>]

On Mon, 12 Mar 2018 at 17:36 Matthias Bläsing <mb...@doppel-helix.eu>
wrote:

> My reading is a bit less *heaven will fall*:
> ...
>  * The future of Swing and AWT is not yet decided
>

Same here!  And I agree with you.  That document doesn't say anything about
post-J2SE 11.  I'm questioning the idea that people keep quoting that as if
J2SE 11 will be freely, publicly supported until 2026.  Great if it is, but
someone really should tell Azul's marketing team! ;-)

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Chuck Davis <cj...@gmail.com>]

I can't be the only person who has noticed that jdk8 had 15 HTML
classes/interfaces and jdk9 has 74 HTML classes/interfaces?  Does this tell
us something?  Sure looks to me like HTML is coming to Java in a big way.

Is there anything a browser can render that Java cannot render?  If so,
what is the point of all the HTML creeping into Java?

On Mon, Mar 12, 2018 at 11:26 AM, Kenneth Fogel <kf...@dawsoncollege.qc.ca>
wrote:

> As far as I can tell Swing and AWT were pretty much abandoned years ago
> except for maintenance.
>
> Ken
>
> -----Original Message-----
> From: Matthias Bläsing [mailto:mblaesing@doppel-helix.eu]
> Sent: March 12, 2018 1:37 PM
> To: dev@netbeans.incubator.apache.org
> Subject: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX
> from Oracle JDK
>
> Am Montag, den 12.03.2018, 17:26 +0000 schrieb Neil C Smith:
> > On Mon, 12 Mar 2018 at 17:12 Geertjan Wielenga <
> > geertjan.wielenga@googlemail.com> wrote:
> >
> > > I really wouldn't be worried at all about something that will be
> > > supported "through at least 2026".
> > >
> >
> > In a public, freely available JDK?
> >
>
> I did not see Swing or AWT marked as deprecated in OpenJDK. So removal
> at this point is out of the question. I doubt that Oracle will remove
> the whole desktop module from their JDK, so even Oracle JDK will most
> probably carry AWT+Swing.
>
> My reading is a bit less *heaven will fall*:
>
>  * The java plugin is dead (thanks go to the browser makers)
>  * Java Web Start is mostly dead and was never open source. Interested
>    parties could place their money on Red Hat, which might have its
>    open source successor (Iced Tea Web)
>  * JavaFX is not part of the Oracle JDK anymore
>  * The future of Swing and AWT is not yet decided
>
> To read more into the white-paper is just reading tea-leaves. It might
> be fun, but the future is not told there.
>
> Greetings
>
> Matthias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Tim Boudreau <ni...@gmail.com>]

First - we're talking 8 years from now.  Eight years is a long time.  That
doesn't mean don't be ready for it, but it does mean don't panic.
Secondly, what it means is that Oracle doesn't plan to develop AWT and
Swing after that point.  That doesn't mean nobody will or could.

That said, the way AWT does graphics is optimized for the XWindows of the
90s, and does not play nicely with what modern graphics cards actually do
today.  That was really the promise of JavaFX in its final, neutered,
too-late form - a modern graphics pipeline.

Re Electron:  Think of what Electron actually *is* - it bundles *all* of
Chromium.  I feel this pain particularly since I run Gentoo and build my
entire system and all its software from source - Chromium builds lately
take about 5-7 hours (on a 3Ghz i7 with 8Gb and SSD!) - while nothing else
on my system takes more than a few minutes.  For a while I had Atom
installed, which uses Electron.  Building that from source added another 8
hours to every time I updated my system - turning what used to be an hour
or so to update everything into something akin to compiling the Linux
kernel on a 486 - check back tomorrow to see if it's done.

I also, using Gentoo and frequently MongoDB, lived through MongoDB's brief
dalliance with depending on and linking, then bundling, then getting rid of
v8 - and the big problem there was that v8's ABI was broken incompatibly
very regularly.  I expect Electron will suffer that pain as well, and
eventually go through some growing pains that likely result in forking what
they depend on, or writing their own replacement + vanilla WebKit or
something like that.  Not to mention that, both in terms of build times and
size, there will be pressure from people developing on it to please, please
make the gargantuan runtime smaller.  In other words, to do exactly the
same kind of splitting the JDK finally began to undergo with JDK 9.  Any
solves-all-your-desktop-application-problems platform is going to wind up
recapitulating a lot of the history of the Java platform.


I thought Oracle's effort to make NetBeans into a web-based IDE was likely
misguided - I don't want to program in a web browser and don't know anyone
who does, and doing that rules out using well, pick-any-unix-text-utility -
it's a huge step backwards in development tooling.  But I liked the idea
that it forced decoupling the functionality of the IDE from AWT and Swing,
so from that perspective it's goodness.

The only good I see out of doing the UI in HTML and Javascript is, finally,
a solution to blocking the UI on I/O, which is a bug baked so deeply into
NetBeans APIs it can't be eliminated without a separate UI layer on top of
the existing one.  I don't actually think it's a great way to go - for
anyone who wrote dynamic HTML with Javascript in the 90s or early 2000s,
how much of your code still works?  Browsers are a moving target in a way
Swing never was.

To my instincts, preferable would probably be some OpenGL-based toolkit for
the basic drawing and interaction support, and take it from there with a
small suite of custom components on top of that, in terms of
cost-of-maintenance and stability.  The brave new world of modern web
development - and I just spent a bunch of time working on a React project
(and spent a bunch of time patching a drag and drop library because Chrome
stopped allowing you to call consume() on touch events unless you do
something special when you register your listener - code which worked fine
a few months before) - doesn't really do backward compatibility - which
means keeping an HTML-based NetBeans actually working for users requires a
large, permanent ongoing investment of work that's more costly than
maintaining a handful of UI components where, once you have a button
component that works, it works forever.  I see the appeal of HTML in that
it's omnipresent, and at present looks like it's sucked all the air out of
the user interface room - but I also remember when Javascript was dead, and
when Windows had killed Unix.

-Tim

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

["William L. Thomson Jr." <wl...@o-sinc.com>]

On Wed, 14 Mar 2018 10:20:17 -0400
Scott Palmer <sw...@gmail.com> wrote:

> > On Mar 14, 2018, at 3:01 AM, <to...@eppleton.de>
> > <to...@eppleton.de> wrote:
> > 
> > There's a problem with this whole discussion. Participants are
> > mixing criticism of webapps with criticism of Desktop applications
> > which use a HTML5Component as their renderer. I don't know if I
> > should respond, because technologies like DukeScript or Electron do
> > not suffer from this browser compatibility problem. They ship their
> > own renderer/browser. Still we keep getting this.   
> 
> Because HTML5 is horrible to use as a rendering technology regardless
> of browser issues.  It is simply the wrong tool for the job.  It
> makes no sense to convert everything back to a form (HTML) that
> poorly expresses what you want to do.  The internet is full of “How
> can a get a layout like this…?” questions with regard to HTML.
> Followed by hack upon hack to try to make it work. If you use a
> proper GUI toolkit instead of a mutilated mark-up language, you just
> do it.

Everyone keeps forgetting that many used Flash for consistency where
HTML could not. Not to mention doing things you could not in
HTML/CSS/JS. Many things still trying to move from Flash to HTML5.
Other things are making no effort. Major things like Trustwave's
Trustkeeper for PCI Compliance, all in Flash....
https://login.trustwave.com/portal-core/home

They are not doing anything that special, it could be done even before
HTML5 was a thing... One reason they may use Flash is consistency, and
not having to deal with browser quirks.... Though maybe also to prevent
people from hacking the HTML/JS in various pages. Like Java on Desktop,
you cannot easily manipulate compiled code....

Any longtime web developer has had to make various CSS files to handle
issues in different browsers, wrote conditional JS code, based on DOM,
etc. Browsers and web develop is a freaking nightmare and has never
gotten better in decades.... Same page in different browsers on same OS
can look different. Same page on different OS can look different in
same browser....

Its all garbage for UI IMHO. Anytime someone talks HTML/JS/CSS for UI I
stop listening right there.... I have been there, done that, wasted to
many hours of my life dealing with quirks...

-- 
William L. Thomson Jr.

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Scott Palmer <sw...@gmail.com>]

> On Mar 14, 2018, at 3:01 AM, <to...@eppleton.de> <to...@eppleton.de> wrote:
> 
> There's a problem with this whole discussion. Participants are mixing criticism of webapps with criticism of Desktop applications which use a HTML5Component as their renderer. I don't know if I should respond, because technologies like DukeScript or Electron do not suffer from this browser compatibility problem. They ship their own renderer/browser. Still we keep getting this. 

Because HTML5 is horrible to use as a rendering technology regardless of browser issues.  It is simply the wrong tool for the job.  It makes no sense to convert everything back to a form (HTML) that poorly expresses what you want to do.  The internet is full of “How can a get a layout like this…?” questions with regard to HTML. Followed by hack upon hack to try to make it work. If you use a proper GUI toolkit instead of a mutilated mark-up language, you just do it.

Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[to...@eppleton.de]

There's a problem with this whole discussion. Participants are mixing criticism of webapps with criticism of Desktop applications which use a HTML5Component as their renderer. I don't know if I should respond, because technologies like DukeScript or Electron do not suffer from this browser compatibility problem. They ship their own renderer/browser. Still we keep getting this. 

It's correct, that there are many frameworks. That's because the technology has lots of users. Nobody forces you to use these frameworks. Still some of these frameworks show modern approaches of UI development which make software development, faster, more testable and lead to less code. My experience from porting Swing applications to DukeScript is, that by using the MVVM pattern you can throw away 4/5th of the UI code. And the remaining code will be completely testable with simple unit tests. 

--Toni


-----Ursprüngliche Nachricht-----
Von: Glenn Holmer <ce...@kolabnow.com> 
Gesendet: Dienstag, 13. März 2018 18:58
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

On 03/13/2018 12:13 AM, cowwoc wrote:
> Web-based development is cool because everyone is jumping on board. It 
> isn't cool because it's better. Every week there is a new framework. 
> The level of cross-platform compatibility doesn't begin to compare to Java.
> You have portability problems across different browsers on the same 
> operating system, not to mention different operating systems.

Very well said, totally agree.

--
Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Glenn Holmer <ce...@kolabnow.com>]

On 03/13/2018 12:13 AM, cowwoc wrote:
> Web-based development is cool because everyone is jumping on board. It
> isn't cool because it's better. Every week there is a new framework. The
> level of cross-platform compatibility doesn't begin to compare to Java.
> You have portability problems across different browsers on the same
> operating system, not to mention different operating systems.

Very well said, totally agree.

-- 
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[cowwoc <co...@bbs.darktech.org>]

Agreed.

People keep on saying that Oracle will support AWT/Swing for another 8 
years... Have you noticed what the last 8 years have been like? If this 
is the kind of "support" we can expect then they might as well spin it 
out the JDK like JavaFX.

The end result of this announcement is fragmentation, fragmentation, 
fragmentation. Instead of one half-baked technology, we'll end up with 
five of them and none of them will be as mature/stable as AWT/Swing. All 
the big players are walking away from client-side dvelopment, except for 
Microsoft. It's very sad to see.

Web-based development is cool because everyone is jumping on board. It 
isn't cool because it's better. Every week there is a new framework. The 
level of cross-platform compatibility doesn't begin to compare to Java. 
You have portability problems across different browsers on the same 
operating system, not to mention different operating systems. All in 
all, this is a huge step backward for the developer community.

Gili

On 2018-03-12 2:26 PM, Kenneth Fogel wrote:
> As far as I can tell Swing and AWT were pretty much abandoned years ago except for maintenance.
>
> Ken
>
> -----Original Message-----
> From: Matthias Bläsing [mailto:mblaesing@doppel-helix.eu]
> Sent: March 12, 2018 1:37 PM
> To: dev@netbeans.incubator.apache.org
> Subject: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK
>
> Am Montag, den 12.03.2018, 17:26 +0000 schrieb Neil C Smith:
>> On Mon, 12 Mar 2018 at 17:12 Geertjan Wielenga <
>> geertjan.wielenga@googlemail.com> wrote:
>>
>>> I really wouldn't be worried at all about something that will be
>>> supported "through at least 2026".
>>>
>> In a public, freely available JDK?
>>
> I did not see Swing or AWT marked as deprecated in OpenJDK. So removal
> at this point is out of the question. I doubt that Oracle will remove
> the whole desktop module from their JDK, so even Oracle JDK will most
> probably carry AWT+Swing.
>
> My reading is a bit less *heaven will fall*:
>
>   * The java plugin is dead (thanks go to the browser makers)
>   * Java Web Start is mostly dead and was never open source. Interested
>     parties could place their money on Red Hat, which might have its
>     open source successor (Iced Tea Web)
>   * JavaFX is not part of the Oracle JDK anymore
>   * The future of Swing and AWT is not yet decided
>
> To read more into the white-paper is just reading tea-leaves. It might
> be fun, but the future is not told there.
>
> Greetings
>
> Matthias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Kenneth Fogel <kf...@dawsoncollege.qc.ca>]

As far as I can tell Swing and AWT were pretty much abandoned years ago except for maintenance.

Ken

-----Original Message-----
From: Matthias Bläsing [mailto:mblaesing@doppel-helix.eu] 
Sent: March 12, 2018 1:37 PM
To: dev@netbeans.incubator.apache.org
Subject: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

Am Montag, den 12.03.2018, 17:26 +0000 schrieb Neil C Smith:
> On Mon, 12 Mar 2018 at 17:12 Geertjan Wielenga < 
> geertjan.wielenga@googlemail.com> wrote:
> 
> > I really wouldn't be worried at all about something that will be 
> > supported "through at least 2026".
> > 
> 
> In a public, freely available JDK?
> 

I did not see Swing or AWT marked as deprecated in OpenJDK. So removal
at this point is out of the question. I doubt that Oracle will remove
the whole desktop module from their JDK, so even Oracle JDK will most
probably carry AWT+Swing.

My reading is a bit less *heaven will fall*:

 * The java plugin is dead (thanks go to the browser makers)
 * Java Web Start is mostly dead and was never open source. Interested
   parties could place their money on Red Hat, which might have its
   open source successor (Iced Tea Web)
 * JavaFX is not part of the Oracle JDK anymore
 * The future of Swing and AWT is not yet decided

To read more into the white-paper is just reading tea-leaves. It might
be fun, but the future is not told there.

Greetings

Matthias

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Matthias Bläsing <mb...@doppel-helix.eu>]

Am Montag, den 12.03.2018, 17:26 +0000 schrieb Neil C Smith:
> On Mon, 12 Mar 2018 at 17:12 Geertjan Wielenga <
> geertjan.wielenga@googlemail.com> wrote:
> 
> > I really wouldn't be worried at all about something that will be
> > supported
> > "through at least 2026".
> > 
> 
> In a public, freely available JDK?
> 

I did not see Swing or AWT marked as deprecated in OpenJDK. So removal
at this point is out of the question. I doubt that Oracle will remove
the whole desktop module from their JDK, so even Oracle JDK will most
probably carry AWT+Swing.

My reading is a bit less *heaven will fall*:

 * The java plugin is dead (thanks go to the browser makers)
 * Java Web Start is mostly dead and was never open source. Interested
   parties could place their money on Red Hat, which might have its
   open source successor (Iced Tea Web)
 * JavaFX is not part of the Oracle JDK anymore
 * The future of Swing and AWT is not yet decided

To read more into the white-paper is just reading tea-leaves. It might
be fun, but the future is not told there.

Greetings

Matthias

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Neil C Smith <ne...@apache.org>]

On Mon, 12 Mar 2018 at 17:12 Geertjan Wielenga <
geertjan.wielenga@googlemail.com> wrote:

> I really wouldn't be worried at all about something that will be supported
> "through at least 2026".
>

In a public, freely available JDK?

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Geertjan Wielenga <ge...@googlemail.com>]

Well, when I read the blog below from Oracle's Donald Smith, in charge of
all Java things, Swing isn't even mentioned, i.e., it is all about JavaFX:

https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates

That means for AWT and Swing, everything is as it always has been, i.e.,
the status quo continues, which is fine, and then read the official PDF
announcement...

http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf

...which ends with these words:

"Oracle will continue developing Swing and AWT in Java SE 8 and Java SE 11
(18.9 LTS). This means they will be supported by Oracle through at least
2026."

I really wouldn't be worried at all about something that will be supported
"through at least 2026".

Gj



On Mon, Mar 12, 2018 at 6:06 PM, Matthias Bläsing <mblaesing@doppel-helix.eu
> wrote:

> Hey,
>
> Am Montag, den 12.03.2018, 16:59 +0100 schrieb Jaroslav Tulach:
> > > "Oracle has begun conversations with interested parties in the Java
> > > ecosystem on the stewardship of JavaFX, Swing and AWT beyond the
> > > above
> > > > > > referenced timeframes."
> > > > > >
> >
> > Forget about AWT, Swing and JavaFX - the future is HTML. In case you
> > still
> > care about Java, then your future should be Apache HTML/Java API!
>
> Funfact: Without JavaFX you don't have a HTML5 renderer in the core
> JDK. So the only thing that could run your HTML/Java API is removed by
> Oracle.
>
> BTW: Swing was declared dead as often as Java itself. And just wonder
> it is still here.
>
> If this path is followed, I'll reconsider the IDE that is build on-top
> of SWT.
>
> Greetings
>
> Matthias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Peter Nabbefeld <pe...@gmx.de>]

Hi,

has everybody discussing here actually read the document ("Java Client 
Roadmap Update")?

There's nothing about end of awt or swing support:
"Oracle will continue developing Swing and AWT in Java SE 8 and Java SE 
11 (18.9 LTS). This means they will be supported by Oracle through at 
least 2026."

Only JFX will be removed in Java 11 - but, of course, they can still 
change their mind ...

Kind regards
Peter



Am 12.03.2018 um 18:06 schrieb Matthias Bläsing:
> Hey,
>
> Am Montag, den 12.03.2018, 16:59 +0100 schrieb Jaroslav Tulach:
>>> "Oracle has begun conversations with interested parties in the Java
>>> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the
>>> above
>>>>>> referenced timeframes."
>>>>>>
>> Forget about AWT, Swing and JavaFX - the future is HTML. In case you
>> still
>> care about Java, then your future should be Apache HTML/Java API!
> Funfact: Without JavaFX you don't have a HTML5 renderer in the core
> JDK. So the only thing that could run your HTML/Java API is removed by
> Oracle.
>
> BTW: Swing was declared dead as often as Java itself. And just wonder
> it is still here.
>
> If this path is followed, I'll reconsider the IDE that is build on-top
> of SWT.
>
> Greetings
>
> Matthias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Neil C Smith <ne...@apache.org>]

Hi,

On Mon, 12 Mar 2018, 21:52 , <to...@eppleton.de> wrote:

> No, Electron is not involved so far, although it probably would work. On
> most of our supported platforms we have a "real" Java application talk to
> JavaScript via a Java-JavaScript Bridge. Similar to what you can do in a
> JavaFX application with the WebView, but with a nice typesafe API. One of
> the benefits is that we can make use of the full Java core APIs. The Vaadin
> example Java presumably is transpiled to js and limited to the very basic
> Java API GWT supports.
>

No, it's mainly a real Java application, with just the actual UI layer
display and interaction in JS/CEF. It's basically running both sides of a
Vaadin client/server web application locally via Electron. Rather
heavyweight way to do it, perhaps! On the other hand the open source
nature, active development and distribution framework of Electron make it
potentially an attractive option for mixed Java/HTML applications.

Best wishes,

Neil


-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[to...@eppleton.de]

No, Electron is not involved so far, although it probably would work. On most of our supported platforms we have a "real" Java application talk to JavaScript via a Java-JavaScript Bridge. Similar to what you can do in a JavaFX application with the WebView, but with a nice typesafe API. One of the benefits is that we can make use of the full Java core APIs. The Vaadin example Java presumably is transpiled to js and limited to the very basic Java API GWT supports.

--Toni 



----Ursprüngliche Nachricht-----
Von: Neil C Smith <ne...@apache.org> 
Gesendet: Montag, 12. März 2018 19:08
An: dev@netbeans.incubator.apache.org; Toni Epple <to...@eppleton.de>
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

Hi Toni,

On Mon, 12 Mar 2018 at 17:51 <to...@eppleton.de> wrote:

> At DukeScript (http://dukescript.com) we have plenty of HTML4J 
> renderers other than JavaFX (Chromium via JXBrowser, ios WebView via 
> Multi OS Engine and MobiVM, Android WebView, plain Webkit, 
> Instrumented Browser...) and we can even run inside the browser itself with bck2brws &, TeaVM.
>

So, out of interest, do those renderers or any experiments include Electron?  After the last conversation on here that touched on this, and JCEF, etc. I came across this https://github.com/jreznot/electron-java-app
and a related blog post.  I keep trying to find some time to experiment with Apache HTML/Java and wondered at the feasibility of reworking that Electron example with it?

Best wishes,

Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Neil C Smith <ne...@apache.org>]

Hi Toni,

On Mon, 12 Mar 2018 at 17:51 <to...@eppleton.de> wrote:

> At DukeScript (http://dukescript.com) we have plenty of HTML4J renderers
> other than JavaFX (Chromium via JXBrowser, ios WebView via Multi OS Engine
> and MobiVM, Android WebView, plain Webkit, Instrumented Browser...) and we
> can even run inside the browser itself with bck2brws &, TeaVM.
>

So, out of interest, do those renderers or any experiments include
Electron?  After the last conversation on here that touched on this, and
JCEF, etc. I came across this https://github.com/jreznot/electron-java-app
and a related blog post.  I keep trying to find some time to experiment
with Apache HTML/Java and wondered at the feasibility of reworking that
Electron example with it?

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Matthias Bläsing <mb...@doppel-helix.eu>]

Hey,

On 2018/03/12 17:51:00, <t....@eppleton.de> wrote: 
> At DukeScript (http://dukescript.com) we have plenty of HTML4J
> renderers other than JavaFX (Chromium via JXBrowser, ios WebView via
> Multi OS Engine and MobiVM, Android WebView, plain Webkit, 
> Instrumented Browser...) and we can even run inside the browser 
> itself with bck2brws&, TeaVM. So in no way are we limited by the 
> removal of JavaFX. JavaFX
> is only one, and to be honest, the worst and least complete, renderer
> of the many HTML4J supports.> 

ok I'll bite - which renderer do you suggest, that:

 * works on windows, macOS and linux
 * is ALv2 licensed
 * is supported
 * will not cause the netbeans installation to grow by around 40 MB
   (that is the size of the webkit library in the JavaFX)
 * supports JDK 8, 9 and 10
 * will stay around for more than a few years

Greetings

Matthias



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[to...@eppleton.de]

At DukeScript (http://dukescript.com) we have plenty of HTML4J renderers other than JavaFX (Chromium via JXBrowser, ios WebView via Multi OS Engine and MobiVM, Android WebView, plain Webkit, Instrumented Browser...) and we can even run inside the browser itself with bck2brws &, TeaVM. So in no way are we limited by the removal of JavaFX. JavaFX is only one, and to be honest, the worst and least complete, renderer of the many HTML4J supports.

--Toni


-----Ursprüngliche Nachricht-----
Von: Matthias Bläsing <mb...@doppel-helix.eu> 
Gesendet: Montag, 12. März 2018 18:07
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

Hey,

Am Montag, den 12.03.2018, 16:59 +0100 schrieb Jaroslav Tulach:
> > "Oracle has begun conversations with interested parties in the Java 
> > ecosystem on the stewardship of JavaFX, Swing and AWT beyond the 
> > above
> > > > > referenced timeframes."
> > > > > 
> 
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you 
> still care about Java, then your future should be Apache HTML/Java 
> API!

Funfact: Without JavaFX you don't have a HTML5 renderer in the core JDK. So the only thing that could run your HTML/Java API is removed by Oracle.

BTW: Swing was declared dead as often as Java itself. And just wonder it is still here.

If this path is followed, I'll reconsider the IDE that is build on-top of SWT.

Greetings

Matthias

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Matthias Bläsing <mb...@doppel-helix.eu>]

Hey,

Am Montag, den 12.03.2018, 16:59 +0100 schrieb Jaroslav Tulach:
> > "Oracle has begun conversations with interested parties in the Java
> > ecosystem on the stewardship of JavaFX, Swing and AWT beyond the
> > above
> > > > > referenced timeframes."
> > > > > 
> 
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you
> still
> care about Java, then your future should be Apache HTML/Java API!

Funfact: Without JavaFX you don't have a HTML5 renderer in the core
JDK. So the only thing that could run your HTML/Java API is removed by
Oracle.

BTW: Swing was declared dead as often as Java itself. And just wonder
it is still here.

If this path is followed, I'll reconsider the IDE that is build on-top
of SWT.

Greetings

Matthias

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

["William L. Thomson Jr." <wl...@o-sinc.com>]

On Wed, 14 Mar 2018 13:04:08 -0700
Chuck Davis <cj...@gmail.com> wrote:

> So, what are you waiting for?
> https://wiki.openjdk.java.net/display/OpenJFX/Main will be more than
> happy to suck up some energy from you.
> 
> Sorry, I guess I'm in a snarky mood today but I just get so tired of
> everybody ragging on Oracle.  

I see this constantly for years around Gentoo. While others are not
hated, which should be IMHO like Google, and others. Oracle is hardly
the bad company out there. Though others are forcing their hand in a
way, eating into their eco system. IMHO they are just reacting to
ensure their own place in the market space.

> How long has OpenJDK been the source and
> Oracle has been doctoring it to make it usable?  Now it has a shiny,
> new rendering engine for AWT/Swing; they don't have to screw around
> upgrading rendering with every release.  What else should we (the
> Community) be doing for Java to make it more usable?  What bugs have
> any of us here fixed (I know some of you have done many and you are
> herewith thanked for your efforts)?

There is tons of interest in OpenJDK in the FOSS world and almost no
one working on building it, etc. That includes myself. I am happy to
use the binaries Oracle puts out, knowing the time they put into such.
Seeing the time others put into just packaging OpenJDK.

> Same can be said for OpenJFX.

Which almost no distro or anyone has packaged anywhere.
https://bugs.gentoo.org/547918

The lack of involvement in OpenJDK gets even worse with OpenJFX...

> As far as I know Oracle and IBM are the only companies that have been
> taking OpenJDK and doctoring it to improve it enough to be released
> (and IBM has never included JFX).  Maybe they're tired of the drag
> we've been.

IBM released their OpenJ9 which seems to have a fair amount of
interest. But short of them releasing an OpenJDK with OpenJ9, not sure
who else would have made that happen.
https://github.com/eclipse/openj9
https://github.com/ibmruntimes/openj9-openjdk-jdk9

There is like 1 guy working on it at RedHat, short of the icedtea-web
team. This guy should have a team, and I question why Redhat has not
invested in more man power. Java is a big revenue source for RedHat.
https://www.linkedin.com/in/gnuandrew
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/

Then again RedHat is footing the bill for the entire world...

> PS  I am not and never have been an Oracle employee.  I don't get
> commissions for sales of their products.  I'm just another freeloader
> like the rest of you whiners and complainers (trust me, I've done my
> share).

Same here, though I know someone who works for them locally. I even
tried to apply with them years ago and never got a call back or
anything. Thus not a super fan of Oracle, but I have no reason to
dislike them either. More a Sun fan, but those years are passed.

I respect Oracle as a tech company, and thankful for what they do put
out. Way better than others like say Google....


-- 
William L. Thomson Jr.

Re: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[John Kostaras <jk...@gmail.com>]

+1 for a UI agnostic NetBeans Platform

On 15 March 2018 at 23:07, Antonio <an...@vieiro.net> wrote:

> On 15/03/18 22:49, Sven Reimers wrote:
>
>> Thanks for great API's Jarda - let's create even better API's together for
>> the future.
>>
>>
> +1
>
> And thanks for the book too!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Antonio <an...@vieiro.net>]

On 15/03/18 22:49, Sven Reimers wrote:
> Thanks for great API's Jarda - let's create even better API's together for
> the future.
> 

+1

And thanks for the book too!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Sven Reimers <sv...@gmail.com>]

Hi all,

after reading all the different views I thought I add my 2€c...

As Tony mentioned I created an experimental POC for a JavaFX window system
on top of NetBeans (ok what remains once you get rid of ALL Swing
dependencies).

With this experience I would suggest the following:

1. Try to identify what we can reuse in a post Swing world  (JavaFX or
HTML5 as a replacement does not matter for this step)
2. Decouple this (or more if possible) from actual Swing dependencies
3. Start the discussion again based on the new API's

Anyone familiar with E4? Sounds very similar to this?

So what do we really expect from a UI agnostic NetBeans Platform?

Hope this starts a discussion about API design and ends the flame war..

Thanks for great API's Jarda - let's create even better API's together for
the future.

Sven

P.S. The prototype is available as efx and a sample app vmFX at
bitbucket... dormant for a while...

Am 15.03.2018 19:43 schrieb <to...@eppleton.de>:

>
> >Yes, that would be the logical next step. I created a  simple experiment
> like that for JavaFX a while ago and Sven
> >Reimers did a little more work with JavaFX & a NB Platform with a new
> Window System, MenuBar etc.. It's
> >totally possible, and this is what I would suggest as the next step. If
> you want to join, that would be great."
>
> Sorry, I just realize that this sounds very confusing. I wanted to say:
> The same thing we did for JavaFX could be easily done for a HTML5 based UI,
> because NB Platform is quite modular and things like the Window System are
> not bound to Swing.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[to...@eppleton.de]

>Yes, that would be the logical next step. I created a  simple experiment like that for JavaFX a while ago and Sven
>Reimers did a little more work with JavaFX & a NB Platform with a new Window System, MenuBar etc.. It's 
>totally possible, and this is what I would suggest as the next step. If you want to join, that would be great."

Sorry, I just realize that this sounds very confusing. I wanted to say: The same thing we did for JavaFX could be easily done for a HTML5 based UI, because NB Platform is quite modular and things like the Window System are not bound to Swing.





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[to...@eppleton.de]

-----Ursprüngliche Nachricht-----
Von: Neil C Smith <ne...@apache.org> 
Gesendet: Donnerstag, 15. März 2018 19:01
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

On Thu, 15 Mar 2018 at 16:28 <to...@eppleton.de> wrote:

> Von: Neil C Smith <ne...@apache.org>
> Gesendet: Donnerstag, 15. März 2018 16:20
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove 
> JavaFXfromOracle JDK
>
> > If we have a fully open stack that's as easy to build within the IDE 
> > as
> a Swing application, then we have the basis for something quite useful.
>
> Well, there are some people who are already using it for quite some 
> time in commercial projects, so to them the project is quite useful already.
>

> Ha ha, sorry, no criticism meant at the usefulness of your commercial solution there! :-)  But by "we" I'm really  
> thinking of us here at Apache, and what we can ship support for in the IDE.  Not to mention that a commercial 
> license is a massive disadvantage to wider adoption.

Me too, I wasn't talking about the commercial (Dukehoff/DukeScript ) stuff. There are companies building applications on top of NetBeans Java/HTML API using our (and with our I mean Apache NetBeans😊 ) JavaFX Webview Presenter. There are also companies who use it to port their applets with a presenter for Jaroslavs bck2brwsr.  ( I probably shouldn't have mentioned that, because that's really running in a browser 😉 )

> If we have a solution within the IDE, possibly built around (non-UI) parts of the NetBeans RCP, where people can  
> export an application for each OS, we then have the basis of a Java-based Electron alternative / new NetBeans 
> RCP where we could really drive some of this forward?

Yes, that would be the logical next step. I created a  simple experiment like that for JavaFX a while ago and Sven Reimers did a little more work with JavaFX & a NB Platform with a new Window System, MenuBar etc.. It's totally possible, and this is what I would suggest as the next step. If you want to join, that would be great.

Cheers

Toni



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Neil C Smith <ne...@apache.org>]

On Thu, 15 Mar 2018 at 16:28 <to...@eppleton.de> wrote:

> Von: Neil C Smith <ne...@apache.org>
> Gesendet: Donnerstag, 15. März 2018 16:20
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove
> JavaFXfromOracle JDK
>
> > If we have a fully open stack that's as easy to build within the IDE as
> a Swing application, then we have the basis for something quite useful.
>
> Well, there are some people who are already using it for quite some time
> in commercial projects, so to them the project is quite useful already.
>

Ha ha, sorry, no criticism meant at the usefulness of your commercial
solution there! :-)  But by "we" I'm really thinking of us here at Apache,
and what we can ship support for in the IDE.  Not to mention that a
commercial license is a massive disadvantage to wider adoption.

If we have a solution within the IDE, possibly built around (non-UI) parts
of the NetBeans RCP, where people can export an application for each OS, we
then have the basis of a Java-based Electron alternative / new NetBeans RCP
where we could really drive some of this forward?

On Thu, 15 Mar 2018 at 17:05 <to...@eppleton.de> wrote:

> For this the feedback we filtered out was valuable. The messages from
> Chris, Neil and Emilian gave me a new perspective and valuable feedback to
> how they currently see this part of NetBeans, and how we can improve it.


Thanks!  But this is also an area I'm willing to put my time where my mouth
is! ;-)

Best wishes,

Neil


-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[to...@eppleton.de]

Von: Neil C Smith <ne...@apache.org> 
Gesendet: Donnerstag, 15. März 2018 16:20
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

On Thu, 15 Mar 2018, 14:59 , <to...@eppleton.de> wrote:

> We have that already for quite some time. The only thing missing are 
> the non-commercial non-JavaFX presenters.


> That is kind of the crux of my argument! ;-)

> If we have a fully open stack that's as easy to build within the IDE as a Swing application, then we have the basis for something quite useful.


Well, there are some people who are already using it for quite some time in commercial projects, so to them the project is quite useful already. But I agree that it would be even better if we had a better renderer 😊.

Cheers

Toni


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Neil C Smith <ne...@apache.org>]

On Thu, 15 Mar 2018, 14:59 , <to...@eppleton.de> wrote:

> We have that already for quite some time. The only thing missing are the
> non-commercial non-JavaFX presenters.


That is kind of the crux of my argument! ;-)

If we have a fully open stack that's as easy to build within the IDE as a
Swing application, then we have the basis for something quite useful.

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[to...@eppleton.de]

ECF -> CEF

-----Ursprüngliche Nachricht-----
Von: toni.epple@eppleton.de <to...@eppleton.de> 
Gesendet: Donnerstag, 15. März 2018 15:59
An: dev@netbeans.incubator.apache.org
Betreff: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK


> Having an Electron-like build and deploy system that uses the HTML/Java library and a JVM rather than node. That sounds like a powerful thing to have in our armoury for developers to use. The question of whether the IDE should migrate to that if it proves viable - that's a whole other distraction for a future time IMO.

We have that already for quite some time. The only thing missing are the non-commercial non-JavaFX presenters. And I think there's enough presenters around at DukeScript that prove it's possible to port to a new one like ECF or directly to Chromium Content API.

What I would find way more interesting is a POC as Geertjan demanded. One that proofs that we could run the IDE on top  of it.

--Toni




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[to...@eppleton.de]

> Having an Electron-like build and deploy system that uses the HTML/Java library and a JVM rather than node. That sounds like a powerful thing to have in our armoury for developers to use. The question of whether the IDE should migrate to that if it proves viable - that's a whole other distraction for a future time IMO.

We have that already for quite some time. The only thing missing are the non-commercial non-JavaFX presenters. And I think there's enough presenters around at DukeScript that prove it's possible to port to a new one like ECF or directly to Chromium Content API.

What I would find way more interesting is a POC as Geertjan demanded. One that proofs that we could run the IDE on top  of it.

--Toni




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Neil C Smith <ne...@apache.org>]

On Thu, 15 Mar 2018, 13:40 Wade Chandler, <wa...@apache.org> wrote:

>
> > On Mar 15, 2018, at 8:54 AM, Neil C Smith <ne...@apache.org> wrote:
> >
> > Anyway, this whole thing is going a bit in circles. We need to look at
> > improving the POCs in NetBeans to be able to show where (and where not)
> > this approach is viable and useful.
> >
>
> Agreed, but I think, so IMO, those just take us off the things that will
> actually have direct and immediate impacts. We can work on NB just as it
> is, and work to fix the index lock issues, add new Java parsing, add better
> language and feature support for some things like Groovy and Python, and
> generally move ahead, even while fixing some issues in Swing/AWT, or bog
> down in all this talk of web UIs which starts to make a lot of work which
> in the end didn’t really move the needle because we’ll still have a desktop
> IDE, but a lot of time would have been spent to just get further behind.
>

Agreed, 110%! To clarify, by proofs of concepts here I'm talking examples
and build systems that people can use within projects in the IDE, not bits
of the IDE UI itself.

Having an Electron-like build and deploy system that uses the HTML/Java
library and a JVM rather than node. That sounds like a powerful thing to
have in our armoury for developers to use. The question of whether the IDE
should migrate to that if it proves viable - that's a whole other
distraction for a future time IMO.

Best wishes,

Neil

-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

AW: AW: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[to...@eppleton.de]

Ok, I'm glad we could clarify that 😊. I really don't want to sell DukeScript - actually if we're implementing some of the stuff discussed here it will be harder to sell our JXBrowser (Chromium) presenters as there will be an Apache licensed free alternative.

I agree that the discussion here is quite long, sometimes heated, and it's getting hard to keep track. And I agree that we should probably get back from UI toolkit flame wars to something more productive. What drives me and likely also Jaroslav is to point out, that with HTML/Java we possibly have a good way to future proof NetBeans and we're willing to invest some time to investigate that. 

For this the feedback we filtered out was valuable. The messages from Chris, Neil and Emilian gave me a new perspective and valuable feedback to how they currently see this part of NetBeans, and how we can improve it.

 Cheers

Toni

-----Ursprüngliche Nachricht-----
Von: Peter Steele <st...@gmail.com> 
Gesendet: Donnerstag, 15. März 2018 17:30
An: dev@netbeans.incubator.apache.org
Betreff: Re: AW: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

Toni

Apologies, I didn't mean to offend. I'm just frustrated with a lot of the conversations here. If I miss interpreted you "selling" dukescript to the group I apologies. There are, what looks to be, so many intermingled conversations here.

People are trying to solve a problem which doesn't currently need solving, I'd rather people concentrate on the current product and make that better rather than waste time working out how replace swing.


On 15 Mar 2018 16:17, <to...@eppleton.de> wrote:

Peter,

Did I say MVVM is a technology? Are we using MVVM with Swing? HTML/Java uses it, so it would be new (and in my opinion) better way from what we've got.

Running the IDE in a Browser means, at least in my interpretation, that the program logic is executed in the browser. With HTML/Java the logic is running in the JVM, only the view is rendered in HTML. That is the difference.

Where did I propose to use DukeScript Presenters or DukeScript proprietary stuff for any of this? I only mentioned it as an example to show it's possible to use other renderers than JavaFX WebView.

I'm beginning to feel Jaroslav's pain.

--Toni

-----Ursprüngliche Nachricht-----
Von: Peter Steele <st...@gmail.com>
Gesendet: Donnerstag, 15. März 2018 17:01
An: dev@netbeans.incubator.apache.org
Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

Toni

MVVM is an architecture, not a technology. You can use any technology to implement it (there are even some that use swing).

If you want the whole ui rendered in HTML 5, you need something to parse html, CSS and JavaScript. Which, despite what you say, needs a browser like rendering engine. Which brings us back to running an ide in a browser. If there was no javafx, swing or awt what would dukescript use as the rendering engine?

Netbeans already has good support for web technologies, and already has the ability to run those in the browser of your choice. I see no reason for other people to add more including your dukescript, the product is open source and there is no reason not to create a module if you want to promote your own project

And lastly because Dukescript is a commercial product (if you want no ads, nag screen) i would say we should not even consider it as a potential risk long term alternative to swing. There are other free alternatives and these should be considered as and when there is actually a need to do.

This conversation has gone on long enough, can we please re focus on netbeans.

On 15 Mar 2018 14:59, <to...@eppleton.de> wrote:

> These things can happen in parallel. I for my part cannot help much 
> with Python or Groovy features, but I can help with the POCs to 
> improve NB UI and make it future proof. If for example we manage to 
> replace JavaFX WebView with something better, contributors like Chris 
> Lenz will be able to use more HTML5 features for writing their plugins 
> and the performance of HTML-based plugins will improve.
>
> Maybe some of the Swing/JavaFX developers will also try it out and 
> realize that developing with modern ui patterns like MVVM can 
> dramatically speed up development, and lead to more testable and 
> stable code while reducing the LOC. This would have the immediate 
> effect of better code that needs less maintenance.
>
> But we can also offer them a way to still run their ( in my opinion 
> horribly archaic 😊 ) Swing code.
>
> As a side effect we could also replace the embedded Browser for 
> debugging web applications with a real browser and make Web 
> Development in NB even more attractive. Projects like the Oracle JET 
> support in NetBeans, but also EE projects could directly benefit from
that.
>
> You're right these changes are driven by longer term goals, but they 
> will also create huge short term improvements.
>
> And since there's a lot of confusion here between "web technologies"
> and "web applications": I for my part don't want to run NetBeans in a
Browser.
> I want NetBeans to remain a traditional Desktop application, which can 
> use modern HTML5 UIs and is prepared for the end of Swing.
>
> --Toni
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Wade Chandler <wa...@apache.org>
> Gesendet: Donnerstag, 15. März 2018 14:40
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove 
> JavaFXfromOracle JDK
>
>
> > On Mar 15, 2018, at 8:54 AM, Neil C Smith <ne...@apache.org> wrote:
> >
> > Anyway, this whole thing is going a bit in circles. We need to look 
> > at improving the POCs in NetBeans to be able to show where (and 
> > where
> > not) this approach is viable and useful.
> >
>
> Agreed, but I think, so IMO, those just take us off the things that 
> will actually have direct and immediate impacts. We can work on NB 
> just as it is, and work to fix the index lock issues, add new Java 
> parsing, add better language and feature support for some things like 
> Groovy and Python, and generally move ahead, even while fixing some 
> issues in Swing/AWT, or bog down in all this talk of web UIs which 
> starts to make a lot of work which in the end didn’t really move the 
> needle because we’ll still have a desktop IDE, but a lot of time would
have been spent to just get further behind.
>
> Wade
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail:
> dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail:
> dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: AW: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Peter Steele <st...@gmail.com>]

Toni

Apologies, I didn't mean to offend. I'm just frustrated with a lot of the
conversations here. If I miss interpreted you "selling" dukescript to the
group I apologies. There are, what looks to be, so many intermingled
conversations here.

People are trying to solve a problem which doesn't currently need solving,
I'd rather people concentrate on the current product and make that better
rather than waste time working out how replace swing.


On 15 Mar 2018 16:17, <to...@eppleton.de> wrote:

Peter,

Did I say MVVM is a technology? Are we using MVVM with Swing? HTML/Java
uses it, so it would be new (and in my opinion) better way from what we've
got.

Running the IDE in a Browser means, at least in my interpretation, that the
program logic is executed in the browser. With HTML/Java the logic is
running in the JVM, only the view is rendered in HTML. That is the
difference.

Where did I propose to use DukeScript Presenters or DukeScript proprietary
stuff for any of this? I only mentioned it as an example to show it's
possible to use other renderers than JavaFX WebView.

I'm beginning to feel Jaroslav's pain.

--Toni

-----Ursprüngliche Nachricht-----
Von: Peter Steele <st...@gmail.com>
Gesendet: Donnerstag, 15. März 2018 17:01
An: dev@netbeans.incubator.apache.org
Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove
JavaFXfromOracle JDK

Toni

MVVM is an architecture, not a technology. You can use any technology to
implement it (there are even some that use swing).

If you want the whole ui rendered in HTML 5, you need something to parse
html, CSS and JavaScript. Which, despite what you say, needs a browser like
rendering engine. Which brings us back to running an ide in a browser. If
there was no javafx, swing or awt what would dukescript use as the
rendering engine?

Netbeans already has good support for web technologies, and already has the
ability to run those in the browser of your choice. I see no reason for
other people to add more including your dukescript, the product is open
source and there is no reason not to create a module if you want to promote
your own project

And lastly because Dukescript is a commercial product (if you want no ads,
nag screen) i would say we should not even consider it as a potential risk
long term alternative to swing. There are other free alternatives and these
should be considered as and when there is actually a need to do.

This conversation has gone on long enough, can we please re focus on
netbeans.

On 15 Mar 2018 14:59, <to...@eppleton.de> wrote:

> These things can happen in parallel. I for my part cannot help much
> with Python or Groovy features, but I can help with the POCs to
> improve NB UI and make it future proof. If for example we manage to
> replace JavaFX WebView with something better, contributors like Chris
> Lenz will be able to use more HTML5 features for writing their plugins
> and the performance of HTML-based plugins will improve.
>
> Maybe some of the Swing/JavaFX developers will also try it out and
> realize that developing with modern ui patterns like MVVM can
> dramatically speed up development, and lead to more testable and
> stable code while reducing the LOC. This would have the immediate
> effect of better code that needs less maintenance.
>
> But we can also offer them a way to still run their ( in my opinion
> horribly archaic 😊 ) Swing code.
>
> As a side effect we could also replace the embedded Browser for
> debugging web applications with a real browser and make Web
> Development in NB even more attractive. Projects like the Oracle JET
> support in NetBeans, but also EE projects could directly benefit from
that.
>
> You're right these changes are driven by longer term goals, but they
> will also create huge short term improvements.
>
> And since there's a lot of confusion here between "web technologies"
> and "web applications": I for my part don't want to run NetBeans in a
Browser.
> I want NetBeans to remain a traditional Desktop application, which can
> use modern HTML5 UIs and is prepared for the end of Swing.
>
> --Toni
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Wade Chandler <wa...@apache.org>
> Gesendet: Donnerstag, 15. März 2018 14:40
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove
> JavaFXfromOracle JDK
>
>
> > On Mar 15, 2018, at 8:54 AM, Neil C Smith <ne...@apache.org> wrote:
> >
> > Anyway, this whole thing is going a bit in circles. We need to look
> > at improving the POCs in NetBeans to be able to show where (and
> > where
> > not) this approach is viable and useful.
> >
>
> Agreed, but I think, so IMO, those just take us off the things that
> will actually have direct and immediate impacts. We can work on NB
> just as it is, and work to fix the index lock issues, add new Java
> parsing, add better language and feature support for some things like
> Groovy and Python, and generally move ahead, even while fixing some
> issues in Swing/AWT, or bog down in all this talk of web UIs which
> starts to make a lot of work which in the end didn’t really move the
> needle because we’ll still have a desktop IDE, but a lot of time would
have been spent to just get further behind.
>
> Wade
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail:
> dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail:
> dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

AW: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[to...@eppleton.de]

Peter,

Did I say MVVM is a technology? Are we using MVVM with Swing? HTML/Java uses it, so it would be new (and in my opinion) better way from what we've got.

Running the IDE in a Browser means, at least in my interpretation, that the program logic is executed in the browser. With HTML/Java the logic is running in the JVM, only the view is rendered in HTML. That is the difference.

Where did I propose to use DukeScript Presenters or DukeScript proprietary stuff for any of this? I only mentioned it as an example to show it's possible to use other renderers than JavaFX WebView.

I'm beginning to feel Jaroslav's pain.

--Toni

-----Ursprüngliche Nachricht-----
Von: Peter Steele <st...@gmail.com> 
Gesendet: Donnerstag, 15. März 2018 17:01
An: dev@netbeans.incubator.apache.org
Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

Toni

MVVM is an architecture, not a technology. You can use any technology to implement it (there are even some that use swing).

If you want the whole ui rendered in HTML 5, you need something to parse html, CSS and JavaScript. Which, despite what you say, needs a browser like rendering engine. Which brings us back to running an ide in a browser. If there was no javafx, swing or awt what would dukescript use as the rendering engine?

Netbeans already has good support for web technologies, and already has the ability to run those in the browser of your choice. I see no reason for other people to add more including your dukescript, the product is open source and there is no reason not to create a module if you want to promote your own project

And lastly because Dukescript is a commercial product (if you want no ads, nag screen) i would say we should not even consider it as a potential risk long term alternative to swing. There are other free alternatives and these should be considered as and when there is actually a need to do.

This conversation has gone on long enough, can we please re focus on netbeans.

On 15 Mar 2018 14:59, <to...@eppleton.de> wrote:

> These things can happen in parallel. I for my part cannot help much 
> with Python or Groovy features, but I can help with the POCs to 
> improve NB UI and make it future proof. If for example we manage to 
> replace JavaFX WebView with something better, contributors like Chris 
> Lenz will be able to use more HTML5 features for writing their plugins 
> and the performance of HTML-based plugins will improve.
>
> Maybe some of the Swing/JavaFX developers will also try it out and 
> realize that developing with modern ui patterns like MVVM can 
> dramatically speed up development, and lead to more testable and 
> stable code while reducing the LOC. This would have the immediate 
> effect of better code that needs less maintenance.
>
> But we can also offer them a way to still run their ( in my opinion 
> horribly archaic 😊 ) Swing code.
>
> As a side effect we could also replace the embedded Browser for 
> debugging web applications with a real browser and make Web 
> Development in NB even more attractive. Projects like the Oracle JET 
> support in NetBeans, but also EE projects could directly benefit from that.
>
> You're right these changes are driven by longer term goals, but they 
> will also create huge short term improvements.
>
> And since there's a lot of confusion here between "web technologies" 
> and "web applications": I for my part don't want to run NetBeans in a Browser.
> I want NetBeans to remain a traditional Desktop application, which can 
> use modern HTML5 UIs and is prepared for the end of Swing.
>
> --Toni
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Wade Chandler <wa...@apache.org>
> Gesendet: Donnerstag, 15. März 2018 14:40
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove 
> JavaFXfromOracle JDK
>
>
> > On Mar 15, 2018, at 8:54 AM, Neil C Smith <ne...@apache.org> wrote:
> >
> > Anyway, this whole thing is going a bit in circles. We need to look 
> > at improving the POCs in NetBeans to be able to show where (and 
> > where
> > not) this approach is viable and useful.
> >
>
> Agreed, but I think, so IMO, those just take us off the things that 
> will actually have direct and immediate impacts. We can work on NB 
> just as it is, and work to fix the index lock issues, add new Java 
> parsing, add better language and feature support for some things like 
> Groovy and Python, and generally move ahead, even while fixing some 
> issues in Swing/AWT, or bog down in all this talk of web UIs which 
> starts to make a lot of work which in the end didn’t really move the 
> needle because we’ll still have a desktop IDE, but a lot of time would have been spent to just get further behind.
>
> Wade
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: 
> dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: 
> dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Peter Steele <st...@gmail.com>]

Toni

MVVM is an architecture, not a technology. You can use any technology to
implement it (there are even some that use swing).

If you want the whole ui rendered in HTML 5, you need something to parse
html, CSS and JavaScript. Which, despite what you say, needs a browser like
rendering engine. Which brings us back to running an ide in a browser. If
there was no javafx, swing or awt what would dukescript use as the
rendering engine?

Netbeans already has good support for web technologies, and already has the
ability to run those in the browser of your choice. I see no reason for
other people to add more including your dukescript, the product is open
source and there is no reason not to create a module if you want to promote
your own project

And lastly because Dukescript is a commercial product (if you want no ads,
nag screen) i would say we should not even consider it as a potential risk
long term alternative to swing. There are other free alternatives and these
should be considered as and when there is actually a need to do.

This conversation has gone on long enough, can we please re focus on
netbeans.

On 15 Mar 2018 14:59, <to...@eppleton.de> wrote:

> These things can happen in parallel. I for my part cannot help much with
> Python or Groovy features, but I can help with the POCs to improve NB UI
> and make it future proof. If for example we manage to replace JavaFX
> WebView with something better, contributors like Chris Lenz will be able to
> use more HTML5 features for writing their plugins and the performance of
> HTML-based plugins will improve.
>
> Maybe some of the Swing/JavaFX developers will also try it out and realize
> that developing with modern ui patterns like MVVM can dramatically speed up
> development, and lead to more testable and stable code while reducing the
> LOC. This would have the immediate effect of better code that needs less
> maintenance.
>
> But we can also offer them a way to still run their ( in my opinion
> horribly archaic 😊 ) Swing code.
>
> As a side effect we could also replace the embedded Browser for debugging
> web applications with a real browser and make Web Development in NB even
> more attractive. Projects like the Oracle JET support in NetBeans, but also
> EE projects could directly benefit from that.
>
> You're right these changes are driven by longer term goals, but they will
> also create huge short term improvements.
>
> And since there's a lot of confusion here between "web technologies" and
> "web applications": I for my part don't want to run NetBeans in a Browser.
> I want NetBeans to remain a traditional Desktop application, which can use
> modern HTML5 UIs and is prepared for the end of Swing.
>
> --Toni
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Wade Chandler <wa...@apache.org>
> Gesendet: Donnerstag, 15. März 2018 14:40
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove
> JavaFXfromOracle JDK
>
>
> > On Mar 15, 2018, at 8:54 AM, Neil C Smith <ne...@apache.org> wrote:
> >
> > Anyway, this whole thing is going a bit in circles. We need to look at
> > improving the POCs in NetBeans to be able to show where (and where
> > not) this approach is viable and useful.
> >
>
> Agreed, but I think, so IMO, those just take us off the things that will
> actually have direct and immediate impacts. We can work on NB just as it
> is, and work to fix the index lock issues, add new Java parsing, add better
> language and feature support for some things like Groovy and Python, and
> generally move ahead, even while fixing some issues in Swing/AWT, or bog
> down in all this talk of web UIs which starts to make a lot of work which
> in the end didn’t really move the needle because we’ll still have a desktop
> IDE, but a lot of time would have been spent to just get further behind.
>
> Wade
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Wade Chandler <wa...@apache.org>]

On Mar 15, 2018 10:59, <to...@eppleton.de> wrote:

These things can happen in parallel. I for my part cannot help much with
Python or Groovy features, but I can help with the POCs to improve NB UI
and make it future proof. If for example we manage to replace JavaFX
WebView with something better, contributors like Chris Lenz will be able to
use more HTML5 features for writing their plugins and the performance of
HTML-based plugins will improve.


I agree with that.

Maybe some of the Swing/JavaFX developers will also try it out and realize
that developing with modern ui patterns like MVVM can dramatically speed up
development, and lead to more testable and stable code while reducing the
LOC. This would have the immediate effect of better code that needs less
maintenance.


MVVM is certainly possible now considering the components already have
their own model, so VM there, then other logic is a translation of the
Angular concept of a service, and data models which differ from the
component model is that. Now, one can certainly write better or worse UI
code in a tightly coupled manner. But, and I have seen it, one can also do
that with Angular. So, I get what you are saying here, and only agree in
that there are plenty of people who don't know how to decouple UI logic,
and the Angular style guide does a better job of getting people down the
right path than the Swing tutorials.

But we can also offer them a way to still run their ( in my opinion
horribly archaic 😊 ) Swing code.


Ha...see what you did there. You have gone to the dark side, but it's cool.
I still like you!


As a side effect we could also replace the embedded Browser for debugging
web applications with a real browser and make Web Development in NB even
more attractive. Projects like the Oracle JET support in NetBeans, but also
EE projects could directly benefit from that.


Yeah, as part of the web support, such things sound reasonable for those
purposes no matter what.

You're right these changes are driven by longer term goals, but they will
also create huge short term improvements.


I will wait to see on it then. In the mean time I will work on my parallel
bits :-)

And since there's a lot of confusion here between "web technologies" and
"web applications": I for my part don't want to run NetBeans in a Browser.
I want NetBeans to remain a traditional Desktop application, which can use
modern HTML5 UIs


Got it.

and is prepared for the end of Swing.


Dark man; dark. Lol.

Thanks

Wade

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[to...@eppleton.de]

These things can happen in parallel. I for my part cannot help much with Python or Groovy features, but I can help with the POCs to improve NB UI and make it future proof. If for example we manage to replace JavaFX WebView with something better, contributors like Chris Lenz will be able to use more HTML5 features for writing their plugins and the performance of HTML-based plugins will improve.

Maybe some of the Swing/JavaFX developers will also try it out and realize that developing with modern ui patterns like MVVM can dramatically speed up development, and lead to more testable and stable code while reducing the LOC. This would have the immediate effect of better code that needs less maintenance. 

But we can also offer them a way to still run their ( in my opinion horribly archaic 😊 ) Swing code.

As a side effect we could also replace the embedded Browser for debugging web applications with a real browser and make Web Development in NB even more attractive. Projects like the Oracle JET support in NetBeans, but also EE projects could directly benefit from that. 

You're right these changes are driven by longer term goals, but they will also create huge short term improvements.  

And since there's a lot of confusion here between "web technologies" and "web applications": I for my part don't want to run NetBeans in a Browser. I want NetBeans to remain a traditional Desktop application, which can use modern HTML5 UIs and is prepared for the end of Swing.

--Toni



-----Ursprüngliche Nachricht-----
Von: Wade Chandler <wa...@apache.org> 
Gesendet: Donnerstag, 15. März 2018 14:40
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK


> On Mar 15, 2018, at 8:54 AM, Neil C Smith <ne...@apache.org> wrote:
> 
> Anyway, this whole thing is going a bit in circles. We need to look at 
> improving the POCs in NetBeans to be able to show where (and where 
> not) this approach is viable and useful.
> 

Agreed, but I think, so IMO, those just take us off the things that will actually have direct and immediate impacts. We can work on NB just as it is, and work to fix the index lock issues, add new Java parsing, add better language and feature support for some things like Groovy and Python, and generally move ahead, even while fixing some issues in Swing/AWT, or bog down in all this talk of web UIs which starts to make a lot of work which in the end didn’t really move the needle because we’ll still have a desktop IDE, but a lot of time would have been spent to just get further behind.

Wade


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Wade Chandler <wa...@apache.org>]

> On Mar 15, 2018, at 8:54 AM, Neil C Smith <ne...@apache.org> wrote:
> 
> Anyway, this whole thing is going a bit in circles. We need to look at
> improving the POCs in NetBeans to be able to show where (and where not)
> this approach is viable and useful.
> 

Agreed, but I think, so IMO, those just take us off the things that will actually have direct and immediate impacts. We can work on NB just as it is, and work to fix the index lock issues, add new Java parsing, add better language and feature support for some things like Groovy and Python, and generally move ahead, even while fixing some issues in Swing/AWT, or bog down in all this talk of web UIs which starts to make a lot of work which in the end didn’t really move the needle because we’ll still have a desktop IDE, but a lot of time would have been spent to just get further behind.

Wade


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Neil C Smith <ne...@apache.org>]

On Thu, 15 Mar 2018, 02:54 Chuck Davis, <cj...@gmail.com> wrote:

> The only reason I've heard for using HTML is it looks better.  Well, if you
> don't like the looks of Swing change the L&F!  If there's no L&F you like,
> create one.
>

You do realise the relative difference in workload involved there?!

 But I know VERY well
> what business users need; browsers can't cut it but Swing provides
> everything the financial side of businesses need and want.
>

I'll be the first one to say I don't think a HTML toolkit is going to cut
it for all cases, but have you seriously looked at and used any of the
browser-based financial packages aimed at SME's? It's possible to build a
UI / UX at least as productive as Swing there, and it's potentially easier
to develop too.

Anyway, this whole thing is going a bit in circles. We need to look at
improving the POCs in NetBeans to be able to show where (and where not)
this approach is viable and useful.

Best wishes,

Neil


-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[cowwoc <co...@bbs.darktech.org>]

Chuck,

My main beef with AWT/Swing is one of API design first, bugs second, and 
performance last.

I think there is a real opportunity here but it is a difficult one to 
solve in an open-source context. I think open-source communities are 
great for fixing bugs and implementing features but they are not great 
for API design. I wish we had someone like Joshua Bloch in charge of 
designing a new API that would sit on top of AWT/Swing, provide 
equivalent functionality as the original, but with a clean API. I also 
believe that it is vital to gradually break backwards compatiblity over 
time (as Google Guava does) in order to end up with a better API long-term.

My goal is to make UI development as easy under Java as it is for the 
web. For the vast majority of use-cases, technical performance is not 
the bottleneck. Developer productivity is. I want an API that faciliates 
building Filthy Rich Clients, similar to Android/iOS applications we're 
all familiar with that ooze UI goodness.

Gili

On 2018-03-14 10:53 PM, Chuck Davis wrote:
> Gili:
>
> So now that they are no longer in charge (it's open source now) let's fix
> AWT/Swing/FX and start marketing.  We're in charge now.  Or did I take a
> nap and miss something?   Ultimately, perhaps not in the short term, you
> get market share by providing a demonstrably better alternative.
>
> We agree on one thing and that is how horrible are browsers for getting
> real work done and the level of coding skills -- anybody can make a web
> site these days -- and they look like it.  It's like VBA making everybody
> who writes a macro in excel think they are a programmer.  I've heard that
> in offices:  "I'm programming an excel sheet."
>
> The only reason I've heard for using HTML is it looks better.  Well, if you
> don't like the looks of Swing change the L&F!  If there's no L&F you like,
> create one.  Don't throw the baby out with the bath water as they say.
> Maybe NB needs to start a L&F contest?
>
> One of the problems with this whole discussion is that there is such a wide
> variety of interests.  I happen to be from a business background and
> specifically financial interests.  I got into programming because the
> software I had to use (MOST accounting software) was so poor.  I learned
> what I needed to get the job done (I wasn't being paid to be a programmer)
> and, unfortunately, because of that I never got the academic background the
> smart people here have about render pipelines, etc.  But I know VERY well
> what business users need; browsers can't cut it but Swing provides
> everything the financial side of businesses need and want.
>
> Now if your use case is disseminating information to either internal or
> external users and providing file downloads there is no better tool than a
> browser.  For doing company handbooks, training films, etc. NOBODY wants to
> use Swing in that case.  Things that move and bob are not welcome in a
> business use case but they're all the rage (and appropriate) for
> information dissemination.  For business use cases "pretty" and "cute" are
> unwelcome -- we want functionality.  For a browser "pretty" and "cute" are
> what it's all about -- HTML is the right tool.
>
> The corollary to that is the audience.  There is a vast difference between
> 250 people placing an order at a web site in a day (a browser is quite
> appropriate here) and the AP clerk who has to record 250 AP invoices every
> day (or even one day!).  With a heads down, efficient data entry Swing
> dialog that clerk can process 250 invoices in a relatively short time (and
> time IS money).  Giving that poor clerk a browser interface to struggle
> with is a mean thing to do to an employee.  Swing provides a great focus
> traversal policy -- FX is even easier and better.
>
> Use the right tool for the use case.
>
> I do desktop apps -- give me Swing/FX.  Christian does web apps -- give him
> a browser.  NB can handle them both and handle them nicely....er, well, at
> least as nicely as HTML/browsers can be made to work.
>
>
>
>
> On Wed, Mar 14, 2018 at 5:58 PM, cowwoc <co...@bbs.darktech.org> wrote:
>
>> Chuck, I appreciate free software as much as the next guy. But I still
>> blame Sun and Oracle for killing AWT/Swing.
>>
>> If they wanted more community contributions they could have opened up the
>> bug reporting system, faciliated pull requests, and shown that they are
>> acting in good faith. They chose to pursue a one-way conversation and it
>> cost them the market.
>>
>> So yes, I appreciate what we got but ultimately Oracle bares the
>> responsibility for AWT/Swing/JavaFX dying. Oracle is not a B2C company and
>> these technologies requires a company that excels at marketing to end-users.
>>
>> Gili
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Chuck Davis <cj...@gmail.com>]

Gili:

So now that they are no longer in charge (it's open source now) let's fix
AWT/Swing/FX and start marketing.  We're in charge now.  Or did I take a
nap and miss something?   Ultimately, perhaps not in the short term, you
get market share by providing a demonstrably better alternative.

We agree on one thing and that is how horrible are browsers for getting
real work done and the level of coding skills -- anybody can make a web
site these days -- and they look like it.  It's like VBA making everybody
who writes a macro in excel think they are a programmer.  I've heard that
in offices:  "I'm programming an excel sheet."

The only reason I've heard for using HTML is it looks better.  Well, if you
don't like the looks of Swing change the L&F!  If there's no L&F you like,
create one.  Don't throw the baby out with the bath water as they say.
Maybe NB needs to start a L&F contest?

One of the problems with this whole discussion is that there is such a wide
variety of interests.  I happen to be from a business background and
specifically financial interests.  I got into programming because the
software I had to use (MOST accounting software) was so poor.  I learned
what I needed to get the job done (I wasn't being paid to be a programmer)
and, unfortunately, because of that I never got the academic background the
smart people here have about render pipelines, etc.  But I know VERY well
what business users need; browsers can't cut it but Swing provides
everything the financial side of businesses need and want.

Now if your use case is disseminating information to either internal or
external users and providing file downloads there is no better tool than a
browser.  For doing company handbooks, training films, etc. NOBODY wants to
use Swing in that case.  Things that move and bob are not welcome in a
business use case but they're all the rage (and appropriate) for
information dissemination.  For business use cases "pretty" and "cute" are
unwelcome -- we want functionality.  For a browser "pretty" and "cute" are
what it's all about -- HTML is the right tool.

The corollary to that is the audience.  There is a vast difference between
250 people placing an order at a web site in a day (a browser is quite
appropriate here) and the AP clerk who has to record 250 AP invoices every
day (or even one day!).  With a heads down, efficient data entry Swing
dialog that clerk can process 250 invoices in a relatively short time (and
time IS money).  Giving that poor clerk a browser interface to struggle
with is a mean thing to do to an employee.  Swing provides a great focus
traversal policy -- FX is even easier and better.

Use the right tool for the use case.

I do desktop apps -- give me Swing/FX.  Christian does web apps -- give him
a browser.  NB can handle them both and handle them nicely....er, well, at
least as nicely as HTML/browsers can be made to work.




On Wed, Mar 14, 2018 at 5:58 PM, cowwoc <co...@bbs.darktech.org> wrote:

> Chuck, I appreciate free software as much as the next guy. But I still
> blame Sun and Oracle for killing AWT/Swing.
>
> If they wanted more community contributions they could have opened up the
> bug reporting system, faciliated pull requests, and shown that they are
> acting in good faith. They chose to pursue a one-way conversation and it
> cost them the market.
>
> So yes, I appreciate what we got but ultimately Oracle bares the
> responsibility for AWT/Swing/JavaFX dying. Oracle is not a B2C company and
> these technologies requires a company that excels at marketing to end-users.
>
> Gili
>
>

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[cowwoc <co...@bbs.darktech.org>]

Chuck, I appreciate free software as much as the next guy. But I still 
blame Sun and Oracle for killing AWT/Swing.

If they wanted more community contributions they could have opened up 
the bug reporting system, faciliated pull requests, and shown that they 
are acting in good faith. They chose to pursue a one-way conversation 
and it cost them the market.

So yes, I appreciate what we got but ultimately Oracle bares the 
responsibility for AWT/Swing/JavaFX dying. Oracle is not a B2C company 
and these technologies requires a company that excels at marketing to 
end-users.

Gili

On 2018-03-14 4:04 PM, Chuck Davis wrote:
> So, what are you waiting for?
> https://wiki.openjdk.java.net/display/OpenJFX/Main will be more than happy
> to suck up some energy from you.
>
> Sorry, I guess I'm in a snarky mood today but I just get so tired of
> everybody ragging on Oracle.  How long has OpenJDK been the source and
> Oracle has been doctoring it to make it usable?  Now it has a shiny, new
> rendering engine for AWT/Swing; they don't have to screw around upgrading
> rendering with every release.  What else should we (the Community) be doing
> for Java to make it more usable?  What bugs have any of us here fixed (I
> know some of you have done many and you are herewith thanked for your
> efforts)?
>
> Same can be said for OpenJFX.
>
> As far as I know Oracle and IBM are the only companies that have been
> taking OpenJDK and doctoring it to improve it enough to be released (and
> IBM has never included JFX).  Maybe they're tired of the drag we've been.
>
> PS  I am not and never have been an Oracle employee.  I don't get
> commissions for sales of their products.  I'm just another freeloader like
> the rest of you whiners and complainers (trust me, I've done my share).
>
> PPS  Doubly snarky benefits being dished out today -- free as in beer.
>
>
> On Wed, Mar 14, 2018 at 11:53 AM, Norquay <ja...@norquay.com> wrote:
>
>>   JavaFX would be faster than WebGL if it got some developer energy pumped
>> into it.  O is so fucking brain dead...
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Chuck Davis <cj...@gmail.com>]

So, what are you waiting for?
https://wiki.openjdk.java.net/display/OpenJFX/Main will be more than happy
to suck up some energy from you.

Sorry, I guess I'm in a snarky mood today but I just get so tired of
everybody ragging on Oracle.  How long has OpenJDK been the source and
Oracle has been doctoring it to make it usable?  Now it has a shiny, new
rendering engine for AWT/Swing; they don't have to screw around upgrading
rendering with every release.  What else should we (the Community) be doing
for Java to make it more usable?  What bugs have any of us here fixed (I
know some of you have done many and you are herewith thanked for your
efforts)?

Same can be said for OpenJFX.

As far as I know Oracle and IBM are the only companies that have been
taking OpenJDK and doctoring it to improve it enough to be released (and
IBM has never included JFX).  Maybe they're tired of the drag we've been.

PS  I am not and never have been an Oracle employee.  I don't get
commissions for sales of their products.  I'm just another freeloader like
the rest of you whiners and complainers (trust me, I've done my share).

PPS  Doubly snarky benefits being dished out today -- free as in beer.


On Wed, Mar 14, 2018 at 11:53 AM, Norquay <ja...@norquay.com> wrote:

>  JavaFX would be faster than WebGL if it got some developer energy pumped
> into it.  O is so fucking brain dead...
>

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Norquay <ja...@norquay.com>]

Another way to look at is is, if web apps were so great, why are phone apps so dominant?  In the early days of the iPhone, their stock answer was “write web apps”.  That failed miserably, and they eventually caved in and allowed developers to write real apps.  JavaFX would be faster than WebGL if it got some developer energy pumped into it.  O is so fucking brain dead...


> On Mar 14, 2018, at 10:35 AM, cowwoc <co...@bbs.darktech.org> wrote:
> 
> I agree. If the web was such a great platform for desktop apps, you would have seen many other projects/companies porting complex desktop applications to it. They are not.
> 
> Web technologies are great for basic interfaces. They are utter garbage for Filty Rich Clients.
> 
> Don't repeat the mistake of ORMs: jumping on a technology because it looks great from far, only to discover that it doesn't do what you want when you're "95% done".
> 
> Gili
> 
> On 2018-03-14 6:58 AM, Peter Steele wrote:
>> One of the biggest limitations is the fact everything is single threaded.
>> This isn't related to vaadin and gwt.
>> 
>> I have used vaadin and like it alot, and to build certain types of
>> applications it is a great candidate if you are used to java. I have also
>> used GWT alot and have extended it for areas which it doesn't cover.
>> (Vaadin uses GWT too)
>> 
>> Another js pet hate for me is the fact it is not OO based, people have
>> tried to put wrappers around us but they inevitably have issues because
>> they are wrappers.
>> 
>> Chrome has a good debugger but compared to debugging support from desktop
>> languages it is inferior
>> 
>> The language is too visual basic like for my taste, it's nice and easy to
>> use but if you want to do anything complicated you are in trouble. Thumbs
>> up for closure support, thumbs down for the complete over use of closures.
>> 
>> Btw these are only my opinions, you may disagree with everything i say and
>> that is ok. I am in the camp of "i will never use a web based ide" but i
>> have no issues building apps that are designed for the web and work well on
>> the web (like for thin clients). Forcing everything in to the browser is
>> not they way forward.
>> 
>> 
>> On 14 Mar 2018 10:26, "Christian Lenz" <ch...@gmx.net> wrote:
>> 
>> Peter,
>> 
>> can you tell me which limitations you mean? As I wrote in an other thread,
>> the limitations came from GWT. The Problem is that a Java developer doesn’t
>> want to write HTML, CSS and JS so they are looking for an alternative. GWT
>> or Vaadin or kotlin to js, I can’t understand that, but ok. So please don’t
>> compare GWT or Vaadin with native JS.
>> 
>> 
>> Cheers
>> 
>> Chris
>> 
>> Von: Peter Steele
>> Gesendet: Montag, 12. März 2018 17:50
>> An: dev@netbeans.incubator.apache.org
>> Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove
>> JavaFXfromOracle JDK
>> 
>> Christian
>> 
>> I am sure electron is good, but my personal preference is to not use a web
>> ide. Javascript as a language has a lot of limitations. I have written gwt
>> code to export java to html and you are limited a lot in how you design
>> your apps.
>> 
>> On 12 Mar 2018 16:40, "Christian Lenz" <ch...@gmx.net> wrote:
>> 
>>> Have a look into electron apps. A lot of apps are written with this
>>> Framework like VS Code and I think this is a big Player and you can see,
>>> that it performs very well and it is performant as hell. Only to say one
>> of
>>> those apps.
>>> 
>>> 
>>> Cheers
>>> 
>>> Chris
>>> Von: Peter Steele
>>> Gesendet: Montag, 12. März 2018 17:37
>>> An: dev@netbeans.incubator.apache.org
>>> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX
>>> fromOracle JDK
>>> 
>>> What about the eclipse RCP framework which uses swt? This would seem to be
>>> a much better solution than having a html front end.
>>> 
>>> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>>> 
>>>> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
>>>> wrote:
>>>> 
>>>>> Forget about AWT, Swing and JavaFX - the future is HTML. In case you
>>>> still
>>>>> care about Java, then your future should be Apache HTML/Java API!
>>>>> 
>>>> Generally inclined to agree with you - definitely on forgetting JavaFX,
>>> and
>>>> probably on forgetting AWT/Swing (intrigued to see what actually happens
>>>> there).  I don't think HTML is the only game in town, but for a lot of
>>>> things it's probably the right way forward.
>>>> 
>>>> But, if we start turning to Apache HTML/Java way, what does it run in?
>>>> 
>>>> Out of interest, I was looking at an example project using Vaadin
>> running
>>>> inside Electron recently.  Have you tried this approach with HTML/Java?
>>>> 
>>>> Best wishes,
>>>> 
>>>> Neil
>>>> --
>>>> Neil C Smith
>>>> Artist & Technologist
>>>> www.neilcsmith.net
>>>> 
>>>> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>>>> 
>>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

AW: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK

[Christian Lenz <ch...@gmx.net>]

I think it is not really about Performance, I mean yes it is a part of it, but for me it is a mess to create the UI with atm the Mantisse Editor, which I pointed my biggest breakpoint fewer in the thread. Sure, it is one Point but for me it was never been easier to create good, nice, fancy how ever you want that the UI Looks like, UIs with my/web Technologies. Years ago we had WinForms, looked like Win NT and 95 style. Now we want to create nice UIs, century save not UIs decades ago. Sure it could be possible, but not that easy. Then you have Win32 API to create the UIs via real C/C++ Code. Then you have Qt to QXML where you create the UI with XML, like in Android. It is XML. HTML is for sure a bit different from XML but the way is clear I think.

JavaFX was for me an alternative to create good looking UIs with XML based designing and moving too. Same for C# WPF with XAML. So you can see a similarity of those Frameworks all brings XML based UI grid with a Styling which is similar to CSS because this is what works out best and you have to full Control.

Why I didn’t use JavaFX much, because, I tried to search, whether there is a way to create UIs, only the UIs with binding and interaction in HTML, because this is my eco System, my daily Business, I know much of it to know how to write it and been fast to create such UIs, you are working with Swing or JavaFX and you are fast with those Technologies. The Thing is, HTML is an alternative, it shouldn’t be a Limitation to say not swing, not javafx only HTML, it should be possible to say, hey we have Swing OR JavaFX or HTML so why not using it, if it is still possible?

At the Moment, what Ionic does and HTML4J, they use the WebView so a Little browser to render the HTML, but there could be an other Approach, what NativeScript does. It maps the UI to native controls or CodenameOne too, I think. This could be also good, if you think HTML within the WebView could be slows down the application. Just map (easier to say, I know) to native swing or javafx controls or whatever.


Cheers

Chris 

Gesendet von Mail für Windows 10

Von: toni.epple@eppleton.de
Gesendet: Mittwoch, 14. März 2018 23:57
An: dev@netbeans.incubator.apache.org
Betreff: AW: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK

Hi Christian,

You're experiencing something all the Java devs had to go through 10 years ago, when everyone still told us Java/Swing is so slow, and will never be able to keep up with real programming languages/native UIs, while we were coding really huge and fast Applications with it. 

It takes some time until these prejudices wear off. Don't worry, it will slowly get better in 10 years or so 😉. 

Cheers

Toni




-----Ursprüngliche Nachricht-----
Von: Christian Lenz <ch...@gmx.net> 
Gesendet: Mittwoch, 14. März 2018 19:48
An: dev@netbeans.incubator.apache.org
Betreff: AW: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK

So the example from Github, with Atom and the example of Microsoft with VS Code or Slack with the Desktop app, is not valuable enough for you? VS Code is such a fast DIE/Editor. And valuable against sublime for sure. It is very stable, is the most contributed Project on github etc. So I think yes there are such apps out there who are willing to try electron. And you can take a look here to see a lot of apps where built with electron: https://github.com/sindresorhus/awesome-electron. It is not because it is hip but it is an ecosystem for frontend developers who wants to create good looking Desktop apps with our Technology which is JS, HTML, and CSS. The same for GWT or Vaadin for Backend devs, who wants work in the frontend. I don’t say you have to and I don’t say it is the wholy grail, but it is a good alternative and not that bad.


Cheers

Chris

Von: cowwoc
Gesendet: Mittwoch, 14. März 2018 18:35
An: dev@netbeans.incubator.apache.org
Betreff: Re: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK

I agree. If the web was such a great platform for desktop apps, you would have seen many other projects/companies porting complex desktop applications to it. They are not.

Web technologies are great for basic interfaces. They are utter garbage for Filty Rich Clients.

Don't repeat the mistake of ORMs: jumping on a technology because it looks great from far, only to discover that it doesn't do what you want when you're "95% done".

Gili

On 2018-03-14 6:58 AM, Peter Steele wrote:
> One of the biggest limitations is the fact everything is single threaded.
> This isn't related to vaadin and gwt.
>
> I have used vaadin and like it alot, and to build certain types of 
> applications it is a great candidate if you are used to java. I have 
> also used GWT alot and have extended it for areas which it doesn't cover.
> (Vaadin uses GWT too)
>
> Another js pet hate for me is the fact it is not OO based, people have 
> tried to put wrappers around us but they inevitably have issues 
> because they are wrappers.
>
> Chrome has a good debugger but compared to debugging support from 
> desktop languages it is inferior
>
> The language is too visual basic like for my taste, it's nice and easy 
> to use but if you want to do anything complicated you are in trouble. 
> Thumbs up for closure support, thumbs down for the complete over use of closures.
>
> Btw these are only my opinions, you may disagree with everything i say 
> and that is ok. I am in the camp of "i will never use a web based ide" 
> but i have no issues building apps that are designed for the web and 
> work well on the web (like for thin clients). Forcing everything in to 
> the browser is not they way forward.
>
>
> On 14 Mar 2018 10:26, "Christian Lenz" <ch...@gmx.net> wrote:
>
> Peter,
>
> can you tell me which limitations you mean? As I wrote in an other 
> thread, the limitations came from GWT. The Problem is that a Java 
> developer doesn’t want to write HTML, CSS and JS so they are looking 
> for an alternative. GWT or Vaadin or kotlin to js, I can’t understand 
> that, but ok. So please don’t compare GWT or Vaadin with native JS.
>
>
> Cheers
>
> Chris
>
> Von: Peter Steele
> Gesendet: Montag, 12. März 2018 17:50
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove 
> JavaFXfromOracle JDK
>
> Christian
>
> I am sure electron is good, but my personal preference is to not use a 
> web ide. Javascript as a language has a lot of limitations. I have 
> written gwt code to export java to html and you are limited a lot in 
> how you design your apps.
>
> On 12 Mar 2018 16:40, "Christian Lenz" <ch...@gmx.net> wrote:
>
>> Have a look into electron apps. A lot of apps are written with this 
>> Framework like VS Code and I think this is a big Player and you can 
>> see, that it performs very well and it is performant as hell. Only to 
>> say one
> of
>> those apps.
>>
>>
>> Cheers
>>
>> Chris
>> Von: Peter Steele
>> Gesendet: Montag, 12. März 2018 17:37
>> An: dev@netbeans.incubator.apache.org
>> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove 
>> JavaFX fromOracle JDK
>>
>> What about the eclipse RCP framework which uses swt? This would seem 
>> to be a much better solution than having a html front end.
>>
>> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>>
>>> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach 
>>> <ja...@gmail.com>
>>> wrote:
>>>
>>>> Forget about AWT, Swing and JavaFX - the future is HTML. In case 
>>>> you
>>> still
>>>> care about Java, then your future should be Apache HTML/Java API!
>>>>
>>> Generally inclined to agree with you - definitely on forgetting 
>>> JavaFX,
>> and
>>> probably on forgetting AWT/Swing (intrigued to see what actually 
>>> happens there).  I don't think HTML is the only game in town, but 
>>> for a lot of things it's probably the right way forward.
>>>
>>> But, if we start turning to Apache HTML/Java way, what does it run in?
>>>
>>> Out of interest, I was looking at an example project using Vaadin
> running
>>> inside Electron recently.  Have you tried this approach with HTML/Java?
>>>
>>> Best wishes,
>>>
>>> Neil
>>> --
>>> Neil C Smith
>>> Artist & Technologist
>>> www.neilcsmith.net
>>>
>>> Praxis LIVE - hybrid visual IDE for creative coding - 
>>> www.praxislive.org
>>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists






---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: AW: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK

[cowwoc <co...@bbs.darktech.org>]

The problem with browser UIs is not their performance (although that's 
not great either). The problem is development productivity is utter crap.

The obvious problem is the lack of consistency between browsers, OSs, 
and even versions thereof. The less obvious problem is the constant 
churn: features that used to work no longer do, the constant need to 
"upgrade" your framework, the total inability to produce non-trivial 
visual layouts, etc.

Any idiot can make a form user interface. HTML/CSS/JS is great for this 
but it is literally the easiest thing a UI framework can provide. People 
are happy with these frameworks because the bar has been set so low. A 
few years ago we were blown away by people doing drag-n-drop on the web.

Come on people. It's 1990 all over again.

So again... the amazing thing about web technologies is not web 
technologies. It's the low learning curve. It's the fact that millions 
of people can now write shit code (whereas before they couldn't code at 
all).

If you could provide this same experience with Java, or any other 
technology, then people would flock to it the same way that they flock 
to web development today.

Ironically, the main thing keeping first-time developers away from Java 
is Sun and Oracle's inability to internalize the User Experience. If 
they invested more in client-side development they would inevitably have 
to care more about the user experience of coding. Had they done this 
they could have displaced Javascript as the de-facto web programming 
language.

Gili

On 2018-03-14 6:57 PM, toni.epple@eppleton.de wrote:
> Hi Christian,
>
> You're experiencing something all the Java devs had to go through 10 years ago, when everyone still told us Java/Swing is so slow, and will never be able to keep up with real programming languages/native UIs, while we were coding really huge and fast Applications with it.
>
> It takes some time until these prejudices wear off. Don't worry, it will slowly get better in 10 years or so 😉.
>
> Cheers
>
> Toni
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Christian Lenz <ch...@gmx.net>
> Gesendet: Mittwoch, 14. März 2018 19:48
> An: dev@netbeans.incubator.apache.org
> Betreff: AW: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK
>
> So the example from Github, with Atom and the example of Microsoft with VS Code or Slack with the Desktop app, is not valuable enough for you? VS Code is such a fast DIE/Editor. And valuable against sublime for sure. It is very stable, is the most contributed Project on github etc. So I think yes there are such apps out there who are willing to try electron. And you can take a look here to see a lot of apps where built with electron: https://github.com/sindresorhus/awesome-electron. It is not because it is hip but it is an ecosystem for frontend developers who wants to create good looking Desktop apps with our Technology which is JS, HTML, and CSS. The same for GWT or Vaadin for Backend devs, who wants work in the frontend. I don’t say you have to and I don’t say it is the wholy grail, but it is a good alternative and not that bad.
>
>
> Cheers
>
> Chris
>
> Von: cowwoc
> Gesendet: Mittwoch, 14. März 2018 18:35
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK
>
> I agree. If the web was such a great platform for desktop apps, you would have seen many other projects/companies porting complex desktop applications to it. They are not.
>
> Web technologies are great for basic interfaces. They are utter garbage for Filty Rich Clients.
>
> Don't repeat the mistake of ORMs: jumping on a technology because it looks great from far, only to discover that it doesn't do what you want when you're "95% done".
>
> Gili
>
> On 2018-03-14 6:58 AM, Peter Steele wrote:
>> One of the biggest limitations is the fact everything is single threaded.
>> This isn't related to vaadin and gwt.
>>
>> I have used vaadin and like it alot, and to build certain types of
>> applications it is a great candidate if you are used to java. I have
>> also used GWT alot and have extended it for areas which it doesn't cover.
>> (Vaadin uses GWT too)
>>
>> Another js pet hate for me is the fact it is not OO based, people have
>> tried to put wrappers around us but they inevitably have issues
>> because they are wrappers.
>>
>> Chrome has a good debugger but compared to debugging support from
>> desktop languages it is inferior
>>
>> The language is too visual basic like for my taste, it's nice and easy
>> to use but if you want to do anything complicated you are in trouble.
>> Thumbs up for closure support, thumbs down for the complete over use of closures.
>>
>> Btw these are only my opinions, you may disagree with everything i say
>> and that is ok. I am in the camp of "i will never use a web based ide"
>> but i have no issues building apps that are designed for the web and
>> work well on the web (like for thin clients). Forcing everything in to
>> the browser is not they way forward.
>>
>>
>> On 14 Mar 2018 10:26, "Christian Lenz" <ch...@gmx.net> wrote:
>>
>> Peter,
>>
>> can you tell me which limitations you mean? As I wrote in an other
>> thread, the limitations came from GWT. The Problem is that a Java
>> developer doesn’t want to write HTML, CSS and JS so they are looking
>> for an alternative. GWT or Vaadin or kotlin to js, I can’t understand
>> that, but ok. So please don’t compare GWT or Vaadin with native JS.
>>
>>
>> Cheers
>>
>> Chris
>>
>> Von: Peter Steele
>> Gesendet: Montag, 12. März 2018 17:50
>> An: dev@netbeans.incubator.apache.org
>> Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove
>> JavaFXfromOracle JDK
>>
>> Christian
>>
>> I am sure electron is good, but my personal preference is to not use a
>> web ide. Javascript as a language has a lot of limitations. I have
>> written gwt code to export java to html and you are limited a lot in
>> how you design your apps.
>>
>> On 12 Mar 2018 16:40, "Christian Lenz" <ch...@gmx.net> wrote:
>>
>>> Have a look into electron apps. A lot of apps are written with this
>>> Framework like VS Code and I think this is a big Player and you can
>>> see, that it performs very well and it is performant as hell. Only to
>>> say one
>> of
>>> those apps.
>>>
>>>
>>> Cheers
>>>
>>> Chris
>>> Von: Peter Steele
>>> Gesendet: Montag, 12. März 2018 17:37
>>> An: dev@netbeans.incubator.apache.org
>>> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove
>>> JavaFX fromOracle JDK
>>>
>>> What about the eclipse RCP framework which uses swt? This would seem
>>> to be a much better solution than having a html front end.
>>>
>>> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>>>
>>>> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach
>>>> <ja...@gmail.com>
>>>> wrote:
>>>>
>>>>> Forget about AWT, Swing and JavaFX - the future is HTML. In case
>>>>> you
>>>> still
>>>>> care about Java, then your future should be Apache HTML/Java API!
>>>>>
>>>> Generally inclined to agree with you - definitely on forgetting
>>>> JavaFX,
>>> and
>>>> probably on forgetting AWT/Swing (intrigued to see what actually
>>>> happens there).  I don't think HTML is the only game in town, but
>>>> for a lot of things it's probably the right way forward.
>>>>
>>>> But, if we start turning to Apache HTML/Java way, what does it run in?
>>>>
>>>> Out of interest, I was looking at an example project using Vaadin
>> running
>>>> inside Electron recently.  Have you tried this approach with HTML/Java?
>>>>
>>>> Best wishes,
>>>>
>>>> Neil
>>>> --
>>>> Neil C Smith
>>>> Artist & Technologist
>>>> www.neilcsmith.net
>>>>
>>>> Praxis LIVE - hybrid visual IDE for creative coding -
>>>> www.praxislive.org
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

AW: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK

[to...@eppleton.de]

Hi Christian,

You're experiencing something all the Java devs had to go through 10 years ago, when everyone still told us Java/Swing is so slow, and will never be able to keep up with real programming languages/native UIs, while we were coding really huge and fast Applications with it. 

It takes some time until these prejudices wear off. Don't worry, it will slowly get better in 10 years or so 😉. 

Cheers

Toni




-----Ursprüngliche Nachricht-----
Von: Christian Lenz <ch...@gmx.net> 
Gesendet: Mittwoch, 14. März 2018 19:48
An: dev@netbeans.incubator.apache.org
Betreff: AW: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK

So the example from Github, with Atom and the example of Microsoft with VS Code or Slack with the Desktop app, is not valuable enough for you? VS Code is such a fast DIE/Editor. And valuable against sublime for sure. It is very stable, is the most contributed Project on github etc. So I think yes there are such apps out there who are willing to try electron. And you can take a look here to see a lot of apps where built with electron: https://github.com/sindresorhus/awesome-electron. It is not because it is hip but it is an ecosystem for frontend developers who wants to create good looking Desktop apps with our Technology which is JS, HTML, and CSS. The same for GWT or Vaadin for Backend devs, who wants work in the frontend. I don’t say you have to and I don’t say it is the wholy grail, but it is a good alternative and not that bad.


Cheers

Chris

Von: cowwoc
Gesendet: Mittwoch, 14. März 2018 18:35
An: dev@netbeans.incubator.apache.org
Betreff: Re: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK

I agree. If the web was such a great platform for desktop apps, you would have seen many other projects/companies porting complex desktop applications to it. They are not.

Web technologies are great for basic interfaces. They are utter garbage for Filty Rich Clients.

Don't repeat the mistake of ORMs: jumping on a technology because it looks great from far, only to discover that it doesn't do what you want when you're "95% done".

Gili

On 2018-03-14 6:58 AM, Peter Steele wrote:
> One of the biggest limitations is the fact everything is single threaded.
> This isn't related to vaadin and gwt.
>
> I have used vaadin and like it alot, and to build certain types of 
> applications it is a great candidate if you are used to java. I have 
> also used GWT alot and have extended it for areas which it doesn't cover.
> (Vaadin uses GWT too)
>
> Another js pet hate for me is the fact it is not OO based, people have 
> tried to put wrappers around us but they inevitably have issues 
> because they are wrappers.
>
> Chrome has a good debugger but compared to debugging support from 
> desktop languages it is inferior
>
> The language is too visual basic like for my taste, it's nice and easy 
> to use but if you want to do anything complicated you are in trouble. 
> Thumbs up for closure support, thumbs down for the complete over use of closures.
>
> Btw these are only my opinions, you may disagree with everything i say 
> and that is ok. I am in the camp of "i will never use a web based ide" 
> but i have no issues building apps that are designed for the web and 
> work well on the web (like for thin clients). Forcing everything in to 
> the browser is not they way forward.
>
>
> On 14 Mar 2018 10:26, "Christian Lenz" <ch...@gmx.net> wrote:
>
> Peter,
>
> can you tell me which limitations you mean? As I wrote in an other 
> thread, the limitations came from GWT. The Problem is that a Java 
> developer doesn’t want to write HTML, CSS and JS so they are looking 
> for an alternative. GWT or Vaadin or kotlin to js, I can’t understand 
> that, but ok. So please don’t compare GWT or Vaadin with native JS.
>
>
> Cheers
>
> Chris
>
> Von: Peter Steele
> Gesendet: Montag, 12. März 2018 17:50
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove 
> JavaFXfromOracle JDK
>
> Christian
>
> I am sure electron is good, but my personal preference is to not use a 
> web ide. Javascript as a language has a lot of limitations. I have 
> written gwt code to export java to html and you are limited a lot in 
> how you design your apps.
>
> On 12 Mar 2018 16:40, "Christian Lenz" <ch...@gmx.net> wrote:
>
>> Have a look into electron apps. A lot of apps are written with this 
>> Framework like VS Code and I think this is a big Player and you can 
>> see, that it performs very well and it is performant as hell. Only to 
>> say one
> of
>> those apps.
>>
>>
>> Cheers
>>
>> Chris
>> Von: Peter Steele
>> Gesendet: Montag, 12. März 2018 17:37
>> An: dev@netbeans.incubator.apache.org
>> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove 
>> JavaFX fromOracle JDK
>>
>> What about the eclipse RCP framework which uses swt? This would seem 
>> to be a much better solution than having a html front end.
>>
>> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>>
>>> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach 
>>> <ja...@gmail.com>
>>> wrote:
>>>
>>>> Forget about AWT, Swing and JavaFX - the future is HTML. In case 
>>>> you
>>> still
>>>> care about Java, then your future should be Apache HTML/Java API!
>>>>
>>> Generally inclined to agree with you - definitely on forgetting 
>>> JavaFX,
>> and
>>> probably on forgetting AWT/Swing (intrigued to see what actually 
>>> happens there).  I don't think HTML is the only game in town, but 
>>> for a lot of things it's probably the right way forward.
>>>
>>> But, if we start turning to Apache HTML/Java way, what does it run in?
>>>
>>> Out of interest, I was looking at an example project using Vaadin
> running
>>> inside Electron recently.  Have you tried this approach with HTML/Java?
>>>
>>> Best wishes,
>>>
>>> Neil
>>> --
>>> Neil C Smith
>>> Artist & Technologist
>>> www.neilcsmith.net
>>>
>>> Praxis LIVE - hybrid visual IDE for creative coding - 
>>> www.praxislive.org
>>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists






---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: AW: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK

[Antonio <an...@vieiro.net>]

Hey,

Add also gitkraken [1] to the list of cool, fast, developer-oriented UIs 
you can do with libchromiumcontent [2].

libchromiumcontent is BSD licensed, by the way, and is cross platform 
and also well maintained.

Now that JavaFX (GPL/CPE) is going to be a separate download from the 
JDK, I wonder what the difference would be between a JavaFX download or 
a libchromiumcontent swing-enabled component download would be.

Cheers,
Antonio


[1]
https://www.gitkraken.com/features

[2]
https://github.com/electron/libchromiumcontent/tree/f0d7c2dc0d44960069a2d8b0a9f7c5722ceeb259

I don't think java-cef is a wrapper around libchromiumcontent, or is it?
https://github.com/chromiumembedded/java-cef

On 14/03/18 19:48, Christian Lenz wrote:
> So the example from Github, with Atom and the example of Microsoft with VS Code or Slack with the Desktop app, is not valuable enough for you? VS Code is such a fast DIE/Editor. And valuable against sublime for sure. It is very stable, is the most contributed Project on github etc. So I think yes there are such apps out there who are willing to try electron. And you can take a look here to see a lot of apps where built with electron: https://github.com/sindresorhus/awesome-electron. It is not because it is hip but it is an ecosystem for frontend developers who wants to create good looking Desktop apps with our Technology which is JS, HTML, and CSS. The same for GWT or Vaadin for Backend devs, who wants work in the frontend. I don’t say you have to and I don’t say it is the wholy grail, but it is a good alternative and not that bad.
> 
> 
> Cheers
> 
> Chris
> 
> Von: cowwoc
> Gesendet: Mittwoch, 14. März 2018 18:35
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK
> 
> I agree. If the web was such a great platform for desktop apps, you
> would have seen many other projects/companies porting complex desktop
> applications to it. They are not.
> 
> Web technologies are great for basic interfaces. They are utter garbage
> for Filty Rich Clients.
> 
> Don't repeat the mistake of ORMs: jumping on a technology because it
> looks great from far, only to discover that it doesn't do what you want
> when you're "95% done".
> 
> Gili
> 
> On 2018-03-14 6:58 AM, Peter Steele wrote:
>> One of the biggest limitations is the fact everything is single threaded.
>> This isn't related to vaadin and gwt.
>>
>> I have used vaadin and like it alot, and to build certain types of
>> applications it is a great candidate if you are used to java. I have also
>> used GWT alot and have extended it for areas which it doesn't cover.
>> (Vaadin uses GWT too)
>>
>> Another js pet hate for me is the fact it is not OO based, people have
>> tried to put wrappers around us but they inevitably have issues because
>> they are wrappers.
>>
>> Chrome has a good debugger but compared to debugging support from desktop
>> languages it is inferior
>>
>> The language is too visual basic like for my taste, it's nice and easy to
>> use but if you want to do anything complicated you are in trouble. Thumbs
>> up for closure support, thumbs down for the complete over use of closures.
>>
>> Btw these are only my opinions, you may disagree with everything i say and
>> that is ok. I am in the camp of "i will never use a web based ide" but i
>> have no issues building apps that are designed for the web and work well on
>> the web (like for thin clients). Forcing everything in to the browser is
>> not they way forward.
>>
>>
>> On 14 Mar 2018 10:26, "Christian Lenz" <ch...@gmx.net> wrote:
>>
>> Peter,
>>
>> can you tell me which limitations you mean? As I wrote in an other thread,
>> the limitations came from GWT. The Problem is that a Java developer doesn’t
>> want to write HTML, CSS and JS so they are looking for an alternative. GWT
>> or Vaadin or kotlin to js, I can’t understand that, but ok. So please don’t
>> compare GWT or Vaadin with native JS.
>>
>>
>> Cheers
>>
>> Chris
>>
>> Von: Peter Steele
>> Gesendet: Montag, 12. März 2018 17:50
>> An: dev@netbeans.incubator.apache.org
>> Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove
>> JavaFXfromOracle JDK
>>
>> Christian
>>
>> I am sure electron is good, but my personal preference is to not use a web
>> ide. Javascript as a language has a lot of limitations. I have written gwt
>> code to export java to html and you are limited a lot in how you design
>> your apps.
>>
>> On 12 Mar 2018 16:40, "Christian Lenz" <ch...@gmx.net> wrote:
>>
>>> Have a look into electron apps. A lot of apps are written with this
>>> Framework like VS Code and I think this is a big Player and you can see,
>>> that it performs very well and it is performant as hell. Only to say one
>> of
>>> those apps.
>>>
>>>
>>> Cheers
>>>
>>> Chris
>>> Von: Peter Steele
>>> Gesendet: Montag, 12. März 2018 17:37
>>> An: dev@netbeans.incubator.apache.org
>>> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX
>>> fromOracle JDK
>>>
>>> What about the eclipse RCP framework which uses swt? This would seem to be
>>> a much better solution than having a html front end.
>>>
>>> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>>>
>>>> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
>>>> wrote:
>>>>
>>>>> Forget about AWT, Swing and JavaFX - the future is HTML. In case you
>>>> still
>>>>> care about Java, then your future should be Apache HTML/Java API!
>>>>>
>>>> Generally inclined to agree with you - definitely on forgetting JavaFX,
>>> and
>>>> probably on forgetting AWT/Swing (intrigued to see what actually happens
>>>> there).  I don't think HTML is the only game in town, but for a lot of
>>>> things it's probably the right way forward.
>>>>
>>>> But, if we start turning to Apache HTML/Java way, what does it run in?
>>>>
>>>> Out of interest, I was looking at an example project using Vaadin
>> running
>>>> inside Electron recently.  Have you tried this approach with HTML/Java?
>>>>
>>>> Best wishes,
>>>>
>>>> Neil
>>>> --
>>>> Neil C Smith
>>>> Artist & Technologist
>>>> www.neilcsmith.net
>>>>
>>>> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>>>>
>>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> 
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

AW: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK

[Christian Lenz <ch...@gmx.net>]

So the example from Github, with Atom and the example of Microsoft with VS Code or Slack with the Desktop app, is not valuable enough for you? VS Code is such a fast DIE/Editor. And valuable against sublime for sure. It is very stable, is the most contributed Project on github etc. So I think yes there are such apps out there who are willing to try electron. And you can take a look here to see a lot of apps where built with electron: https://github.com/sindresorhus/awesome-electron. It is not because it is hip but it is an ecosystem for frontend developers who wants to create good looking Desktop apps with our Technology which is JS, HTML, and CSS. The same for GWT or Vaadin for Backend devs, who wants work in the frontend. I don’t say you have to and I don’t say it is the wholy grail, but it is a good alternative and not that bad.


Cheers

Chris

Von: cowwoc
Gesendet: Mittwoch, 14. März 2018 18:35
An: dev@netbeans.incubator.apache.org
Betreff: Re: AW: AW: Apache HTML/Java UI instead of ... Oracle will removeJavaFXfromOracle JDK

I agree. If the web was such a great platform for desktop apps, you 
would have seen many other projects/companies porting complex desktop 
applications to it. They are not.

Web technologies are great for basic interfaces. They are utter garbage 
for Filty Rich Clients.

Don't repeat the mistake of ORMs: jumping on a technology because it 
looks great from far, only to discover that it doesn't do what you want 
when you're "95% done".

Gili

On 2018-03-14 6:58 AM, Peter Steele wrote:
> One of the biggest limitations is the fact everything is single threaded.
> This isn't related to vaadin and gwt.
>
> I have used vaadin and like it alot, and to build certain types of
> applications it is a great candidate if you are used to java. I have also
> used GWT alot and have extended it for areas which it doesn't cover.
> (Vaadin uses GWT too)
>
> Another js pet hate for me is the fact it is not OO based, people have
> tried to put wrappers around us but they inevitably have issues because
> they are wrappers.
>
> Chrome has a good debugger but compared to debugging support from desktop
> languages it is inferior
>
> The language is too visual basic like for my taste, it's nice and easy to
> use but if you want to do anything complicated you are in trouble. Thumbs
> up for closure support, thumbs down for the complete over use of closures.
>
> Btw these are only my opinions, you may disagree with everything i say and
> that is ok. I am in the camp of "i will never use a web based ide" but i
> have no issues building apps that are designed for the web and work well on
> the web (like for thin clients). Forcing everything in to the browser is
> not they way forward.
>
>
> On 14 Mar 2018 10:26, "Christian Lenz" <ch...@gmx.net> wrote:
>
> Peter,
>
> can you tell me which limitations you mean? As I wrote in an other thread,
> the limitations came from GWT. The Problem is that a Java developer doesn’t
> want to write HTML, CSS and JS so they are looking for an alternative. GWT
> or Vaadin or kotlin to js, I can’t understand that, but ok. So please don’t
> compare GWT or Vaadin with native JS.
>
>
> Cheers
>
> Chris
>
> Von: Peter Steele
> Gesendet: Montag, 12. März 2018 17:50
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove
> JavaFXfromOracle JDK
>
> Christian
>
> I am sure electron is good, but my personal preference is to not use a web
> ide. Javascript as a language has a lot of limitations. I have written gwt
> code to export java to html and you are limited a lot in how you design
> your apps.
>
> On 12 Mar 2018 16:40, "Christian Lenz" <ch...@gmx.net> wrote:
>
>> Have a look into electron apps. A lot of apps are written with this
>> Framework like VS Code and I think this is a big Player and you can see,
>> that it performs very well and it is performant as hell. Only to say one
> of
>> those apps.
>>
>>
>> Cheers
>>
>> Chris
>> Von: Peter Steele
>> Gesendet: Montag, 12. März 2018 17:37
>> An: dev@netbeans.incubator.apache.org
>> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX
>> fromOracle JDK
>>
>> What about the eclipse RCP framework which uses swt? This would seem to be
>> a much better solution than having a html front end.
>>
>> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>>
>>> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
>>> wrote:
>>>
>>>> Forget about AWT, Swing and JavaFX - the future is HTML. In case you
>>> still
>>>> care about Java, then your future should be Apache HTML/Java API!
>>>>
>>> Generally inclined to agree with you - definitely on forgetting JavaFX,
>> and
>>> probably on forgetting AWT/Swing (intrigued to see what actually happens
>>> there).  I don't think HTML is the only game in town, but for a lot of
>>> things it's probably the right way forward.
>>>
>>> But, if we start turning to Apache HTML/Java way, what does it run in?
>>>
>>> Out of interest, I was looking at an example project using Vaadin
> running
>>> inside Electron recently.  Have you tried this approach with HTML/Java?
>>>
>>> Best wishes,
>>>
>>> Neil
>>> --
>>> Neil C Smith
>>> Artist & Technologist
>>> www.neilcsmith.net
>>>
>>> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Paul Franz <pa...@oracle.com>]

Gili,
    I agree with you the browsers are not as performant as desktop 
applications. Here is the one thing that I have run into on the Windows 
platform and that it is becoming more difficult to deploy applications 
on Windows because Anti-Virus thinks anything with an Embedded JVM is 
infected.

Paul Franz
Senior Principal Applications Engineer
Oracle Transportation Management


On 14 Mar 2018, at 13:35, cowwoc wrote:

> I agree. If the web was such a great platform for desktop apps, you 
> would have seen many other projects/companies porting complex desktop 
> applications to it. They are not.
>
> Web technologies are great for basic interfaces. They are utter 
> garbage for Filty Rich Clients.
>
> Don't repeat the mistake of ORMs: jumping on a technology because it 
> looks great from far, only to discover that it doesn't do what you 
> want when you're "95% done".
>
> Gili
>
> On 2018-03-14 6:58 AM, Peter Steele wrote:
>> One of the biggest limitations is the fact everything is single 
>> threaded.
>> This isn't related to vaadin and gwt.
>>
>> I have used vaadin and like it alot, and to build certain types of
>> applications it is a great candidate if you are used to java. I have 
>> also
>> used GWT alot and have extended it for areas which it doesn't cover.
>> (Vaadin uses GWT too)
>>
>> Another js pet hate for me is the fact it is not OO based, people 
>> have
>> tried to put wrappers around us but they inevitably have issues 
>> because
>> they are wrappers.
>>
>> Chrome has a good debugger but compared to debugging support from 
>> desktop
>> languages it is inferior
>>
>> The language is too visual basic like for my taste, it's nice and 
>> easy to
>> use but if you want to do anything complicated you are in trouble. 
>> Thumbs
>> up for closure support, thumbs down for the complete over use of 
>> closures.
>>
>> Btw these are only my opinions, you may disagree with everything i 
>> say and
>> that is ok. I am in the camp of "i will never use a web based ide" 
>> but i
>> have no issues building apps that are designed for the web and work 
>> well on
>> the web (like for thin clients). Forcing everything in to the browser 
>> is
>> not they way forward.
>>
>>
>> On 14 Mar 2018 10:26, "Christian Lenz" <ch...@gmx.net> 
>> wrote:
>>
>> Peter,
>>
>> can you tell me which limitations you mean? As I wrote in an other 
>> thread,
>> the limitations came from GWT. The Problem is that a Java developer 
>> doesn’t
>> want to write HTML, CSS and JS so they are looking for an 
>> alternative. GWT
>> or Vaadin or kotlin to js, I can’t understand that, but ok. So 
>> please don’t
>> compare GWT or Vaadin with native JS.
>>
>>
>> Cheers
>>
>> Chris
>>
>> Von: Peter Steele
>> Gesendet: Montag, 12. März 2018 17:50
>> An: dev@netbeans.incubator.apache.org
>> Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will 
>> remove
>> JavaFXfromOracle JDK
>>
>> Christian
>>
>> I am sure electron is good, but my personal preference is to not use 
>> a web
>> ide. Javascript as a language has a lot of limitations. I have 
>> written gwt
>> code to export java to html and you are limited a lot in how you 
>> design
>> your apps.
>>
>> On 12 Mar 2018 16:40, "Christian Lenz" <ch...@gmx.net> 
>> wrote:
>>
>>> Have a look into electron apps. A lot of apps are written with this
>>> Framework like VS Code and I think this is a big Player and you can 
>>> see,
>>> that it performs very well and it is performant as hell. Only to say 
>>> one
>> of
>>> those apps.
>>>
>>>
>>> Cheers
>>>
>>> Chris
>>> Von: Peter Steele
>>> Gesendet: Montag, 12. März 2018 17:37
>>> An: dev@netbeans.incubator.apache.org
>>> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove 
>>> JavaFX
>>> fromOracle JDK
>>>
>>> What about the eclipse RCP framework which uses swt? This would seem 
>>> to be
>>> a much better solution than having a html front end.
>>>
>>> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>>>
>>>> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach 
>>>> <ja...@gmail.com>
>>>> wrote:
>>>>
>>>>> Forget about AWT, Swing and JavaFX - the future is HTML. In case 
>>>>> you
>>>> still
>>>>> care about Java, then your future should be Apache HTML/Java API!
>>>>>
>>>> Generally inclined to agree with you - definitely on forgetting 
>>>> JavaFX,
>>> and
>>>> probably on forgetting AWT/Swing (intrigued to see what actually 
>>>> happens
>>>> there).  I don't think HTML is the only game in town, but for a lot 
>>>> of
>>>> things it's probably the right way forward.
>>>>
>>>> But, if we start turning to Apache HTML/Java way, what does it run 
>>>> in?
>>>>
>>>> Out of interest, I was looking at an example project using Vaadin
>> running
>>>> inside Electron recently.  Have you tried this approach with 
>>>> HTML/Java?
>>>>
>>>> Best wishes,
>>>>
>>>> Neil
>>>> --
>>>> Neil C Smith
>>>> Artist & Technologist
>>>> www.neilcsmith.net
>>>>
>>>> Praxis LIVE - hybrid visual IDE for creative coding - 
>>>> www.praxislive.org
>>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: 
> dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_NETBEANS_Mailing-2Blists&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=FjvsW90PKoOYMVsj6ymexkCdiXoDvGSnRuj2IoGocmg&m=tDo6z0V-TlksKeSq2kjJT_s9I61C87vYLvvLGY9UTeA&s=kaO1tx2p945HSKimf5mw4f_jpZ6Zzw5KU_krNkE4seU&e=

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: AW: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[cowwoc <co...@bbs.darktech.org>]

I agree. If the web was such a great platform for desktop apps, you 
would have seen many other projects/companies porting complex desktop 
applications to it. They are not.

Web technologies are great for basic interfaces. They are utter garbage 
for Filty Rich Clients.

Don't repeat the mistake of ORMs: jumping on a technology because it 
looks great from far, only to discover that it doesn't do what you want 
when you're "95% done".

Gili

On 2018-03-14 6:58 AM, Peter Steele wrote:
> One of the biggest limitations is the fact everything is single threaded.
> This isn't related to vaadin and gwt.
>
> I have used vaadin and like it alot, and to build certain types of
> applications it is a great candidate if you are used to java. I have also
> used GWT alot and have extended it for areas which it doesn't cover.
> (Vaadin uses GWT too)
>
> Another js pet hate for me is the fact it is not OO based, people have
> tried to put wrappers around us but they inevitably have issues because
> they are wrappers.
>
> Chrome has a good debugger but compared to debugging support from desktop
> languages it is inferior
>
> The language is too visual basic like for my taste, it's nice and easy to
> use but if you want to do anything complicated you are in trouble. Thumbs
> up for closure support, thumbs down for the complete over use of closures.
>
> Btw these are only my opinions, you may disagree with everything i say and
> that is ok. I am in the camp of "i will never use a web based ide" but i
> have no issues building apps that are designed for the web and work well on
> the web (like for thin clients). Forcing everything in to the browser is
> not they way forward.
>
>
> On 14 Mar 2018 10:26, "Christian Lenz" <ch...@gmx.net> wrote:
>
> Peter,
>
> can you tell me which limitations you mean? As I wrote in an other thread,
> the limitations came from GWT. The Problem is that a Java developer doesn’t
> want to write HTML, CSS and JS so they are looking for an alternative. GWT
> or Vaadin or kotlin to js, I can’t understand that, but ok. So please don’t
> compare GWT or Vaadin with native JS.
>
>
> Cheers
>
> Chris
>
> Von: Peter Steele
> Gesendet: Montag, 12. März 2018 17:50
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove
> JavaFXfromOracle JDK
>
> Christian
>
> I am sure electron is good, but my personal preference is to not use a web
> ide. Javascript as a language has a lot of limitations. I have written gwt
> code to export java to html and you are limited a lot in how you design
> your apps.
>
> On 12 Mar 2018 16:40, "Christian Lenz" <ch...@gmx.net> wrote:
>
>> Have a look into electron apps. A lot of apps are written with this
>> Framework like VS Code and I think this is a big Player and you can see,
>> that it performs very well and it is performant as hell. Only to say one
> of
>> those apps.
>>
>>
>> Cheers
>>
>> Chris
>> Von: Peter Steele
>> Gesendet: Montag, 12. März 2018 17:37
>> An: dev@netbeans.incubator.apache.org
>> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX
>> fromOracle JDK
>>
>> What about the eclipse RCP framework which uses swt? This would seem to be
>> a much better solution than having a html front end.
>>
>> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>>
>>> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
>>> wrote:
>>>
>>>> Forget about AWT, Swing and JavaFX - the future is HTML. In case you
>>> still
>>>> care about Java, then your future should be Apache HTML/Java API!
>>>>
>>> Generally inclined to agree with you - definitely on forgetting JavaFX,
>> and
>>> probably on forgetting AWT/Swing (intrigued to see what actually happens
>>> there).  I don't think HTML is the only game in town, but for a lot of
>>> things it's probably the right way forward.
>>>
>>> But, if we start turning to Apache HTML/Java way, what does it run in?
>>>
>>> Out of interest, I was looking at an example project using Vaadin
> running
>>> inside Electron recently.  Have you tried this approach with HTML/Java?
>>>
>>> Best wishes,
>>>
>>> Neil
>>> --
>>> Neil C Smith
>>> Artist & Technologist
>>> www.neilcsmith.net
>>>
>>> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: AW: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Peter Steele <st...@gmail.com>]

One of the biggest limitations is the fact everything is single threaded.
This isn't related to vaadin and gwt.

I have used vaadin and like it alot, and to build certain types of
applications it is a great candidate if you are used to java. I have also
used GWT alot and have extended it for areas which it doesn't cover.
(Vaadin uses GWT too)

Another js pet hate for me is the fact it is not OO based, people have
tried to put wrappers around us but they inevitably have issues because
they are wrappers.

Chrome has a good debugger but compared to debugging support from desktop
languages it is inferior

The language is too visual basic like for my taste, it's nice and easy to
use but if you want to do anything complicated you are in trouble. Thumbs
up for closure support, thumbs down for the complete over use of closures.

Btw these are only my opinions, you may disagree with everything i say and
that is ok. I am in the camp of "i will never use a web based ide" but i
have no issues building apps that are designed for the web and work well on
the web (like for thin clients). Forcing everything in to the browser is
not they way forward.


On 14 Mar 2018 10:26, "Christian Lenz" <ch...@gmx.net> wrote:

Peter,

can you tell me which limitations you mean? As I wrote in an other thread,
the limitations came from GWT. The Problem is that a Java developer doesn’t
want to write HTML, CSS and JS so they are looking for an alternative. GWT
or Vaadin or kotlin to js, I can’t understand that, but ok. So please don’t
compare GWT or Vaadin with native JS.


Cheers

Chris

Von: Peter Steele
Gesendet: Montag, 12. März 2018 17:50
An: dev@netbeans.incubator.apache.org
Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove
JavaFXfromOracle JDK

Christian

I am sure electron is good, but my personal preference is to not use a web
ide. Javascript as a language has a lot of limitations. I have written gwt
code to export java to html and you are limited a lot in how you design
your apps.

On 12 Mar 2018 16:40, "Christian Lenz" <ch...@gmx.net> wrote:

> Have a look into electron apps. A lot of apps are written with this
> Framework like VS Code and I think this is a big Player and you can see,
> that it performs very well and it is performant as hell. Only to say one
of
> those apps.
>
>
> Cheers
>
> Chris
> Von: Peter Steele
> Gesendet: Montag, 12. März 2018 17:37
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX
> fromOracle JDK
>
> What about the eclipse RCP framework which uses swt? This would seem to be
> a much better solution than having a html front end.
>
> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>
> > On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
> > wrote:
> >
> > > Forget about AWT, Swing and JavaFX - the future is HTML. In case you
> > still
> > > care about Java, then your future should be Apache HTML/Java API!
> > >
> >
> > Generally inclined to agree with you - definitely on forgetting JavaFX,
> and
> > probably on forgetting AWT/Swing (intrigued to see what actually happens
> > there).  I don't think HTML is the only game in town, but for a lot of
> > things it's probably the right way forward.
> >
> > But, if we start turning to Apache HTML/Java way, what does it run in?
> >
> > Out of interest, I was looking at an example project using Vaadin
running
> > inside Electron recently.  Have you tried this approach with HTML/Java?
> >
> > Best wishes,
> >
> > Neil
> > --
> > Neil C Smith
> > Artist & Technologist
> > www.neilcsmith.net
> >
> > Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
> >
>
>

AW: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Christian Lenz <ch...@gmx.net>]

Peter,

can you tell me which limitations you mean? As I wrote in an other thread, the limitations came from GWT. The Problem is that a Java developer doesn’t want to write HTML, CSS and JS so they are looking for an alternative. GWT or Vaadin or kotlin to js, I can’t understand that, but ok. So please don’t compare GWT or Vaadin with native JS.


Cheers

Chris

Von: Peter Steele
Gesendet: Montag, 12. März 2018 17:50
An: dev@netbeans.incubator.apache.org
Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

Christian

I am sure electron is good, but my personal preference is to not use a web
ide. Javascript as a language has a lot of limitations. I have written gwt
code to export java to html and you are limited a lot in how you design
your apps.

On 12 Mar 2018 16:40, "Christian Lenz" <ch...@gmx.net> wrote:

> Have a look into electron apps. A lot of apps are written with this
> Framework like VS Code and I think this is a big Player and you can see,
> that it performs very well and it is performant as hell. Only to say one of
> those apps.
>
>
> Cheers
>
> Chris
> Von: Peter Steele
> Gesendet: Montag, 12. März 2018 17:37
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX
> fromOracle JDK
>
> What about the eclipse RCP framework which uses swt? This would seem to be
> a much better solution than having a html front end.
>
> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>
> > On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
> > wrote:
> >
> > > Forget about AWT, Swing and JavaFX - the future is HTML. In case you
> > still
> > > care about Java, then your future should be Apache HTML/Java API!
> > >
> >
> > Generally inclined to agree with you - definitely on forgetting JavaFX,
> and
> > probably on forgetting AWT/Swing (intrigued to see what actually happens
> > there).  I don't think HTML is the only game in town, but for a lot of
> > things it's probably the right way forward.
> >
> > But, if we start turning to Apache HTML/Java way, what does it run in?
> >
> > Out of interest, I was looking at an example project using Vaadin running
> > inside Electron recently.  Have you tried this approach with HTML/Java?
> >
> > Best wishes,
> >
> > Neil
> > --
> > Neil C Smith
> > Artist & Technologist
> > www.neilcsmith.net
> >
> > Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
> >
>
>

Re: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX fromOracle JDK

[Peter Steele <st...@gmail.com>]

Christian

I am sure electron is good, but my personal preference is to not use a web
ide. Javascript as a language has a lot of limitations. I have written gwt
code to export java to html and you are limited a lot in how you design
your apps.

On 12 Mar 2018 16:40, "Christian Lenz" <ch...@gmx.net> wrote:

> Have a look into electron apps. A lot of apps are written with this
> Framework like VS Code and I think this is a big Player and you can see,
> that it performs very well and it is performant as hell. Only to say one of
> those apps.
>
>
> Cheers
>
> Chris
> Von: Peter Steele
> Gesendet: Montag, 12. März 2018 17:37
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX
> fromOracle JDK
>
> What about the eclipse RCP framework which uses swt? This would seem to be
> a much better solution than having a html front end.
>
> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>
> > On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
> > wrote:
> >
> > > Forget about AWT, Swing and JavaFX - the future is HTML. In case you
> > still
> > > care about Java, then your future should be Apache HTML/Java API!
> > >
> >
> > Generally inclined to agree with you - definitely on forgetting JavaFX,
> and
> > probably on forgetting AWT/Swing (intrigued to see what actually happens
> > there).  I don't think HTML is the only game in town, but for a lot of
> > things it's probably the right way forward.
> >
> > But, if we start turning to Apache HTML/Java way, what does it run in?
> >
> > Out of interest, I was looking at an example project using Vaadin running
> > inside Electron recently.  Have you tried this approach with HTML/Java?
> >
> > Best wishes,
> >
> > Neil
> > --
> > Neil C Smith
> > Artist & Technologist
> > www.neilcsmith.net
> >
> > Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
> >
>
>

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX fromOracle JDK

[Christian Lenz <ch...@gmx.net>]

Have a look into electron apps. A lot of apps are written with this Framework like VS Code and I think this is a big Player and you can see, that it performs very well and it is performant as hell. Only to say one of those apps.


Cheers

Chris
Von: Peter Steele
Gesendet: Montag, 12. März 2018 17:37
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX fromOracle JDK

What about the eclipse RCP framework which uses swt? This would seem to be
a much better solution than having a html front end.

On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:

> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
> wrote:
>
> > Forget about AWT, Swing and JavaFX - the future is HTML. In case you
> still
> > care about Java, then your future should be Apache HTML/Java API!
> >
>
> Generally inclined to agree with you - definitely on forgetting JavaFX, and
> probably on forgetting AWT/Swing (intrigued to see what actually happens
> there).  I don't think HTML is the only game in town, but for a lot of
> things it's probably the right way forward.
>
> But, if we start turning to Apache HTML/Java way, what does it run in?
>
> Out of interest, I was looking at an example project using Vaadin running
> inside Electron recently.  Have you tried this approach with HTML/Java?
>
> Best wishes,
>
> Neil
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Peter Steele <st...@gmail.com>]

And there is Apache pivot, being Apache maybe we could get help in any
migration if that was the path chosen

On 12 Mar 2018 16:39, "Peter Steele" <st...@gmail.com> wrote:

> To be clear (which i wasn't) i meant eclipse RCP is pretty popular, it
> uses swt as it's foundation. Could netbeans use swt as it's foundations too?
>
> On 12 Mar 2018 16:36, "Peter Steele" <st...@gmail.com> wrote:
>
>> What about the eclipse RCP framework which uses swt? This would seem to
>> be a much better solution than having a html front end.
>>
>> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>>
>>> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
>>> wrote:
>>>
>>> > Forget about AWT, Swing and JavaFX - the future is HTML. In case you
>>> still
>>> > care about Java, then your future should be Apache HTML/Java API!
>>> >
>>>
>>> Generally inclined to agree with you - definitely on forgetting JavaFX,
>>> and
>>> probably on forgetting AWT/Swing (intrigued to see what actually happens
>>> there).  I don't think HTML is the only game in town, but for a lot of
>>> things it's probably the right way forward.
>>>
>>> But, if we start turning to Apache HTML/Java way, what does it run in?
>>>
>>> Out of interest, I was looking at an example project using Vaadin running
>>> inside Electron recently.  Have you tried this approach with HTML/Java?
>>>
>>> Best wishes,
>>>
>>> Neil
>>> --
>>> Neil C Smith
>>> Artist & Technologist
>>> www.neilcsmith.net
>>>
>>> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>>>
>>

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Peter Steele <st...@gmail.com>]

To be clear (which i wasn't) i meant eclipse RCP is pretty popular, it uses
swt as it's foundation. Could netbeans use swt as it's foundations too?

On 12 Mar 2018 16:36, "Peter Steele" <st...@gmail.com> wrote:

> What about the eclipse RCP framework which uses swt? This would seem to be
> a much better solution than having a html front end.
>
> On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:
>
>> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
>> wrote:
>>
>> > Forget about AWT, Swing and JavaFX - the future is HTML. In case you
>> still
>> > care about Java, then your future should be Apache HTML/Java API!
>> >
>>
>> Generally inclined to agree with you - definitely on forgetting JavaFX,
>> and
>> probably on forgetting AWT/Swing (intrigued to see what actually happens
>> there).  I don't think HTML is the only game in town, but for a lot of
>> things it's probably the right way forward.
>>
>> But, if we start turning to Apache HTML/Java way, what does it run in?
>>
>> Out of interest, I was looking at an example project using Vaadin running
>> inside Electron recently.  Have you tried this approach with HTML/Java?
>>
>> Best wishes,
>>
>> Neil
>> --
>> Neil C Smith
>> Artist & Technologist
>> www.neilcsmith.net
>>
>> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>>
>

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Peter Steele <st...@gmail.com>]

What about the eclipse RCP framework which uses swt? This would seem to be
a much better solution than having a html front end.

On 12 Mar 2018 16:25, "Neil C Smith" <ne...@apache.org> wrote:

> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
> wrote:
>
> > Forget about AWT, Swing and JavaFX - the future is HTML. In case you
> still
> > care about Java, then your future should be Apache HTML/Java API!
> >
>
> Generally inclined to agree with you - definitely on forgetting JavaFX, and
> probably on forgetting AWT/Swing (intrigued to see what actually happens
> there).  I don't think HTML is the only game in town, but for a lot of
> things it's probably the right way forward.
>
> But, if we start turning to Apache HTML/Java way, what does it run in?
>
> Out of interest, I was looking at an example project using Vaadin running
> inside Electron recently.  Have you tried this approach with HTML/Java?
>
> Best wishes,
>
> Neil
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Neil C Smith <ne...@apache.org>]

On Mon, 12 Mar 2018 at 16:33 John Kostaras <jk...@gmail.com> wrote:

> If this is the case with the Java kingdom, then all these apps will move to
> other technologies that take advantage of the new hardware and the GPUs.
>

The Java kingdom does have quite a few of these things outside of the JDK
though.  That's why I said I don't think it's the only game in town.  There
are certain things that need that low-level hardware / GPU access,
including the things I work on myself and for others.   Not a lot of that
has anything to do with AWT / Swing, doesn't need to be in the JDK, and is
probably better off without AWT around (looking at you OSX /
startOnFirstThread!)

On Mon, 12 Mar 2018 at 16:37 Peter Steele <st...@gmail.com> wrote:

> What about the eclipse RCP framework which uses swt? This would seem to be
> a much better solution than having a html front end.


Eclipse is also building an IDE with a HTML front end! ;-)

On Mon, 12 Mar 2018 at 16:40 Christian Lenz <ch...@gmx.net> wrote:

> Have a look into electron apps. A lot of apps are written with this
> Framework like VS Code and I think this is a big Player and you can see,
> that it performs very well and it is performant as hell.
>

Mind you, I've spent a lot of the last couple of weeks in conversation with
people complaining about the performance and resource usage of Electron
apps too, including the coding environments!

Best wishes,

Neil

-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[John Kostaras <jk...@gmail.com>]

All very nice with HTML UI and the browser, but what about standalone apps
that need near real time performance. They cannot count on the browser and
on Javascript I 'm afraid. They need Swing and/or JavaFX or something
similar.

If this is the case with the Java kingdom, then all these apps will move to
other technologies that take advantage of the new hardware and the GPUs.

Regards,

John.

On 12 March 2018 at 17:25, Neil C Smith <ne...@apache.org> wrote:

> On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
> wrote:
>
> > Forget about AWT, Swing and JavaFX - the future is HTML. In case you
> still
> > care about Java, then your future should be Apache HTML/Java API!
> >
>
> Generally inclined to agree with you - definitely on forgetting JavaFX, and
> probably on forgetting AWT/Swing (intrigued to see what actually happens
> there).  I don't think HTML is the only game in town, but for a lot of
> things it's probably the right way forward.
>
> But, if we start turning to Apache HTML/Java way, what does it run in?
>
> Out of interest, I was looking at an example project using Vaadin running
> inside Electron recently.  Have you tried this approach with HTML/Java?
>
> Best wishes,
>
> Neil
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Neil C Smith <ne...@apache.org>]

On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach <ja...@gmail.com>
wrote:

> Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> care about Java, then your future should be Apache HTML/Java API!
>

Generally inclined to agree with you - definitely on forgetting JavaFX, and
probably on forgetting AWT/Swing (intrigued to see what actually happens
there).  I don't think HTML is the only game in town, but for a lot of
things it's probably the right way forward.

But, if we start turning to Apache HTML/Java way, what does it run in?

Out of interest, I was looking at an example project using Vaadin running
inside Electron recently.  Have you tried this approach with HTML/Java?

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Bernd Ruehlicke <be...@eriksfiord.com>]

Indeed, lets look forward, I have not looked at JavaScript as always 
being into heavy desktop Swing apps. Over the years it has helped me 
with a demo app showing all kind of features a given system allows me to 
use. Like a toolbox, which I run and say - hey that's the component I 
need. Is there something like this for the HTML+JAVA api ? Or some 
websites showing the current func?

Jaroslav, thanks for also looking forward and suggesting a way out of 
this swamp ... I will start looking into this.
Bernd

On 3/12/2018 10:59 AM, Jaroslav Tulach wrote:
>> "Oracle has begun conversations with interested parties in the Java
>> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
>>>>> referenced timeframes."
>>>>>
> The official announcement is here and people are finally starting to
> realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
> will sponsor development of anything new for these technologies. Even if
> they get transfered to their new owners, they will be in maintenance mode:
> Bugfixes and little features. No bigger changes - no new rendering
> pipelines using new nifty features of graphics cards. Just sustaining. I've
> been explaining this would happen since 2012.
>
> To help us out of this situation and save Java as a programming language I
> dedicated my days to smoothing out interoperability between Java and
> JavaScript with the goal to reuse the most flexible and portable rendering
> system of these days: the browser. My work has already been donated to
> Apache, see: https://github.com/apache/incubator-netbeans-html4j - let's
> use it to build new features of NetBeans and other future Java desktop
> applications. Get started by reading Javadoc at
> http://bits.netbeans.org/html+java/
>
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> care about Java, then your future should be Apache HTML/Java API!
> -jt
>

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[to...@eppleton.de]

Hi Neil, Emi and others, 

thanks for the constructive answers. I agree for NB we need to find an alternative to the current presenters. I also think with Browser, iOS and Android we've already proven to be capable of using anything you throw at us as a renderer 😉. CEF/Chromium would be an option (New BSD as far as I know, is that compatible). Although I think it's more important at the moment to focus on getting some Proof of Concept, as Geertjan proposed, working ASAP.

I wanted to avoid going that path, but if a Swing compatibility layer is really required - and Emi made some strong arguments here- we should consider working on that as well. 

More tomorrow.

Best Regards

Toni



 

-----Ursprüngliche Nachricht-----
Von: Neil C Smith <ne...@apache.org> 
Gesendet: Mittwoch, 14. März 2018 09:49
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

Hi Toni,

On Wed, 14 Mar 2018, 07:35 , <to...@eppleton.de> wrote:

> Regarding the architecture: In a plain DukeScript application we're 
> starting a normal Java process. This process starts a HTML5Renderer 
> using a "Presenter", e.g embedded chromium. The task of the Presenter 
> is to take care of the communication and make it transparent to the developer.


Thanks for the info, and you know I'm sold on this approach, at least for some uses.

But a big question, which is what I'm trying to get to - do we have a simple, Apache license compatible and robust way to build and deploy such a thing cross platform?  And JavaFX doesn't count! ;-)  And if not, how do we get there?

If we had that, and the tooling in the IDE using our own framework to do that, I think we'd have a powerful (and unique?) offering amongst Java IDE's.

Note that I'm mainly considering standalone applications built with the IDE there - I think we need to separate that out a little from thoughts of the future of the IDE, although it might help prove whether that approach is at all feasible.

I'm less keen on the selective HTML-ifying of the IDE using JavaFX.  If that's no longer shipped with the JDK but retains its current license we may even have difficulties using what we have under Apache?

Regarding Web APIs, I agree with Sean that not every browser out there can
> handle it, but if you control the browser, you're way better off than 
> with JavaFX 3D, because modern browser are using fast and well 
> maintained rendering pipelines. Chrome, for example uses ANGLE to map 
> commands to DirectX and OpenGL. I think tere were discussions about 
> using ANGLE for javaFX as well to improve performance, but I haven't 
> heard what came out of this.
>

That Web GL is faster than JavaFX doesn't entirely surprise me, but it's also noticeably slower than using a direct OpenGL binding with JOGL or LWJGL.  And at least the latter is also getting Vulkan support.

We do like our bloated abstractions in the Java world, but sometimes bare metal is still the way to go! :-)

Best wishes,

Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Neil C Smith <ne...@apache.org>]

Hi Toni,

On Wed, 14 Mar 2018, 07:35 , <to...@eppleton.de> wrote:

> Regarding the architecture: In a plain DukeScript application we're
> starting a normal Java process. This process starts a HTML5Renderer using a
> "Presenter", e.g embedded chromium. The task of the Presenter is to take
> care of the communication and make it transparent to the developer.


Thanks for the info, and you know I'm sold on this approach, at least for
some uses.

But a big question, which is what I'm trying to get to - do we have a
simple, Apache license compatible and robust way to build and deploy such a
thing cross platform?  And JavaFX doesn't count! ;-)  And if not, how do we
get there?

If we had that, and the tooling in the IDE using our own framework to do
that, I think we'd have a powerful (and unique?) offering amongst Java
IDE's.

Note that I'm mainly considering standalone applications built with the IDE
there - I think we need to separate that out a little from thoughts of the
future of the IDE, although it might help prove whether that approach is at
all feasible.

I'm less keen on the selective HTML-ifying of the IDE using JavaFX.  If
that's no longer shipped with the JDK but retains its current license we
may even have difficulties using what we have under Apache?

Regarding Web APIs, I agree with Sean that not every browser out there can
> handle it, but if you control the browser, you're way better off than with
> JavaFX 3D, because modern browser are using fast and well maintained
> rendering pipelines. Chrome, for example uses ANGLE to map commands to
> DirectX and OpenGL. I think tere were discussions about using ANGLE for
> javaFX as well to improve performance, but I haven't heard what came out of
> this.
>

That Web GL is faster than JavaFX doesn't entirely surprise me, but it's
also noticeably slower than using a direct OpenGL binding with JOGL or
LWJGL.  And at least the latter is also getting Vulkan support.

We do like our bloated abstractions in the Java world, but sometimes bare
metal is still the way to go! :-)

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[to...@eppleton.de]

Hi Wade,

one of the ideas behind DukeScript was to not create our own rendering technology and set of widgets. That has huge benefits:

- We don't have to write and maintain a Rendering Pipeline. JavaFX proofs how hard it is. They have huge performance problems, partially caused by basically only using egl commands, after more than 10 years.
- Our API has about 60 classes, of which you probably touch 30 at most unless you want to port it to a new platform. JavaFX has about 700 due to the many widgets.
- We can use all the Widgets supported by HTML/CSS and any HTML/CSS/JavaScript framework without any additional work. All the guys writing new JS libraries and tools are working for us.

As a result, we can focus on porting to new platforms, making the API better, improving testability, etc. instead of having to maintain a huge codebase. That doesn't prevent you from providing a different rendering pipeline. We'd be more than happy to see such development.

Regarding the architecture: In a plain DukeScript application we're starting a normal Java process. This process starts a HTML5Renderer using a "Presenter", e.g embedded chromium. The task of the Presenter is to take care of the communication and make it transparent to the developer. As the Java process is running on your local machine, you can use java.io or nio to open files.

Regarding Web APIs, I agree with Sean that not every browser out there can handle it, but if you control the browser, you're way better off than with JavaFX 3D, because modern browser are using fast and well maintained rendering pipelines. Chrome, for example uses ANGLE to map commands to DirectX and OpenGL. I think tere were discussions about using ANGLE for javaFX as well to improve performance, but I haven't heard what came out of this.

--Toni


-----Ursprüngliche Nachricht-----
Von: Wade Chandler <wa...@apache.org> 
Gesendet: Dienstag, 13. März 2018 15:19
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK


> On Mar 13, 2018, at 3:04 AM, <to...@eppleton.de> <to...@eppleton.de> wrote:
> 
> Hi Wade,
> 
> I agree, desktop isn't going away. At DukeScript we're using HTML4J Apis mainly for desktop applications. The Java Desktop Application is just using a HTML5-Component ("browser") to render the view instead of a native or Java rendering pipeline. 

How are events handled then? If you want to open a file as an example? Are you running the JVM as a separate service backend and using web services?

> 
> Since the separation of view and view logic is very clean the view technology can be completely replaced. In some of our commercial projects we used Controls4J to render the view, in others plain HTML and CSS. I've got working prototypes that use native controls instead on iOS and Android. Even one that renders to JavaFX that I sometimes use for debugging. 

That sounds pretty cool.

> 
> And unlike Swing or JavaFX browsers are evolving at great speed and getter better day by day without any investment on our side. That's a great benefit if you compare that to the sluggish development of Swing and JavaFX that we've seen in the past years.  
> 

Perhaps, but I think one has to bind a product to a specific and embeddable browser for something like NB and NB RCP, or perhaps some custom Webkit. Relying on just anything seems like a lot to support at that level.

I figure if views themselves can be replaced, then technically we could have our own native views instead. We could do some things based on OpenGL or Vulkan https://www.khronos.org/vulkan/ <https://www.khronos.org/vulkan/> or stay low-level yet remain in Java with LWJGL https://www.lwjgl.org <https://www.lwjgl.org/>, and not have any browser limitations. Here’s an example of an OpenGL based UI library https://github.com/wjakob/nanogui <https://github.com/wjakob/nanogui>
> I think that the stuff that Sean does with the crippled JavaFX 3D API is amazing, but think about what he could do with a really good 3D API, like the many that exist for WebGL. 
> 

I’ll let him speak more to this, but per his talks he tried different browser based 3D APIs, and the performance wasn’t there yet. Personally, I have seen a lot of WebGL components get the sad face uh oh in Chrome, and not be that stable; this on good hardware.

Wade



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Wade Chandler <wa...@apache.org>]

> On Mar 13, 2018, at 3:04 AM, <to...@eppleton.de> <to...@eppleton.de> wrote:
> 
> Hi Wade,
> 
> I agree, desktop isn't going away. At DukeScript we're using HTML4J Apis mainly for desktop applications. The Java Desktop Application is just using a HTML5-Component ("browser") to render the view instead of a native or Java rendering pipeline. 

How are events handled then? If you want to open a file as an example? Are you running the JVM as a separate service backend and using web services?

> 
> Since the separation of view and view logic is very clean the view technology can be completely replaced. In some of our commercial projects we used Controls4J to render the view, in others plain HTML and CSS. I've got working prototypes that use native controls instead on iOS and Android. Even one that renders to JavaFX that I sometimes use for debugging. 

That sounds pretty cool.

> 
> And unlike Swing or JavaFX browsers are evolving at great speed and getter better day by day without any investment on our side. That's a great benefit if you compare that to the sluggish development of Swing and JavaFX that we've seen in the past years.  
> 

Perhaps, but I think one has to bind a product to a specific and embeddable browser for something like NB and NB RCP, or perhaps some custom Webkit. Relying on just anything seems like a lot to support at that level.

I figure if views themselves can be replaced, then technically we could have our own native views instead. We could do some things based on OpenGL or Vulkan https://www.khronos.org/vulkan/ <https://www.khronos.org/vulkan/> or stay low-level yet remain in Java with LWJGL https://www.lwjgl.org <https://www.lwjgl.org/>, and not have any browser limitations. Here’s an example of an OpenGL based UI library https://github.com/wjakob/nanogui <https://github.com/wjakob/nanogui>
> I think that the stuff that Sean does with the crippled JavaFX 3D API is amazing, but think about what he could do with a really good 3D API, like the many that exist for WebGL. 
> 

I’ll let him speak more to this, but per his talks he tried different browser based 3D APIs, and the performance wasn’t there yet. Personally, I have seen a lot of WebGL components get the sad face uh oh in Chrome, and not be that stable; this on good hardware.

Wade

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[to...@eppleton.de]

Hi Wade,

I agree, desktop isn't going away. At DukeScript we're using HTML4J Apis mainly for desktop applications. The Java Desktop Application is just using a HTML5-Component ("browser") to render the view instead of a native or Java rendering pipeline. 

Since the separation of view and view logic is very clean the view technology can be completely replaced. In some of our commercial projects we used Controls4J to render the view, in others plain HTML and CSS. I've got working prototypes that use native controls instead on iOS and Android. Even one that renders to JavaFX that I sometimes use for debugging. 

And unlike Swing or JavaFX browsers are evolving at great speed and getter better day by day without any investment on our side. That's a great benefit if you compare that to the sluggish development of Swing and JavaFX that we've seen in the past years.  

I think that the stuff that Sean does with the crippled JavaFX 3D API is amazing, but think about what he could do with a really good 3D API, like the many that exist for WebGL. 

--Toni





 





-----Ursprüngliche Nachricht-----
Von: Wade Chandler <wa...@apache.org> 
Gesendet: Dienstag, 13. März 2018 05:54
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

On Mar 12, 2018 11:59, "Jaroslav Tulach" <ja...@gmail.com> wrote:

> "Oracle has begun conversations with interested parties in the Java

> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
>>>> referenced timeframes."
>>>>
>>>
>>
The official announcement is here and people are finally starting to realize the truth: There is no future for JavaFX, AWT and Swing. Nobody will sponsor development of anything new for these technologies. Even if they get transfered to their new owners, they will be in maintenance mode:
Bugfixes and little features. No bigger changes - no new rendering pipelines using new nifty features of graphics cards. Just sustaining. I've been explaining this would happen since 2012.

To help us out of this situation and save Java as a programming language I dedicated my days to smoothing out interoperability between Java and JavaScript with the goal to reuse the most flexible and portable rendering system of these days: the browser. My work has already been donated to Apache, see: https://github.com/apache/incubator-netbeans-html4j - let's use it to build new features of NetBeans and other future Java desktop applications. Get started by reading Javadoc at http://bits.netbeans.org/html+java/

Forget about AWT, Swing and JavaFX - the future is HTML. In case you still care about Java, then your future should be Apache HTML/Java API!


Personally, I feel if that is true, then why all the hodgepodge, and why not just Electron which is already driving window creation and interacting with the desktop? Then, why not wasm and a real type safe language, and not TypeScript nor JS? Or maybe just VS Code plugins?

Why use the browser for all that if there is a desktop need? I mean, is it just me, or does that all just feel wrong?

Look at how many resources the Slack and VS Code apps need just running a few simple things, and they exist how they are, and are successful because people want to use the desktop app, and not tabs in their browsers. Then there are all the tricks to access the file system indirectly.

I don't see the desktop app disappearing for specific types of applications, and IMO that includes IDEs. Who wants to do all that work in browser tabs? Nobody. Electron is a desktop app environment. It isn't a container or a browser bound environment even if a browser is a component.

So what is the benefit of doing away with better rendering pipelines and direct resource access just to wind up manipulating a slow and bloated DOM in its place? Folks should checkout things Sean Phillips is doing with Java FX inside NB RCP Swing.

I think IntelliJ shows that a successful Swing based product can be a winner just as NetBeans has, and doesn't seem to be slowing down nor changing directions. To me it seems more feasible to support Swing itself for our needs, and continue making NB and NB RCP unique if we can be involved. Otherwise, isn't it VS Code or Eclipse Che ideas, just far behind?

Wade


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Wade Chandler <wa...@apache.org>]

On Mar 12, 2018 11:59, "Jaroslav Tulach" <ja...@gmail.com> wrote:

> "Oracle has begun conversations with interested parties in the Java

> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
>>>> referenced timeframes."
>>>>
>>>
>>
The official announcement is here and people are finally starting to
realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
will sponsor development of anything new for these technologies. Even if
they get transfered to their new owners, they will be in maintenance mode:
Bugfixes and little features. No bigger changes - no new rendering
pipelines using new nifty features of graphics cards. Just sustaining. I've
been explaining this would happen since 2012.

To help us out of this situation and save Java as a programming language I
dedicated my days to smoothing out interoperability between Java and
JavaScript with the goal to reuse the most flexible and portable rendering
system of these days: the browser. My work has already been donated to
Apache, see: https://github.com/apache/incubator-netbeans-html4j - let's
use it to build new features of NetBeans and other future Java desktop
applications. Get started by reading Javadoc at
http://bits.netbeans.org/html+java/

Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
care about Java, then your future should be Apache HTML/Java API!


Personally, I feel if that is true, then why all the hodgepodge, and why
not just Electron which is already driving window creation and interacting
with the desktop? Then, why not wasm and a real type safe language, and not
TypeScript nor JS? Or maybe just VS Code plugins?

Why use the browser for all that if there is a desktop need? I mean, is it
just me, or does that all just feel wrong?

Look at how many resources the Slack and VS Code apps need just running a
few simple things, and they exist how they are, and are successful because
people want to use the desktop app, and not tabs in their browsers. Then
there are all the tricks to access the file system indirectly.

I don't see the desktop app disappearing for specific types of
applications, and IMO that includes IDEs. Who wants to do all that work in
browser tabs? Nobody. Electron is a desktop app environment. It isn't a
container or a browser bound environment even if a browser is a component.

So what is the benefit of doing away with better rendering pipelines and
direct resource access just to wind up manipulating a slow and bloated DOM
in its place? Folks should checkout things Sean Phillips is doing with Java
FX inside NB RCP Swing.

I think IntelliJ shows that a successful Swing based product can be a
winner just as NetBeans has, and doesn't seem to be slowing down nor
changing directions. To me it seems more feasible to support Swing itself
for our needs, and continue making NB and NB RCP unique if we can be
involved. Otherwise, isn't it VS Code or Eclipse Che ideas, just far behind?

Wade

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX fromOracle JDK

[Christian Lenz <ch...@gmx.net>]

I totally agree with your, but as we discussed some glitches in other threads, you already know my pain. To create stable, usable UIs with HTML inside Java, with the Rendering Browser from the JDK or from wherever, there Need some bigger improvements to get everyone involved.

But what happens with HTML4J? I thought this lib will also use JavaFX browser, or am I wrong?

Sure, for me, as a frontend dev, there is nothing better than creating UIs with HTML and use them everywhere, like in the Electron Framework.


Cheers

Chris

Von: Jaroslav Tulach
Gesendet: Montag, 12. März 2018 17:00
An: Apache NetBeans
Betreff: Apache HTML/Java UI instead of ... Oracle will remove JavaFX fromOracle JDK

> "Oracle has begun conversations with interested parties in the Java

> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
>>>> referenced timeframes."
>>>>
>>>
>>
The official announcement is here and people are finally starting to
realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
will sponsor development of anything new for these technologies. Even if
they get transfered to their new owners, they will be in maintenance mode:
Bugfixes and little features. No bigger changes - no new rendering
pipelines using new nifty features of graphics cards. Just sustaining. I've
been explaining this would happen since 2012.

To help us out of this situation and save Java as a programming language I
dedicated my days to smoothing out interoperability between Java and
JavaScript with the goal to reuse the most flexible and portable rendering
system of these days: the browser. My work has already been donated to
Apache, see: https://github.com/apache/incubator-netbeans-html4j - let's
use it to build new features of NetBeans and other future Java desktop
applications. Get started by reading Javadoc at
http://bits.netbeans.org/html+java/

Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
care about Java, then your future should be Apache HTML/Java API!
-jt

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX fromOracle JDK

[to...@eppleton.de]

@Chris: you are correct: This actually is a demo from the 90s 😊, the SwingSet was a demo application for Swing controls that you could download with the JDK.

-----Ursprüngliche Nachricht-----
Von: Christian Lenz <ch...@gmx.net> 
Gesendet: Mittwoch, 14. März 2018 11:00
An: dev@netbeans.incubator.apache.org
Betreff: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX fromOracle JDK

Best example Neil, the app is horrible, it is slow initialization like 10 seconds or more? Please come one. No way!. And the UI is horrible too, out from the latest 90s or whenever.

Gesendet von Mail für Windows 10

Von: Neil C Smith
Gesendet: Dienstag, 13. März 2018 10:35
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX fromOracle JDK

On Tue, 13 Mar 2018 at 08:56 <to...@eppleton.de> wrote:

> > We need a way to render Swing on a web browser canvas!
>
>  We were actually thinking about doing this using DukeScript a while 
> ago to allow people to run their legacy applications. It would be doable.


Reminds me of this - http://demo.creamtec.com/ajaxswing/apps/SwingSet2


> But then we decided that it's much better if developers use a modern 
> concept for UI Development like MVVM, otherwise we'll end up in a 
> horrible niche as the only ones doing archaic Swing development in a 
> world that has much better concepts for UI development.
>

Yep, still reminds me of this -
http://demo.creamtec.com/ajaxswing/apps/SwingSet2 ;-)

Best wishes,

Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX fromOracle JDK

[Christian Lenz <ch...@gmx.net>]

Best example Neil, the app is horrible, it is slow initialization like 10 seconds or more? Please come one. No way!. And the UI is horrible too, out from the latest 90s or whenever.

Gesendet von Mail für Windows 10

Von: Neil C Smith
Gesendet: Dienstag, 13. März 2018 10:35
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX fromOracle JDK

On Tue, 13 Mar 2018 at 08:56 <to...@eppleton.de> wrote:

> > We need a way to render Swing on a web browser canvas!
>
>  We were actually thinking about doing this using DukeScript a while ago
> to allow people to run their legacy applications. It would be doable.


Reminds me of this - http://demo.creamtec.com/ajaxswing/apps/SwingSet2


> But then we decided that it's much better if developers use a modern
> concept for UI Development like MVVM, otherwise we'll end up in a horrible
> niche as the only ones doing archaic Swing development in a world that has
> much better concepts for UI development.
>

Yep, still reminds me of this -
http://demo.creamtec.com/ajaxswing/apps/SwingSet2 ;-)

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Neil C Smith <ne...@apache.org>]

On Tue, 13 Mar 2018 at 08:56 <to...@eppleton.de> wrote:

> > We need a way to render Swing on a web browser canvas!
>
>  We were actually thinking about doing this using DukeScript a while ago
> to allow people to run their legacy applications. It would be doable.


Reminds me of this - http://demo.creamtec.com/ajaxswing/apps/SwingSet2


> But then we decided that it's much better if developers use a modern
> concept for UI Development like MVVM, otherwise we'll end up in a horrible
> niche as the only ones doing archaic Swing development in a world that has
> much better concepts for UI development.
>

Yep, still reminds me of this -
http://demo.creamtec.com/ajaxswing/apps/SwingSet2 ;-)

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Emilian Bold <em...@protonmail.ch>]

> We were actually thinking about doing this using DukeScript a while ago to allow people to run their legacy applications. It would be doable.

I believe it would rather useful for NetBeans (and others).

> But then we decided that it's much better if developers use a modern concept for UI Development like MVVM, otherwise we'll end up in a horrible niche as the only ones doing archaic Swing development in a world that has much better concepts for UI development.

This makes sense if you want to start something new, but what about the 1000 man-years-projects like NetBeans. Just rewrite it all, with open-source contributors?

Isn't MVVM accomplished with Swing an a BeansBinding library?

--emi

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On 13 March 2018 10:56 AM, <to...@eppleton.de> wrote:

> > We need a way to render Swing on a web browser canvas!
> 
> We were actually thinking about doing this using DukeScript a while ago to allow people to run their legacy applications. It would be doable. The JavaFX Team at Oracle had a working JavaFX version for the browser (without Java Plugin). It was using bck2brwsr and my DukeScript canvas API as the rendering pipeline (the demo is still in the internet somewhere). The same would be possible for Swing.
> 
> But then we decided that it's much better if developers use a modern concept for UI Development like MVVM, otherwise we'll end up in a horrible niche as the only ones doing archaic Swing development in a world that has much better concepts for UI development.
> 
> --Toni
> 
> -----Ursprüngliche Nachricht-----
> 
> Von: Emilian Bold emilian.bold@protonmail.ch
> 
> Gesendet: Dienstag, 13. März 2018 08:59
> 
> An: dev@netbeans.incubator.apache.org
> 
> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK
> 
> HTML4J goes the wrong way in providing a migration path.
> 
> We don't need new ways to embed components into Swing. We could already embed JavaFX stuff and now we can also embed HTML stuff (rendered by JavaFX).
> 
> We need a way to render Swing on a web browser canvas!
> 
> Then, after Swing is fully in the browser we can decide that instead of having a canvas there just replace that topcomponent rectangle area with a div.
> 
> So, for new apps HTML4J makes more sense.
> 
> For NetBeans HTML4J only makes sense if we start a multi-year process of slowly migrating to HTML4J and then, in the far future, realise we migrated so much we might as well switch the whole main window from a JFrame to a browser tab.
> 
> This plan would probably make sense in a corporation like Oracle, but will no do well under Apache, also because we would have our own technology stack that no contributor would use elsewhere. Mozilla also had XULRunner and people didn't really flock to it.
> 
> --emi
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 
> On 12 March 2018 5:59 PM, Jaroslav Tulach jaroslav.tulach@gmail.com wrote:
> 
> > > "Oracle has begun conversations with interested parties in the Java
> > 
> > > ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
> > > 
> > > > > > referenced timeframes."
> > 
> > The official announcement is here and people are finally starting to
> > 
> > realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
> > 
> > will sponsor development of anything new for these technologies. Even if
> > 
> > they get transfered to their new owners, they will be in maintenance mode:
> > 
> > Bugfixes and little features. No bigger changes - no new rendering
> > 
> > pipelines using new nifty features of graphics cards. Just sustaining. I've
> > 
> > been explaining this would happen since 2012.
> > 
> > To help us out of this situation and save Java as a programming language I
> > 
> > dedicated my days to smoothing out interoperability between Java and
> > 
> > JavaScript with the goal to reuse the most flexible and portable rendering
> > 
> > system of these days: the browser. My work has already been donated to
> > 
> > Apache, see: https://github.com/apache/incubator-netbeans-html4j \- let's
> > 
> > use it to build new features of NetBeans and other future Java desktop
> > 
> > applications. Get started by reading Javadoc at
> > 
> > http://bits.netbeans.org/html+java/
> > 
> > Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> > 
> > care about Java, then your future should be Apache HTML/Java API!
> > 
> > -jt
> 
> --
> 
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> 
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> 
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> HTML4J goes the wrong way in providing a migration path.
> 
> We don't need new ways to embed components into Swing. We could already embed JavaFX stuff and now we can also embed HTML stuff (rendered by JavaFX).
> 
> We need a way to render Swing on a web browser canvas!
> 
> Then, after Swing is fully in the browser we can decide that instead of having a canvas there just replace that topcomponent rectangle area with a div.
> 
> So, for new apps HTML4J makes more sense.
> 
> For NetBeans HTML4J only makes sense if we start a multi-year process of slowly migrating to HTML4J and then, in the far future, realise we migrated so much we might as well switch the whole main window from a JFrame to a browser tab.
> 
> This plan would probably make sense in a corporation like Oracle, but will no do well under Apache, also because we would have our own technology stack that no contributor would use elsewhere. Mozilla also had XULRunner and people didn't really flock to it.
> 
> --emi
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 
> On 12 March 2018 5:59 PM, Jaroslav Tulach jaroslav.tulach@gmail.com wrote:
> 
> > > "Oracle has begun conversations with interested parties in the Java
> > 
> > > ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
> > > 
> > > > > > referenced timeframes."
> > 
> > The official announcement is here and people are finally starting to
> > 
> > realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
> > 
> > will sponsor development of anything new for these technologies. Even if
> > 
> > they get transfered to their new owners, they will be in maintenance mode:
> > 
> > Bugfixes and little features. No bigger changes - no new rendering
> > 
> > pipelines using new nifty features of graphics cards. Just sustaining. I've
> > 
> > been explaining this would happen since 2012.
> > 
> > To help us out of this situation and save Java as a programming language I
> > 
> > dedicated my days to smoothing out interoperability between Java and
> > 
> > JavaScript with the goal to reuse the most flexible and portable rendering
> > 
> > system of these days: the browser. My work has already been donated to
> > 
> > Apache, see: https://github.com/apache/incubator-netbeans-html4j \- let's
> > 
> > use it to build new features of NetBeans and other future Java desktop
> > 
> > applications. Get started by reading Javadoc at
> > 
> > http://bits.netbeans.org/html+java/
> > 
> > Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> > 
> > care about Java, then your future should be Apache HTML/Java API!
> > 
> > -jt
> 
> --
> 
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> 
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> 
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> 
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> 
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> 
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Christian Lenz <ch...@gmx.net>]

Sure it is my opinion but never ever, will a FrontEnd developer using swing to bring it into the browser. For me, it doesn’t make sense, if you have a powerful language like HTML and CSS and JS to make better UIs than you can expect, to communicate with a REST Backend.


Cheers

Chris


Von: toni.epple@eppleton.de
Gesendet: Dienstag, 13. März 2018 10:09
An: dev@netbeans.incubator.apache.org; 'Emilian Bold'
Betreff: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

> We need a way to render Swing on a web browser canvas!

 We were actually thinking about doing this using DukeScript a while ago to allow people to run their legacy applications. It would be doable. The JavaFX Team at Oracle had a working JavaFX version for the browser (without Java Plugin). It was using bck2brwsr and my DukeScript canvas API as the rendering pipeline (the demo is still in the internet somewhere). The same would be possible for Swing.

But then we decided that it's much better if developers use a modern concept for UI Development like MVVM, otherwise we'll end up in a horrible niche as the only ones doing archaic Swing development in a world that has much better concepts for UI development.

--Toni
 
-----Ursprüngliche Nachricht-----
Von: Emilian Bold <em...@protonmail.ch> 
Gesendet: Dienstag, 13. März 2018 08:59
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

HTML4J goes the wrong way in providing a migration path.

We don't need new ways to embed components into Swing. We could already embed JavaFX stuff and now we can also embed HTML stuff (rendered by JavaFX).

We need a way to render Swing on a web browser canvas!

Then, after Swing is fully in the browser we can decide that instead of having a canvas there just replace that topcomponent rectangle area with a div.

So, for new apps HTML4J makes more sense.

For NetBeans HTML4J only makes sense if we start a multi-year process of slowly migrating to HTML4J and then, in the far future, realise we migrated so much we might as well switch the whole main window from a JFrame to a browser tab.
  This plan would probably make sense in a corporation like Oracle, but will no do well under Apache, also because we would have our own technology stack that no contributor would use elsewhere. Mozilla also had XULRunner and people didn't really flock to it. 

--emi

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On 12 March 2018 5:59 PM, Jaroslav Tulach <ja...@gmail.com> wrote:

> > "Oracle has begun conversations with interested parties in the Java
> 
> > ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
> > 
> > > > > referenced timeframes."
> 
> The official announcement is here and people are finally starting to
> 
> realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
> 
> will sponsor development of anything new for these technologies. Even if
> 
> they get transfered to their new owners, they will be in maintenance mode:
> 
> Bugfixes and little features. No bigger changes - no new rendering
> 
> pipelines using new nifty features of graphics cards. Just sustaining. I've
> 
> been explaining this would happen since 2012.
> 
> To help us out of this situation and save Java as a programming language I
> 
> dedicated my days to smoothing out interoperability between Java and
> 
> JavaScript with the goal to reuse the most flexible and portable rendering
> 
> system of these days: the browser. My work has already been donated to
> 
> Apache, see: https://github.com/apache/incubator-netbeans-html4j \- let's
> 
> use it to build new features of NetBeans and other future Java desktop
> 
> applications. Get started by reading Javadoc at
> 
> http://bits.netbeans.org/html+java/
> 
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> 
> care about Java, then your future should be Apache HTML/Java API!
> 
> -jt



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[to...@eppleton.de]

> We need a way to render Swing on a web browser canvas!

 We were actually thinking about doing this using DukeScript a while ago to allow people to run their legacy applications. It would be doable. The JavaFX Team at Oracle had a working JavaFX version for the browser (without Java Plugin). It was using bck2brwsr and my DukeScript canvas API as the rendering pipeline (the demo is still in the internet somewhere). The same would be possible for Swing.

But then we decided that it's much better if developers use a modern concept for UI Development like MVVM, otherwise we'll end up in a horrible niche as the only ones doing archaic Swing development in a world that has much better concepts for UI development.

--Toni
 
-----Ursprüngliche Nachricht-----
Von: Emilian Bold <em...@protonmail.ch> 
Gesendet: Dienstag, 13. März 2018 08:59
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

HTML4J goes the wrong way in providing a migration path.

We don't need new ways to embed components into Swing. We could already embed JavaFX stuff and now we can also embed HTML stuff (rendered by JavaFX).

We need a way to render Swing on a web browser canvas!

Then, after Swing is fully in the browser we can decide that instead of having a canvas there just replace that topcomponent rectangle area with a div.

So, for new apps HTML4J makes more sense.

For NetBeans HTML4J only makes sense if we start a multi-year process of slowly migrating to HTML4J and then, in the far future, realise we migrated so much we might as well switch the whole main window from a JFrame to a browser tab.
  This plan would probably make sense in a corporation like Oracle, but will no do well under Apache, also because we would have our own technology stack that no contributor would use elsewhere. Mozilla also had XULRunner and people didn't really flock to it. 

--emi

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On 12 March 2018 5:59 PM, Jaroslav Tulach <ja...@gmail.com> wrote:

> > "Oracle has begun conversations with interested parties in the Java
> 
> > ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
> > 
> > > > > referenced timeframes."
> 
> The official announcement is here and people are finally starting to
> 
> realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
> 
> will sponsor development of anything new for these technologies. Even if
> 
> they get transfered to their new owners, they will be in maintenance mode:
> 
> Bugfixes and little features. No bigger changes - no new rendering
> 
> pipelines using new nifty features of graphics cards. Just sustaining. I've
> 
> been explaining this would happen since 2012.
> 
> To help us out of this situation and save Java as a programming language I
> 
> dedicated my days to smoothing out interoperability between Java and
> 
> JavaScript with the goal to reuse the most flexible and portable rendering
> 
> system of these days: the browser. My work has already been donated to
> 
> Apache, see: https://github.com/apache/incubator-netbeans-html4j \- let's
> 
> use it to build new features of NetBeans and other future Java desktop
> 
> applications. Get started by reading Javadoc at
> 
> http://bits.netbeans.org/html+java/
> 
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> 
> care about Java, then your future should be Apache HTML/Java API!
> 
> -jt



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Emilian Bold <em...@protonmail.ch>]

HTML4J goes the wrong way in providing a migration path.

We don't need new ways to embed components into Swing. We could already embed JavaFX stuff and now we can also embed HTML stuff (rendered by JavaFX).

We need a way to render Swing on a web browser canvas!

Then, after Swing is fully in the browser we can decide that instead of having a canvas there just replace that topcomponent rectangle area with a div.

So, for new apps HTML4J makes more sense.

For NetBeans HTML4J only makes sense if we start a multi-year process of slowly migrating to HTML4J and then, in the far future, realise we migrated so much we might as well switch the whole main window from a JFrame to a browser tab.
  This plan would probably make sense in a corporation like Oracle, but will no do well under Apache, also because we would have our own technology stack that no contributor would use elsewhere. Mozilla also had XULRunner and people didn't really flock to it. 

--emi

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On 12 March 2018 5:59 PM, Jaroslav Tulach <ja...@gmail.com> wrote:

> > "Oracle has begun conversations with interested parties in the Java
> 
> > ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
> > 
> > > > > referenced timeframes."
> 
> The official announcement is here and people are finally starting to
> 
> realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
> 
> will sponsor development of anything new for these technologies. Even if
> 
> they get transfered to their new owners, they will be in maintenance mode:
> 
> Bugfixes and little features. No bigger changes - no new rendering
> 
> pipelines using new nifty features of graphics cards. Just sustaining. I've
> 
> been explaining this would happen since 2012.
> 
> To help us out of this situation and save Java as a programming language I
> 
> dedicated my days to smoothing out interoperability between Java and
> 
> JavaScript with the goal to reuse the most flexible and portable rendering
> 
> system of these days: the browser. My work has already been donated to
> 
> Apache, see: https://github.com/apache/incubator-netbeans-html4j \- let's
> 
> use it to build new features of NetBeans and other future Java desktop
> 
> applications. Get started by reading Javadoc at
> 
> http://bits.netbeans.org/html+java/
> 
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> 
> care about Java, then your future should be Apache HTML/Java API!
> 
> -jt



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists