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

Jason Mehrens jason_mehrens at hotmail.com
Wed May 18 14:00:17 UTC 2016


Have you considered increasing the visibility of just the EntrySet constructor from private to default access?  This should get rid an extra generated class file if you compare the javac output since you are accessing just the constructor from the enclosing class.


From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Brent Christian <brent.christian at oracle.com>
Sent: Tuesday, May 17, 2016 8:46 PM
To: Mandy Chung; David Holmes
Cc: core-libs-dev
Subject: Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival


Here's the final(?) 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:



* 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.


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

More information about the core-libs-dev mailing list