Re: RFR 9: 8180082 : Broken javadoc links

2017-05-12 Thread Jonathan Gibbons 

I can strongly recommend using link checker tools.

For a long time, linklint has been the recommendation. However, linklint 
cannot cope with "id" attribute on tags that are not  tags. That's 
legal in HTML 5, but linklint is an old tool.  There are newer tools out 
there, for both online and offline use, but I haven't used them enough 
to make a specific recommendation.


-- Jon


On 05/12/2017 01:26 AM, Magnus Ihse Bursie wrote:

On 2017-05-10 23:05, Brian Burkhalter wrote:

Hi Roger,

Looks all right to me. I assume you will have already built the 
actual docs and clicked through the updated links. Always a bit 
painful …


Roger,

Did you test the actual links?

I found one needing updating:

In src/java.base/share/classes/java/io/ObjectStreamClass.java, 
class.html#4100 should be updated to 
class.html#stream-unique-identifiers.


Also, the link in src/java.base/share/classes/java/lang/String.java 
looks suspect. The text refers to Section 6.2 Stream Elements, but to 
get there the link should go to protocol.html#stream-elements. Instead 
it points to output.html, which is Section 2, Object Output Classes. I 
can't really tell which is correct, but my guess is that the text is 
correct and the link is not.


/Magnus



Thanks,

Brian

On May 10, 2017, at 11:22 AM, Roger Riggs  
wrote:



Please review corrections to broken javadoc links:
- links to the serialization spec now in ./specs/serialization
- links in java.lang to java/util/Spliterator
- link in ModuleLayer to Classloader
- Links using ../../../.. do not work well when they show up in some 
indexes; they should use @docRoot


webrev:
http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/

Issue:
  https://bugs.openjdk.java.net/browse/JDK-8180082

Re: RFR 9: 8180082 : Broken javadoc links

2017-05-12 Thread Magnus Ihse Bursie 



On 2017-05-12 17:23, Roger Riggs wrote:

Hi Magnus,

Webrev updated:
http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/


Looks good to me.





On 5/12/2017 4:26 AM, Magnus Ihse Bursie wrote:

On 2017-05-10 23:05, Brian Burkhalter wrote:

Hi Roger,

Looks all right to me. I assume you will have already built the 
actual docs and clicked through the updated links. Always a bit 
painful …


Roger,

Did you test the actual links?
Well, linklint tries; though the output is a bit clouded by the 7105 
missing named anchors

and it did not complain about the missing #4100.



I found one needing updating:

In src/java.base/share/classes/java/io/ObjectStreamClass.java, 
class.html#4100 should be updated to 
class.html#stream-unique-identifiers.

yes, fixed


Also, the link in src/java.base/share/classes/java/lang/String.java 
looks suspect. The text refers to Section 6.2 Stream Elements, but to 
get there the link should go to protocol.html#stream-elements. 
Instead it points to output.html, which is Section 2, Object Output 
Classes. I can't really tell which is correct, but my guess is that 
the text is correct and the link is not.
The current reference is to bullet 9 that describes procedurally how 
serializationof String occurs.


The target you suggest in protocol.html describes the encoding and 
would be ok too,

but for stability I'd leave it as is.

Is it ok to put in a  anchor in 
the output.md markdown

or what is the preferred markup?


Yes, if you need to link to something other than a heading, that's what 
you need to to. More modern pandocs support a more "markdownish" syntax 
but that's not available for us right now.


/Magnus

Re: RFR 8180309: Minor update to javax.sql.rowset package.html

2017-05-12 Thread Mandy Chung 
+1

Mandy

> On May 12, 2017, at 11:07 AM, Lance Andersen  
> wrote:
> 
> Hi all, 
> 
> This change updates the JDBC spec that is being pointed to
> 
> —
> hg diff
> diff -r e2b414957632 
> src/java.sql.rowset/share/classes/javax/sql/rowset/package.html
> --- a/src/java.sql.rowset/share/classes/javax/sql/rowset/package.html Fri May 
> 12 10:43:28 2017 -0700
> +++ b/src/java.sql.rowset/share/classes/javax/sql/rowset/package.html Fri May 
> 12 14:03:34 2017 -0400
> @@ -284,7 +284,7 @@
> 
> 4.0 Related Specifications
> 
> -https://jcp.org/en/jsr/detail?id=221";>JDBC 4.2 Specification
> +https://jcp.org/en/jsr/detail?id=221";>JDBC 4.3 Specification
> http://www.w3.org/XML/Schema";>XML Schema
> 
> 
> ———
> 
> Best
> Lance
> 
>  
> 
> 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 8180309: Minor update to javax.sql.rowset package.html

2017-05-12 Thread Lance Andersen 
Hi all, 

This change updates the JDBC spec that is being pointed to

—
hg diff
diff -r e2b414957632 
src/java.sql.rowset/share/classes/javax/sql/rowset/package.html
--- a/src/java.sql.rowset/share/classes/javax/sql/rowset/package.html   Fri May 
12 10:43:28 2017 -0700
+++ b/src/java.sql.rowset/share/classes/javax/sql/rowset/package.html   Fri May 
12 14:03:34 2017 -0400
@@ -284,7 +284,7 @@
 
 4.0 Related Specifications
 
-https://jcp.org/en/jsr/detail?id=221";>JDBC 4.2 Specification
+https://jcp.org/en/jsr/detail?id=221";>JDBC 4.3 Specification
 http://www.w3.org/XML/Schema";>XML Schema
 

———

Best
Lance
 
  

 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 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

2017-05-12 Thread Brent Christian 

On 5/12/17 9:11 AM, Mandy Chung wrote:


Minor comment:
  95 private final List COMMON_ARGS;

This is an instance field and you can use lower case as the convention.

 238 return !s.equals("");

You can consider using String::isEmpty.


Thanks, Mandy.  I will make these changes before pushing.

-Brent

Re: (9) (docs only) RFR: 8180176: Broken javadoc links in java.logging and java.naming

2017-05-12 Thread Mandy Chung 

> On May 12, 2017, at 4:39 AM, Daniel Fuchs  wrote:
> 
> Hi,
> 
> I have refreshed my webrev to use {@extLink } instead as this
> is what is needed now for links to technical guides:
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html

Looks good.

Mandy

Re: (9) (docs only) RFR: 8180176: Broken javadoc links in java.logging and java.naming

2017-05-12 Thread Chris Hegarty 

On 12/05/17 12:39, Daniel Fuchs wrote:

Hi,

I have refreshed my webrev to use {@extLink } instead as this
is what is needed now for links to technical guides:

http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html


Looks good.

-Chris.

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

2017-05-12 Thread Mandy Chung 

> On May 11, 2017, at 3:25 PM, Brent Christian  
> wrote:
> 
> Hi,
> 
> I have one more update, with a couple of suggested changes to simplify the 
> execute() calls:
> 
> * execute() takes a vararg, so explicit String[] creation can be omitted 
> (mostly).
> 
> * args common to every execute() call are consolidated into a List. (The 
> resulting arg reordering should not affect test execution.)
> 
> http://cr.openjdk.java.net/~bchristi/8177328/webrev.02/

This looks much cleaner.  Thanks for the change.

Minor comment:
  95 private final List COMMON_ARGS;

This is an instance field and you can use lower case as the convention.

 238 return !s.equals("");

You can consider using String::isEmpty.

No need for an updated webrev.

Thanks
Mandy

Re: JDK 9 RFR(xs): 8180137: fix broken link in java.lang.Iterable

2017-05-12 Thread Roger Riggs 

Looks fine.

On 5/12/2017 11:19 AM, Stuart Marks wrote:

Hi all,

Another quick doc change. This one removes a link from Iterable to 
technotes/guides and adjusts adjacent wording to match. Patch below.


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

Thanks,

s'marks

# HG changeset patch
# User smarks
# Date 1494544788 25200
#  Thu May 11 16:19:48 2017 -0700
# Node ID cfff17f92ff2422ea4c576835b90cc16f0e3d805
# Parent  a3af889e7f6591e4c00d79ce454f6725cba19eb6
8180137: fix broken link in java.lang.Iterable
Reviewed-by: XXX

diff -r a3af889e7f65 -r cfff17f92ff2 
src/java.base/share/classes/java/lang/Iterable.java
--- a/src/java.base/share/classes/java/lang/Iterable.javaWed May 
10 15:59:15 2017 -0700
+++ b/src/java.base/share/classes/java/lang/Iterable.javaThu May 
11 16:19:48 2017 -0700

@@ -31,16 +31,13 @@
 import java.util.function.Consumer;

 /**
- * Implementing this interface allows an object to be the target of
- * the "for-each loop" statement. See
- * 
- * href="{@docRoot}/../technotes/guides/language/foreach.html">For-each 
Loop

- * 
+ * Implementing this interface allows an object to be the target of 
the enhanced
+ * {@code for} statement (sometimes called the "for-each loop" 
statement).

  *
  * @param  the type of elements returned by the iterator
  *
  * @since 1.5
- * @jls 14.14.2 The enhanced for statement
+ * @jls 14.14.2 The enhanced {@code for} statement
  */
 public interface Iterable {
 /**

Re: RFR 9: 8180082 : Broken javadoc links

2017-05-12 Thread Roger Riggs 

Hi Magnus,

Webrev updated:
   http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/


On 5/12/2017 4:26 AM, Magnus Ihse Bursie wrote:

On 2017-05-10 23:05, Brian Burkhalter wrote:

Hi Roger,

Looks all right to me. I assume you will have already built the 
actual docs and clicked through the updated links. Always a bit 
painful …


Roger,

Did you test the actual links?
Well, linklint tries; though the output is a bit clouded by the 7105 
missing named anchors

and it did not complain about the missing #4100.



I found one needing updating:

In src/java.base/share/classes/java/io/ObjectStreamClass.java, 
class.html#4100 should be updated to 
class.html#stream-unique-identifiers.

yes, fixed


Also, the link in src/java.base/share/classes/java/lang/String.java 
looks suspect. The text refers to Section 6.2 Stream Elements, but to 
get there the link should go to protocol.html#stream-elements. Instead 
it points to output.html, which is Section 2, Object Output Classes. I 
can't really tell which is correct, but my guess is that the text is 
correct and the link is not.
The current reference is to bullet 9 that describes procedurally how 
serializationof String occurs.


The target you suggest in protocol.html describes the encoding and would 
be ok too,

but for stability I'd leave it as is.

Is it ok to put in a  anchor in 
the output.md markdown

or what is the preferred markup?

Thanks, Roger




/Magnus



Thanks,

Brian

On May 10, 2017, at 11:22 AM, Roger Riggs  
wrote:



Please review corrections to broken javadoc links:
- links to the serialization spec now in ./specs/serialization
- links in java.lang to java/util/Spliterator
- link in ModuleLayer to Classloader
- Links using ../../../.. do not work well when they show up in some 
indexes; they should use @docRoot


webrev:
http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/

Issue:
  https://bugs.openjdk.java.net/browse/JDK-8180082

JDK 9 RFR(xs): 8180137: fix broken link in java.lang.Iterable

2017-05-12 Thread Stuart Marks 

Hi all,

Another quick doc change. This one removes a link from Iterable to 
technotes/guides and adjusts adjacent wording to match. Patch below.


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

Thanks,

s'marks

# HG changeset patch
# User smarks
# Date 1494544788 25200
#  Thu May 11 16:19:48 2017 -0700
# Node ID cfff17f92ff2422ea4c576835b90cc16f0e3d805
# Parent  a3af889e7f6591e4c00d79ce454f6725cba19eb6
8180137: fix broken link in java.lang.Iterable
Reviewed-by: XXX

diff -r a3af889e7f65 -r cfff17f92ff2 
src/java.base/share/classes/java/lang/Iterable.java
--- a/src/java.base/share/classes/java/lang/Iterable.java	Wed May 10 15:59:15 
2017 -0700
+++ b/src/java.base/share/classes/java/lang/Iterable.java	Thu May 11 16:19:48 
2017 -0700

@@ -31,16 +31,13 @@
 import java.util.function.Consumer;

 /**
- * Implementing this interface allows an object to be the target of
- * the "for-each loop" statement. See
- * 
- * For-each 
Loop
- * 
+ * Implementing this interface allows an object to be the target of the 
enhanced
+ * {@code for} statement (sometimes called the "for-each loop" statement).
  *
  * @param  the type of elements returned by the iterator
  *
  * @since 1.5
- * @jls 14.14.2 The enhanced for statement
+ * @jls 14.14.2 The enhanced {@code for} statement
  */
 public interface Iterable {
 /**

Re: Getting a live view of environment variables (Gradle and JDK 9)

2017-05-12 Thread dalibor topic 

On 11.05.2017 18:29, Cédric Champeau wrote:



Unfortunately, they are not safely mutable in multi-threaded
programs on many operating system/libc combinations.

But the problem is less about mutating, that it is about reading: the VM
returns wrong values at some point, because it _assumes_ that the
environment variables are not mutated.


Right. Assuming that another thread could be simultaneously writing to 
the same data structure holding environment variables (char **), reading 
itself becomes problematic at such points in time, as you might read a 
temporarily corrupted data structure.


I guess the question underneath is if there is a safe point in time when 
reading the data could be preformed and no concurrent write from JNI 
code corrupting the data when it's partially read is possible.


cheers,
dalibor topic
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

Re: (9) (docs only) RFR: 8180176: Broken javadoc links in java.logging and java.naming

2017-05-12 Thread Vyom Tewari 

Hi Daniel,

Changes looks good, i was under impression that if {@extLink } 
description is multi word then you have to put it under double quotes 
like {xtLink jndi_overview "JNDI documentation"} but looks like that is 
not the case ExtLink.java will take care of this.


Thanks,

Vyom


On Friday 12 May 2017 05:09 PM, Daniel Fuchs wrote:

Hi,

I have refreshed my webrev to use {@extLink } instead as this
is what is needed now for links to technical guides:

http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html

best regards,

-- daniel

On 11/05/2017 12:54, Daniel Fuchs wrote:

Hi,

Please find below a patch for:

8180176: Broken javadoc links in java.logging and java.naming
https://bugs.openjdk.java.net/browse/JDK-8180176

The fix is to use {@docRoot} as has been done elsewhere...
http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html

best regards,

-- daniel

Re: (9) (docs only) RFR: 8180176: Broken javadoc links in java.logging and java.naming

2017-05-12 Thread Daniel Fuchs 

Hi,

I have refreshed my webrev to use {@extLink } instead as this
is what is needed now for links to technical guides:

http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html

best regards,

-- daniel

On 11/05/2017 12:54, Daniel Fuchs wrote:

Hi,

Please find below a patch for:

8180176: Broken javadoc links in java.logging and java.naming
https://bugs.openjdk.java.net/browse/JDK-8180176

The fix is to use {@docRoot} as has been done elsewhere...
http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html

best regards,

-- daniel

Re: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, jdk.httpserver, jdk.net, jdk.sctp

2017-05-12 Thread Daniel Fuchs 

Hi Kumar,

On 12/05/2017 00:16, Kumar Srinivasan wrote:


Hi Daniel,

As Jon surmised, this is an ARIA/accessibility requirement, in that one
can't
have holes in the usage of h* tags,  as javadoc tool itself uses h1 and h2,
the API docs have to start with h3.

With respect to your comment, the h2->h3 is erroneous and have reverted
them back, so the only changes wrt. h* are h4 -> h3.

New webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.1/


This looks good now. Thanks for explaining the issue with holes in
the usage of h* tags - it makes it much easier to understand the
rationale behind the changes.

A few nits:
com/sun/net/httpserver/HttpServer.java:
  62  * description
  71  * description

there are 2 spaces after 'caption'


javax/naming/event/package.html:
  82 Threading Issues
 101 Exception Handling

I wonder if these two tags should be changed to  as well,
so as not to introduce a hierarchy that was not there before.
(these do not seem to be sub-concepts of Naming Events
 as far as I can see - but then I'm not a JNDI expert)

Otherwise looks good, no need for a new webrev.

best regards,

-- daniel




Thanks
Kumar




Hi Kumar,

Looks mostly good.
I'm not too sure about the changes from  to  and  to
 though.

Now some of the package.html files in java.naming retain their
Package Specification section, and others have it
changed to Package Specification.

best regards,

-- daniel

On 10/05/2017 19:57, Kumar Srinivasan wrote:

Hello,

Please review HTML5 related changes to the above modules, please
note there are no changes to the verbiage.

Thanks
Kumar

Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/
JBS: https://bugs.openjdk.java.net/browse/JDK-8179697

How to create dynamically generated JNLP files post JDK-8157337?

2017-05-12 Thread Tim Anderson 
Apologies if this is the wrong place for this post, but there doesn't 
appear to be a webstart specific list.


Is it possible to generate a JNLP file with arguments that change each 
invocation, and avoid the webstart security popup being displayed each time?


Background

I have a signed webstart application that is launched via a generated JNLP.

The JNLP is generated to:
* specify the codebase. The application is deployed from a .war
* supply arguments to the application, which change with each invocation

This was working fine up to Java 8 update 111. With subsequent releases, 
webstart now displays a popup every time the app is run:


   Do you want to run this application ?
   ...

   This application will run with unrestricted access which may put 
your computer and personal information at risk.

   Run this application only if you trust the location and publisher above.

It appears to have broken since 8 update 112, when 
https://bugs.openjdk.java.net/browse/JDK-8157337 was introduced.


The issue seems to be that the jnlp href is not supplied, so it 
considers the app to be from multiple hosts.
I can't implement the workaround suggested at 
http://stackoverflow.com/a/43716680 as the codebase is not known until 
runtime.


The JNLP used for template replacement:











   



$$arguments



The APPLICATION_TEMPLATE.JNLP














*



Thanks,

-Tim

Also see:
* https://bugs.openjdk.java.net/browse/JDK-8175981
* https://bugs.openjdk.java.net/browse/JDK-8157337
* 
http://stackoverflow.com/questions/42866652/the-do-you-want-to-run-this-application-prompt-is-always-displayed-for-a-dyna

Re: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, jdk.httpserver, jdk.net, jdk.sctp

2017-05-12 Thread Daniel Fuchs 

On 11/05/2017 20:46, Jonathan Gibbons wrote:

Daniel,

As a general comment, it is an accessibility error to have "gaps" in the
header numbering, such as an  following an  without an
intervening .


Oh! Thank you for the precision. I will take a second look with
that in mind.



If you can point to specific files where you think the numbering has
been semantically changed, that would be good to know.


In java.naming package.html files, some  have been changed to .
I was just surprised that it only happened in some of java.naming
package.html files and not all, but I see that Kumar has fixed the issue
in his later webrev.

best regards,

-- daniel



-- Jon

Re: Proposal: javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder()

2017-05-12 Thread Alan Bateman 

On 11/05/2017 22:25, Andrew Guibert wrote:

Alan, could you please commit this patch for me? We've tested it 
locally and all of the jdk_other tests pass with this change on jdk9.


93d92
< * Once installed, the builder cannot be replaced.
101d99
< * @exception IllegalStateException If a factory has already been 
installed.

109,111d106
< if (object_factory_builder != null)
< throw new IllegalStateException("ObjectFactoryBuilder already set");
<
739,740c734
< * the security manager to do so. Once installed, the builder cannot
< * be replaced.
---
> * the security manager to do so.
747d740
< * @exception IllegalStateException If a builder was previous installed.
754,757d746
< if (initctx_factory_builder != null)
< throw new IllegalStateException(
< "InitialContextFactoryBuilder already set");
<

I assume you will be able to get an IBM contributor to sponsor this. It 
will need an issue in JIRA and tests. All API changes for Java SE 10 and 
beyond will be reviewed by the CSR group [1], that process will be 
opening soon.


-Alan

[1] https://wiki.openjdk.java.net/display/csr/Main

Re: RFR 9: 8180082 : Broken javadoc links

2017-05-12 Thread Daniel Fuchs 

Hi Roger,

Looks good!

Nit:
java/lang/management/package.html:
  38 conforms to the {@link javax.management JMX}
should probably use {@linkplain } instead.

(no need for a new webrev)

best regards,

-- daniel

On 11/05/2017 20:41, Roger Riggs wrote:

Hi,

Thanks for the review and suggestions.
{@link ...} will work those links;  some hrefs will remain in cases
where the link is to an "id" of some
element that is not a method or field name.

Webrev updated in place:
http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/

Thanks, Roger

On 5/11/2017 5:24 AM, Daniel Fuchs wrote:

Hi Roger,

I'm surprised to see we have  style links in .java
files to link to package summary and java APIs for classes and
methods, when {@link } should work...

For instance in this file:
http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/src/jdk.management/share/classes/com/sun/management/package-info.java.frames.html


Does:

  29  * 


actualy works?? Looks like it has too many ../.. to me...

I suspect (hope?) it could be advantageously replaced by {@link
java.lang.management}.


Similarly:

  36  * 

  37  * java.lang.management.ManagementFactory.getPlatformMBeanServer

could probably be {@link
java.lang.management.ManagementFactory#getPlatformMBeanServer()}


This also reminds me that as part of the technical debt we might also
think about replacing package.html files by their more modern
package-info.java counterpart - but that's probably for another day...


cheers,

-- daniel



On 10/05/2017 19:22, Roger Riggs wrote:

Please review corrections to broken javadoc links:
 - links to the serialization spec now in ./specs/serialization
 - links in java.lang to java/util/Spliterator
 - link in ModuleLayer to Classloader
 - Links using ../../../.. do not work well when they show up in some
indexes; they should use @docRoot

webrev:
http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/

Issue:
  https://bugs.openjdk.java.net/browse/JDK-8180082

Thanks, Roger

Re: RFR 9: 8180082 : Broken javadoc links

2017-05-12 Thread Magnus Ihse Bursie 

On 2017-05-10 23:05, Brian Burkhalter wrote:

Hi Roger,

Looks all right to me. I assume you will have already built the actual docs and 
clicked through the updated links. Always a bit painful …


Roger,

Did you test the actual links?

I found one needing updating:

In src/java.base/share/classes/java/io/ObjectStreamClass.java, 
class.html#4100 should be updated to class.html#stream-unique-identifiers.


Also, the link in src/java.base/share/classes/java/lang/String.java 
looks suspect. The text refers to Section 6.2 Stream Elements, but to 
get there the link should go to protocol.html#stream-elements. Instead 
it points to output.html, which is Section 2, Object Output Classes. I 
can't really tell which is correct, but my guess is that the text is 
correct and the link is not.


/Magnus



Thanks,

Brian

On May 10, 2017, at 11:22 AM, Roger Riggs  wrote:


Please review corrections to broken javadoc links:
- links to the serialization spec now in ./specs/serialization
- links in java.lang to java/util/Spliterator
- link in ModuleLayer to Classloader
- Links using ../../../.. do not work well when they show up in some indexes; 
they should use @docRoot

webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/

Issue:
  https://bugs.openjdk.java.net/browse/JDK-8180082