shannah78

What do you mean be centralized service? It allows you to publish to GitHub releases or npm. Do you mean "central" like "GitHub"?

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.

There are at least two GUI toolkits that run on TeaVM: 1. Codename One. Similar to swing, but focused on mobile https://www.codenameone.com 2. SnapKit. Targeted at desktop. Also a light-weight toolkit, like Swing. https://github.com/reportmill/SnapKit

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.

"at the cost of some npm shenanigans"

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.

Neat. I hadn't heard of either of those before (though I'm not a Clojure developer). Thanks for sharing.

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.

That sounds about right to me. AJAX - or more broadly, what we call HTML5 could have been the gamechanger.

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.

This is fixed now. If you download the demo again it should work for you.

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.

I have received a few reports on Linux. I'm working on it. Literally this is the reason why jDeploy is helpful. I've spent 2 years working out many details. Every OS/Version/distribution has needed some special care. Up to now I've been working with a single Ubuntu 20 box for my linux testing. Today, in response to these reports, I'm setting up a number of Linux VMs to test other variations to get to the bottom of this. I should have these issues resolved shortly.

Very naive question but is it different from what npm, pip, etc. let you do already?

npm, pip, etc.. are CLI install tools. jDeploy supports CLI app distribution using npm also. But the key difference is that jDeploy provides double-clickable installers for the apps. If you're distributing a desktop app, it should be installable in the desktop (IMO). Making users go to the command-line to install the app is actually prohibitive for the average user. Even when your userbase is programmers, I find that making them go into the command-line loses them.

Does the app installed this way get more permissions coming from a signed installer? I'm not familiar with OSX security model.

Since Catalina, you can't download and run a Mac app in any form unless it is signed and notarized. Using the signed and notarized installer allows you to get around this limitation.

The launcher is about 3 megs compressed. The actual jar files and JVM are downloaded on demand in the $HOME/.jdeploy directory.

I need to not use public npm.

In a previous iteration everything was designed to be self-hosted, but decided to focus on npm support because it made things much simpler. I'll be re-exposing the self-hosting, and private npm options as demand dictates.

There is a way to control to what version auto updates?

Internally it supports some rich update rules. It is possible to generate apps that are pegged to a specific version (e.g. 1.0.7), or that will only update build updates (e.g. 1.0.), or minor updates (e.g. 1.). By default they don't update to pre-releases (e.g. 1.0.1-alpha.1), but this is configurable by the user.

I haven't documented this yet because I want to avoid confusion at the beginning as much as possible. There are dozens of variations that could be supported, but I'm trying to hit the 90% use case out of the box first...

I need to avoid that the client app auto updates to the wrong version, before the server and the database are updated.

You could just bake that into your client (detect the server version). Alternatively, just wait until the server is updated before you publish the client update. This could be triggered in CI as well.

Interesting idea, though I thought the orig. goal of Java was to avoid this in the first place.

IMO this is moving back in the direction of the original WORA philosophy of Java. jDeploy is designed to be cross platform. No platform-specific build settings, to as much extent possible. After the death of Applets and WebStart, the new direction of bundle a JRE with every app - and rely on platform-specific 3rd-part tools to create the bundles never felt right to me.

But hats off, cool project!

Thanks!

Thanks. I saw the issue (presumably) you posted, and am setting up a VM to try to reproduce. Should have this fixed shortly.

Hard to tell if this is sarcasm. However, I totally agree that learning about operating system packaging is a rewarding exercise. In developing jDeploy I had to learn a lot of details about OS packaging. Very interesting most of the time. Very frustrating at other times when all you want to do is build your app in a form that your users can easily install.

This method of distribution doesn't work when pretty much all apps are almost guaranteed to used a different JVM

Not really. Currently it supports Java 8, 11, and 17. For each of those there is a JRE/JDK option, and a JavaFX option. Plus some of these are subsets. E.g. An app that doesn't need JavaFX can still use the JRE with JavaFX. And an app that doesn't need the full JDK can still use the JDK.

as others pointed out, downloading two apps from the samples already shows the problem).

This was just an issue with the installer not needing JavaFX so downloading a non-javafx JRE first - but then the app needing JavaFX, so downloading one with JavaFX. This is a special case that will be resolved in an upcoming release by making the installer use a JRE that is compatible with the app to avoid the double download.

Anyways these are "fixed costs". Only incurred on first install. And, even then, maybe not if a compatible JVM is already present. All of your updates go through without the baggage of a JVM.

If you need more specific control over which JVM you're using than this (e.g. a specific build version or distribution), then jlink is a good tool for that. Life is about tradeoffs.

1) Can I run jlink somewhere in the build process?

No need. Just specify your JVM requirements and the launcher will automatically use (or download if necessary) a compatible VM. This allows JVMs to be shared between apps, and your app updates are much smaller since they don't include the VM bundled directly.

2) Can I use a private npm repo like Verdaccio, or are there plans for other (non npm?) backends in the future?

Right now it's pegged to the public npm repo, but I'll be exploring other options soon, including private repos, self hosting, GitHub releases.