<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 13/08/2024 17:48, Liam Miller-Cushon wrote:<br>
<blockquote type="cite" cite="mid:CAL4QsgvmX7UDTTB79eds+JM3Lmj3_BrSJ820jc1LT_bEKse7ug@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Hi,
I have a data point to share on the compatibility impact of
JDK-8325621 (Improve jspawnhelper version checks), which was
backported to earlier release trains.
As a result of that change, doing an in-place upgrade from 22.0.1 to
22.0.2 breaks long-running Java applications that create subprocesses.
This is an expected consequence of the change, which adds version
checks to jspawnhelper to detect if a JVM is updated in-place to a
version with an incompatible jspawnhelper.
I'm curious if the list has suggestions on the best way to mitigate
the compatibility impact. One possibility is that replacing a JVM
in-place for a running process should never happen, and installers
should use new directories, or ensure any long-running Java processes
are shut down during the upgrade. Is that considered a best practice?
</pre>
</blockquote>
There was some discussion about this scenario at the time (someone
brought it up here). I think the summary is that upgrading in-place
with running VMs isn't a good idea. When upgrading like this then
you need to ensure that all usages are shutdown first.<br>
<br>
-Alan<br>
<br>
</body>
</html>