[External] : Re: Disallowing the dynamic loading of agents by default

[Gregg G Wonderly]

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 <mike at 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/