4 ms·

It is not a step backward for anyone. The jlink model does not preclude auto-update of either the runtime or the application. It does preclude a JRE, i.e. a cen

by pron 6y ago

It is not a step backward for anyone. The jlink model does not preclude auto-update of either the runtime or the application. It does preclude a JRE, i.e. a centralised "system" Java runtime that the user obtains from a third party. You can write a launcher that updates the runtime and your app that does what Web Start does, but for your applications. You do not and should not control which runtime is used for other applications from other vendors, and the user shouldn't need to go to a third-party that does, either.

mcculley 6y ago
Yes, I can write a launcher that queries a URL and downloads the latest copy of my JAR if necessary. Fortunately for me, it already exists. It is called OpenWebStart. It is a shame that it is no longer in the JDK. Yes, it would be nice to narrow down the runtime, but that is not a requirement for me and others in my situation. I deploy multiple Java applications to desktops. I have been doing so since the late 90s. Requiring my users to use a current JRE/JDK is not at all problem. Ideally, I would have all of these apps share a common JVM so that they are not running multiple garbage collectors, but I realize this is a capability that most have simply discarded.
- pron 6y ago
  I was not talking about something like Web Start and the JRE. The JRE was a centrally-managed software that determined the runtime for all Java applications. I don't think it's a good idea for one party to determine the runtime for applications written by others. It is better for your applications to manage their own runtime in a way that does not interfere with others. That is not what Web Start or OpenWebStart do; what they do is discouraged, even if you are used to it, because it makes global decisions over the user's environment that apply beyond the application itself. > Ideally, I would have all of these apps share a common JVM so that they are not running multiple garbage collectors, but I realize this is a capability that most have simply discarded. I'm not sure that one JVM doing more work would necessarily be better than multiple ones, but since you now control the runtime, you can do that if you like. Use a launcher that runs all of your applications JARs in one VM; since you control the applications, too, you could make sure that they are well isolated.

by pron 6y ago

mcculley 6y ago

Yes, I can write a launcher that queries a URL and downloads the latest copy of my JAR if necessary. Fortunately for me, it already exists. It is called OpenWebStart. It is a shame that it is no longer in the JDK. Yes, it would be nice to narrow down the runtime, but that is not a requirement for me and others in my situation. I deploy multiple Java applications to desktops. I have been doing so since the late 90s. Requiring my users to use a current JRE/JDK is not at all problem. Ideally, I would have all of these apps share a common JVM so that they are not running multiple garbage collectors, but I realize this is a capability that most have simply discarded.

pron 6y ago
I was not talking about something like Web Start and the JRE. The JRE was a centrally-managed software that determined the runtime for all Java applications. I don't think it's a good idea for one party to determine the runtime for applications written by others. It is better for your applications to manage their own runtime in a way that does not interfere with others. That is not what Web Start or OpenWebStart do; what they do is discouraged, even if you are used to it, because it makes global decisions over the user's environment that apply beyond the application itself. > Ideally, I would have all of these apps share a common JVM so that they are not running multiple garbage collectors, but I realize this is a capability that most have simply discarded. I'm not sure that one JVM doing more work would necessarily be better than multiple ones, but since you now control the runtime, you can do that if you like. Use a launcher that runs all of your applications JARs in one VM; since you control the applications, too, you could make sure that they are well isolated.