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
