I think that is only part of the problem in this instance. The other
part of the problem is that Base.class presents only runtime
information. There is no way to invoke Base.<Void>class to get
Class<Base<Void>> in a manner similar to how you can invoke a generic
method. The type represented in the <> returned by a class literal is
not generic since this information is not present at runtime. Derived
does not have this problem since it is not generic.

I am not completely sure why this plays out the way it does with the
given method signatures, but I have an idea. Derived provides the
reifiable (completely preserved at runtime) type of Void in place of T.
So when the method bad is called with Derived, ? can be inferred to be
of type Void. This is not possible with the generic type Base since T is
not reifiable and not provided by the literal Base.class. The compiler
cannot infer what ? should be. Providing <X extends Base<?>> for the
method good circumvents this conundrum. 

Looking at the messages this produces in Eclipse:

        bad(Derived.class) displays on hover:
                "void Test.bad(Class<? extends Base<?>> clazz)"

        bad(Base.class) displays the error:
                "The method bad(Class<? extends Base<?>>) in the 
                type Test is not applicable for the  arguments 
                (Class<Base>)"

        good(Derived.class) displays on hover
                <Derived> void Test.good(Class<Derived> clazz)

        good(Base.class) displays on hover
                <Base> void Test.good(Class<Base> clazz)

So in the last instance the compiler infers Base for X since Base.class
returns Class<Base> and is happy. Changing 

        good(Class<X> clazz)
to
        good(Class<? extends X> clazz)

Should preserve the original intention of bad(Class<? extends Base<?>>
clazz). It is instructive that if you put bad(clazz) as the body of the
method good, everything compiles and runs just fine.

Sorry for the verbosity of this message. I just really wanted to try to
understand this problem and thought that some of you might be interested
in any ideas about it. I have been using the O'Reilly book "Java
Generics and Collections" as a guide through the murky depths of
generics and it has been most helpful.

-----Original Message-----
From: Peter Ertl [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 21, 2008 5:04 AM
To: users@wicket.apache.org
Subject: Re: (Class<? extends Page<?>>) casting troubles

I suspect the multiple wildcards (?) in one type expression causing  
all that trouble.

probably an issue of the compiler and not of the language spec.

public class Test
{
   public static void main(String[] args)
   {
     bad(Derived.class); // ok
     bad(Base.class); // compile error
     good(Derived.class); // ok
     good(Base.class); // ok
   }

   public static void bad(Class<? extends Base<?>> clazz)
   { //                          ^^ two wildcards in one expression:
     //                             uh oh, calling for trouble!
   }

   public static <X extends Base<?>> void good(Class<X> clazz)
   {
     //
   }

   public static class Base<T>
   {
   }

   public static class Derived extends Base<Void>
   {
   }
}








Am 21.05.2008 um 10:38 schrieb Gerolf Seitz:

> On Wed, May 21, 2008 at 10:30 AM, Johan Compagner
<[EMAIL PROTECTED] 
> >
> wrote:
>
>> always strange that that works
>> If you just look at it then it seems to be the same thing :)
>>
>
> tbh, i would still like to get an explanation _why_ it works with
> <S extends Component<?>> and not directly with <? extends Component<? 
> >>.
>
>  Gerolf

______________

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_____________

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to