Re: RFR: 8179370: Replace use of , and tags in java.base

[joe darcy]

Looks better; thanks Jon,

-Joe


On 4/26/2017 6:49 PM, Jonathan Gibbons wrote:
Updated webrev to address Joe's suggestion to try harder to use 
{@code} as a substitute for .


http://cr.openjdk.java.net/~jjg/8179370/webrev.01

The modified sed script has a new first line:

s|\([^&<>]*\)|{@code \1}|g
s|||g
s|||g
s|<\\/tt>|<\\/code>|g
s|\(]*\)>\([^<]*\)|\1 
style="text-align:center">\2|
s|style="margin:0 auto" |

s|||
s|||

Also note that there is a small visible bug in webrev. If you look at 
ServiceLoader.java:133,
the second instance of  is not converted to {@code} because the 
embedded '\' is actually
an entity in the source file ... and so it is inappropriate to use 
{@code} for that instance.


-- Jon



On 04/26/2017 06:09 PM, Jonathan Gibbons wrote:

Joe,

Yes, there are occurrences here that require  instead of 
{@code}, because of the presence of HTML entities. It's about 50/50.


I'd prefer to stay with mechanical updates as much as possible for 
these bulk updates, as compared to manual updates, but I may be able 
to improve the sed script for this case.


-- Jon

On 04/26/2017 05:55 PM, Joseph D. Darcy wrote:

Hi Jon,

I'd prefer if the "foo" were replaced with "{@code tt}" 
rather than "foo"- none of the tricky cases which 
preclude use of {@code } use seem to be present here - but will 
approve the changeset in its current form too.


Cheers,

-Joe

On 4/26/2017 5:50 PM, Jonathan Gibbons wrote:
Please review these mostly simple changes to replace HTML tags 
which are not valid in HTML 5 in public doc comments in java.base.


As with the previous changes, the changes were done mechanically, 
using the following sed script:


s|||g
s|||g
s|<\\/tt>|<\\/code>|g
s|\(]*\)>\([^<]*\)|\1 
style="text-align:center">\2|
s|style="margin:0 auto" |

s|||
s|||

The unusual form of the 3rd line was to cover the occurrence in a 
makefile.


The 4th line is specific for DataInput.java, and replaces  
within a  with a style on the  element itself.


The 5th and 6th lines are specific to URLConnection. The use of the 
table itself and the ASCII art that follows it are questionable, 
but the intent here is just to update the HTML and not to rework 
the visual appearance of the generated documentation.


The changes cover files in the following packages:

java.base java/io
java.base java/net
java.base java/util
java.base javax/net/ssl


JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/

-- Jon

Re: RFR: 8179370: Replace use of , and tags in java.base

[Jonathan Gibbons]

Updated webrev to address Joe's suggestion to try harder to use {@code} 
as a substitute for .


http://cr.openjdk.java.net/~jjg/8179370/webrev.01

The modified sed script has a new first line:

s|\([^&<>]*\)|{@code \1}|g
s|||g
s|||g
s|<\\/tt>|<\\/code>|g
s|\(]*\)>\([^<]*\)|\1 style="text-align:center">\2|
s|
s|||
s|||

Also note that there is a small visible bug in webrev. If you look at 
ServiceLoader.java:133,
the second instance of  is not converted to {@code} because the 
embedded '\' is actually
an entity in the source file ... and so it is inappropriate to use 
{@code} for that instance.


-- Jon



On 04/26/2017 06:09 PM, Jonathan Gibbons wrote:

Joe,

Yes, there are occurrences here that require  instead of 
{@code}, because of the presence of HTML entities. It's about 50/50.


I'd prefer to stay with mechanical updates as much as possible for 
these bulk updates, as compared to manual updates, but I may be able 
to improve the sed script for this case.


-- Jon

On 04/26/2017 05:55 PM, Joseph D. Darcy wrote:

Hi Jon,

I'd prefer if the "foo" were replaced with "{@code tt}" 
rather than "foo"- none of the tricky cases which 
preclude use of {@code } use seem to be present here - but will 
approve the changeset in its current form too.


Cheers,

-Joe

On 4/26/2017 5:50 PM, Jonathan Gibbons wrote:
Please review these mostly simple changes to replace HTML tags which 
are not valid in HTML 5 in public doc comments in java.base.


As with the previous changes, the changes were done mechanically, 
using the following sed script:


s|||g
s|||g
s|<\\/tt>|<\\/code>|g
s|\(]*\)>\([^<]*\)|\1 
style="text-align:center">\2|
s|style="margin:0 auto" |

s|||
s|||

The unusual form of the 3rd line was to cover the occurrence in a 
makefile.


The 4th line is specific for DataInput.java, and replaces  
within a  with a style on the  element itself.


The 5th and 6th lines are specific to URLConnection. The use of the 
table itself and the ASCII art that follows it are questionable, but 
the intent here is just to update the HTML and not to rework the 
visual appearance of the generated documentation.


The changes cover files in the following packages:

java.base java/io
java.base java/net
java.base java/util
java.base javax/net/ssl


JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/

-- Jon

Re: RFR: 8179370: Replace use of , and tags in java.base

[Mandy Chung]

Looks okay.
Mandy

> On Apr 26, 2017, at 5:50 PM, Jonathan Gibbons  
> wrote:
> 
> Please review these mostly simple changes to replace HTML tags which are not 
> valid in HTML 5 in public doc comments in java.base.
> 
> As with the previous changes, the changes were done mechanically, using the 
> following sed script:
> 
> s|||g
> s|||g
> s|<\\/tt>|<\\/code>|g
> s|\(]*\)>\([^<]*\)|\1 style="text-align:center">\2|
> s| |
> s|||
> s| s|||
> 
> The unusual form of the 3rd line was to cover the occurrence in a makefile.
> 
> The 4th line is specific for DataInput.java, and replaces  within a 
>  with a style on the  element itself.
> 
> The 5th and 6th lines are specific to URLConnection. The use of the table 
> itself and the ASCII art that follows it are questionable, but the intent 
> here is just to update the HTML and not to rework the visual appearance of 
> the generated documentation.
> 
> The changes cover files in the following packages:
> 
> java.base java/io
> java.base java/net
> java.base java/util
> java.base javax/net/ssl
> 
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
> Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/
> 
> -- Jon

Re: RFR: 8179370: Replace use of , and tags in java.base

[Jonathan Gibbons]

Joe,

Yes, there are occurrences here that require  instead of {@code}, 
because of the presence of HTML entities. It's about 50/50.


I'd prefer to stay with mechanical updates as much as possible for these 
bulk updates, as compared to manual updates, but I may be able to 
improve the sed script for this case.


-- Jon

On 04/26/2017 05:55 PM, Joseph D. Darcy wrote:

Hi Jon,

I'd prefer if the "foo" were replaced with "{@code tt}" 
rather than "foo"- none of the tricky cases which 
preclude use of {@code } use seem to be present here - but will 
approve the changeset in its current form too.


Cheers,

-Joe

On 4/26/2017 5:50 PM, Jonathan Gibbons wrote:
Please review these mostly simple changes to replace HTML tags which 
are not valid in HTML 5 in public doc comments in java.base.


As with the previous changes, the changes were done mechanically, 
using the following sed script:


s|||g
s|||g
s|<\\/tt>|<\\/code>|g
s|\(]*\)>\([^<]*\)|\1 
style="text-align:center">\2|
s|style="margin:0 auto" |

s|||
s|||

The unusual form of the 3rd line was to cover the occurrence in a 
makefile.


The 4th line is specific for DataInput.java, and replaces  
within a  with a style on the  element itself.


The 5th and 6th lines are specific to URLConnection. The use of the 
table itself and the ASCII art that follows it are questionable, but 
the intent here is just to update the HTML and not to rework the 
visual appearance of the generated documentation.


The changes cover files in the following packages:

java.base java/io
java.base java/net
java.base java/util
java.base javax/net/ssl


JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/

-- Jon

Re: RFR: 8179370: Replace use of , and tags in java.base

[Joseph D. Darcy]

Hi Jon,

I'd prefer if the "foo" were replaced with "{@code tt}" rather 
than "foo"- none of the tricky cases which preclude use of 
{@code } use seem to be present here - but will approve the changeset in 
its current form too.


Cheers,

-Joe

On 4/26/2017 5:50 PM, Jonathan Gibbons wrote:
Please review these mostly simple changes to replace HTML tags which 
are not valid in HTML 5 in public doc comments in java.base.


As with the previous changes, the changes were done mechanically, 
using the following sed script:


s|||g
s|||g
s|<\\/tt>|<\\/code>|g
s|\(]*\)>\([^<]*\)|\1 
style="text-align:center">\2|
s|style="margin:0 auto" |

s|||
s|||

The unusual form of the 3rd line was to cover the occurrence in a 
makefile.


The 4th line is specific for DataInput.java, and replaces  
within a  with a style on the  element itself.


The 5th and 6th lines are specific to URLConnection. The use of the 
table itself and the ASCII art that follows it are questionable, but 
the intent here is just to update the HTML and not to rework the 
visual appearance of the generated documentation.


The changes cover files in the following packages:

java.base java/io
java.base java/net
java.base java/util
java.base javax/net/ssl


JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/

-- Jon

RFR: 8179370: Replace use of , and tags in java.base

[Jonathan Gibbons]

Please review these mostly simple changes to replace HTML tags which are 
not valid in HTML 5 in public doc comments in java.base.


As with the previous changes, the changes were done mechanically, using 
the following sed script:


s|||g
s|||g
s|<\\/tt>|<\\/code>|g
s|\(]*\)>\([^<]*\)|\1 style="text-align:center">\2|
s|
s|||
s|||

The unusual form of the 3rd line was to cover the occurrence in a makefile.

The 4th line is specific for DataInput.java, and replaces  
within a  with a style on the  element itself.


The 5th and 6th lines are specific to URLConnection. The use of the 
table itself and the ASCII art that follows it are questionable, but the 
intent here is just to update the HTML and not to rework the visual 
appearance of the generated documentation.


The changes cover files in the following packages:

java.base java/io
java.base java/net
java.base java/util
java.base javax/net/ssl


JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/

-- Jon

Re: RFR: Remove map synchronization from SignatureAndHashAlgorithm

[Sean Mullan]

On 4/26/17 1:52 PM, Steven Davidovitz wrote:

Thanks! I'm working on the OCA right now, I made a mistake when I
submitted it before so I'll follow up when it's done.

Anything else I need to do? Could this also be backported to version 8?


We are already at RDP2 [1] for JDK 9. Only P1 and P2 bugs that are 
critical issues should be fixed now and in my opinion, this is not a 
critical issue for JDK 9. So we will need to fix it in JDK 10 first. 
Backports to a 9u/8u release can be considered later.


--Sean

[1] http://openjdk.java.net/projects/jdk9/rdp-2



On Tue, Apr 25, 2017 at 7:05 AM, Sean Mullan mailto:sean.mul...@oracle.com>> wrote:

Hi Steven,

Thanks, I filed an issue on your behalf for tracking purposes:
https://bugs.openjdk.java.net/browse/JDK-8179275


Also, have you signed the OCA? See
http://www.oracle.com/technetwork/community/oca-486395.html
 for
more information.

--Sean


On 4/15/17 3:25 PM, Steven Davidovitz wrote:

With the removal of the synchronization on priorityMap inside
'SignatureAndHashAlgorithm.getSupportedAlgorithms' in rev
daaace32c979
[1], it seems unnecessary to use a synchronizedSortedMap.
Benchmarking, I see a 2x performance increase by using the bare
TreeMap.

measureModified   sample  11336330 11949.506 ± 1775.776  ns/op
measureOriginalsample  10855026 23003.654 ± 2286.571  ns/op

Thanks,
Steven Davidovitz

1: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/daaace32c979


diff --git

a/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java

b/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
---

a/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
+++

b/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
@@ -396,46 +396,42 @@
 }

 static {
-supportedMap = Collections.synchronizedSortedMap(
-new TreeMap());
-priorityMap = Collections.synchronizedSortedMap(
-new TreeMap());
-
-synchronized (supportedMap) {
-int p = SUPPORTED_ALG_PRIORITY_MAX_NUM;
-supports(HashAlgorithm.MD5,
 SignatureAlgorithm.RSA,
-"MD5withRSA",   --p);
-supports(HashAlgorithm.SHA1,
SignatureAlgorithm.DSA,
-"SHA1withDSA",  --p);
-supports(HashAlgorithm.SHA1,
SignatureAlgorithm.RSA,
-"SHA1withRSA",  --p);
-supports(HashAlgorithm.SHA1,
SignatureAlgorithm.ECDSA,
-"SHA1withECDSA",--p);
+supportedMap = new TreeMap();
+priorityMap = new TreeMap();

-if (Security.getProvider("SunMSCAPI") == null) {
-supports(HashAlgorithm.SHA224,
SignatureAlgorithm.DSA,
-"SHA224withDSA",--p);
-supports(HashAlgorithm.SHA224,
SignatureAlgorithm.RSA,
-"SHA224withRSA",--p);
-supports(HashAlgorithm.SHA224,
SignatureAlgorithm.ECDSA,
-"SHA224withECDSA",  --p);
-}
+int p = SUPPORTED_ALG_PRIORITY_MAX_NUM;
+supports(HashAlgorithm.MD5, SignatureAlgorithm.RSA,
+"MD5withRSA",   --p);
+supports(HashAlgorithm.SHA1,SignatureAlgorithm.DSA,
+"SHA1withDSA",  --p);
+supports(HashAlgorithm.SHA1,SignatureAlgorithm.RSA,
+"SHA1withRSA",  --p);
+supports(HashAlgorithm.SHA1,
SignatureAlgorithm.ECDSA,
+"SHA1withECDSA",--p);

-supports(HashAlgorithm.SHA256,
SignatureAlgorithm.DSA,
-"SHA256withDSA",--p);
-supports(HashAlgorithm.SHA256,
SignatureAlgorithm.RSA,
-"SHA256withRSA",--p);
-supports(HashAlgorithm.SHA256,
SignatureAlgorithm.ECDSA,
-"SHA256withECDSA",  --p);
-supports(HashAlgorithm.SHA384,
SignatureAlgorithm.RSA,
-"SHA384withRSA",--p);
-supports(HashAlgorithm.SHA384,
SignatureAlgorithm.ECDSA,
-

Re: RFR: Remove map synchronization from SignatureAndHashAlgorithm

[Steven Davidovitz]

Thanks! I'm working on the OCA right now, I made a mistake when I submitted
it before so I'll follow up when it's done.

Anything else I need to do? Could this also be backported to version 8?

On Tue, Apr 25, 2017 at 7:05 AM, Sean Mullan  wrote:

> Hi Steven,
>
> Thanks, I filed an issue on your behalf for tracking purposes:
> https://bugs.openjdk.java.net/browse/JDK-8179275
>
> Also, have you signed the OCA? See http://www.oracle.com/technetw
> ork/community/oca-486395.html for more information.
>
> --Sean
>
>
> On 4/15/17 3:25 PM, Steven Davidovitz wrote:
>
>> With the removal of the synchronization on priorityMap inside
>> 'SignatureAndHashAlgorithm.getSupportedAlgorithms' in rev daaace32c979
>> [1], it seems unnecessary to use a synchronizedSortedMap.
>> Benchmarking, I see a 2x performance increase by using the bare
>> TreeMap.
>>
>> measureModified   sample  11336330 11949.506 ± 1775.776  ns/op
>> measureOriginalsample  10855026 23003.654 ± 2286.571  ns/op
>>
>> Thanks,
>> Steven Davidovitz
>>
>> 1: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/daaace32c979
>>
>> diff --git a/src/java.base/share/classes/sun/security/ssl/SignatureAndH
>> ashAlgorithm.java
>> b/src/java.base/share/classes/sun/security/ssl/SignatureAndH
>> ashAlgorithm.java
>> --- a/src/java.base/share/classes/sun/security/ssl/SignatureAndH
>> ashAlgorithm.java
>> +++ b/src/java.base/share/classes/sun/security/ssl/SignatureAndH
>> ashAlgorithm.java
>> @@ -396,46 +396,42 @@
>>  }
>>
>>  static {
>> -supportedMap = Collections.synchronizedSortedMap(
>> -new TreeMap());
>> -priorityMap = Collections.synchronizedSortedMap(
>> -new TreeMap());
>> -
>> -synchronized (supportedMap) {
>> -int p = SUPPORTED_ALG_PRIORITY_MAX_NUM;
>> -supports(HashAlgorithm.MD5, SignatureAlgorithm.RSA,
>> -"MD5withRSA",   --p);
>> -supports(HashAlgorithm.SHA1,SignatureAlgorithm.DSA,
>> -"SHA1withDSA",  --p);
>> -supports(HashAlgorithm.SHA1,SignatureAlgorithm.RSA,
>> -"SHA1withRSA",  --p);
>> -supports(HashAlgorithm.SHA1,SignatureAlgorithm.ECDSA,
>> -"SHA1withECDSA",--p);
>> +supportedMap = new TreeMap();
>> +priorityMap = new TreeMap();
>>
>> -if (Security.getProvider("SunMSCAPI") == null) {
>> -supports(HashAlgorithm.SHA224,
>> SignatureAlgorithm.DSA,
>> -"SHA224withDSA",--p);
>> -supports(HashAlgorithm.SHA224,
>> SignatureAlgorithm.RSA,
>> -"SHA224withRSA",--p);
>> -supports(HashAlgorithm.SHA224,
>> SignatureAlgorithm.ECDSA,
>> -"SHA224withECDSA",  --p);
>> -}
>> +int p = SUPPORTED_ALG_PRIORITY_MAX_NUM;
>> +supports(HashAlgorithm.MD5, SignatureAlgorithm.RSA,
>> +"MD5withRSA",   --p);
>> +supports(HashAlgorithm.SHA1,SignatureAlgorithm.DSA,
>> +"SHA1withDSA",  --p);
>> +supports(HashAlgorithm.SHA1,SignatureAlgorithm.RSA,
>> +"SHA1withRSA",  --p);
>> +supports(HashAlgorithm.SHA1,SignatureAlgorithm.ECDSA,
>> +"SHA1withECDSA",--p);
>>
>> -supports(HashAlgorithm.SHA256,  SignatureAlgorithm.DSA,
>> -"SHA256withDSA",--p);
>> -supports(HashAlgorithm.SHA256,  SignatureAlgorithm.RSA,
>> -"SHA256withRSA",--p);
>> -supports(HashAlgorithm.SHA256,
>> SignatureAlgorithm.ECDSA,
>> -"SHA256withECDSA",  --p);
>> -supports(HashAlgorithm.SHA384,  SignatureAlgorithm.RSA,
>> -"SHA384withRSA",--p);
>> -supports(HashAlgorithm.SHA384,
>> SignatureAlgorithm.ECDSA,
>> -"SHA384withECDSA",  --p);
>> -supports(HashAlgorithm.SHA512,  SignatureAlgorithm.RSA,
>> -"SHA512withRSA",--p);
>> -supports(HashAlgorithm.SHA512,
>> SignatureAlgorithm.ECDSA,
>> -"SHA512withECDSA",  --p);
>> +if (Security.getProvider("SunMSCAPI") == null) {
>> +supports(HashAlgorithm.SHA224,  SignatureAlgorithm.DSA,
>> +"SHA224withDSA",--p);
>> +supports(HashAlgorithm.SHA224,  SignatureAlgorithm.RSA,
>> +"SHA224withRSA",--p);
>> +supports(HashAlgorithm.SHA224,
>> SignatureAlgorithm.ECDSA,
>> +"SHA224withECDSA",  --p);
>>  }
>> +
>> +supports(HashAlgorithm.SHA256,  SignatureAlgorithm.DSA,
>> +"SHA256withDSA",--p);
>> +supports(HashAlgorithm.SHA256,  SignatureAlgo