RFR: JDK-8186160 Fix a11y issues in java.security package

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFR: JDK-8186160 Fix a11y issues in java.security package

Jonathan Gibbons
Please review the following small fix for some accessibility issues in
the java.security package.

3 tables are converted to the de-facto JDK standard for row-oriented
tables, and updated
with appropriate scope=row|col attributes to identify the header cell in
each row or column.
You can see the appearance of the updated tables in the API link below.

This is part of the ongoing effort to clean up all such issues in the
JDK documentation.

JBS: https://bugs.openjdk.java.net/browse/JDK-8186160
Webrev: http://cr.openjdk.java.net/~jjg/8186160/webrev.00
API: http://cr.openjdk.java.net/~jjg/8186160/api.00

-- Jon

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR: JDK-8186160 Fix a11y issues in java.security package

Brad R. Wetmore
Changes look good to me, although I'm not an HTML expert nor an expert
in our current documentation style.  I did compare the output, and can
see the effects.  (Striped, scope (row vs col), style)

Brad



On 8/11/2017 5:01 PM, Jonathan Gibbons wrote:

> Please review the following small fix for some accessibility issues in
> the java.security package.
>
> 3 tables are converted to the de-facto JDK standard for row-oriented
> tables, and updated
> with appropriate scope=row|col attributes to identify the header cell in
> each row or column.
> You can see the appearance of the updated tables in the API link below.
>
> This is part of the ongoing effort to clean up all such issues in the
> JDK documentation.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8186160
> Webrev: http://cr.openjdk.java.net/~jjg/8186160/webrev.00
> API: http://cr.openjdk.java.net/~jjg/8186160/api.00
>
> -- Jon
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR: JDK-8186160 Fix a11y issues in java.security package

Jonathan Gibbons
Brad,

Thanks. I should have noted that the issues were detected by checking tools,
and that after the edits, no such issues were reported in this package.

FWIW, there is one remaining issue to be addressed: it is a broken link
in Provider.html.
It comes from Provider.replace(Object, Object, Object) which overrides
Properties.replace(Object, Object, Object), but for some reason, that
method is
marked @hidden in Properties, causing a broken link in Provider. That needs
to be investigated, but I don't want to block these accessibility fixes.

-- Jon


On 08/11/2017 05:14 PM, Bradford Wetmore wrote:

> Changes look good to me, although I'm not an HTML expert nor an expert
> in our current documentation style.  I did compare the output, and can
> see the effects.  (Striped, scope (row vs col), style)
>
> Brad
>
>
>
> On 8/11/2017 5:01 PM, Jonathan Gibbons wrote:
>> Please review the following small fix for some accessibility issues
>> in the java.security package.
>>
>> 3 tables are converted to the de-facto JDK standard for row-oriented
>> tables, and updated
>> with appropriate scope=row|col attributes to identify the header cell
>> in each row or column.
>> You can see the appearance of the updated tables in the API link below.
>>
>> This is part of the ongoing effort to clean up all such issues in the
>> JDK documentation.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8186160
>> Webrev: http://cr.openjdk.java.net/~jjg/8186160/webrev.00
>> API: http://cr.openjdk.java.net/~jjg/8186160/api.00
>>
>> -- Jon
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR: JDK-8186160 Fix a11y issues in java.security package

Weijun Wang
>
> FWIW, there is one remaining issue to be addressed: it is a broken link in Provider.html.
> It comes from Provider.replace(Object, Object, Object) which overrides
> Properties.replace(Object, Object, Object), but for some reason, that method is
> marked @hidden in Properties, causing a broken link in Provider. That needs
> to be investigated, but I don't want to block these accessibility fixes.

I don't understand why there is a @hidden in Properties.java. There are many other methods nearby with a similar structure and I cannot see how this one is different.

The tag was added at

   http://hg.openjdk.java.net/jdk9/dev/jdk/rev/01a8615439f0#l2.349

in the fix for

   8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java

+
+    /** @hidden */
+    @Override
+    public synchronized boolean replace(Object key, Object oldValue, Object newValue) {
+        return map.replace(key, oldValue, newValue);
+    }

*Brent*: Is this method any special?

Thanks
Max

>
> -- Jon


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR: JDK-8186160 Fix a11y issues in java.security package

Brent Christian-2
Hi, Max

This tag snuck in by mistake.  Before pushing the fix for JDK-8029891,
we looked into ways to avoid addition of JavaDoc for all the
trivial method overrides.  I tried adding @hidden tags,
but they didn't do what we wanted, so they were taken out.  Except one -
sorry about that.

-Brent

On 8/14/17 3:36 AM, Weijun Wang wrote:

>>
>> FWIW, there is one remaining issue to be addressed: it is a broken link in Provider.html.
>> It comes from Provider.replace(Object, Object, Object) which overrides
>> Properties.replace(Object, Object, Object), but for some reason, that method is
>> marked @hidden in Properties, causing a broken link in Provider. That needs
>> to be investigated, but I don't want to block these accessibility fixes.
>
> I don't understand why there is a @hidden in Properties.java. There are many other methods nearby with a similar structure and I cannot see how this one is different.
>
> The tag was added at
>
>     http://hg.openjdk.java.net/jdk9/dev/jdk/rev/01a8615439f0#l2.349
>
> in the fix for
>
>     8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java
>
> +
> +    /** @hidden */
> +    @Override
> +    public synchronized boolean replace(Object key, Object oldValue, Object newValue) {
> +        return map.replace(key, oldValue, newValue);
> +    }
>
> *Brent*: Is this method any special?
>
> Thanks
> Max
>
>>
>> -- Jon
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR: JDK-8186160 Fix a11y issues in java.security package

Brent Christian-2
FYI, I plan to fix this by way of:

https://bugs.openjdk.java.net/browse/JDK-8186217

Remove erroneous @hidden JavaDoc tag from
java.util.Properties.replace(Object, Object, Object)

-Brent

On 8/14/17 10:02 AM, Brent Christian wrote:

> Hi, Max
>
> This tag snuck in by mistake.  Before pushing the fix for JDK-8029891,
> we looked into ways to avoid addition of JavaDoc for all the
> trivial method overrides.  I tried adding @hidden tags,
> but they didn't do what we wanted, so they were taken out.  Except one -
> sorry about that.
>
> -Brent
>
> On 8/14/17 3:36 AM, Weijun Wang wrote:
>>>
>>> FWIW, there is one remaining issue to be addressed: it is a broken
>>> link in Provider.html.
>>> It comes from Provider.replace(Object, Object, Object) which overrides
>>> Properties.replace(Object, Object, Object), but for some reason, that
>>> method is
>>> marked @hidden in Properties, causing a broken link in Provider. That
>>> needs
>>> to be investigated, but I don't want to block these accessibility fixes.
>>
>> I don't understand why there is a @hidden in Properties.java. There
>> are many other methods nearby with a similar structure and I cannot
>> see how this one is different.
>>
>> The tag was added at
>>
>>     http://hg.openjdk.java.net/jdk9/dev/jdk/rev/01a8615439f0#l2.349
>>
>> in the fix for
>>
>>     8029891 : Deadlock detected in
>> java/lang/ClassLoader/deadlock/GetResource.java
>>
>> +
>> +    /** @hidden */
>> +    @Override
>> +    public synchronized boolean replace(Object key, Object oldValue,
>> Object newValue) {
>> +        return map.replace(key, oldValue, newValue);
>> +    }
>>
>> *Brent*: Is this method any special?
>>
>> Thanks
>> Max
>>
>>>
>>> -- Jon
>>
>>
Loading...