This feature is a java10 feature list number: `296 – jdk multiple code repositories will be merged into a single comprehensive repository.
286: [Local-Variable Type Inference] (http://openjdk.java.net/jeps/286)
296: [Consolidate the JDK Forest into a Single Repository] (http://openjdk.java.net/jeps/296)
304: [Garbage-Collector Interface] (http://openjdk.java.net/jeps/304)
307: [Parallel Full GC for G1] (http://openjdk.java.net/jeps/307)
310: [Application Class-Data Sharing] (http://openjdk.java.net/jeps/310)
312: [Thread-Local Handshakes] (http://openjdk.java.net/jeps/312)
313: [Remove the Native-Header Generation Tool (javah)] (http://openjdk.java.net/jeps/313)
314: [Additional Unicode Language-Tag Extensions] (http://openjdk.java.net/jeps/314)
316: [Heap Allocation on Alternative Memory Devices] (http://openjdk.java.net/jeps/316)
317: [Experimental Java-Based JIT Compiler] (http://openjdk.java.net/jeps/317)
319: [Root Certificates] (http://openjdk.java.net/jeps/319)
322: [Time-Based Release Versioning] (http://openjdk.java.net/jeps/322)
In the previous article, feature 286 was introduced: [local variable type inference] (https://blog.zhouzhipeng.com/java10-features-local-variable-infer.html), friends who haven’t seen it can see it first. Look at it 🙂
Because this feature is mainly
jdk internal warehouse optimization, and does not involve features such as compilers. So here is mainly based on translation and interpretation. Let’s take a sneak peek!
Combine the numerous repositories of the JDK forest into a single repository in order to simplify and streamline development.
In order to simplify the development process, several code repositories of
jdk are assembled into a code repository.
Over the years, JDK’s complete code base has been broken down into multiple code repositories. There are eight repositories in JDK 9: root, corba, hotspot, jaxp, jaxws, jdk, langtools, and nashorn.
While this multi-warehouse model offers some advantages, it also has a number of disadvantages and does not work well in source code management operations. In particular, it is not possible to perform atomic commits across repositories of interdependent change sets.
In order to solve the above problems, a prototype of a comprehensive warehouse has been developed. The prototype can be:
Some support conversion scripts for creating prototypes are attached as unify.zip.
In the prototype repository, eight repositories have been merged into a single repository using an automatic conversion script that keeps a history at each file level and is used to mark some changes to the JDK. Change set comments and creation dates are also retained.
The prototype has another level of code reorganization. In the merged repository, the Java module’s code is usually combined in a single top-level src directory. For example, there is a module-based directory in the JDK composite warehouse today.
$ROOT/jdk/src/java.base ... $ROOT/langtools/src/java.compiler ...
In a comprehensive warehouse, the code is organized as follows:
$ROOT/src/java.base $ROOT/src/java.compiler ...
Therefore, in the root of the code repository, after the merge and src directories are combined, the relative path of the source files in the module is preserved.
The test directory organization form changes as follows:
Since only a prototype is currently being worked on, not all parts are fully completed, and compatibility and appropriateness need to be adjusted in some places. The HotSpot C / C++ source code is moved to the shared src directory along with the modular Java code.
The regression test will run with the current state of the prototype, but further integration of the jtreg configuration file is possible and may be completed in the future.