-
Bug
-
Resolution: Fixed
-
P3
-
None
JVMS Chapter 4.8 "Format Checking" states base checks for a basic class file integrity. It is expected that the "format checking" process occurs when a module-info.class file is loaded by JVM and it ensures that the recognized attribute "Module" is well formed.
In the case of module-info, for example, the following unwell formed class file that is used to test the assertion:
"If the exports_count item is zero, then the Java Virtual Machine does not infer the existence
of an exports table nor the existence of any particular entry therein."
module callee02 {
0xCAFEBABE;// magic
0;// minor class version
52;// major class version
[6] {
{ };// first element is empty
Utf8 "callee02/module-info";// #1
class #1;// #2
Utf8 "Module";// #3
Utf8 "java.base";// #4
Utf8 "javasoft/sqe/jck/tests/vm/callee";// #5
.........
// attribute "Module"
Attr(#3) {
// requires
[1] {
{ #4 0x0020 };
};
// exports
[0] { // [1]
{ #5 [] {} };
}
Here u2 exports_count is 0 although the exports table is not empty.
cause
java.lang.NullPointerException
at java.lang.module.ModuleInfo$ConstantPool.getClassName(java.base@9-ea/ModuleInfo.java:624)
at java.lang.module.ModuleInfo.readModuleAttribute(java.base@9-ea/ModuleInfo.java:326)
at java.lang.module.ModuleInfo.doRead(java.base@9-ea/ModuleInfo.java:210)
at java.lang.module.ModuleInfo.read(java.base@9-ea/ModuleInfo.java:89)
at java.lang.module.ModuleDescriptor.read(java.base@9-ea/ModuleDescriptor.java:1427)
at java.lang.module.ModulePath.readExplodedModule(java.base@9-ea/ModulePath.java:536)
at java.lang.module.ModulePath.readModule(java.base@9-ea/ModulePath.java:272)
at java.lang.module.ModulePath.scanDirectory(java.base@9-ea/ModulePath.java:236)
at java.lang.module.ModulePath.scan(java.base@9-ea/ModulePath.java:188)
at java.lang.module.ModulePath.scanNextEntry(java.base@9-ea/ModulePath.java:145)
at java.lang.module.ModulePath.find(java.base@9-ea/ModulePath.java:109)
at com.oracle.jmpp.lib.module.runner.ModuleAccessor.find(ModuleAccessor.java:65)
I believe the ClassFormatError should be thrown and the checking needs to be more robust.
<< enclosed JCK partial build that holds corrupted module-info.class files>>
In the case of module-info, for example, the following unwell formed class file that is used to test the assertion:
"If the exports_count item is zero, then the Java Virtual Machine does not infer the existence
of an exports table nor the existence of any particular entry therein."
module callee02 {
0xCAFEBABE;// magic
0;// minor class version
52;// major class version
[6] {
{ };// first element is empty
Utf8 "callee02/module-info";// #1
class #1;// #2
Utf8 "Module";// #3
Utf8 "java.base";// #4
Utf8 "javasoft/sqe/jck/tests/vm/callee";// #5
.........
// attribute "Module"
Attr(#3) {
// requires
[1] {
{ #4 0x0020 };
};
// exports
[0] { // [1]
{ #5 [] {} };
}
Here u2 exports_count is 0 although the exports table is not empty.
cause
java.lang.NullPointerException
at java.lang.module.ModuleInfo$ConstantPool.getClassName(java.base@9-ea/ModuleInfo.java:624)
at java.lang.module.ModuleInfo.readModuleAttribute(java.base@9-ea/ModuleInfo.java:326)
at java.lang.module.ModuleInfo.doRead(java.base@9-ea/ModuleInfo.java:210)
at java.lang.module.ModuleInfo.read(java.base@9-ea/ModuleInfo.java:89)
at java.lang.module.ModuleDescriptor.read(java.base@9-ea/ModuleDescriptor.java:1427)
at java.lang.module.ModulePath.readExplodedModule(java.base@9-ea/ModulePath.java:536)
at java.lang.module.ModulePath.readModule(java.base@9-ea/ModulePath.java:272)
at java.lang.module.ModulePath.scanDirectory(java.base@9-ea/ModulePath.java:236)
at java.lang.module.ModulePath.scan(java.base@9-ea/ModulePath.java:188)
at java.lang.module.ModulePath.scanNextEntry(java.base@9-ea/ModulePath.java:145)
at java.lang.module.ModulePath.find(java.base@9-ea/ModulePath.java:109)
at com.oracle.jmpp.lib.module.runner.ModuleAccessor.find(ModuleAccessor.java:65)
I believe the ClassFormatError should be thrown and the checking needs to be more robust.
<< enclosed JCK partial build that holds corrupted module-info.class files>>