Hello Stuart,
Kindly find the diff file attached for your reference.
Request you to review and provide your feedback.
Once we finalize SortedSet, I'll start to enhance TreeSet documentation.
Thank you,
Kishor Gollapalliwar
On Tue, Dec 18, 2018 at 4:13 AM Stuart Marks <[email protected]>
wrote:
> 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 <[email protected] 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
>>
>
--
Thanks & Regards,
*Kishor Golapelliwar,*
The ability to convert ideas to things is the secret to outward success.
diff -r da66807df40f src/share/classes/java/util/SortedSet.java
--- a/src/share/classes/java/util/SortedSet.java Wed Dec 05 03:51:45 2018 -0500
+++ b/src/share/classes/java/util/SortedSet.java Tue Dec 18 08:13:43 2018 +0530
@@ -26,35 +26,24 @@
package java.util;
/**
- * A {@link Set} that further provides a <i>total ordering</i> on its elements.
- * The elements are ordered using their {@linkplain Comparable natural
- * ordering}, or by a {@link Comparator} typically provided at sorted
- * set creation time. The set's iterator will traverse the set in
- * ascending element order. Several additional operations are provided
- * to take advantage of the ordering. (This interface is the set
- * analogue of {@link SortedMap}.)
+ * A <b>comparison method</b> is either {@link Comparator#compare} or
+ * {@link Comparable#compareTo}, implemented by elements of this {@link Set}.<br/><br/>
*
- * <p>All elements inserted into a sorted set must implement the <tt>Comparable</tt>
- * interface (or be accepted by the specified comparator). Furthermore, all
- * such elements must be <i>mutually comparable</i>: <tt>e1.compareTo(e2)</tt>
- * (or <tt>comparator.compare(e1, e2)</tt>) must not throw a
- * <tt>ClassCastException</tt> for any elements <tt>e1</tt> and <tt>e2</tt> in
- * the sorted set. Attempts to violate this restriction will cause the
- * offending method or constructor invocation to throw a
- * <tt>ClassCastException</tt>.
+ * A {@link Set} that additionally provides <i>ordering</i> on its elements, using
+ * comparison method. Client <b>must</b> provide comparison method either by making set
+ * elements {@link Comparable} or providing custom {@link Comparator} while set creation
+ * eg, {@linkplain TreeSet#TreeSet(Comparator)}. Furthermore, all set elements must be
+ * <i>mutually comparable</i>, that is comparison method <b>must</b> not throw
+ * <tt>ClassCastException</tt> for any two elements. Several additional operations are
+ * provided to take advantage of the ordering. (This interface is the set analogue of
+ * {@link SortedMap}.) <br/><br/>
*
- * <p>Note that the ordering maintained by a sorted set (whether or not an
- * explicit comparator is provided) must be <i>consistent with equals</i> if
- * the sorted set is to correctly implement the <tt>Set</tt> interface. (See
- * the <tt>Comparable</tt> interface or <tt>Comparator</tt> interface for a
- * precise definition of <i>consistent with equals</i>.) This is so because
- * the <tt>Set</tt> interface is defined in terms of the <tt>equals</tt>
- * operation, but a sorted set performs all element comparisons using its
- * <tt>compareTo</tt> (or <tt>compare</tt>) 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 <i>is</i> well-defined even if its
- * ordering is inconsistent with equals; it just fails to obey the general
- * contract of the <tt>Set</tt> interface.
+ * Unlike other {@link Set} implementations, eligibility of an element is decided by
+ * comparison method and not using {@link Object#equals}. The equals <b>must</b>
+ * be consistent with comparison method, ie if elementA is equals to elementB (according
+ * to equals), comparison method must return 0 (zero) for them and vice versa. If two
+ * elements are not equal (according to equals method), but returns 0 (zero) when
+ * compared (using comparison method) will be considered equal.<br/><br/>
*
* <p>All general-purpose sorted set implementation classes should
* provide four "standard" constructors: 1) A void (no arguments)
