The implication of the JDK-8194154 fix in jdk8u342.
Aleksei Voitylov
aleksei.voitylov at bell-sw.com
Fri Jul 22 08:59:04 UTC 2022
Hi Sergey,
JDK-8194154 is originally mislabeled as P3, it should IMO have been P2
according to ILW. That said, unfortunately the 8u backport had
unintended consequences, which have badly broken compatibility by making
it impossible to change user.dir.
I'm thus for backing out JDK-8194154, and having an 8u345(?) respin of
OpenJDK when this fix is in. Thank you for proposing JDK-8290832.
-Aleksei
On 20.07.2022 23:27, Sergey Bylokhov wrote:
> Hello, the last release of jdk8u includes the fix for JDK-8194154[1]
> which disabled the possibility to change the "user.dir" property.
>
> Changing the "user.dir" was not recommended from the beginning but it
> was not forbidden, so there are some old applications that rely on the
> old behavior. One of the app which sets the "user.dir" is Gradle. The
> Gradle has a notice in the documentation for the user:
> "Never use new File(relative path) because this creates a path
> relative to the current working directory (CWD). Gradle can make no
> guarantees about the location of the CWD, which means builds that rely
> on it may break at any time".
>
> But for compatibility reasons they still set the "user.dir" property,
> so the old plugins will work. Now that compatibility is broken due to
> the fix I mention. We found such apps immediately after the release.
>
> I would like to ask what was the reason for the backport, is it
> critical enough to change a behavior? I did not find any broad
> discussion about that backport nor the reason why it was pushed but I
> would like to bring a compatibility concerns about that change. I
> think we should roll it back as soon as possible.
>
> Please share your opinions?
>
> [1] https://bugs.openjdk.org/browse/JDK-8194154
>
More information about the jdk8u-dev
mailing list