is ClassLoader.loadClass() supposed to work on module-info classes?

Ali Ebrahimi ali.ebrahimi1781 at
Sat Dec 5 07:00:54 UTC 2015


On Sat, Dec 5, 2015 at 3:42 AM, Alex Buckley <alex.buckley at>

> On 12/4/2015 7:52 AM, David M. Lloyd wrote:
>> Yes, the tool is a Java compiler, piggybacking on the fact that a
> compiler already needs to figure out an observable universe of types to
> compile the source of a program against, and in the vast majority of Java
> programs, the "same" universe of types will be present at run time. By all
> means have the runtime system observe different versions of those types,
> but fundamentally the program's constant pool is explicit about the types
> it needs.
> That's slightly
>> tangential to the main idea here though, which is that an installation
>> of modules may well be necessarily (and reasonably) fluid, and that
>> fluidity extends to the descriptors of already-installed modules,
>> because the run time graph of modules is something that is
>> installation-dependent.  OSGi accommodates this by using packages to
>> link - basically punting the link decisions to the run time.
> The allusion to Import-Package means your end goal must be to link your
> program with a different version of package P today than the version your
> program linked with yesterday. Maybe the different version has debug info
> in the class files, or maybe the methods are mocks, or maybe an AOP tool
> has injected a bunch of logging calls. Great use cases.
> We accommodate this by bundling the descriptor externally to the
>> artifact so it can be easily updated by users and separately updated
>> by tools (without modifying artifacts).  But in any event, this
>> reality *has* to be accommodated in a robust module system.
> It seems like the different version of P has ended up in a
> differently-named JBoss module (or OSGi bundle) than yesterday.
> (Sidebar: Obviously, Jigsaw supports discovery of service providers at run
> time from modules not known at compile time, but I'm assuming you're not
> talking about that kind of intf-v-impl fluidity.)
> This seems like an opportunity for a build tool to manage "configurations"
> -- in the "debug" config, invoke javac -g P/*.java, bundle P into the
> FOO-debug module, and arrange for the consumer's module-info.class to say
> "requires FOO-debug" rather than "requires FOO".

I think David 's intention here is "requires implementation FOO.api".

With assuming:

module FOO.impl{
     implements FOO.api;

module FOO.impl2{
     implements FOO.api;

module FOO.debug{
     implements FOO.api;

module FOO.aop{
     implements FOO.api;

In other word, consumer module doesn't know any think about implementing
module since here we have contract and that is API module. think of today's
I think this would be much more powerful than service providers. So we have
api and implementation modules such that implementation modules can be
replaced without any change in consumer modules.


Best Regards,
Ali Ebrahimi

More information about the jigsaw-dev mailing list