This is my take on it: http://www.nabble.com/RE%3A-%28Class%3C--extends-Page%3C-%3E%3E%29-casti ng-troubles-p17370699.html
I feel it covers the topic pretty thoroughly but I am by no means an expert on the matter. -----Original Message----- From: Martin Funk [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2008 8:14 AM To: users@wicket.apache.org Subject: Re: (Class<? extends Page<?>>) casting troubles Hi Peter, 2008/6/4 Peter Ertl <[EMAIL PROTECTED]>: > I remember that having more than one wildcard in an type expression seems > to be inherently broken. I hope it is not, I hope it is just hard to understand. > > Usually you can rewrite something like > > void foo(Class<? extends Page<?>> pageClass) I think both signatures are not semanticall equal. Here there are two wildcards. On one hand wildcards are by definition independent from each other, but on the other hand there are coupled in this example, by the extends. Maybe in java it was decided that the independance is more important than the coupling. As I read the signature the type parameter might be of any type as long as it extends Page parametrized with any other type. Now when the method is used one parameter is given. foo(Bar.class) If Bar is a non-generic subtype of Page the compiler is happy. Either cause the type paramter of Page is well defined by the declaration of Bar or the compiler just forgets about them type parameters in an non-generic case (I don't know). If Bar is a generic subtype than Bar.class is its raw type which is a subtype of the raw type of Page, but nothing else. So the compiler is not happy. > > into something like > > <X extends Page<?>> void foo(Class<X> pageClass) Having the wildcard in the generic type definition of the method it relaxes the Bounds. Here the compiler just has to make sure that X extends a parametrized Page which every subtype of Page does. @All Is there anyone out there having a better explanation? Currently I'm working my way through the generics FAQ by Angelika Langer http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html I see quite some statements there that apply here, but I still can't grab the whole picture. > > I would bet this solves your problem :-) > > However, nobody can explain why... :-( > > Probably some lack of the generics specification, broken compiler, or > whatever... > > I would suggest to avoid more than one wildcard in one type expression in > general and use above workaround. I'm not sure about the analysis but still a good guideline. mf > > Cheers > Peter > > > Am 04.06.2008 um 10:10 schrieb Johan Compagner: > > > Yeah it is very strange that you get different errors in eclipse and >> javac. >> I wonder which one is correcct.. >> >> But you have to generify the Page then it should work fine (like <Void>) >> >> I think we just need to drop the <?> in that example >> What do you exactly call? >> >> >> johan >> >> >> On Wed, Jun 4, 2008 at 9:39 AM, Rod Good <[EMAIL PROTECTED]> wrote: >> >> Hi, >>> >>> I'm getting inconvertible type errors when I compile from Maven on the >>> command line with Java 6. >>> >>> Does anyone know if this issue was resolved ? I am building against >>> 1.4-m2 - downloaded today (04-06-2008). >>> >>> The issue is the same as noted by Ryan Mckinley on 05/21/2008 : >>> >>> >>>> strangely, things work fine for me in eclipse, but from the command >>>> >>> line, I still get: >>> >>>> >>>> $ mvn clean install: >>>> >>>> >>>> /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/website/ >>> wicket/page/DownloadingPage.java:[18,97] inconvertible types found : >>> java.lang.Class<dexter.website.wicket.page.account.DexSignInPage> >>> required: java.lang.Class<? extends org.apache.wicket.Page<?>> >>> >>>> >>>> I ran: mvn clean install in the wicket directory... >>>> >>>> Not sure if the java version is helpful: ryan$ mvn -version Maven >>>> >>> version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp >>> >>> Thanks, >>> Rod. >>> >>> NOTICE >>> This e-mail and any attachments are confidential and may contain >>> copyright >>> material of Macquarie Group Limited or third parties. If you are not the >>> intended recipient of this email you should not read, print, re-transmit, >>> store or act in reliance on this e-mail or any attachments, and should >>> destroy all copies of them. Macquarie Group Limited does not guarantee >>> the >>> integrity of any emails or any attached files. The views or opinions >>> expressed are the author's own and may not reflect the views or opinions >>> of >>> Macquarie Group Limited. >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ______________ 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]
