Re: Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java

2021-11-04 Thread Cheng Jin





Hi There,

Hotspot developers already identified a bug in verification (failure to
capture an invalid package name "die/verwandlung/" existing in the constant
pool of bytecode) at https://bugs.openjdk.java.net/browse/JDK-8276241 as I
raised via
https://mail.openjdk.java.net/pipermail/hotspot-dev/2021-October/055618.html
, which was associated with the issue here in XSLT transformation given the
invalid package name "die/verwandlung/" was actually triggered by OpenJDK
due to the incorrect result from setClassName(Util.baseName(systemId))
(systemId = "xxx:" in which case Util.baseName(systemId) returns null and
setClassName(null) ended up with "die/verwandlung/" in generating the
bytecode). So I expect someone in OpenJDK to take a look into this issue to
see what really happened to the code there in such case. Thanks.


Thanks and Best Regards
Cheng Jin


RE: Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java

2021-11-03 Thread Cheng Jin




The issue for the XSLTC was raised at
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-October/082767.html
:


The code in compile(InputSource input, String name) at
https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java

seems incorrect as follows:

public boolean compile(InputSource input, String name) {
try {
// Reset globals in case we're called by compile(ArrayList v);
reset();

// The systemId may not be set, so we'll have to check the URL
String systemId = null;
if (input != null) {
systemId = input.getSystemId();
}

// Set the translet class name if not already set
if (_className == null) {
if (name != null) {
setClassName(name);
}
else if (systemId != null && !systemId.equals("")) {
setClassName(Util.baseName(systemId)); <---
incorrect here
}

// Ensure we have a non-empty class name at this point
if (_className == null || _className.length() == 0) {
setClassName("GregorSamsa"); // default translet name
}
}
...

Specifically, the code above assumes that systemId is something like
"xxx:yyy" in which case the class name (_className) is
"die.verwandlung.yyy" ("die.verwandlung." is the default package name since
Java11) However,Util.baseName(systemId) returns null when systemId is
something like "xxx:" (empty after ":"), in which case the class name
(_className) ends up with "die.verwandlung."(an invalid class name inserted
in the constant pool of the generated bytecode).

>From the perspective of robustness, the code above should be updated to
handle the situation. e.g.

else if (systemId != null && !systemId.equals("")) {
  String baseName = Util.baseName(systemId);
 if ((baseName != null) && (baseName.length() > 0))
{ <--
setClassName(baseName);
}

which means it should check whether the returned base name from
Util.baseName(systemId) is empty before setting the class name; otherwise,
it should use the default class name ("GregorSamsa").


Thanks and Best Regards
Cheng Jin

J9 VM, IBM Ottawa Lab at Riverside, Ottawa
IBM Runtime Technologies
+1-613-356-5625
jinch...@ca.ibm.com


Re: Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java

2021-11-03 Thread Cheng Jin




Hi There,

Hotspot developers already identified a bug in verification (failure to
capture an invalid package name "die/verwandlung/" existing in the constant
pool of bytecode) at https://bugs.openjdk.java.net/browse/JDK-8276241 as I
raised via
https://mail.openjdk.java.net/pipermail/hotspot-dev/2021-October/055618.html
, which was associated with the issue here in XSLT transformation given the
invalid package name "die/verwandlung/" was actually triggered by OpenJDK
due to the incorrect result from setClassName(Util.baseName(systemId))
(systemId = "xxx:" in which case Util.baseName(systemId) returns null and
setClassName(null) ended up with "die/verwandlung/" in generating the
bytecode). So I expect someone in OpenJDK to take a look into this issue to
see what really happened to the code there in such case. Thanks.


Thanks and Best Regards
Cheng Jin