Module slots may be deprecated

Tuesday, 21 June 2016

Java 9 modules do not have a concept of a slot, and are identified only 
by name.  On the other hand, the module slot in JBoss Modules is 
essentially an extension of the name, and is used mainly as a helper to 
name parsing for things like the filesystem module loader to allow easy 
multi-version or parallel installation support.  A few projects use 
slots for other purposes.  In many module loaders, slots are not used at 
all and are allowed to default to "main".

Among the changes coming to JBoss Modules for Java 9, my current plan 
for this is to migrate towards the Java 9 way of doing things and 
support only a general name field.  For compatibility purposes, the 
ModuleIdentifier API will continue to function, until/unless it is clear 
that all major users have migrated off of it.  It will work as a 
frontend to plain String names - a ModuleIdentifier with name "name" and 
slot "slot" will be translated behind the scenes as a module named 
"name:slot".  A module with a slot of "main" will be translated as
just 
"name".  A simple character escaping scheme will be employed to ensure 
that there is a lossless two-way mapping from plain names to 
ModuleIdentifier-style names, in the event that there is a ':' in the 
name part of the ModuleIdentifier, though in practice this may not come 
up much.

The existing module loaders can continue to function more or less as 
they are.  For filesystem modules using module.xml, the slot could still 
be used by way of the compatibility syntax scheme above.  The filesystem 
module loader will continue to use the same file name mapping scheme for 
now, using the aforementioned compatibility scheme to achieve the same 
effect that slots do now; we can look at ways to transition off of that 
later if it proves necessary to do so.

The deployment module loader in WildFly can be transitioned to using 
plain names easily, and this can probably be done at any time.  We can 
keep WildFly management APIs which reference modules as they are for now 
- if a slot is present, it could simply be appended to the given module 
name after a dividing ":", otherwise the module name is used as-is.  The 
slot attributes could be deprecated at any time.

Overall though I think the best way of approaching the change is that we 
start thinking of "name:slot" as merely a ModuleLoader-specific name 
syntax policy that some loaders use, and some do not.  I suspect that 
some module loaders will actively benefit from not having to deal with 
the annoying possibility that a slot will be present and will not be the 
expected "main" value; having a simple unrestricted String name allows 
each ModuleLoader to have complete control over their syntax policy, 
which is something that JBoss Modules has been moving towards for some 
time now.

Ultimately slots are a pretty limited tool and are already essentially a 
facade over a plain name, with a very thin convenience class over the 
top of it to implement a parsing policy.  While many people have taken 
advantage of slots in many ways, it is my view that moving this 
logic/policy into each module loader will afford more flexibility than 
does simply dividing names into two fields.  The ModuleIdentifier class 
could be preserved as a convenience, though I would not recommend its 
use (hence deprecation), especially as it may map awkwardly into things 
like Java 9 module-aware stack traces.  However this is something that 
can be discussed before any decision is reached.

The estimated time frame for these changes relates to the time frame and 
progress of Java 9, so it is not clear at the moment exactly when this 
must happen, but it is certain that the changes will definitely not 
occur before WildFly 12.  Hopefully this will give everyone enough time 
to recover from the shock. :-)

Discussion!
-- 
- DML

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013