Actually it is our belief that #2 does NOT in fact introduce unnecessary
instantiation of the instances, as the instance will not get created
until the "get" is performed where the original lookup occurred. Hence
this change should be every bit as lazy (in terms of instances) as in
the original code. It is for this very reason that we are not just
replacing these things with direct injections of the type itself, but
instead replacing it with a provider for the type.
On the other hand, if it is the early loading of the class due to the
inclusion of the type in the parameterized type, then you could be
correct in that the class will get loaded earlier than it was before.
In most of the cases I saw this was not an issue, since the class was
already being loaded early due to type parameters on methods or other
reasons. (Furthermore, technically the JVM is free to load classes used
in a class at any time, not just when it hits it in code, though I will
admit that most JVMs do not do greedy loads).
However, it is certainly the case that this should be done with care,
and if we come across cases where we think the early loading of the
class is an issue, we will definitely talk to the appropriate teams.
John Wells (Aziz)
john.wells_at_oracle.comNOSPAM
On 2/8/2012 4:01 AM, Sahoo wrote:
> I am concerned about #2 as it lookup is more dynamic than injection.
> Be careful while making #2, else we may cause some unnecessary loading.
>
> On Wednesday 08 February 2012 12:56 PM, Mahesh.Kannan_at_Oracle.Com wrote:
>> Hi All,
>>
>> The HK2 team (Tom Beerbower, John Wells, Mason Taube, Larry Feigen
>> & myself) went to asarch last week to
>> discuss about some of the changes to hk2 that we had been discussing
>> for a while. Some of the ideas were
>> initiated by Jerome & Jeff Trent.
>>
>> While the HK2 team is yet to present the full set of changes to
>> the asarch (which we will do so in about a couple
>> of weeks from now), it was agreed that, to start with, GlassFish
>> modules should move away from using non
>> standard Classes like Habitat and use standards based annotations
>> and classes as specified by jsr 330
>> (javax.inject.Inject, javax.inject.Provider etc.). To quote Jerome:
>> "Classes like Habitat exposes too many APIs
>> available to the users that makes the hk2 evolution very difficult.
>> " Also some of the APIs are unclear (when to
>> use habitat.getComponent() versus habitat.getByType()
>> /habitat.getByContract() ).
>>
>> So, the first step is to move away from Habitat (where ever
>> possible) and use jsr 330 interface and annotations.
>>
>> In order to do this, the hk2 team will be making the following
>> changes to the GlassFish modules.
>>
>> 1. Move away from org.jvnet.hk2.annotations.Inject to
>> javax.inject.Inject
>> 1.1 We will convert @org.jvnet.hk2.annotations.Inject Foo foo
>> to @javax.inject.Inject
>> Foo foo;
>> 1.2 We will convert
>> @org.jvnet.hk2.annotations.Inject(name="foo") Foo foo
>> to @javax.inject.Inject
>> @javax.inject.Named("foo")
>> Foo foo;
>> 1.3 We will convert
>> @org.jvnet.hk2.annotations.Inject(optional=true) Foo foo
>> to @javax.inject.Inject
>> @org.jvnet.hk2.annotations.Optional
>> Foo foo;
>> 1.3 We will convert
>> @org.jvnet.hk2.annotations.Inject(name="foo", option=true) Foo foo
>> to @javax.inject.Inject
>> @javax.inject.Named("foo")
>> @org.jvnet.hk2.annotations.Optional
>> Foo foo;
>>
>> 2. If we find that a class injects Habitat (or Services) and uses
>> habitat.getByContract(Foo.class) or
>> service.forContract(Foo.class).get(), then we will do the following:
>> 2.1 Introduce a new injection:
>> @javax.inject.Inject
>> javax.inject.Provider<Foo> fooProvider;
>> and 2.2 replace the getBycontract() / forContract() calls with:
>> fooProvider.get();
>>
>> 3. If we find that a class
>> a) implements PostConstruct,
>> b) injects Habitat (or Services) and
>> c) uses habitat.getByContract(Foo.class) or
>> services.forContract(Foo.class).get()*in the postConstruct
>> method, *then we will do the following:
>> 3.1 replace the getBycontract() / forConttract() calls with:
>> @javax.inject.Inject Foo foo;
>> 3.2 Obviously, we will talk to the module owner to find out
>> why the injection was not made in the first place.
>>
>>
>> Note: *The Hk2 team will be making the above changes and will reach
>> out to the module owners to find out what tests (dev tests, QL etc.)
>> need to be run before committing the changes.*
>>
>> Please let us know if you have any questions / concerns.
>>
>> Thanks
>> Hk2 team
>>
>