The implication of the JDK-8194154 fix in jdk8u342.

[hedongbo]

The initial reason is that the customer set -Duser dir=./xxx relative path, resulting in an error: Error: Could not find or load main class xxx.
Unfortunately, we can't get the customer's code, so PR uses the tes case that comes with the original fix to illustrate this problem.

Thanks,
hedongbo

-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.org> On Behalf Of Sergey Bylokhov
Sent: Thursday, July 21, 2022 4:28 AM
To: jdk8u-dev at openjdk.org; Andrew Hughes <gnu.andrew at redhat.com>
Subject: The implication of the JDK-8194154 fix in jdk8u342.

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

--
Best regards, Sergey.