Java module-info Essentials, from Binary code point of view

Java module system has been introduced since Java 9, via the project Jigsaw. Each java module contains a module-info.class file, for the specification of current module. Here we are trying to make an introduction of the module-info file.

Binary Code is always the best document.

So let's inspect an example module-info: module info in java.base.jmod file, which is the biggest java module in current OpenJDK.

We can open the module-info.class file using Java Class Viewer, as the screen shots bellow.

The module-info.class file is a special type of .class file, and it has the following key differences from other normal .class file:

1. module-info.class do not have super class, interfaces, fields, methods.
  • From the screen shot bellow, we can find that the super_class node's value is "0", which means this module-info.class do not have a super class.
  • All other class will have a super/parent class; if the parent class did not specified in the source code, the java.lang.Object would be the super_class by default; this relationship would be added by the Java compiler (javac) automatically.
And, the module-info.class do not have interfaces, fields, and methods either, as the following screen shot indicates.
  • interfaces_count is "0" (zero), which means current module-info.class do not implement any interfaces
  • fields_count is "0" (zero), which means current module-info.class do not contain any fields
  • methods_count is "0" (zero), which means current module-info.class do not contain any methods

module-info.class overview for java.base.jmod in OpenJDK 11, via Java Class Viewer


2. module-info.class contains the Module attribute

The Module attribute specify the super details of current attribute, the full details could be found from the Java VM Specification.

Here we will highlight several interesting attributes of the Module attribute:

  • module_name_index: which is an index pointing to the module name: "java.base" in the following example
  • module_version_index: which is an index pointing to the module version: "11.0.4" in the following example, which is the OpenJDK version containing current module
  • exports_count and exports: the Java packages exported by current module. Current module exports 107 Java packages
  • uses_count and uses: the Java service interface used by current module. Current module uses 33 Java service interfaces, which the current module may discover via java.util.ServiceLoader
  • provides_count and provides: the Java service implementation provided by current module. Current module provides 1 Java service interface implementation


Module attribute in module-info.class for java.base.jmod in OpenJDK 11, via Java Class Viewer
Here is the details of the exports section, which contains the Java packages exported by current module, like:
  1. java.io
  2. java.lang
  3. java.lang.annotation
  4. java.lang.invoke
  5. java.lang.module
  6. java.lang.ref
  7. java.lang.reflect
  8. java.math
  9. java.net
  10. etc.

Exports section in Module attribute in module-info.class for java.base.jmod in OpenJDK 11, via Java Class Viewer



Here is the details of the uses section, which contains the Java service interface used by current module, like:

  1. java.lang.System$LoggerFinder
  2. java.net.ContentHandlerFactory
  3. java.net.spi.URLStreamHandlerProvider
  4. java.nio.channels.spi.AsynchronousChannelProvider
  5. java.nio.channels.spi.SelectorProvider
  6. java.nio.charset.spi.CharsetProvider
  7. java.nio.file.spi.FileSystemProvider
  8. java.nio.file.spi.FileTypeDetector
  9. java.security.Provider
  10. etc.



Uses section in Module attribute in module-info.class for java.base.jmod in OpenJDK 11, via Java Class Viewer


Here is the details of the provides section, which contains the Java service implementation provided by current module. Current module provides one service implementation:
  1. jdk.internal.jrtfs.JrtFileSystemProvider for java.nio.file.spi.FileSystemProvider

Exports section in Module attribute in module-info.class for java.base.jmod in OpenJDK 11, via Java Class Viewer

3. module-info.class contains the ModulePackages attribute

The ModulePackages attribute indicates all the packages of a module that are exported or opened by the Module attribute, as well as all the packages of the service implementations recorded in the Module attribute. The full details could be found from the Java VM Specification.

The following screen shot is an example values for ModulePackages attribute in module-info.class from java.base.jmod from OpenJDK 11:

  1. sun.security.ssl
  2. sun.reflect.annotation
  3. sun.net.ftp
  4. sun.net.www.protocol.http
  5. jdk.internal.jimage
  6. sun.security.tools
  7. com.sun.net.ssl
  8. java.nio
  9. sun.net.www.content.text
  10. etc.


ModulePackages attribute in module-info.class for java.base.jmod in OpenJDK 11, via Java Class Viewer



Location: Palo Alto, CA, USA

Comments

Post a Comment

Popular posts from this blog

What is Java Synthetic Class (ACC_SYNTHETIC)? with the example of BoundMethodHandle$1.class in Java package java.lang.invoke

Image
When a .class file marked with the ACC_SYNTHETIC flag, it indicates the .class file was generated by compiler and does not appear in the corresponding .java source code . Binary Code is always the best document, so let's check an example: the BoundMethodHandle$1.class class in java.base.jmod in JDK. The class file BoundMethodHandle$1.class has been marked as synthetic flag, as shown bellow: Basic Information of BoundMethodHandle$1.class  UML diagram of BoundMethodHandle$1.class And this class is used by the container class BoundMethodHandle : Dependency Network diagram of BoundMethodHandle$1.class This class does not exist in the original source code BoundMethodHandle.java , but generated by the java compiler, from the following two (2) methods in the Java class BoundMethodHandle : BoundMethodHandle.bindSingle() , at byte code offset 0 BoundMethodHandle.arg() , at byte code offset 17 Byte code of method BoundMethodHandle.bindSingle()
Read more

What is Java Bridge Method (ACC_BRIDGE)?

Image
Java method could be tagged with bridge ( ACC_BRIDGE ) in the .class file, denotes this method is generated by Java Compiler for type erasure purpose of Java Generics . Code is the best document, so let's check the code of java.util.ArrayDeque as an example for the details. In the source code of ArrayDeque , there is only one (1) clone() method defined, as bellow: public ArrayDeque<E> clone() { try { @SuppressWarnings("unchecked") ArrayDeque<E> result = (ArrayDeque<E>) super.clone(); result.elements = Arrays.copyOf(elements, elements.length); return result; } catch (CloneNotSupportedException e) { throw new AssertionError(); } } Well in the generated the .class file for ArrayDeque , there are two (2) clone() methods, as the generated UML diagram from the ArrayDeque.class file shown: UML Diagram of ArrayDeque.class Here are the details of
Read more

Java Native Methods Essentials, from Binary code point of view, with example of java.lang.Runtime

Image
Java Native method provides a mechanism for Java code to call OS native code, either due to functional or performance reasons. Binary Code is always the best document. Let's take the an example from OpenJDK of the class java.lang.Rutime to discover the details in binary code manner. Here is the source code of the Runtime class: master/src/java.base/share/classes/java/lang/Runtime.java In this class we have the following methods defined as native : 606 public native int availableProcessors(); 617 public native long freeMemory(); 630 public native long totalMemory(); 641 public native long maxMemory(); 664 public native void gc(); For the native Java methods, the corresponding generated methods in the class file will set the ACC_NATIVE ( 0x0100 ) flag, and the there is no bytecode generated in the .class file as other none-native Java methods. The access_flags field is a mask of flags used to denote access permission to and properties of an method: access
Read more