Re: RFR: JDK-8179631: Fix Html5 errors in java.management, jdk.management, jdk.jdi and jdk.attach

> On May 10, 2017, at 11:35 AM, Kumar Srinivasan > wrote: > > Hi All, > > Please review fixes to make the API doc comments HTML5 clean, > there are no changes to the verbiage, and mostly fixes for the table > styles defined here: >

Re: RFR: 8180256: HTML5 issues in java.sql

Thanks -- Jon On 05/11/2017 05:37 PM, Lance Andersen wrote: Looks fine Jon Best Lance On May 11, 2017, at 7:38 PM, Jonathan Gibbons > wrote: More HTML 5 fixes to review in a few files in the java.sql and java.sql.rowset

Re: RFR: 8180256: HTML5 issues in java.sql

Looks fine Jon Best Lance > On May 11, 2017, at 7:38 PM, Jonathan Gibbons > wrote: > > More HTML 5 fixes to review in a few files in the java.sql and > java.sql.rowset modules: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8180256 > Webrev:

Re: RFR: JDK-8179631: Fix Html5 errors in java.management, jdk.management, jdk.jdi and jdk.attach

Hello, Ping!. Lets wrap this up soon, as we have to move to the next steps in the docs related work. Thanks Kumar Hi All, Please review fixes to make the API doc comments HTML5 clean, there are no changes to the verbiage, and mostly fixes for the table styles defined here:

RFR: 8180256: HTML5 issues in java.sql

More HTML 5 fixes to review in a few files in the java.sql and java.sql.rowset modules: JBS: https://bugs.openjdk.java.net/browse/JDK-8180256 Webrev: http://cr.openjdk.java.net/~jjg/8180256/webrev.00/ API: http://cr.openjdk.java.net/~jjg/8180256/api.00/overview-summary.html -- Jon

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

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

Re: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom fails to Initialize when using SecurityManager

On 12/05/2017 7:55 AM, Mandy Chung wrote: +1 (dropping the null check as Claes suggests). Ok - dropping null check. :) Thanks, David Mandy On May 11, 2017, at 2:01 PM, Claes Redestad wrote: The null check is redundant, so the code could be simplified a bit.

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

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

Re: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom fails to Initialize when using SecurityManager

+1 (dropping the null check as Claes suggests). Mandy > On May 11, 2017, at 2:01 PM, Claes Redestad wrote: > > The null check is redundant, so the code could be simplified a bit. > > Reviewed regardless! > > /Claes > > On 2017-05-11 22:46, David Holmes wrote: >>

Re: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom fails to Initialize when using SecurityManager

Thanks Paul! David On 12/05/2017 7:14 AM, Paul Sandoz wrote: +1 Paul. On 11 May 2017, at 13:46, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8179515 webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/ This is a fix contributed by Doug

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

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.

Re: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom fails to Initialize when using SecurityManager

+1 Paul. > On 11 May 2017, at 13:46, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179515 > webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/ > > This is a fix contributed by Doug Lea, from a suggestion made by Alan > Bateman. While

Re: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom fails to Initialize when using SecurityManager

On 12/05/2017 7:01 AM, Claes Redestad wrote: The null check is redundant, so the code could be simplified a bit. Reviewed regardless! Thanks Claes! David /Claes On 2017-05-11 22:46, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8179515 webrev:

Re: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom fails to Initialize when using SecurityManager

The null check is redundant, so the code could be simplified a bit. Reviewed regardless! /Claes On 2017-05-11 22:46, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8179515 webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/ This is a fix contributed by Doug Lea,

(9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom fails to Initialize when using SecurityManager

Bug: https://bugs.openjdk.java.net/browse/JDK-8179515 webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/ This is a fix contributed by Doug Lea, from a suggestion made by Alan Bateman. While I'm handling the fix process for Doug, it isn't my fix so I am also a Reviewer of this fix. I

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

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 . If you can point to specific files where you think the numbering has been semantically changed, that would be good to know. -- Jon On

Re: RFR 9: 8180082 : Broken javadoc links

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,

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

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

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

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

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

2017-05-11 12:50 GMT+02:00 David Holmes : > Hi Cedric, > > On 11/05/2017 5:02 PM, Cédric Champeau wrote: > >> Thanks for the answers, folks, but I think they are kind of missing the >> point. The fact is that environment variables *are* mutable. Java >> > > Yes they are,

Re: RFR: [Updated] Update tables in java.base to be HTML5-friendly.

Martin, I've worked with Bhavesh to sort out these issues. The inconsistency in the syntax has been fixed. The CSS could be more compact ... if we did not have to deal with nested tables. It was also a goal to simplify the use for the doc comment author, such that it was possible to put

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

On 11.05.2017 09:02, Cédric Champeau wrote: Thanks for the answers, folks, but I think they are kind of missing the point. The fact is that environment variables *are* mutable. Unfortunately, they are not safely mutable in multi-threaded programs on many operating system/libc combinations.

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

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

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

Hi Cedric, On 11/05/2017 5:02 PM, Cédric Champeau wrote: Thanks for the answers, folks, but I think they are kind of missing the point. The fact is that environment variables *are* mutable. Java Yes they are, provided you do it carefully and don't have to deal with the fact that its

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

On 11/05/2017 08:02, Cédric Champeau wrote: Thanks for the answers, folks, but I think they are kind of missing the point. The fact is that environment variables *are* mutable. Java happens to return an immutable view of the environment variables when the VM was started, which is not the

Re: RFR 9: 8180082 : Broken javadoc links

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:

Re: RFR 9: 8180082 : Broken javadoc links

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

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

Thanks for the answers, folks, but I think they are kind of missing the point. The fact is that environment variables *are* mutable. Java happens to return an immutable view of the environment variables when the VM was started, which is not the reality. We cannot trust what `System.geteenv`