module-info

What is the difference between module with open keyword before and without it? For instance: open module foo { } module foo { } Michał Szewczyk In order to provide reflective access to your module, Java 9 introduced open keyword. You can create open module by using open keyword in module declaration. An open module grants reflective access to all of it's packages to other modules. For example, if you want to use some framework, that heavily relies on reflection, such as Spring, Hibernate etc, you can use this keyword, to enable reflective access for it. You can enable reflective access for

Using IDEA-EAP for JDK9 development experiments. I am getting the following error - Error:(3, 20) java: package jdk.internal.misc is not visible (package jdk.internal.misc is declared in module java.base, which does not export it to module com.jigsaw.npe) The class definition is as - package experiment; import jdk.internal.misc.Unsafe; public class CompareAndSwap { static Unsafe UNSAFE = Unsafe.getUnsafe(); ... } I've tried including a module-info.java file as well inside the module created using the IDE with the following statements - module com.jigsaw.npe { requires java.base; } Directory

What's the difference between requires and requires static module statements in module declaration? For example: module bar { requires java.compiler; requires static java.base; } A requires clause expresses that the required module is needed at compile and run time. Consequently, when the module system encounters such a clause during module resolution (the phase in which module descriptors are processed and dependencies are resolved) it searches the universe of observable modules (the modules in the JDK and on the module path) and throws an error if it doesn't find the module. A requires

What's the difference between requires and requires transitive module statements in module declaration? For example: module foo { requires java.base; requires transitive java.compiler; } Readability recap If module bar requires module drink , then the module system... enforces the presence of drink (called reliable configuration ) allows bar to read drink (called readability ) allows code in bar to access public classes in exported packages in drink (called accessibility ) Exactly the same happens if bar requires transitive drink - drink must be present, can be read and accessed. In fact, for

Suppose I have some library lib.jar for which I do not have the source code (or it is written in some non-Java language which is unaware of modules yet). lib.jar does not have module-info.class and I do not want to use it as an automatic module, so I would like to inject module-info.class into it. I first generate module-info.java with the following command: jdeps --generate-module-info . lib.jar Suppose this generated something like that: module lib { exports package1; exports package2; } Then I try to compile it but javac fails because the packages package1 and package2 do not exist: > javac

How can one get to know of the list of modules that have been resolved while the application has been started so as to figure out what all service providers are accessible from the root module. Module Resolution The module resolution is a two-step process. The first step recursively enumerates the 'requires' directives of a set of root modules. If all the enumerated modules are observable, then the second step computes their readability graph. The readability graph embodies how modules depend on each other, which in turn controls access across module boundaries. One can make use of the