Re: More Generics warnings.

On Jan 1, 1:50 am, Lew <l...@lewscanon.com> wrote:


 any


Looks good to me (damn you for being faster on the draw, too).

Since Lew has already solved the basic problem I'll take this as a
chance to ruminate about generics in the hopes of shedding some light
on them.

I came to Java from a C++ background, so I already had a working
understanding of C++'s implementation of generics (templates) to
compare to. This has been invaluable for me. In C++, a templated
class or function is not a function itself, but can be used at compile
time to create whole families of related functions. For example,

template <typename T>
T hello () {
 return T ();
}

allows the creation of many functions with concrete types. Calling,
for example, hello<string> () causes the compiler to emit code like

template <>
string hello () {
  return string (); // an empty string, maybe :)
}

Java's generics don't work this way, but for simple cases, it's a
useful model. You can pretend that QuickSort.sort (...) is actually a
family of functions, each taking a specific array type (one for
String[], one for Integer[], one for MyFavouriteClass[], et cetera),
and that the compiler uses the right definition at compile time.

The one place this comparison breaks down is in type bounds.

References do not have to have the same type as their referrent. This
is something we deal with regularly, eg., with List: a List reference
might be referring to an ArrayList object. Type bounds on a reference
constrain the set of types allowed in objects assigned to the
reference, like so:

The simplest type bound is the wildcard bound, ?, which means that
objects with any generic type can be assigned to the reference, but
that the generic type cannot be assigned to. Concrete example:

  List<?> someList = anyFunctionReturningAList ();

We can be certain that someList refers either to null or to a list of
a single homogenous type (anyFunction might have returned, say,
List<String>, which is a list only containing strings), but we don't
know/care what type that is. This means that code operating on
someList cannot insert elements into the list without a cast, and that
objects can only be read out of the list as Object:

  assert (someList.size() > 0);
  Object o = someList.get (0);

  // someList.add ("Hello, Roedy!"); would be an error

  // ((List<Object>) someList).add ("Hello, Roedy!");
  // would provoke a warning since it likely breaks the
  // type constraint on someList's concrete referrent.

The wildcard constraint can be reduced from "Object" to some more
specific type using the 'extends' constraint. If we wanted to operate
on a List of some subtype of Runnable, to pick a cheesy and unlikely
example, you could write

  List<? extends Runnable> someList2 = someSourceOfTasks ();

where someSourceOfTasks might return List<Runnable> or
List<MyTaskType> (assuming MyTaskType extends Runnable).

In fact, the bare wildcard constraint ? is exactly equivalent to the
extends constraint "? extends Object", and we can use Runnable with
someList2 the same way we used Object with someList:

  assert (someList2.size () > 0);
  Runnable task = someList2.get(0); // This is valid

  // MyTaskType task = someList2.get(0); // needs cast

The 'super' constraint goes the other direction: instead of saying
that the generic type must be assignable *to* a specific type, it says
that the generic type must be assignable *from* a specific type.
Cheesy example 3:

  public static void populate (List<? super Runnable> tasks) {
    tasks.add (new Runnable () { /* ... */ }); // valid
    // Runnable r = tasks.get (0); // [0]
  }

The line [0] is not valid, because the super constraint imposes no
upper bound on the wildcard. The only type elements of the list are
guaranteed to be assignable to is Object.

Wildcards in class and method declarations work the same way, except
that instead of leaving the specific type anonymous, they create a
type parameter that names it. For example, List's type parameter is
<T>, which is an unconstrained but named type: List instances can be
Lists of any specific type (List<Object>, List<String>, et cetera).
You can also use 'extends' and 'super' constraints; the following
example

  public interface TaskList<R extends Runnable> {
  }

defines a trivial interface whose type parameter accepts only Runnable
and subtypes of Runnable; within the class references of type R will
be assignable to type Runnable but Runnable is NOT assignable to R.
It's rare to see a super constraint in this context, but it's valid.

Generic promotion works slightly differently from reference
promotion. Using List and ArrayList as examples, the following
promoting assignments are valid:

  ArrayList<CharSequence> strings = ... ;

  // Constraint includes type:
  // CharSequence is a superclass of String.
  ArrayList<? super String> a = strings;

  // Constraint includes type:
  // CharSequence is a subclass of Object.
  ArrayList<? extends Object> b = strings;

  // Constraint includes type:
  // CharSequence is a type.
  ArrayList<?> c = strings;

  List<CharSequence> d = strings; // widening the base type