Mark Reinhold
http://openjdk.java.net/projects/jigsaw/spec/issues/2016-03-23http://openjdk.java.net/projects/jigsaw/spec/issues/jpms-spec-comments@openjdk.java.net This is the issue list for JSR 376, the Java
Platform Module System. The issues documented here have been collected
from the JSR 376 Expert Group mailing list, the JSR
376 comments list, the JSR 376 observers’
list, and the OpenJDK jigsaw-dev
list. References to pertinent messages, though not all
related messages, are included.
This is a living document, which will be updated regularly as work on these issues progresses. Each issue is assigned a unique #HashTag for use in the e-mail messages and other textual media in which these issues are discussed so that such discussions can be discovered, tracked, and summarized.
#ModuleNameSyntax · #ModuleNameCharacters · #CompileTimeDependences · #ModuleAnnotations · #ModuleDeprecation · #ExportAnnotation
#CyclicDependences · #MutableConfigurations · #LazyConfigurationAndInstantiation · #CustomizableAutomaticModuleNameMapping
#ClassFilesAsResources · #ResourceEncapsulation · #ResourceExistenceAndSize · #ReflectiveAccessToNonExportedTypes · #ReflectionWithoutReadability
#ModuleNameSyntax — Some people find the use of the same syntax
for module names and package names to be confusing. Should the
recommended syntax for module names be changed to something else,
e.g., lower-case words separated by underscores? Or should the
syntax of module declarations be revised to expand requires into
requires module, and exports into exports package, in order to
disambiguate these two kinds of names? Or is there some other
solution? [Rémi
Forax, Stephen
Colebourne, Paul
Benedict]
#ModuleNameCharacters — Module names are presently constrained to be Java identifiers. Some existing module systems allow additional characters in module names, such as hyphens and slashes. Should this restriction be lifted or, perhaps, should it somehow be made layer-specific? [David Lloyd]
#CompileTimeDependences — Provide a means to specify a module dependence that is mandatory at compile time but optional at run time, for use with libraries that are not strictly necessary but can be leveraged if present at run time. (Detail: If a dependence is “optional at run time” then does the module system try to satisfy it during resolution but fail silently if it cannot, or does it ignore it during resolution but add the corresponding read edge to that module if it was resolved for some other reason?) [Philippe Marschall, Stephen Colebourne, Juergen Hoeller, Stephane Epardaud, Paul Benedict]
#ModuleAnnotations — Should it be possible to annotate module declarations? As previously discussed this is technically feasible but it would add significant complexity. [Peter Kriens, Stephane Epardaud, Paul Benedict]
#ModuleDeprecation — If module declarations cannot be annotated, should there be some other way to deprecate modules? [Rémi Forax]
#ExportAnnotation — Define a standard, source-retention Export
annotation which can be used in a package-info.java file to
indicate that the package is to be exported. Tools that create
module-info.java files could then interpret this annotation in
order to generate corresponding exports clauses. [Paul
Benedict]
#MultiModuleExecutableJARs — Provide a means to create an executable modular “uber-JAR” that contains more than one module, preserving module identities and boundaries, so that an entire application can be shipped as a single artifact. [This issue has not come up in e-mail but was raised multiple times in person at JavaOne 2015, Devoxx BE 2015, and FOSDEM 2016.]
#MultiModuleJARs — Provide a means to package more than one module in a single artifact, while preserving module identities and boundaries. (This is a generalization of #MultiModuleExecutableJARs.) [Stefan Fuchs]
#ReifiedModuleGraphs — Define a means to record, in some type of artifact, the module graph that results from resolving a given main module against a given application module path. The artifact could contain full copies of the corresponding module artifacts, or references to such artifacts, or some combination of the two. At run time such an artifact could be used to create a new layer. [Peter Kriens]
#ModuleNameInManifest — For ease of migration, consider allowing
the name of a module to be specified in the MANIFEST.MF file of a
JAR file. If a JAR file with such a manifest entry is not a modular
JAR (i.e., it has no module-info.class file), but is used as an
automatic module, then the name of the automatic module is that
specified in the manifest rather than that derived from the name of
the JAR file itself. This would allow the maintainer of an existing
library to specify a preferred module names simply by updating the
library’s manifest. If a JAR file with such a manifest entry is a
modular JAR then the module name in the module-info.class file
determines the module name, and the name in the manifest is expected
to match. In both cases, the presence of the module name in the
manifest is useful to tools that must run on older versions of the
platform, since they can use the existing java.util.jar API to read
the module name. [Paul
Benedict]
#CyclicDependences — The current draft disallows cycles when the module graph is initially resolved at compile time, link time, and run time. Cycles can arise later on at run time if readability edges are added for automatic modules, or via reflection. The rationale for disallowing cycles during resolution is that it makes the module graph easier to reason about, it simplifies the module system itself, and that, philosophically, any modules involved in a cycle are logically one module anyway, so they should be defined as such in the first place. This constraint is not, however, a documented requirement, and some have argued that cycles should be permitted. [Jochen Theodorou, Stephane Epardaud]
#MutableConfigurations — Configurations are immutable: Once created, they cannot be modified. Some have argued that this will make it impossible for container applications to add and remove modules at run time. Should configurations, and hence the aspects of layers that depend upon configurations, be made mutable instead? [David Lloyd]
#LazyConfigurationAndInstantiation — The construction of a configuration loads all of the relevant module descriptors, and the instantiation of a configuration into a layer defines all of its modules to the virtual machine. There is some concern that this could result in significant startup overhead for layers with thousands or tens of thousands of modules, which some consider to be realistic scenarios. If the startup overhead is actually that bad in such settings, should configuration and layer creation be revised to use incremental algorithms? [David Lloyd]
#CustomizableAutomaticModuleNameMapping — Provide a means to customize the algorithm that computes the names and version strings of automatic modules. [Paul Benedict]
#ClassFilesAsResources — If a type is visible and was loaded
from a class file then it should be possible to read that file by
invoking the getResourceAsStream method of the type’s class loader,
as it is in earlier releases. [Uwe
Schindler, Rafael
Winterhalter]
#ResourceEncapsulation — The Module::getResourceAsStream
method can be used to read the resources of any named module, without
restriction, which violates the resource encapsulation
requirement. This method should be restricted somehow so that
only “suitably-privileged” code (for some definition of that term)
can access resources in a named module other than its own. An
alternative is to drop this requirement
(cf. #ClassFilesAsResources). [Mark
Reinhold]
#ResourceExistenceAndSize — Given a Module object and a
resource name, should there be a way to determine whether that
resource exists in that module and, if it does exist, what its size
is, without actually opening the resource as a stream? One way to do
this would be to introduce a new abstraction to represent resources.
[David Lloyd]
#ReflectiveAccessToNonExportedTypes — Some kinds of framework libraries require reflective access to members of the non-exported types of other modules; examples include dependency injection (Guice), persistence (JPA), debugging tools, code-automation tools, and serialization (XStream). In some cases the particular library to be used is not known until run time (e.g., Hibernate and EclipseLink both implement JPA). This capability is also sometimes used to work around bugs in unchangeable code. Access to non-exported packages can, at present, only be done via command-line flags, which is extremely awkward. Provide an easier way for reflective code to access such non-exported types. [Reinier Zwitserloot, Paul Benedict, Alan Snyder, Rémi Forax, Simon Nash]
#ReflectionWithoutReadability — Having to add read edges dynamically just to enable reflection is painful, and could slow migration and adoption. Consider relaxing the access model so that reflection does not require, or perhaps simply assumes, readability. [Rémi Forax, Peter Levart]
Resolution: Adopt the second suggested alternative. Revise the core
reflection APIs in the java.lang.reflect package to assume that any
module that contains code that invokes a reflective operation can read
the module that defines the types that are the subject of that operation.
[Mark Reinhold]
#AvoidConcealedPackageConflicts — Provide a simple means to load two modules, without using reflection, when they contain non-exported packages of the same name. This could be done by loading them via different class loaders or, alternatively, via #StaticLayerConfiguration. [Karl Sanders]
#PlatformClassLoader — Add a static method to
java.lang.ClassLoader to return a class loader via which all of the
built-in Java SE and JDK types are visible. (This is, at present,
the loader formerly known as the “extension” class loader.) [Alan
Snyder]
#StaticLayerConfiguration — Layers can, at present, only be created dynamically, via reflection. If there were a way to specify them statically, i.e., at startup time, then they could be used to solve the kinds of version conflicts that are presently addressed via shading or shadowing. [Ron Pressler, Nicolai Parlog]
#MultipleModuleVersions — Allow multiple distinct modules of a given name to be loaded in a convenient fashion, without using reflection. This could be done by creating new layers automatically, or by relaxing the constraints on multiple versions within a layer, or by some other means (cf. #StaticLayerConfiguration, #AvoidConcealedPackageConflicts). Addressing this issue may entail reconsidering the multiple versions non-requirement. [Mike Hearn]
#VersionsInModuleNames — Some have argued that library maintainers will be tempted to encode major version numbers, or even full version numbers, in module names. Is there some way we can guide people away from doing that? [Mike Hearn, Paul Benedict]
#VersionedDependences — Consider allowing specific version
strings, or perhaps version constraints, as an optional element of
requires clauses in module declarations. Failing that, consider
allowing specific version strings, or perhaps version constraints, to
be added to the dependences recorded in a compiled module descriptor;
this would, e.g., allow a compiler or build system to record the
versions of the modules against which a particular module was
compiled, for use by other tools. In either case, if such version
information is merely informative then it will still honor the
version selection non-requirement; if such version
information is interpreted by the module system then that requirement
may come into question. [Cristiano
Mariano, Stephane
Epardaud]
#VersionSyntax — Revise the syntax of module version strings to accommodate a wider variety of existing version-string schemes. [David Lloyd]
#BootstrapClassLoaderSearchInJVMTI — The JVM TI API
defines a function, AddToBootstrapClassLoaderSearch, by
which an instrumentation agent can append a file-system path element
to the bootstrap class loader’s class path. The bootstrap class
path, as such, no longer exists, but this function remains supported
for now. Should this function be deprecated, with the intent to
remove it in a future release, or should it remain supported? It
appears to be critical to the operation of at least one popular
instrumentation agent. [Andrew
Dinn]
#ReflectiveAccessByInstrumentationAgents — As noted in the related issue #ReflectiveAccessToNonExportedTypes, the core reflection API cannot be used to gain access to members of packages that are not exported by their defining modules. Even if that issue is addressed for the use cases cited, a distinct use case is that of instrumentation agents that need to enable injected code to invoke non-public methods and access non-public fields. A possible solution for this use case is specifically to provide instrumentation agents with the ability to use core reflection, or some equivalent, even on elements of non-exported packages. [Andrew Dinn]