JDK-8049692 : Re-examine upgradeable modules
  • Type: Task
  • Component: core-libs
  • Sub-Component: java.lang.module
  • Priority: P2
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2014-07-09
  • Updated: 2016-05-27
  • Resolved: 2016-05-18
Related Reports
Blocks :  
Relates :  
Relates :  
Description
This task is for tracking purposes.

From the Project Jigsaw: Goals & Requirements document:

"Upgradeable modules ��� If a JDK module implements an endorsed standard or standalone technology then it must be possible to use a version of that module from a later release in any phase, i.e., at compile time, build time, or run time."

This task need to be fleshed out further and sub-tasks created for the specific areas. For example, we need to identify the Java SE modules that are allowed to be overridden, we need both javac and the runtime to support, we need to see how this relates to dynamic configuration (although this already works in our prototypes builds by way of the "before finder").

For now we assume that this feature is separate to -Xoverride (the module replacement to -Xbootclasspath/a) as this option is about replacing classes in existing modules. 
Comments
I don't think there is any further work to do here. JDK-8133882 tracks aligning javac with runtime.
18-05-2016

As of now, we have: 1. Upgrade module support in both javac and the runtime. 2. The EE modules are upgradeable, as are the deploy modules (as part of the solution for the JDK N-3 issue). 3. At build time, hashes are generated for the packaged version of all the standard and JDK modules, except the upgradeable modules (#2), and stored in java.base. This makes it possible to deploy newer versions of the EE modules on the upgrade module path without falling foul of integrity checks. The hashes are checked at both link time and runtime. 4. If a custom runtime image is created that does not have all standard or JDK modules then it possible to deploy the EE modules on the upgrade module path but not other standard / JDK modules. This is because module java.base has the hashes and java.base is in all runtime images. 5. It is possible to put user modules on the upgrade module path - it is equivalent to prepending to the application module path.
13-05-2016

The remaining/open issues aren't critical for the initial push of the module system to JDK 9 so I think we can move this one to the bill list.
24-06-2015

In JDK 8, the runtime supports -Xbootclasspath -Xbootclasspath/p: -Xbootclasspath/a: We should consider whether we need replacements for each of these, and if not, why not. Note that javac also supports these options w.r.t. the compilation environment, so ideally we need to come up with a spec for replacement options that works consistently for both javac and the runtime.
10-07-2014