Before we begin, let me remind everyone that JSR-277 is only in the early draft stage, and it is by no means complete. The design in the early draft is deliberately kept simple, so we can make the spec available to the Java community sooner for feedbacks. Thus, it should be no surprise if you find issues or holes in the early draft (otherwise, it's not really an "early" draft anymore, right?). In any case, if you have any feedback on the early draft, please send them to jsr-277-comments@jcp.org.

Now, are you ready? Here we go:

Q: What are the advantages of JSR-277 compared to other existing systems?

Many existing systems (e.g. .NET, OSGi, NetBeans, Maven, Ivy, etc.) offer reasonable solutions in their problem space, but they are not trying to solve the same problem as JSR-277. Because JSR-277 will become part of the core Java platform, it has several distinct advantages that allows us to solve problems in a different (and we think more elegant) ways than existing systems, for example,

* It can, in theory at least, define a better solution since it has the ability to mandate deep changes to the underlying architecture of the SE platform, and in particular class loading, which is something that no previous module system could do.
* It can integrate with JSR-294, which will move module definitions from crufty XML files into the Java language itself. Kind of like replacing Java EE 1.4 deployment descriptors with in-code annotations in Java EE 5.
* It is extensible. That should make it possible for other systems to interact with the Java Module System and even make it possible for them to offer new features made possible by the integration of JSR-277 into the Java platform. We are still working out many of the details and would appreciate feedback on this topic.

To learn from the experience of existing systems, JSR-277 has a large (20 members) and very diverse EG to accommodate a variety of viewpoints (e.g. a few members are .NET experts, two are OSGi experts who co-authored the R4 modularity spec, one is Maven's creator and one is Maven expert, one is Ivy's creator, etc.).

Q: Does the module system do built-in type consistency checking?

Yes. After each module instance is connected to all of its imports, shallow validation is performed on the module instance. One of the checks shallow validation will go through is to ensure that there is no overlap in the exported types from imported modules. Let's look at an example,

A import B v1.0, C v1.0
B import D v1.1
C import D v1.0

Suppose type T is in D. If type T is neither re-exported from B or C, then T is not visible to A at all and there is no type inconsistency. If type T is re-exported only from B or only from C, there is still no type inconsistency. Only when type T is re-exported from both B and C, there is a type consistency issue, but it will be caught by shallow validation automatically and A will not be fully initialized.

It is true that if B returns an object of type T to A via a "cast" to a superclass such as java.lang.Object, and B passes that object to C with tries to cast it to T, then that will fail. However, this is a rare scenario in real applications and we expect that the deep validation would catch this kind of inconsistency.

It is still fair to say that type consistency checking is not explicitly spell out in the early draft, and it probably requires lots of refinements in the next few months. If you have any good suggestion to contribute in this area, I'm sure the EG would appreciate your inputs.

Q: Can modules be loaded or unloaded at runtime? Does it require a JVM restart?

Yes, modules can be loaded or unloaded at runtime.

New modules can be installed into a repository at runtime for the module system to use and load them. Existing modules can also be uninstalled from the repository at runtime so they will not be used when other modules request them subsequently.

When a new repository is created at runtime, modules from the new repository will become available to the module system dynamically. When a repository is shutdown, all modules will be torn down so they can be unloaded eventually. (See Section C.10 in the early draft - how to tear down a module is a future work item for the EG). In fact, we expect module-based Java applets and JNLP applications will be supported by using the URLRepository class, so web-based modules can be loaded and unloaded from a codebase dynamically in a JVM.

In any case, JVM restart is NOT required to load or unload modules.

Q: Mapping a module file (defined in JSR-294) to the module metadata (in JSR-277) seems like a huge constraint. Does it mean that the deployment module is rigidly bound to the development module?

Actually, I consider this degree of integration between JSR-277 and JSR-294 a big advantage. This allow us to move module definitions from crufty XML files into the Java language itself. This is kind of like replacing Java EE 1.4 deployment descriptors with in-code annotations in Java EE 5. Also, by specifying the module information directly in the source file, the compiler can validate the module information to ensure its correctness (How many hours did you spend on debugging manually written metadata?); it'll also be possible for developers to compile a module and generate a JAM file for deployment in a single step - without going through a separate step for writing separate metadata and packaging like what we have been doing for years.

Q: Why didn't the spec use a XML representation format for module metadata?

The format for the module metadata will be defined in JSR-294, and the actual format has not yet been decided by the JSR-294 EG. What is shown in the JSR-277 early draft is just a logical representation of the information in the module metadata file and should not be mistaken for the physical file format. Make no mistake, XML is a reasonable representation format for typical metadata. On the other hand, because the module metadata will be used directly by the JVM to enforce module membership and module-level access control, I won't be surprised if the JSR-294 EG decides to use a more compact representation format.

Q: Does JSR-277 have split package problem?

Split package refers to the issue that classes from the same package can come from different modules through the import. We currently do not plan to support split packages in JSR-277. It will be spelled out more explicitly in the JSR-277 specification in the future.

Q: Isn't specifying the import policy declaratively in the metadata a better choice than expressing the import policy in Java code?

Not necessarily. Designing declarative metadata is typically based on a set of requirements. However, as soon as there are new requirements arise that the existing design can no longer satisfy these requirements, the declarative metadata will need to be extended. Imagine if you want to use a module with metadata v2 in a module system that only recognizes metadata v1, you'll likely run into some problems. Import policy has no such problem because developers can express any logic they want in the code as long as the programming language and the class libraries support it, and the import policy can be executed and supported by all versions of the module system.

It's a valid concern that some import policies may not be written properly thus may cause side effect to the module system. However, it is not much different from encountering problems while executing code in the static initializer or instance initializer today. Even if the import policy results in exception during execution, this is really not an issue as long as the JVM can recover gracefully from it.

It's also a valid concern that expressing the import policy in Java code may be difficult for tools and management systems to analyze module dependencies, and this will be addressed in the next question.

Q: Without declarative metadata, it seems impossible for tools and management systems to analyze module dependencies.

It is not uncommon for the module system to have many repositories at runtime. Contents in the repositories are opaque, and they could be stored in different media (for instance, file system, database, HTTP server); the Repository APIs would effectively hides that from the application/tool. In addition, new repositories could be created and existing repositories could be removed at runtime. Also, it is possible that some implementations of the module system could provide mechanism to override/block/redirect module dependencies based on some deployment policies. Given there are so many potential variations in deployment, if tools and management systems attempts to analyze the module dependencies by accessing the physical metadata from the modules in the repositories, the task would be very complicated. Perhaps asking a different question would help:

Does it really make sense for tools and management systems to parse all the module metadata from the repositories and analyze module dependencies on their own, given all the capabilities in accessing the modules from the repositories and in supporting any potential override mechanism are already built into the module system?

Obviously, the answer is no. In fact, if the module system can provide APIs to expose dependency information it already has for a specific module, tools and management systems can simply make use of the dependency information provided by the module system. Hence, it is not necessary for module metadata to be declarative in order for tools and management systems to analyze module dependencies. As mentioned in Section C.5 in the early draft, missing dependency prediction is one of the future work items for the EG.

Q: Does the module system support module lifecycle?

The early draft specification does not spell out any lifecycle support in details, but it is on the EG's radar. As mentioned in Section C.6 in the early draft, more explicit lifecycle is one of the future work items. If you have any requirements on this feature, I'm sure the EG would like to hear them.

Q: Does the module system support optional import dependency?

Optional import dependency is currently not supported in the early draft. However, the EG may consider such feature if there are reasonable use cases and sufficient demands. If you have any requirements, I'm sure the EG would appreciate your feedbacks.

Q: Is the built-in repository model too simplistic?

Yes, but for good reasons. One of the strengths of the Java Module System is its extensibility. It makes it possible for 3rd parties to plug in custom repository implementations to address complex or unforeseeable cases when these cases arise. Hence, we can keep the built-in repository model very simple, and it doesn't have to deal with every possible use cases.

Q: The early draft does not specify how the module-aware compiler should compile the module sources.

The language aspect and compilation aspect of a module will be defined in JSR-294, instead of JSR-277. Having said that, we will likely provide more explicit instructions in the future for module-aware compilers to generate versioning constraints properly when compiling JSR-294 module in the context of JSR-277.