The implication of the JDK-8194154 fix in jdk8u342.

[Sergey Bylokhov]

You just confirmed that people tends to set that property for one reason or another. In your case if 
the customer application is new then it was broken from the beginning, if the application was old 
then this change just broke it in another way since all local paths which are used by the 
application will be changed. Take a look to this discussion and the number of discussions linked 
from there:
https://github.com/gradle/gradle/issues/5187

Even the checkstyle plugin is broken:
https://github.com/reposense/RepoSense/pull/530



On 7/20/22 19:01, hedongbo wrote:
> 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.


-- 
Best regards, Sergey.