[9] RFR 8138838: docs cleanup for java.desktop

2015-10-14 Thread Alexander Stepanov 
Sorry, just a reminder. If the activity is untimely, then could you 
please review the following minimum part of fix?


http://cr.openjdk.java.net/~avstepan/8138838/webrev.min.00/index.html
(some misprints + midget JDK-8138893 fixed).

Thanks,
Alexander

On 10/5/2015 2:12 PM, Alexander Stepanov wrote:

Hello,

Could you please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8138838

Patch + webrev zipped + specdiff report:
http://cr.openjdk.java.net/~avstepan/8138838

Just some cosmetic changes for docs (... -> {@code ...} 
replacement) + some misprints fixed.


Not sure if these changes are desired at all for now.

Thanks,
Alexander

(Just in case, adding the prehistory and sending a copy to 
core-libs-dev).




On 10/1/2015 2:31 PM, Alexander Stepanov wrote:

Hello Martin, Stuart,

Thank you for the notes,

Yes, the initial utility is quite ugly, I just tried to prepare it as 
quickly as possible hoping that it covers the majority of "trivial" 
replace cases. Yes, it does not process multi-line  inclusions.


>  s = s.replace( "", tag1);
>  s = s.replace( "", tag1);
>  s = s.replace("", tag2);
>  s = s.replace("", tag2);

- replaced with "s = ln.replaceAll("(?i)", 
"").replaceAll("(?i)", "");"


Unfortunately my Perl/lisp knowledge are zero :)

> Should you publish your specdiff?  I guess not - it would be empty!
For now it contains a single fixed misprint diff, but there are a few 
another misprints at the moment which I'd like to include in the 
patch as well.


So if you don't have objections, I'll delay for a several days and 
then publish a final RFR (probably containing changes in some other 
repos like jaxws, corba or jaxp) which would be more formal 
(containing bug # and the final specdiff report).


Thanks again,
Alexander


On 10/1/2015 9:54 AM, Martin Buchholz wrote:

Hi s'marks,
You probably don't need to absolutify paths.
And you can easily handle multiple args.

(just for fun!)
Checks for javadoc comment; handles popular html entities; handles 
multiple lines; handles both tt and code:


#!/bin/bash
find "$@" -name '*.java' | \
  xargs -r perl -p0777i -e \
  'do {} while s~^ 
*\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)~$_=$2; 
s///g; s//&/g; "{\@code $_}"~mgie'



On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks 
<stuart.ma...@oracle.com <mailto:stuart.ma...@oracle.com>> wrote:


Hi Alexander, Martin,

The challenge of Perl file slurping and Emacs one-liners was too
much to bear.

This is Java, so one-liners are hardly possible. Still, there are
a bunch of improvements that can be made to the Java version. (OK,
and I'm showing off a bit.)

Take a look at this:

http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java 
<http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java>


I haven't studied the output exhaustively, but it seems to do a
reasonably good job for the common cases. I ran it over java.lang
and I noticed a few cases where there is markup embedded within
 text, which should be looked at more closely.

I don't particularly care if you use my version, but there are
some techniques that I'd strongly recommend that you consider
using in any such tool. In particular:

 - Pattern.DOTALL to do multi-line matches
 - Pattern.CASE_INSENSITIVE
 - try-with-resources to ensure that files are closed properly
 - NIO instead of old java.io <http://java.io> APIs, particularly
Files.walk() and streams
 - use Scanner to deal with input file buffering
 - Scanner's stream support (I recently added this to JDK 9)

Enjoy,

s'marks



On 9/29/15 2:23 PM, Martin Buchholz wrote:

Hi Alexander,

your change looks good.  It's OK to have manual corrections
for automated
mega-changes like this, as long as they all revert changes.

Random comments:

Should you publish your specdiff?  I guess not - it would be
empty!

 while((s = br.readLine()) != null) {

by matching only one line at a time, you lose the ability to 
make

replacements that span lines.  Perlers like to "slurp" in the
entire file
as a single string.

 s = s.replace( "", tag1);
 s = s.replace( "", tag1);
 s = s.replace("", tag2);
 s = s.replace("", tag2);

Why not use case-insensitive regex?

Here's an emacs-lisp one-liner I've been known to use:

(defun tt-code ()
   (interactive)
   (query-replace-regexp
"<\\(tt\\|code\\)>\\([^&<>]+\\)" "{@code
\\2}"))

With more work, one can automate transformation

Re: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs

2015-10-05 Thread Alexander Stepanov 

Hello,

Could you please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8138838

Patch + webrev zipped + specdiff report:
http://cr.openjdk.java.net/~avstepan/8138838

Just some cosmetic changes for docs (... -> {@code ...} 
replacement) + some misprints fixed.


Not sure if these changes are desired at all for now.

Thanks,
Alexander

(Just in case, adding the prehistory and sending a copy to core-libs-dev).



On 10/1/2015 2:31 PM, Alexander Stepanov wrote:

Hello Martin, Stuart,

Thank you for the notes,

Yes, the initial utility is quite ugly, I just tried to prepare it as 
quickly as possible hoping that it covers the majority of "trivial" 
replace cases. Yes, it does not process multi-line  inclusions.


>  s = s.replace( "", tag1);
>  s = s.replace( "", tag1);
>  s = s.replace("", tag2);
>  s = s.replace("", tag2);

- replaced with "s = ln.replaceAll("(?i)", 
"").replaceAll("(?i)", "");"


Unfortunately my Perl/lisp knowledge are zero :)

> Should you publish your specdiff?  I guess not - it would be empty!
For now it contains a single fixed misprint diff, but there are a few 
another misprints at the moment which I'd like to include in the patch 
as well.


So if you don't have objections, I'll delay for a several days and 
then publish a final RFR (probably containing changes in some other 
repos like jaxws, corba or jaxp) which would be more formal 
(containing bug # and the final specdiff report).


Thanks again,
Alexander


On 10/1/2015 9:54 AM, Martin Buchholz wrote:

Hi s'marks,
You probably don't need to absolutify paths.
And you can easily handle multiple args.

(just for fun!)
Checks for javadoc comment; handles popular html entities; handles 
multiple lines; handles both tt and code:


#!/bin/bash
find "$@" -name '*.java' | \
  xargs -r perl -p0777i -e \
  'do {} while s~^ 
*\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)~$_=$2; 
s///g; s//&/g; "{\@code $_}"~mgie'



On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks 
<stuart.ma...@oracle.com <mailto:stuart.ma...@oracle.com>> wrote:


Hi Alexander, Martin,

The challenge of Perl file slurping and Emacs one-liners was too
much to bear.

This is Java, so one-liners are hardly possible. Still, there are
a bunch of improvements that can be made to the Java version. (OK,
and I'm showing off a bit.)

Take a look at this:

http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java 
<http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java>


I haven't studied the output exhaustively, but it seems to do a
reasonably good job for the common cases. I ran it over java.lang
and I noticed a few cases where there is markup embedded within
 text, which should be looked at more closely.

I don't particularly care if you use my version, but there are
some techniques that I'd strongly recommend that you consider
using in any such tool. In particular:

 - Pattern.DOTALL to do multi-line matches
 - Pattern.CASE_INSENSITIVE
 - try-with-resources to ensure that files are closed properly
 - NIO instead of old java.io <http://java.io> APIs, particularly
Files.walk() and streams
 - use Scanner to deal with input file buffering
 - Scanner's stream support (I recently added this to JDK 9)

Enjoy,

s'marks



On 9/29/15 2:23 PM, Martin Buchholz wrote:

Hi Alexander,

your change looks good.  It's OK to have manual corrections
for automated
mega-changes like this, as long as they all revert changes.

Random comments:

Should you publish your specdiff?  I guess not - it would be
empty!

 while((s = br.readLine()) != null) {

by matching only one line at a time, you lose the ability to 
make

replacements that span lines.  Perlers like to "slurp" in the
entire file
as a single string.

 s = s.replace( "", tag1);
 s = s.replace( "", tag1);
 s = s.replace("", tag2);
 s = s.replace("", tag2);

Why not use case-insensitive regex?

Here's an emacs-lisp one-liner I've been known to use:

(defun tt-code ()
   (interactive)
   (query-replace-regexp
"<\\(tt\\|code\\)>\\([^&<>]+\\)" "{@code
\\2}"))

With more work, one can automate transformation of embedded
things like 

But of course, it's not even possible to transform ALL uses of
 to
{@code, if there was imaginative use of nested html tags.


On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov <
alexander.v.stepa...@oracle.com
<mailto:alexa

[9] RFR 8138838: docs cleanup for java.desktop

2015-10-05 Thread Alexander Stepanov 

Sorry; wrong subject...

On 10/5/2015 2:12 PM, Alexander Stepanov wrote:

Hello,

Could you please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8138838

Patch + webrev zipped + specdiff report:
http://cr.openjdk.java.net/~avstepan/8138838

Just some cosmetic changes for docs (... -> {@code ...} 
replacement) + some misprints fixed.


Not sure if these changes are desired at all for now.

Thanks,
Alexander

(Just in case, adding the prehistory and sending a copy to 
core-libs-dev).




On 10/1/2015 2:31 PM, Alexander Stepanov wrote:

Hello Martin, Stuart,

Thank you for the notes,

Yes, the initial utility is quite ugly, I just tried to prepare it as 
quickly as possible hoping that it covers the majority of "trivial" 
replace cases. Yes, it does not process multi-line  inclusions.


>  s = s.replace( "", tag1);
>  s = s.replace( "", tag1);
>  s = s.replace("", tag2);
>  s = s.replace("", tag2);

- replaced with "s = ln.replaceAll("(?i)", 
"").replaceAll("(?i)", "");"


Unfortunately my Perl/lisp knowledge are zero :)

> Should you publish your specdiff?  I guess not - it would be empty!
For now it contains a single fixed misprint diff, but there are a few 
another misprints at the moment which I'd like to include in the 
patch as well.


So if you don't have objections, I'll delay for a several days and 
then publish a final RFR (probably containing changes in some other 
repos like jaxws, corba or jaxp) which would be more formal 
(containing bug # and the final specdiff report).


Thanks again,
Alexander


On 10/1/2015 9:54 AM, Martin Buchholz wrote:

Hi s'marks,
You probably don't need to absolutify paths.
And you can easily handle multiple args.

(just for fun!)
Checks for javadoc comment; handles popular html entities; handles 
multiple lines; handles both tt and code:


#!/bin/bash
find "$@" -name '*.java' | \
  xargs -r perl -p0777i -e \
  'do {} while s~^ 
*\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)~$_=$2; 
s///g; s//&/g; "{\@code $_}"~mgie'



On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks 
<stuart.ma...@oracle.com <mailto:stuart.ma...@oracle.com>> wrote:


Hi Alexander, Martin,

The challenge of Perl file slurping and Emacs one-liners was too
much to bear.

This is Java, so one-liners are hardly possible. Still, there are
a bunch of improvements that can be made to the Java version. (OK,
and I'm showing off a bit.)

Take a look at this:

http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java 
<http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java>


I haven't studied the output exhaustively, but it seems to do a
reasonably good job for the common cases. I ran it over java.lang
and I noticed a few cases where there is markup embedded within
 text, which should be looked at more closely.

I don't particularly care if you use my version, but there are
some techniques that I'd strongly recommend that you consider
using in any such tool. In particular:

 - Pattern.DOTALL to do multi-line matches
 - Pattern.CASE_INSENSITIVE
 - try-with-resources to ensure that files are closed properly
 - NIO instead of old java.io <http://java.io> APIs, particularly
Files.walk() and streams
 - use Scanner to deal with input file buffering
 - Scanner's stream support (I recently added this to JDK 9)

Enjoy,

s'marks



On 9/29/15 2:23 PM, Martin Buchholz wrote:

Hi Alexander,

your change looks good.  It's OK to have manual corrections
for automated
mega-changes like this, as long as they all revert changes.

Random comments:

Should you publish your specdiff?  I guess not - it would be
empty!

 while((s = br.readLine()) != null) {

by matching only one line at a time, you lose the ability to 
make

replacements that span lines.  Perlers like to "slurp" in the
entire file
as a single string.

 s = s.replace( "", tag1);
 s = s.replace( "", tag1);
 s = s.replace("", tag2);
 s = s.replace("", tag2);

Why not use case-insensitive regex?

Here's an emacs-lisp one-liner I've been known to use:

(defun tt-code ()
   (interactive)
   (query-replace-regexp
"<\\(tt\\|code\\)>\\([^&<>]+\\)" "{@code
\\2}"))

With more work, one can automate transformation of embedded
things like 

But of course, it's not even possible to transform ALL uses of
 to
{@code, if there was imaginative use of nested html tags.


On Tue, Sep 29, 2015 at 3:21 AM, Alexander

Re: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs

2015-10-01 Thread Alexander Stepanov 

Hello Martin, Stuart,

Thank you for the notes,

Yes, the initial utility is quite ugly, I just tried to prepare it as 
quickly as possible hoping that it covers the majority of "trivial" 
replace cases. Yes, it does not process multi-line  inclusions.


>  s = s.replace( "", tag1);
>  s = s.replace( "", tag1);
>  s = s.replace("", tag2);
>  s = s.replace("", tag2);

- replaced with "s = ln.replaceAll("(?i)", 
"").replaceAll("(?i)", "");"


Unfortunately my Perl/lisp knowledge are zero :)

> Should you publish your specdiff?  I guess not - it would be empty!
For now it contains a single fixed misprint diff, but there are a few 
another misprints at the moment which I'd like to include in the patch 
as well.


So if you don't have objections, I'll delay for a several days and then 
publish a final RFR (probably containing changes in some other repos 
like jaxws, corba or jaxp) which would be more formal (containing bug # 
and the final specdiff report).


Thanks again,
Alexander


On 10/1/2015 9:54 AM, Martin Buchholz wrote:

Hi s'marks,
You probably don't need to absolutify paths.
And you can easily handle multiple args.

(just for fun!)
Checks for javadoc comment; handles popular html entities; handles 
multiple lines; handles both tt and code:


#!/bin/bash
find "$@" -name '*.java' | \
  xargs -r perl -p0777i -e \
  'do {} while s~^ 
*\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)~$_=$2; 
s///g; s//&/g; "{\@code $_}"~mgie'



On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks <stuart.ma...@oracle.com 
<mailto:stuart.ma...@oracle.com>> wrote:


Hi Alexander, Martin,

The challenge of Perl file slurping and Emacs one-liners was too
much to bear.

This is Java, so one-liners are hardly possible. Still, there are
a bunch of improvements that can be made to the Java version. (OK,
and I'm showing off a bit.)

Take a look at this:

http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java 
<http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java>

I haven't studied the output exhaustively, but it seems to do a
reasonably good job for the common cases. I ran it over java.lang
and I noticed a few cases where there is markup embedded within
 text, which should be looked at more closely.

I don't particularly care if you use my version, but there are
some techniques that I'd strongly recommend that you consider
using in any such tool. In particular:

 - Pattern.DOTALL to do multi-line matches
 - Pattern.CASE_INSENSITIVE
 - try-with-resources to ensure that files are closed properly
 - NIO instead of old java.io <http://java.io> APIs, particularly
Files.walk() and streams
 - use Scanner to deal with input file buffering
 - Scanner's stream support (I recently added this to JDK 9)

Enjoy,

s'marks



On 9/29/15 2:23 PM, Martin Buchholz wrote:

Hi Alexander,

your change looks good.  It's OK to have manual corrections
for automated
mega-changes like this, as long as they all revert changes.

Random comments:

Should you publish your specdiff?  I guess not - it would be
empty!

 while((s = br.readLine()) != null) {

by matching only one line at a time, you lose the ability to make
replacements that span lines.  Perlers like to "slurp" in the
entire file
as a single string.

 s = s.replace( "", tag1);
 s = s.replace( "", tag1);
 s = s.replace("", tag2);
 s = s.replace("", tag2);

Why not use case-insensitive regex?

Here's an emacs-lisp one-liner I've been known to use:

(defun tt-code ()
   (interactive)
   (query-replace-regexp
"<\\(tt\\|code\\)>\\([^&<>]+\\)" "{@code
\\2}"))

With more work, one can automate transformation of embedded
things like 

But of course, it's not even possible to transform ALL uses of
 to
{@code, if there was imaginative use of nested html tags.


On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov <
alexander.v.stepa...@oracle.com
<mailto:alexander.v.stepa...@oracle.com>> wrote:

Updated: a few manual corrections were made (as @linkplain
tags displays
nested {@code } literally):
http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch 
<http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch>
-checked with specdiff (which of course does not cover
documentation for
internal packages), no unex

Re: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs

2015-10-01 Thread Alexander Stepanov 

Hello Lance,

Yes, to be honest, I also fear to push at once a single changeset for 
jdk touching thousands of files.


Moreover, I'm pretty sure that e.g. java.desktop part should go to a 
client repository instead of dev, changes for client and security libs 
should be approved by corresponding dev teams etc. Also, probably some 
of these cosmetic changes should be postponed for now to avoid potential 
merging issues for people who really do something valuable.


So I'll try to split the initial overall fix for jdk part into some 
reasonable amount of sub-tasks and send RFRs one by one, as earlier.


Thanks,
Alexander

On 10/1/2015 3:40 PM, Lance Andersen wrote:

Hi Alexander,

Personally, I would find it easier to review if the changes were sent 
out by category/module vs one large patch as it is easier to miss things.


Also for technologies such as jaxws, these will need to go to the 
external workspace at the same time for the technology so these should 
definitely be kept separate.


Best
Lance
On Oct 1, 2015, at 7:31 AM, Alexander Stepanov 
<alexander.v.stepa...@oracle.com 
<mailto:alexander.v.stepa...@oracle.com>> wrote:





So if you don't have objections, I'll delay for a several days and 
then publish a final RFR (probably containing changes in some other 
repos like jaxws, corba or jaxp) which would be more formal 
(containing bug # and the final specdiff report).


Thanks again,
Alexander


On 10/1/2015 9:54 AM, Martin Buchholz wrote:

Hi s'marks,
You probably don't need to absolutify paths.
And you can easily handle multiple args.

(just for fun!)
Checks for javadoc comment; handles popular html entities; handles 
multiple lines; handles both tt and code:


#!/bin/bash
find "$@" -name '*.java' | \
 xargs -r perl -p0777i -e \
 'do {} while s~^ 
*\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)~$_=$2; 
s///g; s//&/g; "{\@code $_}"~mgie'



On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks 
<stuart.ma...@oracle.com <mailto:stuart.ma...@oracle.com> 
<mailto:stuart.ma...@oracle.com>> wrote:


   Hi Alexander, Martin,

   The challenge of Perl file slurping and Emacs one-liners was too
   much to bear.

   This is Java, so one-liners are hardly possible. Still, there are
   a bunch of improvements that can be made to the Java version. (OK,
   and I'm showing off a bit.)

   Take a look at this:

http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java 
<http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java> 
<http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java>


   I haven't studied the output exhaustively, but it seems to do a
   reasonably good job for the common cases. I ran it over java.lang
   and I noticed a few cases where there is markup embedded within
text, which should be looked at more closely.

   I don't particularly care if you use my version, but there are
   some techniques that I'd strongly recommend that you consider
   using in any such tool. In particular:

- Pattern.DOTALL to do multi-line matches
- Pattern.CASE_INSENSITIVE
- try-with-resources to ensure that files are closed properly
- NIO instead of old java.io <http://java.io> APIs, particularly
   Files.walk() and streams
- use Scanner to deal with input file buffering
- Scanner's stream support (I recently added this to JDK 9)

   Enjoy,

   s'marks



   On 9/29/15 2:23 PM, Martin Buchholz wrote:

   Hi Alexander,

   your change looks good.  It's OK to have manual corrections
   for automated
   mega-changes like this, as long as they all revert changes.

   Random comments:

   Should you publish your specdiff?  I guess not - it would be
   empty!

while((s = br.readLine()) != null) {

   by matching only one line at a time, you lose the ability to make
   replacements that span lines.  Perlers like to "slurp" in the
   entire file
   as a single string.

s = s.replace( "", tag1);
s = s.replace( "", tag1);
s = s.replace("", tag2);
s = s.replace("", tag2);

   Why not use case-insensitive regex?

   Here's an emacs-lisp one-liner I've been known to use:

   (defun tt-code ()
  (interactive)
  (query-replace-regexp
   "<\\(tt\\|code\\)>\\([^&<>]+\\)" "{@code
   \\2}"))

   With more work, one can automate transformation of embedded
   things like 

   But of course, it's not even possible to transform ALL uses of
to
   {@code, if there was imaginative use of nested html tags.


   On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov <
alexander.v.stepa...@oracle.com <mailto:alexander.v.stepa...@oracle.com>
   <mailto:alexander.v.stepa...@oracle.com>> wrote

Re: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs

2015-09-29 Thread Alexander Stepanov 
Updated: a few manual corrections were made (as @linkplain tags displays 
nested {@code } literally):

http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
-checked with specdiff (which of course does not cover documentation for 
internal packages), no unexpected diffs detected.


Regards,
Alexander

On 9/27/2015 4:52 PM, Alexander Stepanov wrote:

Hello Martin,

Here is some simple app. to replace  tags with a new-style {@code 
} one (which is definitely not so elegant as the Perl one-liners):
http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java

Corresponding patch for jdk and replacement log (~62k of the tag changes):
http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log
(sorry, I have to check the correctness of the patch with specdiff yet, so this 
is rather demo at the moment).

Don't know if these changes (cosmetic by nature) are desired for now or not. Moreover, probably some 
part of them should go to another repos (e.g., awt, swing -> "client" instead of 
"dev").

Regards,
Alexander



- Исходное сообщение -
От: alexander.v.stepa...@oracle.com
Кому: marti...@google.com
Копия: core-libs-dev@openjdk.java.net
Отправленные: Четверг, 24 Сентябрь 2015 г 16:06:56 GMT +03:00 Москва, 
Санкт-Петербург, Волгоград
Тема: Re: RFR [9] 8133651: replace some  tags (obsolete in html5) in 
core-libs docs

Hello Martin,

Thank you for review and for the notes!

  > I'm biased of course, but I like the approach I took with
blessed-modifier-order:
  > - make the change completely automated
  > - leave "human editing" for a separate change
  > - publish the code used to make the automated change (in my case,
typically a perl one-liner)

Automated replacement has an obvious advantage: it is fast and massive.
But there are some disadvantages at the same time (just IMHO).

Using script it is quite easy to miss some not very trivial cases, e.g.:
- remove unnecessary linebreaks, like
   * someCode
   * 
(which would be better to replace with single-line {@code someCode};
- joining of successive terms, like "ONE, TWO,
THREE" -> "{@code ONE, TWO, THREE}";
- errors like extra or missing "" or "": * Collection
T>", - there were a lot of them;
- some cases when  should be replaced with , not
{@code } (e.g. because of unicode characters inside of code etc.);
- extra tags inside of  or  which should be moved outside of
{@code }, like someCode or someCode;
- simple removing of needless tags, like "{@link ...}" ->
"{@link ...}";
- replace HTML codes with symbols ('<', '>', '@', ...)
- etc.
- plus some other formatting changes and fixes for misprints which would
be omitted during the automated replacement (and wouldn't be done in
future manually because there is no motivation for repeated processing).

So sometimes it may be difficult to say where is the border between
"trivial" and "human-editing" cases (and the portion of "non-trivial
cases" is definitely not minor); moreover, even the automated
replacement requires the subsequent careful review before publishing of
webrev (as well as by reviewers who probably wouldn't be happy to review
hundreds of files at the same time) and iterative checks/corrections.
specdiff is very useful for this task but also cannot fully cover the
diffs (as some changes are situated in the internal com/... sun/...
packages).

Moreover, I'm sure that some reviewers would be annoyed with the fact
that some (quite simple) changes were postponed because they are "not
too trivial to be fixed just now" (because they will suspect they would
be postponed forever). So the patch creator would (probably) receive
some advices during the review like "please fix also fix this and that"
(which is normal, of course).

So my preference was to make the changes package by package (in some
reasonable amount of files) not postponing part of the changes for the
future (sorry for these boring repeating review requests). Please note
that all the above mentioned is *rather explanation of my motivation
than objection* :) (and of course I used some text editor replace
automation which is surely not so advanced as Perl).

  > It's probably correct, but I would have left it out of this change
Yes, I see. Reverted (please update the web page):
http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html

Thanks,
Alexander

P.S. The  replacement job is mostly (I guess, ~80%) complete. But
probably this approach should be used if some similar replacement task
for, e.g.,  tags would be planned in future (there are
thousands of them).


On 9/24/2015 6:10 AM, Martin Buchholz wrote:


On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov
<alexander.v.stepa...@oracle.com
<mailto:alexander.v.stepa...@oracle.com>> wrote:

 Hello,

 Could you ple

Re: RFR [9] 8133651: replace some tags (obsolete in html5) in core-libs docs

2015-09-24 Thread Alexander Stepanov 

Hello Martin,

Thank you for review and for the notes!

> I'm biased of course, but I like the approach I took with 
blessed-modifier-order:

> - make the change completely automated
> - leave "human editing" for a separate change
> - publish the code used to make the automated change (in my case, 
typically a perl one-liner)


Automated replacement has an obvious advantage: it is fast and massive. 
But there are some disadvantages at the same time (just IMHO).


Using script it is quite easy to miss some not very trivial cases, e.g.:
- remove unnecessary linebreaks, like
 * someCode
 * 
(which would be better to replace with single-line {@code someCode};
- joining of successive terms, like "ONE, TWO, 
THREE" -> "{@code ONE, TWO, THREE}";
- errors like extra or missing "" or "": * Collection 
T>", - there were a lot of them;
- some cases when  should be replaced with , not 
{@code } (e.g. because of unicode characters inside of code etc.);
- extra tags inside of  or  which should be moved outside of 
{@code }, like someCode or someCode;
- simple removing of needless tags, like "{@link ...}" -> 
"{@link ...}";

- replace HTML codes with symbols ('<', '>', '@', ...)
- etc.
- plus some other formatting changes and fixes for misprints which would 
be omitted during the automated replacement (and wouldn't be done in 
future manually because there is no motivation for repeated processing).


So sometimes it may be difficult to say where is the border between 
"trivial" and "human-editing" cases (and the portion of "non-trivial 
cases" is definitely not minor); moreover, even the automated 
replacement requires the subsequent careful review before publishing of 
webrev (as well as by reviewers who probably wouldn't be happy to review 
hundreds of files at the same time) and iterative checks/corrections. 
specdiff is very useful for this task but also cannot fully cover the 
diffs (as some changes are situated in the internal com/... sun/... 
packages).


Moreover, I'm sure that some reviewers would be annoyed with the fact 
that some (quite simple) changes were postponed because they are "not 
too trivial to be fixed just now" (because they will suspect they would 
be postponed forever). So the patch creator would (probably) receive 
some advices during the review like "please fix also fix this and that" 
(which is normal, of course).


So my preference was to make the changes package by package (in some 
reasonable amount of files) not postponing part of the changes for the 
future (sorry for these boring repeating review requests). Please note 
that all the above mentioned is *rather explanation of my motivation 
than objection* :) (and of course I used some text editor replace 
automation which is surely not so advanced as Perl).


> It's probably correct, but I would have left it out of this change
Yes, I see. Reverted (please update the web page):
http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html

Thanks,
Alexander

P.S. The  replacement job is mostly (I guess, ~80%) complete. But 
probably this approach should be used if some similar replacement task 
for, e.g.,  tags would be planned in future (there are 
thousands of them).



On 9/24/2015 6:10 AM, Martin Buchholz wrote:



On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov 
<alexander.v.stepa...@oracle.com 
<mailto:alexander.v.stepa...@oracle.com>> wrote:


Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/
<http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/>
http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html
<http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html>
for
https://bugs.openjdk.java.net/browse/JDK-8133651

Just another portion of deprecated  (and ) tags replaced
with {@code }. Some misprints were also fixed.


I'm biased of course, but I like the approach I took with 
blessed-modifier-order:

- make the change completely automated
- leave "human editing" for a separate change
- publish the code used to make the automated change (in my case, 
typically a perl one-liner)



The following (expected) changes were detected by specdiff:
- removed needless dashes in java.util.Locale,
- removed needless curly brace in xml.bind.annotation.XmlElementRef


I would do a separate automated "removed needless dashes" changeset.


Please let me know if the following changes are desirable or not:

http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html

<http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html>


This is an actual change to the behavior of this code - the 
maintainers of jconsole need to approve it.  It's probably correct, 
but I would have left it out of this change. If you remove it, then I 
approve this change.

RFR [9] 8133651: replace some tags (obsolete in html5) in core-libs docs

2015-09-19 Thread Alexander Stepanov 

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/
http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html
for
https://bugs.openjdk.java.net/browse/JDK-8133651

Just another portion of deprecated  (and ) tags replaced with 
{@code }. Some misprints were also fixed.



The following (expected) changes were detected by specdiff:
- removed needless dashes in java.util.Locale,
- removed needless curly brace in xml.bind.annotation.XmlElementRef

Please let me know if the following changes are desirable or not:
http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html

Thanks,
Alexander

RFR [9] 8133650: replace some tags (obsolete in html5) in CORBA docs

2015-09-13 Thread Alexander Stepanov 

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133650/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8133650

Just another portion of deprecated  tags replaced with {@code }.

A single (expected) change was indicated by specdiff (in ORB.java).

Thanks,
Alexander

Re: RFR [9] 8133650: replace some tags (obsolete in html5) in CORBA docs

2015-09-13 Thread Alexander Stepanov 

Thanks!

Regards,
Alexander

On 9/13/2015 7:10 PM, Lance Andersen wrote:
I did not see any issues looking at the udiffs.  I assume based on 
your specdiff comment this should be good to go


On Sep 13, 2015, at 11:25 AM, Alexander Stepanov 
<alexander.v.stepa...@oracle.com 
<mailto:alexander.v.stepa...@oracle.com>> wrote:


http://cr.openjdk.java.net/~avstepan/8133650/webrev.00/ 
<http://cr.openjdk.java.net/%7Eavstepan/8133650/webrev.00/>


<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
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>

RFR [9] 8132478: [tidy] three new warnings from java docs (java.net, javax.annotation)

2015-08-18 Thread Alexander Stepanov 

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8132478/jdk.00/index.html
http://cr.openjdk.java.net/~avstepan/8132478/jaxws.00/index.html
for
https://bugs.openjdk.java.net/browse/JDK-8132478

Just a minor fix for docs (a few tidy warnings + some invalid tags).

Thanks,
Alexander

Re: RFR [9] 8132478: [tidy] three new warnings from java docs (java.net, javax.annotation)

2015-08-18 Thread Alexander Stepanov 

Hello Lance,

Thanks!

Regards,
Alexander

On 8/18/2015 2:56 PM, Lance @ Oracle wrote:

Hi Alexander

Looks ok but you will need to make sure the jaxws changes get pushed 
to the standalone project as well


Best,
Lance


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

Oracle Java Engineering
1 Network Drive x-apple-data-detectors://34/0
Burlington, MA 01803 x-apple-data-detectors://34/0
lance.ander...@oracle.com mailto:lance.ander...@oracle.com
Sent from my iPad

On Aug 18, 2015, at 7:50 AM, Alexander Stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8132478/jdk.00/index.html 
http://cr.openjdk.java.net/%7Eavstepan/8132478/jdk.00/index.html
http://cr.openjdk.java.net/~avstepan/8132478/jaxws.00/index.html 
http://cr.openjdk.java.net/%7Eavstepan/8132478/jaxws.00/index.html

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

Just a minor fix for docs (a few tidy warnings + some invalid tags).

Thanks,
Alexander

Re: RFR [9] 8133480: replace some tt tags (obsolete in html5) in core-libs docs

2015-08-14 Thread Alexander Stepanov 

Thanks!

Regards,
Alexander

On 8/13/2015 8:42 PM, Lance Andersen wrote:

looks OK.  Nothing obvious stands out.

Best
Lance
On Aug 13, 2015, at 10:42 AM, Alexander Stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133480/webrev.00 
http://cr.openjdk.java.net/%7Eavstepan/8133480/webrev.00

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

Just another portion of deprecated tt tags replaced with {@code }.
A single misprint was fixed; no other changes indicated by specdiff.

Thanks,
Alexander


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

RFR [9] 8133480: replace some tt tags (obsolete in html5) in core-libs docs

2015-08-13 Thread Alexander Stepanov 

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133480/webrev.00
for
https://bugs.openjdk.java.net/browse/JDK-8133480

Just another portion of deprecated tt tags replaced with {@code }.
A single misprint was fixed; no other changes indicated by specdiff.

Thanks,
Alexander

RFR [9] 8133459: replace tt tags (obsolete in html5) in java.nio docs

2015-08-12 Thread Alexander Stepanov 

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133459/webrev.00/index.html
for
https://bugs.openjdk.java.net/browse/JDK-8133459

Just a next portion of deprecated 'tt' tags replaced (didn't touch all 
these multiple 'nbsp;'s to avoid undesirable formatting changes).


specdiff did not detect any changes in java.nio.*

Regards,
Alexander

Re: RFR [9] 8133459: replace tt tags (obsolete in html5) in java.nio docs

2015-08-12 Thread Alexander Stepanov 

Hello Lance,

Thanks!

Regards,
Alexander

On 8/12/2015 7:41 PM, Lance Andersen wrote:

Hi Alexander,

Nothing seems amiss in the changes and you indicated the specdiff 
shows no issues so you should be good to go


Best
Lance
On Aug 12, 2015, at 11:46 AM, Alexander Stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133459/webrev.00/index.html 
http://cr.openjdk.java.net/%7Eavstepan/8133459/webrev.00/index.html

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

Just a next portion of deprecated 'tt' tags replaced (didn't touch 
all these multiple 'nbsp;'s to avoid undesirable formatting changes).


specdiff did not detect any changes in java.nio.*

Regards,
Alexander



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] 8133188: docs: replace tt tags (obsolete in html5) for java.util

2015-08-11 Thread Alexander Stepanov 

Hello Martin,

the changes were reverted for the following files:

java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
java.base/share/classes/java/util/AbstractQueue.java
java.base/share/classes/java/util/Deque.java
java.base/share/classes/java/util/NavigableMap.java
java.base/share/classes/java/util/NavigableSet.java

webrev updated:
http://cr.openjdk.java.net/~avstepan/8133188/webrev.02

specdiff report (please update the web page):
http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html
(the changes in concurrent are seemingly due to inherited documentation).

Regards,
Alexander

On 8/10/2015 5:28 PM, Martin Buchholz wrote:

Hi Alexander,

I've been hoping that someone does cleanups of the jdk as you are 
doing now.


Some of these source files are part of jsr166 and are maintained 
separately, in jsr166 CVS.

http://g.oswego.edu/dl/concurrency-interest/
And that has already been tt/code-cleaned (although it has been 
done slightly differently) and will be integrated into jdk9 in an 
upcoming merge.  So please leave out:

concurrent/
*Queue.java
*Deque.java
Navigable*.java

On Mon, Aug 10, 2015 at 6:39 AM, Alexander Stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:


Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133188/webrev.01
http://cr.openjdk.java.net/%7Eavstepan/8133188/webrev.01
for
https://bugs.openjdk.java.net/browse/JDK-8133188

Just a next portion of tt tags removed.

specdiff report:

http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html

http://cr.openjdk.java.net/%7Eavstepan/8133188/specdiff.util/overview-summary.html
 - some constructs like
tt(o==nullnbsp;?nbsp;e==nullnbsp;:nbsp;o.equals(e))/tt
were replaced with {@code Objects.equals(o, e)}
(e.g.,

http://cr.openjdk.java.net/~avstepan/8133188/webrev.01/src/java.base/share/classes/java/util/LinkedList.java.udiff.html

http://cr.openjdk.java.net/%7Eavstepan/8133188/webrev.01/src/java.base/share/classes/java/util/LinkedList.java.udiff.html);
- please see JDK-8133188 comments.

Thanks,
Alexander

Re: RFR [9] 8133188: docs: replace tt tags (obsolete in html5) for java.util

2015-08-11 Thread Alexander Stepanov 

Thanks!

Regards,
Alexander

On 8/11/2015 7:10 PM, Martin Buchholz wrote:

Thanks!   Looks good to me.

On Tue, Aug 11, 2015 at 4:33 AM, Alexander Stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:


Hello Martin,

the changes were reverted for the following files:

java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
java.base/share/classes/java/util/AbstractQueue.java
java.base/share/classes/java/util/Deque.java
java.base/share/classes/java/util/NavigableMap.java
java.base/share/classes/java/util/NavigableSet.java

webrev updated:
http://cr.openjdk.java.net/~avstepan/8133188/webrev.02
http://cr.openjdk.java.net/%7Eavstepan/8133188/webrev.02

specdiff report (please update the web page):

http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html

http://cr.openjdk.java.net/%7Eavstepan/8133188/specdiff.util/overview-summary.html
(the changes in concurrent are seemingly due to inherited
documentation).

Regards,
Alexander


On 8/10/2015 5:28 PM, Martin Buchholz wrote:

Hi Alexander,

I've been hoping that someone does cleanups of the jdk as you are
doing now.

Some of these source files are part of jsr166 and are maintained
separately, in jsr166 CVS.
http://g.oswego.edu/dl/concurrency-interest/
And that has already been tt/code-cleaned (although it has
been done slightly differently) and will be integrated into jdk9
in an upcoming merge.  So please leave out:
concurrent/
*Queue.java
*Deque.java
Navigable*.java

On Mon, Aug 10, 2015 at 6:39 AM, Alexander Stepanov
alexander.v.stepa...@oracle.com
mailto:alexander.v.stepa...@oracle.com wrote:

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133188/webrev.01
http://cr.openjdk.java.net/%7Eavstepan/8133188/webrev.01
for
https://bugs.openjdk.java.net/browse/JDK-8133188

Just a next portion of tt tags removed.

specdiff report:

http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html

http://cr.openjdk.java.net/%7Eavstepan/8133188/specdiff.util/overview-summary.html
 - some constructs like
tt(o==nullnbsp;?nbsp;e==nullnbsp;:nbsp;o.equals(e))/tt
were replaced with {@code Objects.equals(o, e)}
mailto:%7B@codeObjects.equals%28o,e%29%7D
(e.g.,

http://cr.openjdk.java.net/~avstepan/8133188/webrev.01/src/java.base/share/classes/java/util/LinkedList.java.udiff.html

http://cr.openjdk.java.net/%7Eavstepan/8133188/webrev.01/src/java.base/share/classes/java/util/LinkedList.java.udiff.html);
- please see JDK-8133188 comments.

Thanks,
Alexander

RFR [9] 8133188: docs: replace tt tags (obsolete in html5) for java.util

2015-08-10 Thread Alexander Stepanov 

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133188/webrev.01
for
https://bugs.openjdk.java.net/browse/JDK-8133188

Just a next portion of tt tags removed.

specdiff report:
http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html
 - some constructs like
tt(o==nullnbsp;?nbsp;e==nullnbsp;:nbsp;o.equals(e))/tt
were replaced with {@code Objects.equals(o, e)}
(e.g., 
http://cr.openjdk.java.net/~avstepan/8133188/webrev.01/src/java.base/share/classes/java/util/LinkedList.java.udiff.html); 
- please see JDK-8133188 comments.


Thanks,
Alexander

Re: RFR [9] 8132468: docs: replace tt tags (obsolete in html5) for java.io, java.lang, java.math

2015-08-06 Thread Alexander Stepanov 

Thanks!

On 8/5/2015 10:46 PM, Stuart Marks wrote:

Hi Alexander,

The changes to File.java look good. Thanks for doing the specdiffs as 
well; it's a good way to verify that even with all these markup 
changes, specdiff didn't detect any changes to java.io.File at all.


(I didn't look at other files; I'm presuming that others have.)

s'marks

On 8/5/15 5:01 AM, Alexander Stepanov wrote:

Hello Stuart,

Please see the final version of File.java (please update the page) - 
just

replacing tt with code in the mentioned places:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/src/java.base/share/classes/java/io/File.java.udiff.html 



The specdiff reports for lang and io:
http://cr.openjdk.java.net/~avstepan/8132468/specdiff.io/overview-summary.html 

http://cr.openjdk.java.net/~avstepan/8132468/specdiff.lang/overview-summary.html 



Regards,
Alexander

On 8/4/2015 12:47 AM, Stuart Marks wrote:

Hi Alexander,

I think Pavel's advice to run specdiff is useful. It's not too 
difficult to
run and in this case it provides a useful cross-check for making a 
large
number of markup changes. Contact me directly if you need help with 
specdiff.

I've run specdiff over your webrev.01 and I've posted the results here:

http://cr.openjdk.java.net/~smarks/reviews/8132468/specdiff.01/overview-summary.html 




They show that of all the changes you made, only four are considered
significant from specdiff's point of view. Of these, two appear to 
be merely
whitespace issues, but there are two changes that do appear 
significant:


File(URI) // constructor
File.toURI()

In both cases the italic 'f' is intended to be a metasyntactic 
variable, not
an actual variable that's part of the code. The italic 'f' should be 
restored.

In the case of File.toURI() it appears that the resulting code is now
malformed, so there's clearly an error here.

You and Daniel Fuchs had an exchange about this a bit earlier. I 
suspect the
reason for the nbsp; that appears between the opening parenthesis 
and the
italic 'f' is so that the tail of the 'f' doesn't crash into 
parenthesis. In
other words, the nbsp; is there merely for typographical purposes. 
I suspect

that after you restore the italic 'f' it'll look bad, so you'll want to
restore the nbsp; as well.

s'marks

On 8/3/15 9:03 AM, Alexander Stepanov wrote:

Hello Pavel

  Hi Alexander, if I were you I would run specdiff
Thanks; but sorry, I'm afraid I haven't enough time for the extra 
experiments

just now...

  It's very easy to go the all the way and lose oneself in there :)
please accept my condolences :)

Regards,
Alexander

On 8/3/2015 6:33 PM, Pavel Rappo wrote:
On 3 Aug 2015, at 16:07, Alexander Stepanov 
alexander.v.stepa...@oracle.com

wrote:

Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/

removed wrapping code/code around the links (mostly 
PrintStream.java,

PrintWriter.java, File.java), plus other changes in File.java

Thanks,
Alexander
Hi Alexander, if I were you I would run specdiff against the 
changes and

upload it along with the RFR.

P.S. I've tried it once, it was awful. [1] It's very easy to go 
the all the

way and lose oneself in there :)

-- 


[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030262.html 



-Pavel

Re: RFR [9] 8133040: docs: replace tt tags (obsolete in html5) for java.management

2015-08-06 Thread Alexander Stepanov 

Hello Daniel,

Thanks!

Regards,
Alexander

On 8/6/2015 1:14 PM, Daniel Fuchs wrote:

Hi Alexander,

Cursory inspection of the patch file has not revealed anything wrong.
Specdiff looks OK, so that's good for me.

best regards,

-- daniel

On 05/08/15 19:37, Alexander Stepanov wrote:

  javax.management - one (expected) change in TabularDataSupport:
(full package diff:
http://cr.openjdk.java.net/~avstepan/8133040/javax.management/overview-summary.html) 




On 8/5/2015 8:22 PM, Alexander Stepanov wrote:

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133040/webrev.00
for
https://bugs.openjdk.java.net/browse/JDK-8133040

specdiffs:
java.lang.management - no changes detected:
http://cr.openjdk.java.net/~avstepan/8133040/java.lang.management/overview-summary.html 



javax.management - one (expected) change in TabularDataSupport:
http://cr.openjdk.java.net/~avstepan/8133040/javax.management/openmbean/package-summary.html 




Regards,
Alexander

RFR [9] 8133115: docs: replace tt tags (obsolete in html5) for java.util.logging, java.util.prefs, java.util.zip, java.util.jar

2015-08-06 Thread Alexander Stepanov 

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133115/webrev.00
for
https://bugs.openjdk.java.net/browse/JDK-8133115

Just a next portion of tt tags removed.

specdiffs did not detect any changes for java.util package:
http://cr.openjdk.java.net/~avstepan/8133115/util.diff.00/overview-summary.html

Thanks,
Alexander

Re: RFR [9] 8133115: docs: replace tt tags (obsolete in html5) for java.util.logging, java.util.prefs, java.util.zip, java.util.jar

2015-08-06 Thread Alexander Stepanov 

Thanks!

On 8/6/2015 6:33 PM, Lance Andersen wrote:

Looks fine

Best
Lance
On Aug 6, 2015, at 11:08 AM, Alexander Stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133115/webrev.00 
http://cr.openjdk.java.net/%7Eavstepan/8133115/webrev.00

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

Just a next portion of tt tags removed.

specdiffs did not detect any changes for java.util package:
http://cr.openjdk.java.net/~avstepan/8133115/util.diff.00/overview-summary.html

Thanks,
Alexander



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] 8132877: docs: replace tt tags (obsolete in html5) for java.naming

2015-08-05 Thread Alexander Stepanov 

Thanks!

On 8/5/2015 11:14 AM, Daniel Fuchs wrote:

Hi Alexander,

On 04/08/15 19:34, Alexander Stepanov wrote:

Hello Daniel,

The review was re-uploaded as specdiff indeed discovered a couple of
unwanted changes (in 'InitialContext' and 'ReferralException'), so your
and Pavel's recommendations were very useful, thanks.

webrev (please update the web-page):
http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html
sdiff out (0 changes at the moment):
http://cr.openjdk.java.net/~avstepan/8132877/specdiff.01/overview-summary.html 



Looks good for me then.

best regards,

-- daniel




Regards,
Alexander

On 8/4/2015 11:56 AM, Daniel Fuchs wrote:

Hi Alexander,

I had a look at
http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/jdk.patch, and
there's nothing that caught my eye.

However - it would be good if you could generate a specdiff so that
we could verify that no mistake has crept in.

best regards,

-- daniel

On 03/08/15 17:39, Alexander Stepanov wrote:

just in case, the updated webrev:
http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html

On 8/3/2015 4:01 PM, Alexander Stepanov wrote:

P.S. I have also to replace code{@link ...}/code with just {@link
...} in a couple of places here (as in the previous RFR 8132468...)

Regards,
Alexander

On 8/3/2015 3:57 PM, Alexander Stepanov wrote:

Thanks!

On 8/3/2015 3:53 PM, Lance Andersen wrote:

I think this looks ok also.

I agree with Daniel that we have additional clean-up opportunities
 throughout we can do to the javadocs, but keeping each change set
 more narrow helps reduce the chance of  introducing additional
errors

Best
Lance
On Aug 3, 2015, at 5:43 AM, Alexander Stepanov
alexander.v.stepa...@oracle.com
mailto:alexander.v.stepa...@oracle.com wrote:


http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/
http://cr.openjdk.java.net/%7Eavstepan/8132877/webrev.00/


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] 8132468: docs: replace tt tags (obsolete in html5) for java.io, java.lang, java.math

2015-08-05 Thread Alexander Stepanov 

Hello Stuart,

Please see the final version of File.java (please update the page) - 
just replacing tt with code in the mentioned places:

http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/src/java.base/share/classes/java/io/File.java.udiff.html
The specdiff reports for lang and io:
http://cr.openjdk.java.net/~avstepan/8132468/specdiff.io/overview-summary.html
http://cr.openjdk.java.net/~avstepan/8132468/specdiff.lang/overview-summary.html

Regards,
Alexander

On 8/4/2015 12:47 AM, Stuart Marks wrote:

Hi Alexander,

I think Pavel's advice to run specdiff is useful. It's not too 
difficult to run and in this case it provides a useful cross-check for 
making a large number of markup changes. Contact me directly if you 
need help with specdiff. I've run specdiff over your webrev.01 and 
I've posted the results here:


http://cr.openjdk.java.net/~smarks/reviews/8132468/specdiff.01/overview-summary.html 



They show that of all the changes you made, only four are considered 
significant from specdiff's point of view. Of these, two appear to be 
merely whitespace issues, but there are two changes that do appear 
significant:


File(URI) // constructor
File.toURI()

In both cases the italic 'f' is intended to be a metasyntactic 
variable, not an actual variable that's part of the code. The italic 
'f' should be restored. In the case of File.toURI() it appears that 
the resulting code is now malformed, so there's clearly an error here.


You and Daniel Fuchs had an exchange about this a bit earlier. I 
suspect the reason for the nbsp; that appears between the opening 
parenthesis and the italic 'f' is so that the tail of the 'f' doesn't 
crash into parenthesis. In other words, the nbsp; is there merely for 
typographical purposes. I suspect that after you restore the italic 
'f' it'll look bad, so you'll want to restore the nbsp; as well.


s'marks

On 8/3/15 9:03 AM, Alexander Stepanov wrote:

Hello Pavel

  Hi Alexander, if I were you I would run specdiff
Thanks; but sorry, I'm afraid I haven't enough time for the extra 
experiments

just now...

  It's very easy to go the all the way and lose oneself in there :)
please accept my condolences :)

Regards,
Alexander

On 8/3/2015 6:33 PM, Pavel Rappo wrote:
On 3 Aug 2015, at 16:07, Alexander Stepanov 
alexander.v.stepa...@oracle.com

wrote:

Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/

removed wrapping code/code around the links (mostly 
PrintStream.java,

PrintWriter.java, File.java), plus other changes in File.java

Thanks,
Alexander
Hi Alexander, if I were you I would run specdiff against the changes 
and

upload it along with the RFR.

P.S. I've tried it once, it was awful. [1] It's very easy to go 
the all the

way and lose oneself in there :)

-- 


[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030262.html 



-Pavel

RFR [9] 8133040: docs: replace tt tags (obsolete in html5) for java.management

2015-08-05 Thread Alexander Stepanov 

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133040/webrev.00
for
https://bugs.openjdk.java.net/browse/JDK-8133040

specdiffs:
java.lang.management - no changes detected:
http://cr.openjdk.java.net/~avstepan/8133040/java.lang.management/overview-summary.html
javax.management - one (expected) change in TabularDataSupport:
http://cr.openjdk.java.net/~avstepan/8133040/javax.management/openmbean/package-summary.html

Regards,
Alexander

Re: RFR [9] 8133040: docs: replace tt tags (obsolete in html5) for java.management

2015-08-05 Thread Alexander Stepanov 

 javax.management - one (expected) change in TabularDataSupport:
(full package diff: 
http://cr.openjdk.java.net/~avstepan/8133040/javax.management/overview-summary.html)


On 8/5/2015 8:22 PM, Alexander Stepanov wrote:

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133040/webrev.00
for
https://bugs.openjdk.java.net/browse/JDK-8133040

specdiffs:
java.lang.management - no changes detected:
http://cr.openjdk.java.net/~avstepan/8133040/java.lang.management/overview-summary.html 


javax.management - one (expected) change in TabularDataSupport:
http://cr.openjdk.java.net/~avstepan/8133040/javax.management/openmbean/package-summary.html 



Regards,
Alexander

Re: RFR [9] 8132877: docs: replace tt tags (obsolete in html5) for java.naming

2015-08-04 Thread Alexander Stepanov 

Hello Daniel,

The review was re-uploaded as specdiff indeed discovered a couple of 
unwanted changes (in 'InitialContext' and 'ReferralException'), so your 
and Pavel's recommendations were very useful, thanks.


webrev (please update the web-page):
http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html
sdiff out (0 changes at the moment):
http://cr.openjdk.java.net/~avstepan/8132877/specdiff.01/overview-summary.html

Regards,
Alexander

On 8/4/2015 11:56 AM, Daniel Fuchs wrote:

Hi Alexander,

I had a look at 
http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/jdk.patch, and 
there's nothing that caught my eye.


However - it would be good if you could generate a specdiff so that
we could verify that no mistake has crept in.

best regards,

-- daniel

On 03/08/15 17:39, Alexander Stepanov wrote:

just in case, the updated webrev:
http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html

On 8/3/2015 4:01 PM, Alexander Stepanov wrote:

P.S. I have also to replace code{@link ...}/code with just {@link
...} in a couple of places here (as in the previous RFR 8132468...)

Regards,
Alexander

On 8/3/2015 3:57 PM, Alexander Stepanov wrote:

Thanks!

On 8/3/2015 3:53 PM, Lance Andersen wrote:

I think this looks ok also.

I agree with Daniel that we have additional clean-up opportunities
 throughout we can do to the javadocs, but keeping each change set
 more narrow helps reduce the chance of  introducing additional 
errors


Best
Lance
On Aug 3, 2015, at 5:43 AM, Alexander Stepanov
alexander.v.stepa...@oracle.com
mailto:alexander.v.stepa...@oracle.com wrote:


http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/
http://cr.openjdk.java.net/%7Eavstepan/8132877/webrev.00/


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] 8132877: docs: replace tt tags (obsolete in html5) for java.naming

2015-08-03 Thread Alexander Stepanov 
just in case, the updated webrev: 
http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html


On 8/3/2015 4:01 PM, Alexander Stepanov wrote:
P.S. I have also to replace code{@link ...}/code with just {@link 
...} in a couple of places here (as in the previous RFR 8132468...)


Regards,
Alexander

On 8/3/2015 3:57 PM, Alexander Stepanov wrote:

Thanks!

On 8/3/2015 3:53 PM, Lance Andersen wrote:

I think this looks ok also.

I agree with Daniel that we have additional clean-up opportunities 
 throughout we can do to the javadocs, but keeping each change set 
 more narrow helps reduce the chance of  introducing additional errors


Best
Lance
On Aug 3, 2015, at 5:43 AM, Alexander Stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:


http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/ 
http://cr.openjdk.java.net/%7Eavstepan/8132877/webrev.00/


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] 8132468: docs: replace tt tags (obsolete in html5) for java.io, java.lang, java.math

2015-08-03 Thread Alexander Stepanov 

Hello Pavel

 Hi Alexander, if I were you I would run specdiff
Thanks; but sorry, I'm afraid I haven't enough time for the extra 
experiments just now...


 It's very easy to go the all the way and lose oneself in there :)
please accept my condolences :)

Regards,
Alexander

On 8/3/2015 6:33 PM, Pavel Rappo wrote:

On 3 Aug 2015, at 16:07, Alexander Stepanov alexander.v.stepa...@oracle.com 
wrote:

Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/

removed wrapping code/code around the links (mostly PrintStream.java, 
PrintWriter.java, File.java), plus other changes in File.java

Thanks,
Alexander

Hi Alexander, if I were you I would run specdiff against the changes and
upload it along with the RFR.

P.S. I've tried it once, it was awful. [1] It's very easy to go the all the
way and lose oneself in there :)

--
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030262.html

-Pavel

RFR [9] 8132468: docs: replace tt tags (obsolete in html5) for java.io, java.lang, java.math

2015-08-03 Thread Alexander Stepanov 

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8132468

Just some cleanup for docs (replacing obsolete tt/tt).

Thanks,
Alexander

RFR [9] 8132877: docs: replace tt tags (obsolete in html5) for java.naming

2015-08-03 Thread Alexander Stepanov 

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8132877

Just some cleanup for docs (replacing obsolete tt/tt).

Thanks,
Alexander

Re: RFR [9] 8132468: docs: replace tt tags (obsolete in html5) for java.io, java.lang, java.math

2015-08-03 Thread Alexander Stepanov 

Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/

removed wrapping code/code around the links (mostly 
PrintStream.java, PrintWriter.java, File.java), plus other changes in 
File.java


Thanks,
Alexander

On 8/3/2015 3:40 PM, Alexander Stepanov wrote:

Hello Daniel,

Thank you for the notes;

 The code/code is not needed around {@link } - as that should be 
the default formatting for {@link }

Sorry, didn't know; I have to fix that.

 Would that be easier to read as:
Yes, probably that's better. Some old-style code/code tags were 
saved just because of some extra code formatting (like italic letters, 
strong or sup tags etc.) inside of them (which should be displayed 
literally in case of {@code })


 if the goal is to replace code/code and tt/tt everywhere
Sorry, I didn't replace *all* of code/code, just some of them. The 
main intention was to replace just tt/tt (as the tag is deprecated 
for HTML5, in contrast to the code). So the touched packages (and 
even files) still have a lot of code tags.


Thanks,
Alexander

On 8/3/2015 3:17 PM, Daniel Fuchs wrote:

On 03/08/15 11:31, Alexander Stepanov wrote:

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8132468

Just some cleanup for docs (replacing obsolete tt/tt).

Thanks,
Alexander


Hi Alexander,

mostly looks good to me - with afew remarks though.

In some files, such as
src/java.base/share/classes/java/io/Console.java and
src/java.base/share/classes/java/lang/ClassLoader.java
(possibly others) - you're using formatting like:

+* code{@link #readLine}/code.

The code/code is not needed around {@link } - as that should be
the default formatting for {@link } (we use {@linkplain } when we
don't want the code formatting for @link).


src/java.base/share/classes/java/io/File.java

+ * blockquotecode
+ * new File(/codeinbsp;f/icode.{@link
+ * #toURI() toURI}()).equals(/codeinbsp;f/icode.{@link
+ * #getAbsoluteFile() getAbsoluteFile}())
+ * /code/blockquote

Would that be easier to read as:

 * blockquote{@code new File(f.}{@link
 * #toURI() toURI()}{@code .equals(f.}{@link
 * #getAbsoluteFile() getAbsoluteFile()}{@code )}
 * /blockquote

(not sure why the original text has hard spaces nbsp - as
 we usually don't put any space after an open parenthesis)

Same remark for this a few lines below:

+ * blockquotecode
+ * new {@link #File(java.net.URI) File}(/codeinbsp;f/i{@code
+ * .toURI()).equals(}inbsp;f/icode.{@link 
#getAbsoluteFile() getAbsoluteFile}())

+ * /code/blockquote

I mean - I don't particularly object but if the goal is to replace
code/code and tt/tt everywhere - then why not go the full
way down?

The other question is whether pre/pre would be a better fit than
blockquotecode/code/blockquote.


Otherwise looks good!

-- daniel

Re: RFR [9] 8132877: docs: replace tt tags (obsolete in html5) for java.naming

2015-08-03 Thread Alexander Stepanov 

Thanks!

On 8/3/2015 3:53 PM, Lance Andersen wrote:

I think this looks ok also.

I agree with Daniel that we have additional clean-up opportunities 
 throughout we can do to the javadocs, but keeping each change set 
 more narrow helps reduce the chance of  introducing additional errors


Best
Lance
On Aug 3, 2015, at 5:43 AM, Alexander Stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:


http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/ 
http://cr.openjdk.java.net/%7Eavstepan/8132877/webrev.00/


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] 8132877: docs: replace tt tags (obsolete in html5) for java.naming

2015-08-03 Thread Alexander Stepanov 
P.S. I have also to replace code{@link ...}/code with just {@link 
...} in a couple of places here (as in the previous RFR 8132468...)


Regards,
Alexander

On 8/3/2015 3:57 PM, Alexander Stepanov wrote:

Thanks!

On 8/3/2015 3:53 PM, Lance Andersen wrote:

I think this looks ok also.

I agree with Daniel that we have additional clean-up opportunities 
 throughout we can do to the javadocs, but keeping each change set 
 more narrow helps reduce the chance of  introducing additional errors


Best
Lance
On Aug 3, 2015, at 5:43 AM, Alexander Stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:


http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/ 
http://cr.openjdk.java.net/%7Eavstepan/8132877/webrev.00/


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] 8132468: docs: replace tt tags (obsolete in html5) for java.io, java.lang, java.math

2015-08-03 Thread Alexander Stepanov 

Hello Daniel,

Thank you for the notes;

 The code/code is not needed around {@link } - as that should be 
the default formatting for {@link }

Sorry, didn't know; I have to fix that.

 Would that be easier to read as:
Yes, probably that's better. Some old-style code/code tags were 
saved just because of some extra code formatting (like italic letters, 
strong or sup tags etc.) inside of them (which should be displayed 
literally in case of {@code })


 if the goal is to replace code/code and tt/tt everywhere
Sorry, I didn't replace *all* of code/code, just some of them. The 
main intention was to replace just tt/tt (as the tag is deprecated 
for HTML5, in contrast to the code). So the touched packages (and even 
files) still have a lot of code tags.


Thanks,
Alexander

On 8/3/2015 3:17 PM, Daniel Fuchs wrote:

On 03/08/15 11:31, Alexander Stepanov wrote:

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8132468

Just some cleanup for docs (replacing obsolete tt/tt).

Thanks,
Alexander


Hi Alexander,

mostly looks good to me - with afew remarks though.

In some files, such as
src/java.base/share/classes/java/io/Console.java and
src/java.base/share/classes/java/lang/ClassLoader.java
(possibly others) - you're using formatting like:

+* code{@link #readLine}/code.

The code/code is not needed around {@link } - as that should be
the default formatting for {@link } (we use {@linkplain } when we
don't want the code formatting for @link).


src/java.base/share/classes/java/io/File.java

+ * blockquotecode
+ * new File(/codeinbsp;f/icode.{@link
+ * #toURI() toURI}()).equals(/codeinbsp;f/icode.{@link
+ * #getAbsoluteFile() getAbsoluteFile}())
+ * /code/blockquote

Would that be easier to read as:

 * blockquote{@code new File(f.}{@link
 * #toURI() toURI()}{@code .equals(f.}{@link
 * #getAbsoluteFile() getAbsoluteFile()}{@code )}
 * /blockquote

(not sure why the original text has hard spaces nbsp - as
 we usually don't put any space after an open parenthesis)

Same remark for this a few lines below:

+ * blockquotecode
+ * new {@link #File(java.net.URI) File}(/codeinbsp;f/i{@code
+ * .toURI()).equals(}inbsp;f/icode.{@link 
#getAbsoluteFile() getAbsoluteFile}())

+ * /code/blockquote

I mean - I don't particularly object but if the goal is to replace
code/code and tt/tt everywhere - then why not go the full
way down?

The other question is whether pre/pre would be a better fit than
blockquotecode/code/blockquote.


Otherwise looks good!

-- daniel

RFR [9] 8130247: fix some new tidy warnings from jaxws and CORBA

2015-07-01 Thread alexander stepanov 

Hello,

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

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

Just a minor correction for the docs. Some empty trimming p tidy 
warnings fixed; some deprecated tt tags were replaced with {@code 
} as well.


Thanks,
Alexander

Re: RFR [9] 8081517: minor cleanup for docs

2015-06-08 Thread alexander stepanov 

Thanks!

On 05.06.2015 21:32, Roger Riggs wrote:

Hi Alexander,

Looks good, thanks for the updates.

Roger


On 6/5/2015 1:33 PM, alexander stepanov wrote:

Hello Lance, Roger,

Thank you for the notes, please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8081517/webrev.01/index.html
(files changed: FtpURLConnection.java, VmIdentifier.java, 
TraceClassVisitor.java, HttpAuthenticator.java, PlatformLogger.java 
and JdbcRowSetImpl.java - some indents were fixed)


 SQL AS clause
that's probably used for the SQL AS keyword. In such a case the 
upper case may be suitable.


Regards,
Alexander


On 05.06.2015 17:12, Lance Andersen wrote:

Hi Roger
On Jun 5, 2015, at 10:08 AM, Roger Riggs roger.ri...@oracle.com 
wrote:



2)
If indentation is in the scope of your cleanup…
Agree with you and I did not comment on this as I felt it this 
should be done separately as there is a fair amount that can be done 
in these classes for clean up.


Best
lance


In JdbcRowSetImpl.java, the indentation of continued lines after 
@return or @param tags

isn't correct; the continued line should be indented.

And there are a some very long lines that should be wrapped;
See +5637...   If the SQL AS clause was not...

+5784 the indentation needs to be fixed.
+5840 also
+5988
+6265 and after...
  in many cases the lines that follow of /* do not align the * .

CachedRowSetWriter.java:
- many method comment blocks are not aligned properly with the 
method of field that follows.

For example,
/**
* The codeConnection/code object that this writer will use to 
make a

* connection to the data source to which it will write data.
*
*/
private transient Connection con;

3)

CachedRowSetWriter.java:
+1056:  The tag @ param should be tighted up to @param

Thanks, Roger



On 6/5/2015 8:51 AM, alexander stepanov wrote:

Hello,

Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8081517/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8081517

Just some cleanup for docs.

Thanks,
Alexander



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

RFR [9] 8081517: minor cleanup for docs

2015-06-05 Thread alexander stepanov 

Hello,

Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8081517/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8081517

Just some cleanup for docs.

Thanks,
Alexander

Re: RFR [9] 8081517: minor cleanup for docs

2015-06-05 Thread alexander stepanov 

Hello Lance, Roger,

Thank you for the notes, please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8081517/webrev.01/index.html
(files changed: FtpURLConnection.java, VmIdentifier.java, 
TraceClassVisitor.java, HttpAuthenticator.java, PlatformLogger.java and 
JdbcRowSetImpl.java - some indents were fixed)


 SQL AS clause
that's probably used for the SQL AS keyword. In such a case the upper 
case may be suitable.


Regards,
Alexander


On 05.06.2015 17:12, Lance Andersen wrote:

Hi Roger
On Jun 5, 2015, at 10:08 AM, Roger Riggs roger.ri...@oracle.com wrote:


2)
If indentation is in the scope of your cleanup…

Agree with you and I did not comment on this as I felt it this should be done 
separately as there is a fair amount that can be done in these classes for 
clean up.

Best
lance


In JdbcRowSetImpl.java, the indentation of continued lines after @return or 
@param tags
isn't correct; the continued line should be indented.

And there are a some very long lines that should be wrapped;
See +5637...   If the SQL AS clause was not...

+5784 the indentation needs to be fixed.
+5840 also
+5988
+6265 and after...
  in many cases the lines that follow of /* do not align the * .

CachedRowSetWriter.java:
- many method comment blocks are not aligned properly with the method of field 
that follows.
For example,
/**
* The codeConnection/code object that this writer will use to make a
* connection to the data source to which it will write data.
*
*/
private transient Connection con;

3)

CachedRowSetWriter.java:
+1056:  The tag @ param should be tighted up to @param

Thanks, Roger



On 6/5/2015 8:51 AM, alexander stepanov wrote:

Hello,

Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8081517/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8081517

Just some cleanup for docs.

Thanks,
Alexander



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] 8081517: minor cleanup for docs

2015-06-05 Thread alexander stepanov 

 indentation is in the scope of your cleanup

No, I didn't check the indents, lengths of lines etc. (sorry). The 
intention was just to fix some tidy warnings (like empty p tags) and 
javadoc errors like invalid parameter names, invalid tags etc. Tags  
code/code were replaced with {@code} in couple of files just because 
of some connected warnings like unclosed tags etc.


Regards,
Alexander

On 05.06.2015 17:12, Lance Andersen wrote:

Hi Roger
On Jun 5, 2015, at 10:08 AM, Roger Riggs roger.ri...@oracle.com wrote:


2)
If indentation is in the scope of your cleanup…

Agree with you and I did not comment on this as I felt it this should be done 
separately as there is a fair amount that can be done in these classes for 
clean up.

Best
lance


In JdbcRowSetImpl.java, the indentation of continued lines after @return or 
@param tags
isn't correct; the continued line should be indented.

And there are a some very long lines that should be wrapped;
See +5637...   If the SQL AS clause was not...

+5784 the indentation needs to be fixed.
+5840 also
+5988
+6265 and after...
  in many cases the lines that follow of /* do not align the * .

CachedRowSetWriter.java:
- many method comment blocks are not aligned properly with the method of field 
that follows.
For example,
/**
* The codeConnection/code object that this writer will use to make a
* connection to the data source to which it will write data.
*
*/
private transient Connection con;

3)

CachedRowSetWriter.java:
+1056:  The tag @ param should be tighted up to @param

Thanks, Roger



On 6/5/2015 8:51 AM, alexander stepanov wrote:

Hello,

Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8081517/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8081517

Just some cleanup for docs.

Thanks,
Alexander



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] 8040147: minor cleanup for docs

2015-05-26 Thread alexander stepanov 

Hello Lance,

Thank you.
 One suggestion for webrevs  is to  change code/code to {@code}
Please see the updated webrev (Blob.java and Clob.java were changed):
http://cr.openjdk.java.net/~avstepan/8040147/webrev.02/jdk.upd01/

Regards,
Alexander

On 25.05.2015 18:53, Lance Andersen wrote:

Hi Alexander,

Overal this looks OK.  One suggestion for webrevs  is to  change 
code/code to {@code} while you are updating specific comments (not 
the entire file, but at least the lines you are touching).


Thank you for making the changes.

Best
Lance
On May 25, 2015, at 5:40 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8040147/webrev.02/ 
http://cr.openjdk.java.net/%7Eavstepan/8040147/webrev.02/

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

Just a minor fix for docs (some tidy warnings + misprints).

Thanks,
Alexander





Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
http://oracle.com/us/design/oracle-email-sig-198324.giflance.ander...@oracle.com 
mailto:lance.ander...@oracle.com

Re: RFR [9] 8040147: minor cleanup for docs

2015-05-26 Thread alexander stepanov 

Thanks!

On 26.05.2015 15:30, Lance Andersen wrote:

Hi Alexander,

the updates look fine as well

Best
Lance
On May 26, 2015, at 7:45 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello Lance,

Thank you.
 One suggestion for webrevs  is to  change code/code to {@code}
Please see the updated webrev (Blob.java and Clob.java were changed):
http://cr.openjdk.java.net/~avstepan/8040147/webrev.02/jdk.upd01/ 
http://cr.openjdk.java.net/%7Eavstepan/8040147/webrev.02/jdk.upd01/


Regards,
Alexander

On 25.05.2015 18:53, Lance Andersen wrote:

Hi Alexander,

Overal this looks OK.  One suggestion for webrevs  is to  change 
code/code to {@code} while you are updating specific comments 
(not the entire file, but at least the lines you are touching).


Thank you for making the changes.

Best
Lance
On May 25, 2015, at 5:40 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8040147/webrev.02/ 
http://cr.openjdk.java.net/%7Eavstepan/8040147/webrev.02/

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

Just a minor fix for docs (some tidy warnings + misprints).

Thanks,
Alexander





Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
http://oracle.com/us/design/oracle-email-sig-198324.giflance.ander...@oracle.com 
mailto:lance.ander...@oracle.com









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

RFR [9] 8040147: minor cleanup for docs

2015-05-25 Thread alexander stepanov 

Hello,

Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8040147/webrev.02/
for
https://bugs.openjdk.java.net/browse/JDK-8040147

Just a minor fix for docs (some tidy warnings + misprints).

Thanks,
Alexander

Re: RFR [9] 8080422: some docs cleanup for core libs

2015-05-18 Thread alexander stepanov 

Hello Roger,

Fixed; please see
http://cr.openjdk.java.net/~avstepan/8080422/webrev.02/index.html

Regards,
Alexander

On 18.05.2015 17:43, Roger Riggs wrote:

Hi Alexander,

Thanks for these needed cleanups;  a few corrections below.



1) src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java:

The grammar *which *this method can read is  can remove the 'which'



2) src/java.base/share/classes/sun/misc/CharacterEncoder.java: 107

The {@code newline} is confusing, typically @code marks a literal
but in this case it is a symbol for the new line character.
Perhaps use only newline without any special chars, as is used in 
PrintStream.


src/java.base/share/classes/sun/misc/ExtensionDependency.java: 106
Correct the spelling of attriutes:
- * @param jarFile containing the *attriutes *declaring the 
dependencies

+ * @param jar containing the *attributes *declaring the dependencies


3) src/java.base/share/classes/sun/misc/resources/Messages_de.java: 26
Please use {@code instead of code...
- * p This class represents the codeResourceBundle/code
+ * This class represents the codeResourceBundle/code

4) Ditto all of the files in:
 src/java.base/share/classes/sun/misc/resources/Messages_* files:

Thanks, Roger



On 5/18/2015 10:08 AM, alexander stepanov wrote:

Please see the updated webrev
http://cr.openjdk.java.net/~avstepan/8080422/webrev.01/
- some misprints were fixed as well
(not 100% sure if comparision should be replaced with comparison, 
but the latter looks more suitable).


Thanks,
Alexander

On 15.05.2015 20:16, alexander stepanov wrote:

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8080422/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8080422

Just some HTML markup fix.

The affected packages should (probably) not be visible in the new 
modular system, but nevertheless...


Thanks,
Alexander

RFR [9] 8080422: some docs cleanup for core libs

2015-05-18 Thread alexander stepanov 

Please see the updated webrev
http://cr.openjdk.java.net/~avstepan/8080422/webrev.01/
- some misprints were fixed as well
(not 100% sure if comparision should be replaced with comparison, 
but the latter looks more suitable).


Thanks,
Alexander

On 15.05.2015 20:16, alexander stepanov wrote:

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8080422/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8080422

Just some HTML markup fix.

The affected packages should (probably) not be visible in the new 
modular system, but nevertheless...


Thanks,
Alexander

Re: RFR [9] 8080422: some docs cleanup for core libs

2015-05-18 Thread alexander stepanov 

Hello, Lance, Roger,

Thanks!

P.S. sorry - one minor change after the review - a list was added in 
ExtensionDependency.java:

http://cr.openjdk.java.net/~avstepan/8080422/webrev.02/src/java.base/share/classes/sun/misc/ExtensionDependency.java.udiff.html
(please update the page).

Regards,
Alexander

On 18.05.2015 18:54, Lance Andersen wrote:

The revised changes  seem OK in addition to the previous webrev

Best
Lance
On May 18, 2015, at 11:36 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello Roger,

Fixed; please see
http://cr.openjdk.java.net/~avstepan/8080422/webrev.02/index.html 
http://cr.openjdk.java.net/%7Eavstepan/8080422/webrev.02/index.html


Regards,
Alexander

On 18.05.2015 17:43, Roger Riggs wrote:

Hi Alexander,

Thanks for these needed cleanups;  a few corrections below.



1) src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java:

The grammar *which *this method can read is  can remove the 'which'



2) src/java.base/share/classes/sun/misc/CharacterEncoder.java: 107

The {@code newline} is confusing, typically @code marks a literal
but in this case it is a symbol for the new line character.
Perhaps use only newline without any special chars, as is used in 
PrintStream.


src/java.base/share/classes/sun/misc/ExtensionDependency.java: 106
Correct the spelling of attriutes:
- * @param jarFile containing the *attriutes *declaring the 
dependencies
+ * @param jar containing the *attributes *declaring the 
dependencies



3) src/java.base/share/classes/sun/misc/resources/Messages_de.java: 26
Please use {@code instead of code...
- * p This class represents the codeResourceBundle/code
+ * This class represents the codeResourceBundle/code

4) Ditto all of the files in:
src/java.base/share/classes/sun/misc/resources/Messages_* files:

Thanks, Roger



On 5/18/2015 10:08 AM, alexander stepanov wrote:

Please see the updated webrev
http://cr.openjdk.java.net/~avstepan/8080422/webrev.01/
- some misprints were fixed as well
(not 100% sure if comparision should be replaced with 
comparison, but the latter looks more suitable).


Thanks,
Alexander

On 15.05.2015 20:16, alexander stepanov wrote:

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8080422/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8080422

Just some HTML markup fix.

The affected packages should (probably) not be visible in the new 
modular system, but nevertheless...


Thanks,
Alexander









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

RFR [9] 8080422: some docs cleanup for core libs

2015-05-15 Thread alexander stepanov 

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8080422/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8080422

Just some HTML markup fix.

The affected packages should (probably) not be visible in the new 
modular system, but nevertheless...


Thanks,
Alexander

Re: RFR [9] 8079342: some docs cleanup for CORBA - part 2

2015-05-06 Thread alexander stepanov 

Thanks!

 the comments in ValueBoxGen24 are somewhat cryptic to me at least
Yes, indeed... Roger mentioned that these may be some (outdated?) bug 
tracker references, so I prefer not to touch them; just remove the angle 
brackets to avoid warnings.


Regards,
Alexander

On 05.05.2015 21:25, Lance Andersen wrote:
The changes seem reasonable those the comments in ValueBoxGen24 are 
somewhat cryptic to me at least :-)


On May 5, 2015, at 12:30 PM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



 _variableName in the public  javadocs

Please see
http://cr.openjdk.java.net/~avstepan/8079342/webrev.00/src/java.corba/share/classes/com/sun/corba/se/impl/io/ValueHandlerImpl.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8079342/webrev.00/src/java.corba/share/classes/com/sun/corba/se/impl/io/ValueHandlerImpl.java.udiff.html
(please update the page as I didn't prepare a new webrev). Hopefully 
that do not harm the code...


Thanks,
Alexander

On 05.05.2015 18:46, Lance Andersen wrote:

Hi Alexander,

Thank you,  I guess I am not a fan of _variableName in the public 
 javadocs as it is not something we normally see.


Understand less is more, especially with CORBA.

On May 5, 2015, at 11:41 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello Lance,

It just seemed to be less hazardous. E.g., method 'readValue' (in 
ValueHandlerImpl) contains inner variable 'in' and parameter '_in' 
being documented (also, '_sender' - 'sender').


But of course the names could be swapped, if desired. I lazily 
preferred not to touch the code (just in case...).


Regards,
Alexander


On 05.05.2015 18:25, Lance Andersen wrote:

Hi Alexander,

I just started to look at this and have a question:


/**
 * Writes the value to the stream using java semantics.
- * @param out The stream to write the value to
+ * @param _out The stream to write the value to
 * @param value The value to be written to the stream
 **/
public void writeValue(org.omg.CORBA.portable.OutputStream _out,


Is there a reason that you did not change the parameter name to 
out vs changing the @param tag to _out ?


Best,
lance


On May 5, 2015, at 11:21 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8079342/webrev.00/ 
http://cr.openjdk.java.net/%7Eavstepan/8079342/webrev.00/ 
http://cr.openjdk.java.net/%7Eavstepan/8079342/webrev.00/

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

Just some HTML markup fix for CORBA.

Thanks,
Alexander


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 
mailto:lance.ander...@oracle.com








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







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

RFR [9] 8079342: some docs cleanup for CORBA - part 2

2015-05-05 Thread alexander stepanov 

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8079342/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8079342

Just some HTML markup fix for CORBA.

Thanks,
Alexander

Re: RFR [9] 8079342: some docs cleanup for CORBA - part 2

2015-05-05 Thread alexander stepanov 
But yes, for 'writeValue' it could be renamed without any thoughts, 
thanks...


On 05.05.2015 18:41, alexander stepanov wrote:

Hello Lance,

It just seemed to be less hazardous. E.g., method 'readValue' (in 
ValueHandlerImpl) contains inner variable 'in' and parameter '_in' 
being documented (also, '_sender' - 'sender').


But of course the names could be swapped, if desired. I lazily 
preferred not to touch the code (just in case...).


Regards,
Alexander


On 05.05.2015 18:25, Lance Andersen wrote:

Hi Alexander,

I just started to look at this and have a question:


/**
   * Writes the value to the stream using java semantics.
- * @param out The stream to write the value to
+ * @param _out The stream to write the value to
   * @param value The value to be written to the stream
   **/
  public void writeValue(org.omg.CORBA.portable.OutputStream _out,


Is there a reason that you did not change the parameter name to out 
vs changing the @param tag to _out ?


Best,
lance


On May 5, 2015, at 11:21 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8079342/webrev.00/ 
http://cr.openjdk.java.net/%7Eavstepan/8079342/webrev.00/

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

Just some HTML markup fix for CORBA.

Thanks,
Alexander


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] 8079342: some docs cleanup for CORBA - part 2

2015-05-05 Thread alexander stepanov 

Hello Lance,

It just seemed to be less hazardous. E.g., method 'readValue' (in 
ValueHandlerImpl) contains inner variable 'in' and parameter '_in' being 
documented (also, '_sender' - 'sender').


But of course the names could be swapped, if desired. I lazily preferred 
not to touch the code (just in case...).


Regards,
Alexander


On 05.05.2015 18:25, Lance Andersen wrote:

Hi Alexander,

I just started to look at this and have a question:


/**
   * Writes the value to the stream using java semantics.
- * @param out The stream to write the value to
+ * @param _out The stream to write the value to
   * @param value The value to be written to the stream
   **/
  public void writeValue(org.omg.CORBA.portable.OutputStream _out,


Is there a reason that you did not change the parameter name to out 
vs changing the @param tag to _out ?


Best,
lance


On May 5, 2015, at 11:21 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8079342/webrev.00/ 
http://cr.openjdk.java.net/%7Eavstepan/8079342/webrev.00/

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

Just some HTML markup fix for CORBA.

Thanks,
Alexander


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] 8079342: some docs cleanup for CORBA - part 2

2015-05-05 Thread alexander stepanov 

 _variableName in the public  javadocs

Please see
http://cr.openjdk.java.net/~avstepan/8079342/webrev.00/src/java.corba/share/classes/com/sun/corba/se/impl/io/ValueHandlerImpl.java.udiff.html
(please update the page as I didn't prepare a new webrev). Hopefully 
that do not harm the code...


Thanks,
Alexander

On 05.05.2015 18:46, Lance Andersen wrote:

Hi Alexander,

Thank you,  I guess I am not a fan of _variableName in the public 
 javadocs as it is not something we normally see.


Understand less is more, especially with CORBA.

On May 5, 2015, at 11:41 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello Lance,

It just seemed to be less hazardous. E.g., method 'readValue' (in 
ValueHandlerImpl) contains inner variable 'in' and parameter '_in' 
being documented (also, '_sender' - 'sender').


But of course the names could be swapped, if desired. I lazily 
preferred not to touch the code (just in case...).


Regards,
Alexander


On 05.05.2015 18:25, Lance Andersen wrote:

Hi Alexander,

I just started to look at this and have a question:


/**
  * Writes the value to the stream using java semantics.
- * @param out The stream to write the value to
+ * @param _out The stream to write the value to
  * @param value The value to be written to the stream
  **/
 public void writeValue(org.omg.CORBA.portable.OutputStream _out,


Is there a reason that you did not change the parameter name to 
out vs changing the @param tag to _out ?


Best,
lance


On May 5, 2015, at 11:21 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8079342/webrev.00/ 
http://cr.openjdk.java.net/%7Eavstepan/8079342/webrev.00/ 
http://cr.openjdk.java.net/%7Eavstepan/8079342/webrev.00/

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

Just some HTML markup fix for CORBA.

Thanks,
Alexander


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 
mailto:lance.ander...@oracle.com








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] 8079075: some docs cleanup for CORBA - part 1

2015-04-30 Thread alexander stepanov 
P.S. Sorry, not sure if changes like d62023 - {@literal d62023} 
(see, e.g., ValueBoxGen24.java) are what expected; please correct me if 
I'm wrong.


But something should be done; otherwise d62023 is interpreted as an 
unknown HTML tag causing the errors.


Thanks,
Alexander

On 30.04.2015 14:31, alexander stepanov wrote:

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8079075/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8079075

Just some HTML markup fix for CORBA.

Thanks,
Alexander

RFR [9] 8040147: tidy warnings cleanup for javax.transaction

2015-04-30 Thread alexander stepanov 

Hello,

Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8040147/webrev.01/
for
https://bugs.openjdk.java.net/browse/JDK-8040147

Just a very minor fix of docs markup.

Thanks,
Alexander

Re: RFR [9] 8079075: some docs cleanup for CORBA - part 1

2015-04-30 Thread alexander stepanov 

Hello Roger,

Thank you for the notes; please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8079075/webrev.01/

Regards,
Alexander

On 30.04.2015 16:47, Roger Riggs wrote:

Hi Alexander,

Thanks for working through all these changes.

0) Is there an upstream version of any of this code?  Making even 
cosmetic changes

   would make future versions harder to merge.

1) For files that we don't typically generate javadoc for, it is 
simpler to avoid adding unnecessary markup.

For example:

old/src/java.corba/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java:222+ 


+ * @return  the {@code TypeCode} for the element in the Any

There is not much value in the addition of {@code }.

For these kind of files, the javadoc should be well formed and any 
warnings/errors should be fixed.


2) a number of changes do not maintain the indentation, for example,
- * @result  the InputStream to marshal value of Any out of.
+ * @return  the {@code InputStream} to marshal value of Any out of.

Unless all of the indentation is going to be fixed in a file; it is 
better to remain consistent with the per file style.


3) Removing degenerate @author tags is great.  But adding an extra 
blank line is not desirable.
   For example, 
old/src/java.corba/share/classes/com/sun/corba/se/impl/ior/GenericTaggedProfile.java:39


-/**
- * @author
- */
+

4) For snippets of code, use {@code} instead of a plain or {@literal ...}
These files don't that pattern extensively and its not important to 
fix it everywhere since it is in the impl code.

But for example, it would make sense here:
old/src/java.corba/share/classes/com/sun/corba/se/impl/ior/ObjectAdapterIdNumber.java:31+ 



- * internally as arrays of the form { OldRootPOA, number },
+ * internally as arrays of the form { OldRootPOA, {@literal 
number} },


Might be better as:
+ * internally as arrays of the form {@code { OldRootPOA, number 
}},


5) The continuation of @param should be indented.

src/java.corba/share/classes/com/sun/corba/se/impl/naming/pcosnaming/NamingContextImpl.java 


@@ -1204,14 +1202,13 @@
 * This operation creates a URL based iiopname:// format name
 * from the Stringified Name of the object.
 * @param addr internet based address of the host machine where
-* Name Service is running p
-* @param sn Stringified Name of the object p
*+* Name Service is running*
+* @param sn Stringified Name of the object


6) correct the punctuation since the line is being modified.
src/java.corba/share/classes/com/sun/corba/se/pept/transport/Acceptor.java 



- * @return codetrue/code. if the codeAcceptor/code has been
+ * @return codetrue/code. if the codeAcceptor/code has been

Would read better as:
+ * @return codetrue/code if the codeAcceptor/code has been


7)  I don't recognize the strings of the format dN but they seem 
to be referring
to past bug reports and the authors who fixed them.  I doubt they 
have any value in
the code anymore. It would probably be fine to just drop the extra 
'' symbols.

And around the author initials.  klr  --  klr

Regards, Roger



On 4/30/2015 7:56 AM, alexander stepanov wrote:
P.S. Sorry, not sure if changes like d62023 - {@literal 
d62023} (see, e.g., ValueBoxGen24.java) are what expected; please 
correct me if I'm wrong.


But something should be done; otherwise d62023 is interpreted as 
an unknown HTML tag causing the errors.


Thanks,
Alexander

On 30.04.2015 14:31, alexander stepanov wrote:

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8079075/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8079075

Just some HTML markup fix for CORBA.

Thanks,
Alexander

Re: RFR [9] 8079075: some docs cleanup for CORBA - part 1

2015-04-30 Thread Alexander Stepanov 
Thanks!

- Исходное сообщение -
От: roger.ri...@oracle.com
Кому: alexander.v.stepa...@oracle.com
Копия: core-libs-dev@openjdk.java.net
Отправленные: Четверг, 30 Апрель 2015 г 21:41:05 GMT +03:00 Москва, 
Санкт-Петербург, Волгоград
Тема: Re: RFR [9] 8079075: some docs cleanup for CORBA - part 1

Hi Alexander,

The improvements look good to me.

Thank you,  Roger


On 4/30/2015 12:35 PM, alexander stepanov wrote:
 Hello Roger,

 Thank you for the notes; please see the updated webrev:
 http://cr.openjdk.java.net/~avstepan/8079075/webrev.01/

 Regards,
 Alexander

 On 30.04.2015 16:47, Roger Riggs wrote:
 Hi Alexander,

 Thanks for working through all these changes.

 0) Is there an upstream version of any of this code?  Making even 
 cosmetic changes
would make future versions harder to merge.

 1) For files that we don't typically generate javadoc for, it is 
 simpler to avoid adding unnecessary markup.
 For example:

 old/src/java.corba/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java:222+
  

 + * @return  the {@code TypeCode} for the element in the Any

 There is not much value in the addition of {@code }.

 For these kind of files, the javadoc should be well formed and any 
 warnings/errors should be fixed.

 2) a number of changes do not maintain the indentation, for example,
 - * @result  the InputStream to marshal value of Any out of.
 + * @return  the {@code InputStream} to marshal value of Any out of.

 Unless all of the indentation is going to be fixed in a file; it is 
 better to remain consistent with the per file style.

 3) Removing degenerate @author tags is great.  But adding an extra 
 blank line is not desirable.
For example, 
 old/src/java.corba/share/classes/com/sun/corba/se/impl/ior/GenericTaggedProfile.java:39

 -/**
 - * @author
 - */
 +

 4) For snippets of code, use {@code} instead of a plain or {@literal 
 ...}
 These files don't that pattern extensively and its not important to 
 fix it everywhere since it is in the impl code.
 But for example, it would make sense here:
 old/src/java.corba/share/classes/com/sun/corba/se/impl/ior/ObjectAdapterIdNumber.java:31+
  


 - * internally as arrays of the form { OldRootPOA, number },
 + * internally as arrays of the form { OldRootPOA, {@literal 
 number} },

 Might be better as:
 + * internally as arrays of the form {@code { OldRootPOA, 
 number }},

 5) The continuation of @param should be indented.

 src/java.corba/share/classes/com/sun/corba/se/impl/naming/pcosnaming/NamingContextImpl.java
  

 @@ -1204,14 +1202,13 @@
  * This operation creates a URL based iiopname:// format name
  * from the Stringified Name of the object.
  * @param addr internet based address of the host machine where
 -* Name Service is running p
 -* @param sn Stringified Name of the object p
 *+* Name Service is running*
 +* @param sn Stringified Name of the object


 6) correct the punctuation since the line is being modified.
 src/java.corba/share/classes/com/sun/corba/se/pept/transport/Acceptor.java 


 - * @return codetrue/code. if the codeAcceptor/code has been
 + * @return codetrue/code. if the codeAcceptor/code has been

 Would read better as:
 + * @return codetrue/code if the codeAcceptor/code has been


 7)  I don't recognize the strings of the format dN but they seem 
 to be referring
 to past bug reports and the authors who fixed them.  I doubt they 
 have any value in
 the code anymore. It would probably be fine to just drop the 
 extra '' symbols.
 And around the author initials.  klr  --  klr

 Regards, Roger



 On 4/30/2015 7:56 AM, alexander stepanov wrote:
 P.S. Sorry, not sure if changes like d62023 - {@literal 
 d62023} (see, e.g., ValueBoxGen24.java) are what expected; please 
 correct me if I'm wrong.

 But something should be done; otherwise d62023 is interpreted as 
 an unknown HTML tag causing the errors.

 Thanks,
 Alexander

 On 30.04.2015 14:31, alexander stepanov wrote:
 Hello,

 Could you please review the following fix
 http://cr.openjdk.java.net/~avstepan/8079075/webrev.00/
 for
 https://bugs.openjdk.java.net/browse/JDK-8079075

 Just some HTML markup fix for CORBA.

 Thanks,
 Alexander

RFR [9] 8076224: some tidy warning from core libs

2015-04-28 Thread alexander stepanov 

Hello,

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

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

Just some HTML cleanup for docs (remove tidy warnings; remove some 
unnecessary tt tags as they are not supported in HTML5).


Thanks,
Alexander

Re: RFR [9] 8076224: some tidy warning from core libs

2015-04-28 Thread alexander stepanov 

Hello Roger,

Thanks!

 Generally, avoiding line breaks of {@link x} across lines makes 
the source easier to read.


Please see the updated version (no line breaks inside of {@link} tags):
http://cr.openjdk.java.net/~avstepan/8076224/webrev.01/
(is that what expected?)

Regards,
Alexander

On 28.04.2015 17:06, Roger Riggs wrote:

Hi Alexander,

Thanks for doing this cleanup.

Generally, avoiding line breaks of {@link x} across lines makes 
the source easier to read.

Its is ok to re-wrap lines to make the source more readable.

Otherwise, it looks fine to me.

Thanks, Roger


On 4/28/2015 8:22 AM, alexander stepanov wrote:

Hello,

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

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

Just some HTML cleanup for docs (remove tidy warnings; remove some 
unnecessary tt tags as they are not supported in HTML5).


Thanks,
Alexander

Re: RFR [9] 8076224: some tidy warning from core libs

2015-04-28 Thread alexander stepanov 

thanks!

On 28.04.2015 19:25, Lance Andersen wrote:

This seems better now :-)

On Apr 28, 2015, at 12:09 PM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello Roger,

Thanks!

 Generally, avoiding line breaks of {@link x} across lines makes 
the source easier to read.


Please see the updated version (no line breaks inside of {@link} tags):
http://cr.openjdk.java.net/~avstepan/8076224/webrev.01/ 
http://cr.openjdk.java.net/%7Eavstepan/8076224/webrev.01/

(is that what expected?)

Regards,
Alexander

On 28.04.2015 17:06, Roger Riggs wrote:

Hi Alexander,

Thanks for doing this cleanup.

Generally, avoiding line breaks of {@link x} across lines makes 
the source easier to read.

Its is ok to re-wrap lines to make the source more readable.

Otherwise, it looks fine to me.

Thanks, Roger


On 4/28/2015 8:22 AM, alexander stepanov wrote:

Hello,

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

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

Just some HTML cleanup for docs (remove tidy warnings; remove some 
unnecessary tt tags as they are not supported in HTML5).


Thanks,
Alexander






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

RFR [9] 8078622: remove tidy warnings from JPDA docs

2015-04-24 Thread alexander stepanov 

Hello,

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

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

Just some HTML cleanup for docs.

Thanks,
Alexander

Re: RFR [9] 8038764: tidy warnings cleanup for javax.activation

2015-04-20 Thread alexander stepanov 

Thanks!

On 20.04.2015 18:10, Lance Andersen wrote:
Looks fine.  Need to get this into the upstream project though so they 
are not lost on the next update


Best
Lance
On Apr 20, 2015, at 11:01 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8038764/webrev.00/ 
http://cr.openjdk.java.net/%7Eavstepan/8038764/webrev.00/


for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8038764

Just a minor HTML markup fix (few 'trimming empty p' warnings fixed).

Probably the code affected is an upstream.

Regards,
Alexander


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

RFR [9] 8038764: tidy warnings cleanup for javax.activation

2015-04-20 Thread alexander stepanov 

Hello,

Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8038764/webrev.00/

for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8038764

Just a minor HTML markup fix (few 'trimming empty p' warnings fixed).

Probably the code affected is an upstream.

Regards,
Alexander

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

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

Re: Review Request for 8039440: Tidy warnings cleanup for org/omg

2015-04-08 Thread alexander stepanov 

Thanks!

On 07.04.2015 20:13, Roger Riggs wrote:

Thanks, looks fine.

Roger


On 4/7/2015 1:00 PM, alexander stepanov wrote:

Hello Roger,

Thank you for the notes, fixed:
http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/src/java.corba/share/classes/org/omg/CORBA/portable/package.html.udiff.html 

http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/src/java.corba/share/classes/org/omg/CORBA/ShortHolder.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/src/java.corba/share/classes/org/omg/CORBA/TypeCode.java.udiff.html 



Regards,
Alexander

On 07.04.2015 18:20, Roger Riggs wrote:

Hi,

Just a few minor comments;  no need for another webrev (on my account).

The preferred form for code markup is {@code } instead of code... 
/code

and tt... /tt but that may beyond the scope of the current issue.

- Lowercase markup p is preferred over uppercase P but per file 
conventions should be consistent.


+++ 
new/src/java.corba/share/classes/org/omg/CORBA/portable/package.html 
2015-04-07 16:41:12.299150361 +0400


-liDelegate
+li*code*Delegate/*code*

(RR) Why is this list element in code, the others are not.

+++ new/src/java.corba/share/classes/org/omg/CORBA/ShortHolder.java 
2015-04-07 16:41:09.883150470 +0400

@@ -32,7 +32,7 @@
 /**
  * The Holder for ttShort/tt.  For more information on
  * Holder files, see a href=doc-files/generatedfiles.html#holder
- * Generated Files: Holder Files/a.P
+ * Generated Files: Holder Files/a.*P*

(RR) p should be on a new line; before the paragraph it separates

+++ new/src/java.corba/share/classes/org/omg/CORBA/TypeCode.java 
2015-04-07 16:41:10.567150439 +0400


@@ -164,9 +164,9 @@
  *
  * Java IDL extends the CORBA specification to allow all operations 
permitted

  * on a codestruct/code codeTypeCode/code to be permitted
- * on an codeexception/code codeTypeCode/code as well. p
- *
+ * on an codeexception/code codeTypeCode/code as well.
  */
+
 public abstract class TypeCode implements IDLEntity {

(RR) There should not be blank line between comment and class 
definition.



Thanks, Roger


On 4/7/2015 10:40 AM, alexander stepanov wrote:

Hello,

I'm not if the mail list is correct, but could anyone please review 
the following fix?

http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/

Bug: https://bugs.openjdk.java.net/browse/JDK-8039440

Just an HTML markup fix for CORBA.

Thanks,
Alexander

Re: Review Request for 8039440: Tidy warnings cleanup for org/omg

2015-04-08 Thread alexander stepanov 

Thanks!

On 07.04.2015 20:48, Lance Andersen wrote:

Hi Alexander,

InTypeCode.java you might want to use {@code} vs code so that you do 
not have to use gt; lt;


Otherwise it is OK

Best
Lance
On Apr 7, 2015, at 1:00 PM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello Roger,

Thank you for the notes, fixed:
http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/src/java.corba/share/classes/org/omg/CORBA/portable/package.html.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8039440/webrev.01/src/java.corba/share/classes/org/omg/CORBA/portable/package.html.udiff.html

http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/src/java.corba/share/classes/org/omg/CORBA/ShortHolder.java.udiff.html
http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/src/java.corba/share/classes/org/omg/CORBA/TypeCode.java.udiff.html

Regards,
Alexander

On 07.04.2015 18:20, Roger Riggs wrote:

Hi,

Just a few minor comments;  no need for another webrev (on my account).

The preferred form for code markup is {@code } instead of code... 
/code

and tt... /tt but that may beyond the scope of the current issue.

- Lowercase markup p is preferred over uppercase P but per file 
conventions should be consistent.


+++ 
new/src/java.corba/share/classes/org/omg/CORBA/portable/package.html 
2015-04-07 16:41:12.299150361 +0400


-liDelegate
+li*code*Delegate/*code*

(RR) Why is this list element in code, the others are not.

+++ new/src/java.corba/share/classes/org/omg/CORBA/ShortHolder.java 
2015-04-07 16:41:09.883150470 +0400

@@ -32,7 +32,7 @@
/**
 * The Holder for ttShort/tt.  For more information on
 * Holder files, see a href=doc-files/generatedfiles.html#holder
- * Generated Files: Holder Files/a.P
+ * Generated Files: Holder Files/a.*P*

(RR) p should be on a new line; before the paragraph it separates

+++ new/src/java.corba/share/classes/org/omg/CORBA/TypeCode.java 
2015-04-07 16:41:10.567150439 +0400


@@ -164,9 +164,9 @@
 *
 * Java IDL extends the CORBA specification to allow all operations 
permitted

 * on a codestruct/code codeTypeCode/code to be permitted
- * on an codeexception/code codeTypeCode/code as well. p
- *
+ * on an codeexception/code codeTypeCode/code as well.
 */
+
public abstract class TypeCode implements IDLEntity {

(RR) There should not be blank line between comment and class 
definition.



Thanks, Roger


On 4/7/2015 10:40 AM, alexander stepanov wrote:

Hello,

I'm not if the mail list is correct, but could anyone please review 
the following fix?

http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/

Bug: https://bugs.openjdk.java.net/browse/JDK-8039440

Just an HTML markup fix for CORBA.

Thanks,
Alexander







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

Review Request for 8039440: Tidy warnings cleanup for org/omg

2015-04-07 Thread alexander stepanov 

Hello,

I'm not if the mail list is correct, but could anyone please review the 
following fix?

http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/

Bug: https://bugs.openjdk.java.net/browse/JDK-8039440

Just an HTML markup fix for CORBA.

Thanks,
Alexander

Re: Review Request for 8039440: Tidy warnings cleanup for org/omg

2015-04-07 Thread alexander stepanov 

Thanks!

On 07.04.2015 17:45, Yuri Nesterenko wrote:

I'm not sure either but the fix looks OK to me.

-yan

On 04/07/2015 05:40 PM, alexander stepanov wrote:

Hello,

I'm not if the mail list is correct, but could anyone please review the
following fix?
http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/

Bug: https://bugs.openjdk.java.net/browse/JDK-8039440

Just an HTML markup fix for CORBA.

Thanks,
Alexander

Re: Review Request for 8039440: Tidy warnings cleanup for org/omg

2015-04-07 Thread alexander stepanov 

Hello Roger,

Thank you for the notes, fixed:
http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/src/java.corba/share/classes/org/omg/CORBA/portable/package.html.udiff.html
http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/src/java.corba/share/classes/org/omg/CORBA/ShortHolder.java.udiff.html
http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/src/java.corba/share/classes/org/omg/CORBA/TypeCode.java.udiff.html

Regards,
Alexander

On 07.04.2015 18:20, Roger Riggs wrote:

Hi,

Just a few minor comments;  no need for another webrev (on my account).

The preferred form for code markup is {@code } instead of code... 
/code

and tt... /tt but that may beyond the scope of the current issue.

- Lowercase markup p is preferred over uppercase P but per file 
conventions should be consistent.


+++ 
new/src/java.corba/share/classes/org/omg/CORBA/portable/package.html 
2015-04-07 16:41:12.299150361 +0400


-liDelegate
+li*code*Delegate/*code*

(RR) Why is this list element in code, the others are not.

+++ new/src/java.corba/share/classes/org/omg/CORBA/ShortHolder.java 
2015-04-07 16:41:09.883150470 +0400

@@ -32,7 +32,7 @@
 /**
  * The Holder for ttShort/tt.  For more information on
  * Holder files, see a href=doc-files/generatedfiles.html#holder
- * Generated Files: Holder Files/a.P
+ * Generated Files: Holder Files/a.*P*

(RR) p should be on a new line; before the paragraph it separates

+++ new/src/java.corba/share/classes/org/omg/CORBA/TypeCode.java 
2015-04-07 16:41:10.567150439 +0400


@@ -164,9 +164,9 @@
  *
  * Java IDL extends the CORBA specification to allow all operations 
permitted

  * on a codestruct/code codeTypeCode/code to be permitted
- * on an codeexception/code codeTypeCode/code as well. p
- *
+ * on an codeexception/code codeTypeCode/code as well.
  */
+
 public abstract class TypeCode implements IDLEntity {

(RR) There should not be blank line between comment and class definition.


Thanks, Roger


On 4/7/2015 10:40 AM, alexander stepanov wrote:

Hello,

I'm not if the mail list is correct, but could anyone please review 
the following fix?

http://cr.openjdk.java.net/~avstepan/8039440/webrev.01/

Bug: https://bugs.openjdk.java.net/browse/JDK-8039440

Just an HTML markup fix for CORBA.

Thanks,
Alexander

Re: Core Libs Dev[9] Review request for 8029451: Tidy warnings cleanup for java.util package; minor changes in java.nio, java.sql

2014-04-30 Thread alexander stepanov 
Sorry, could please anybody else review the changes? We need at least 
two positive responses to push the changes.


Thanks,
Alexander


On 18.04.2014 23:47, Lance Andersen wrote:

looks fine
On Apr 18, 2014, at 10:04 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8029451

Webrev corresponding:
http://cr.openjdk.java.net/~yan/JDK-8029451/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


Thanks.

Regards,
Alexander


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: Core Libs Dev[9] Review request for 8029451: Tidy warnings cleanup for java.util package; minor changes in java.nio, java.sql

2014-04-30 Thread alexander stepanov 

Hello Lance,

oh yes, thanks!

Regards,
Alexander

On 30.04.2014 14:39, Lance Andersen wrote:


On Apr 30, 2014, at 4:23 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:


Sorry, could please anybody else review the changes? We need at least 
two positive responses to push the changes.


Why?  You only need one reviewer prior to FC: 
http://openjdk.java.net/guide/changePlanning.html#bug





Thanks,
Alexander


On 18.04.2014 23:47, Lance Andersen wrote:

looks fine
On Apr 18, 2014, at 10:04 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8029451

Webrev corresponding:
http://cr.openjdk.java.net/~yan/JDK-8029451/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other 
code affected.


Thanks.

Regards,
Alexander


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 
mailto:lance.ander...@oracle.com








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

Core Libs Dev[9] Review request for 8029451: Tidy warnings cleanup for java.util package; minor changes in java.nio, java.sql

2014-04-18 Thread alexander stepanov 

Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8029451

Webrev corresponding:
http://cr.openjdk.java.net/~yan/JDK-8029451/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


Thanks.

Regards,
Alexander

Core Libs Dev[9] Review Request for 8030709: Tidy warnings cleanup for java.lang package

2014-04-15 Thread alexander stepanov 
Sorry, the webrev was updated to include one other minor change in 
javax/script/ScriptEngineFactory.java to avoid creation of separate 
review request:

http://cr.openjdk.java.net/~yan/8030709/webrev.01/

Regards,
Alexander

On 10.04.2014 12:24, alexander stepanov wrote:

 BigInteger.java from java.lang was also touched.
sorry, from java.math

On 10.04.2014 12:23, alexander stepanov wrote:

Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8030709

Webrev corresponding:
http://cr.openjdk.java.net/~yan/8030709/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


BigInteger.java from java.lang was also touched.

Thanks.

Regards,
Alexander

Re: Core Libs Dev[9] Review Request for 8030709: Tidy warnings cleanup for java.lang package

2014-04-15 Thread alexander stepanov 

thanks!

On 15.04.2014 17:24, Lance Andersen wrote:

looks ok
On Apr 15, 2014, at 9:11 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:


Sorry, the webrev was updated to include one other minor change in 
javax/script/ScriptEngineFactory.java to avoid creation of separate 
review request:
http://cr.openjdk.java.net/~yan/8030709/webrev.01/ 
http://cr.openjdk.java.net/%7Eyan/8030709/webrev.01/


Regards,
Alexander

On 10.04.2014 12:24, alexander stepanov wrote:

 BigInteger.java from java.lang was also touched.
sorry, from java.math

On 10.04.2014 12:23, alexander stepanov wrote:

Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8030709

Webrev corresponding:
http://cr.openjdk.java.net/~yan/8030709/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other 
code affected.


BigInteger.java from java.lang was also touched.

Thanks.

Regards,
Alexander








Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
http://oracle.com/us/design/oracle-email-sig-198324.giflance.ander...@oracle.com 
mailto:lance.ander...@oracle.com

Core Libs Dev[9] Review Request for 8030709: Tidy warnings cleanup for java.lang package

2014-04-10 Thread alexander stepanov 

Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8030709

Webrev corresponding:
http://cr.openjdk.java.net/~yan/8030709/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


BigInteger.java from java.lang was also touched.

Thanks.

Regards,
Alexander

Core Libs Dev[9] Review Request for 8030709: Tidy warnings cleanup for java.lang package

2014-04-10 Thread alexander stepanov 

 BigInteger.java from java.lang was also touched.
sorry, from java.math

On 10.04.2014 12:23, alexander stepanov wrote:

Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8030709

Webrev corresponding:
http://cr.openjdk.java.net/~yan/8030709/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


BigInteger.java from java.lang was also touched.

Thanks.

Regards,
Alexander

Core Libs Dev[9] Review Request for 8039488: tidy warnings cleanup for javax.sql

2014-04-09 Thread alexander stepanov 

Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8039488

Webrev corresponding:
http://cr.openjdk.java.net/~yan/8039488/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


Thanks.

Regards,
Alexander

Re: Core Libs Dev[9] Review Request for 8039488: tidy warnings cleanup for javax.sql

2014-04-09 Thread alexander stepanov 

Hello Lance,

Thanks; please see the updated webrev: 
http://cr.openjdk.java.net/~yan/8039488/webrev.01/


Regards,
Alexander

On 09.04.2014 14:10, Lance @ Oracle wrote:

I think this looks ok but a couple of suggestions

*src/share/classes/javax/sql/rowset/spi/package.html - *The URL links 
at the bottom of the page need updated, please address them as part of 
this putback if possible

*
*
*src/share/classes/javax/sql/package.html *- I would use trade;  as 
part of the change on lines 40 and 42


Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 
tel:+1.781.442.2037

Oracle Java Engineering
1 Network Drive x-apple-data-detectors://34/0
Burlington, MA 01803 x-apple-data-detectors://34/0
lance.ander...@oracle.com mailto:lance.ander...@oracle.com
Sent from my iPad

On Apr 9, 2014, at 5:45 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8039488

Webrev corresponding:
http://cr.openjdk.java.net/~yan/8039488/webrev.00/ 
http://cr.openjdk.java.net/%7Eyan/8039488/webrev.00/


Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


Thanks.

Regards,
Alexander

Core Libs Dev[9] Review request for 8039172: Tidy warnings cleanup for java.net, java.math, java.time, java.rmi

2014-04-04 Thread alexander stepanov 

Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8039172

Webrev corresponding:
http://cr.openjdk.java.net/~yan/8039172/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


Thanks.

Regards,
Alexander

Re: Core Libs Dev[9] Review request for 8039172: Tidy warnings cleanup for java.net, java.math, java.time, java.rmi

2014-04-04 Thread alexander stepanov 

Hello Lance,

Thank you for the note; the summaries were removed, please see the 
updated webrev:

http://cr.openjdk.java.net/~yan/8039172/webrev.01/

Regards,
Alexander

On 04.04.2014 15:16, Lance @ Oracle wrote:
Looks ok but have one concern/question as to why you added the summary 
attribute to the table tag as it has been deprecated and believe it is 
not supported in HTML 5.


I would probably not include it

Best
Lance

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

Oracle Java Engineering
1 Network Drive x-apple-data-detectors://34/0
Burlington, MA 01803 x-apple-data-detectors://34/0
lance.ander...@oracle.com mailto:lance.ander...@oracle.com
Sent from my iPad

On Apr 4, 2014, at 4:55 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8039172

Webrev corresponding:
http://cr.openjdk.java.net/~yan/8039172/webrev.00/ 
http://cr.openjdk.java.net/%7Eyan/8039172/webrev.00/


Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


Thanks.

Regards,
Alexander

Re: Core Libs Dev[9] Review request for 8039172: Tidy warnings cleanup for java.net, java.math, java.time, java.rmi

2014-04-04 Thread alexander stepanov 

Thanks; the line in net-properties.html was splitted.

Regards,
Alexander

On 04.04.2014 19:25, Alan Bateman wrote:

On 04/04/2014 12:53, alexander stepanov wrote:

Hello Lance,

Thank you for the note; the summaries were removed, please see the 
updated webrev:

http://cr.openjdk.java.net/~yan/8039172/webrev.01/
I looked through the updated webrev and it looks okay to me. One 
suggestion for net-properties.html is to split line 38 as it's very 
long compared to all the rest.


-Alan.

Core Libs Dev[9] Review request for 8039041: tidy warnings cleanup for javax.naming

2014-04-03 Thread alexander stepanov 

Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8039041

Webrev corresponding:
http://cr.openjdk.java.net/~yan/8039041/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


Thanks.

Regards,
Alexander

Core Libs Dev[9] Review Request for 8038795: tidy warnings cleanup for javax.management

2014-04-01 Thread alexander stepanov 

Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8038795

Webrev corresponding:
http://cr.openjdk.java.net/~yan/8038795/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


Thanks.

Regards,
Alexander

Re: Core Libs Dev[9] Review Request for 8038795: tidy warnings cleanup for javax.management

2014-04-01 Thread alexander stepanov 

Thanks!

On 01.04.2014 16:57, Alan Bateman wrote:


I think you are looking for jmx-dev so forwarding to that list.

On 01/04/2014 13:51, alexander stepanov wrote:

Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8038795

Webrev corresponding:
http://cr.openjdk.java.net/~yan/8038795/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


Thanks.

Regards,
Alexander

Core Libs Dev[9] Review Request for 8038493: tidy warnings cleanup for java.sql

2014-03-28 Thread alexander stepanov 

Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8038493

Webrev corresponding:
http://cr.openjdk.java.net/~yan/8038493/webrev.00/

Just a minor cleanup of javadoc to avoid tidy warnings; no other code 
affected.


Thanks.

Regards,
Alexander