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

2015-08-05 Thread Daniel Fuchs
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

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

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

2015-08-04 Thread Daniel Fuchs
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

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

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,

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

2015-08-03 Thread Martin Buchholz
I'm surprised tt is going away. Do you have a reference that explains the new jdk9 javadoc standards? On Mon, Aug 3, 2015 at 2:43 AM, Alexander Stepanov alexander.v.stepa...@oracle.com wrote: Hello, Could you please review the following fix:

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

2015-08-03 Thread Martin Buchholz
Bhavesh, it would be good if jep 224 said what to do with the many legacy tt tags. Best practice seems to be to convert to {@code ...} if possible and appropriate, else to code, kbd, or samp, as given by http://www.w3schools.com/tags/tag_code.asp On Mon, Aug 3, 2015 at 10:21 AM, Alexander

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

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

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

2015-08-03 Thread Lance Andersen
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