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.
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
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
when Windows had killed Unix.