limitations of generic reflection

Thread view:

Roger Levy - 16 Apr 2008 17:58 GMT

I think I have hit up against an interesting limitation of generics in
Java, and I want to confirm that I'm understanding the limitations
properly. I would like to write a method that takes a parameterized
Collection of type C<A>, and apply to each member of the Collection a
method that takes an A and returns a B. The result should be a
Collection of type C. The code would ideally look something like:

public <A, B, C extends Collection> C applyAll(C<A> as,
Function<A,B> f) {
C result = (C) as.getClass().newInstance();
for(A a : as)
result.add(f.apply(a));
return result;
}

with the appropriate exception handling. But it seems like this is
impossible because type parameters themselves cannot be
parameterized. Is there a way around this limitation that I haven't
thought of?

Many thanks!

Roger

Reply to this Message

Owen Jacobson - 16 Apr 2008 18:08 GMT

> I think I have hit up against an interesting limitation of generics in
> Java, and I want to confirm that I'm understanding the limitations
[quoted text clipped - 15 lines]
> parameterized. Is there a way around this limitation that I haven't
> thought of?

You can parameterize type bounds:

public static
<A, B,
CA extends Collection<A>,
CB extends Collection>
CB apply(
CA as, Function<A, B> f) {

}

however, once you're past that hurdle, you're going to discover that
you can't, eg., do 'new CB', which you'd need for a truly generic
implementation of the map meta-function, nor can you specialize
generics on some arguments the way you could with C++ templates.

-o

Reply to this Message

lscharen@d.umn.edu - 16 Apr 2008 19:00 GMT

> > I think I have hit up against an interesting limitation of generics in
> > Java, and I want to confirm that I'm understanding the limitations
[quoted text clipped - 31 lines]
> implementation of the map meta-function, nor can you specialize
> generics on some arguments the way you could with C++ templates.

This may be a redundant post, but I've found that making the meta-
function evaluation lazy allow you to "code around" the issue somewhat
elegantly.

Assume that your applyAll() returns an Iterable object and computes
f.apply() on demand. In order to get a collection of type C, you
have to do a bit more work by creating an addAll() method. The
framework looks like this (I may be off on exact syntax of the
wildcard bounds, I hope the intention is clear):

public static <A, B> Iterable applyAll( Collection<? extends A> as,
Function<A, B> f ) { // lazy implementation... }

public static <A> void addAll( Collection<? super A> c, Iterable<?
extends A> iterable )
{
for ( A a : iterable )
c.add( a );
}

In your code you might do the following. Assume Set<A> and List<A>
are populated with values.

Function<A, B> myFunc = new MyFunc();
Set<A> sa;
Set sb;
List<A> la;
List lb;

addAll( lb, applyAll( la, myFunc ));
addAll( sb, applyAll( sa, myFunc ));

Like I said, not quite as elegant as one might like, but serviceable.
You might be able to pretty it up some more using the parameterized
type bounds.

Reply to this Message

Roger Levy - 19 Apr 2008 19:37 GMT

On Apr 16, 11:00 am, lscha...@d.umn.edu wrote:

> > > I think I have hit up against an interesting limitation of generics in
> > > Java, and I want to confirm that I'm understanding the limitations
[quoted text clipped - 68 lines]
> You might be able to pretty it up some more using the parameterized
> type bounds.

Hmm, this is an interesting idea, though it doesn't really get what
I'd like to have ideally. Oh well...

Reply to this Message

Roger Levy - 19 Apr 2008 19:37 GMT

Yeah, I did know about this -- thanks!

Reply to this Message

limitations of generic reflection

Free Magazines