Remove raw types support

[gissuebot]

Original issue created by Ash2kk on 2012-05-02 at 03:54 PM

---

Do Guava users still need raw types support?

e.g. Sets public static <E extends Comparable> TreeSet<E> newTreeSet() should be public static <E extends Comparable<? super E>> TreeSet<E> newTreeSet()

[gissuebot]

Original comment posted by wasserman.louis on 2012-05-02 at 08:21 PM

---

(No comment entered for this change.)

---

Labels: Package-Collect

[gissuebot]

Original comment posted by gak@google.com on 2012-05-10 at 06:49 PM

---

We need to develop a good migration plan for this. We'll try the experiment internally and see how much breaks in order to assess how feasible this is.

---

Status: Accepted

[gissuebot]

Original comment posted by Ash2kk on 2012-05-28 at 04:08 AM

---

Also com.google.common.collect.Ranges (and maybe other classes) have methods with generics that can be improved. e.g. <C extends Comparable<?>> Range<C> downTo(C endpoint, BoundType boundType); should be <C extends Comparable<? super C>> Range<C> downTo(C endpoint, BoundType boundType);

[gissuebot]

Original comment posted by wasserman.louis on 2012-05-28 at 08:59 AM

---

Issue #1015 has been merged into this issue.

[gissuebot]

Original comment posted by kevinb@google.com on 2012-06-22 at 06:30 PM

---

(No comment entered for this change.)

---

Labels: Type-Enhancement

[gissuebot]

Original comment posted by cpovirk@google.com on 2012-11-07 at 07:42 PM

---

<C extends Comparable<? super C>> still causes problems internally.

<C extends Comparable<C>>: likewise

<C extends Comparable<?>> is an option.

[gissuebot]

Original comment posted by cpovirk@google.com on 2013-12-20 at 07:46 PM

---

Issue #1015 has been merged into this issue.

[kevinb9n]

I see three separate things we can consider this upgrade for

• Ordering.natural()
• Range and related
• MultimapBuilder (whoops?)

(also an internal-only binarySearch replacement)

I'm not worrying about the collection factory methods as those are sort of passe.

Also, MinMaxPriorityQueue and ImmutableSortedMultiset use <C extends Comparable<C>> instead of <C extends Comparable<? super C>>, but might have usage low enough that they can skirt the "problems" Chris referred to above.

[cpovirk]

I took a tiny step in this direction for Truth in https://github.com/google/truth/pull/1095, at least moving to T extends Comparable<?> (from T extends Comparable). It went fine (at least inside Google—we'll see how the next public release goes).

Then I ran some tests with changes that took further steps (to T extends Comparable<T> and T extends Comparable<? super T>, including declaring parameters as both T and Comparable<T> (maybe also Comparable<? super T>; I forget). Those led to source incompatibilities. I assume that we could fix them if we cared, but it was hard to get too excited about. It also appeared that at least some of those changes would enable unsafe calls that weren't possible before, but that may have happened only with raw Comparable types.

Truth may be different from Guava for various reasons:

• Few users have to write "Foo<SomeComparableType>" in their code for Truth; more would have to for Guava.
• Truth uses a fluent/chained style for calls more than Guava does. This affects type inference.

[kevinb9n]

One hopes that 99.9999% of users have finished moving to generics by now (18 years later!), but the trouble is that for any code that got stuck with a raw Comparable, this change would leave them high and dry, and they can't even suppress their way out of it. That last part is what bothers me.

We also just don't want to make any potentially breaking change at this point.

[cpovirk]

I think we can do this in some places without leaving users high and dry. For example, I think we could do it for Ordering.natural(), and users could still cast to Ordering<Foo> as needed. That's in contrast to something like Range, where users wouldn't even be able to declare a Range<Foo> if Foo extended raw Comparable (IIRC). Not that we want to force even a cast, but at least users would be able to suppress their way out of it. (And of course this change would be binary-compatible, so we're talking about "only" source compatibility.)

I mention this because a change of Ordering.natural() to use Comparable<?> (instead of Comparable) passes our internal testing, and it would have avoided a bunch of explicit type arguments in #7080.

I'm still not going to do it now, but I'm reopening this, in part because I keep looking for this issue and have trouble finding it :) But another part of the reason that I'm having trouble finding it is that it does not contain the term "rawtypes," so: rawtypes rawtypes rawtypes.

[kevinb9n]

Dangit Chris, don't you know saying "rawtypes" three times in a row summons rawtypes to show up and play mischievous chaotic pranks on you and your friends?