taken from SUN's generic tutorial:

http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
end of page 8

:::: snip :::

interface Collection<E>
{
public boolean containsAll(Collection<?> c);
public boolean addAll(Collection<? extends E> c);
}
We could have used generic methods here instead:
interface Collection<E>
{
public <T> boolean containsAll(Collection<T> c);
public <T extends E> boolean addAll(Collection<T> c);
// hey, type variables can have bounds too!
}
:::: snip :::

isn't addAll() that the same as

 public void foo(Class< ? extends Component< ? >> clazz);

and

 public <X extends Component<?>> void foo(Class<X> clazz);

???

seems like this is our first generic bug :-)




Am 15.05.2008 um 16:41 schrieb Peter Ertl:

this one will do:

   public <X extends Component<?>> void foo(Class<X> clazz);

however, the subtle differences between this and igors version are really hard to get.



Am 15.05.2008 um 16:31 schrieb Igor Vaynberg:

this is the usecase we are talking about. i get a compile error, which sucks.

public class Test
{
  public static void main(String[] args)
  {
      Foo foo = new FooImpl();
      foo.foo(IntegerComponent.class); // ok
      foo.foo(Component.class); // compile error
  }

  public static class Component<T> {}
  public static class IntegerComponent extends Component<Integer> {}

  public static interface Foo
  {
      public void foo(Class< ? extends Component< ? >> clazz);
  }

  public static class FooImpl implements Foo
  {
      public void foo(Class< ? extends Component< ? >> clazz) {}
  }
}

-igor

On Wed, May 14, 2008 at 11:56 PM, Sebastiaan van Erk
<[EMAIL PROTECTED]> wrote:
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<?>>

-igor

I 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,
Sebastiaan


On 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]



---------------------------------------------------------------------
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]

Reply via email to