We should make every jar produced by us (including this universal jar) a
module. As Jerome mentioned, making it a module not only leads to
efficient class loading in HK2 environment, it is sometimes needed to
avoid ClassCastException in a modular environment. AFAIK, every jar can
be packaged as a HK2 module irrespective of whether it depends on HK2
module system or not. There is *no* side effect. If it really does not
depend on HK2 module system, then it won't have any static dependencies
on HK2 APIs, but it will only have some HK2 manifest entries. When such
a jar is used in a non-HK2 environment, the HK2 specific manifest
entries are simply ignored by the runtime and it is used as a "Plain Old
Jar." You can use the jar file in javac classpath without any issues.
When it is indeed used in HK2 environment, HK2 module system would treat
it as a module.
So, why not turn universal.jar into a HK2 module? You don't have to do
it, as I am taking care of such things in my workspace - all I need is
an agreement from you.
Thanks,
Sahoo
Jerome Dochez wrote:
> In general, a module will be shared by all its user's while a plain
> old jar file will be loaded by all the importing modules classloaders
> with no sharing. This can be inefficient but can also obviously lead
> to ClassCastException if you end up passing around instances.
>
> My advice on this matter is to have everything packaged as a module
> even if it does not use HK2 services. That does not apply to jars
> which need to be used in different executable environment that do not
> rely on a modular subsystem. That's the case of universal so we could
> leave it as jar if it is not used in multiple modules in the appserver.
>
> Another way to fix that that problem is to leave code in a plain old
> jar like grizzly (grizzly.jar) and have a module definition that wraps
> the grizzly jar and its jar dependencies in a module. That's what we
> do in grizzly-module for instance. That way, when using grizzly on non
> modular env, you use the jar, when using a modular subsystem, you use
> the grizzly module.
>
> Jerome
>
> On Mar 14, 2008, at 12:43 PM, Kedar Mhaswade wrote:
>
>> Sahoo wrote:
>>> What stops a HK2 module jar from being used in a non-HK2 environment?
>>> Thanks,
>>> Sahoo
>>
>> Sahoo,
>>
>> I think the basic question is if I delivering some utility code that
>> - does not use HK-2 facilities, annotations etc.
>> - provides simple API and implementation to do something,
>>
>> what is the best way to "package" it -- as a "jar" or "hk2-jar"?
>>
>> For such a module, what additional benefits would you get by
>> packaging it as an hk2-jar?
>>
>> Regards,
>> Kedar
>>
>>> Byron Nevins wrote:
>>>> Yes.
>>>> So that it can be used by non-hk2 clients as well as hk2-modules.
>>>>
>>>>
>>>> Sahoo wrote:
>>>>> Byron,
>>>>>
>>>>> Have you authored org.glassfish.common:universal module? Why is it
>>>>> not a HK2 module?
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>