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

[Peter Levart]

Hi Brent,

The unsynchronized test looks good.

Let's hope that we didn't miss any hidden detail. We'll see how this 
works out when people get hold of new build containing this change.

Regards, Peter


On 05/18/2016 03: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:
>
> * 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
>>