JDK-8204620 : ModuleEntry::is_non_jdk_module() determination for what is a jdk module is incorrect
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-06-08
  • Updated: 2018-06-26
  • Resolved: 2018-06-14
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 11
11 b19Fixed
Related Reports
Blocks :  
JDK-8169559 - Add class loader names to relevant VM messages
Description
How a module is determined to be a JDK module within the VM needs to be reworked given that for example, java.corba and jdk.scripting.nashorn.shell are no longer considered part of the JDK.  Currently any unnamed module or named module whose location is "jrt:/java." or "jrt:/jdk." does not have the "@version_string appended to the end of the module's name.  ModuleEntry::is_non_jdk_module needs to be reworked.
Comments
StackTraceElement::toString omits module version if the module is hashed in java.base and the module is in the boot layer, i.e. non-upgradeable JDK modules. The VM implementation to determine if the module version should be omitted or not is an approximation. It currently omits module version if the module's location is "jrt:/java." or "jrt:/jdk." java.corba, java.xml.ws, jdk.xml.ws, jdk.snmp modules are removed from JDK. If they are placed on the module path, the module version will be printed. If they are linked to create a run-time image, their version will be omitted. To determine non-upgradeable JDK module, VM could use the same algorithm as StackTraceElement reading ModuleHashes attribute, or the library indicates that at define module time. We think a refinement to the current implementation would work well for most cases: Omit module version if a module location is from `jrt:/java.*` and defined to the bootstrap and platform loaders. java.corba and java.xml.ws are defined to the application class loader and so the module version will be printed, if present, and not considered as JDK module. Omit module version if a module location is from `jrt:/jdk.*` and defined to one of the builtin loader and same version as java.base. If a non-JDK module `jdk.foo` linked in a run-time image with same version as java.base then its module version will be omitted. It's not a big issue since the version of jdk.foo is shown from stack trace and `java --list-modules` and other ways. I expect it's not the typical case.
12-06-2018
Another approach would be to add an is_non_upgradeable flag to ModuleDescriptor that the JVM could access from the java.lang.Module object. StackTraceElement.java could also use this flag.
08-06-2018
The function is only used here: // Use version if exists and is not a jdk module if (module->is_non_jdk_module() && module->version() != NULL) { has_version = true; version = module->version()->as_C_string(); msglen += strlen("@") + strlen(version); } If jdk modules do not have versions or if it is ok to display their version then we could just remove is_non_jdk_module().
08-06-2018