> On 18 May 2023, at 14:27, Mike Hearn <m...@plan99.net> wrote: > > Right, for agent loading it probably doesn't matter. I think the reaction is > to the general direction of travel. Panama also requires a command line flag, > JNI may do so in future, maybe other features. The latter would cause any fat > jar app that does self-extraction of native code to break.
When we publish the JEP preparing to restrict JNI with a warning, it will address executable JARs (and probably so will FFM before turning its warnings into errors). > That's still pretty common to see in little CLI tools or GUI demos > distributed on github, for example. Having a JVM-Flags manifest entry would > also fix that. Alternatively, bringing back a WebStart like mechanism could > also work. Arbitrary command line options are particularly sensitive to the runtime’s version and executable JARs certainly shouldn’t be made more sensitive to the runtime version, so that will not have a significant positive effect. As for other deployment options, we try to follow the market’s demands and the constraints of the environment controlled by OSes. When fashions shift again, we’ll do our best to accommodate them. > > I agree jlink is a more powerful approach. The question is whether there's a > path that tips the cost/benefit trade-off back in the direction of > convenience, without losing the upsides. Sometimes there is and sometimes there must be tradeoffs (e.g. shipping a native executable is subject to the rules imposed by the OS). But I think we’ve strayed too far from the subject at hand, which is JEP 451. — Ron
