The implication of the JDK-8194154 fix in jdk8u342.

[Langer, Christoph]

Hi,

out of interest, I was playing a bit with JDK-8194154 and I agree that it should not have been backported to 8u in first place and should definitely be reverted. The effect of the fix is simply to not honor a change of System property "user.dir" within Java code any longer in nio Path handling. This is a change in behavior which should be avoided in update releases.

The patch in itself is questionable since the potential crash that should be addressed by the fix is still lurking and can be reproduced by starting the VM with a -D option, e.g. -Duser.dir="/home/a/b/c/". That is still possible with current JDK11, by the way. It must have been fixed somehow in between 11 and 17.

And furthermore, I also doubt that the problem that the backporters of this patch wanted to address, e.g. to avoid issues starting the VM when a relative path is set via -Duser.dir, would be fixed. This can still be reproduced with JDK-8194154 applied. It must have been fixed with another change between 8 and 11.

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.org> On Behalf Of hedongbo
> Sent: Donnerstag, 21. Juli 2022 04:01
> To: Sergey Bylokhov <bylokhov at amazon.com>; jdk8u-dev at openjdk.org;
> Andrew Hughes <gnu.andrew at redhat.com>
> Cc: Chenshanyao <chenshanyao at huawei.com>
> Subject: RE: The implication of the JDK-8194154 fix in jdk8u342.
> 
> 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.