Hi,
On Sat, Dec 5, 2015 at 3:42 AM, Alex Buckley <alex.buck...@oracle.com>
wrote:
> 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
interface.
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
