Go to the Java 7 Module System

I was very excited after watching the demo of javasxx on jigsaw. I think it should be a solution for problems such as complex class path versions and jar traps. Developers can eventually use any version of xalan they expect without being forced to use the authorization mechanism. Unfortunately, the journey to a more effective module system is not very clear.

Before studying the problem, let's look at some basic concepts:

　　Modular

　　Modular

Is an important tool for solving complexity issues. It is an effective method to divide an application into different parts (modules, libraries, packages, sub-projects, and components) and calculate them separately. The ultimate goal of modularity is to define an API for inter-module communication.

If all the communication between modules is implemented only through this API, the modules are loosely coupled, so:

It is easy to change the implementation of a module.

The development and testing modules can be easily independent.

The object-oriented model is similar. In Oop, it is ideal to have a large number of small, reusable, simple, and well-separated objects. In the module system, small, reusable, simple, and well-separated modules can be perfectly implemented. Their ideas are exactly the same as their original motives, but their scale is different.

　　Logical separation

　
Traditionally, Java has two methods to implement modularity. Logical separation is the most natural way. It includes dividing an application into a logical module (sub-project) and then deploying it into a complete application. Pass
It is also possible to implement logical separation by using the correct package, but the more common method is to split the application into some archive files (that is, the jar package ). The logic separation can promote the reuse of modules and facilitate the coupling between modules.
. You may even define an API and declare that communication between all modules must be achieved through the given API. There is a big problem with this idea, that is, it is very difficult for you to use this restriction.
And there is no mechanism to ensure the usage of this API. You cannot distinguish the classes used by applications by a given module from those used as part of a public API. If a class is
Public ", then it can be used by any other class, no matter which module the class that calls it belongs. On the other hand, the calls of protected or package-level visibility classes within their modules are also limited. Generally,
Modules that cover some packages and classes in the package must be able to call each other. Therefore, even if an application is composed of some logic modules, if these modules are coupled, separation is useless at all.

　　Physical separation

　
Another traditional approach is physical separation. You can split an application into different components and deploy each component on different JVMs for separation. These components are accessed remotely.
Communication, such as RMI, CORBA, or WebServices. Physical separation achieves separation and loose coupling, but the negative impact is a great expense. Dedicated remote access for Separation
Question mechanism: It's a bit cool. This increases the unnecessary complexity of development and deployment, and the impact on performance cannot be ignored.

　　Module System

　　Module System

　
The role is between logical and physical separation. It emphasizes module separation, but each module is still deployed in the same JVM, and communication between modules is composed of simple and traditional method calls, so there is no running
. The most popular module framework in the Java ecosystem is osgi. It is a mature specification with several different implementations. In osgi, a module is called a bundle.
Bundle is equivalent to a jar. Each bundle also contains a META-INF/manifest. MF file that will announce which packages to export)
And which packages to import. Only the classes in the export package can be used by other bundle, while other packages only target the internal members of the package. The classes in the package can only be used in the bundle itself.

For example, the following statement:

Manifest-version: 1.0

Import-package: net. krecan. Spring. osgi. Common

Export-package: net. krecan. Spring. osgi. Dao

Bundle-version: 1.0.0

Bundle-Name: Demo-spring-osgi-Dao

Bundle-symbolicname: net. krecan. spring-osgi.demo-spring-osgi-dao

　
This specification specifies the bundle named demo-spring-osgi-Dao.
Net. krecan. Spring. osgi. Common class, and export the class in the package named net. krecan. Spring. osgi. Dao. In other words
This statement indicates that other modules can only use the net. krecan. Spring. osgi. Dao package. On the contrary, this module only needs to use
Net. krecan. Spring. osgi. Common package, and osgi may provide a dedicated module to export the package. Of course, you can import and export
Multiple package names are defined in.

Note that osgi modularization is built on java. It is not part of the language! The module separation here can be implemented by the GUI
But cannot be executed by the compiler. When running an osgi-based application, you need an osgi container. This container may be part of the runtime environment, for example, in the springdm Server
Or embedded in an application. This container not only provides separation, but also provides other services such as security, module management, and lifecycle management. Osgi also provides a lot of other interesting features
But these are not what this article focuses on.

There was a lot of controversy about the JSR-277, and this JSR was partially repeated with osgi. For several months in a row, both sides of the experts tried to debate who was better until the JSR-277 was declared to give up, and the new module system would be part of java7.

　　JSR-294

The first part of this new module system is the JSR-294, the so-called Super package. This specification explains the concept of the Java language module.

　　JSR-294

　
A new visibility keyword "module" is introduced ". If a member has such visibility, it means that it is only visible to members in the same module. It creates an internal API with only modules
Can be called. In this case, the "public" keyword should be used only when a public API is declared. In other cases, you should use "module" or have more restrictions on visibility.
Key word. Of course, once the language contains the "module" keyword, the compiler will check the visibility constraints between modules.

　　JSR-294

You can also define dependencies. In a given version, you can define that a module depends on another module. For example:

// ORG/netbeans/CORE/module-info.java

@ Version ("7.0 ")

@ Importmodule (name = "Java. se. Core", version = "1.7 + ")

Module org. netbeans. core;

　
The last statement indicates that the "org. netbeans. Core" module depends on version 1.7 or later of "Java. se. Core. This is similar to Maven dependency or
Osgi import. You can also ignore these syntaxes for the moment, because the syntax may change in the future. It is important that the dependency here is defined in the module-info.java and will be compiled
To the class file. In osgi, dependencies are defined in common text files.

　　Jigsaw Project

　　Jigsaw Project

　
Is the second part of the new module system. I expect it will be sun-specific implementation of the JSR-294, or sunjdk's modular implementation. Since it is necessary to create a complete JDK Modularization
Sun wants to split the standard library into modules. This directly simplifies content integration in JRE. All content except swing of the entire JRE can be run on mobile devices. It is also possible
Introduce a new standard API for the language without waiting for the release of a new version of the entire platform. At present, it seems that this project is absolutely promising.

But I have another concern, that is, the relationship between ahref = "http://blogs.sun.com/mr/entry/jigsaw"> proprietary jigsaw and JSR standards is not clear, as markreinhold said:

　
The investment in jigsaw will undoubtedly create a simple, low-level module system, and its design will strictly develop towards the JDK modularization goal. Developers can apply this module system
Sun will definitely support this module system in their code, but it will not be the official part of the specifications of the E7 platform, or be supported by other SE 7 implementations.

　
This section is not very clear, and there are many questions. Does it mean that the created module can only run in sunjre? I 'd like to say that if the developer writes
"@ Importmodule (name =" Java. se. Core ", version =" 1.7 + ")", this module can only run in sunjre
Cannot I run it in the ibmjre environment? Or does Sun divide its JRE into many modules in some way, and Oracle will choose another method to separate it? (Translator)
Note: At least it seems that there is no such possibility, because Oracle just acquired Sun ). We don't want to, because there is another principle of "writing once and running everywhere.

More problems will be solved in detail. We do not know what the main goal of the jigsaw project is. According to the main goals announced by the project itself, sunjre is designed to be modularized. However, if it is purely modularized, no language changes are required. Sun can modularize JRE without modifying the Java language itself.

Will the changes in these languages become a by-product of sunjre modularization? If so, it would be totally wrong! Language changes must be a first-class citizen, rather than an exclusive by-product.

　　Dependency

　
My other concern is dependency. If dependencies are managed by the module system, classpath is no longer required. On the one hand, this is good because classpath often causes the so-called
. On the other hand, classpath is extremely flexible. I am afraid this flexibility cannot be possessed by a static module dependency. Let's see why:

　　Dependencies during deployment

　
Java has two types of paths (classpath ). One is the build path (buildpath), which is used during the build. The other is the class path, which is used at runtime. The two are almost the same,
But not exactly. The typical example is the JDBC driver. During construction, you do not need to specify the JDBC driver. The JDBC interface is part of the Java core library. But at runtime, it is necessary to ensure that the class
The path contains the JDBC driver. If a programmer needs to modify the database connection, he only needs to modify the name of the driver class in the configuration file and add the driver JAR file to the class path. If
Some dependencies need to be specified during compilation, and developers obviously cannot do this. Of course, in javaee, it can use the JNDI data source, but there is nothing similar in javase.
The JDBC driver has to re-compile the entire application, which is obviously unreliable.

Generally, recompilation is unlikely. In some organizations, the final application is composed of modules of the so-called application assembler. The developer does not have source code. He just puts some jar files together, modifies the configuration file, and creates the final package. The role of the application assembler is even mentioned in Java EE specifications.

　　Optional dependency

　
Similar problems are optional dependencies. Let's assume that we want to build a log framework like log4j. This library can log on JMS, so the JMS package must be included in the build path. But 99%
Users do not use JMS logs, so they do not need to put dependencies in the class path. There must be a mechanism to solve such problems. We need a library to build this module. This dependency depends on the final
Users are optional. Of course, the perfect situation is that the JMS function will be an independent module, but we are not living in a perfect world, and sometimes it is not realistic to use this method to separate projects.

　　Dependency conflict

　
Another major problem is dependency conflicts. If you have used Maven, it is not difficult to understand what I am talking about. Most enterprise applications use about a dozen third-party libraries.
A conflict occurs. For example, a developer wants to use hibernate, it depends on the commons-collections2.1.1, he also wants to use commons-DBCP,
But need to rely on commons-collections2.1. Developers themselves or application assemblers need to decide how to solve such problems. It either decides to use only a specific version
Library, or decide to use different versions of the class library in different parts of the application. It is important that these problems cannot be solved on their own. It is always determined by a person who understands how each module works in an application.
It also identifies possible incompatibility between different versions.

There are many other things about Java dependencies that I will not discuss in this article, but it should be noted that they are not static. I
The component of an application may use a set of class libraries, but its operation requires a completely different set of libraries. All module systems must solve these problems in some way. Maven has a lot of information about how to configure
Dependency, and how to handle dependency conflicts, but it is just a build system. The worst case is that you need to manually configure the class path. Osgi is another situation. It only processes Runtime (during deployment) according
Lai, regardless of the build. The new Java module system supports both build time and runtime dependencies (I guess), and even makes the existing complex problems more complex.

　　Summary

　
Of course, I believe Sun's engineers do not want to destroy Java itself. I think they also want to make Java better and easier to use, but I am worried that political and market factors will be far greater than technological influences. Again
This is not just an API change or a sun-specific change. This will change the language level! Once the language is changed, once the "module" keyword is added, there will be no more
Turning back. At that time, there will be a module system in Java. Whether we like it or not, we have to use this module system. It's hard to imagine a modularized JVM or a Java language
Module keyword, and we need to use osgi on this.

From: http://it.hexun.com/2009-05-14/117684830.html