I think Swing is a non-goal of this project. It provides good interop with the DOM and core JS methods, and it makes it easy to create your own interop for JS apis that aren't in the core.
A little over 10 years ago, I ran across TeaVM for the first time (probably) on GitHub. We had been looking for a way to port Codename One to the web, but we needed thread support, which wasn't supported by any existing solutions.
I emailed Alexey (the creator of TeaVM) to ask if he had plans for thread support, and he replied that, while "proper" threads weren't possible, he had some ideas for supporting green threads. Over the following 6 months or so, Alexey would share updates on progress he had made on the thread front. In March 2015, he shared that he had found a new approach for async code that wouldn't affect the performance of single-threaded code, and would support natural stack traces.
We released a preview of our web port using TeaVM a month later, and it exceeded all of our expectations, both in how easy it ended up being to do the port (because of TeaVM), and on the performance.
Alexey's solution for supporting threads, was truly a piece of genius. Had he not created TeaVM, and added threading support, I don't think we would have ended up with our web port - or, at the very least it wouldn't have ended up performing nearly as well.
Nice. I haven't used Flavour for anything yet, but TeaVm is awesome sauce! This past year or so, I've noticed an uptick in activity surrounding TeaVM. More contributions from people other than Alexey. Some of this is seems to be related to the growing interest in WASM solutions, and TeaVM is probably the best pathway from Java to WASM right now.
jDeploy developer here. No shenanigans, I swear. npm just simplified things. Some have expressed interest in adding self-hosting options, so I'll likely add support for that. It's open source too, so others could potentially add other hosting options also.
"Swing suffered from two central weaknesses: the tutorials provided by Oracle were... often insufficient. And you could pick up some bad habits by following them. And then there were the UI builders where anybody could draw up something mediocre."
Agreed. Also, the IDEs would typically give you too much rope - enough for a novice to hang himself. When you create a new project with Xcode, you get a default project with all of the essentials for a native app. The menus, a window, an "About" window. Etc. In most java IDEs you get an empty main() method. Making an app that feels like a first-class citizen requires a lot of work and attention to detail.
My experience with many Swing apps is the same. I think a large part of the problem lay with the development tools. When you create a new Cococa project in Xcode, it generates a full app with all the necessary parts to feel native. You build it, you have a functioning hello world app with your "File" menu, etc...
In Java, when you create a new Swing app, the IDE (by default) just creates an empty main() method for you. You're expected to create your own menus and windows. Trying to make the app "native" requires a significant amount of work.
I always found this very confusing. I still do. At one point in time I think I could have explained why there were three tags. But I don't remember the specifics anymore.
I never really understood why, but I can guess. Could have been political/strategic, to try to force developers onto Objective-C. Or his keen attention to detail might have just bristled at some of the performance an UI issues that many of the Java apps had at the time.
100% agree. The "distribution" step has always taken way more time than I expected. And, I almost always had to compromise on certain platforms just because it couldn't get the square peg in to the round hole.
The goal of jDeploy is to sand off as many of these rough edges as possible to make cross-platform distribution as easy as cross-platform development.
The FileDialog is the only AWT widget I still use regularly. It gives you the native file chooser. Unfortunately it isn't terribly flexible when it comes to, for example, only selecting directories. In those cases, I have been known to use JNI to use the truly native dialog.
I started from the other side of that fence, and I remember feeling jealous of how smooth the GUI editor was in Visual Studio. Even in 2022, I still don't think I've seen any Java GUI builders that are as easy to use as Visual Studio circa 2001/2.
SceneBuilder is nice though.
I can't disagree with anything you say here, except the thing about "the article seems quite off". lol.
This piece covers the state of the technology at that time. In the early 2000's Java was slow. I wasn't familiar with IntelliJ at that time, so can't comment on their performance then. I wouldn't expect it to be dramatically better than other Java apps on the market at that time.
Moore's law has steadily changed the landscape. So have improvements in JIT technology.
> It was a little odd that the new download had the same version number as the old
The build number refers to your app version. The download page creates the bundle on the fly (but does cache) using the latest jDeploy release, so when I released the new version of jDeploy, the bundles in the download page are auto-updated. I thought of adding the jdeploy version number into the installer name, but it was getting pretty busy already, so I decided to just leave that off.
I have reproduced this issue, and have posted and update that should fix it. Please try downloading either of the demos again and let me know if it still gives you issues.
> Any plans for commercial features in the future?
I'll have to find out what kinds of features are of interest to commercial clients. I'd like to find some way to support continued development. Commercial features are certainly a possibility.
I agree. Once you fight through the initial project setup, and solve the deployment difficulties (jDeploy), Java is a remarkably good platform for Desktop development. The sheer number of libraries available to you with a simple copy/paste dependency snippet, is unrivalled in any other ecosystem.