«

The return types for keySet and entrySet are just Set, rather than
SortedSet. This could have been changed when Java 5 began to allow
overrides/implementations with covariant return types. Does anybody
know why it wasn't?

In article
<bc043354-7d0b-4a28-93a7->,
Captain Koloth <> wrote:

> The return types for keySet and entrySet are just Set, rather than
> SortedSet. This could have been changed when Java 5 began to allow
> overrides/implementations with covariant return types. Does anybody
> know why it wasn't?

Perhaps I'm overlooking something, but shouldn't one prefer the
superinterface?

<code>
import java.util.ArrayList;
import java.util.Arrays;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.TreeMap;

/**
* @author John B. Matthews
*/
public class MapTest {

public static void main(String[] args) {
final Map<String, List<String>> map =
new HashMap<String, List<String>>();
List<String> list = new ArrayList<String>(
Arrays.asList("Alpha", "Beta", "Gamma"));
map.put("Ordinals", list);

list = new ArrayList<String>(
Arrays.asList("Aleph", "Beth", "Gimel"));
map.put("Cardinals", list);

list = new ArrayList<String>(
Arrays.asList("Alpher", "Bethe", "Gammow"));
map.put("Physicists", list);

list = new ArrayList<String>(
Arrays.asList("Actinomyces", "Bordetella", "Giardia"));
map.put("Pathogens", list);

printMap(map);
System.out.println();

final Map<String, List<String>> tm = new
TreeMap<String, List<String>>(map);
printMap(tm);
}

private static void printMap(Map<String, List<String>> map) {
for (Map.Entry entry : map.entrySet()) {
System.out.println(entry.getKey()
+ " " + entry.getValue());
}
}
}
</code>

<console>
Physicists [Alpher, Bethe, Gammow]
Ordinals [Alpha, Beta, Gamma]
Cardinals [Aleph, Beth, Gimel]
Pathogens [Actinomyces, Bordetella, Giardia]

Cardinals [Aleph, Beth, Gimel]
Ordinals [Alpha, Beta, Gamma]
Pathogens [Actinomyces, Bordetella, Giardia]
Physicists [Alpher, Bethe, Gammow]
</console>
--
John B. Matthews
trashgod at gmail dot com
http://home.roadrunner.com/~jbmatthews/

On Nov 27, 9:41*pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article
> <bc043354-7d0b-4a28-93a7-eb0be4050...@z1g2000yqn.googlegroups.com>,
> *Captain Koloth <kolot...@gmail.com> wrote:
>
> > The return types for keySet and entrySet are just Set, rather than
> > SortedSet. This could have been changed when Java 5 began to allow
> > overrides/implementations with covariant return types. Does anybody
> > know why it wasn't?
>
> Perhaps I'm overlooking something, but shouldn't one prefer the
> superinterface?

That depends. If you want to use SortedMap or SortedSet features that
are not general Map or Set features, then you don't want to type your
references as plain Map or Set.

Generally, you want to use the least specific type that will do the
job.

Not the least specific type, period, or else you'd have all your
references be of type Object.

And if all your references ARE of type Object, your coworkers and the
future maintenance programmers that have to deal with your code will
call you a petaQ, and rightly so!

In article
<5288d7d5-494a-45b3-9695->,
Captain Koloth <> wrote:

> On Nov 27, 9:41*pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> > In article
> > <bc043354-7d0b-4a28-93a7-eb0be4050...@z1g2000yqn.googlegroups.com>,
> > *Captain Koloth <kolot...@gmail.com> wrote:
> >
> > > The return types for keySet and entrySet are just Set, rather than
> > > SortedSet. This could have been changed when Java 5 began to allow
> > > overrides/implementations with covariant return types. Does anybody
> > > know why it wasn't?
> >
> > Perhaps I'm overlooking something, but shouldn't one prefer the
> > superinterface?
>
> That depends. If you want to use SortedMap or SortedSet features that
> are not general Map or Set features, then you don't want to type your
> references as plain Map or Set.

TreeMap implements the SortedMap methods; TreeSet implements the
SortedSet methods. The two subinterfaces seem parallel. I don't
understand what benefit would accrue to mixing them.

> Generally, you want to use the least specific type that will do the
> job.

Agreed. It seems the authors have done that.

> Not the least specific type, period, or else you'd have all your
> references be of type Object. And if all your references ARE of type
> Object, your coworkers and the future maintenance programmers that
> have to deal with your code will call you a petaQ, and rightly so!

The word "Object" did not appear in my example, so perhaps I am safe.
How did you know my coworkers speak Klingon?

--
John B. Matthews
trashgod at gmail dot com
http://home.roadrunner.com/~jbmatthews/

On Fri, 28 Nov 2008, John B. Matthews wrote:

> In article
> <5288d7d5-494a-45b3-9695->,
> Captain Koloth <> wrote:
>
>> On Nov 27, 9:41*pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
>>> In article
>>> <bc043354-7d0b-4a28-93a7-eb0be4050...@z1g2000yqn.googlegroups.com>,
>>> *Captain Koloth <kolot...@gmail.com> wrote:
>>>
>>>> The return types for keySet and entrySet are just Set, rather than
>>>> SortedSet. This could have been changed when Java 5 began to allow
>>>> overrides/implementations with covariant return types. Does anybody
>>>> know why it wasn't?
>>>
>>> Perhaps I'm overlooking something, but shouldn't one prefer the
>>> superinterface?
>>
>> That depends. If you want to use SortedMap or SortedSet features that
>> are not general Map or Set features, then you don't want to type your
>> references as plain Map or Set.
>
> TreeMap implements the SortedMap methods; TreeSet implements the
> SortedSet methods. The two subinterfaces seem parallel. I don't
> understand what benefit would accrue to mixing them.

The point is that the key set of a SortedMap is sorted, so it could/should
be a SortedSet.

That said, i can't think of anything you could do with a SortedSet key set
that you can't do another way. If we have:

SortedMap<String, Object> map ;

Then:

map.keySet().first() ; // can't be done
map.firstKey() ; // can

map.keySet().headSet("Bolivia") ; // can't be done
map.headMap("Bolivia").keySet() ; // can

If you had some method that took a SortedSet, and you wanted to apply it
to the keys of a SortedMap, then you'd be stuffed, but that's the only
situation i can think of.

I would say it would be more elegant if the key set was a SortedSet,
though. It more completely describes the properties of the map.

tom

--
Would you like to remember more?

Captain Koloth wrote:
> The return types for keySet and entrySet are just Set, rather than
> SortedSet. This could have been changed when Java 5 began to allow
> overrides/implementations with covariant return types. Does anybody
> know why it wasn't?

It would have broken the contract established for earlier code.

SortedMap implementors are free to document that they return SortedSet for
those methods. The methods documented to return Set are free to return a
SortedSet should they choose, they just can't promise to do so in the return type.

It isn't nice to just go and change the definition of SortedMap's methods just
because now you can. Code has been developed in the field for a long time
with the old contract. Look at the grief caused from the few changes to old
contracts that Java 5 did make. Only when the need was great or the benefit
overwhelming did such changes occur.

This is an object lesson for API developers, comprising virtually all Java
coders. Once you commit an API to a contract, you're committed in perpetuity.
That's why things like implementing Serializable are such serious decisions,
and why one must prefer the widest appropriate declared type for variables and
method returns.

--
Lew

On Nov 28, 7:33*pm, Lew <l...@lewscanon.com> wrote:
> Captain Koloth wrote:
> > The return types for keySet and entrySet are just Set, rather than
> > SortedSet. This could have been changed when Java 5 began to allow
> > overrides/implementations with covariant return types. Does anybody
> > know why it wasn't?
>
> It would have broken the contract established for earlier code.

Nope. SortedSet extends Set, so any code that used the keySet or
entrySet from, say, a TreeMap would still work. Nowhere is there a
contract that what these return is *not sorted*, and I expect set
views of SortedMaps will in fact be sorted whatever the compile-time
type of the reference used to hold them.

One minor issue would be whether you would be allowed to change the
Comparator of the map through the returned set. But SortedSet only
specifies a method to retrieve the comparator, not to set it, so
that's moot unless the comparator is itself mutable in some way. I
expect a mutable comparator, with methods that change its sorting
behavior, breaks the Comparator contract anyway. Trees would have to
be completely rebuilt if the comparison changed, and comparators would
need to accept some kinds of Listeners, and all kinds of other chaos
would ensue if you wanted mutable comparators to work. If all the
classes assume comparators are immutable (at least with respect to
sort order semantics) already then this issue is indeed moot.

On Sat, 29 Nov 2008, Captain Koloth wrote:

> On Nov 28, 7:33*pm, Lew <l...@lewscanon.com> wrote:
>> Captain Koloth wrote:
>>> The return types for keySet and entrySet are just Set, rather than
>>> SortedSet. This could have been changed when Java 5 began to allow
>>> overrides/implementations with covariant return types. Does anybody
>>> know why it wasn't?
>>
>> It would have broken the contract established for earlier code.
>
> Nope.

Yup.

You're only thinking about the contract from the point of view of the
caller. But the contract also exists for the SortedMap implementer, and it
defines what he's allowed to do. If i wrote a SortedMap under 1.4 that
returned a key set that wasn't a SortedSet, which was perfectly legal at
that point, i would take a very dim view of a change to the definition of
SortedMap in 1.5 that made it illegal.

tom

--
This is your life and it's ending one minute at a time.

On Nov 29, 2:21*pm, Tom Anderson <t...@urchin.earth.li> wrote:
> On Sat, 29 Nov 2008, Captain Koloth wrote:
> > On Nov 28, 7:33*pm, Lew <l...@lewscanon.com> wrote:
> >> Captain Koloth wrote:
> >>> The return types for keySet and entrySet are just Set, rather than
> >>> SortedSet. This could have been changed when Java 5 began to allow
> >>> overrides/implementations with covariant return types. Does anybody
> >>> know why it wasn't?
>
> >> It would have broken the contract established for earlier code.
>
> > Nope.
>
> Yup.

Nope.

> You're only thinking about the contract from the point of view of the
> caller.

That IS the contract.

> But the contract also exists for the SortedMap implementer, and it
> defines what he's allowed to do. If i wrote a SortedMap under 1.4 that
> returned a key set that wasn't a SortedSet, which was perfectly legal at
> that point, i would take a very dim view of a change to the definition of
> SortedMap in 1.5 that made it illegal.

Why? It would be very easy to update it, since the backing Map is
sorted. You'd just need to implement first, last, subSet, tailSet, and
headSet, and you could make all of those (in presumably an anonymous
inner class of your map) punt to MySortedMap.this.firstKey(), lastKey
(), subMap(x,y).keySet(), tailMap(x).keySet(), and headMap(y).keySet
().

It would take all of five minutes.

Also, how common are third-party implementations of SortedMap, really?

> On Nov 29, 2:21 pm,
>> On Sat, 29 Nov 2008,
Lew wrote:
>>>> It would have broken the contract established for earlier code.

Captain Koloth wrote:
>>> Nope.


>> Yup.

Captain Koloth wrote:
> Nope.

Tom Anderson <t...@urchin.earth.li> wrote:
>> You're only thinking about the contract from the point of view of the
>> caller.

Captain Koloth wrote:
> That IS the contract.

Only half of it. People who write code are just as important as those who use it.

>> But the contract also exists for the SortedMap implementer, and it
>> defines what he's allowed to do. If i wrote a SortedMap under 1.4 that
>> returned a key set that wasn't a SortedSet, which was perfectly legal at
>> that point, i would take a very dim view of a change to the definition of
>> SortedMap in 1.5 that made it illegal.
>
> Why? It would be very easy to update it, since the backing Map is

But you thus show that you realize that there would be a need for change if
the contract changed. And you don't know how easy it would be to update it,
since the implementation to change will itself be used by other code, which
then will need to change, thus requiring unit tests, regression tests,
deployment to a zillion production sites, possible new bugs to fix, delays to
other more critical feature improvements or repair, and a whole lot of cost to
Java projects overall. That would be egregiously irresponsible of Sun absent
a compelling reason. Look how long the adoption of Java 5 is taking with its
compelling changes - many, many projects have yet to upgrade and it's already
in End-of-Life. You can't just go imposing costs on your customers willy-nilly.

> sorted. You'd just need to implement first, last, subSet, tailSet, and
> headSet, and you could make all of those (in presumably an anonymous
> inner class of your map) punt to MySortedMap.this.firstKey(), lastKey
> (), subMap(x,y).keySet(), tailMap(x).keySet(), and headMap(y).keySet
> ().
>
> It would take all of five minutes.

Not so.

> Also, how common are third-party implementations of SortedMap, really?

At the time the contract was written, there weren't any. Having written the
contract, Java must not assume that continues to pertain. There could be
thousands of such implementations by now.

--
Lew