Hi Brent,
On 13/05/2016 7:02 AM, Brent Christian wrote:
Hi, David
On 5/11/16 8:39 PM, David Holmes wrote:
On 11/05/2016 7:56 AM, Brent Christian wrote:
While good progress was made during the original code review, all of the
overridden methods in Properties caused an explosion of unnecessary
JavaDoc (see specdiff at [2]). With the recent fix of 8073100 (new
"@hidden" JavaDoc tag), we can now avoid the additional clutter.
The existing javadoc has a section "Methods inherited from
java.util.Hashtable" which I can't see in your specdiff - what does that
section say about the methods you overrode to delegate to the CHM
instance? Are they simply not listed, or does it lie and claim they are
inherited, or does it have some new way to present "@hidden" things?
Good catch! specdiff didn't pick up that change with --config=javadoc,
which is a bit troubling, but it does show up with --config=plain:
http://cr.openjdk.java.net/~bchristi/8029891/webrev.4/specdiff-plain/Properties.html
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 guess I need to raise this with the javadoc folk :( Is there a mailing
list for that?
while the original deadlock is resolved by all this change, there
still exists a deadlock.
I should have been clearer. Since this issue was filed, the code paths
in question changed a fair bit with jigsaw. Pre-fix, the test still
hung, but in different code (NewDeadlock.txt). As Mandy said, with the
fix, Properties::get no longer locks on the object, and this test passes.
Ah, sorry about the misunderstanding.
Thanks,
David
Thanks,
-Brent
