Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-17 Thread alexander stepanov 

Hello Joe,

 [jw] as I mentioned, pre/pre is needed for the code snippet.
Fixed, please see
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxp/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java.udiff.html

  [jw] I saw in a few cases where two @code tags are next to each other
Fixed in a couple of places.

Regards,
Alexander

On 16.04.2015 19:57, huizhe wang wrote:

Hi Alexander,

Looks very good. Thanks for making all the changes!

Please note that for the JAXWS, you may need to check with JAXWS/Miran 
(miroslav@oracle.com). Changes to JAXWS generally goes into the 
standalone first. They do periodic integration.


For the jaxp portion:
--- old/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.249473095 +0400
+++ new/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.161473099 +0400


@@ -725,37 +725,37 @@

  *
- * @return the relationship between codethis/code 
codeDuration/codeand codeduration/code parameter as
+ * @return the relationship between {@code this} {@code 
Duration}and {@code duration} parameter as


[jw] I saw in a few cases where two @code tags are next to each other, 
you may do a s/} {@code//g to combine them. A space is also missing 
before 'and': e.g. {@code Duration} and.



--- 
old/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.197472963 +0400
+++ 
new/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.105472967 +0400


@@ -542,7 +543,7 @@
* If the number of characters actually copied is less than the 
length, then there is no more text.
* Otherwise, subsequent calls need to be made until all text has 
been retrieved. For example:

*
-   *code
+   * {@code
* int length = 1024;
* char[] myBuffer = new char[ length ];
*
@@ -553,7 +554,7 @@
*   if (nCopied  length)
*   break;
* }
-   * /code
+   * }

[jw] as I mentioned, pre/pre is needed for the code snippet.


BTW, have you compiled and verified the Javadoc after the changes?

Thanks,
Joe

On 4/16/2015 7:07 AM, alexander stepanov wrote:

I'm sorry, two extra files touched -
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html 



Hopefully that's all for this bug...

Thanks,
Alexander

On 16.04.2015 15:48, alexander stepanov wrote:

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 



On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary 
/p, used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd 
date every time the sources were touched (but that may be a 
question of ambiguous interpretation).


But of course I can easily revert these changes if you're 
totally sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been 
optional. I think the original assumption was that the 
update_copyright_year script (in the top-level repo) be run 
periodically to do bulk updates. Unfortunately that script 
doesn't seem to be run very often now and this strengthens the 
case to update the dates on a continuous basis. I have not come 
across the argument that html tidy tasks that don't change the 
javadoc should not update the copyright date. The general topic 
probably should move to jdk9-dev and get this decided once and 
documented in the developer guide.


I think the key question to ask is: is this the code I can claim 
Copyright with? To me, format, code style, html tags and other 
minor changes, these are not code changes one can claim

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-17 Thread huizhe wang 

Hi Alexander,

That fixed the issue in the existing Javadoc. The JAXP changes look good 
now.


Thanks for doing this!

Best,
Joe

On 4/17/2015 4:36 AM, alexander stepanov wrote:

Hello Joe,

 [jw] as I mentioned, pre/pre is needed for the code snippet.
Fixed, please see
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxp/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java.udiff.html 



  [jw] I saw in a few cases where two @code tags are next to each other
Fixed in a couple of places.

Regards,
Alexander

On 16.04.2015 19:57, huizhe wang wrote:

Hi Alexander,

Looks very good. Thanks for making all the changes!

Please note that for the JAXWS, you may need to check with 
JAXWS/Miran (miroslav@oracle.com). Changes to JAXWS generally 
goes into the standalone first. They do periodic integration.


For the jaxp portion:
--- old/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.249473095 +0400
+++ new/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.161473099 +0400


@@ -725,37 +725,37 @@

  *
- * @return the relationship between codethis/code 
codeDuration/codeand codeduration/code parameter as
+ * @return the relationship between {@code this} {@code 
Duration}and {@code duration} parameter as


[jw] I saw in a few cases where two @code tags are next to each 
other, you may do a s/} {@code//g to combine them. A space is also 
missing before 'and': e.g. {@code Duration} and.



--- 
old/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.197472963 +0400
+++ 
new/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.105472967 +0400


@@ -542,7 +543,7 @@
* If the number of characters actually copied is less than the 
length, then there is no more text.
* Otherwise, subsequent calls need to be made until all text has 
been retrieved. For example:

*
-   *code
+   * {@code
* int length = 1024;
* char[] myBuffer = new char[ length ];
*
@@ -553,7 +554,7 @@
*   if (nCopied  length)
*   break;
* }
-   * /code
+   * }

[jw] as I mentioned, pre/pre is needed for the code snippet.


BTW, have you compiled and verified the Javadoc after the changes?

Thanks,
Joe

On 4/16/2015 7:07 AM, alexander stepanov wrote:

I'm sorry, two extra files touched -
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html 



Hopefully that's all for this bug...

Thanks,
Alexander

On 16.04.2015 15:48, alexander stepanov wrote:

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 



On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary 
/p, used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd 
date every time the sources were touched (but that may be a 
question of ambiguous interpretation).


But of course I can easily revert these changes if you're 
totally sure it should be done.


This has always been confusing. Some areas insist on updating 
the copyright dates, others don't. AFAIK, it has always been 
optional. I think the original assumption was that the 
update_copyright_year script (in the top-level repo) be run 
periodically to do bulk updates. Unfortunately that script 
doesn't seem to be run very often now and this strengthens the 
case to update the dates on a continuous basis. I have not come 
across the argument that html tidy tasks that don't change the 
javadoc should not update the copyright date. The general topic 
probably should move to jdk9-dev and get this decided once and 
documented in the developer guide.


I

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-17 Thread alexander stepanov 

Thanks!

Regards,
Alexander

On 17.04.2015 19:33, huizhe wang wrote:

Hi Alexander,

That fixed the issue in the existing Javadoc. The JAXP changes look 
good now.


Thanks for doing this!

Best,
Joe

On 4/17/2015 4:36 AM, alexander stepanov wrote:

Hello Joe,

 [jw] as I mentioned, pre/pre is needed for the code snippet.
Fixed, please see
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxp/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java.udiff.html 



  [jw] I saw in a few cases where two @code tags are next to each other
Fixed in a couple of places.

Regards,
Alexander

On 16.04.2015 19:57, huizhe wang wrote:

Hi Alexander,

Looks very good. Thanks for making all the changes!

Please note that for the JAXWS, you may need to check with 
JAXWS/Miran (miroslav@oracle.com). Changes to JAXWS generally 
goes into the standalone first. They do periodic integration.


For the jaxp portion:
--- old/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.249473095 +0400
+++ new/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.161473099 +0400


@@ -725,37 +725,37 @@

  *
- * @return the relationship between codethis/code 
codeDuration/codeand codeduration/code parameter as
+ * @return the relationship between {@code this} {@code 
Duration}and {@code duration} parameter as


[jw] I saw in a few cases where two @code tags are next to each 
other, you may do a s/} {@code//g to combine them. A space is also 
missing before 'and': e.g. {@code Duration} and.



--- 
old/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.197472963 +0400
+++ 
new/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.105472967 +0400


@@ -542,7 +543,7 @@
* If the number of characters actually copied is less than the 
length, then there is no more text.
* Otherwise, subsequent calls need to be made until all text has 
been retrieved. For example:

*
-   *code
+   * {@code
* int length = 1024;
* char[] myBuffer = new char[ length ];
*
@@ -553,7 +554,7 @@
*   if (nCopied  length)
*   break;
* }
-   * /code
+   * }

[jw] as I mentioned, pre/pre is needed for the code snippet.


BTW, have you compiled and verified the Javadoc after the changes?

Thanks,
Joe

On 4/16/2015 7:07 AM, alexander stepanov wrote:

I'm sorry, two extra files touched -
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html 



Hopefully that's all for this bug...

Thanks,
Alexander

On 16.04.2015 15:48, alexander stepanov wrote:

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 



On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary 
/p, used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd 
date every time the sources were touched (but that may be a 
question of ambiguous interpretation).


But of course I can easily revert these changes if you're 
totally sure it should be done.


This has always been confusing. Some areas insist on updating 
the copyright dates, others don't. AFAIK, it has always been 
optional. I think the original assumption was that the 
update_copyright_year script (in the top-level repo) be run 
periodically to do bulk updates. Unfortunately that script 
doesn't seem to be run very often now and this strengthens the 
case to update the dates on a continuous basis. I have not come 
across the argument that html tidy tasks that don't change the 
javadoc should not update the copyright date. The general topic 
probably should move to jdk9-dev and

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-16 Thread alexander stepanov 

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html


On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary /p, 
used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd date 
every time the sources were touched (but that may be a question of 
ambiguous interpretation).


But of course I can easily revert these changes if you're totally 
sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been optional. I 
think the original assumption was that the update_copyright_year 
script (in the top-level repo) be run periodically to do bulk 
updates. Unfortunately that script doesn't seem to be run very often 
now and this strengthens the case to update the dates on a 
continuous basis. I have not come across the argument that html tidy 
tasks that don't change the javadoc should not update the copyright 
date. The general topic probably should move to jdk9-dev and get 
this decided once and documented in the developer guide.


I think the key question to ask is: is this the code I can claim 
Copyright with? To me, format, code style, html tags and other minor 
changes, these are not code changes one can claim copyright with.


The date of a Copyright establishes how far back the claim is made. 
In case where the work is substantially revised, a new Copyright 
claim is established, which is what the 2nd year is about.


In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd 
like to see the years maintained because those are the years the API 
was designed and modified. The tidy warnings change did not change 
the API.


-Joe



-Alan

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-16 Thread alexander stepanov 

I'm sorry, two extra files touched -
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html

Hopefully that's all for this bug...

Thanks,
Alexander

On 16.04.2015 15:48, alexander stepanov wrote:

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 



On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary /p, 
used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd date 
every time the sources were touched (but that may be a question of 
ambiguous interpretation).


But of course I can easily revert these changes if you're totally 
sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been optional. 
I think the original assumption was that the update_copyright_year 
script (in the top-level repo) be run periodically to do bulk 
updates. Unfortunately that script doesn't seem to be run very 
often now and this strengthens the case to update the dates on a 
continuous basis. I have not come across the argument that html 
tidy tasks that don't change the javadoc should not update the 
copyright date. The general topic probably should move to jdk9-dev 
and get this decided once and documented in the developer guide.


I think the key question to ask is: is this the code I can claim 
Copyright with? To me, format, code style, html tags and other minor 
changes, these are not code changes one can claim copyright with.


The date of a Copyright establishes how far back the claim is made. 
In case where the work is substantially revised, a new Copyright 
claim is established, which is what the 2nd year is about.


In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd 
like to see the years maintained because those are the years the API 
was designed and modified. The tidy warnings change did not change 
the API.


-Joe



-Alan

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-16 Thread alexander stepanov 

Hello Joe,

Thanks!

 as I mentioned, pre/pre is needed for the code snippet.
Oh, yes, that was that was forgotten.

 BTW, have you compiled
Yes; some javadoc errors were fixed as well

 and verified the Javadoc after the changes?
Only briefly. So as the above example shows I have to look it over once 
again (at least for files where the changes weren't trivial); will do that.


 Please note that for the JAXWS, you may need to check with JAXWS/Miran
Yes, I'll contact him, thanks.

Regards,
Alexander

On 16.04.2015 19:57, huizhe wang wrote:

Hi Alexander,

Looks very good. Thanks for making all the changes!

Please note that for the JAXWS, you may need to check with JAXWS/Miran 
(miroslav@oracle.com). Changes to JAXWS generally goes into the 
standalone first. They do periodic integration.


For the jaxp portion:
--- old/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.249473095 +0400
+++ new/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.161473099 +0400


@@ -725,37 +725,37 @@

  *
- * @return the relationship between codethis/code 
codeDuration/codeand codeduration/code parameter as
+ * @return the relationship between {@code this} {@code 
Duration}and {@code duration} parameter as


[jw] I saw in a few cases where two @code tags are next to each other, 
you may do a s/} {@code//g to combine them. A space is also missing 
before 'and': e.g. {@code Duration} and.



--- 
old/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.197472963 +0400
+++ 
new/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.105472967 +0400


@@ -542,7 +543,7 @@
* If the number of characters actually copied is less than the 
length, then there is no more text.
* Otherwise, subsequent calls need to be made until all text has 
been retrieved. For example:

*
-   *code
+   * {@code
* int length = 1024;
* char[] myBuffer = new char[ length ];
*
@@ -553,7 +554,7 @@
*   if (nCopied  length)
*   break;
* }
-   * /code
+   * }

[jw] as I mentioned, pre/pre is needed for the code snippet.


BTW, have you compiled and verified the Javadoc after the changes?

Thanks,
Joe

On 4/16/2015 7:07 AM, alexander stepanov wrote:

I'm sorry, two extra files touched -
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html 



Hopefully that's all for this bug...

Thanks,
Alexander

On 16.04.2015 15:48, alexander stepanov wrote:

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 



On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary 
/p, used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd 
date every time the sources were touched (but that may be a 
question of ambiguous interpretation).


But of course I can easily revert these changes if you're 
totally sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been 
optional. I think the original assumption was that the 
update_copyright_year script (in the top-level repo) be run 
periodically to do bulk updates. Unfortunately that script 
doesn't seem to be run very often now and this strengthens the 
case to update the dates on a continuous basis. I have not come 
across the argument that html tidy tasks that don't change the 
javadoc should not update the copyright date. The general topic 
probably should move to jdk9-dev and get this decided once and 
documented in the developer guide.


I think the key question to ask

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-16 Thread alexander stepanov 

Hello Lance,

Thanks.

Regards,
Alexander

On 16.04.2015 19:58, Lance Andersen wrote:

Hi Alexander,

These seem to be OK

Best
Lance
On Apr 16, 2015, at 10:07 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



I'm sorry, two extra files touched -
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html

Hopefully that's all for this bug...

Thanks,
Alexander

On 16.04.2015 15:48, alexander stepanov wrote:

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 



On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary 
/p, used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd 
date every time the sources were touched (but that may be a 
question of ambiguous interpretation).


But of course I can easily revert these changes if you're 
totally sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been 
optional. I think the original assumption was that the 
update_copyright_year script (in the top-level repo) be run 
periodically to do bulk updates. Unfortunately that script 
doesn't seem to be run very often now and this strengthens the 
case to update the dates on a continuous basis. I have not come 
across the argument that html tidy tasks that don't change the 
javadoc should not update the copyright date. The general topic 
probably should move to jdk9-dev and get this decided once and 
documented in the developer guide.


I think the key question to ask is: is this the code I can claim 
Copyright with? To me, format, code style, html tags and other 
minor changes, these are not code changes one can claim copyright 
with.


The date of a Copyright establishes how far back the claim is 
made. In case where the work is substantially revised, a new 
Copyright claim is established, which is what the 2nd year is about.


In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd 
like to see the years maintained because those are the years the 
API was designed and modified. The tidy warnings change did not 
change the API.


-Joe



-Alan










http://oracle.com/us/design/oracle-email-sig-198324.gif
http://oracle.com/us/design/oracle-email-sig-198324.gifhttp://oracle.com/us/design/oracle-email-sig-198324.gif
http://oracle.com/us/design/oracle-email-sig-198324.gifLance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com mailto:lance.ander...@oracle.com

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-16 Thread huizhe wang 

Hi Alexander,

Looks very good. Thanks for making all the changes!

Please note that for the JAXWS, you may need to check with JAXWS/Miran 
(miroslav@oracle.com). Changes to JAXWS generally goes into the 
standalone first. They do periodic integration.


For the jaxp portion:
--- old/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.249473095 +0400
+++ new/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.161473099 +0400


@@ -725,37 +725,37 @@

  *
- * @return the relationship between codethis/code 
codeDuration/codeand codeduration/code parameter as
+ * @return the relationship between {@code this} {@code 
Duration}and {@code duration} parameter as


[jw] I saw in a few cases where two @code tags are next to each other, 
you may do a s/} {@code//g to combine them. A space is also missing 
before 'and': e.g. {@code Duration} and.



--- old/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.197472963 +0400
+++ new/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.105472967 +0400


@@ -542,7 +543,7 @@
* If the number of characters actually copied is less than the 
length, then there is no more text.
* Otherwise, subsequent calls need to be made until all text has 
been retrieved. For example:

*
-   *code
+   * {@code
* int length = 1024;
* char[] myBuffer = new char[ length ];
*
@@ -553,7 +554,7 @@
*   if (nCopied  length)
*   break;
* }
-   * /code
+   * }

[jw] as I mentioned, pre/pre is needed for the code snippet.


BTW, have you compiled and verified the Javadoc after the changes?

Thanks,
Joe

On 4/16/2015 7:07 AM, alexander stepanov wrote:

I'm sorry, two extra files touched -
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html 



Hopefully that's all for this bug...

Thanks,
Alexander

On 16.04.2015 15:48, alexander stepanov wrote:

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 



On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary 
/p, used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd 
date every time the sources were touched (but that may be a 
question of ambiguous interpretation).


But of course I can easily revert these changes if you're totally 
sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been optional. 
I think the original assumption was that the update_copyright_year 
script (in the top-level repo) be run periodically to do bulk 
updates. Unfortunately that script doesn't seem to be run very 
often now and this strengthens the case to update the dates on a 
continuous basis. I have not come across the argument that html 
tidy tasks that don't change the javadoc should not update the 
copyright date. The general topic probably should move to jdk9-dev 
and get this decided once and documented in the developer guide.


I think the key question to ask is: is this the code I can claim 
Copyright with? To me, format, code style, html tags and other 
minor changes, these are not code changes one can claim copyright 
with.


The date of a Copyright establishes how far back the claim is made. 
In case where the work is substantially revised, a new Copyright 
claim is established, which is what the 2nd year is about.


In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd 
like to see the years maintained because those are the years the 
API was designed and modified. The tidy warnings

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-16 Thread Lance Andersen 
Hi Alexander,

These seem to be OK

Best
Lance
On Apr 16, 2015, at 10:07 AM, alexander stepanov 
alexander.v.stepa...@oracle.com wrote:

 I'm sorry, two extra files touched -
 http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html
 http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html
 
 Hopefully that's all for this bug...
 
 Thanks,
 Alexander
 
 On 16.04.2015 15:48, alexander stepanov wrote:
 Please note also that a couple of new files were touched:
 
 http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html
  
 http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html
  
 http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html
  
 http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html
  
 
 On 15.04.2015 19:12, alexander stepanov wrote:
 Hello Joe,
 
 The copyright changes were reverted.
 
 Please review the updated fix:
 http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/
 
 (code/code replaced with {@code}, removed unnecessary /p, used 
 @literal tag).
 
 Thanks,
 Alexander
 
 
 On 13.04.2015 21:19, huizhe wang wrote:
 
 On 4/13/2015 4:42 AM, Alan Bateman wrote:
 On 13/04/2015 12:22, alexander stepanov wrote:
 Hello Joe,
 
 Thank you for the notes;
 
  Copyright year shall not be changed.
 
 That seems to be a bit controversial point; sometimes (while cleaning 
 docs) I was asked to do that, other times - not to do that. Our internal 
 policy seemingly assigns to change the 2nd date every time the sources 
 were touched (but that may be a question of ambiguous interpretation).
 
 But of course I can easily revert these changes if you're totally sure 
 it should be done.
 
 This has always been confusing. Some areas insist on updating the 
 copyright dates, others don't. AFAIK, it has always been optional. I 
 think the original assumption was that the update_copyright_year script 
 (in the top-level repo) be run periodically to do bulk updates. 
 Unfortunately that script doesn't seem to be run very often now and this 
 strengthens the case to update the dates on a continuous basis. I have 
 not come across the argument that html tidy tasks that don't change the 
 javadoc should not update the copyright date. The general topic probably 
 should move to jdk9-dev and get this decided once and documented in the 
 developer guide.
 
 I think the key question to ask is: is this the code I can claim Copyright 
 with? To me, format, code style, html tags and other minor changes, these 
 are not code changes one can claim copyright with.
 
 The date of a Copyright establishes how far back the claim is made. In 
 case where the work is substantially revised, a new Copyright claim is 
 established, which is what the 2nd year is about.
 
 In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd like to 
 see the years maintained because those are the years the API was designed 
 and modified. The tidy warnings change did not change the API.
 
 -Joe
 
 
 -Alan
 
 
 
 



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-15 Thread alexander stepanov 

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary /p, 
used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do that. 
Our internal policy seemingly assigns to change the 2nd date every 
time the sources were touched (but that may be a question of 
ambiguous interpretation).


But of course I can easily revert these changes if you're totally 
sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been optional. I 
think the original assumption was that the update_copyright_year 
script (in the top-level repo) be run periodically to do bulk 
updates. Unfortunately that script doesn't seem to be run very often 
now and this strengthens the case to update the dates on a continuous 
basis. I have not come across the argument that html tidy tasks that 
don't change the javadoc should not update the copyright date. The 
general topic probably should move to jdk9-dev and get this decided 
once and documented in the developer guide.


I think the key question to ask is: is this the code I can claim 
Copyright with? To me, format, code style, html tags and other minor 
changes, these are not code changes one can claim copyright with.


The date of a Copyright establishes how far back the claim is made. In 
case where the work is substantially revised, a new Copyright claim is 
established, which is what the 2nd year is about.


In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd 
like to see the years maintained because those are the years the API 
was designed and modified. The tidy warnings change did not change 
the API.


-Joe



-Alan

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-13 Thread huizhe wang 


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while cleaning 
docs) I was asked to do that, other times - not to do that. Our 
internal policy seemingly assigns to change the 2nd date every time 
the sources were touched (but that may be a question of ambiguous 
interpretation).


But of course I can easily revert these changes if you're totally 
sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been optional. I 
think the original assumption was that the update_copyright_year 
script (in the top-level repo) be run periodically to do bulk updates. 
Unfortunately that script doesn't seem to be run very often now and 
this strengthens the case to update the dates on a continuous basis. I 
have not come across the argument that html tidy tasks that don't 
change the javadoc should not update the copyright date. The general 
topic probably should move to jdk9-dev and get this decided once and 
documented in the developer guide.


I think the key question to ask is: is this the code I can claim 
Copyright with? To me, format, code style, html tags and other minor 
changes, these are not code changes one can claim copyright with.


The date of a Copyright establishes how far back the claim is made. In 
case where the work is substantially revised, a new Copyright claim is 
established, which is what the 2nd year is about.


In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd like 
to see the years maintained because those are the years the API was 
designed and modified. The tidy warnings change did not change the API.


-Joe



-Alan

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-13 Thread alexander stepanov 

Thanks!

On 10.04.2015 20:07, Sean Mullan wrote:

On 04/10/2015 12:01 PM, Alan Bateman wrote:

On 10/04/2015 16:50, alexander stepanov wrote:

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8077332/

for
https://bugs.openjdk.java.net/browse/JDK-8077332

Some HTML cleanup for docs.

cc'ing security-dev as that is where the XML-DSIG code is maintained.


The DSig changes look fine.

--Sean

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-13 Thread Alan Bateman 

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while cleaning 
docs) I was asked to do that, other times - not to do that. Our 
internal policy seemingly assigns to change the 2nd date every time 
the sources were touched (but that may be a question of ambiguous 
interpretation).


But of course I can easily revert these changes if you're totally sure 
it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been optional. I 
think the original assumption was that the update_copyright_year script 
(in the top-level repo) be run periodically to do bulk updates. 
Unfortunately that script doesn't seem to be run very often now and this 
strengthens the case to update the dates on a continuous basis. I have 
not come across the argument that html tidy tasks that don't change the 
javadoc should not update the copyright date. The general topic probably 
should move to jdk9-dev and get this decided once and documented in the 
developer guide.


-Alan

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-13 Thread alexander stepanov 

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while cleaning 
docs) I was asked to do that, other times - not to do that. Our internal 
policy seemingly assigns to change the 2nd date every time the sources 
were touched (but that may be a question of ambiguous interpretation).


But of course I can easily revert these changes if you're totally sure 
it should be done.


Regards,
Alexander.


On 10.04.2015 21:27, huizhe wang wrote:

Hi Alexander,

First of all, there's no code change in this webrev, the copyright 
year should not be changed.


I see that in some cases, you removed /p, in a lot more cases 
though, you didn't, for example,

- * Return day in month or {@link 
DatatypeConstants#FIELD_UNDEFINED}./p
+ * Return day in month or {@link DatatypeConstants#FIELD_UNDEFINED}.
   *
   * pValue constraints for this value are summarized in
   * a href=#datetimefield-dayday field of date/time field mapping 
table/a./p

I suggest you do a global substitution for each of the classes.

As Roger suggested in the previous view, {@code } is preferable to 
code... /code. This can be a couple of global substitutions as 
well (s/code/{@code /g and s/\/code/}/g), An example is the 
following change:

+++ new/src/java.xml/share/classes/javax/xml/datatype/DatatypeFactory.java  
2015-04-10 19:59:29.427759390 +0400

@@ -787,7 +786,7 @@
   * /tr
   * tr
   *   td
- * code(ZONE_OFFSET + DST_OFFSET) / (60*1000)/codebr/
+ * code(ZONE_OFFSET + DST_OFFSET) / (60*1000)/codebr

Note also at line 35, the s was outside of markup:
  * Factory that creates new codejavax.xml.datatype/code codeObject/codes that map 
XML to/from Java codeObject/codes.

+++ new/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-10 19:59:29.807759373 +0400
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2003, 2006, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved.

*(JW) Copyright year shall not be changed.*

   *
- * pThe first five fields have non-negative (=0) integers or null
+ * pThe first five fields have non-negative (ge;0) integers or null

*(JW) Use {@literal }**instead.*

@@ -57,7 +57,7 @@
   *  liAlt;B (A is shorter than B)
   *  liAgt;B (A is longer than B)
   *  liA==B   (A and B are of the same duration)
- *  liAlt;B (Comparison between A and B is indeterminate)
+ *  liAlt;gt;B (Comparison between A and B is indeterminate)

*(JW) Use @literal instead.*

There are a lot more  being changed to lt;gt;, please use 
@literal or @code. @code is preferable if the content is presented in 
the code font.


   * pFor example, P1D (one day)  PT12H (12 hours) and

 *^ this one was missed by the way.*

- * P2Y (two years)  P23M (23 months)./p
+ * P2Y (two years) gt; P23M (23 months)./p

+++ new/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java
2015-04-10 19:59:32.027759273 +0400

@@ -542,7 +543,7 @@
 * If the number of characters actually copied is less than the length, 
then there is no more text.
 * Otherwise, subsequent calls need to be made until all text has been 
retrieved. For example:
 *
-   *code
+   * code
 * int length = 1024;
 * char[] myBuffer = new char[ length ];
 *
@@ -550,7 +551,7 @@
 * {
 *int nCopied = stream.getTextCharacters( sourceStart, myBuffer, 0, 
length );
 *
-   *   if (nCopied  length)
+   *   if (nCopied lt; length)
 *   break;
 * }
 * /code
(JW) after substituting code/code with {@code ...}, no need to 
change  to lt;

Please also add pre/pre to the code snippet.

- * pNormally, result tree serialization escapes  and  (and
+ * pNormally, result tree serialization escapes amp; and lt; (and

*(JW) use @literal for  as well.*

- * pUse a DOM node to create a new output target with the specified System 
ID.p
+ * pUse a DOM node to create a new output target with the specified System 
ID./p

*(JW) again, replace and remove all /p*


Thanks,
Joe


On 4/10/2015 8:50 AM, alexander stepanov wrote:

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8077332/

for
https://bugs.openjdk.java.net/browse/JDK-8077332

Some HTML cleanup for docs.

Thanks,
Alexander

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-13 Thread alexander stepanov 

Hello Alan,

Thank you.

Regards,
Alexander

On 10.04.2015 19:01, Alan Bateman wrote:

On 10/04/2015 16:50, alexander stepanov wrote:

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8077332/

for
https://bugs.openjdk.java.net/browse/JDK-8077332

Some HTML cleanup for docs.

cc'ing security-dev as that is where the XML-DSIG code is maintained.

I've also cc'ed Miroslav Kos as I think you'll need to work with him 
to get the JAX-WS and JAXB updated in the upstream repos. This is 
mostly just about ensuring that the changes in the jaxws repo don't 
get overridden at the next JAX-WS sync up.


-Alan