[wildfly-dev] Module slots may be deprecated

[Bob McWhirter]

This is horrible! Horrible I say.

Actually, no, we’re cool.

Thanks for the heads-up.

-Bob

On Tue, Jun 21, 2016 at 4:39 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160621/f439575d/attachment.html