Igor Vaynberg wrote:
well, apparently johan ran into a situation where component<?> is too restrictive...
As I understand it, Johan ran into a situation where Component<?> causes *warnings* for users who use raw types. Which I've been arguing all along that they SHOULD get: they should use Component<Object> or Component<Void> instead of raw types, or live-with/suppress the warning.
To make it clear, I made the following test class:
public class Test<T> {
public void doTest(Test<? extends Test<?>> test) {
System.out.println("test");
}
public static void main(String[] args) {
Test<Test<Integer>> test1 = newInstance(); // fine - no
warnings.
Test<Test> test2 = newInstance(); // not fine, use of raw type,
warning
Test test3 = newInstance(); // not fine, use of raw type,
warning
test1.doTest(test1); // fine - no warnings.
test1.doTest(test2); // error - generic types don't match, can be
"fixed" by line below
test1.doTest((Test) test2); // warning - unchecked conversion
test1.doTest(test3); // warning - unchecked conversion
}
public static <T> Test<T> newInstance() {
return new Test<T>();
}
}
As you can see, there is only one case when you get a compile error when
using the <? extends Test<?>> generic type, and that is a case where
there is on the user side an incorrect generic type: Test<Test>. The
user here declares he's using generics, but then inserts a raw type of a
known generic type - a situation that should not happen.
Regards, Sebastiaan
-igor On Wed, May 14, 2008 at 2:37 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:Igor Vaynberg wrote:since then the thread has evolved into whether or not we should use <? extends Component> or <? extends Component<?>> -igorI don't understand how that changes any of my points. The first is incorrect (from a generics point of view) since you're referencing an unparameterized generic type. So the second gives warnings only in code that is not properly generified... Regards, SebastiaanOn Wed, May 14, 2008 at 1:54 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:Igor Vaynberg wrote:i do like generics. did i ever say otherwise? the problem here is that if we scope something as Class<? extends Component> then even though you ARE using generics in your code you will still get a warning because we did not scope the class as Class<? extends Component<?>>. on the other hand if we do scope it as Class<? extends Component<?>> then you can no longer pass a raw reference when calling the function.But that's exactly the point isn't it? If you're using generics then you shouldn't be using raw Components anymore...so we are screwed if we do and we are screwed if we dont, i expected generics to be better.Well they definitely could have been better (erasure is terrible if you ask me), but I don't see what's wrong in this case. It warns you if you should be using a parameterized type but you don't.And especially if you look at the vote result, I think the majority wants the generics...that vote was before we uncovered this issue. we voted on the idea of generics, not on the implementation.That's true, but I wonder if this issue would change the vote much. I don't really understand why it's an issue, because you can use generified Components always: Component<Object> if you don't want to constrain the model object, and Component<Void> if you don't need a model. The question that started the thread was about StringResourceModel which was not yet generified, and in that case, the warning seems to me to be perfectly ok: it just says StringResourceModel should be generified. It's not a release yet, so that some users who use the current snapshot run into these kind of warnings which cannot be removed seems to be fine to me... Regards, Sebastiaan--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
