RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival

[David Holmes]

On 18/05/2016 11:46 AM, Brent Christian wrote:
> Hi!
>
> Here's the final(?) webrev:
>   http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/webrev/
> with the following changes since the last one:

No further comments from me.

Thanks,
David

> * The @hidden JavaDoc tag has been removed.  It can't be used due to
> methods disappearing from the API page.  Living with the additional
> JavaDoc is the best option for now.  The situation should be improved by
> JDK-8157000 (thanks for filing, Mandy).
>
> * I also firmed up the doc update regarding iterators (using words from
> the java.util.concurrent package description of "weakly-consistent").
> Line 170.
>
> New specdiff views:
>
> http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/specdiff-javadoc/Properties.html
>
>
> http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/specdiff-plain/Properties.html
>
>
> * I did make one real code change, making the new Properties.EntrySet
> inner class static.  Line 1250.
>
> * I added a new test of unsynchronized, as suggested by Peter, and
> expanded coverage to all newly-unsynchronized methods.
>
> Thanks,
> -Brent
>
> On 5/13/16 8:01 AM, Mandy Chung wrote:
>>
>>> On May 12, 2016, at 5:58 PM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>>
>>>> With all of the inherited methods @hidden, it looks like that section
>>>> is left out altogether.
>>>
>>> Okay, so I have to say @hidden seems to me to be seriously flawed! If
>>> a class has a method that can be called then IMHO that has to be
>>> documented in that class as either being first defined, overridden,
>>> or inherited - it can't just say nothing as-if the method were not
>>> there!
>>>
>>> If we are overriding in a trivial way that does not change the
>>> specification at all then there should be a simple way to show that -
>>> perhaps the "Methods inherited from ..." should be split into two
>>> parts: method implementations inherited from ..., and method
>>> specifications inherited from ... ??
>>>
>>
>> I agree for this case these methods should not be hidden as if it’s
>> not there (that’s probably carried from the original @treatAsPrivate
>> request).
>>
>>> I guess I need to raise this with the javadoc folk :( Is there a
>>> mailing list for that?
>>
>> Can you file a JBS issue?  Kumar is on vacation and will talk with him
>> when he’s back.
>>
>> Mandy
>>