[picocontainer-dev] JSR330 work progress
Paul Hammant <[email protected]> Fri, 23 Jul 2010 04:23:04 -0500
| Newsgroups | gmane.comp.java.picocontainer.devel |
|---|---|
| Message-ID | <[email protected]> |
--0015175d077e03aa06048c0a95d7
Content-Type: text/plain; charset=ISO-8859-1
Hi folks,
I'm working towards JSR330 compatibility in the Git Pico3 repo. There's a
TCK that comes with JSR330 so tracking progress is easy.
First up, I've had to add a mechanism to a) preserve type erasure and b)
allow lookup based on types. Looking at the PicoContainer API, you'll see
<T> T getComponent(TypeOf<T> componentType);
.. in addition to ..
<T> T getComponent(Class<T> componentType);
TypeOf is used rather than Type itself because one cannot do the following
in Java:
List<Color> colors = pico.getComponent(List<Color>.class);
Instead (and like Guice), we'll have to do:
List<Color> colors = pico.getComponent(new TypeOf<Color>(){}); // note
the anon inner class
TypeOf is doing a getGenericSuperclass() call to preserve the generics info.
I've to think more about references being held to TypeOf instances because
of the inner class consequences for garbage collection.
Internally, PicoContainer is moving towards using TypeOf as the general key
for items. Thus even 'old fashioned' Class keys are morphed into TypeOfs
via TypeOf.fromClass(Class c) calls.
- Paul
--0015175d077e03aa06048c0a95d7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi folks,<div><br></div><div>I'm working towards JSR330 compatibility i=
n the Git Pico3 repo. =A0There's a TCK that comes with JSR330 so tracki=
ng progress is easy.</div><div><br></div><div>First up, I've had to add=
a mechanism to a) preserve type erasure and b) allow lookup based on types=
. =A0Looking at the PicoContainer API, you'll see</div>
<div><br></div><div><div>=A0=A0 =A0<T> T getComponent(TypeOf<T>=
componentType);</div></div><div><br></div><div>.. in addition to ..</div><=
div><br></div><div><div>=A0=A0 =A0<T> T getComponent(Class<T> c=
omponentType);</div>
</div><div><br></div><div>TypeOf is used rather than Type itself because on=
e cannot do the following in Java:</div><div><br></div><div>=A0=A0 =A0 List=
<Color> colors =3D pico.getComponent(List<Color>.class);</div><=
div>
<br></div><div>Instead (and like Guice), we'll have to do:=A0</div><div=
><br></div><div><div>=A0=A0 =A0 List<Color> colors =3D pico.getCompon=
ent(new TypeOf<Color>(){}); // note the anon inner class</div></div><=
div><br>
</div><div>TypeOf is doing a=A0getGenericSuperclass() call to preserve the =
generics info. =A0I've to think more about references being held to Typ=
eOf instances because of the inner class consequences for garbage collectio=
n.</div>
<div><br></div><div>Internally, PicoContainer is moving towards using TypeO=
f as the general key for items. =A0Thus even 'old fashioned' Class =
keys are morphed into TypeOfs via TypeOf.fromClass(Class c) calls.=A0</div>
<div><br></div><div>- Paul</div>
--0015175d077e03aa06048c0a95d7--