It's hard to dabble in generics unless you're willing to put up with (or
turn off) the warnings.  You very quickly run into situations where you
need to perform a generics overhaul on classes, class hierarchies, and
even whole applications in order to get everything right with respect to
generics.  That's not intended to be critical of generics, by the way;
generics constitute a significant and fundamental change to Java's type
system, so its not surprising that it their use has broad impact.

On to the problem at hand.  You have run into one of those situations
that is not neatly restricted to a single method.  As is often the case,
you have a larger-scale design problem that generics can solve, but for
which your current code appears to follow the best model available in
1.4.  The issue revolves around your model of a "range".  You have
designed a generic range by defining bounds with use of a very abstract
type (Comparable), which is good pre-1.5 style, but the /declarations/
do not express the constraint that the bounds be comparable to each
other.  More succinctly, the question that the compiler wants to be able
to answer is "SimpleRange of /what/?"  This demands a full generic
treatment, something along these lines:

public class SimpleRange<T extends Comparable<? super T>> {

    T lowValue;
    T highValue;

    public SimpleRange(T low, T high) {
        if (low == null) {
            throw new IllegalArgumentException("Null lower bound");
        } else if (high == null) {
            throw new IllegalArgumentException("Null upper bound");
        } else {
            lowValue = low;
            highValue = high;

            // No need to test mutual comparability
        }
    }

    // other methods ...
}

Key points:
(1) The class is made generic, with one type parameter (T) defining the
type of the range's bounds, and presumably also the type of the members
of the range.
(2) The type parameter is assigned an upper bound (Comparable<? super
T>) that ensures that valid type arguments are all of types that are
comparable to themselves, whether by implementing Comparable directly or
by inheriting it from a superclass.
(3) The type parameter allows easy expression of the constraint that the
constructor arguments be of mutually compatible, Comparable, types.
(4) Making this change will produce a cascade of type safety warnings
from the compiler, requiring you to specify a type argument everywhere
you declare a reference of this type.

On Thu, 9 Mar 2006 19:52:29 -0500, "Rhino"
<no.offline.contact.please@nospam.com> wrote, quoted or indirectly
quoted someone who said :

Look at the code for Comparable and you will see:
public interface Comparable<T>

That is your clue. Wherever you have said Comparable you must say
Comparable<T> or Comparable<String> or the like.

For notes on implementing Comparable with generics see
http://mindprod.com/jgloss/comparable.html

see http://mindprod.com/jgloss/generics.html for the hair splitting.