RE: RE : RFR(S): 8207766: [testbug] Adapt tests for Aix.

Hi Matthias, thanks for lookin at this! Best regards, Goetz. > -Original Message- > From: Baesken, Matthias > Sent: Freitag, 20. Juli 2018 09:03 > To: core-libs-dev@openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: RE : RFR(S): 8207766: [testbug] Adapt tests for Aix. > > Looks go

RE : RFR(S): 8207766: [testbug] Adapt tests for Aix.

Looks good to me ( however I am not a Reviewer). Best regards, Matthias > -Original Message- > From: core-libs-dev > mailto:core-libs-dev-boun...@openjdk.java.net>> > On Behalf > Of Lindenmaier, Goetz > Sent: Mittwoch, 18. Juli 2018 09:28 > To: core-libs-dev@openjdk.java.net

RE: RFR : 8207395: jar has issues with UNC-path arguments for the jar -C parameter [windows]

Looks good. Best regards, Goetz. > -Original Message- > From: Baesken, Matthias > Sent: Donnerstag, 19. Juli 2018 11:15 > To: core-libs-dev@openjdk.java.net; xueming.s...@oracle.com > Cc: Lindenmaier, Goetz > Subject: Re: RFR : 8207395: jar has issues with UNC-path arguments for the >

RE: RFR : 8207395: jar has issues with UNC-path arguments for the jar -C parameter [windows]

Thanks ! Sherman - are you fine with the latest version , if so I would push it . Best regards, Matthias > -Original Message- > From: Lindenmaier, Goetz > Sent: Freitag, 20. Juli 2018 09:38 > To: Baesken, Matthias ; core-libs- > d...@openjdk.java.net; xueming.s...@oracle.com > Subject:

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

I agree with Chris. Unlike the connection failure error messages where the IP/port being part of the error message did add value, I don't think including the "path" to the jar (something like /opt/private/foo/bar/helloworld.jar) in case of MANIFEST parsing errors is really necessary. I think, just

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

> On 19 Jul 2018, at 15:42, Sean Mullan wrote: > >> ... > > Note that making this a security property for all general cases may have > performance implications in certain scenarios since the java.security file > will need to be loaded and fully parsed before it can be used. If you are > alr

RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

JDK-8204233 added a new security property, `jdk.net.includeInExceptions`, to include additional, potentially security sensitive, information in exception detail messages in the networking area. The property accepts a comma separated list of values that specifies the particular type of extra detail

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

> On 19 Jul 2018, at 13:54, Chris Hegarty wrote: > > > I filed the following issue to generalize the `includeInExceptions` security > property: > https://bugs.openjdk.java.net/browse/JDK-8207846 I sent out an RFR for 8207846, since I think it is worth proceeding with regardless of the ou

RE: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

Hi Chris, thanks for starting the new RFR for to generalization of the `includeInExceptions` security property: Best regards, Matthias > -Original Message- > From: Chris Hegarty [mailto:chris.hega...@oracle.com] > Sent: Freitag, 20. Juli 2018 13:41 > To: Alan Bateman ; Baesken,

RE: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

Hi, I scanned all the changes we did to exception messages in our internal VM, see below. We print paths and sockets in a row of places, but also other information. It's wide spread, while most is in java.base. We plan to contribute these messages in the near future. Thus it'll be useful if t

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

On 20/07/2018 12:38, Chris Hegarty wrote: JDK-8204233 added a new security property, `jdk.net.includeInExceptions`, to include additional, potentially security sensitive, information in exception detail messages in the networking area. The property accepts a comma separated list of values that sp

RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

I have finally managed to draft a JEP to formally present the proposal I circulated a month or two back regarding support for MappedByteBuffer access to non-volatile memory. JEP JIRA: https://bugs.openjdk.java.net/browse/JDK-8207851 The JEP references a re-implementation of the proposed API:

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

On 20/07/2018 14:50, Andrew Dinn wrote: I have finally managed to draft a JEP to formally present the proposal I circulated a month or two back regarding support for MappedByteBuffer access to non-volatile memory. JEP JIRA: https://bugs.openjdk.java.net/browse/JDK-8207851 The JEP references

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

Roger, > On 20 Jul 2018, at 14:52, Roger Riggs wrote: > > Hi Chris, > > It is very unusual for the processing of system properties to do *any* > parsing except for delimiters > including removing spaces, etc. It complicates the handling and sets a bad > precedent > that makes it more complex

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

On 20/07/18 15:05, Alan Bateman wrote: > On 20/07/2018 14:50, Andrew Dinn wrote: >> I have finally managed to draft a JEP to formally present the proposal I >> circulated a month or two back regarding support for MappedByteBuffer >> access to non-volatile memory. >> >> JEP JIRA: >>    https://bugs.

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

Hi Chris, It is important to be clear about how whitespace is treated and within the java.security file there are other uses that explicitly define how whitespace is used. I am more concerned about how command line properties are understood and used how we have to document them. Allowing whit

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

Roger, > On 20 Jul 2018, at 15:36, Roger Riggs wrote: > > Hi Chris, > > It is important to be clear about how whitespace is treated and within the > java.security file > there are other uses that explicitly define how whitespace is used. Right, and the usages are already inconsistent. Nothing

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

Hi Chris, The updated text is fine. Thanks for your consideration. The overlapping of configure options between java.security, net.properties, etc. and command line options is something to keep an eye on. Roger On 7/20/18 11:08 AM, Chris Hegarty wrote: Roger, On 20 Jul 2018, at 15:36, Ro

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

> On 20 Jul 2018, at 16:15, Roger Riggs wrote: > > Hi Chris, > > The updated text is fine. > Thanks for your consideration. Updated webrev as discussed. http://cr.openjdk.java.net/~chegar/8207846/webrev.01/ -Chris.

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

+1 Thanks, Roger On 7/20/18 11:33 AM, Chris Hegarty wrote: On 20 Jul 2018, at 16:15, Roger Riggs wrote: Hi Chris, The updated text is fine. Thanks for your consideration. Updated webrev as discussed. http://cr.openjdk.java.net/~chegar/8207846/webrev.01/ -Chris.

Re: RFR : 8207395: jar has issues with UNC-path arguments for the jar -C parameter [windows]

+1 On 7/20/18, 1:08 AM, Baesken, Matthias wrote: Thanks ! Sherman - are you fine with the latest version , if so I would push it . Best regards, Matthias -Original Message- From: Lindenmaier, Goetz Sent: Freitag, 20. Juli 2018 09:38 To: Baesken, Matthias; core-libs- d...@openjdk.jav

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

On 7/20/18 11:08 AM, Chris Hegarty wrote: This is ambiguous, and needs to be clarified. Surely, it is better to use the same wording as the serial filter: "Whitespace is significant and is considered part of the value." Kind of on the fence on that one. If this were a general property/value

Re: JDK 11 RFR(s) JDK-8206865 RMI activation tests fail with InvalidClassException

On 7/19/18 11:55 PM, Alan Bateman wrote: On 19/07/2018 22:22, Stuart Marks wrote: Please review this fix for some failing RMI activation tests. Some reflective code needed adjustment to take nestmates into account. This also removes the failing tests from the problem list. Webrev: http:/

Re: JDK 11 RFR(s) JDK-8206865 RMI activation tests fail with InvalidClassException

On 7/20/18 10:27 AM, Stuart Marks wrote: On 7/19/18 11:55 PM, Alan Bateman wrote: On 19/07/2018 22:22, Stuart Marks wrote: Please review this fix for some failing RMI activation tests. Some reflective code needed adjustment to take nestmates into account. This also removes the failing tests

Long chains created by direct Buffer::slice

src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template contains this, unfortunately without further comments: | public $Type$Buffer slice() { | int pos = this.position(); | int lim = this.limit(); | assert (pos <= lim); | int rem = (pos <= lim ? lim

Re: JDK 11 RFR(s) JDK-8206865 RMI activation tests fail with InvalidClassException

On 20/07/2018 18:27, Stuart Marks wrote: OK. Updated webrev: http://cr.openjdk.java.net/~smarks/reviews/8206865/webrev.1/ Looks good.

Re: Long chains created by direct Buffer::slice

2018/7/20 10:55:52 -0700, Florian Weimer : > ... > > The constructor invoked: > > | // For duplicates and slices > | // > | Direct$Type$Buffer$RW$$BO$(DirectBuffer db, // package-private > |int mark, int pos, int lim, int cap, > |

RFR: 8207263: Store the Configuration for system modules into CDS archive

Please review the following webrev that archives the system module boot layer Configuration (including all java objects reachable from the Configuration) in CDS archive. This is built on top of the earlier change for JDK-8202035 (https://bugs.openjdk.java.net/browse/JDK-8202035), which provides

JDK 12 RFR of JDK-8208060: Additional corrections of serial-related declarations

Hello, Another round of cleaning up the declarations of serial-related fields and methods: JDK-8208060: Additional corrections of serial-related declarations http://cr.openjdk.java.net/~darcy/8208060.0/ Summary of the issues being addressed: src/java.base/share/classes/java/net/I

Re: JDK 12 RFR of JDK-8208060: Additional corrections of serial-related declarations

Looks fine Joe, Thanks for the cleanup. Roger On 7/20/18 5:18 PM, Joseph D. Darcy wrote: Hello, Another round of cleaning up the declarations of serial-related fields and methods:     JDK-8208060: Additional corrections of serial-related declarations     http://cr.openjdk.java.net/~darcy/

Re: JDK 12 RFR of JDK-8208060: Additional corrections of serial-related declarations

Hi Joe, Looks fine > On Jul 20, 2018, at 5:18 PM, Joseph D. Darcy wrote: > > Hello, > > Another round of cleaning up the declarations of serial-related fields and > methods: > >JDK-8208060: Additional corrections of serial-related declarations >http://cr.openjdk.java.net/~darcy/82080

Re: JDK 12 RFR of JDK-8208060: Additional corrections of serial-related declarations

Looks fine. Mandy On 7/20/18 2:18 PM, Joseph D. Darcy wrote: Hello, Another round of cleaning up the declarations of serial-related fields and methods:     JDK-8208060: Additional corrections of serial-related declarations     http://cr.openjdk.java.net/~darcy/8208060.0/ Summary of the i

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

* Andrew Dinn: > Comments and suggestions for improvement would be very welcome. There are a bunch of typos in the JEP (“susbet”, “Rntime”). Formatting of the headlines looks wrong to me, too. On the implementation side, I find this a bit concerning: +// TODO - remove the following defines

Re: RFR 8207314 : Unnecessary reallocation when constructing WeakHashMap from a large Map

Hi Martin, Thank you for looking into this! Please see the comments inline. On 7/15/18 9:14 AM, Martin Buchholz wrote: Hi Ivan, Here are some thoughts while looking at this: --- WeakHashMap promises to have similar "capacity" handling to HashMap, but implementations (and doc?) seem more d