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
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev