BinaryDoc - Binary code is the Best Document

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

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 . Source code: master/src/java.base/share/classes/module-info.java   The binary file is located at: JAVA_HOME/jmods/java.base.jmod - classes/module-info.class 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 ", whic

The OpenJDK community is trying to modularize the OpenJDK itself in the past years, and the following Dependency Network diagrams of OpenJDK jar/jmod files can show it visually. Dependency Network diagrams of OpenJDK 7 Dependency Network Diagram of OpenJDK 7 Dependency Network diagrams of OpenJDK 8 Dependency Network Diagram of OpenJDK 8 Dependency Network diagrams of OpenJDK 9   Dependency Network Diagram of OpenJDK 9 Dependency Network diagrams of OpenJDK 10 Dependency Network Diagram of OpenJDK 10 Dependency Network diagrams of OpenJDK 11 Dependency Network Diagram of OpenJDK 11 Dependency Network diagrams of OpenJDK 12 Dependency Network Diagram of OpenJDK 12 Dependency Network diagrams of OpenJDK 13 Dependency Network Diagram of OpenJDK 13 From the diagrams above, we can have the following points: OpenJDK 7 and 8 is very similar, well there is a big change Since OpenJDK 9 Since Java 9, the keyword module has been

A Java method in .class file marked with the ACC_SYNTHETIC flag to indicate that it was generated by Java compiler and does not appear in source code. Binary Code is always the best document. So let's inspect an example of such case: the Java method AbstractPlainSocketImpl . lambda$getInputStream$0() in Java package java.net is tagged as synthetic in AbstractPlainSocketImpl.class . The UML generated form the AbstractExecutorService.class file indicates it contains a method named lambda$getInputStream$0() , and the detailed inspection shows this method is generated by compiler, since its "Access Flags" contains the value synthetic , which means this field " not present in the source code ". UML Diagram generated from AbstractExecutorService.class Basic Information of Method lambda$getInputStream$0() So why Java compiler is generating this method? Let's continue to inspect the method AbstractPlainSocketImpl.lambda$getInputStream$0() . T

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()

A Java field in .class file marked with the ACC_SYNTHETIC flag to indicate that it was generated by a compiler and does not appear in source code . Binary Code is always the best document, so let's inspect an example of this case, from the class AbstractExecutorService ( source code ) in the package java.util.concurrent . The UML generated form the AbstractExecutorService.class file indicates it contains a field named $assertionsDisabled , and the detailed inspection shows this field is generated by compiler, since its "Access Flags" contains the value synthetic , which means this field "not present in the source code". UML diagram generated from AbstractExecutorService.class   Details page for the field AbstractExecutorService.$assertionsDisabled So why Java compiler is generating this field? Let's continue to inspect the field AbstractExecutorService.$assertionsDisabled . From the .class binary data analysis, the field Abstract

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

Java is famous for its cross-platform feature, and declared as Write once, run anywhere (WORE). Well the question is, how many platforms Java can run? Code always contains the best answer, let's investigate the code of Java Virtual Machine (JVM) for this. The Architecture ( source code ) class in the jdk.internal.vm.ci.jmod module indicates the CPU architectures Java Virtual Machine can run on:   UML Hierarchy Diagram for Java class Architecture We can found Java can execute on the following three (3) CPU architectures / platforms: AArch64 ( source code ): ARM CPU, 64 bit, which is mostly used in Mobile devices, like Android phone, Android PAD, Apple iPhone, etc AMD64 ( source code ): x86 CPU, 64 bit, which is used by most laptop and desktop computers, including Acer, Apple, Asus, Dell, Hewlett-Packard (HP), IBM, Lenovo, Samsung, Toshiba, etc SPARC ( source code ): SPARC CPU, originally designed by Sun Microsystems , which is used by powerful servers