JDK-8148248 : Pre-defined attributes in JVMS 4.7 may appear in binary form of a module declaration
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.module
  • Affected Version: 9,9-repo-jigsaw
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2016-01-26
  • Updated: 2016-06-01
  • Resolved: 2016-06-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9-repo-jigsawResolved
Related Reports
Relates :  
JDK-8148834 - Update module-info reader/writer to 53.0
Description
Document: lang-vm.html
Chapter:   2.
Assertion:
...
attributes: One Module attribute must be present. Except for Module, InnerClasses, Synthetic, SourceFile, SourceDebugExtension, and Deprecated, none of the pre-defined attributes in JVMS 4.7 may appear.
...
The following pre-defined attributes in JVMS 4.7 can be added to CF without raising any exceptions:  ConstantValue, Code, Exceptions, Signature, LineNumberTable 
(see attachment)
Comments
Latest JCK 9 VM tests indicate that Runtime behaves as written in the document lang-vm.html (Chapter 2) 2 JCK tests that fail with the exception: "CV must be >= 53.0" is in the exclude list because HotSpot prior to b120 (JDK-8148651) allows to module-info to be less than 53.0
01-06-2016
Sergei - I think you've latched onto the wrong bug. The failure in your log is "java.lang.module.InvalidModuleDescriptorException: Must be >= 53.0" so I assume you are running an older version of JCK that has not upgraded its module-info.class files to v53.0.
31-05-2016
I will close this issue as soon as appropriate tests are integrated into JCK 9.
19-04-2016
Can we drop the conformance and tck-red-9 labels from this issue? I don't think we have any conformance tests failing now.
19-04-2016
JDK-8148834 tracks updating the module-info.class reader to check the major/minor version. This will happen once the transition to accept and generation v53.0 class files is done in JDK 9.
04-02-2016
We've updated the module-info.class parser in jake so that InvalidModuleDescriptorException is thrown if any of the 18 pre-defined attributes that are not allowed is in the class file. For now, InnerClasses, Synthetic, SourceFile, SourceDebugExtension, and Deprecated are skipped (not parsed) so further work is required. The current implementation will detect when there is more than one SourceFile or SourceDebugExtension attribute. One other thing to mention is that we don't have too many tests for malformed module-info.class in the jdk repo. I've created some tests but don't want to duplicate tests that will be in the JCK and elsewhere.
27-01-2016
A few more notes on the January 2016 implementation: - the major_version/minor_version is not checked, this is only because we haven't transitioned to 53.0 yet. - the requires_count is > 0 for all modules except "java.base". It does not currently check that the requires_count is 0 when the module name is "java.base". - requires_flags other than ACC_PUBLIC, ACC_SYNTHETIC and ACC_MANDATED are ignored.
27-01-2016
It's not clear how to run these JCK tests but just to say that the module-info.class parser currently ignores/skips all attributes except for Module, Synthetic, and the (currently JDK-specific) ConcealedPackages, Version, MainClass and Hashes attributes.
27-01-2016
Alan, JCK-VM is saying that the draft JVM Spec demands exactly one Module attribute, up to one Synthetic attribute, zero Code attributes, etc -- but that HotSpot is not currently enforcing these constraints. JCK-VM is uninterested in whether some other actor (e.g. java.lang.module.ModuleDescriptor) enforces these constraints. The JVM Spec will eventually make clear that a class file containing a Module attribute has its constraints checked by the Java SE API, not the JVM. The JVM Spec already defers to the Java SE API for the Runtime*Annotations family of attributes; now it will be deferring for the entire class file. (To record some color about the API's checking as of January 2016: The VM (meaning HotSpot) doesn't read module-info.class, it all done by ModuleDescriptor.read which throws InvalidModuleDescriptorException when it encounters an invalid module descriptor. It will detect structural issues and will detect duplicate Module attributes but beyond that it only detects: - access_flags != ACC_MODULE - this_class not of the form name/module-info - Any of super_class, interface_count, fields_count, method_count > 0)
26-01-2016