<div dir="ltr">This is horrible! Horrible I say.<div><br></div><div>Actually, no, we’re cool.</div><div><br></div><div>Thanks for the heads-up.</div><div><br></div><div>-Bob</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 21, 2016 at 4:39 PM, David M. Lloyd <span dir="ltr"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Java 9 modules do not have a concept of a slot, and are identified only<br>
by name. On the other hand, the module slot in JBoss Modules is<br>
essentially an extension of the name, and is used mainly as a helper to<br>
name parsing for things like the filesystem module loader to allow easy<br>
multi-version or parallel installation support. A few projects use<br>
slots for other purposes. In many module loaders, slots are not used at<br>
all and are allowed to default to "main".<br>
<br>
Among the changes coming to JBoss Modules for Java 9, my current plan<br>
for this is to migrate towards the Java 9 way of doing things and<br>
support only a general name field. For compatibility purposes, the<br>
ModuleIdentifier API will continue to function, until/unless it is clear<br>
that all major users have migrated off of it. It will work as a<br>
frontend to plain String names - a ModuleIdentifier with name "name" and<br>
slot "slot" will be translated behind the scenes as a module named<br>
"name:slot". A module with a slot of "main" will be translated as just<br>
"name". A simple character escaping scheme will be employed to ensure<br>
that there is a lossless two-way mapping from plain names to<br>
ModuleIdentifier-style names, in the event that there is a ':' in the<br>
name part of the ModuleIdentifier, though in practice this may not come<br>
up much.<br>
<br>
The existing module loaders can continue to function more or less as<br>
they are. For filesystem modules using module.xml, the slot could still<br>
be used by way of the compatibility syntax scheme above. The filesystem<br>
module loader will continue to use the same file name mapping scheme for<br>
now, using the aforementioned compatibility scheme to achieve the same<br>
effect that slots do now; we can look at ways to transition off of that<br>
later if it proves necessary to do so.<br>
<br>
The deployment module loader in WildFly can be transitioned to using<br>
plain names easily, and this can probably be done at any time. We can<br>
keep WildFly management APIs which reference modules as they are for now<br>
- if a slot is present, it could simply be appended to the given module<br>
name after a dividing ":", otherwise the module name is used as-is. The<br>
slot attributes could be deprecated at any time.<br>
<br>
Overall though I think the best way of approaching the change is that we<br>
start thinking of "name:slot" as merely a ModuleLoader-specific name<br>
syntax policy that some loaders use, and some do not. I suspect that<br>
some module loaders will actively benefit from not having to deal with<br>
the annoying possibility that a slot will be present and will not be the<br>
expected "main" value; having a simple unrestricted String name allows<br>
each ModuleLoader to have complete control over their syntax policy,<br>
which is something that JBoss Modules has been moving towards for some<br>
time now.<br>
<br>
Ultimately slots are a pretty limited tool and are already essentially a<br>
facade over a plain name, with a very thin convenience class over the<br>
top of it to implement a parsing policy. While many people have taken<br>
advantage of slots in many ways, it is my view that moving this<br>
logic/policy into each module loader will afford more flexibility than<br>
does simply dividing names into two fields. The ModuleIdentifier class<br>
could be preserved as a convenience, though I would not recommend its<br>
use (hence deprecation), especially as it may map awkwardly into things<br>
like Java 9 module-aware stack traces. However this is something that<br>
can be discussed before any decision is reached.<br>
<br>
The estimated time frame for these changes relates to the time frame and<br>
progress of Java 9, so it is not clear at the moment exactly when this<br>
must happen, but it is certain that the changes will definitely not<br>
occur before WildFly 12. Hopefully this will give everyone enough time<br>
to recover from the shock. :-)<br>
<br>
Discussion!<br>
<span class="HOEnZb"><font color="#888888">--<br>
- DML<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</font></span></blockquote></div><br></div>