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.
Gesendet: Dienstag, 13. März 2018 10:09
An: email@example.com; 'Emilian Bold'
Betreff: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from
> 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.
Von: Emilian Bold <emilian.b...@protonmail.ch>
Gesendet: Dienstag, 13. März 2018 08:59
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from
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.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 12 March 2018 5:59 PM, Jaroslav Tulach <jaroslav.tul...@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
> 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
> 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!
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit: