This is exactly my point! Why would any one want to do something like this? This level of workaround and specialized deployment is the kind of breakage that I am referring to. I just don’t understand how this kind of rigging and customization can even start to feel right.
Gregg Wonderly > On Mar 28, 2023, at 11:11 AM, Mike Hearn <m...@plan99.net> wrote: > > Hi Gregg, > > Distributing little apps as JARs indeed doesn't work well anymore out > of the box, but it doesn't have to be the end of the line for them. > I've spent a couple of years writing a tool designed explicitly to > solve all these problems [1]. You give Conveyor your JARs (or a > Maven/Gradle build), it'll create and upload self-updating packages > for Windows, Mac and Linux that bundle a jlinked and minified JVM, > fully signed and notarized, along with a download HTML page for end > users to get a big green button. It'll even draw an icon for you. You > can do this from any OS, you don't need Windows or macOS to ship for > them. > > This approach has the major downside that unless your app is open > source it's not free (we gotta make money somehow) BUT if you can put > that to one side, it works better than the JAR era ever could: > > - No Java compatibility issues by design. > > - Not blocked by browsers/operating system security. > > - Apps can update more smoothly than Web Start ever allowed. > > - You can use OS specific integrations. > > - Clean uninstalls, native code handled better and so on. > > You might object that this is somehow more effort than just making a > fat jar and sending it to people, but in practice it's not harder. You > run it, out pops a bunch of files, you make them available to people, > done. > > W.R.T. corporate deployment, note that Conveyor makes MSIX files which > are Microsoft's official format and easily deployed across Windows > networks. > > The difficulty with the send-a-JAR approach is that maintaining > backwards compatibility at the level you want (Win32, web level) takes > a massive level of spend, a large library of public programs which can > be automatically regression tested against, and a commitment to never > break anything even if it seriously disadvantages later developers, > and even then things will still break despite best intentions. Decades > ago this tradeoff made more sense because bandwidth and storage space > were much tighter, but now it's harder to justify. That's why so few > platforms do it anymore. > > [1] https://hydraulic.software/