Hi Kishor,
No problem about the delay; I've certainly contributed to delays myself. And
certainly I have an unbounded queue of things I'm working on myself at the moment.
And no, it's not too late for this work! In the past, if you missed a JDK
deadline, you might have to wait three years for the next major JDK release (one
in which specification changes were allowed). In the new release cadence, the
next "feature" release is only six months after the previous one, so effectively
there is always the possibility to get changes into the "next" JDK.
Looking forward to your draft.
s'marks
On 12/13/18 7:19 AM, Kishor Gollapalliwar wrote:
Hello Stuart,
Forgive me for delayed response.
I was not well for a week, due to which lot of work got queued up in office.
It took a while to sort it out.
Your guidance was really helpful.
And by end of this week I'll share first patch, containing document
enhancements for SortedSet class.
Hope I'm not too late.
Thanks,
Kishor Gollapalliwar
On Fri 30 Nov, 2018, 10:22 Stuart Marks <stuart.ma...@oracle.com
<mailto:stuart.ma...@oracle.com> wrote:
On 11/1/18 8:12 PM, Kishor Gollapalliwar wrote:
> Thank you for providing this opportunity. I'm up for this challenge and
I'd
> love to take this task. The only huddle would be, how to proceed, ie
planning
> things step by step, as this is my first time. If you can help me with the
> planning, I'll do the rest and fix these issues.
Hi, sorry for the delay. I had a couple conferences and then some vacation.
This issue comes up periodically. Consider this Stack Overflow question
and this
answer in particular:
https://stackoverflow.com/a/53375284/1441122
It quotes the relevant part of the TreeSet spec (which is also in the
SortedSet
interface):
> Note that the ordering maintained by a sorted set (whether or not an
explicit
> comparator is provided) must be consistent with equals if the sorted set
is
> to correctly implement the Set interface. (See the Comparable interface or
> Comparator interface for a precise definition of consistent with equals.)
> This is so because the Set interface is defined in terms of the equals
> operation, but a sorted set performs all element comparisons using its
> compareTo (or compare) method, so two elements that are deemed equal by
this
> method are, from the standpoint of the sorted set, equal. The behavior of
a
> sorted set is well-defined even if its ordering is inconsistent with
equals;
> it just fails to obey the general contract of the Set interface.
What's missing here are 1) a clear statement that membership in a
SortedSet is
determined by the comparison method, and 2) a crisp definition of
"comparison
method".
Various places in the spec mention something like "the Comparator's
compare()
method, if there is a comparator method, otherwise the compareTo() method
if the
set is using the elements' natural order...." The term "comparison method"
should be defined early on so that it can be used in later parts of the
spec,
avoiding the comparator/natural-order awkwardness.
Then, it should be specified that the comparison method 1) determines
membership
in the set as well as 2) ordering of set iteration, subsetting, etc. This
overlaps some with the first two paragraphs of the SortedSet class spec.
Regarding membership, the Set interface says:
> sets contain no pair of elements e1 and e2 such that e1.equals(e2)
SortedSet should have something similar, e.g.,
> SortedSets contain no pair of elements e1 and e2 such that e1 CMP e2 == 0
where "CMP" is the "comparison method". (You don't have to use this
notation,
but the idea is that there is no pair of elements in the set for which the
comparison method returns zero.)
Only at this point should the "consistent with equals" discussion be
introduced.
The problem with the existing text is that it introduces the "consistent
with
equals" topic, and then only incidentally mentions that set membership is
determined by "equality" according to the comparison method instead of
equals().
That's the first step, which basically amounts to rewriting the first three
paragraphs of the SortedSet class specification. The subsequent steps are:
2) Reconcile class doc of SortedSet subtypes, e.g. NavigableSet, TreeSet,
possibly ConcurrentSkipListSet.
3) Audit all method specs of all classes and reconcile them with the class
specs. A starting point for methods to look at is in this bug:
https://bugs.openjdk.java.net/browse/JDK-8190545
4) 5) 6) Similar steps as above for the SortedMap family.
**
I'd suggest just starting off with the first step instead of trying to do
it all
at once. Don't worry about posting webrevs or specdiffs yet; just send a
patch
or even plain text of the draft to the list and I'll start reviewing it.
Thanks,
s'marks
