Wikipedia:Redaktion Informatik/Fehlende Artikel/Java Platform Module System

The Java Platform Module System specifies a distribution format for collections of Java code and associated resources. It also specifies a repository for storing these collections, or modules, and identifies how they can be discovered, loaded and checked for integrity. It includes features such as versioning and namespaces with the aim of fixing some of the shortcomings in the existing JAR format, especially the JAR Hell, which can lead to issues such as classpath and class loading problems.

The Java Module System was initially being developed under the Java Community Process as JSR 277 and was scheduled to be released with Java 7.

JSR 277 later was put on hold and Project Jigsaw^[1] was created to modularize the JDK. This JSR was superseded by JSR 376 (Java Platform Module System).

Project Jigsaw was originally intended for Java 7 (2011) but was deferred to Java 8 (2014) as part of Plan B,^[2] and again deferred to a Java 9 release in 2017.^[3]. On 1 August 2017, the Java Expert Group responsible for the JSR 376 published the "Final Draft Proposal".^[4] Java 9 including the Java Platform Module System was released on September 21, 2017^[5]

The Java Module System implemented for Java 9 include the following JEPs and JSR (Java Specification Request):^[1]

• JEP 200: The Modular JDK: Define a modular structure for the JDK
• JEP 201: Modular Source Code: Reorganize the JDK source code into modules, enhance the build system to compile modules, and enforce module boundaries at build time
• JEP 220: Modular Run-Time Images: Restructure the JDK and JRE run-time images to accommodate modules and to improve performance, security, and maintainability
• JEP 260: Encapsulate Most Internal APIs
• JEP 261: Module System: Implement the Java Platform Module System
• JEP 282: The Java Linker: Create a tool that can assemble and optimize a set of modules and their dependencies into a custom run-time image^[6]
• JSR 376: Java Platform Module System^[7]

Additionally, several other JDK 9 features have been added to ease transition to the module system:

• JEP 238: Multi-Release JAR Files: Extend the JAR file format to allow multiple, Java-release-specific versions of class files to coexist in a single archive.^[8]
• JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization: Define public APIs for the JavaFX functionalities that is presently only available via internal APIs and would become inaccessible due to modularization.^[9]
• JEP 260: Encapsulate Most Internal APIs: Make most of the JDK's internal APIs inaccessible by default but leave a few critical, widely-used internal APIs accessible, until supported replacements exist for all or most of their functionality.^[10]
• JEP 275: Modular Java Application Packaging: The Java packager will evolve for JDK 9, making it aware of modules, allowing for example to package a module and all the modules it depends on.^[11]

Modules are a new way of grouping code and data. Contrary to Jar files, modules explicitly declare which modules they depend on, and what packages they export.^[12]

For example, the following module declaration declares that the module com.foo.bar depends on another com.foo.baz module, and exports the following packages: com.foo.bar.alpha and com.foo.bar.beta:

module com.foo.bar {
    requires com.foo.baz;
    exports com.foo.bar.alpha;
    exports com.foo.bar.beta;
}

Contrary to the Jar file format, the module will describe these dependencies in a module declaration which will be placed in a file named module-info.java at the root of the module’s source-file hierarchy. The JDK will able to check them both at compile-time and runtime. The JDK itself will be modularized for Java 9.^[13]

The Java Module System does not intend to support all the functionalities that the OSGi platform currently supports (for example the Life-Cycle model and the Services Registry). However the Java Module System will support functions which are not supported by OSGi, such as modularity at compile-time, and built-in support for native libraries.^[14] A couple of articles exploring how the Java Module System and OSGi could interoperate were published in 2016. These can be found on InfoQ^[15] and also the OSGi Alliance Blog.^[16]

• Java package
• Classpath (Java)
• Java Classloader

Vorlage:Reflist

• JSR 277
• JSR 294
• JSR 376
• Project Jigsaw
• The State of the Module System
• Java Platform Module System: Issue Summary

Category:Java platform Category:Java specification requests

1. ↑ ^{a b} Project Jigsaw. Oracle Corporation, abgerufen am 29. November 2015. 
2. ↑ Mark Reinhold: It’s time for … Plan B. Oracle Corporation, 20. September 2009, abgerufen am 21. Juni 2017. 
3. ↑ JDK 9. Oracle Corporation, abgerufen am 24. Februar 2016. 
4. ↑ JSR #376. Oracle Corporation, abgerufen am 11. August 2017. .
5. ↑ Java 9: Release date and new features. techworld.com, 21. Juli 2017, abgerufen am 18. November 2017. 
6. ↑ jlink: The Java Linker (JSR 282). Oracle Corporation, abgerufen am 12. März 2016. 
7. ↑ Java Platform Module System (JSR 376). Oracle Corporation, abgerufen am 29. November 2015. 
8. ↑ JEP 238: Multi-Release JAR Files. Oracle Corporation, abgerufen am 31. Juli 2017. 
9. ↑ JEP 275: Modular Java Application Packaging. Oracle Corporation, abgerufen am 31. Juli 2017. 
10. ↑ JEP 260: Encapsulate Most Internal APIs. Oracle Corporation, abgerufen am 31. Juli 2017. 
11. ↑ JEP 275: Modular Java Application Packaging. Oracle Corporation, abgerufen am 31. Juli 2017. 
12. ↑ Mark Reinhold: The State of the Module System. Oracle Corporation, 8. März 2016, abgerufen am 18. Februar 2017. 
13. ↑ JDK Module Summary. Oracle Corporation, 24. Juni 2016, abgerufen am 18. Februar 2017. 
14. ↑ Mark Reinhold: Project Jigsaw: Late for the train: The Q&A. Oracle Corporation, 24. August 2012, abgerufen am 29. November 2015. 
15. ↑ Java 9, OSGi and the Future of Modularity. InfoQ, abgerufen am 26. September 2016. 
16. ↑ Java Module Layers and OSGi Bundles. OSGi Alliance, abgerufen am 1. August 2016.