-
Bug
-
Resolution: Fixed
-
P4
-
17.0.14
-
b02
We see test/hotspot/jtreg/compiler/controldependency/TestAntiDependencyForPinnedLoads.java failing in 17. Not so in 21 or younger. The test was just brought to 17 by JDK-8337066.
As 17 lacks "JEP 400: UTF-8 by Default" the test must explicitly be compiled with -encoding UTF-8. We saw this failing on Windows which happens to have a different locale.
If I change the test error output to
if (!revStr.equals("日DD月MM年YYYY")) throw new InternalError("FAIL " + i + ": revStr: " + revStr + " str: " + str + " result literal: 日DD月MM年YYYY");
I get output
java.lang.InternalError: FAIL 0:
revStr: \u00a5\u2014\u00e6DD\u02c6\u0153\u00e6MM\u00b4\u00b9\u00e5YYYY
str: YYYY\u00e5\u00b9\u00b4MM\u00e6\u0153\u02c6DD\u00e6\u2014\u00a5
result literal: \u00e6\u2014\u00a5DD\u00e6\u0153\u02c6MM\u00e5\u00b9\u00b4YYYY
If I add the print statement unconditionally on linux I get
revStr: \u65e5DD\u6708MM\u5e74YYYY
str: YYYY\u5e74MM\u6708DD\u65e5
result literal: \u65e5DD\u6708MM\u5e74YYYY
Some properties on my windows box are:
file.encoding = Cp1252
file.separator = \
java.class.path =
java.class.version = 61
java.vm.specification.version = 17
line.separator = \r \n
native.encoding = Cp1252
os.arch = amd64
os.name = Windows 11
os.version = 10.0
path.separator = ;
sun.arch.data.model = 64
sun.io.unicode.encoding = UnicodeLittle
sun.java.launcher = SUN_STANDARD
sun.jnu.encoding = Cp1252
sun.stderr.encoding = cp437
sun.stdout.encoding = cp437
user.country = DE
user.language = de
As 17 lacks "JEP 400: UTF-8 by Default" the test must explicitly be compiled with -encoding UTF-8. We saw this failing on Windows which happens to have a different locale.
If I change the test error output to
if (!revStr.equals("日DD月MM年YYYY")) throw new InternalError("FAIL " + i + ": revStr: " + revStr + " str: " + str + " result literal: 日DD月MM年YYYY");
I get output
java.lang.InternalError: FAIL 0:
revStr: \u00a5\u2014\u00e6DD\u02c6\u0153\u00e6MM\u00b4\u00b9\u00e5YYYY
str: YYYY\u00e5\u00b9\u00b4MM\u00e6\u0153\u02c6DD\u00e6\u2014\u00a5
result literal: \u00e6\u2014\u00a5DD\u00e6\u0153\u02c6MM\u00e5\u00b9\u00b4YYYY
If I add the print statement unconditionally on linux I get
revStr: \u65e5DD\u6708MM\u5e74YYYY
str: YYYY\u5e74MM\u6708DD\u65e5
result literal: \u65e5DD\u6708MM\u5e74YYYY
Some properties on my windows box are:
file.encoding = Cp1252
file.separator = \
java.class.path =
java.class.version = 61
java.vm.specification.version = 17
line.separator = \r \n
native.encoding = Cp1252
os.arch = amd64
os.name = Windows 11
os.version = 10.0
path.separator = ;
sun.arch.data.model = 64
sun.io.unicode.encoding = UnicodeLittle
sun.java.launcher = SUN_STANDARD
sun.jnu.encoding = Cp1252
sun.stderr.encoding = cp437
sun.stdout.encoding = cp437
user.country = DE
user.language = de
- relates to
-
JDK-8337066 Repeated call of StringBuffer.reverse with double byte string returns wrong result
-
- Closed
-
- links to
-
Commit(master) openjdk/jdk17u-dev/93b2aa48
-
Review(master) openjdk/jdk11u-dev/2961
-
Review(master) openjdk/jdk17u-dev/3030