From zoltan.majo at oracle.com Wed Jul 1 08:54:26 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 01 Jul 2015 10:54:26 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> Message-ID: <5593AAC2.5070202@oracle.com> Hi, thank you, everyone, for the comments/suggestions/feedback! If no other issues come up, I intend to push the latest webrev (webrev.07) on Thursday (July 2). Best regards, Zoltan From claes.redestad at oracle.com Wed Jul 1 12:02:01 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 01 Jul 2015 14:02:01 +0200 Subject: RFR JDK-8075526: Need a way to read and write time in UTC In-Reply-To: <55930615.5080808@oracle.com> References: <55930615.5080808@oracle.com> Message-ID: <5593D6B9.60002@oracle.com> Hi, On 2015-06-30 23:11, Xueming Shen wrote: > Hi, > > Please help review and comment on this rfe. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8075526 > webrev: http://cr.openjdk.java.net/~sherman/8075526 I think this looks reasonable. I think we could consolidate the LocalDateTime<->xdostime conversions into ZipUtils along with and aligned with the code to convert UTC instants (ZipUtils::dosToJavaTime/javaToDosTime), which I've suggested should be converted into similar code anyhow: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031716.html The get32S changes seems like an unrelated but welcome optimization. > > Background info: > > The title of the RFE is a little "mis-leading". All the existing > set/get date-time > methods actually work with "UTC" time. Both the old pair > > public void setTime(long time); > public long getTime(); > > and the newly introduced pair > > pubic ZipEntry set/getLastModifiedTime(FileTime time); > public FileTime getLastModifiedTime(); > > are to set/get the last modified time in UTC time. However the ZIP > specification > clearly specifies that the "normal" date and time fields in the zip > file entry (loc and > cen) are defined as the date/time in dos format, which unfortunately > is a "local" > date-time. Therefor timezone conversion must be applied before/after > the utc time > can be set into/got from those fields (the UTC timestamps set/get by > the new pair > are therefor being set into/got from the "extended timestamp fields" > of the optional > extra data of each entry, those fields are specified as unix/utc > timestamp) > > We did not have an "local-date-time" abstract before the > java.time.LocalDateTime > was introduced in jdk8, the epoc date/time is the only date/time > abstract in java > vm. > > The proposed change here is to add yet another pair of set/get > modified time methods > > public void setTimeLocale(LocalDateTime time); > public LocalDateTime getTimeLocal(); > > to use the java.time.LocalDateTime type to set/get the modified time > into zip entry's > dos timestamp fields directly WITHOUT involving the timezone > conversion (implied, with > default TimeZone). > > Other than solving the pack/unpack problem raised in this RFE, it > should also help improve > the performance when local-date-time is actually desired when > interfacing with the ZipEntry > by eliminating the un-necessary/implied timezone conversion. For > example, in our jar tool, > currently we are "printing" the timestamp for zip entry "e" as > > new Date(e.getTime()).toString(); > > in which we are converting the local-date-time (ms-dos-formatted in > zip entry) to utc time > by using the default timezone (in ZipEntry), and then converting the > utc time (in Date) back > to the printable "local date time" again. > > It might be desired to format the "local-date-time" directly without > involving the timezone > conversion now via the proposed method > > java.time.format.DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss zzz > yyyy") > .withZone(java.time.ZoneId.systemDefault()); > .format(e.getTimeLocal() > > In above example, we still use the "system default timezone", however, > it is used > purely to output the zone name for the "zzz" (which the > Date.toString() does), not for conversion. > if the "zzz" is not required/needed, it can just be > > java.time.format.DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss > yyyy").format(e.getTimeLocal()); Since you're asking for opinions: I think we should try not to propagate the problem we're working around here (that values are printed/represented in a local time with no way of knowing what timezone the time was local to). If we can print the local timezone at little to no cost, why not? Thanks! /Claes > Comment/Opinion please. If we agree the approach/webrev, I will submit > the CCC before integration. > > Thanks, > -Sherman > From daniel.fuchs at oracle.com Wed Jul 1 13:02:58 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 01 Jul 2015 15:02:58 +0200 Subject: RFR- 8130238: Remove com.sun.org.apache.xalan.internal.xsltc.cmdline Message-ID: <5593E502.9090501@oracle.com> Hi, Please find below a trivial patch that removes com.sun.org.apache.xalan.internal.xsltc.cmdline This package is not used in the JDK. http://cr.openjdk.java.net/~dfuchs/webrev_8130238/webrev.00/ Jaxp tests passed locally (jaxp/test, jdk/test/javax/xml/jaxp) JCK for XML APIs also passed. More thorough testing through jprt under way... best regards, -- daniel From lance.andersen at oracle.com Wed Jul 1 13:06:50 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 1 Jul 2015 09:06:50 -0400 Subject: RFR- 8130238: Remove com.sun.org.apache.xalan.internal.xsltc.cmdline In-Reply-To: <5593E502.9090501@oracle.com> References: <5593E502.9090501@oracle.com> Message-ID: <55A39C26-F5B0-4698-B195-74F7A2FA8D8B@oracle.com> Looks fine Daniel, I doubt there will be any issues with nuking this Best Lance On Jul 1, 2015, at 9:02 AM, Daniel Fuchs wrote: > http://cr.openjdk.java.net/~dfuchs/webrev_8130238/webrev.00/ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From alexander.v.stepanov at oracle.com Wed Jul 1 14:35:35 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Wed, 01 Jul 2015 17:35:35 +0300 Subject: RFR [9] 8130247: fix some new tidy warnings from jaxws and CORBA Message-ID: <5593FAB7.4020204@oracle.com> 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

" tidy warnings fixed; some deprecated "" tags were replaced with "{@code }" as well. Thanks, Alexander From Alan.Bateman at oracle.com Wed Jul 1 14:43:56 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 Jul 2015 15:43:56 +0100 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5592B056.2060900@oracle.com> References: <5582D4CB.9090109@oracle.com> <558C2B60.6060502@oracle.com> <558C2E70.4050704@oracle.com> <558D0619.7090108@oracle.com> <558D1135.20908@oracle.com> <558D55D4.4080007@oracle.com> <558D5B03.3050506@oracle.com> <55910B87.9070001@oracle.com> <55911952.3070906@oracle.com> <55912B44.9090505@oracle.com> <55928735.1050601@oracle.com> <55929F84.7060605@oracle.com> <5592A756.3050801@oracle.com> <5592B056.2060900@oracle.com> Message-ID: <5593FCAC.7030609@oracle.com> On 30/06/2015 16:05, Jan Lahoda wrote: > > We need to override these "settings" for jshell (we use subclasses of > WindowsTerminal/UnixTerminal to get e.g. Ctrl-C detection - not sure > if we will want to generalize these additional features for jjs as > well). Is there a way to override them (just) for jshell using > ServiceLoader? Is extending these classes the normal way to customize? That makes it really awkward to cleanly separate the multiple implementations. BTW: I think what you in the current webrev is okay for now. -Alan From jan.lahoda at oracle.com Wed Jul 1 15:58:57 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 01 Jul 2015 17:58:57 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5593FCAC.7030609@oracle.com> References: <5582D4CB.9090109@oracle.com> <558C2B60.6060502@oracle.com> <558C2E70.4050704@oracle.com> <558D0619.7090108@oracle.com> <558D1135.20908@oracle.com> <558D55D4.4080007@oracle.com> <558D5B03.3050506@oracle.com> <55910B87.9070001@oracle.com> <55911952.3070906@oracle.com> <55912B44.9090505@oracle.com> <55928735.1050601@oracle.com> <55929F84.7060605@oracle.com> <5592A756.3050801@oracle.com> <5592B056.2060900@oracle.com> <5593FCAC.7030609@oracle.com> Message-ID: <55940E41.8000006@oracle.com> On 1.7.2015 16:43, Alan Bateman wrote: > > > On 30/06/2015 16:05, Jan Lahoda wrote: >> >> We need to override these "settings" for jshell (we use subclasses of >> WindowsTerminal/UnixTerminal to get e.g. Ctrl-C detection - not sure >> if we will want to generalize these additional features for jjs as >> well). Is there a way to override them (just) for jshell using >> ServiceLoader? > Is extending these classes the normal way to customize? That makes it > really awkward to cleanly separate the multiple implementations. Subclassing is used in JLine (there's for example NoInterruptUnixTerminal which is a subclass of UnixTerminal). We could use delegation for some of our purposes, but so far it seems we need to be able to use customized Terminals instead of the original ones, as e.g. WindowsTerminal is synthesizing an InputStream (which is then used instead of System.in) which we are intercepting and continuously reading from it awaiting Ctrl-C (when the user's code is running, Ctrl-C will interrupt it). > > BTW: I think what you in the current webrev is okay for now. Thanks! Jan > > -Alan From xueming.shen at oracle.com Wed Jul 1 17:05:51 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 01 Jul 2015 10:05:51 -0700 Subject: RFR JDK-8075526: Need a way to read and write time in UTC In-Reply-To: <5593D6B9.60002@oracle.com> References: <55930615.5080808@oracle.com> <5593D6B9.60002@oracle.com> Message-ID: <55941DEF.5000707@oracle.com> On 07/01/2015 05:02 AM, Claes Redestad wrote: > Hi, > > On 2015-06-30 23:11, Xueming Shen wrote: >> Hi, >> >> Please help review and comment on this rfe. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8075526 >> webrev: http://cr.openjdk.java.net/~sherman/8075526 > > I think this looks reasonable. > > I think we could consolidate the LocalDateTime<->xdostime > conversions into ZipUtils along with and aligned with the code > to convert UTC instants (ZipUtils::dosToJavaTime/javaToDosTime), > which I've suggested should be converted into similar code > anyhow: I would prefer to deal with JDK-8066644 issue separately. One of the concerns of replacing the j.u.Date with the java.time classes was the possible startup time regression that may be triggered by forcing the vm to load lots of java.time classes given all the jvm starts with loading bunch of jar files. As a matter of fact, we spent the time and did the prototype when doing JSR310, it did show startup regression back then... This might no longer be an issue if moving to module system, but it'd be better to have some data first. On the other hand, the proposed change here is for two new methods, no impact to any existing apps. > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031716.html > > The get32S changes seems like an unrelated but welcome > optimization. It's to fix the bug for negative date-time, which I missed when doing the unix timestamp support. The 32-bit date-time need to be signed to suport date-time before epoch. Well, you really should not have a zip file with last modified time before that though :-) Well in theory we still have the 2106 32-bit overflow issue for the unix timestamp, should find a solution later. >> In above example, we still use the "system default timezone", however, it is used >> purely to output the zone name for the "zzz" (which the Date.toString() does), not for conversion. >> if the "zzz" is not required/needed, it can just be >> >> java.time.format.DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss yyyy").format(e.getTimeLocal()); > > > Since you're asking for opinions: > > I think we should try not to propagate the problem we're working around here > (that values are printed/represented in a local time with no way of knowing what > timezone the time was local to). If we can print the local timezone at little to no > cost, why not? > We actually might not be able to just change the jar tool to use the new LocalDateTime interface. It will be an "incompatible" change again :-) As in the past there were regression complains that there are tools "over there" that have dependency on the output format of the jar tool. Like my example, even with "zzz", the j.t.f.DTF will output the zonename for local here now as "pt" but the Date.toString() go with "PDT", because without tz lookup (with either a ldt or an instant) you don't know if it's PDT or PST. Well someone says it really does not matter:-) Thanks for the review. -Sherman From joe.darcy at oracle.com Wed Jul 1 18:24:53 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 01 Jul 2015 11:24:53 -0700 Subject: RFR [9] 8130247: fix some new tidy warnings from jaxws and CORBA In-Reply-To: <5593FAB7.4020204@oracle.com> References: <5593FAB7.4020204@oracle.com> Message-ID: <55943075.6030906@oracle.com> Hello, Looks fine to me; thanks, -Joe On 7/1/2015 7:35 AM, alexander stepanov wrote: > 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

" tidy > warnings fixed; some deprecated "" tags were replaced with "{@code > }" as well. > > Thanks, > Alexander > From kumar.x.srinivasan at oracle.com Wed Jul 1 21:09:10 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 01 Jul 2015 14:09:10 -0700 Subject: RFR JDK-8075526: Need a way to read and write time in UTC In-Reply-To: <55930615.5080808@oracle.com> References: <55930615.5080808@oracle.com> Message-ID: <559456F6.2030704@oracle.com> Hi Sherman, Thanks for solving this!, this has been a long standing issue for pack200. The changes looks generally good, I have also tested the initial prototype with pack200. Some nitpicks: TestLocalTime.java: 0. line 51, s/supoprt/support/ 1. line 63, you have a "}" out of place 2. line 71, misplaced "," 3. line 111: extra LF. Thanks Kumar On 6/30/2015 2:11 PM, Xueming Shen wrote: > Hi, > > Please help review and comment on this rfe. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8075526 > webrev: http://cr.openjdk.java.net/~sherman/8075526 > > Background info: > > The title of the RFE is a little "mis-leading". All the existing > set/get date-time > methods actually work with "UTC" time. Both the old pair > > public void setTime(long time); > public long getTime(); > > and the newly introduced pair > > pubic ZipEntry set/getLastModifiedTime(FileTime time); > public FileTime getLastModifiedTime(); > > are to set/get the last modified time in UTC time. However the ZIP > specification > clearly specifies that the "normal" date and time fields in the zip > file entry (loc and > cen) are defined as the date/time in dos format, which unfortunately > is a "local" > date-time. Therefor timezone conversion must be applied before/after > the utc time > can be set into/got from those fields (the UTC timestamps set/get by > the new pair > are therefor being set into/got from the "extended timestamp fields" > of the optional > extra data of each entry, those fields are specified as unix/utc > timestamp) > > We did not have an "local-date-time" abstract before the > java.time.LocalDateTime > was introduced in jdk8, the epoc date/time is the only date/time > abstract in java > vm. > > The proposed change here is to add yet another pair of set/get > modified time methods > > public void setTimeLocale(LocalDateTime time); > public LocalDateTime getTimeLocal(); > > to use the java.time.LocalDateTime type to set/get the modified time > into zip entry's > dos timestamp fields directly WITHOUT involving the timezone > conversion (implied, with > default TimeZone). > > Other than solving the pack/unpack problem raised in this RFE, it > should also help improve > the performance when local-date-time is actually desired when > interfacing with the ZipEntry > by eliminating the un-necessary/implied timezone conversion. For > example, in our jar tool, > currently we are "printing" the timestamp for zip entry "e" as > > new Date(e.getTime()).toString(); > > in which we are converting the local-date-time (ms-dos-formatted in > zip entry) to utc time > by using the default timezone (in ZipEntry), and then converting the > utc time (in Date) back > to the printable "local date time" again. > > It might be desired to format the "local-date-time" directly without > involving the timezone > conversion now via the proposed method > > java.time.format.DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss zzz > yyyy") > .withZone(java.time.ZoneId.systemDefault()); > .format(e.getTimeLocal() > > In above example, we still use the "system default timezone", however, > it is used > purely to output the zone name for the "zzz" (which the > Date.toString() does), not for conversion. > if the "zzz" is not required/needed, it can just be > > java.time.format.DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss > yyyy").format(e.getTimeLocal()); > > Comment/Opinion please. If we agree the approach/webrev, I will submit > the CCC before integration. > > Thanks, > -Sherman > From ivan.gerasimov at oracle.com Wed Jul 1 21:18:33 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 02 Jul 2015 00:18:33 +0300 Subject: RFR [S] 8077242: (str) Optimize AbstractStringBuilder.append(CharSequence, int, int) for String argument In-Reply-To: References: <558EB1E1.708@oracle.com> Message-ID: <55945929.90202@oracle.com> Thank you Martin for review! On 01.07.2015 0:59, Martin Buchholz wrote: > This looks good. > > Because we already have append(String) it *may* be a good idea to add > append(String, int, int). > I found only a dozen of the places in JDK where this method is applicable, so I thought it doesn't seem to worth a change in the API. > See also my failure to add getChars to CharSequence itself. > If we (you?) could make that happen, that would eliminate the need for > instanceof String etc. > Yes, it was my initial thought too: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-May/033285.html I guess, it's not a problem to add default CharSequence.getChars(). The problem is to call it safely. If there were a way to enforce all the derived classes except a few trusted stick to the default implementation, it would be possible to use getChars in sb.append(). For now, I limited the scope of the change, so that changing sb.append(str.substring(a, b)) to sb.append(str, a, b) will be at least no slower. Sincerely yours, Ivan > On Sat, Jun 27, 2015 at 7:23 AM, Ivan Gerasimov > > wrote: > > Hello! > > AbstractStringBuilder, which is base for StringBuilder and > StringBuffer has a method for appending a sub-sequence of a > CharSequence. > Internally, it copies one char at a time in a loop, picking them > up with CharSequence.charAt() method. > For the case when the argument is a String, it can be done more > efficiently, by a call to String.getChars(). > Since String is a final class, it should be safe to pass 'value' > to its method. > > I've also found a few places in JDK where code can be done more > efficient, using this optimization. > > Would you please help review this fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8077242 > WEBREV: http://cr.openjdk.java.net/~igerasim/8077242/02/webrev/ > > > Sincerely yours, > Ivan > > From xueming.shen at oracle.com Wed Jul 1 22:19:27 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 01 Jul 2015 15:19:27 -0700 Subject: RFR JDK-8075526: Need a way to read and write time in UTC In-Reply-To: <559456F6.2030704@oracle.com> References: <55930615.5080808@oracle.com> <559456F6.2030704@oracle.com> Message-ID: <5594676F.60007@oracle.com> Hi Kumar, thanks for the comments. Webrev has been updated according. On 7/1/15 2:09 PM, Kumar Srinivasan wrote: > Hi Sherman, > > Thanks for solving this!, this has been a long standing issue for > pack200. > > The changes looks generally good, I have also tested the initial > prototype > with pack200. > > Some nitpicks: > TestLocalTime.java: > 0. line 51, s/supoprt/support/ > 1. line 63, you have a "}" out of place > 2. line 71, misplaced "," > 3. line 111: extra LF. > > Thanks > Kumar > > On 6/30/2015 2:11 PM, Xueming Shen wrote: >> Hi, >> >> Please help review and comment on this rfe. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8075526 >> webrev: http://cr.openjdk.java.net/~sherman/8075526 >> >> Background info: >> >> The title of the RFE is a little "mis-leading". All the existing >> set/get date-time >> methods actually work with "UTC" time. Both the old pair >> >> public void setTime(long time); >> public long getTime(); >> >> and the newly introduced pair >> >> pubic ZipEntry set/getLastModifiedTime(FileTime time); >> public FileTime getLastModifiedTime(); >> >> are to set/get the last modified time in UTC time. However the ZIP >> specification >> clearly specifies that the "normal" date and time fields in the zip >> file entry (loc and >> cen) are defined as the date/time in dos format, which unfortunately >> is a "local" >> date-time. Therefor timezone conversion must be applied before/after >> the utc time >> can be set into/got from those fields (the UTC timestamps set/get by >> the new pair >> are therefor being set into/got from the "extended timestamp fields" >> of the optional >> extra data of each entry, those fields are specified as unix/utc >> timestamp) >> >> We did not have an "local-date-time" abstract before the >> java.time.LocalDateTime >> was introduced in jdk8, the epoc date/time is the only date/time >> abstract in java >> vm. >> >> The proposed change here is to add yet another pair of set/get >> modified time methods >> >> public void setTimeLocale(LocalDateTime time); >> public LocalDateTime getTimeLocal(); >> >> to use the java.time.LocalDateTime type to set/get the modified time >> into zip entry's >> dos timestamp fields directly WITHOUT involving the timezone >> conversion (implied, with >> default TimeZone). >> >> Other than solving the pack/unpack problem raised in this RFE, it >> should also help improve >> the performance when local-date-time is actually desired when >> interfacing with the ZipEntry >> by eliminating the un-necessary/implied timezone conversion. For >> example, in our jar tool, >> currently we are "printing" the timestamp for zip entry "e" as >> >> new Date(e.getTime()).toString(); >> >> in which we are converting the local-date-time (ms-dos-formatted in >> zip entry) to utc time >> by using the default timezone (in ZipEntry), and then converting the >> utc time (in Date) back >> to the printable "local date time" again. >> >> It might be desired to format the "local-date-time" directly without >> involving the timezone >> conversion now via the proposed method >> >> java.time.format.DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss zzz >> yyyy") >> .withZone(java.time.ZoneId.systemDefault()); >> .format(e.getTimeLocal() >> >> In above example, we still use the "system default timezone", >> however, it is used >> purely to output the zone name for the "zzz" (which the >> Date.toString() does), not for conversion. >> if the "zzz" is not required/needed, it can just be >> >> java.time.format.DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss >> yyyy").format(e.getTimeLocal()); >> >> Comment/Opinion please. If we agree the approach/webrev, I will >> submit the CCC before integration. >> >> Thanks, >> -Sherman >> > From peter.levart at gmail.com Thu Jul 2 07:32:25 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 02 Jul 2015 09:32:25 +0200 Subject: RFR 9: 8078099 : (process) ProcessHandle should uniquely identify processes In-Reply-To: <5588257A.5060802@Oracle.com> References: <5588257A.5060802@Oracle.com> Message-ID: <5594E909.3060003@gmail.com> Hi Roger, I looked at the code briefly and have the following comments: For ProcessHandleImpl_macosx.c, in method getProcessPids0: 224 // Get buffer size needed to read all processes 225 int mib[4] = {CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0}; 226 if (sysctl(mib, 4, NULL, &bufSize, NULL, 0) < 0) { 227 JNU_ThrowByNameWithLastError(env, 228 "java/lang/RuntimeException", "sysctl failed"); 229 return -1; 230 } 231 232 // Allocate buffer big enough for all processes 233 void *buffer = malloc(bufSize); 234 if (buffer == NULL) { 235 JNU_ThrowOutOfMemoryError(env, "malloc failed"); 236 return -1; 237 } 238 239 // Read process info for all processes 240 if (sysctl(mib, 4, buffer, &bufSize, NULL, 0) < 0) { 241 JNU_ThrowByNameWithLastError(env, 242 "java/lang/RuntimeException", "sysctl failed"); 243 free(buffer); 244 return -1; 245 } ... the 1st call to sysctl is used to measure the size of the needed buffer and the 2nd call fills-in the buffer. The documentation for sysctl says: " The information is copied into the buffer specified by oldp. The size of the buffer is given by the location specified by oldlenp before the call, and that location gives the amount of data copied after a successful call and after a call that returns with the error code ENOMEM. If the amount of data available is greater than the size of the buffer supplied, the call supplies as much data as fits in the buffer provided and returns with the error code ENOMEM. If the old value is not desired, oldp and oldlenp should be set to NULL. The size of the available data can be determined by calling sysctl() with the NULL argument for oldp. The size of the available data will be returned in the location pointed to by oldlenp. For some opera-tions, operations, tions, the amount of space may change often. For these operations, the system attempts to round up so that the returned size is large enough for a call to return the data shortly thereafter." So while not very probable, it can happen that you get ENOMEM from 2nd call because of underestimated buffer size. Would it be better to retry (re)allocation of buffer and 2nd call in a loop with new estimation returned from previous call while the error is ENOMEM? Another suggestion: What would it be if the buffer size estimation was not computed by a call to sysctl with NULL buffer, but was taken from the passed-in resulting array size(s). In case the user passes-in arrays of sufficient size, you can avoid double invocation of sysctl. Also, if ENOMEM happens, you can just return the result obtained and the new estimation - no looping in native code. The UNIX, Solaris and Windows variants look good. Regards, Peter On 06/22/2015 05:10 PM, Roger Riggs wrote: > Please review changes to ProcessHandle implementation to uniquely > identify > processes based on the start time provided by the OS. It addresses the > issue > of PID reuse. > > This is the implementation of the ProcessHandle.equals() spec change in > 8129344 : (process) ProcessHandle instances should define equals > and be value-based > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-starttime-8078099/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8078099 > > Thanks, Roger > From alexander.v.stepanov at oracle.com Thu Jul 2 11:05:27 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Thu, 02 Jul 2015 14:05:27 +0300 Subject: RFR [9] 8130247: fix some new tidy warnings from jaxws and CORBA In-Reply-To: <55943075.6030906@oracle.com> References: <5593FAB7.4020204@oracle.com> <55943075.6030906@oracle.com> Message-ID: <55951AF7.3000305@oracle.com> Thanks! On 01.07.2015 21:24, joe darcy wrote: > Hello, > > Looks fine to me; thanks, > > -Joe > > On 7/1/2015 7:35 AM, alexander stepanov wrote: >> 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

" tidy >> warnings fixed; some deprecated "" tags were replaced with >> "{@code }" as well. >> >> Thanks, >> Alexander >> > From jan.lahoda at oracle.com Thu Jul 2 11:41:56 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 02 Jul 2015 13:41:56 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: References: <5582D4CB.9090109@oracle.com> Message-ID: <55952384.6070906@oracle.com> Hi Ben, (Sorry for a late answer.) Yes, this builds with JDK 9 compiler as part of the JDK build. JLine's own build is uses -source/-target 1.5, which is no longer supported in JDK 9 javac, so this may be one of the issues there. Thanks, Jan On 18.6.2015 22:01, Ben Evans wrote: > Hi, > > Has this been tested with a JDK 9 compiler? > > The last time I checked JLine wouldn't build with an OpenJDK 9 javac. > > Thanks, > > Ben > > On 18 Jun 2015 3:26 pm, "Jan Lahoda" > wrote: > > Hello, > > I am proposing to add JLine 2.12.1 into the jdk repository for use > by the Java and Nashorn REPLs. Full patch is available here: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ > > To aid the review, I've split this patch into to smaller patches: > -a patch that only adds unmodified jline sources at appropriate > places in the jdk repository: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ > > -a patch that shows the additional changes I've done: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ > > This split is intended solely to simplify reviewing, my plan is to > integrate this as a single patch. > > The main additional changes are: > -plugging the new module, jdk.jline, into the JDK build. Currently, > the JLine packages are exported only to jdk.scripting.nashorn (the > plan is to also export them to the future jdk.jshell module). (The > patch is not adding the dependency from jdk.scripting.nashorn to > jdk.jline, though - I expect that to be added when needed.) > -the sources are re-packaged from package "jline" to > "jdk.internal.jline" > -removing trailing whitespace, adding newlines at the end of the > files, encoding characters that are not ASCII > -avoiding the dependency on another library, jansi, by > reimplementing two elements that were used from the other library. > These are mainly the changes in WindowsTerminal and > ConsoleReader.java. This also includes the WindowsTerminal.cpp > native library. The native part is heavily inspired by: > http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html > As I am not experienced in native programming, comments to the > native part would be particularly useful. > -changes to resolve javac warnings in JLine. > -tests for some of the added functionality. > > Any comments are welcome! > > Thanks, > Jan > From Alan.Bateman at oracle.com Thu Jul 2 12:48:38 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 Jul 2015 13:48:38 +0100 Subject: RFR(XXS): 8130315: Fix wrong prototype of GrowKnownVMs() in java.c In-Reply-To: References: Message-ID: <55953326.6020601@oracle.com> On 02/07/2015 13:43, Volker Simonis wrote: > Hi, > > could someone please review this tiny fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8130315/ > https://bugs.openjdk.java.net/browse/JDK-8130315 > > Because of this bug jdk9 doesn't build without > '--disable-warnings-as-errors' on SLES 12 with gcc 4.8.3 > (moving this to core-libs-dev). This looks right. -Alan. From volker.simonis at gmail.com Thu Jul 2 13:03:37 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 2 Jul 2015 15:03:37 +0200 Subject: RFR(XXS): 8130315: Fix wrong prototype of GrowKnownVMs() in java.c In-Reply-To: <55953326.6020601@oracle.com> References: <55953326.6020601@oracle.com> Message-ID: Thanks Alan and sorry for choosing the wrong list once again :) Volker On Thu, Jul 2, 2015 at 2:48 PM, Alan Bateman wrote: > On 02/07/2015 13:43, Volker Simonis wrote: >> >> Hi, >> >> could someone please review this tiny fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8130315/ >> https://bugs.openjdk.java.net/browse/JDK-8130315 >> >> Because of this bug jdk9 doesn't build without >> '--disable-warnings-as-errors' on SLES 12 with gcc 4.8.3 >> > (moving this to core-libs-dev). > > This looks right. > > -Alan. From kumar.x.srinivasan at oracle.com Thu Jul 2 13:09:55 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 02 Jul 2015 06:09:55 -0700 Subject: RFR(XXS): 8130315: Fix wrong prototype of GrowKnownVMs() in java.c In-Reply-To: References: <55953326.6020601@oracle.com> Message-ID: <55953823.9080901@oracle.com> Looks good and thanks for fixing this. I have marked the jbs issue with a "noreg-trivial". Kumar On 7/2/2015 6:03 AM, Volker Simonis wrote: > Thanks Alan and sorry for choosing the wrong list once again :) > > Volker > > > On Thu, Jul 2, 2015 at 2:48 PM, Alan Bateman wrote: >> On 02/07/2015 13:43, Volker Simonis wrote: >>> Hi, >>> >>> could someone please review this tiny fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8130315/ >>> https://bugs.openjdk.java.net/browse/JDK-8130315 >>> >>> Because of this bug jdk9 doesn't build without >>> '--disable-warnings-as-errors' on SLES 12 with gcc 4.8.3 >>> >> (moving this to core-libs-dev). >> >> This looks right. >> >> -Alan. From volker.simonis at gmail.com Thu Jul 2 13:23:19 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 2 Jul 2015 15:23:19 +0200 Subject: RFR(XXS): 8130315: Fix wrong prototype of GrowKnownVMs() in java.c In-Reply-To: <55953823.9080901@oracle.com> References: <55953326.6020601@oracle.com> <55953823.9080901@oracle.com> Message-ID: Thanks Kumar! On Thu, Jul 2, 2015 at 3:09 PM, Kumar Srinivasan wrote: > Looks good and thanks for fixing this. > > I have marked the jbs issue with a "noreg-trivial". > > Kumar > > > On 7/2/2015 6:03 AM, Volker Simonis wrote: >> >> Thanks Alan and sorry for choosing the wrong list once again :) >> >> Volker >> >> >> On Thu, Jul 2, 2015 at 2:48 PM, Alan Bateman >> wrote: >>> >>> On 02/07/2015 13:43, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> could someone please review this tiny fix: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8130315/ >>>> https://bugs.openjdk.java.net/browse/JDK-8130315 >>>> >>>> Because of this bug jdk9 doesn't build without >>>> '--disable-warnings-as-errors' on SLES 12 with gcc 4.8.3 >>>> >>> (moving this to core-libs-dev). >>> >>> This looks right. >>> >>> -Alan. > > From peter.levart at gmail.com Thu Jul 2 13:56:03 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 02 Jul 2015 15:56:03 +0200 Subject: Exception handling in Files.walk and Files.find Message-ID: <559542F3.2030409@gmail.com> Hi, Recently I wanted to use Files.walk method returning a Stream to scan a directory of files. I quickly learned that it is of limited use. For example, the following code: long pngFilesCount = Files.walk(Paths.get("/usr")) .filter(path -> path.toString().endsWith(".png")) .count(); Throws exception on my computer: Exception in thread "main" java.io.UncheckedIOException: java.nio.file.AccessDeniedException: /usr/share/polkit-1/rules.d This is a consequence of the fact that some files and/or directories in the tree being scanned are not accessible to my user account on the computer. If I wanted to skip those files/directories I would be forced to use different API (Files.walkFileTree using FileVisitor which can handle exceptions too). I propose the addition of overloads to Files.walk and Files.find that take an additional parameter of type Consumer to be responsible for handling IOExceptions that are thrown while walking the file tree: http://cr.openjdk.java.net/~plevart/jdk9-dev/Files.walkIOException/webrev.01/ Ignoring AccessDeniedException(s) in above code can therefore be coded as: long pngFilesCount = Files.walk(Paths.get("/usr"), Integer.MAX_VALUE, ioe -> { if (!(ioe instanceof AccessDeniedException)) { throw new UncheckedIOException(ioe); } }) .filter(path -> path.toString().endsWith(".png")) .count(); What do you think? Regards, Peter From jan.lahoda at oracle.com Thu Jul 2 15:33:41 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 02 Jul 2015 17:33:41 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <55940E41.8000006@oracle.com> References: <5582D4CB.9090109@oracle.com> <558C2B60.6060502@oracle.com> <558C2E70.4050704@oracle.com> <558D0619.7090108@oracle.com> <558D1135.20908@oracle.com> <558D55D4.4080007@oracle.com> <558D5B03.3050506@oracle.com> <55910B87.9070001@oracle.com> <55911952.3070906@oracle.com> <55912B44.9090505@oracle.com> <55928735.1050601@oracle.com> <55929F84.7060605@oracle.com> <5592A756.3050801@oracle.com> <5592B056.2060900@oracle.com> <5593FCAC.7030609@oracle.com> <55940E41.8000006@oracle.com> Message-ID: <559559D5.8090608@oracle.com> On 1.7.2015 17:58, Jan Lahoda wrote: > On 1.7.2015 16:43, Alan Bateman wrote: >> >> >> On 30/06/2015 16:05, Jan Lahoda wrote: >>> >>> We need to override these "settings" for jshell (we use subclasses of >>> WindowsTerminal/UnixTerminal to get e.g. Ctrl-C detection - not sure >>> if we will want to generalize these additional features for jjs as >>> well). Is there a way to override them (just) for jshell using >>> ServiceLoader? >> Is extending these classes the normal way to customize? That makes it >> really awkward to cleanly separate the multiple implementations. > > Subclassing is used in JLine (there's for example > NoInterruptUnixTerminal which is a subclass of UnixTerminal). We could > use delegation for some of our purposes, but so far it seems we need to > be able to use customized Terminals instead of the original ones, as > e.g. WindowsTerminal is synthesizing an InputStream (which is then used > instead of System.in) which we are intercepting and continuously reading > from it awaiting Ctrl-C (when the user's code is running, Ctrl-C will > interrupt it). > >> >> BTW: I think what you in the current webrev is okay for now. > > Thanks! One more iteration, now when the WindowsTerminal loads the library in the static initializer, it can only be used on Windows, and so the KeyConversionTest can (in the current form) only run on Windows, so using @requires to achieve that (sorry I did not realize this sooner). Also, I did the change Remi suggested with Map.getOrDefault. The webrev: http://cr.openjdk.java.net/~jlahoda/8080679/webrev.06/full/ Delta against previous: http://cr.openjdk.java.net/~jlahoda/8080679/webrev.06/delta/ Is this OK? Thanks, Jan > > Jan > >> >> -Alan From zoltan.majo at oracle.com Thu Jul 2 15:39:52 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 02 Jul 2015 17:39:52 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <5593AAC2.5070202@oracle.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> <5593AAC2.5070202@oracle.com> Message-ID: <55955B48.2070108@oracle.com> Hi, I updated the code to also consider intrinsics that were recently added for the following methods: - java.math.BigInteger.implMontgomeryMultiply - java.math.BigInteger.implMontgomerySquare - java.util.zip.CRC32C.updateBytes - java.util.zip.CRC32C.updateDirectByteBuffer In the latest webrev (webrev.08) three files have changed relative to the previous webrev (webrev.07): - hotspot: src/share/vm/classfile/vmSymbols.hpp (merge conflict) - jdk: src/java.base/share/classes/java/util/zip/CRC32.java and src/java.base/share/classes/java/math/BigInteger.java (annotations were added to intrinsified methods) Here is the updated webrev: - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.08/ - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.08/ All JPRT tests pass. I plan to push the newest webrev (webrev.08) on Friday (July 3) if no other issues come up by then. Thank you and best regards, Zoltan On 07/01/2015 10:54 AM, Zolt?n Maj? wrote: > Hi, > > > thank you, everyone, for the comments/suggestions/feedback! If no > other issues come up, I intend to push the latest webrev (webrev.07) > on Thursday (July 2). > > Best regards, > > > Zoltan > From stevenschlansker at gmail.com Thu Jul 2 17:11:57 2015 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Thu, 2 Jul 2015 10:11:57 -0700 Subject: Exception handling in Files.walk and Files.find In-Reply-To: <559542F3.2030409@gmail.com> References: <559542F3.2030409@gmail.com> Message-ID: How about BiConsumer, unless the Path is easily accessible otherwise? On Jul 2, 2015, at 6:56 AM, Peter Levart wrote: > Hi, > > Recently I wanted to use Files.walk method returning a Stream to scan a directory of files. I quickly learned that it is of limited use. For example, the following code: > > long pngFilesCount = Files.walk(Paths.get("/usr")) > .filter(path -> path.toString().endsWith(".png")) > .count(); > > Throws exception on my computer: > > Exception in thread "main" java.io.UncheckedIOException: java.nio.file.AccessDeniedException: /usr/share/polkit-1/rules.d > > This is a consequence of the fact that some files and/or directories in the tree being scanned are not accessible to my user account on the computer. If I wanted to skip those files/directories I would be forced to use different API (Files.walkFileTree using FileVisitor which can handle exceptions too). > > I propose the addition of overloads to Files.walk and Files.find that take an additional parameter of type Consumer to be responsible for handling IOExceptions that are thrown while walking the file tree: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Files.walkIOException/webrev.01/ > > Ignoring AccessDeniedException(s) in above code can therefore be coded as: > > long pngFilesCount = Files.walk(Paths.get("/usr"), Integer.MAX_VALUE, > ioe -> { > if (!(ioe instanceof AccessDeniedException)) { > throw new UncheckedIOException(ioe); > } > }) > .filter(path -> path.toString().endsWith(".png")) > .count(); > > What do you think? > > Regards, Peter > From mandy.chung at oracle.com Fri Jul 3 07:08:02 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 3 Jul 2015 00:08:02 -0700 Subject: JEP 132: More-prompt finalization In-Reply-To: <558E6D72.1050505@gmail.com> References: <55674C6E.8050509@gmail.com> <5567CC5E.7000102@oracle.com> <8DBC7345-09D8-458F-9017-298D1E620F86@gmail.com> <6882C9A35DFB9B4FA2779F7BF5B9757D20761169A2@GSCMAMP06EX.firmwide.corp.gs.com> <556B61B0.5030708@gmail.com> <55767D37.4080100@gmail.com> <5587BA4E.3050103@gmail.com> <73CD8857-E400-4F30-9651-39ECBE19CC51@oracle.com> <558E6D72.1050505@gmail.com> Message-ID: <3E5CCF95-845B-49B8-BAA8-9949C527312C@oracle.com> > On Jun 27, 2015, at 2:31 AM, Peter Levart wrote: > >>> Are any of the features of this prototype interesting for you and worth pursuing further? >> This mostly appears to be a question for core-libs; that's where the >> proposed changes are located. GC is involved mostly to ensure the >> internal APIs between the collector and reference processing are >> maintained. >> >> My personal opinion is that we should be working toward a day when we >> can remove the finalize function, rather than trying to make the >> infrastructure around it faster. But clearly that day won't be soon, >> if ever. >> I agree. We should put efforts in removing our JDK use of finalizer, as many as we can, and that will help tune the design of any new Cleaner-like API. > > The infrastructure is shared for all Reference kinds. Improving it impacts all reference processing, not only finalization. If it makes finalization faster too, it can be viewed as just a coincidence ;-) > Improving the reference processing is definitely attractive work. This work is not a small task and also due to its complexity, we will have to look at this closely after several months once we complete some feature works targeted for JDK 9. We probably should write a JEP for this when that time comes. > But I agree. We should move internal code away from finalization and also give users viable alternatives that would make finalize() method obsolete one day. +1. Mandy From peter.levart at gmail.com Fri Jul 3 08:25:02 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 03 Jul 2015 10:25:02 +0200 Subject: Exception handling in Files.walk and Files.find In-Reply-To: References: <559542F3.2030409@gmail.com> Message-ID: <559646DE.7000603@gmail.com> Hi Steven, I thought of that too. Yes, it can even be a BiPredicate: http://cr.openjdk.java.net/~plevart/jdk9-dev/Files.walkIOException/webrev.02/ If one of the proposed APIs is acceptable, I can push this further and add required test(s), etc... Regards, Peter On 07/02/2015 07:11 PM, Steven Schlansker wrote: > How about BiConsumer, unless the Path is easily accessible otherwise? > > On Jul 2, 2015, at 6:56 AM, Peter Levart wrote: > >> Hi, >> >> Recently I wanted to use Files.walk method returning a Stream to scan a directory of files. I quickly learned that it is of limited use. For example, the following code: >> >> long pngFilesCount = Files.walk(Paths.get("/usr")) >> .filter(path -> path.toString().endsWith(".png")) >> .count(); >> >> Throws exception on my computer: >> >> Exception in thread "main" java.io.UncheckedIOException: java.nio.file.AccessDeniedException: /usr/share/polkit-1/rules.d >> >> This is a consequence of the fact that some files and/or directories in the tree being scanned are not accessible to my user account on the computer. If I wanted to skip those files/directories I would be forced to use different API (Files.walkFileTree using FileVisitor which can handle exceptions too). >> >> I propose the addition of overloads to Files.walk and Files.find that take an additional parameter of type Consumer to be responsible for handling IOExceptions that are thrown while walking the file tree: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Files.walkIOException/webrev.01/ >> >> Ignoring AccessDeniedException(s) in above code can therefore be coded as: >> >> long pngFilesCount = Files.walk(Paths.get("/usr"), Integer.MAX_VALUE, >> ioe -> { >> if (!(ioe instanceof AccessDeniedException)) { >> throw new UncheckedIOException(ioe); >> } >> }) >> .filter(path -> path.toString().endsWith(".png")) >> .count(); >> >> What do you think? >> >> Regards, Peter >> From spederse at redhat.com Sat Jul 4 23:27:19 2015 From: spederse at redhat.com (=?iso-8859-1?Q?St=E5le?= W Pedersen) Date: Sun, 5 Jul 2015 01:27:19 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs Message-ID: <20150704232719.GA26601@lappers.redhat.com> hi, sorry, im a bit late to this discussion, i wasnt aware of any interest for adding jline2 to the jdk until late this week. im working on a project called ?sh/aesh: https://github.com/aeshell/aesh its another java console project derived from jline/jline2. it started as an extension/fork of jline2 and evolved into a separate project. im not quite sure what the reason behind choosing jline2 for the jdk, but i just wanted to give some info on ?sh and what it does compared to jline2. ?sh has all the same functionalities as jline2 and has a number of additional features: - history (search, persistence) - undo/redo - paste buffer - redirect/pipeline - alias +++ jline2 has several bugs regarding input that is resolved in ?sh. one of the bigger differences between jline2 and ?sh is that ?sh isnt locking in the same way as jline2, but rather has a callback when input is given. this give better flexibility for the user when creating commands. perhaps the biggest difference is that ?sh provides two apis for the developer. one is more low-level and similar to jline2: https://gist.github.com/stalep/cea6fbfee1de2b1ac6e4 plus a high level api that ?sh provides for the developer to create commands. https://gist.github.com/stalep/98103347df1dd9b67fd1 in this example we create a ls command that will automatically complete filenames/directories and inject the values into the list field. this it just a very simple example, the api supports converters/completers/activators/renders/+++ we added this api because we noticed that the developers needed to write a lot of code to parse user input. with this api they can focus on creating commands and not parse for input data. if there is any interest in using ?sh in the jdk we would do whatever we can to help you integrate it. ?sh has evolved fairly quickly and tries to resolve any bugs/issues as quickly as possible. it is also supported by red hat so we can promise that this project will not be abandoned any time soon. regards, st?le From mcnepp02 at googlemail.com Sun Jul 5 13:13:36 2015 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Sun, 05 Jul 2015 15:13:36 +0200 Subject: Bad interaction between wildcard and functional interface conversion In-Reply-To: <55914CED.4080803@univ-mlv.fr> References: <5565E2C9.7050009@univ-mlv.fr> <55914CED.4080803@univ-mlv.fr> Message-ID: <55992D80.9090908@googlemail.com> Hi Remi, I think it's fair to say that I know my share of Java Generics, so I generally understand the motivation of introducing wildcards into method signatures. Just in your particular case (and in your original example), I don't see what you gain by having the "super" wildcard for the outer Consumer's type parameter. If you leave it out, the code compiles without problems: static Function factory(Consumer> consumer, Function ifAbsent) { ... } Can you enlighten me? Cheers, Gernot Am 29.06.2015 15:49, schrieb Remi Forax: > Bitten again by the very same issue :( > > The following code doesn't compile: > static Function factory(Consumer super K, ? super T>> consumer, Function > ifAbsent) { > HashMap map = new HashMap<>(); > consumer.accept(map::put); > return key -> map.computeIfAbsent(key, ifAbsent); > } > > I really think that it's a serious bug, the only workaround is to not > use wildcards correctly, i.e. > Function factory(Consumer T>> consumer, Function ifAbsent) > > cheers, > R?mi > > On 05/27/2015 05:29 PM, Remi Forax wrote: >> Hi all, >> >> The way the conversion between a lambda (or a method reference) and a >> functional interface is specified doesn't take wildcard (exactly ? >> super) into account making the concept of contravariance of >> functional interface less intuitive that it should be. >> >> The following code compiles: >> private static void create(Consumer> consumer) { >> consumer.accept(s -> System.out.println(s)); >> } >> >> This one doesn't compile because "? super Consumer" >> is not a functional interface: >> private static void create2(Consumer> String>> consumer) { >> consumer.accept(s -> System.out.println(s)); >> } >> >> The workaround is to introduce a cast :( >> private static void create3(Consumer> String>> consumer) { >> consumer.accept((Consumer)s -> System.out.println(s)); >> } >> which is stupid in this case because there is no ambiguity. >> This cast is just here because the JLS doesn't consider that ? super >> Consumer<...> is a valid target type >> >> IMO, this bug is very similar to JDK-6964923 and i think the spec >> should be changed to allow ? super Foo to be a valid target type for >> a lambda conversion (obviously if Foo is a functional interface). >> >> regards, >> R?mi >> > From forax at univ-mlv.fr Sun Jul 5 13:44:42 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 5 Jul 2015 15:44:42 +0200 Subject: Bad interaction between wildcard and functional interface conversion In-Reply-To: <55992D80.9090908@googlemail.com> References: <5565E2C9.7050009@univ-mlv.fr> <55914CED.4080803@univ-mlv.fr> <55992D80.9090908@googlemail.com> Message-ID: <559934CA.6060903@univ-mlv.fr> On 07/05/2015 03:13 PM, Gernot Neppert wrote: > Hi Remi, > > I think it's fair to say that I know my share of Java Generics, so I > generally understand the motivation of introducing wildcards into > method signatures. > Just in your particular case (and in your original example), I don't > see what you gain by having the "super" wildcard for the outer > Consumer's type parameter. > If you leave it out, the code compiles without problems: > > static Function factory(Consumer super T>> consumer, Function ifAbsent) { > ... > } > > Can you enlighten me? yes I can. The java.util.function.Consumer (or its method accept if you prefer) acts as a consumer of T ( :) ) so using the PECS rule [1], it should be a Consumer. The thing is that if you have a functional interface which is parametrized, if the functional interface is parametrized by a wildcard, it stops to be a functional interface because you can not do any lambda/method reference conversion (without adding an useless cast, that will be removed in the generated code BTW). So it's a stupid bug and I'm ashamed to haven't thought about it before the release of 8. > > Cheers, Gernot regards, R?mi [1] https://sites.google.com/site/io/effective-java-reloaded > > Am 29.06.2015 15:49, schrieb Remi Forax: >> Bitten again by the very same issue :( >> >> The following code doesn't compile: >> static Function factory(Consumer> super K, ? super T>> consumer, Function >> ifAbsent) { >> HashMap map = new HashMap<>(); >> consumer.accept(map::put); >> return key -> map.computeIfAbsent(key, ifAbsent); >> } >> >> I really think that it's a serious bug, the only workaround is to not >> use wildcards correctly, i.e. >> Function factory(Consumer> super T>> consumer, Function ifAbsent) >> >> cheers, >> R?mi >> >> On 05/27/2015 05:29 PM, Remi Forax wrote: >>> Hi all, >>> >>> The way the conversion between a lambda (or a method reference) and >>> a functional interface is specified doesn't take wildcard (exactly ? >>> super) into account making the concept of contravariance of >>> functional interface less intuitive that it should be. >>> >>> The following code compiles: >>> private static void create(Consumer> consumer) { >>> consumer.accept(s -> System.out.println(s)); >>> } >>> >>> This one doesn't compile because "? super Consumer" >>> is not a functional interface: >>> private static void create2(Consumer>> String>> consumer) { >>> consumer.accept(s -> System.out.println(s)); >>> } >>> >>> The workaround is to introduce a cast :( >>> private static void create3(Consumer>> String>> consumer) { >>> consumer.accept((Consumer)s -> System.out.println(s)); >>> } >>> which is stupid in this case because there is no ambiguity. >>> This cast is just here because the JLS doesn't consider that ? super >>> Consumer<...> is a valid target type >>> >>> IMO, this bug is very similar to JDK-6964923 and i think the spec >>> should be changed to allow ? super Foo to be a valid target type for >>> a lambda conversion (obviously if Foo is a functional interface). >>> >>> regards, >>> R?mi >>> >> > > From kumar.x.srinivasan at oracle.com Mon Jul 6 13:56:01 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 06 Jul 2015 06:56:01 -0700 Subject: RFR JDK-8075526: Need a way to read and write time in UTC In-Reply-To: <5594676F.60007@oracle.com> References: <55930615.5080808@oracle.com> <559456F6.2030704@oracle.com> <5594676F.60007@oracle.com> Message-ID: <559A88F1.8000702@oracle.com> Hi Sherman, I am good with this. Thanks Kumar On 7/1/2015 3:19 PM, Xueming Shen wrote: > Hi Kumar, thanks for the comments. Webrev has been updated according. > > On 7/1/15 2:09 PM, Kumar Srinivasan wrote: >> Hi Sherman, >> >> Thanks for solving this!, this has been a long standing issue for >> pack200. >> >> The changes looks generally good, I have also tested the initial >> prototype >> with pack200. >> >> Some nitpicks: >> TestLocalTime.java: >> 0. line 51, s/supoprt/support/ >> 1. line 63, you have a "}" out of place >> 2. line 71, misplaced "," >> 3. line 111: extra LF. >> >> Thanks >> Kumar >> >> On 6/30/2015 2:11 PM, Xueming Shen wrote: >>> Hi, >>> >>> Please help review and comment on this rfe. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8075526 >>> webrev: http://cr.openjdk.java.net/~sherman/8075526 >>> >>> Background info: >>> >>> The title of the RFE is a little "mis-leading". All the existing >>> set/get date-time >>> methods actually work with "UTC" time. Both the old pair >>> >>> public void setTime(long time); >>> public long getTime(); >>> >>> and the newly introduced pair >>> >>> pubic ZipEntry set/getLastModifiedTime(FileTime time); >>> public FileTime getLastModifiedTime(); >>> >>> are to set/get the last modified time in UTC time. However the ZIP >>> specification >>> clearly specifies that the "normal" date and time fields in the zip >>> file entry (loc and >>> cen) are defined as the date/time in dos format, which unfortunately >>> is a "local" >>> date-time. Therefor timezone conversion must be applied before/after >>> the utc time >>> can be set into/got from those fields (the UTC timestamps set/get by >>> the new pair >>> are therefor being set into/got from the "extended timestamp fields" >>> of the optional >>> extra data of each entry, those fields are specified as unix/utc >>> timestamp) >>> >>> We did not have an "local-date-time" abstract before the >>> java.time.LocalDateTime >>> was introduced in jdk8, the epoc date/time is the only date/time >>> abstract in java >>> vm. >>> >>> The proposed change here is to add yet another pair of set/get >>> modified time methods >>> >>> public void setTimeLocale(LocalDateTime time); >>> public LocalDateTime getTimeLocal(); >>> >>> to use the java.time.LocalDateTime type to set/get the modified time >>> into zip entry's >>> dos timestamp fields directly WITHOUT involving the timezone >>> conversion (implied, with >>> default TimeZone). >>> >>> Other than solving the pack/unpack problem raised in this RFE, it >>> should also help improve >>> the performance when local-date-time is actually desired when >>> interfacing with the ZipEntry >>> by eliminating the un-necessary/implied timezone conversion. For >>> example, in our jar tool, >>> currently we are "printing" the timestamp for zip entry "e" as >>> >>> new Date(e.getTime()).toString(); >>> >>> in which we are converting the local-date-time (ms-dos-formatted in >>> zip entry) to utc time >>> by using the default timezone (in ZipEntry), and then converting the >>> utc time (in Date) back >>> to the printable "local date time" again. >>> >>> It might be desired to format the "local-date-time" directly without >>> involving the timezone >>> conversion now via the proposed method >>> >>> java.time.format.DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss >>> zzz yyyy") >>> .withZone(java.time.ZoneId.systemDefault()); >>> .format(e.getTimeLocal() >>> >>> In above example, we still use the "system default timezone", >>> however, it is used >>> purely to output the zone name for the "zzz" (which the >>> Date.toString() does), not for conversion. >>> if the "zzz" is not required/needed, it can just be >>> >>> java.time.format.DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss >>> yyyy").format(e.getTimeLocal()); >>> >>> Comment/Opinion please. If we agree the approach/webrev, I will >>> submit the CCC before integration. >>> >>> Thanks, >>> -Sherman >>> >> > From claes.redestad at oracle.com Mon Jul 6 14:15:37 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 06 Jul 2015 16:15:37 +0200 Subject: RFR JDK-8075526: Need a way to read and write time in UTC In-Reply-To: <55941DEF.5000707@oracle.com> References: <55930615.5080808@oracle.com> <5593D6B9.60002@oracle.com> <55941DEF.5000707@oracle.com> Message-ID: <559A8D89.90007@oracle.com> Hi, On 2015-07-01 19:05, Xueming Shen wrote: > On 07/01/2015 05:02 AM, Claes Redestad wrote: >> Hi, >> >> On 2015-06-30 23:11, Xueming Shen wrote: >>> Hi, >>> >>> Please help review and comment on this rfe. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8075526 >>> webrev: http://cr.openjdk.java.net/~sherman/8075526 >> >> I think this looks reasonable. >> >> I think we could consolidate the LocalDateTime<->xdostime >> conversions into ZipUtils along with and aligned with the code >> to convert UTC instants (ZipUtils::dosToJavaTime/javaToDosTime), >> which I've suggested should be converted into similar code >> anyhow: > > I would prefer to deal with JDK-8066644 issue separately. One of the > concerns > of replacing the j.u.Date with the java.time classes was the possible > startup > time regression that may be triggered by forcing the vm to load lots > of java.time > classes given all the jvm starts with loading bunch of jar files. As a > matter of > fact, we spent the time and did the prototype when doing JSR310, it > did show > startup regression back then... This might no longer be an issue if > moving to > module system, but it'd be better to have some data first. On the > other hand, > the proposed change here is for two new methods, no impact to any > existing > apps. > I fired up the patch proposed to address 8066644 on latest jdk9/dev (the work was paused while Peter Levart addressed some related inefficiencies, e.g., caching result in ZoneId.getDefault()) and have verified that replacing the current j.u.Date implementation with java.time in ZipUtils have no measurable effect on our internal startup and footprint benchmarks (with/without modules) since neither is no longer loaded on application startup. I don't care if we move forward with 8066644 before or after this patch, justnoticedthat the parts of the code from this and that patch looks very much the same. Also spotted this nit: + this.mtime = FileTime.from( + ZonedDateTime.of(time, ZoneId.systemDefault()).toInstant()); could be written + this.mtime = FileTime.from( + time.atZone(ZoneId.systemDefault()).toInstant()); /Claes From Roger.Riggs at Oracle.com Mon Jul 6 14:47:08 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 06 Jul 2015 10:47:08 -0400 Subject: RFR 9: 8078099 : (process) ProcessHandle should uniquely identify processes In-Reply-To: <5594E909.3060003@gmail.com> References: <5588257A.5060802@Oracle.com> <5594E909.3060003@gmail.com> Message-ID: <559A94EC.4040609@Oracle.com> Hi Peter, Thanks for reviewing the new implementation. The idea to pre-allocate the buffer based on the size of the output arrays passed for output will not work as desired. The same native code entry point is used whether it is a query for all processes or just the immediate children. In either case, the buffer for sysctl needs to be large enough to accommodate all of the OS threads; its not a function of the output array size. With respect to the buffer allocation on OS X, I might see the point of a retry when sysctl returns ENOMEM; I don't think its particularly worthwhile to add the native code to retry in the case of ENOMEM. The OSX doc for sysctrl does indicate it tries to round up to avoid a subsequent failure. The ProcessHandle API already cautions that the list of processes is dynamic and that processes may started or terminate concurrently with the call to children/allChildren. So if the sysctl returns ENOMEM indicating not all the processes fit; the ones that do fit within in the allocated buffer are valid at that point in time. If there are extras that do not fit in the buffer they are likely to be 'newer' processes and can be considered to have been started 'after' the children/allChildren invocation. So I propose to change the error checking to consider ENOMEM as a non-exceptional return and return the processes available. Thanks, Roger On 7/2/2015 3:32 AM, Peter Levart wrote: > Hi Roger, > > I looked at the code briefly and have the following comments: > > For ProcessHandleImpl_macosx.c, in method getProcessPids0: > > 224 // Get buffer size needed to read all processes > 225 int mib[4] = {CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0}; > 226 if (sysctl(mib, 4, NULL, &bufSize, NULL, 0) < 0) { > 227 JNU_ThrowByNameWithLastError(env, > 228 "java/lang/RuntimeException", "sysctl failed"); > 229 return -1; > 230 } > 231 > 232 // Allocate buffer big enough for all processes > 233 void *buffer = malloc(bufSize); > 234 if (buffer == NULL) { > 235 JNU_ThrowOutOfMemoryError(env, "malloc failed"); > 236 return -1; > 237 } > 238 > 239 // Read process info for all processes > 240 if (sysctl(mib, 4, buffer, &bufSize, NULL, 0) < 0) { > 241 JNU_ThrowByNameWithLastError(env, > 242 "java/lang/RuntimeException", "sysctl failed"); > 243 free(buffer); > 244 return -1; > 245 } > > ... the 1st call to sysctl is used to measure the size of the needed > buffer and the 2nd call fills-in the buffer. The documentation for > sysctl says: > > " The information is copied into the buffer specified by oldp. The > size of the buffer is given by the > location specified by oldlenp before the call, and that location > gives the amount of data copied after > a successful call and after a call that returns with the error > code ENOMEM. If the amount of data > available is greater than the size of the buffer supplied, the > call supplies as much data as fits in > the buffer provided and returns with the error code ENOMEM. If > the old value is not desired, oldp and > oldlenp should be set to NULL. > > The size of the available data can be determined by calling > sysctl() with the NULL argument for oldp. > The size of the available data will be returned in the location > pointed to by oldlenp. For some opera-tions, operations, > tions, the amount of space may change often. For these > operations, the system attempts to round up so > that the returned size is large enough for a call to return the > data shortly thereafter." > > So while not very probable, it can happen that you get ENOMEM from 2nd > call because of underestimated buffer size. Would it be better to > retry (re)allocation of buffer and 2nd call in a loop with new > estimation returned from previous call while the error is ENOMEM? > > Another suggestion: What would it be if the buffer size estimation was > not computed by a call to sysctl with NULL buffer, but was taken from > the passed-in resulting array size(s). In case the user passes-in > arrays of sufficient size, you can avoid double invocation of sysctl. > Also, if ENOMEM happens, you can just return the result obtained and > the new estimation - no looping in native code. The UNIX, Solaris and > Windows variants look good. > > Regards, Peter > > On 06/22/2015 05:10 PM, Roger Riggs wrote: >> Please review changes to ProcessHandle implementation to uniquely >> identify >> processes based on the start time provided by the OS. It addresses >> the issue >> of PID reuse. >> >> This is the implementation of the ProcessHandle.equals() spec change in >> 8129344 : (process) ProcessHandle instances should define equals >> and be value-based >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-starttime-8078099/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8078099 >> >> Thanks, Roger >> > From xueming.shen at oracle.com Mon Jul 6 17:07:07 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 06 Jul 2015 10:07:07 -0700 Subject: RFR JDK-8075526: Need a way to read and write time in UTC In-Reply-To: <559A8D89.90007@oracle.com> References: <55930615.5080808@oracle.com> <5593D6B9.60002@oracle.com> <55941DEF.5000707@oracle.com> <559A8D89.90007@oracle.com> Message-ID: <559AB5BB.1020204@oracle.com> On 07/06/2015 07:15 AM, Claes Redestad wrote: > Hi, > > On 2015-07-01 19:05, Xueming Shen wrote: >> On 07/01/2015 05:02 AM, Claes Redestad wrote: >>> Hi, >>> >>> On 2015-06-30 23:11, Xueming Shen wrote: >>>> Hi, >>>> >>>> Please help review and comment on this rfe. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8075526 >>>> webrev: http://cr.openjdk.java.net/~sherman/8075526 >>> >>> I think this looks reasonable. >>> >>> I think we could consolidate the LocalDateTime<->xdostime >>> conversions into ZipUtils along with and aligned with the code >>> to convert UTC instants (ZipUtils::dosToJavaTime/javaToDosTime), >>> which I've suggested should be converted into similar code >>> anyhow: >> >> I would prefer to deal with JDK-8066644 issue separately. One of the concerns >> of replacing the j.u.Date with the java.time classes was the possible startup >> time regression that may be triggered by forcing the vm to load lots of java.time >> classes given all the jvm starts with loading bunch of jar files. As a matter of >> fact, we spent the time and did the prototype when doing JSR310, it did show >> startup regression back then... This might no longer be an issue if moving to >> module system, but it'd be better to have some data first. On the other hand, >> the proposed change here is for two new methods, no impact to any existing >> apps. >> > > I fired up the patch proposed to address 8066644 on latest jdk9/dev (the work was paused > while Peter Levart addressed some related inefficiencies, e.g., caching result in > ZoneId.getDefault()) and have verified that replacing the current j.u.Date implementation > with java.time in ZipUtils have no measurable effect on our internal startup and footprint > benchmarks (with/without modules) since neither is no longer loaded on application startup. > > I don't care if we move forward with 8066644 before or after this patch, justnoticedthat > the parts of the code from this and that patch looks very much the same. > Thanks for taking time on this. But let's do it separately. Just in case 8066644 might need to be backport. > Also spotted this nit: > > + this.mtime = FileTime.from( > + ZonedDateTime.of(time, ZoneId.systemDefault()).toInstant()); > > could be written > > + this.mtime = FileTime.from( > + time.atZone(ZoneId.systemDefault()).toInstant()); @Override public ZonedDateTime atZone(ZoneId zone) { return ZonedDateTime.of(this, zone); } Just tried to save one layer of invocation :-) though probably does not matter. The chained/short code may look more decent. -sherman From claes.redestad at oracle.com Mon Jul 6 18:22:47 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 06 Jul 2015 20:22:47 +0200 Subject: RFR JDK-8075526: Need a way to read and write time in UTC In-Reply-To: <559AB5BB.1020204@oracle.com> References: <55930615.5080808@oracle.com> <5593D6B9.60002@oracle.com> <55941DEF.5000707@oracle.com> <559A8D89.90007@oracle.com> <559AB5BB.1020204@oracle.com> Message-ID: <559AC777.9010400@oracle.com> On 2015-07-06 19:07, Xueming Shen wrote: > On 07/06/2015 07:15 AM, Claes Redestad wrote: >> Hi, >> >> On 2015-07-01 19:05, Xueming Shen wrote: >>> On 07/01/2015 05:02 AM, Claes Redestad wrote: >>>> Hi, >>>> >>>> On 2015-06-30 23:11, Xueming Shen wrote: >>>>> Hi, >>>>> >>>>> Please help review and comment on this rfe. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8075526 >>>>> webrev: http://cr.openjdk.java.net/~sherman/8075526 >>>> >>>> I think this looks reasonable. >>>> >>>> I think we could consolidate the LocalDateTime<->xdostime >>>> conversions into ZipUtils along with and aligned with the code >>>> to convert UTC instants (ZipUtils::dosToJavaTime/javaToDosTime), >>>> which I've suggested should be converted into similar code >>>> anyhow: >>> >>> I would prefer to deal with JDK-8066644 issue separately. One of the >>> concerns >>> of replacing the j.u.Date with the java.time classes was the >>> possible startup >>> time regression that may be triggered by forcing the vm to load lots >>> of java.time >>> classes given all the jvm starts with loading bunch of jar files. As >>> a matter of >>> fact, we spent the time and did the prototype when doing JSR310, it >>> did show >>> startup regression back then... This might no longer be an issue if >>> moving to >>> module system, but it'd be better to have some data first. On the >>> other hand, >>> the proposed change here is for two new methods, no impact to any >>> existing >>> apps. >>> >> >> I fired up the patch proposed to address 8066644 on latest jdk9/dev >> (the work was paused >> while Peter Levart addressed some related inefficiencies, e.g., >> caching result in >> ZoneId.getDefault()) and have verified that replacing the current >> j.u.Date implementation >> with java.time in ZipUtils have no measurable effect on our internal >> startup and footprint >> benchmarks (with/without modules) since neither is no longer loaded >> on application startup. >> >> I don't care if we move forward with 8066644 before or after this >> patch, justnoticedthat >> the parts of the code from this and that patch looks very much the same. >> > > Thanks for taking time on this. But let's do it separately. Just in > case 8066644 might need > to be backport. Sure. If backporting is on the table I think it would be more convenient to get 8066644 in first (since this change will block on getting ccc approval etc). I will send out an RFR soon, unless anyone objects or Peter beats me to it. :-) > >> Also spotted this nit: >> >> + this.mtime = FileTime.from( >> + ZonedDateTime.of(time, >> ZoneId.systemDefault()).toInstant()); >> >> could be written >> >> + this.mtime = FileTime.from( >> + time.atZone(ZoneId.systemDefault()).toInstant()); > > @Override > public ZonedDateTime atZone(ZoneId zone) { > return ZonedDateTime.of(this, zone); > } > > Just tried to save one layer of invocation :-) though probably does > not matter. The > chained/short code may look more decent. I was really only considering readability here. This will be path not taken in most cases - if not all - so outlining like I suggested could actually win by poking the JIT to do the right thing and ignore that branch. :-) Thanks! /Claes > > -sherman > > From volker.simonis at gmail.com Tue Jul 7 07:29:34 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 7 Jul 2015 09:29:34 +0200 Subject: RFR 9: 8078099 : (process) ProcessHandle should uniquely identify processes In-Reply-To: <559A94EC.4040609@Oracle.com> References: <5588257A.5060802@Oracle.com> <5594E909.3060003@gmail.com> <559A94EC.4040609@Oracle.com> Message-ID: Hi Roger, sorry but I only now noticed this RFR. Can you please temporary hold this change back. I think it needs some adjustments on AIX. I'll look into it today and let you know. Thanks, Volker On Mon, Jul 6, 2015 at 4:47 PM, Roger Riggs wrote: > Hi Peter, > > Thanks for reviewing the new implementation. > > The idea to pre-allocate the buffer based on the size of the output arrays > passed for output > will not work as desired. > The same native code entry point is used whether it is a query for all > processes or > just the immediate children. In either case, the buffer for sysctl needs to > be > large enough to accommodate all of the OS threads; its not a function of the > output array size. > > With respect to the buffer allocation on OS X, I might see the point of a > retry > when sysctl returns ENOMEM; > > > I don't think its particularly worthwhile to add the native code to retry in > the case > of ENOMEM. The OSX doc for sysctrl does indicate it tries to round up > to avoid a subsequent failure. > The ProcessHandle API already cautions that the list of processes is dynamic > and that processes may started or terminate concurrently with the call to > children/allChildren. > So if the sysctl returns ENOMEM indicating not all the processes fit; the > ones > that do fit within in the allocated buffer are valid at that point in time. > If there are extras that do not fit in the buffer they are likely to be > 'newer' > processes and can be considered to have been started 'after' the > children/allChildren invocation. > So I propose to change the error checking to consider ENOMEM as a > non-exceptional > return and return the processes available. > > Thanks, Roger > > > > > On 7/2/2015 3:32 AM, Peter Levart wrote: >> >> Hi Roger, >> >> I looked at the code briefly and have the following comments: >> >> For ProcessHandleImpl_macosx.c, in method getProcessPids0: >> >> 224 // Get buffer size needed to read all processes >> 225 int mib[4] = {CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0}; >> 226 if (sysctl(mib, 4, NULL, &bufSize, NULL, 0) < 0) { >> 227 JNU_ThrowByNameWithLastError(env, >> 228 "java/lang/RuntimeException", "sysctl failed"); >> 229 return -1; >> 230 } >> 231 >> 232 // Allocate buffer big enough for all processes >> 233 void *buffer = malloc(bufSize); >> 234 if (buffer == NULL) { >> 235 JNU_ThrowOutOfMemoryError(env, "malloc failed"); >> 236 return -1; >> 237 } >> 238 >> 239 // Read process info for all processes >> 240 if (sysctl(mib, 4, buffer, &bufSize, NULL, 0) < 0) { >> 241 JNU_ThrowByNameWithLastError(env, >> 242 "java/lang/RuntimeException", "sysctl failed"); >> 243 free(buffer); >> 244 return -1; >> 245 } >> >> ... the 1st call to sysctl is used to measure the size of the needed >> buffer and the 2nd call fills-in the buffer. The documentation for sysctl >> says: >> >> " The information is copied into the buffer specified by oldp. The >> size of the buffer is given by the >> location specified by oldlenp before the call, and that location >> gives the amount of data copied after >> a successful call and after a call that returns with the error code >> ENOMEM. If the amount of data >> available is greater than the size of the buffer supplied, the call >> supplies as much data as fits in >> the buffer provided and returns with the error code ENOMEM. If the >> old value is not desired, oldp and >> oldlenp should be set to NULL. >> >> The size of the available data can be determined by calling sysctl() >> with the NULL argument for oldp. >> The size of the available data will be returned in the location >> pointed to by oldlenp. For some opera-tions, operations, >> tions, the amount of space may change often. For these operations, >> the system attempts to round up so >> that the returned size is large enough for a call to return the data >> shortly thereafter." >> >> So while not very probable, it can happen that you get ENOMEM from 2nd >> call because of underestimated buffer size. Would it be better to retry >> (re)allocation of buffer and 2nd call in a loop with new estimation returned >> from previous call while the error is ENOMEM? >> >> Another suggestion: What would it be if the buffer size estimation was not >> computed by a call to sysctl with NULL buffer, but was taken from the >> passed-in resulting array size(s). In case the user passes-in arrays of >> sufficient size, you can avoid double invocation of sysctl. Also, if ENOMEM >> happens, you can just return the result obtained and the new estimation - no >> looping in native code. The UNIX, Solaris and Windows variants look good. >> >> Regards, Peter >> >> On 06/22/2015 05:10 PM, Roger Riggs wrote: >>> >>> Please review changes to ProcessHandle implementation to uniquely >>> identify >>> processes based on the start time provided by the OS. It addresses the >>> issue >>> of PID reuse. >>> >>> This is the implementation of the ProcessHandle.equals() spec change in >>> 8129344 : (process) ProcessHandle instances should define equals and >>> be value-based >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-starttime-8078099/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8078099 >>> >>> Thanks, Roger >>> >> > From jan.lahoda at oracle.com Tue Jul 7 09:50:15 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 07 Jul 2015 11:50:15 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <20150704232719.GA26601@lappers.redhat.com> References: <20150704232719.GA26601@lappers.redhat.com> Message-ID: <559BA0D7.8070200@oracle.com> Hi St?le, When we were looking for editing libraries, JLine 2 looked best. Unfortunately, we did not find Aesh. At this stage, I think we should proceed with JLine (so the dependent work can continue). Note that it is intended to be JDK internal-only, so there's a possibility to change to a different library later. Thanks for your pointers, Jan On 5.7.2015 01:27, St?le W Pedersen wrote: > hi, sorry, im a bit late to this discussion, i wasnt aware of any > interest for adding jline2 to the jdk until late this week. > im working on a project called ?sh/aesh: https://github.com/aeshell/aesh > its another java console project derived from jline/jline2. it started > as an extension/fork of jline2 and evolved into a separate project. > > im not quite sure what the reason behind choosing jline2 for the jdk, > but i just wanted to give some info on ?sh and what it does compared to > jline2. > > ?sh has all the same functionalities as jline2 and has a number of > additional features: > - history (search, persistence) > - undo/redo > - paste buffer > - redirect/pipeline > - alias > +++ > > jline2 has several bugs regarding input that is resolved in ?sh. > > one of the bigger differences between jline2 and ?sh is that ?sh isnt > locking in the same way as jline2, but rather has a callback when input > is given. this give better flexibility for the user when creating > commands. > > perhaps the biggest difference is that ?sh provides two apis for the > developer. one is more low-level and similar to jline2: > https://gist.github.com/stalep/cea6fbfee1de2b1ac6e4 > > plus a high level api that ?sh provides for the developer to create > commands. https://gist.github.com/stalep/98103347df1dd9b67fd1 > > in this example we create a ls command that will automatically complete > filenames/directories and inject the values into the list field. this it > just a very simple example, the api supports > converters/completers/activators/renders/+++ > we added this api because we noticed that the developers needed to > write a lot of code to parse user input. with this api they can > focus on creating commands and not parse for input data. > > if there is any interest in using ?sh in the jdk we would do whatever we > can to help you integrate it. ?sh has evolved fairly > quickly and tries to resolve any bugs/issues as quickly as possible. it > is also supported by red hat so we can promise that this project will > not be abandoned any time soon. > > regards, st?le From peter.levart at gmail.com Tue Jul 7 11:31:22 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 07 Jul 2015 13:31:22 +0200 Subject: RFR 9: 8078099 : (process) ProcessHandle should uniquely identify processes In-Reply-To: <559A94EC.4040609@Oracle.com> References: <5588257A.5060802@Oracle.com> <5594E909.3060003@gmail.com> <559A94EC.4040609@Oracle.com> Message-ID: <559BB88A.4060003@gmail.com> Hi Roger, On 07/06/2015 04:47 PM, Roger Riggs wrote: > Hi Peter, > > Thanks for reviewing the new implementation. > > The idea to pre-allocate the buffer based on the size of the output > arrays passed for output > will not work as desired. > The same native code entry point is used whether it is a query for all > processes or > just the immediate children. In either case, the buffer for sysctl > needs to be > large enough to accommodate all of the OS threads; its not a function > of the > output array size. Ah, I see now. You optionally filter the entries returned by sysctl based on passed-in parent pid. > > With respect to the buffer allocation on OS X, I might see the point > of a retry > when sysctl returns ENOMEM; > > > I don't think its particularly worthwhile to add the native code to > retry in the case > of ENOMEM. The OSX doc for sysctrl does indicate it tries to round up > to avoid a subsequent failure. > The ProcessHandle API already cautions that the list of processes is > dynamic > and that processes may started or terminate concurrently with the > call to children/allChildren. > So if the sysctl returns ENOMEM indicating not all the processes fit; > the ones > that do fit within in the allocated buffer are valid at that point in > time. > If there are extras that do not fit in the buffer they are likely to > be 'newer' > processes and can be considered to have been started 'after' the > children/allChildren invocation. If that's the case, then it might be OK to just silently ignore it. But OTOH it would be surprising if some already long running pid was skipped because of that. What about designing the getProcessPids0 API to always return all processes and do the filtering in Java? At least current implementations wouldn't become less optimal because of that (you always retrieve all processes from the OS and just return the filtered list to Java). Some alternatives (I'm sure you have already considered and rejected because of added complexity): An alternative could be designing the API around returning a single long[] that you allocate in native code - with (pid, ppid, stime) placed into array as consecutive triplets: [pid1, ppid1, stime1, pid2, ppid2, stime2, ...], but you would have to deal with allocation and re-allocation of the resulting array in native code which might get complicated. Another alternative: using a private class: static class ProcEntry { long pid, ppid, stime; ProcEntry next; } ...and building a linked-list of ProcEntries in native code... > So I propose to change the error checking to consider ENOMEM as a > non-exceptional > return and return the processes available. It should be non-exceptional in any case. I just wonder if it is OK that this "lack of full-information" is not communicated to the method caller and acted upon. Regards, Peter > > Thanks, Roger > > > > On 7/2/2015 3:32 AM, Peter Levart wrote: >> Hi Roger, >> >> I looked at the code briefly and have the following comments: >> >> For ProcessHandleImpl_macosx.c, in method getProcessPids0: >> >> 224 // Get buffer size needed to read all processes >> 225 int mib[4] = {CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0}; >> 226 if (sysctl(mib, 4, NULL, &bufSize, NULL, 0) < 0) { >> 227 JNU_ThrowByNameWithLastError(env, >> 228 "java/lang/RuntimeException", "sysctl failed"); >> 229 return -1; >> 230 } >> 231 >> 232 // Allocate buffer big enough for all processes >> 233 void *buffer = malloc(bufSize); >> 234 if (buffer == NULL) { >> 235 JNU_ThrowOutOfMemoryError(env, "malloc failed"); >> 236 return -1; >> 237 } >> 238 >> 239 // Read process info for all processes >> 240 if (sysctl(mib, 4, buffer, &bufSize, NULL, 0) < 0) { >> 241 JNU_ThrowByNameWithLastError(env, >> 242 "java/lang/RuntimeException", "sysctl failed"); >> 243 free(buffer); >> 244 return -1; >> 245 } >> >> ... the 1st call to sysctl is used to measure the size of the needed >> buffer and the 2nd call fills-in the buffer. The documentation for >> sysctl says: >> >> " The information is copied into the buffer specified by oldp. >> The size of the buffer is given by the >> location specified by oldlenp before the call, and that location >> gives the amount of data copied after >> a successful call and after a call that returns with the error >> code ENOMEM. If the amount of data >> available is greater than the size of the buffer supplied, the >> call supplies as much data as fits in >> the buffer provided and returns with the error code ENOMEM. If >> the old value is not desired, oldp and >> oldlenp should be set to NULL. >> >> The size of the available data can be determined by calling >> sysctl() with the NULL argument for oldp. >> The size of the available data will be returned in the location >> pointed to by oldlenp. For some opera-tions, operations, >> tions, the amount of space may change often. For these >> operations, the system attempts to round up so >> that the returned size is large enough for a call to return the >> data shortly thereafter." >> >> So while not very probable, it can happen that you get ENOMEM from >> 2nd call because of underestimated buffer size. Would it be better to >> retry (re)allocation of buffer and 2nd call in a loop with new >> estimation returned from previous call while the error is ENOMEM? >> >> Another suggestion: What would it be if the buffer size estimation >> was not computed by a call to sysctl with NULL buffer, but was taken >> from the passed-in resulting array size(s). In case the user >> passes-in arrays of sufficient size, you can avoid double invocation >> of sysctl. Also, if ENOMEM happens, you can just return the result >> obtained and the new estimation - no looping in native code. The >> UNIX, Solaris and Windows variants look good. >> >> Regards, Peter >> >> On 06/22/2015 05:10 PM, Roger Riggs wrote: >>> Please review changes to ProcessHandle implementation to uniquely >>> identify >>> processes based on the start time provided by the OS. It addresses >>> the issue >>> of PID reuse. >>> >>> This is the implementation of the ProcessHandle.equals() spec change in >>> 8129344 : (process) ProcessHandle instances should define equals >>> and be value-based >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-starttime-8078099/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8078099 >>> >>> Thanks, Roger >>> >> > From ivan.gerasimov at oracle.com Tue Jul 7 12:55:02 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 07 Jul 2015 15:55:02 +0300 Subject: RFR [XXS] 8130646: JCK test api/java_io/StringWriter/index_SWWrite5Test start failing after JDK-8077242 Message-ID: <559BCC26.8080107@oracle.com> Hi! With the fix for JDK-8077242 ((str) Optimize AbstractStringBuilder.append(CharSequence, int, int) for String argument) a change in behavior was introduced. In the places, where sb.append(str.substring(from, to)) used to be called, in the case of wrong indices StringIndexOutOfBoundsException was thrown. Now, after I replaced the code to sb.append(str, from, to), in such cases IndexOutOfBoundsException is thrown. The proposal is to make AbstractStringBuilder.append(CharSequence, int, int) throw more specific StringIndexOutOfBoundsException, which 1) will eliminate the regression, 2) will be more consistent with most other methods of AbstractStringBuilder, which throw StringIndexOutOfBoundsException. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8130646 WEBREV: http://cr.openjdk.java.net/~igerasim/8130646/00/webrev/ Sincerely yours, Ivan From Roger.Riggs at Oracle.com Tue Jul 7 13:11:00 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 07 Jul 2015 09:11:00 -0400 Subject: RFR 9: 8078099 : (process) ProcessHandle should uniquely identify processes In-Reply-To: References: <5588257A.5060802@Oracle.com> <5594E909.3060003@gmail.com> <559A94EC.4040609@Oracle.com> Message-ID: <559BCFE4.7050507@Oracle.com> Hi Volker, Sure, let me know what is different about AIX and how it should/can be fixed. Thanks, Roger On 7/7/2015 3:29 AM, Volker Simonis wrote: > Hi Roger, > > sorry but I only now noticed this RFR. Can you please temporary hold > this change back. I think it needs some adjustments on AIX. I'll look > into it today and let you know. > > Thanks, > Volker > > > > On Mon, Jul 6, 2015 at 4:47 PM, Roger Riggs wrote: >> Hi Peter, >> >> Thanks for reviewing the new implementation. >> >> The idea to pre-allocate the buffer based on the size of the output arrays >> passed for output >> will not work as desired. >> The same native code entry point is used whether it is a query for all >> processes or >> just the immediate children. In either case, the buffer for sysctl needs to >> be >> large enough to accommodate all of the OS threads; its not a function of the >> output array size. >> >> With respect to the buffer allocation on OS X, I might see the point of a >> retry >> when sysctl returns ENOMEM; >> >> >> I don't think its particularly worthwhile to add the native code to retry in >> the case >> of ENOMEM. The OSX doc for sysctrl does indicate it tries to round up >> to avoid a subsequent failure. >> The ProcessHandle API already cautions that the list of processes is dynamic >> and that processes may started or terminate concurrently with the call to >> children/allChildren. >> So if the sysctl returns ENOMEM indicating not all the processes fit; the >> ones >> that do fit within in the allocated buffer are valid at that point in time. >> If there are extras that do not fit in the buffer they are likely to be >> 'newer' >> processes and can be considered to have been started 'after' the >> children/allChildren invocation. >> So I propose to change the error checking to consider ENOMEM as a >> non-exceptional >> return and return the processes available. >> >> Thanks, Roger >> >> >> >> >> On 7/2/2015 3:32 AM, Peter Levart wrote: >>> Hi Roger, >>> >>> I looked at the code briefly and have the following comments: >>> >>> For ProcessHandleImpl_macosx.c, in method getProcessPids0: >>> >>> 224 // Get buffer size needed to read all processes >>> 225 int mib[4] = {CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0}; >>> 226 if (sysctl(mib, 4, NULL, &bufSize, NULL, 0) < 0) { >>> 227 JNU_ThrowByNameWithLastError(env, >>> 228 "java/lang/RuntimeException", "sysctl failed"); >>> 229 return -1; >>> 230 } >>> 231 >>> 232 // Allocate buffer big enough for all processes >>> 233 void *buffer = malloc(bufSize); >>> 234 if (buffer == NULL) { >>> 235 JNU_ThrowOutOfMemoryError(env, "malloc failed"); >>> 236 return -1; >>> 237 } >>> 238 >>> 239 // Read process info for all processes >>> 240 if (sysctl(mib, 4, buffer, &bufSize, NULL, 0) < 0) { >>> 241 JNU_ThrowByNameWithLastError(env, >>> 242 "java/lang/RuntimeException", "sysctl failed"); >>> 243 free(buffer); >>> 244 return -1; >>> 245 } >>> >>> ... the 1st call to sysctl is used to measure the size of the needed >>> buffer and the 2nd call fills-in the buffer. The documentation for sysctl >>> says: >>> >>> " The information is copied into the buffer specified by oldp. The >>> size of the buffer is given by the >>> location specified by oldlenp before the call, and that location >>> gives the amount of data copied after >>> a successful call and after a call that returns with the error code >>> ENOMEM. If the amount of data >>> available is greater than the size of the buffer supplied, the call >>> supplies as much data as fits in >>> the buffer provided and returns with the error code ENOMEM. If the >>> old value is not desired, oldp and >>> oldlenp should be set to NULL. >>> >>> The size of the available data can be determined by calling sysctl() >>> with the NULL argument for oldp. >>> The size of the available data will be returned in the location >>> pointed to by oldlenp. For some opera-tions, operations, >>> tions, the amount of space may change often. For these operations, >>> the system attempts to round up so >>> that the returned size is large enough for a call to return the data >>> shortly thereafter." >>> >>> So while not very probable, it can happen that you get ENOMEM from 2nd >>> call because of underestimated buffer size. Would it be better to retry >>> (re)allocation of buffer and 2nd call in a loop with new estimation returned >>> from previous call while the error is ENOMEM? >>> >>> Another suggestion: What would it be if the buffer size estimation was not >>> computed by a call to sysctl with NULL buffer, but was taken from the >>> passed-in resulting array size(s). In case the user passes-in arrays of >>> sufficient size, you can avoid double invocation of sysctl. Also, if ENOMEM >>> happens, you can just return the result obtained and the new estimation - no >>> looping in native code. The UNIX, Solaris and Windows variants look good. >>> >>> Regards, Peter >>> >>> On 06/22/2015 05:10 PM, Roger Riggs wrote: >>>> Please review changes to ProcessHandle implementation to uniquely >>>> identify >>>> processes based on the start time provided by the OS. It addresses the >>>> issue >>>> of PID reuse. >>>> >>>> This is the implementation of the ProcessHandle.equals() spec change in >>>> 8129344 : (process) ProcessHandle instances should define equals and >>>> be value-based >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-starttime-8078099/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8078099 >>>> >>>> Thanks, Roger >>>> From Roger.Riggs at Oracle.com Tue Jul 7 13:52:37 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 07 Jul 2015 09:52:37 -0400 Subject: RFR 9: 8078099 : (process) ProcessHandle should uniquely identify processes In-Reply-To: <559BB88A.4060003@gmail.com> References: <5588257A.5060802@Oracle.com> <5594E909.3060003@gmail.com> <559A94EC.4040609@Oracle.com> <559BB88A.4060003@gmail.com> Message-ID: <559BD9A5.6050207@Oracle.com> Hi Peter, On 7/7/2015 7:31 AM, Peter Levart wrote: > Hi Roger, > > On 07/06/2015 04:47 PM, Roger Riggs wrote: >> Hi Peter, >> >> Thanks for reviewing the new implementation. >> >> The idea to pre-allocate the buffer based on the size of the output >> arrays passed for output >> will not work as desired. >> The same native code entry point is used whether it is a query for >> all processes or >> just the immediate children. In either case, the buffer for sysctl >> needs to be >> large enough to accommodate all of the OS threads; its not a function >> of the >> output array size. > > Ah, I see now. You optionally filter the entries returned by sysctl > based on passed-in parent pid. yes, it was expected that the direct children was the most common use case. Doing the filtering in native reduces the amount of allocation/reallocation that is needed. > >> >> With respect to the buffer allocation on OS X, I might see the point >> of a retry >> when sysctl returns ENOMEM; >> >> >> I don't think its particularly worthwhile to add the native code to >> retry in the case >> of ENOMEM. The OSX doc for sysctrl does indicate it tries to round up >> to avoid a subsequent failure. >> The ProcessHandle API already cautions that the list of processes is >> dynamic >> and that processes may started or terminate concurrently with the >> call to children/allChildren. >> So if the sysctl returns ENOMEM indicating not all the processes fit; >> the ones >> that do fit within in the allocated buffer are valid at that point in >> time. >> If there are extras that do not fit in the buffer they are likely to >> be 'newer' >> processes and can be considered to have been started 'after' the >> children/allChildren invocation. > > If that's the case, then it might be OK to just silently ignore it. > But OTOH it would be surprising if some already long running pid was > skipped because of that. Yes, there is some risk there (without knowing/depending on the OS algorithm for copying). > > What about designing the getProcessPids0 API to always return all > processes and do the filtering in Java? At least current > implementations wouldn't become less optimal because of that (you > always retrieve all processes from the OS and just return the filtered > list to Java). Only that it gathers more information than needed and has to process more of it. The parent pids are not always needed. > > Some alternatives (I'm sure you have already considered and rejected > because of added complexity): > > An alternative could be designing the API around returning a single > long[] that you allocate in native code - with (pid, ppid, stime) > placed into array as consecutive triplets: [pid1, ppid1, stime1, pid2, > ppid2, stime2, ...], but you would have to deal with allocation and > re-allocation of the resulting array in native code which might get > complicated. The Java level return type is a Stream of ProcessHandles; with the current parallel arrays the stream can lazily construct the ProcessHandle instances when they are requested. The stream is driven by a sequence of indexes into the arrays. The parallel arrays are more straight forward to index in both native and java code. Initially, I preferred to do the allocation/reallocation in Java (and Java doesn't handle multiple returns easily). Intermixing the values in a native allocated array would work also, though to keep the java code consistent it would need to reserve space for the parent pid even if it was not used. In the case of a bad estimate on the number of processes, it adds an extra Java-Native call. At this point, optimizing it is lower priority than some other issues. > > Another alternative: using a private class: > > static class ProcEntry { > long pid, ppid, stime; > ProcEntry next; > } > > ...and building a linked-list of ProcEntries in native code... Yes, but it does a lot more allocation whether or not the object is needed to be returned from the Stream in children(), allChildren, etc. > >> So I propose to change the error checking to consider ENOMEM as a >> non-exceptional >> return and return the processes available. > > It should be non-exceptional in any case. I just wonder if it is OK > that this "lack of full-information" is not communicated to the method > caller and acted upon. In the worst case, a high rate of processes being created/deleted, any heuristic for retries might not be able to keep up, so there would need to be a limit; and at/after the limit, the same condition would be true. A simplier approach would be to just double or triple the size reported from sysctl. Though that seems redundant since sysctl asserts it takes potential changes into account already. Thanks, Roger > > Regards, Peter > >> >> Thanks, Roger >> >> >> >> On 7/2/2015 3:32 AM, Peter Levart wrote: >>> Hi Roger, >>> >>> I looked at the code briefly and have the following comments: >>> >>> For ProcessHandleImpl_macosx.c, in method getProcessPids0: >>> >>> 224 // Get buffer size needed to read all processes >>> 225 int mib[4] = {CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0}; >>> 226 if (sysctl(mib, 4, NULL, &bufSize, NULL, 0) < 0) { >>> 227 JNU_ThrowByNameWithLastError(env, >>> 228 "java/lang/RuntimeException", "sysctl failed"); >>> 229 return -1; >>> 230 } >>> 231 >>> 232 // Allocate buffer big enough for all processes >>> 233 void *buffer = malloc(bufSize); >>> 234 if (buffer == NULL) { >>> 235 JNU_ThrowOutOfMemoryError(env, "malloc failed"); >>> 236 return -1; >>> 237 } >>> 238 >>> 239 // Read process info for all processes >>> 240 if (sysctl(mib, 4, buffer, &bufSize, NULL, 0) < 0) { >>> 241 JNU_ThrowByNameWithLastError(env, >>> 242 "java/lang/RuntimeException", "sysctl failed"); >>> 243 free(buffer); >>> 244 return -1; >>> 245 } >>> >>> ... the 1st call to sysctl is used to measure the size of the needed >>> buffer and the 2nd call fills-in the buffer. The documentation for >>> sysctl says: >>> >>> " The information is copied into the buffer specified by oldp. >>> The size of the buffer is given by the >>> location specified by oldlenp before the call, and that >>> location gives the amount of data copied after >>> a successful call and after a call that returns with the error >>> code ENOMEM. If the amount of data >>> available is greater than the size of the buffer supplied, the >>> call supplies as much data as fits in >>> the buffer provided and returns with the error code ENOMEM. If >>> the old value is not desired, oldp and >>> oldlenp should be set to NULL. >>> >>> The size of the available data can be determined by calling >>> sysctl() with the NULL argument for oldp. >>> The size of the available data will be returned in the location >>> pointed to by oldlenp. For some opera-tions, operations, >>> tions, the amount of space may change often. For these >>> operations, the system attempts to round up so >>> that the returned size is large enough for a call to return the >>> data shortly thereafter." >>> >>> So while not very probable, it can happen that you get ENOMEM from >>> 2nd call because of underestimated buffer size. Would it be better >>> to retry (re)allocation of buffer and 2nd call in a loop with new >>> estimation returned from previous call while the error is ENOMEM? >>> >>> Another suggestion: What would it be if the buffer size estimation >>> was not computed by a call to sysctl with NULL buffer, but was taken >>> from the passed-in resulting array size(s). In case the user >>> passes-in arrays of sufficient size, you can avoid double invocation >>> of sysctl. Also, if ENOMEM happens, you can just return the result >>> obtained and the new estimation - no looping in native code. The >>> UNIX, Solaris and Windows variants look good. >>> >>> Regards, Peter >>> >>> On 06/22/2015 05:10 PM, Roger Riggs wrote: >>>> Please review changes to ProcessHandle implementation to uniquely >>>> identify >>>> processes based on the start time provided by the OS. It addresses >>>> the issue >>>> of PID reuse. >>>> >>>> This is the implementation of the ProcessHandle.equals() spec >>>> change in >>>> 8129344 : (process) ProcessHandle instances should define >>>> equals and be value-based >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-starttime-8078099/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8078099 >>>> >>>> Thanks, Roger >>>> >>> >> > From daniel.fuchs at oracle.com Tue Jul 7 16:43:53 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 07 Jul 2015 18:43:53 +0200 Subject: RfR - 8130649: java/util/logging/LoggingDeadlock2.java times out Message-ID: <559C01C9.60102@oracle.com> Please find below a changeset to address: 8130649: java/util/logging/LoggingDeadlock2.java times out https://bugs.openjdk.java.net/browse/JDK-8130649 The proposed changeset doesn't fix the issue but instruments the test a bit more so that we can get a clue of what is happening. http://cr.openjdk.java.net/~dfuchs/webrev_8130649/webrev.00/ When a test fails in timeout, jtreg obtains a Thread Dump before killing it. However - in our case - that thread dump is quite uninteresting - because the real test is performed in a subprocess - and that's where bad things could be happening. The proposed instrumentation will try to obtain a thread dump of the subprocess after a sensible time (60secs) but before the jtreg timeout kicks in (default jtreg timeout should be about 120sec x time factor - if I remember well). best regards, -- daniel From roger.riggs at oracle.com Tue Jul 7 18:49:34 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 7 Jul 2015 11:49:34 -0700 (PDT) Subject: RFR 9: 8085980 java/lang/ProcessHandle/TreeTest.java: AssertionError: Wrong number of spawned children Message-ID: <8079d0d6-fa04-4ab9-89fe-d88fea606e84@default> Please review changes to the ProcessHandle TreeTest to address intermittent failures. Since spurious processes have been observed, the test only tracks the subprocesses it launches and ignores unknown subprocesses.The end-of-test cleanup is more rigorous. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-tree-8085980/ Issue: https://bugs.openjdk.java.net/browse/JDK-8085980 Thanks, Roger From roger.riggs at oracle.com Tue Jul 7 18:52:38 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 7 Jul 2015 11:52:38 -0700 (PDT) Subject: RFR 9: 8098852 : java/lang/ProcessHandle/InfoTest.java failed: total cpu time Message-ID: Please review this ProcessHandle test change to cleanup intermittent failures. The cpuloop timing uses the cputime of the spawned process and the test runs fewer iterations and relaxes the threshold. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/ Issue: https://bugs.openjdk.java.net/browse/JDK-8098852 Thanks, Roger From roger.riggs at oracle.com Tue Jul 7 18:54:02 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 7 Jul 2015 11:54:02 -0700 (PDT) Subject: RFR 9: 8130296 [TESTBUG] java/lang/ProcessHandle/OnExitTest - Unaccounted for children Message-ID: <98c9f919-388f-40e3-88cf-f21f5b773a40@default> Please review this change to a ProcessHandle test to address intermittent failures. Unexpected subprocesses has been observed. The test succeeds if all of the processes under test are accounted for; others are ignored. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-exit-8130296/ Issue: https://bugs.openjdk.java.net/browse/JDK-8130296 Thanks, Roger From lance.andersen at oracle.com Tue Jul 7 19:06:13 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 7 Jul 2015 15:06:13 -0400 Subject: RfR - 8130649: java/util/logging/LoggingDeadlock2.java times out In-Reply-To: <559C01C9.60102@oracle.com> References: <559C01C9.60102@oracle.com> Message-ID: Hi Daniel Seems OK Best Lance On Jul 7, 2015, at 12:43 PM, Daniel Fuchs wrote: > Please find below a changeset to address: > > 8130649: java/util/logging/LoggingDeadlock2.java times out > https://bugs.openjdk.java.net/browse/JDK-8130649 > > The proposed changeset doesn't fix the issue but instruments > the test a bit more so that we can get a clue of what is > happening. > > http://cr.openjdk.java.net/~dfuchs/webrev_8130649/webrev.00/ > > When a test fails in timeout, jtreg obtains a Thread Dump > before killing it. However - in our case - that thread > dump is quite uninteresting - because the real test is > performed in a subprocess - and that's where bad things > could be happening. > > The proposed instrumentation will try to obtain a thread > dump of the subprocess after a sensible time (60secs) but > before the jtreg timeout kicks in (default jtreg timeout > should be about 120sec x time factor - if I remember well). > > best regards, > > -- daniel > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From joe.darcy at oracle.com Tue Jul 7 19:44:31 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 07 Jul 2015 12:44:31 -0700 Subject: RFR 9: 8085980 java/lang/ProcessHandle/TreeTest.java: AssertionError: Wrong number of spawned children In-Reply-To: <8079d0d6-fa04-4ab9-89fe-d88fea606e84@default> References: <8079d0d6-fa04-4ab9-89fe-d88fea606e84@default> Message-ID: <559C2C1F.8030107@oracle.com> Looks fine Roger; thanks, -Joe On 7/7/2015 11:49 AM, Roger Riggs wrote: > Please review changes to the ProcessHandle TreeTest to address intermittent failures. > Since spurious processes have been observed, the test only tracks the subprocesses > it launches and ignores unknown subprocesses.The end-of-test cleanup is more rigorous. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-tree-8085980/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8085980 > > Thanks, Roger > From joe.darcy at oracle.com Tue Jul 7 22:14:31 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 07 Jul 2015 15:14:31 -0700 Subject: JDK 9 RFR of JDK-8130716: Fix reference problems in jaxp javadoc Message-ID: <559C4F47.3030302@oracle.com> Hello, Please review the small patch below to address JDK-8130716: Fix reference problems in jaxp javadoc Thanks, -Joe diff -r 39ac2a55f28d src/java.xml/share/classes/javax/xml/stream/XMLEventReader.java --- a/src/java.xml/share/classes/javax/xml/stream/XMLEventReader.java Tue Jul 07 18:19:57 2015 +0200 +++ b/src/java.xml/share/classes/javax/xml/stream/XMLEventReader.java Tue Jul 07 15:13:48 2015 -0700 @@ -49,7 +49,7 @@ * Get the next XMLEvent * @see XMLEvent * @throws XMLStreamException if there is an error with the underlying XML. - * @throws NoSuchElementException iteration has no more elements. + * @throws java.util.NoSuchElementException iteration has no more elements. */ public XMLEvent nextEvent() throws XMLStreamException; diff -r 39ac2a55f28d src/java.xml/share/classes/javax/xml/stream/events/XMLEvent.java --- a/src/java.xml/share/classes/javax/xml/stream/events/XMLEvent.java Tue Jul 07 18:19:57 2015 +0200 +++ b/src/java.xml/share/classes/javax/xml/stream/events/XMLEvent.java Tue Jul 07 15:13:48 2015 -0700 @@ -170,7 +170,7 @@ * infoset expressed. * * @param writer The writer that will output the data - * @throws XMLStreamException if there is a fatal error writing the event + * @throws javax.xml.stream.XMLStreamException if there is a fatal error writing the event */ public void writeAsEncodedUnicode(Writer writer) throws javax.xml.stream.XMLStreamException; From lance.andersen at oracle.com Tue Jul 7 22:17:12 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 7 Jul 2015 18:17:12 -0400 Subject: JDK 9 RFR of JDK-8130716: Fix reference problems in jaxp javadoc In-Reply-To: <559C4F47.3030302@oracle.com> References: <559C4F47.3030302@oracle.com> Message-ID: looks ok Joe On Jul 7, 2015, at 6:14 PM, joe darcy wrote: > Hello, > > Please review the small patch below to address > > JDK-8130716: Fix reference problems in jaxp javadoc > > Thanks, > > -Joe > > diff -r 39ac2a55f28d src/java.xml/share/classes/javax/xml/stream/XMLEventReader.java > --- a/src/java.xml/share/classes/javax/xml/stream/XMLEventReader.java Tue Jul 07 18:19:57 2015 +0200 > +++ b/src/java.xml/share/classes/javax/xml/stream/XMLEventReader.java Tue Jul 07 15:13:48 2015 -0700 > @@ -49,7 +49,7 @@ > * Get the next XMLEvent > * @see XMLEvent > * @throws XMLStreamException if there is an error with the underlying XML. > - * @throws NoSuchElementException iteration has no more elements. > + * @throws java.util.NoSuchElementException iteration has no more elements. > */ > public XMLEvent nextEvent() throws XMLStreamException; > > diff -r 39ac2a55f28d src/java.xml/share/classes/javax/xml/stream/events/XMLEvent.java > --- a/src/java.xml/share/classes/javax/xml/stream/events/XMLEvent.java Tue Jul 07 18:19:57 2015 +0200 > +++ b/src/java.xml/share/classes/javax/xml/stream/events/XMLEvent.java Tue Jul 07 15:13:48 2015 -0700 > @@ -170,7 +170,7 @@ > * infoset expressed. > * > * @param writer The writer that will output the data > - * @throws XMLStreamException if there is a fatal error writing the event > + * @throws javax.xml.stream.XMLStreamException if there is a fatal error writing the event > */ > public void writeAsEncodedUnicode(Writer writer) > throws javax.xml.stream.XMLStreamException; Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From joe.darcy at oracle.com Tue Jul 7 23:59:46 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 07 Jul 2015 16:59:46 -0700 Subject: RFR 9: 8098852 : java/lang/ProcessHandle/InfoTest.java failed: total cpu time In-Reply-To: References: Message-ID: <559C67F2.6080609@oracle.com> Hi Roger, Generally looks okay; a few comments and suggestions 114 long cpulooptime = 100; // 100 ms How about cpuLoopTime instead? Same comment for the other variables that don't follow camel-case conventions. 284 long cpumillis = Long.valueOf(args[nextArg++]); 285 long cpuTarget = getCpuTime() + cpumillis * 1_000_000L; 286 while (getCpuTime() < cpuTarget) { Is it correct to multiply cpu-millis by 1e6 rather than 1e3? -Joe On 7/7/2015 11:52 AM, Roger Riggs wrote: > Please review this ProcessHandle test change to cleanup intermittent failures. > The cpuloop timing uses the cputime of the spawned process and the > test runs fewer iterations and relaxes the threshold. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8098852 > > Thanks, Roger > From joe.darcy at oracle.com Wed Jul 8 00:35:39 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 07 Jul 2015 17:35:39 -0700 Subject: JDK 9 RFR of JDK-8130719: Fix reference problems in jax-ws javadoc Message-ID: <559C705B.2040204@oracle.com> Hello, Please review the patch below which fixes some javadoc reference issues in jax-ws: JDK-8130719: Fix reference problems in jax-ws javadoc Thanks, -Joe diff -r 1d87054e2d2f src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/SOAPMessageContext.java --- a/src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/SOAPMessageContext.java Thu Jul 02 16:09:51 2015 -0700 +++ b/src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/SOAPMessageContext.java Tue Jul 07 17:28:29 2015 -0700 @@ -55,7 +55,7 @@ /** Sets the SOAPMessage in this message context * * @param message SOAP message - * @throws WebServiceException If any error during the setting + * @throws javax.xml.ws.WebServiceException If any error during the setting * of the SOAPMessage in this message context * @throws java.lang.UnsupportedOperationException If this * operation is not supported @@ -76,7 +76,7 @@ * @return An array of unmarshalled headers; returns an empty array if no * message is present in this message context or no headers match * the supplied qualified name. - * @throws WebServiceException If an error occurs when using the supplied + * @throws javax.xml.ws.WebServiceException If an error occurs when using the supplied * JAXBContext to unmarshall. The cause of * the WebServiceException is the original JAXBException. **/ diff -r 1d87054e2d2f src/java.xml.ws/share/classes/javax/xml/ws/soap/SOAPBinding.java --- a/src/java.xml.ws/share/classes/javax/xml/ws/soap/SOAPBinding.java Thu Jul 02 16:09:51 2015 -0700 +++ b/src/java.xml.ws/share/classes/javax/xml/ws/soap/SOAPBinding.java Tue Jul 07 17:28:29 2015 -0700 @@ -70,7 +70,7 @@ /** Sets the roles played by the SOAP binding instance. * * @param roles The set of roles played by the binding instance. - * @throws WebServiceException On an error in the configuration of + * @throws javax.xml.ws.WebServiceException On an error in the configuration of * the list of roles. **/ public void setRoles(Set roles); @@ -88,7 +88,7 @@ * * @param flag A {@code boolean} specifying whether the use of MTOM should * be enabled or disabled. - * @throws WebServiceException If the specified setting is not supported + * @throws javax.xml.ws.WebServiceException If the specified setting is not supported * by this binding instance. * **/ From huizhe.wang at oracle.com Wed Jul 8 00:53:20 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 07 Jul 2015 17:53:20 -0700 Subject: JDK 9 RFR of JDK-8130719: Fix reference problems in jax-ws javadoc In-Reply-To: <559C705B.2040204@oracle.com> References: <559C705B.2040204@oracle.com> Message-ID: <559C7480.5010907@oracle.com> Looks good to me. Joe On 7/7/2015 5:35 PM, joe darcy wrote: > Hello, > > Please review the patch below which fixes some javadoc reference > issues in jax-ws: > > JDK-8130719: Fix reference problems in jax-ws javadoc > > Thanks, > > -Joe > > diff -r 1d87054e2d2f > src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/SOAPMessageContext.java > --- > a/src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/SOAPMessageContext.java > Thu Jul 02 16:09:51 2015 -0700 > +++ > b/src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/SOAPMessageContext.java > Tue Jul 07 17:28:29 2015 -0700 > @@ -55,7 +55,7 @@ > /** Sets the SOAPMessage in this message context > * > * @param message SOAP message > - * @throws WebServiceException If any error during the setting > + * @throws javax.xml.ws.WebServiceException If any error during > the setting > * of the SOAPMessage in this message context > * @throws java.lang.UnsupportedOperationException If this > * operation is not supported > @@ -76,7 +76,7 @@ > * @return An array of unmarshalled headers; returns an empty > array if no > * message is present in this message context or no > headers match > * the supplied qualified name. > - * @throws WebServiceException If an error occurs when using the > supplied > + * @throws javax.xml.ws.WebServiceException If an error occurs > when using the supplied > * JAXBContext to unmarshall. The cause of > * the WebServiceException is the original > JAXBException. > **/ > diff -r 1d87054e2d2f > src/java.xml.ws/share/classes/javax/xml/ws/soap/SOAPBinding.java > --- a/src/java.xml.ws/share/classes/javax/xml/ws/soap/SOAPBinding.java > Thu Jul 02 16:09:51 2015 -0700 > +++ b/src/java.xml.ws/share/classes/javax/xml/ws/soap/SOAPBinding.java > Tue Jul 07 17:28:29 2015 -0700 > @@ -70,7 +70,7 @@ > /** Sets the roles played by the SOAP binding instance. > * > * @param roles The set of roles played by the binding instance. > - * @throws WebServiceException On an error in the configuration of > + * @throws javax.xml.ws.WebServiceException On an error in the > configuration of > * the list of roles. > **/ > public void setRoles(Set roles); > @@ -88,7 +88,7 @@ > * > * @param flag A {@code boolean} specifying whether the use of > MTOM should > * be enabled or disabled. > - * @throws WebServiceException If the specified setting is not > supported > + * @throws javax.xml.ws.WebServiceException If the specified > setting is not supported > * by this binding instance. > * > **/ > From lance.andersen at oracle.com Wed Jul 8 00:55:47 2015 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Tue, 7 Jul 2015 20:55:47 -0400 Subject: JDK 9 RFR of JDK-8130719: Fix reference problems in jax-ws javadoc In-Reply-To: <559C705B.2040204@oracle.com> References: <559C705B.2040204@oracle.com> Message-ID: Hi joe Looks fine. I think we should get this in the jaxws workspace also Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPad > On Jul 7, 2015, at 8:35 PM, joe darcy wrote: > > Hello, > > Please review the patch below which fixes some javadoc reference issues in jax-ws: > > JDK-8130719: Fix reference problems in jax-ws javadoc > > Thanks, > > -Joe > > diff -r 1d87054e2d2f src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/SOAPMessageContext.java > --- a/src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/SOAPMessageContext.java Thu Jul 02 16:09:51 2015 -0700 > +++ b/src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/SOAPMessageContext.java Tue Jul 07 17:28:29 2015 -0700 > @@ -55,7 +55,7 @@ > /** Sets the SOAPMessage in this message context > * > * @param message SOAP message > - * @throws WebServiceException If any error during the setting > + * @throws javax.xml.ws.WebServiceException If any error during the setting > * of the SOAPMessage in this message context > * @throws java.lang.UnsupportedOperationException If this > * operation is not supported > @@ -76,7 +76,7 @@ > * @return An array of unmarshalled headers; returns an empty array if no > * message is present in this message context or no headers match > * the supplied qualified name. > - * @throws WebServiceException If an error occurs when using the supplied > + * @throws javax.xml.ws.WebServiceException If an error occurs when using the supplied > * JAXBContext to unmarshall. The cause of > * the WebServiceException is the original JAXBException. > **/ > diff -r 1d87054e2d2f src/java.xml.ws/share/classes/javax/xml/ws/soap/SOAPBinding.java > --- a/src/java.xml.ws/share/classes/javax/xml/ws/soap/SOAPBinding.java Thu Jul 02 16:09:51 2015 -0700 > +++ b/src/java.xml.ws/share/classes/javax/xml/ws/soap/SOAPBinding.java Tue Jul 07 17:28:29 2015 -0700 > @@ -70,7 +70,7 @@ > /** Sets the roles played by the SOAP binding instance. > * > * @param roles The set of roles played by the binding instance. > - * @throws WebServiceException On an error in the configuration of > + * @throws javax.xml.ws.WebServiceException On an error in the configuration of > * the list of roles. > **/ > public void setRoles(Set roles); > @@ -88,7 +88,7 @@ > * > * @param flag A {@code boolean} specifying whether the use of MTOM should > * be enabled or disabled. > - * @throws WebServiceException If the specified setting is not supported > + * @throws javax.xml.ws.WebServiceException If the specified setting is not supported > * by this binding instance. > * > **/ > From Roger.Riggs at Oracle.com Wed Jul 8 00:57:14 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 07 Jul 2015 20:57:14 -0400 Subject: RFR 9: 8085981 java/lang/ProcessHandle/OnExitTest.java: AssertionError: Child onExit not called In-Reply-To: <559C5189.6050304@Oracle.com> References: <559C5189.6050304@Oracle.com> Message-ID: <559C756A.7090401@Oracle.com> Please review this test fix for a race condition checking that the onExit CompletableFuture was completed and with the correct value. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-onexit-8085981/ Issue: https://bugs.openjdk.java.net/browse/JDK-8085981 Thanks, Roger From joe.darcy at oracle.com Wed Jul 8 01:12:00 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 07 Jul 2015 18:12:00 -0700 Subject: RFR 9: 8085981 java/lang/ProcessHandle/OnExitTest.java: AssertionError: Child onExit not called In-Reply-To: <559C756A.7090401@Oracle.com> References: <559C5189.6050304@Oracle.com> <559C756A.7090401@Oracle.com> Message-ID: <559C78E0.708@oracle.com> Looks fine; thanks, -Joe On 7/7/2015 5:57 PM, Roger Riggs wrote: > Please review this test fix for a race condition checking that the > onExit CompletableFuture > was completed and with the correct value. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-onexit-8085981/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8085981 > > Thanks, Roger > > > From amaembo at gmail.com Wed Jul 8 02:58:01 2015 From: amaembo at gmail.com (Tagir F. Valeev) Date: Wed, 8 Jul 2015 08:58:01 +0600 Subject: JDK-8071597: close original Stream in default implementation? Message-ID: <15810682512.20150708085801@gmail.com> Hello, I was looking at default implementation of new Stream takeWhile/dropWhile methods: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071597-take-drop-while/webrev/src/java.base/share/classes/java/util/stream/Stream.java.cdiff.html I think in order to make this default behavior more consistent, the original Stream must be closed when the returned one is closed. Thus, takeWhile return statement should look like this: return StreamSupport.stream( new WhileOps.UnorderedWhileSpliterator.OfRef.Taking<> (spliterator(), true, predicate), isParallel()).onClose(this::close); The same for dropWhile method. What do you think? Regards, Tagir Valeev. From paul.sandoz at oracle.com Wed Jul 8 07:59:36 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 8 Jul 2015 09:59:36 +0200 Subject: RFR: 6260652: (coll) Arrays.asList(x).toArray().getClass() should be Object[].class In-Reply-To: References: <0FC2087B-1F26-447F-AE08-0E255E1462E6@oracle.com> Message-ID: <56B51E8A-5636-457F-93F8-151C96A5312B@oracle.com> HI Martin, Sorry the late reply. On Jun 30, 2015, at 7:04 PM, Martin Buchholz wrote: > > The comment remains correct even if 6260652 is fixed. > I can't think up a clearly better one. I would recommend at least removing the issue id (since that refers specifically to Arrays.asList rather than something general that cannot actually be fixed). Up to you. > > I trawled through the JDK code and found one other violation of the toArray contract in: > > com.sun.java.util.jar.pack.ConstantPool.Index: > > public Entry[] toArray() { > return toArray(new Entry[size()]); > } > > Agreed. I'm unfamiliar with that code - it should probably be fixed in another change. Logged: https://bugs.openjdk.java.net/browse/JDK-8130732 Paul. From amy.lu at oracle.com Wed Jul 8 08:01:13 2015 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 08 Jul 2015 16:01:13 +0800 Subject: JDK 9 RFR of JDK-8130402: Mark intermittently failing test: tools/pack200/PackTestZip64.java Message-ID: <559CD8C9.5090400@oracle.com> tools/pack200/PackTestZip64.java This test has been observed to fail intermittently. This patch is to mark it accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8130402 webrev: http://cr.openjdk.java.net/~amlu/8130402/webrev.00/ Thanks, Amy --- old/test/tools/pack200/PackTestZip64.java 2015-07-08 15:51:12.000000000 +0800 +++ new/test/tools/pack200/PackTestZip64.java 2015-07-08 15:51:12.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -37,6 +37,7 @@ * @compile -XDignore.symbol.file Utils.java PackTestZip64.java * @run main PackTestZip64 * @author kizune + * @key intermittent */ public class PackTestZip64 { From paul.sandoz at oracle.com Wed Jul 8 08:27:45 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 8 Jul 2015 10:27:45 +0200 Subject: JDK-8071597: close original Stream in default implementation? In-Reply-To: <15810682512.20150708085801@gmail.com> References: <15810682512.20150708085801@gmail.com> Message-ID: Hi Tagir, Yes, i forgot about that, thanks, nice catch. Patch updated: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071597-take-drop-while/webrev/ See below for a diff. Paul. diff -r 61bc2fe3b2c6 src/java.base/share/classes/java/util/stream/DoubleStream.java --- a/src/java.base/share/classes/java/util/stream/DoubleStream.java Tue Jun 09 07:10:03 2015 +0100 +++ b/src/java.base/share/classes/java/util/stream/DoubleStream.java Wed Jul 08 10:20:25 2015 +0200 @@ -300,7 +300,8 @@ * the wrapped spliterator. The returned stream preserves the execution * characteristics of this stream (namely parallel or sequential execution * as per {@link #isParallel()}) but the wrapped spliterator may choose to - * not support splitting. + * not support splitting. When the returned stream is closed, the close + * handlers for both the returned and this stream are invoked. * * @apiNote * While {@code takeWhile()} is generally a cheap operation on sequential @@ -328,7 +329,7 @@ // is safe to use as long as it configured not to split return StreamSupport.doubleStream( new WhileOps.UnorderedWhileSpliterator.OfDouble.Taking(spliterator(), true, predicate), - isParallel()); + isParallel()).onClose(this::close); } /** @@ -358,7 +359,8 @@ * the wrapped spliterator. The returned stream preserves the execution * characteristics of this stream (namely parallel or sequential execution * as per {@link #isParallel()}) but the wrapped spliterator may choose to - * not support splitting. + * not support splitting. When the returned stream is closed, the close + * handlers for both the returned and this stream are invoked. * * @apiNote * While {@code dropWhile()} is generally a cheap operation on sequential @@ -386,7 +388,7 @@ // is safe to use as long as it configured not to split return StreamSupport.doubleStream( new WhileOps.UnorderedWhileSpliterator.OfDouble.Dropping(spliterator(), true, predicate), - isParallel()); + isParallel()).onClose(this::close); } /** diff -r 61bc2fe3b2c6 src/java.base/share/classes/java/util/stream/IntStream.java --- a/src/java.base/share/classes/java/util/stream/IntStream.java Tue Jun 09 07:10:03 2015 +0100 +++ b/src/java.base/share/classes/java/util/stream/IntStream.java Wed Jul 08 10:20:25 2015 +0200 @@ -298,7 +298,8 @@ * the wrapped spliterator. The returned stream preserves the execution * characteristics of this stream (namely parallel or sequential execution * as per {@link #isParallel()}) but the wrapped spliterator may choose to - * not support splitting. + * not support splitting. When the returned stream is closed, the close + * handlers for both the returned and this stream are invoked. * * @apiNote * While {@code takeWhile()} is generally a cheap operation on sequential @@ -325,7 +326,7 @@ // is safe to use as long as it configured not to split return StreamSupport.intStream( new WhileOps.UnorderedWhileSpliterator.OfInt.Taking(spliterator(), true, predicate), - isParallel()); + isParallel()).onClose(this::close); } /** @@ -355,7 +356,8 @@ * the wrapped spliterator. The returned stream preserves the execution * characteristics of this stream (namely parallel or sequential execution * as per {@link #isParallel()}) but the wrapped spliterator may choose to - * not support splitting. + * not support splitting. When the returned stream is closed, the close + * handlers for both the returned and this stream are invoked. * * @apiNote * While {@code dropWhile()} is generally a cheap operation on sequential @@ -382,7 +384,7 @@ // is safe to use as long as it configured not to split return StreamSupport.intStream( new WhileOps.UnorderedWhileSpliterator.OfInt.Dropping(spliterator(), true, predicate), - isParallel()); + isParallel()).onClose(this::close); } /** diff -r 61bc2fe3b2c6 src/java.base/share/classes/java/util/stream/LongStream.java --- a/src/java.base/share/classes/java/util/stream/LongStream.java Tue Jun 09 07:10:03 2015 +0100 +++ b/src/java.base/share/classes/java/util/stream/LongStream.java Wed Jul 08 10:20:25 2015 +0200 @@ -298,7 +298,8 @@ * the wrapped spliterator. The returned stream preserves the execution * characteristics of this stream (namely parallel or sequential execution * as per {@link #isParallel()}) but the wrapped spliterator may choose to - * not support splitting. + * not support splitting. When the returned stream is closed, the close + * handlers for both the returned and this stream are invoked. * * @apiNote * While {@code takeWhile()} is generally a cheap operation on sequential @@ -326,7 +327,7 @@ // is safe to use as long as it configured not to split return StreamSupport.longStream( new WhileOps.UnorderedWhileSpliterator.OfLong.Taking(spliterator(), true, predicate), - isParallel()); + isParallel()).onClose(this::close); } /** @@ -356,7 +357,8 @@ * the wrapped spliterator. The returned stream preserves the execution * characteristics of this stream (namely parallel or sequential execution * as per {@link #isParallel()}) but the wrapped spliterator may choose to - * not support splitting. + * not support splitting. When the returned stream is closed, the close + * handlers for both the returned and this stream are invoked. * * @apiNote * While {@code dropWhile()} is generally a cheap operation on sequential @@ -384,7 +386,7 @@ // is safe to use as long as it configured not to split return StreamSupport.longStream( new WhileOps.UnorderedWhileSpliterator.OfLong.Dropping(spliterator(), true, predicate), - isParallel()); + isParallel()).onClose(this::close); } /** diff -r 61bc2fe3b2c6 src/java.base/share/classes/java/util/stream/Stream.java --- a/src/java.base/share/classes/java/util/stream/Stream.java Tue Jun 09 07:10:03 2015 +0100 +++ b/src/java.base/share/classes/java/util/stream/Stream.java Wed Jul 08 10:20:25 2015 +0200 @@ -505,7 +505,8 @@ * the wrapped spliterator. The returned stream preserves the execution * characteristics of this stream (namely parallel or sequential execution * as per {@link #isParallel()}) but the wrapped spliterator may choose to - * not support splitting. + * not support splitting. When the returned stream is closed, the close + * handlers for both the returned and this stream are invoked. * * @apiNote * While {@code takeWhile()} is generally a cheap operation on sequential @@ -532,7 +533,7 @@ // is safe to use as long as it configured not to split return StreamSupport.stream( new WhileOps.UnorderedWhileSpliterator.OfRef.Taking<>(spliterator(), true, predicate), - isParallel()); + isParallel()).onClose(this::close); } /** @@ -562,7 +563,8 @@ * the wrapped spliterator. The returned stream preserves the execution * characteristics of this stream (namely parallel or sequential execution * as per {@link #isParallel()}) but the wrapped spliterator may choose to - * not support splitting. + * not support splitting. When the returned stream is closed, the close + * handlers for both the returned and this stream are invoked. * * @apiNote * While {@code dropWhile()} is generally a cheap operation on sequential @@ -589,7 +591,7 @@ // is safe to use as long as it configured not to split return StreamSupport.stream( new WhileOps.UnorderedWhileSpliterator.OfRef.Dropping<>(spliterator(), true, predicate), - isParallel()); + isParallel()).onClose(this::close); } /** diff -r 61bc2fe3b2c6 test/java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpTest.java --- a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpTest.java Tue Jun 09 07:10:03 2015 +0100 +++ b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpTest.java Wed Jul 08 10:20:25 2015 +0200 @@ -31,6 +31,7 @@ import java.util.List; import java.util.Map; import java.util.Set; +import java.util.concurrent.atomic.AtomicBoolean; import java.util.function.Function; import java.util.function.Predicate; import java.util.stream.DefaultMethodStreams; @@ -318,4 +319,43 @@ } } + @Test + public void testRefDefaultClose() { + AtomicBoolean isClosed = new AtomicBoolean(); + Stream s = Stream.of(1, 2, 3).onClose(() -> isClosed.set(true)); + try (Stream ds = DefaultMethodStreams.delegateTo(s).takeWhile(e -> e < 3)) { + ds.count(); + } + assertTrue(isClosed.get()); + } + + @Test + public void testIntDefaultClose() { + AtomicBoolean isClosed = new AtomicBoolean(); + IntStream s = IntStream.of(1, 2, 3).onClose(() -> isClosed.set(true)); + try (IntStream ds = DefaultMethodStreams.delegateTo(s).takeWhile(e -> e < 3)) { + ds.count(); + } + assertTrue(isClosed.get()); + } + + @Test + public void testLongDefaultClose() { + AtomicBoolean isClosed = new AtomicBoolean(); + LongStream s = LongStream.of(1, 2, 3).onClose(() -> isClosed.set(true)); + try (LongStream ds = DefaultMethodStreams.delegateTo(s).takeWhile(e -> e < 3)) { + ds.count(); + } + assertTrue(isClosed.get()); + } + + @Test + public void testDoubleDefaultClose() { + AtomicBoolean isClosed = new AtomicBoolean(); + DoubleStream s = DoubleStream.of(1, 2, 3).onClose(() -> isClosed.set(true)); + try (DoubleStream ds = DefaultMethodStreams.delegateTo(s).takeWhile(e -> e < 3)) { + ds.count(); + } + assertTrue(isClosed.get()); + } } On Jul 8, 2015, at 4:58 AM, Tagir F. Valeev wrote: > Hello, > > I was looking at default implementation of new Stream > takeWhile/dropWhile methods: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071597-take-drop-while/webrev/src/java.base/share/classes/java/util/stream/Stream.java.cdiff.html > > I think in order to make this default behavior more consistent, the > original Stream must be closed when the returned one is closed. Thus, > takeWhile return statement should look like this: > > return StreamSupport.stream( > new WhileOps.UnorderedWhileSpliterator.OfRef.Taking<> > (spliterator(), true, predicate), > isParallel()).onClose(this::close); > > The same for dropWhile method. > > What do you think? > > Regards, > Tagir Valeev. > From paul.sandoz at oracle.com Wed Jul 8 08:33:06 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 8 Jul 2015 10:33:06 +0200 Subject: JDK 9 RFR of JDK-8130402: Mark intermittently failing test: tools/pack200/PackTestZip64.java In-Reply-To: <559CD8C9.5090400@oracle.com> References: <559CD8C9.5090400@oracle.com> Message-ID: <6154A94A-B29D-401B-9A04-9F479425BDFB@oracle.com> On Jul 8, 2015, at 10:01 AM, Amy Lu wrote: > tools/pack200/PackTestZip64.java > > This test has been observed to fail intermittently. This patch is to mark it accordingly with keyword 'intermittent'. > > bug: https://bugs.openjdk.java.net/browse/JDK-8130402 > webrev: http://cr.openjdk.java.net/~amlu/8130402/webrev.00/ > +1 I can push for you. Paul. From miroslav.kos at oracle.com Wed Jul 8 12:29:33 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Wed, 08 Jul 2015 14:29:33 +0200 Subject: [9] RFR: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B API, JAX-WS API, SAAJ-API Message-ID: <559D17AD.6000205@oracle.com> Hi everybody, I'd like to ask for review for following issue: JBS: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B API, JAX-WS API, SAAJ-API webrev: http://cr.openjdk.java.net/~mkos/8130753/jaxws.01/ It addresses all the javadoc errors in all 3 JSRs: SAAJ, JAX-B and JAX-WS and it is also syncup with standalone repos. This clean-up had to be done in order to proceed with changes necessary for Jigsaw (specifically SAAJ API and possibly JAX-WS). Thanks Miran From joe.darcy at oracle.com Wed Jul 8 16:36:16 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 08 Jul 2015 09:36:16 -0700 Subject: [9] RFR: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B API, JAX-WS API, SAAJ-API In-Reply-To: <559D17AD.6000205@oracle.com> References: <559D17AD.6000205@oracle.com> Message-ID: <559D5180.2020306@oracle.com> Hi Miroslav, At least some of the changes in the patch are going in the wrong direction. There are many instances toward the start of the patch where {@code Foo} is listed as being replaced by Foo, but {@code Foo} is what we want to use now. Are you running doclint over Java source or in a docs build to verify the changes? Thanks, -Joe On 7/8/2015 5:29 AM, Miroslav Kos wrote: > Hi everybody, > I'd like to ask for review for following issue: > > JBS: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B > API, JAX-WS API, SAAJ-API > webrev: http://cr.openjdk.java.net/~mkos/8130753/jaxws.01/ > > It addresses all the javadoc errors in all 3 JSRs: SAAJ, JAX-B and > JAX-WS and it is also syncup with standalone repos. This clean-up had > to be done in order to proceed with changes necessary for Jigsaw > (specifically SAAJ API and possibly JAX-WS). > > Thanks > Miran > > From Kirk.Shoop at microsoft.com Wed Jul 8 16:50:30 2015 From: Kirk.Shoop at microsoft.com (Kirk Shoop) Date: Wed, 8 Jul 2015 16:50:30 +0000 Subject: RFR 8124977 cmdline encoding challenges on Windows In-Reply-To: <558C017A.2020708@oracle.com> References: <558C017A.2020708@oracle.com> Message-ID: > -----Original Message----- > From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com] > > Hi Kirk, > > Thanks for proposing this change. > > If you notice all the posix calls are wrapped in JLI_* this gives us the > ability to use "W" functions. I almost got it done, several years ago, > but we upgraded to VS2010 and my work based on VS2003 keeled over, > meanwhile my focus was "shifted" to something else. > > main.c: is really envisioned to be a stub compiled by the tool launchers, > like java, javac, javah, jar etc. I prefer to see all the heavy logic in > this file moved to the platform specific file windows/java_md.* > Heavy logic is moved out of main.c file. > For the reason specified above we need to move fprintf or any naked posix > calls to JLI_* indirections. > Posix calls are wrapped in JLI_* functions. > I don't see any tests ? The tests must be written in java and placed in > jdk/test/tools/launcher, there is a helper framework TestHelper.java. > A new test for our changes is added. > There are other changes in nio, charsets etc, this will be reviewed by my > colleague specializing in that area (Sherman) cc'ed. > > > Thanks > > Kumar Thank you for the feedback! Valery prepared a new webrev which I placed here: http://cr.openjdk.java.net/~kshoop/8124977/webrev.01 Thanks, Kirk From huizhe.wang at oracle.com Wed Jul 8 16:56:00 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 08 Jul 2015 09:56:00 -0700 Subject: [9] RFR: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B API, JAX-WS API, SAAJ-API In-Reply-To: <559D17AD.6000205@oracle.com> References: <559D17AD.6000205@oracle.com> Message-ID: <559D5620.2090105@oracle.com> --- old/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java 2015-07-08 13:25:02.000000000 +0200 +++ new/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java 2015-07-08 13:25:01.000000000 +0200 - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. Did you mean "2015"? Also in PreDestroy.java. --- old/src/java.xml.bind/share/classes/javax/xml/bind/JAXBContext.java 2015-07-08 13:25:03.000000000 +0200 +++ new/src/java.xml.bind/share/classes/javax/xml/bind/JAXBContext.java 2015-07-08 13:25:03.000000000 +0200 Many replacement of @code with , is that intended? (maybe accidentally reversed to old format?) @code is better than . Although it will work, tt is not recommended at W3C . --- old/src/java.xml.ws/share/classes/javax/xml/soap/SOAPConnection.java 2015-07-08 13:25:10.000000000 +0200 +++ new/src/java.xml.ws/share/classes/javax/xml/soap/SOAPConnection.java 2015-07-08 13:25:10.000000000 +0200 - * 

+ * {@code
   *      SOAPConnectionFactory factory = 
SOAPConnectionFactory.newInstance();
   *      SOAPConnection con = factory.createConnection();
- *
- * A SOAPConnection object can be used to send messages + * } @code does not handle linebreaks unfortunately, you still need 
 
outside of @code.

-Joe

On 7/8/2015 5:29 AM, Miroslav Kos wrote:
> Hi everybody,
> I'd like to ask for review for following issue:
>
> JBS: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B 
> API, JAX-WS API, SAAJ-API
> webrev: http://cr.openjdk.java.net/~mkos/8130753/jaxws.01/
>
> It addresses all the javadoc errors in all 3 JSRs: SAAJ, JAX-B and 
> JAX-WS and it is also syncup with standalone repos. This clean-up had 
> to be done in order to proceed with changes necessary for Jigsaw 
> (specifically SAAJ API and possibly JAX-WS).
>
> Thanks
> Miran
>
>



From ivan.gerasimov at oracle.com  Wed Jul  8 17:02:47 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 08 Jul 2015 20:02:47 +0300
Subject: RFR [XXS] 8130778: (str) Make
	AbstractStringBuilder.append(CharSequence, 
	int, int) to throw StringIndexOutOfBoundsException
In-Reply-To: <559BCC26.8080107@oracle.com>
References: <559BCC26.8080107@oracle.com>
Message-ID: <559D57B7.4050904@oracle.com>

Resending the request with a new bug id.

On 07.07.2015 15:55, Ivan Gerasimov wrote:
> Hi!
>
> With the fix for JDK-8077242 ((str) Optimize 
> AbstractStringBuilder.append(CharSequence, int, int) for String 
> argument) a change in behavior was introduced.
>
> In the places, where sb.append(str.substring(from, to)) used to be 
> called, in the case of wrong indices StringIndexOutOfBoundsException 
> was thrown.
> Now, after I replaced the code to sb.append(str, from, to), in such 
> cases IndexOutOfBoundsException is thrown.
>
> The proposal is to make AbstractStringBuilder.append(CharSequence, 
> int, int) throw more specific StringIndexOutOfBoundsException, which
> 1) will eliminate the regression,
> 2) will be more consistent with most other methods of 
> AbstractStringBuilder, which throw StringIndexOutOfBoundsException.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8130646
> WEBREV: http://cr.openjdk.java.net/~igerasim/8130646/00/webrev/
>
> Sincerely yours,
> Ivan
>
>
>



From xueming.shen at oracle.com  Sat Jul 11 17:22:47 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sat, 11 Jul 2015 10:22:47 -0700
Subject: RFR [XXS] 8130778: (str) Make
	AbstractStringBuilder.append(CharSequence, 
	int, int) to throw StringIndexOutOfBoundsException
In-Reply-To: <559D57B7.4050904@oracle.com>
References: <559BCC26.8080107@oracle.com> <559D57B7.4050904@oracle.com>
Message-ID: <55A150E7.5010002@oracle.com>

Hi,

Arguably the "StringIndexOutOfBoundsException" should only be used when the index is out
of a "String" (the builder included) boundary, but the offending object and the index here is
CharSequence/index. The places that throw StringIndexoutOfBoundsException are all for the
index/offset/length of the ASB.

-sherman

On 07/08/2015 10:02 AM, Ivan Gerasimov wrote:
> Resending the request with a new bug id.
>
> On 07.07.2015 15:55, Ivan Gerasimov wrote:
>> Hi!
>>
>> With the fix for JDK-8077242 ((str) Optimize AbstractStringBuilder.append(CharSequence, int, int) for String argument) a change in behavior was introduced.
>>
>> In the places, where sb.append(str.substring(from, to)) used to be called, in the case of wrong indices StringIndexOutOfBoundsException was thrown.
>> Now, after I replaced the code to sb.append(str, from, to), in such cases IndexOutOfBoundsException is thrown.
>>
>> The proposal is to make AbstractStringBuilder.append(CharSequence, int, int) throw more specific StringIndexOutOfBoundsException, which
>> 1) will eliminate the regression,
>> 2) will be more consistent with most other methods of AbstractStringBuilder, which throw StringIndexOutOfBoundsException.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8130646
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8130646/00/webrev/
>>
>> Sincerely yours,
>> Ivan
>>
>>
>>
>



From ivan.gerasimov at oracle.com  Wed Jul  8 17:46:05 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 08 Jul 2015 20:46:05 +0300
Subject: RFR [XXS] 8130778: (str) Make
	AbstractStringBuilder.append(CharSequence, 
	int, int) to throw StringIndexOutOfBoundsException
In-Reply-To: <55A150E7.5010002@oracle.com>
References: <559BCC26.8080107@oracle.com> <559D57B7.4050904@oracle.com>
	<55A150E7.5010002@oracle.com>
Message-ID: <559D61DD.50308@oracle.com>

Thanks Sherman for looking to that!

On 11.07.2015 20:22, Xueming Shen wrote:
> Hi,
>
> Arguably the "StringIndexOutOfBoundsException" should only be used 
> when the index is out
> of a "String" (the builder included) boundary, but the offending 
> object and the index here is
> CharSequence/index. The places that throw 
> StringIndexoutOfBoundsException are all for the
> index/offset/length of the ASB.
>

That was my first thought too, but I found places where 
StringIndexoutOfBoundsException is thrown when violating array char[] 
boundaries.
So, I thought we can use it with CharSequence too.

Here's an example:
     public AbstractStringBuilder insert(int index, char[] str, int offset,
                                         int len)
     {
         if ((index < 0) || (index > length()))
             throw new StringIndexOutOfBoundsException(index);
         if ((offset < 0) || (len < 0) || (offset > str.length - len))
             throw new StringIndexOutOfBoundsException(
                 "offset " + offset + ", len " + len + ", str.length "
                 + str.length);

The second check is about str array, though the exception is 
StringIndexOutOfBoundsException.

Sincerely yours,
Ivan


> -sherman
>
> On 07/08/2015 10:02 AM, Ivan Gerasimov wrote:
>> Resending the request with a new bug id.
>>
>> On 07.07.2015 15:55, Ivan Gerasimov wrote:
>>> Hi!
>>>
>>> With the fix for JDK-8077242 ((str) Optimize 
>>> AbstractStringBuilder.append(CharSequence, int, int) for String 
>>> argument) a change in behavior was introduced.
>>>
>>> In the places, where sb.append(str.substring(from, to)) used to be 
>>> called, in the case of wrong indices StringIndexOutOfBoundsException 
>>> was thrown.
>>> Now, after I replaced the code to sb.append(str, from, to), in such 
>>> cases IndexOutOfBoundsException is thrown.
>>>
>>> The proposal is to make AbstractStringBuilder.append(CharSequence, 
>>> int, int) throw more specific StringIndexOutOfBoundsException, which
>>> 1) will eliminate the regression,
>>> 2) will be more consistent with most other methods of 
>>> AbstractStringBuilder, which throw StringIndexOutOfBoundsException.
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8130646
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8130646/00/webrev/
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>>
>>>
>>
>
>
>



From martinrb at google.com  Wed Jul  8 18:55:49 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 8 Jul 2015 11:55:49 -0700
Subject: RFR: 6260652: (coll) Arrays.asList(x).toArray().getClass() should
	be Object[].class
In-Reply-To: <56B51E8A-5636-457F-93F8-151C96A5312B@oracle.com>
References: 
	<0FC2087B-1F26-447F-AE08-0E255E1462E6@oracle.com>
	
	<56B51E8A-5636-457F-93F8-151C96A5312B@oracle.com>
Message-ID: 

On Wed, Jul 8, 2015 at 12:59 AM, Paul Sandoz  wrote:

>
> > The comment remains correct even if 6260652 is fixed.
> > I can't think up a clearly better one.
>
> I would recommend at least removing the issue id (since that refers
> specifically to Arrays.asList rather than something general that cannot
> actually be fixed). Up to you.
>

I improved (?) various comments referring to  6260652

-        // c.toArray might (incorrectly) not return Object[] (see 6260652)
+        // defend against c.toArray (incorrectly) not returning Object[]
+        // (see e.g. https://bugs.openjdk.java.net/browse/JDK-6260652)

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Arrays.asList.toArray/


From Roger.Riggs at Oracle.com  Wed Jul  8 20:07:09 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 8 Jul 2015 16:07:09 -0400
Subject: RFR 9: 8098852 : java/lang/ProcessHandle/InfoTest.java failed:
	total cpu time
In-Reply-To: <559C67F2.6080609@oracle.com>
References: 
	<559C67F2.6080609@oracle.com>
Message-ID: <559D82ED.80202@Oracle.com>

Hi Joe,

Updated the webrev in place.
    http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/

On 7/7/2015 7:59 PM, joe darcy wrote:
> Hi Roger,
>
> Generally looks okay; a few comments and suggestions
>
> 114             long cpulooptime = 100;             // 100 ms
>
> How about
>
>     cpuLoopTime
ok
>
> instead? Same comment for the other variables that don't follow 
> camel-case conventions.
I fixed a few others too.
>
>  284                         long cpumillis = 
> Long.valueOf(args[nextArg++]);
>  285                         long cpuTarget = getCpuTime() + cpumillis 
> * 1_000_000L;
>  286                         while (getCpuTime() < cpuTarget) {
>
> Is it correct to multiply cpu-millis by 1e6 rather than 1e3?
Yes, CpuTime is in nanos = millis * 1000 (micros) * 1000

Thanks, Roger

>
> -Joe
>
> On 7/7/2015 11:52 AM, Roger Riggs wrote:
>> Please review this ProcessHandle test change to cleanup intermittent 
>> failures.
>> The cpuloop timing uses the cputime of the spawned process and the
>> test runs fewer iterations and relaxes the threshold.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8098852
>>
>> Thanks, Roger
>>
>



From Roger.Riggs at Oracle.com  Wed Jul  8 20:16:12 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 8 Jul 2015 16:16:12 -0400
Subject: RFR 9: 8130296 [TESTBUG] java/lang/ProcessHandle/OnExitTest -
	Unaccounted for children
In-Reply-To: <98c9f919-388f-40e3-88cf-f21f5b773a40@default>
References: <98c9f919-388f-40e3-88cf-f21f5b773a40@default>
Message-ID: <559D850C.2030100@Oracle.com>

Ping and note this change is simplified after the fix for 8085981.

Please review this change to a ProcessHandle test to address 
intermittent failures.
Unexpected subprocesses has been observed. The test succeeds if all of the
processes under test are accounted for; others are ignored.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-exit-8130296/

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

Thanks, Roger




From joe.darcy at oracle.com  Wed Jul  8 20:50:32 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 08 Jul 2015 13:50:32 -0700
Subject: RFR 9: 8130296 [TESTBUG] java/lang/ProcessHandle/OnExitTest -
	Unaccounted for children
In-Reply-To: <559D850C.2030100@Oracle.com>
References: <98c9f919-388f-40e3-88cf-f21f5b773a40@default>
	<559D850C.2030100@Oracle.com>
Message-ID: <559D8D18.6030101@oracle.com>

Hi Roger,

I think the test would be more robust if the hard-coded time out window 
was a function of the time factor the test was running under. Maybe

     10 seconds * timeout

IIRC, the timeout factor is available as an environment variable (or 
similar) in the running tests. I checked the jtreg docs quickly and 
didn't find it, but I believe the jdk regression tests have already had 
a pass to do this kind of update so there should be some guiding 
examples in the sources.

Thanks,

-Joe

On 7/8/2015 1:16 PM, Roger Riggs wrote:
> Ping and note this change is simplified after the fix for 8085981.
>
> Please review this change to a ProcessHandle test to address 
> intermittent failures.
> Unexpected subprocesses has been observed. The test succeeds if all of 
> the
> processes under test are accounted for; others are ignored.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-exit-8130296/
>
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8130296
>
> Thanks, Roger
>
>



From joe.darcy at oracle.com  Wed Jul  8 21:05:51 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 08 Jul 2015 14:05:51 -0700
Subject: RFR 9: 8098852 : java/lang/ProcessHandle/InfoTest.java failed:
	total cpu time
In-Reply-To: <559D82ED.80202@Oracle.com>
References: 
	<559C67F2.6080609@oracle.com> <559D82ED.80202@Oracle.com>
Message-ID: <559D90AF.9020402@oracle.com>

Hi Roger,

A few comments on the updated version.

  284                         long cpuMillis = 
Long.valueOf(args[nextArg++]);
  285                         long cpuTarget = getCpuTime() + cpuMillis 
* 1_000_000L;
  286                         while (getCpuTime() < cpuTarget) {
  287                             // burn the cpu until the time is up

Are there interger overflow issues in adding to the result of getCpuTime()?

Should the time values be a function of the timeout factor the test is 
running under?

If the answer to both of these is "no," then I think this is okay as-is.

Thanks,

-Joe

On 7/8/2015 1:07 PM, Roger Riggs wrote:
> Hi Joe,
>
> Updated the webrev in place.
> http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
>
> On 7/7/2015 7:59 PM, joe darcy wrote:
>> Hi Roger,
>>
>> Generally looks okay; a few comments and suggestions
>>
>> 114             long cpulooptime = 100;             // 100 ms
>>
>> How about
>>
>>     cpuLoopTime
> ok
>>
>> instead? Same comment for the other variables that don't follow 
>> camel-case conventions.
> I fixed a few others too.
>>
>>  284                         long cpumillis = 
>> Long.valueOf(args[nextArg++]);
>>  285                         long cpuTarget = getCpuTime() + 
>> cpumillis * 1_000_000L;
>>  286                         while (getCpuTime() < cpuTarget) {
>>
>> Is it correct to multiply cpu-millis by 1e6 rather than 1e3?
> Yes, CpuTime is in nanos = millis * 1000 (micros) * 1000
>
> Thanks, Roger
>
>>
>> -Joe
>>
>> On 7/7/2015 11:52 AM, Roger Riggs wrote:
>>> Please review this ProcessHandle test change to cleanup intermittent 
>>> failures.
>>> The cpuloop timing uses the cputime of the spawned process and the
>>> test runs fewer iterations and relaxes the threshold.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8098852
>>>
>>> Thanks, Roger
>>>
>>
>



From Roger.Riggs at Oracle.com  Wed Jul  8 21:08:21 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 8 Jul 2015 17:08:21 -0400
Subject: RFR 9: 8130296 [TESTBUG] java/lang/ProcessHandle/OnExitTest -
	Unaccounted for children
In-Reply-To: <559D8D18.6030101@oracle.com>
References: <98c9f919-388f-40e3-88cf-f21f5b773a40@default>
	<559D850C.2030100@Oracle.com> <559D8D18.6030101@oracle.com>
Message-ID: <559D9145.9020800@Oracle.com>

Hi Joe,

Webrev updated in place.

The jdk.testlibrary.Utils.adjustTimeout(timeout) returns the timeout 
adjusted
by the jtreg -timeoutFactor argument.

Thanks, Roger


On 7/8/2015 4:50 PM, joe darcy wrote:
> Hi Roger,
>
> I think the test would be more robust if the hard-coded time out 
> window was a function of the time factor the test was running under. 
> Maybe
>
>     10 seconds * timeout
>
> IIRC, the timeout factor is available as an environment variable (or 
> similar) in the running tests. I checked the jtreg docs quickly and 
> didn't find it, but I believe the jdk regression tests have already 
> had a pass to do this kind of update so there should be some guiding 
> examples in the sources.
>
> Thanks,
>
> -Joe
>
> On 7/8/2015 1:16 PM, Roger Riggs wrote:
>> Ping and note this change is simplified after the fix for 8085981.
>>
>> Please review this change to a ProcessHandle test to address 
>> intermittent failures.
>> Unexpected subprocesses has been observed. The test succeeds if all 
>> of the
>> processes under test are accounted for; others are ignored.
>>
>> Webrev:
>>    http://cr.openjdk.java.net/~rriggs/webrev-exit-8130296/
>>
>> Issue:
>>    https://bugs.openjdk.java.net/browse/JDK-8130296
>>
>> Thanks, Roger
>>
>>
>



From Roger.Riggs at Oracle.com  Wed Jul  8 21:11:37 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 8 Jul 2015 17:11:37 -0400
Subject: RFR 9: 8098852 : java/lang/ProcessHandle/InfoTest.java failed:
	total cpu time
In-Reply-To: <559D90AF.9020402@oracle.com>
References: 
	<559C67F2.6080609@oracle.com> <559D82ED.80202@Oracle.com>
	<559D90AF.9020402@oracle.com>
Message-ID: <559D9209.1070805@Oracle.com>

Hi Joe,

The cputime loop  is designed to run up the cputime of a child process a 
specific
amount so that the parent can verify that the cputime information reported
about the child is correct.

No issues on either point, the range long in nanoseconds is more than 
sufficient for
the length of time this test is running.  The test only asks for the 
child to use 100ms.

Thanks, Roger

On 7/8/2015 5:05 PM, joe darcy wrote:
> Hi Roger,
>
> A few comments on the updated version.
>
>  284                         long cpuMillis = 
> Long.valueOf(args[nextArg++]);
>  285                         long cpuTarget = getCpuTime() + cpuMillis 
> * 1_000_000L;
>  286                         while (getCpuTime() < cpuTarget) {
>  287                             // burn the cpu until the time is up
>
> Are there interger overflow issues in adding to the result of 
> getCpuTime()?
>
> Should the time values be a function of the timeout factor the test is 
> running under?
>
> If the answer to both of these is "no," then I think this is okay as-is.
>
> Thanks,
>
> -Joe
>
> On 7/8/2015 1:07 PM, Roger Riggs wrote:
>> Hi Joe,
>>
>> Updated the webrev in place.
>> http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
>>
>> On 7/7/2015 7:59 PM, joe darcy wrote:
>>> Hi Roger,
>>>
>>> Generally looks okay; a few comments and suggestions
>>>
>>> 114             long cpulooptime = 100;             // 100 ms
>>>
>>> How about
>>>
>>>     cpuLoopTime
>> ok
>>>
>>> instead? Same comment for the other variables that don't follow 
>>> camel-case conventions.
>> I fixed a few others too.
>>>
>>>  284                         long cpumillis = 
>>> Long.valueOf(args[nextArg++]);
>>>  285                         long cpuTarget = getCpuTime() + 
>>> cpumillis * 1_000_000L;
>>>  286                         while (getCpuTime() < cpuTarget) {
>>>
>>> Is it correct to multiply cpu-millis by 1e6 rather than 1e3?
>> Yes, CpuTime is in nanos = millis * 1000 (micros) * 1000
>>
>> Thanks, Roger
>>
>>>
>>> -Joe
>>>
>>> On 7/7/2015 11:52 AM, Roger Riggs wrote:
>>>> Please review this ProcessHandle test change to cleanup 
>>>> intermittent failures.
>>>> The cpuloop timing uses the cputime of the spawned process and the
>>>> test runs fewer iterations and relaxes the threshold.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8098852
>>>>
>>>> Thanks, Roger
>>>>
>>>
>>
>



From joe.darcy at oracle.com  Wed Jul  8 22:35:34 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 08 Jul 2015 15:35:34 -0700
Subject: RFR 9: 8130296 [TESTBUG] java/lang/ProcessHandle/OnExitTest -
	Unaccounted for children
In-Reply-To: <559D9145.9020800@Oracle.com>
References: <98c9f919-388f-40e3-88cf-f21f5b773a40@default>
	<559D850C.2030100@Oracle.com> <559D8D18.6030101@oracle.com>
	<559D9145.9020800@Oracle.com>
Message-ID: <559DA5B6.1030704@oracle.com>

Looks good Roger; thanks,

-Joe

On 7/8/2015 2:08 PM, Roger Riggs wrote:
> Hi Joe,
>
> Webrev updated in place.
>
> The jdk.testlibrary.Utils.adjustTimeout(timeout) returns the timeout 
> adjusted
> by the jtreg -timeoutFactor argument.
>
> Thanks, Roger
>
>
> On 7/8/2015 4:50 PM, joe darcy wrote:
>> Hi Roger,
>>
>> I think the test would be more robust if the hard-coded time out 
>> window was a function of the time factor the test was running under. 
>> Maybe
>>
>>     10 seconds * timeout
>>
>> IIRC, the timeout factor is available as an environment variable (or 
>> similar) in the running tests. I checked the jtreg docs quickly and 
>> didn't find it, but I believe the jdk regression tests have already 
>> had a pass to do this kind of update so there should be some guiding 
>> examples in the sources.
>>
>> Thanks,
>>
>> -Joe
>>
>> On 7/8/2015 1:16 PM, Roger Riggs wrote:
>>> Ping and note this change is simplified after the fix for 8085981.
>>>
>>> Please review this change to a ProcessHandle test to address 
>>> intermittent failures.
>>> Unexpected subprocesses has been observed. The test succeeds if all 
>>> of the
>>> processes under test are accounted for; others are ignored.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-exit-8130296/
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8130296
>>>
>>> Thanks, Roger
>>>
>>>
>>
>



From joe.darcy at oracle.com  Thu Jul  9 00:59:52 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 08 Jul 2015 17:59:52 -0700
Subject: RFR 9: 8098852 : java/lang/ProcessHandle/InfoTest.java failed:
	total cpu time
In-Reply-To: <559D9209.1070805@Oracle.com>
References: 
	<559C67F2.6080609@oracle.com> <559D82ED.80202@Oracle.com>
	<559D90AF.9020402@oracle.com> <559D9209.1070805@Oracle.com>
Message-ID: <559DC788.40402@oracle.com>

Hi Roger,

Le me be more explicit, is getCpuTime() something that gets normalized 
to zero-ish at the start of each run or is it just a shapshot of some 
nano-second granularity counter? If it is the latter, it is possible 
that the counter value is negative or near the long overflow threshold.

-Joe

On 7/8/2015 2:11 PM, Roger Riggs wrote:
> Hi Joe,
>
> The cputime loop  is designed to run up the cputime of a child process 
> a specific
> amount so that the parent can verify that the cputime information reported
> about the child is correct.
>
> No issues on either point, the range long in nanoseconds is more than 
> sufficient for
> the length of time this test is running.  The test only asks for the 
> child to use 100ms.
>
> Thanks, Roger
>
> On 7/8/2015 5:05 PM, joe darcy wrote:
>> Hi Roger,
>>
>> A few comments on the updated version.
>>
>>  284                         long cpuMillis = 
>> Long.valueOf(args[nextArg++]);
>>  285                         long cpuTarget = getCpuTime() + 
>> cpuMillis * 1_000_000L;
>>  286                         while (getCpuTime() < cpuTarget) {
>>  287                             // burn the cpu until the time is up
>>
>> Are there interger overflow issues in adding to the result of 
>> getCpuTime()?
>>
>> Should the time values be a function of the timeout factor the test 
>> is running under?
>>
>> If the answer to both of these is "no," then I think this is okay as-is.
>>
>> Thanks,
>>
>> -Joe
>>
>> On 7/8/2015 1:07 PM, Roger Riggs wrote:
>>> Hi Joe,
>>>
>>> Updated the webrev in place.
>>> http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
>>>
>>> On 7/7/2015 7:59 PM, joe darcy wrote:
>>>> Hi Roger,
>>>>
>>>> Generally looks okay; a few comments and suggestions
>>>>
>>>> 114             long cpulooptime = 100;             // 100 ms
>>>>
>>>> How about
>>>>
>>>>     cpuLoopTime
>>> ok
>>>>
>>>> instead? Same comment for the other variables that don't follow 
>>>> camel-case conventions.
>>> I fixed a few others too.
>>>>
>>>>  284                         long cpumillis = 
>>>> Long.valueOf(args[nextArg++]);
>>>>  285                         long cpuTarget = getCpuTime() + 
>>>> cpumillis * 1_000_000L;
>>>>  286                         while (getCpuTime() < cpuTarget) {
>>>>
>>>> Is it correct to multiply cpu-millis by 1e6 rather than 1e3?
>>> Yes, CpuTime is in nanos = millis * 1000 (micros) * 1000
>>>
>>> Thanks, Roger
>>>
>>>>
>>>> -Joe
>>>>
>>>> On 7/7/2015 11:52 AM, Roger Riggs wrote:
>>>>> Please review this ProcessHandle test change to cleanup 
>>>>> intermittent failures.
>>>>> The cpuloop timing uses the cputime of the spawned process and the
>>>>> test runs fewer iterations and relaxes the threshold.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
>>>>>
>>>>> Issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8098852
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>
>>>
>>
>



From Roger.Riggs at Oracle.com  Thu Jul  9 01:31:51 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 08 Jul 2015 21:31:51 -0400
Subject: RFR 9: 8098852 : java/lang/ProcessHandle/InfoTest.java failed:
	total cpu time
In-Reply-To: <559DC788.40402@oracle.com>
References: 
	<559C67F2.6080609@oracle.com> <559D82ED.80202@Oracle.com>
	<559D90AF.9020402@oracle.com> <559D9209.1070805@Oracle.com>
	<559DC788.40402@oracle.com>
Message-ID: <559DCF07.4060905@Oracle.com>

Hi Joe,

The value is from the operating system as it keeps track of cputime for 
each process as
reported by java.lang.management. It starts at zero for each process 
started.


static long getCpuTime() {
     OperatingSystemMXBean osMbean = (OperatingSystemMXBean)ManagementFactory.getOperatingSystemMXBean();
     return osMbean.getProcessCpuTime();
}

Roger



On 7/8/15 8:59 PM, Joseph D. Darcy wrote:
> Hi Roger,
>
> Le me be more explicit, is getCpuTime() something that gets normalized 
> to zero-ish at the start of each run or is it just a shapshot of some 
> nano-second granularity counter? If it is the latter, it is possible 
> that the counter value is negative or near the long overflow threshold.
>
> -Joe
>
> On 7/8/2015 2:11 PM, Roger Riggs wrote:
>> Hi Joe,
>>
>> The cputime loop  is designed to run up the cputime of a child 
>> process a specific
>> amount so that the parent can verify that the cputime information 
>> reported
>> about the child is correct.
>>
>> No issues on either point, the range long in nanoseconds is more than 
>> sufficient for
>> the length of time this test is running.  The test only asks for the 
>> child to use 100ms.
>>
>> Thanks, Roger
>>
>> On 7/8/2015 5:05 PM, joe darcy wrote:
>>> Hi Roger,
>>>
>>> A few comments on the updated version.
>>>
>>>  284                         long cpuMillis = 
>>> Long.valueOf(args[nextArg++]);
>>>  285                         long cpuTarget = getCpuTime() + 
>>> cpuMillis * 1_000_000L;
>>>  286                         while (getCpuTime() < cpuTarget) {
>>>  287                             // burn the cpu until the time is up
>>>
>>> Are there interger overflow issues in adding to the result of 
>>> getCpuTime()?
>>>
>>> Should the time values be a function of the timeout factor the test 
>>> is running under?
>>>
>>> If the answer to both of these is "no," then I think this is okay as-is.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 7/8/2015 1:07 PM, Roger Riggs wrote:
>>>> Hi Joe,
>>>>
>>>> Updated the webrev in place.
>>>> http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
>>>>
>>>> On 7/7/2015 7:59 PM, joe darcy wrote:
>>>>> Hi Roger,
>>>>>
>>>>> Generally looks okay; a few comments and suggestions
>>>>>
>>>>> 114             long cpulooptime = 100;             // 100 ms
>>>>>
>>>>> How about
>>>>>
>>>>>     cpuLoopTime
>>>> ok
>>>>>
>>>>> instead? Same comment for the other variables that don't follow 
>>>>> camel-case conventions.
>>>> I fixed a few others too.
>>>>>
>>>>>  284                         long cpumillis = 
>>>>> Long.valueOf(args[nextArg++]);
>>>>>  285                         long cpuTarget = getCpuTime() + 
>>>>> cpumillis * 1_000_000L;
>>>>>  286                         while (getCpuTime() < cpuTarget) {
>>>>>
>>>>> Is it correct to multiply cpu-millis by 1e6 rather than 1e3?
>>>> Yes, CpuTime is in nanos = millis * 1000 (micros) * 1000
>>>>
>>>> Thanks, Roger
>>>>
>>>>>
>>>>> -Joe
>>>>>
>>>>> On 7/7/2015 11:52 AM, Roger Riggs wrote:
>>>>>> Please review this ProcessHandle test change to cleanup 
>>>>>> intermittent failures.
>>>>>> The cpuloop timing uses the cputime of the spawned process and the
>>>>>> test runs fewer iterations and relaxes the threshold.
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
>>>>>>
>>>>>> Issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8098852
>>>>>>
>>>>>> Thanks, Roger
>>>>>>
>>>>>
>>>>
>>>
>>
>



From paul.sandoz at oracle.com  Thu Jul  9 07:28:55 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 9 Jul 2015 09:28:55 +0200
Subject: RFR: 6260652: (coll) Arrays.asList(x).toArray().getClass() should
	be Object[].class
In-Reply-To: 
References: 
	<0FC2087B-1F26-447F-AE08-0E255E1462E6@oracle.com>
	
	<56B51E8A-5636-457F-93F8-151C96A5312B@oracle.com>
	
Message-ID: 


On Jul 8, 2015, at 8:55 PM, Martin Buchholz  wrote:

> 
> 
> On Wed, Jul 8, 2015 at 12:59 AM, Paul Sandoz  wrote:
> 
> > The comment remains correct even if 6260652 is fixed.
> > I can't think up a clearly better one.
> 
> I would recommend at least removing the issue id (since that refers specifically to Arrays.asList rather than something general that cannot actually be fixed). Up to you.
> 
> I improved (?) various comments referring to  6260652
> 
> -        // c.toArray might (incorrectly) not return Object[] (see 6260652)
> +        // defend against c.toArray (incorrectly) not returning Object[]
> +        // (see e.g. https://bugs.openjdk.java.net/browse/JDK-6260652)
> 

I think that is improved, linking is also helpful.

+1

Paul.

> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Arrays.asList.toArray/



From miroslav.kos at oracle.com  Thu Jul  9 10:36:15 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Thu, 09 Jul 2015 12:36:15 +0200
Subject: [9] RFR: 8130753: Sync-up javadoc changes in jax-ws area -
	includes JAX-B API, JAX-WS API, SAAJ-API
In-Reply-To: <559D5180.2020306@oracle.com>
References: <559D17AD.6000205@oracle.com> <559D5180.2020306@oracle.com>
Message-ID: <559E4E9F.90808@oracle.com>

Hi again,
thanks for valuable feedback - I missed those before. Second version of 
a patch:
http://cr.openjdk.java.net/~mkos/8130753/jaxws.02/

issues addressed:

  *    :  not backporting correctly changes done in jdk repo, will
    fix in standalone repos
  *   
/ {@code : added 
 again, in two cases used 

  *   copyright years : fixed


Otherwise I don't use -Xdoclint but I generate javadoc so I see warnings -
before patch:
10 errors
78 warnings

after patch:
78 warnings

I also used specdiff to doblecheck that there are no differences in 
output javadoc - those are classes defined by JSRs, so no changes are 
wanted without MR. Only 2 changes found (typos). Additional issues 
(warnings) would be addressed during MRs.

Thanks
Miran


On 08/07/15 18:36, joe darcy wrote:
> Hi Miroslav,
>
> At least some of the changes in the patch are going in the wrong 
> direction. There are many instances toward the start of the patch 
> where {@code Foo} is listed as being replaced by Foo, but 
> {@code Foo} is what we want to use now.
>
> Are you running doclint over Java source or in a docs build to verify 
> the changes?
>
> Thanks,
>
> -Joe
>
> On 7/8/2015 5:29 AM, Miroslav Kos wrote:
>> Hi everybody,
>> I'd like to ask for review for following issue:
>>
>> JBS: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B 
>> API, JAX-WS API, SAAJ-API
>> webrev: http://cr.openjdk.java.net/~mkos/8130753/jaxws.01/
>>
>> It addresses all the javadoc errors in all 3 JSRs: SAAJ, JAX-B and 
>> JAX-WS and it is also syncup with standalone repos. This clean-up had 
>> to be done in order to proceed with changes necessary for Jigsaw 
>> (specifically SAAJ API and possibly JAX-WS).
>>
>> Thanks
>> Miran
>>
>>
>



From philipp at bibik.de  Thu Jul  9 15:55:41 2015
From: philipp at bibik.de (Philipp Bibik)
Date: Thu, 09 Jul 2015 17:55:41 +0200
Subject: Idea to Java ArrayLists
Message-ID: <559E997D.9000606@bibik.de>

Hi,

I'm Philipp Bibik and a 16 jear old free time developer.
I was born and live in Germany and have only an bad school english,
so sorry for any grammar and spelling mistakes.

I have an idea to improve the Java ArrayList API.
Lists are one of the most imported and used components in the Java API.
Although there are relay well designed, there was always something that 
annoyed me.

If you want to create an ArrayList with "String" as diamond operator and 
add the Strings
"1" to "5" to them, you need to do something like this:

     ArrayList strings = new ArrayList<>();
     strings.add("1");
     strings.add("2");
     strings.add("3");
     strings.add("4");
     strings.add("5");

I added a few lines of code the the ArrayList class:

     /**
      * @param e array whose elements are to be placed into this list
      */
     @SafeVarargs
     public ArrayList(E... e) {
         elementData = e;
         size = elementData.length;
     }

After adding the lines above I was able to accomplish the same result
with 77 chars / 5 lines less code:

     ArrayList strings = new ArrayList<>("1", "2", "3", "4", "5");

In my opinion adding a constructor like this to the 
"java.util.ArrayList" class and
all other (at least some) classes, implementing the "java.util.List" 
interface
would be a big improvement to Java SE9.

Thanks for reading,

- Philipp Bibik.


From forax at univ-mlv.fr  Thu Jul  9 16:21:12 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 9 Jul 2015 18:21:12 +0200
Subject: Idea to Java ArrayLists
In-Reply-To: <559E997D.9000606@bibik.de>
References: <559E997D.9000606@bibik.de>
Message-ID: <559E9F78.20906@univ-mlv.fr>

Hi Philipp,

there is an issue with your proposal, with
   ArrayList list = new ArrayList<>(1);
and
   ArrayList list = new ArrayList<>(1, 2);

the first line will create an empty array list, the integer will be used 
to define the capacity of the list,
the second line will create a list with two values.

There is an open bug to add a bunch of static methods 'of' to do 
something similar to what you want,
   https://bugs.openjdk.java.net/browse/JDK-8026106
this is something that a lot of people will like to have and i hope that 
this can be integrated in 9.

cheers,
R?mi

On 07/09/2015 05:55 PM, Philipp Bibik wrote:
> Hi,
>
> I'm Philipp Bibik and a 16 jear old free time developer.
> I was born and live in Germany and have only an bad school english,
> so sorry for any grammar and spelling mistakes.
>
> I have an idea to improve the Java ArrayList API.
> Lists are one of the most imported and used components in the Java API.
> Although there are relay well designed, there was always something 
> that annoyed me.
>
> If you want to create an ArrayList with "String" as diamond operator 
> and add the Strings
> "1" to "5" to them, you need to do something like this:
>
>     ArrayList strings = new ArrayList<>();
>     strings.add("1");
>     strings.add("2");
>     strings.add("3");
>     strings.add("4");
>     strings.add("5");
>
> I added a few lines of code the the ArrayList class:
>
>     /**
>      * @param e array whose elements are to be placed into this list
>      */
>     @SafeVarargs
>     public ArrayList(E... e) {
>         elementData = e;
>         size = elementData.length;
>     }
>
> After adding the lines above I was able to accomplish the same result
> with 77 chars / 5 lines less code:
>
>     ArrayList strings = new ArrayList<>("1", "2", "3", "4", "5");
>
> In my opinion adding a constructor like this to the 
> "java.util.ArrayList" class and
> all other (at least some) classes, implementing the "java.util.List" 
> interface
> would be a big improvement to Java SE9.
>
> Thanks for reading,
>
> - Philipp Bibik.



From martinrb at google.com  Thu Jul  9 16:26:26 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 9 Jul 2015 09:26:26 -0700
Subject: Idea to Java ArrayLists
In-Reply-To: <559E997D.9000606@bibik.de>
References: <559E997D.9000606@bibik.de>
Message-ID: 

Many people have thought about this kind of thing, but it's complicated.
Many people regret having java constructors (instead of factory methods).
Many people regret how varargs worked out, because generics and arrays
don't mix well.
Many people think java should have List and Map literals.
See how guava tried to do ImmutableList.of, which works well in practice,
but is ugly ("don't look behind the curtain!")

On Thu, Jul 9, 2015 at 8:55 AM, Philipp Bibik  wrote:

> Hi,
>
> I'm Philipp Bibik and a 16 jear old free time developer.
> I was born and live in Germany and have only an bad school english,
> so sorry for any grammar and spelling mistakes.
>
> I have an idea to improve the Java ArrayList API.
> Lists are one of the most imported and used components in the Java API.
> Although there are relay well designed, there was always something that
> annoyed me.
>
> If you want to create an ArrayList with "String" as diamond operator and
> add the Strings
> "1" to "5" to them, you need to do something like this:
>
>     ArrayList strings = new ArrayList<>();
>     strings.add("1");
>     strings.add("2");
>     strings.add("3");
>     strings.add("4");
>     strings.add("5");
>
> I added a few lines of code the the ArrayList class:
>
>     /**
>      * @param e array whose elements are to be placed into this list
>      */
>     @SafeVarargs
>     public ArrayList(E... e) {
>         elementData = e;
>         size = elementData.length;
>     }
>
> After adding the lines above I was able to accomplish the same result
> with 77 chars / 5 lines less code:
>
>     ArrayList strings = new ArrayList<>("1", "2", "3", "4", "5");
>
> In my opinion adding a constructor like this to the "java.util.ArrayList"
> class and
> all other (at least some) classes, implementing the "java.util.List"
> interface
> would be a big improvement to Java SE9.
>
> Thanks for reading,
>
> - Philipp Bibik.
>


From blackdrag at gmx.org  Thu Jul  9 17:12:29 2015
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Thu, 09 Jul 2015 19:12:29 +0200
Subject: JDK9 changes to Date?
Message-ID: <559EAB7D.9090200@gmx.org>

Hi,

after fixing some JDK9 related bugs in our build for Groovy we stumbled 
over

new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy", 
Locale.US).parse("Thu Jan 01 01:00:00 CET 1970")

failing to parse with

> java.text.ParseException: Unparseable date: "Thu Jan 01 01:00:00 CET 1970"
>     at java.text.DateFormat.parse(DateFormat.java:366)

This happens not with my local machine using jdk1.9.0-ea-b68, but it 
does fail on our CI server used revision 0906b79c9df4 for this.

A second case is this one:

>         Locale locale = Locale.UK
>         Locale.setDefault locale
>         TimeZone.setDefault TimeZone.getTimeZone('Etc/GMT')
>         Date d = new Date(0)
>         assertEquals '01/01/70', DateFormat.getDateInstance(DateFormat.SHORT).format(d);

the assert used to work, but now the format changed to print 01/01/1970 
instead of 01/01/70. With the same constellation regarding jdk versions.

Are those expected to fail? Can someone verify this?

bye Jochen Theodorou

-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/



From kedar.mhaswade at gmail.com  Thu Jul  9 17:34:16 2015
From: kedar.mhaswade at gmail.com (kedar mhaswade)
Date: Thu, 9 Jul 2015 10:34:16 -0700
Subject: Idea to Java ArrayLists
In-Reply-To: <559E997D.9000606@bibik.de>
References: <559E997D.9000606@bibik.de>
Message-ID: 

Philipp,

Wouldn't Arrays.asList

work for you?

e.g.
List strings = Arrays.asList("1", "2", "3"); or
List strings = Arrays.asList("1", "2", "3", "4", "five");

Regards,
Kedar

On Thu, Jul 9, 2015 at 8:55 AM, Philipp Bibik  wrote:

> Hi,
>
> I'm Philipp Bibik and a 16 jear old free time developer.
> I was born and live in Germany and have only an bad school english,
> so sorry for any grammar and spelling mistakes.
>
> I have an idea to improve the Java ArrayList API.
> Lists are one of the most imported and used components in the Java API.
> Although there are relay well designed, there was always something that
> annoyed me.
>
> If you want to create an ArrayList with "String" as diamond operator and
> add the Strings
> "1" to "5" to them, you need to do something like this:
>
>     ArrayList strings = new ArrayList<>();
>     strings.add("1");
>     strings.add("2");
>     strings.add("3");
>     strings.add("4");
>     strings.add("5");
>
> I added a few lines of code the the ArrayList class:
>
>     /**
>      * @param e array whose elements are to be placed into this list
>      */
>     @SafeVarargs
>     public ArrayList(E... e) {
>         elementData = e;
>         size = elementData.length;
>     }
>
> After adding the lines above I was able to accomplish the same result
> with 77 chars / 5 lines less code:
>
>     ArrayList strings = new ArrayList<>("1", "2", "3", "4", "5");
>
> In my opinion adding a constructor like this to the "java.util.ArrayList"
> class and
> all other (at least some) classes, implementing the "java.util.List"
> interface
> would be a big improvement to Java SE9.
>
> Thanks for reading,
>
> - Philipp Bibik.
>


From pavel.rappo at oracle.com  Thu Jul  9 17:40:22 2015
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 9 Jul 2015 18:40:22 +0100
Subject: Idea to Java ArrayLists
In-Reply-To: 
References: <559E997D.9000606@bibik.de>
	
Message-ID: <612B30D0-2A9A-4353-8F08-3028506610FD@oracle.com>

Not quite. You don't have the ability to specify a particular implementation
(e.g. the thing won't work if what you want is, say, LinkedList)

> On 9 Jul 2015, at 18:34, kedar mhaswade  wrote:
> 
> Wouldn't Arrays.asList
> 
> work for you?



From lowasser at google.com  Thu Jul  9 17:46:15 2015
From: lowasser at google.com (Louis Wasserman)
Date: Thu, 09 Jul 2015 17:46:15 +0000
Subject: Idea to Java ArrayLists
In-Reply-To: <612B30D0-2A9A-4353-8F08-3028506610FD@oracle.com>
References: <559E997D.9000606@bibik.de>
	
	<612B30D0-2A9A-4353-8F08-3028506610FD@oracle.com>
Message-ID: 

Pavel, what you can do there is new ArrayList<>(Arrays.asList("1", "2",
"3", "4", "5"));

On Thu, Jul 9, 2015 at 10:40 AM Pavel Rappo  wrote:

> Not quite. You don't have the ability to specify a particular
> implementation
> (e.g. the thing won't work if what you want is, say, LinkedList)
>
> > On 9 Jul 2015, at 18:34, kedar mhaswade 
> wrote:
> >
> > Wouldn't Arrays.asList
> > <
> http://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#asList-T...-
> >
> > work for you?
>
>


From kedar.mhaswade at gmail.com  Thu Jul  9 17:52:54 2015
From: kedar.mhaswade at gmail.com (kedar mhaswade)
Date: Thu, 9 Jul 2015 10:52:54 -0700
Subject: Idea to Java ArrayLists
In-Reply-To: 
References: <559E997D.9000606@bibik.de>
	
	<612B30D0-2A9A-4353-8F08-3028506610FD@oracle.com>
	
Message-ID: 

Yeah, or LinkedList strings = new LinkedList<>(Arrays.asList("1",
"2", "3"));

But I guess what Phillip really wants is to be able to *express*
ArrayList
strings = ["1", "2", "3"]; and I believe there's a reason he can't have it
:-(

On Thu, Jul 9, 2015 at 10:46 AM, Louis Wasserman 
wrote:

> Pavel, what you can do there is new ArrayList<>(Arrays.asList("1", "2",
> "3", "4", "5"));
>
> On Thu, Jul 9, 2015 at 10:40 AM Pavel Rappo 
> wrote:
>
>> Not quite. You don't have the ability to specify a particular
>> implementation
>> (e.g. the thing won't work if what you want is, say, LinkedList)
>>
>> > On 9 Jul 2015, at 18:34, kedar mhaswade 
>> wrote:
>> >
>> > Wouldn't Arrays.asList
>> > <
>> http://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#asList-T...-
>> >
>> > work for you?
>>
>>


From daniel.fuchs at oracle.com  Thu Jul  9 17:52:51 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 09 Jul 2015 19:52:51 +0200
Subject: Idea to Java ArrayLists
In-Reply-To: 
References: <559E997D.9000606@bibik.de>		<612B30D0-2A9A-4353-8F08-3028506610FD@oracle.com>
	
Message-ID: <559EB4F3.9060906@oracle.com>


Or Stream.of("1", "2", "3").collect(Collectors.toList()); :-)

-- daniel

On 09/07/15 19:46, Louis Wasserman wrote:
> Pavel, what you can do there is new ArrayList<>(Arrays.asList("1", "2",
> "3", "4", "5"));
>
> On Thu, Jul 9, 2015 at 10:40 AM Pavel Rappo  wrote:
>
>> Not quite. You don't have the ability to specify a particular
>> implementation
>> (e.g. the thing won't work if what you want is, say, LinkedList)
>>
>>> On 9 Jul 2015, at 18:34, kedar mhaswade 
>> wrote:
>>>
>>> Wouldn't Arrays.asList
>>> <
>> http://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#asList-T...-
>>>
>>> work for you?
>>
>>



From ivan.gerasimov at oracle.com  Thu Jul  9 17:58:05 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 09 Jul 2015 20:58:05 +0300
Subject: RFR [XXS] 8130778: (str) Make
	AbstractStringBuilder.append(CharSequence, 
	int, int) to throw StringIndexOutOfBoundsException
In-Reply-To: <55A150E7.5010002@oracle.com>
References: <559BCC26.8080107@oracle.com> <559D57B7.4050904@oracle.com>
	<55A150E7.5010002@oracle.com>
Message-ID: <559EB62D.90600@oracle.com>

What about this variant?
http://cr.openjdk.java.net/~igerasim/8130778/00/webrev/

So, we'll throw SOOB only if the CharSequence is actually a String.
I've also added the same code to insert(int,CharSequence,int,int) for 
the sake of symmetry.

Sincerely yours,
Ivan

On 11.07.2015 20:22, Xueming Shen wrote:
> Hi,
>
> Arguably the "StringIndexOutOfBoundsException" should only be used 
> when the index is out
> of a "String" (the builder included) boundary, but the offending 
> object and the index here is
> CharSequence/index. The places that throw 
> StringIndexoutOfBoundsException are all for the
> index/offset/length of the ASB.
>
> -sherman
>
> On 07/08/2015 10:02 AM, Ivan Gerasimov wrote:
>> Resending the request with a new bug id.
>>
>> On 07.07.2015 15:55, Ivan Gerasimov wrote:
>>> Hi!
>>>
>>> With the fix for JDK-8077242 ((str) Optimize 
>>> AbstractStringBuilder.append(CharSequence, int, int) for String 
>>> argument) a change in behavior was introduced.
>>>
>>> In the places, where sb.append(str.substring(from, to)) used to be 
>>> called, in the case of wrong indices StringIndexOutOfBoundsException 
>>> was thrown.
>>> Now, after I replaced the code to sb.append(str, from, to), in such 
>>> cases IndexOutOfBoundsException is thrown.
>>>
>>> The proposal is to make AbstractStringBuilder.append(CharSequence, 
>>> int, int) throw more specific StringIndexOutOfBoundsException, which
>>> 1) will eliminate the regression,
>>> 2) will be more consistent with most other methods of 
>>> AbstractStringBuilder, which throw StringIndexOutOfBoundsException.
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8130646
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8130646/00/webrev/
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>>
>>>
>>
>
>
>



From huizhe.wang at oracle.com  Thu Jul  9 18:05:37 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 09 Jul 2015 11:05:37 -0700
Subject: [9] RFR: 8130753: Sync-up javadoc changes in jax-ws area -
	includes JAX-B API, JAX-WS API, SAAJ-API
In-Reply-To: <559E4E9F.90808@oracle.com>
References: <559D17AD.6000205@oracle.com> <559D5180.2020306@oracle.com>
	<559E4E9F.90808@oracle.com>
Message-ID: <559EB7F1.4080405@oracle.com>


On 7/9/2015 3:36 AM, Miroslav Kos wrote:
> Hi again,
> thanks for valuable feedback - I missed those before. Second version 
> of a patch:
> http://cr.openjdk.java.net/~mkos/8130753/jaxws.02/
>
> issues addressed:
>
>   *   :  not backporting correctly changes done in jdk repo, will
>     fix in standalone repos
>   *  
/ {@code : added 
 again, in two cases used 

>   *  copyright years : fixed
>

That's a lot of changes.  They look good to me.
>
>
> Otherwise I don't use -Xdoclint but I generate javadoc so I see 
> warnings -
> before patch:
> 10 errors
> 78 warnings
>
> after patch:
> 78 warnings
>
> I also used specdiff to doblecheck that there are no differences in 
> output javadoc - those are classes defined by JSRs, so no changes are 
> wanted without MR. Only 2 changes found (typos). Additional issues 
> (warnings) would be addressed during MRs.

Indeed, if you turn on warnings, you'd get tons of them. Same here, I 
have to wait until I'm done with features to deal with them.

Cheers,
Joe

>
> Thanks
> Miran
>
>
> On 08/07/15 18:36, joe darcy wrote:
>> Hi Miroslav,
>>
>> At least some of the changes in the patch are going in the wrong 
>> direction. There are many instances toward the start of the patch 
>> where {@code Foo} is listed as being replaced by Foo, but 
>> {@code Foo} is what we want to use now.
>>
>> Are you running doclint over Java source or in a docs build to verify 
>> the changes?
>>
>> Thanks,
>>
>> -Joe
>>
>> On 7/8/2015 5:29 AM, Miroslav Kos wrote:
>>> Hi everybody,
>>> I'd like to ask for review for following issue:
>>>
>>> JBS: 8130753: Sync-up javadoc changes in jax-ws area - includes 
>>> JAX-B API, JAX-WS API, SAAJ-API
>>> webrev: http://cr.openjdk.java.net/~mkos/8130753/jaxws.01/
>>>
>>> It addresses all the javadoc errors in all 3 JSRs: SAAJ, JAX-B and 
>>> JAX-WS and it is also syncup with standalone repos. This clean-up 
>>> had to be done in order to proceed with changes necessary for Jigsaw 
>>> (specifically SAAJ API and possibly JAX-WS).
>>>
>>> Thanks
>>> Miran
>>>
>>>
>>
>



From pavel.rappo at oracle.com  Thu Jul  9 19:05:38 2015
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 9 Jul 2015 20:05:38 +0100
Subject: Idea to Java ArrayLists
In-Reply-To: 
References: <559E997D.9000606@bibik.de>
	
	<612B30D0-2A9A-4353-8F08-3028506610FD@oracle.com>
	
Message-ID: <7430270C-F43D-4543-9520-832DDA437DC0@oracle.com>


> On 9 Jul 2015, at 18:46, Louis Wasserman  wrote:
> 
>  what you can do there is new ArrayList<>(Arrays.asList("1", "2", "3", "4", "5"));

Louis, sure we can do this. No problem with that. But what we are really talking
about here (as far as I understand) is a convenience. In my opinion there's no
much difference between

   new ArrayList<>(Arrays.asList("1", "2", "3", "4", "5"));

and

   ArrayList l = new ArrayList<>();
   l.addAll(Arrays.asList("1", "2", "3", "4", "5"));

or

   ArrayList l = new ArrayList<>();
   Arrays.asList("1", "2", "3", "4", "5").forEach(l::add);

etc. Thanks for collection types connectivity.

In other words I think the difference between readable and not-so-easily-readable
code in this particular example is very subjective. What we have here is a very
special case of creating a _small_ list of easily enumerable elements. I hope
this work [1] will solve the problem or at least will make it a lot less severe.

------------------------------------------------------------------------------
[1] https://bugs.openjdk.java.net/browse/JDK-8048330



From naoto.sato at oracle.com  Thu Jul  9 19:06:16 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 09 Jul 2015 12:06:16 -0700
Subject: JDK9 changes to Date?
In-Reply-To: <559EAB7D.9090200@gmx.org>
References: <559EAB7D.9090200@gmx.org>
Message-ID: <559EC628.7020507@oracle.com>

Hi Jochen,

It is likely that these are caused by the default locale data change to 
CLDR with 8008577.

On 7/9/15 10:12 AM, Jochen Theodorou wrote:
> Hi,
>
> after fixing some JDK9 related bugs in our build for Groovy we stumbled
> over
>
> new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy",
> Locale.US).parse("Thu Jan 01 01:00:00 CET 1970")
>
> failing to parse with
>
>> java.text.ParseException: Unparseable date: "Thu Jan 01 01:00:00 CET
>> 1970"
>>     at java.text.DateFormat.parse(DateFormat.java:366)
>
> This happens not with my local machine using jdk1.9.0-ea-b68, but it
> does fail on our CI server used revision 0906b79c9df4 for this.

This seems to be the same issue which has already been reported in 8130845.

>
> A second case is this one:
>
>>         Locale locale = Locale.UK
>>         Locale.setDefault locale
>>         TimeZone.setDefault TimeZone.getTimeZone('Etc/GMT')
>>         Date d = new Date(0)
>>         assertEquals '01/01/70',
>> DateFormat.getDateInstance(DateFormat.SHORT).format(d);
>
> the assert used to work, but now the format changed to print 01/01/1970
> instead of 01/01/70. With the same constellation regarding jdk versions.

This is expected, as the short date format for UK in CLDR is "dd/MM/y".

Naoto


From blackdrag at gmx.org  Thu Jul  9 19:26:44 2015
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Thu, 09 Jul 2015 21:26:44 +0200
Subject: JDK9 changes to Date?
In-Reply-To: <559EC628.7020507@oracle.com>
References: <559EAB7D.9090200@gmx.org> <559EC628.7020507@oracle.com>
Message-ID: <559ECAF4.9070107@gmx.org>

but both examples set a locale I thought

Am 09.07.2015 21:06, schrieb Naoto Sato:
> Hi Jochen,
>
> It is likely that these are caused by the default locale data change to
> CLDR with 8008577.
>
> On 7/9/15 10:12 AM, Jochen Theodorou wrote:
>> Hi,
>>
>> after fixing some JDK9 related bugs in our build for Groovy we stumbled
>> over
>>
>> new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy",
>> Locale.US).parse("Thu Jan 01 01:00:00 CET 1970")
>>
>> failing to parse with
>>
>>> java.text.ParseException: Unparseable date: "Thu Jan 01 01:00:00 CET
>>> 1970"
>>>     at java.text.DateFormat.parse(DateFormat.java:366)
>>
>> This happens not with my local machine using jdk1.9.0-ea-b68, but it
>> does fail on our CI server used revision 0906b79c9df4 for this.
>
> This seems to be the same issue which has already been reported in 8130845.
>
>>
>> A second case is this one:
>>
>>>         Locale locale = Locale.UK
>>>         Locale.setDefault locale
>>>         TimeZone.setDefault TimeZone.getTimeZone('Etc/GMT')
>>>         Date d = new Date(0)
>>>         assertEquals '01/01/70',
>>> DateFormat.getDateInstance(DateFormat.SHORT).format(d);
>>
>> the assert used to work, but now the format changed to print 01/01/1970
>> instead of 01/01/70. With the same constellation regarding jdk versions.
>
> This is expected, as the short date format for UK in CLDR is "dd/MM/y".
>
> Naoto


-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/



From blackdrag at gmx.org  Thu Jul  9 19:39:41 2015
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Thu, 09 Jul 2015 21:39:41 +0200
Subject: JDK9 changes to Date?
In-Reply-To: <559ECB31.9080600@oracle.com>
References: <559EAB7D.9090200@gmx.org> <559EC628.7020507@oracle.com>
	<559ECA29.4030600@gmx.org> <559ECB31.9080600@oracle.com>
Message-ID: <559ECDFD.40403@gmx.org>

That means the US locale cannot understand CET as timezone then?

And... it assuming that TimeZone.getTimeZone('Etc/GMT') returns the GMT 
timezone, it means the short format for a date changed from using 70 for 
the year to 1970? Or is that CLDR related as well?

bye blackdrag

Am 09.07.2015 21:27, schrieb Naoto Sato:
> I meant the root cause seems to be the same between your first issue and
> 8130845, where parsing short time zone names has some problem regardless
> of it's the ROOT locale or not.
>
> Naoto
>
> On 7/9/15 12:23 PM, Jochen Theodorou wrote:
>> but both examples set a locale I thought
>>
>> Am 09.07.2015 21:06, schrieb Naoto Sato:
>>> Hi Jochen,
>>>
>>> It is likely that these are caused by the default locale data change to
>>> CLDR with 8008577.
>>>
>>> On 7/9/15 10:12 AM, Jochen Theodorou wrote:
>>>> Hi,
>>>>
>>>> after fixing some JDK9 related bugs in our build for Groovy we stumbled
>>>> over
>>>>
>>>> new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy",
>>>> Locale.US).parse("Thu Jan 01 01:00:00 CET 1970")
>>>>
>>>> failing to parse with
>>>>
>>>>> java.text.ParseException: Unparseable date: "Thu Jan 01 01:00:00 CET
>>>>> 1970"
>>>>>     at java.text.DateFormat.parse(DateFormat.java:366)
>>>>
>>>> This happens not with my local machine using jdk1.9.0-ea-b68, but it
>>>> does fail on our CI server used revision 0906b79c9df4 for this.
>>>
>>> This seems to be the same issue which has already been reported in
>>> 8130845.
>>>
>>>>
>>>> A second case is this one:
>>>>
>>>>>         Locale locale = Locale.UK
>>>>>         Locale.setDefault locale
>>>>>         TimeZone.setDefault TimeZone.getTimeZone('Etc/GMT')
>>>>>         Date d = new Date(0)
>>>>>         assertEquals '01/01/70',
>>>>> DateFormat.getDateInstance(DateFormat.SHORT).format(d);
>>>>
>>>> the assert used to work, but now the format changed to print 01/01/1970
>>>> instead of 01/01/70. With the same constellation regarding jdk
>>>> versions.
>>>
>>> This is expected, as the short date format for UK in CLDR is "dd/MM/y".
>>>
>>> Naoto
>>
>>


-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/



From forax at univ-mlv.fr  Thu Jul  9 19:46:38 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 9 Jul 2015 21:46:38 +0200
Subject: Idea to Java ArrayLists
In-Reply-To: <7430270C-F43D-4543-9520-832DDA437DC0@oracle.com>
References: <559E997D.9000606@bibik.de>
	
	<612B30D0-2A9A-4353-8F08-3028506610FD@oracle.com>
	
	<7430270C-F43D-4543-9520-832DDA437DC0@oracle.com>
Message-ID: <559ECF9E.5070609@univ-mlv.fr>

On 07/09/2015 09:05 PM, Pavel Rappo wrote:
>> On 9 Jul 2015, at 18:46, Louis Wasserman  wrote:
>>
>>   what you can do there is new ArrayList<>(Arrays.asList("1", "2", "3", "4", "5"));
> Louis, sure we can do this. No problem with that. But what we are really talking
> about here (as far as I understand) is a convenience. In my opinion there's no
> much difference between
>
>     new ArrayList<>(Arrays.asList("1", "2", "3", "4", "5"));
>
> and
>
>     ArrayList l = new ArrayList<>();
>     l.addAll(Arrays.asList("1", "2", "3", "4", "5"));
>
> or
>
>     ArrayList l = new ArrayList<>();
>     Arrays.asList("1", "2", "3", "4", "5").forEach(l::add);
>
> etc. Thanks for collection types connectivity.

just to be complete , there is also

    ArrayList l = new ArrayList<>();
    Collections.addAll(l, "1", "2", "3", "4", "5");

which avoid the allocation of the intermediary list.

>
> In other words I think the difference between readable and not-so-easily-readable
> code in this particular example is very subjective. What we have here is a very
> special case of creating a _small_ list of easily enumerable elements. I hope
> this work [1] will solve the problem or at least will make it a lot less severe.
>
> ------------------------------------------------------------------------------
> [1] https://bugs.openjdk.java.net/browse/JDK-8048330
>

cheers,
R?mi



From blackdrag at gmx.org  Thu Jul  9 19:47:13 2015
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Thu, 09 Jul 2015 21:47:13 +0200
Subject: JDK9 changes to Date?
In-Reply-To: <559ECDFD.40403@gmx.org>
References: <559EAB7D.9090200@gmx.org> <559EC628.7020507@oracle.com>
	<559ECA29.4030600@gmx.org> <559ECB31.9080600@oracle.com>
	<559ECDFD.40403@gmx.org>
Message-ID: <559ECFC1.3030206@gmx.org>

ok, so https://bugs.openjdk.java.net/browse/JDK-6712094 tells me that 
the long year format is the right one for Locale.UK, and it mentions 
also CLDR. So I guess the change to CLDR by default made this change 
happen as well.

Am 09.07.2015 21:39, schrieb Jochen Theodorou:
> That means the US locale cannot understand CET as timezone then?
>
> And... it assuming that TimeZone.getTimeZone('Etc/GMT') returns the GMT
> timezone, it means the short format for a date changed from using 70 for
> the year to 1970? Or is that CLDR related as well?
>
> bye blackdrag
>
> Am 09.07.2015 21:27, schrieb Naoto Sato:
>> I meant the root cause seems to be the same between your first issue and
>> 8130845, where parsing short time zone names has some problem regardless
>> of it's the ROOT locale or not.
>>
>> Naoto
>>
>> On 7/9/15 12:23 PM, Jochen Theodorou wrote:
>>> but both examples set a locale I thought
>>>
>>> Am 09.07.2015 21:06, schrieb Naoto Sato:
>>>> Hi Jochen,
>>>>
>>>> It is likely that these are caused by the default locale data change to
>>>> CLDR with 8008577.
>>>>
>>>> On 7/9/15 10:12 AM, Jochen Theodorou wrote:
>>>>> Hi,
>>>>>
>>>>> after fixing some JDK9 related bugs in our build for Groovy we
>>>>> stumbled
>>>>> over
>>>>>
>>>>> new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy",
>>>>> Locale.US).parse("Thu Jan 01 01:00:00 CET 1970")
>>>>>
>>>>> failing to parse with
>>>>>
>>>>>> java.text.ParseException: Unparseable date: "Thu Jan 01 01:00:00 CET
>>>>>> 1970"
>>>>>>     at java.text.DateFormat.parse(DateFormat.java:366)
>>>>>
>>>>> This happens not with my local machine using jdk1.9.0-ea-b68, but it
>>>>> does fail on our CI server used revision 0906b79c9df4 for this.
>>>>
>>>> This seems to be the same issue which has already been reported in
>>>> 8130845.
>>>>
>>>>>
>>>>> A second case is this one:
>>>>>
>>>>>>         Locale locale = Locale.UK
>>>>>>         Locale.setDefault locale
>>>>>>         TimeZone.setDefault TimeZone.getTimeZone('Etc/GMT')
>>>>>>         Date d = new Date(0)
>>>>>>         assertEquals '01/01/70',
>>>>>> DateFormat.getDateInstance(DateFormat.SHORT).format(d);
>>>>>
>>>>> the assert used to work, but now the format changed to print
>>>>> 01/01/1970
>>>>> instead of 01/01/70. With the same constellation regarding jdk
>>>>> versions.
>>>>
>>>> This is expected, as the short date format for UK in CLDR is "dd/MM/y".
>>>>
>>>> Naoto
>>>
>>>
>
>


-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/



From pavel.rappo at oracle.com  Thu Jul  9 20:10:35 2015
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 9 Jul 2015 21:10:35 +0100
Subject: Idea to Java ArrayLists
In-Reply-To: <559ECF9E.5070609@univ-mlv.fr>
References: <559E997D.9000606@bibik.de>
	
	<612B30D0-2A9A-4353-8F08-3028506610FD@oracle.com>
	
	<7430270C-F43D-4543-9520-832DDA437DC0@oracle.com>
	<559ECF9E.5070609@univ-mlv.fr>
Message-ID: 


> On 9 Jul 2015, at 20:46, Remi Forax  wrote:
> 
> just to be complete , there is also
> 
>   ArrayList l = new ArrayList<>();
>   Collections.addAll(l, "1", "2", "3", "4", "5");
> 
> which avoid the allocation of the intermediary list.

Thanks Remi, I forgot about that. That's arguably the next best thing after
a per-type factory.



From staffan.friberg at oracle.com  Thu Jul  9 20:19:17 2015
From: staffan.friberg at oracle.com (Staffan Friberg)
Date: Thu, 09 Jul 2015 13:19:17 -0700
Subject: Idea to Java ArrayLists
In-Reply-To: 
References: <559E997D.9000606@bibik.de>		<612B30D0-2A9A-4353-8F08-3028506610FD@oracle.com>		<7430270C-F43D-4543-9520-832DDA437DC0@oracle.com>	<559ECF9E.5070609@univ-mlv.fr>
	
Message-ID: <559ED745.1090801@oracle.com>


On 07/09/2015 01:10 PM, Pavel Rappo wrote:
>> On 9 Jul 2015, at 20:46, Remi Forax  wrote:
>>
>> just to be complete , there is also
>>
>>    ArrayList l = new ArrayList<>();
>>    Collections.addAll(l, "1", "2", "3", "4", "5");
>>
>> which avoid the allocation of the intermediary list.
> Thanks Remi, I forgot about that. That's arguably the next best thing after
> a per-type factory.
>
Would it make sense to have a version that returns the Collection to 
further simplify the code?
Would probably require some work with generics to work nicely.

ArrayList l = Collections.addAll(new ArrayList<>(), "1", "2", "3", "4", "5");


//Staffan


From henry.jen at oracle.com  Fri Jul 10 03:48:28 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 9 Jul 2015 20:48:28 -0700
Subject: RFR - 8027634: Support @argfiles for java command-line tool
Message-ID: 

Hi,

Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer.

Some early comment is that we probably don?t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp ?c:\\foo bar\\lib;c:\\lib? instead of -cp c:\?foo bar?\lib;c:\lib.

I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well.

Anyhow, with the patch out, at least developer can build idk and have something to test with to see if this can fulfill their use cases.

Also, for tools other than java that use launcher, it?s possible to use -J at argfile to pass arguments. For example, if want to pass -J options to javac, it?s now possible to do so with javac -J at argfile, and put -J options in the argfile.

If the consensus is that such syntax compatibility is not important, we will go ahead remove the escaping support(except probably enable escape for quote itself) in quote, and maybe add support of quote within a token.

CCing build-dev for build changes, jdk9-dev for wider audience for tools.

Cheers,
Henry 

[1] https://bugs.openjdk.java.net/browse/JDK-8027634
[2] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#commandlineargfile
[3] http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/03e083639ee9/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java

From henry.jen at oracle.com  Fri Jul 10 03:50:24 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 9 Jul 2015 20:50:24 -0700
Subject: RFR - 8027634: Support @argfiles for java command-line tool
In-Reply-To: 
References: 
Message-ID: 

Sigh, forgot the link to the webrev again.

http://cr.openjdk.java.net/~henryjen/jdk9/8027634/webrev/

Cheers,
Henry

> On Jul 9, 2015, at 8:48 PM, Henry Jen  wrote:
> 
> Hi,
> 
> Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer.
> 
> Some early comment is that we probably don?t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp ?c:\\foo bar\\lib;c:\\lib? instead of -cp c:\?foo bar?\lib;c:\lib.
> 
> I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well.
> 
> Anyhow, with the patch out, at least developer can build idk and have something to test with to see if this can fulfill their use cases.
> 
> Also, for tools other than java that use launcher, it?s possible to use -J at argfile to pass arguments. For example, if want to pass -J options to javac, it?s now possible to do so with javac -J at argfile, and put -J options in the argfile.
> 
> If the consensus is that such syntax compatibility is not important, we will go ahead remove the escaping support(except probably enable escape for quote itself) in quote, and maybe add support of quote within a token.
> 
> CCing build-dev for build changes, jdk9-dev for wider audience for tools.
> 
> Cheers,
> Henry 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8027634
> [2] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#commandlineargfile
> [3] http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/03e083639ee9/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java



From felix.yang at oracle.com  Fri Jul 10 07:31:53 2015
From: felix.yang at oracle.com (FELIX YANG)
Date: Fri, 10 Jul 2015 15:31:53 +0800
Subject: [9]RFR 8130394: DatagramChannel tests need to be hardened to ignore
	stray datagrams
Message-ID: <559F74E9.2010500@oracle.com>

Hi all,
      please help to review the change for 8130394.

Issue:     https://bugs.openjdk.java.net/browse/JDK-8130394
Patch:    http://cr.openjdk.java.net/~fyuan/felix/8130394/

The patch updates tests to ignore stray datagrams, or at least print 
more information to ease troubleshooting.

thanks,
-Felix


From paul.sandoz at oracle.com  Fri Jul 10 08:46:46 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 10 Jul 2015 10:46:46 +0200
Subject: Idea to Java ArrayLists
In-Reply-To: <559E997D.9000606@bibik.de>
References: <559E997D.9000606@bibik.de>
Message-ID: 

Hi Philipp,

This area has been the subject of much discussion over the years.

Previously we investigated the idea of collection literals in the following research JEP:

  http://openjdk.java.net/jeps/186

See discussion on lambda-dev:

  http://mail.openjdk.java.net/pipermail/lambda-dev/2014-January/thread.html#11671

We concluded, as a result of that discussion, that it would instead be better to reduce the scope of the problem and focus on convenient factory methods. See the following draft JEP that Stuart is working on:

  http://openjdk.java.net/jeps/8048330

Paul.

On Jul 9, 2015, at 5:55 PM, Philipp Bibik  wrote:

> Hi,
> 
> I'm Philipp Bibik and a 16 jear old free time developer.
> I was born and live in Germany and have only an bad school english,
> so sorry for any grammar and spelling mistakes.
> 
> I have an idea to improve the Java ArrayList API.
> Lists are one of the most imported and used components in the Java API.
> Although there are relay well designed, there was always something that annoyed me.
> 
> If you want to create an ArrayList with "String" as diamond operator and add the Strings
> "1" to "5" to them, you need to do something like this:
> 
>    ArrayList strings = new ArrayList<>();
>    strings.add("1");
>    strings.add("2");
>    strings.add("3");
>    strings.add("4");
>    strings.add("5");
> 
> I added a few lines of code the the ArrayList class:
> 
>    /**
>     * @param e array whose elements are to be placed into this list
>     */
>    @SafeVarargs
>    public ArrayList(E... e) {
>        elementData = e;
>        size = elementData.length;
>    }
> 
> After adding the lines above I was able to accomplish the same result
> with 77 chars / 5 lines less code:
> 
>    ArrayList strings = new ArrayList<>("1", "2", "3", "4", "5");
> 
> In my opinion adding a constructor like this to the "java.util.ArrayList" class and
> all other (at least some) classes, implementing the "java.util.List" interface
> would be a big improvement to Java SE9.
> 
> Thanks for reading,
> 
> - Philipp Bibik.



From amaembo at gmail.com  Fri Jul 10 18:01:36 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Sat, 11 Jul 2015 00:01:36 +0600
Subject: Speed optimization of Spliterators.spliteratorUnknownSize for
	parallel case
Message-ID: <187983222.20150711000136@gmail.com>

Hello!

The problem of ineffective parallelization of spliteratorUnknownSize
for low-N/high-Q tasks was already discussed in the thread "Exploiting
concurrency with IteratorSpliterator of unknown size"
[ http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011968.html ]
It was proposed to modify some heuristics and/or add some parameters
to control them.

I have a simpler idea which allows to run in parallel high-Q tasks for
N <~ 3000 about twice faster without any API changes while having no
visible impact for high-N or sequential cases. Here's the gist with
proof-of-concept implementation (UnknownSizeSpliterator.java), JMH
benchmark (IteratorTest.java) and benchmarking results (performed
on Quad-Core i5-3340, Win7 64bit):
https://gist.github.com/amaembo/781c64a3b4f48fdeb196

The problem which I noticed is the following. When trySplit is
requested and JDK IteratorSpliterator fills the buffer, it may
suddenly discover that the source iterator has no more elements. At
this point the IteratorSpliterator splits in very uneven manner.
Namely it dumps everything into the ArraySpliterator leaving no
elements for itself. As it did not report the size previously, the
pipeline engine assumes that both parts are roughly equal which
result in very poor performance.

I merged both IteratorSpliterator and ArraySpliterator into single
class UnknownSizeSpliterator. When it sees that input spliterator has
no more elements, it converts itself into array-mode and splits right
here to two equal parts, thus the first call of trySplit for N < 1024
performs actual split.

Note that I did not change the heuristics at all, thus for big-N
tasks the results should be the same. My implementation is a little
bit simplified (no additional characteristics, no precondition
checks, no primitive implementations), but I guess current version is
ok for preliminary testing to decide whether it's good or bad.

This implementation might improve the performance of existing methods
like BufferedReader.lines, Files.lines, Pattern.splitAsStream when
using the parallel stream as well as user-defined iterator-based
spliterators. Also it maybe useful for JDK-8072727 feature
[ https://bugs.openjdk.java.net/browse/JDK-8072727 ].

What do you think?

With best regards,
Tagir Valeev.



From joe.darcy at oracle.com  Fri Jul 10 23:08:35 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 10 Jul 2015 16:08:35 -0700
Subject: [9] RFR: 8130753: Sync-up javadoc changes in jax-ws area -
	includes JAX-B API, JAX-WS API, SAAJ-API
In-Reply-To: <559E4E9F.90808@oracle.com>
References: <559D17AD.6000205@oracle.com> <559D5180.2020306@oracle.com>
	<559E4E9F.90808@oracle.com>
Message-ID: <55A05073.1050003@oracle.com>

Hello,

Note that as part of JEP 212, large parts of the sources in the jdk are 
now compiled with both lint and doclint checks enabled. For technical 
reasons explained in

     "FYI, coming soon: doclint checking of references"
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002343.html

the "reference" doclint category will be enforced in the main *javadoc* 
build rather than the javac build of the sources. Therefore, javadoc 
changes should include a docs build to verify the docs build still works 
(which is a good, if not commonly done, practice anyway).

Thanks,

-Joe

On 7/9/2015 3:36 AM, Miroslav Kos wrote:
> Hi again,
> thanks for valuable feedback - I missed those before. Second version 
> of a patch:
> http://cr.openjdk.java.net/~mkos/8130753/jaxws.02/
>
> issues addressed:
>
>   *   :  not backporting correctly changes done in jdk repo, will
>     fix in standalone repos
>   *  
/ {@code : added 
 again, in two cases used 

>   *  copyright years : fixed
>
>
> Otherwise I don't use -Xdoclint but I generate javadoc so I see 
> warnings -
> before patch:
> 10 errors
> 78 warnings
>
> after patch:
> 78 warnings
>
> I also used specdiff to doblecheck that there are no differences in 
> output javadoc - those are classes defined by JSRs, so no changes are 
> wanted without MR. Only 2 changes found (typos). Additional issues 
> (warnings) would be addressed during MRs.
>
> Thanks
> Miran
>
>
> On 08/07/15 18:36, joe darcy wrote:
>> Hi Miroslav,
>>
>> At least some of the changes in the patch are going in the wrong 
>> direction. There are many instances toward the start of the patch 
>> where {@code Foo} is listed as being replaced by Foo, but 
>> {@code Foo} is what we want to use now.
>>
>> Are you running doclint over Java source or in a docs build to verify 
>> the changes?
>>
>> Thanks,
>>
>> -Joe
>>
>> On 7/8/2015 5:29 AM, Miroslav Kos wrote:
>>> Hi everybody,
>>> I'd like to ask for review for following issue:
>>>
>>> JBS: 8130753: Sync-up javadoc changes in jax-ws area - includes 
>>> JAX-B API, JAX-WS API, SAAJ-API
>>> webrev: http://cr.openjdk.java.net/~mkos/8130753/jaxws.01/
>>>
>>> It addresses all the javadoc errors in all 3 JSRs: SAAJ, JAX-B and 
>>> JAX-WS and it is also syncup with standalone repos. This clean-up 
>>> had to be done in order to proceed with changes necessary for Jigsaw 
>>> (specifically SAAJ API and possibly JAX-WS).
>>>
>>> Thanks
>>> Miran
>>>
>>>
>>
>



From Ulf.Zibis at CoSoCo.de  Fri Jul 10 23:25:20 2015
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Sat, 11 Jul 2015 01:25:20 +0200
Subject: RFR 8124977 cmdline encoding challenges on Windows
In-Reply-To: 
References: 		<558C017A.2020708@oracle.com>
	
Message-ID: <55A05460.3010508@CoSoCo.de>



Am 08.07.2015 um 18:50 schrieb Kirk Shoop:
> Valery prepared a new webrev which I placed here:
>    http://cr.openjdk.java.net/~kshoop/8124977/webrev.01

May be better to avoid potetially superfluous lookup of UTF-8:

public static Charset defaultUnicodeCharset() {
     if (defaultUnicodeCharset == null) {
         synchronized (Charset.class) {
             String csn = AccessController.doPrivileged(
                     new GetPropertyAction("file.encoding.unicode"));  // indent 8 spaces !!
             if (csn == null || (defaultUnicodeCharset =lookup(csn)  == null)) {
                 defaultUnicodeCharset = forName("UTF-8");
             }
         }
     }
     return defaultUnicodeCharset;
}


-Ulf


From xueming.shen at oracle.com  Sat Jul 11 18:50:31 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sat, 11 Jul 2015 11:50:31 -0700
Subject: RFR 8124977 cmdline encoding challenges on Windows
In-Reply-To: 
References: 
	
	<558C017A.2020708@oracle.com>
	
Message-ID: <55A16577.8050302@oracle.com>

Hi Kirk,

Two questions

(1) Why do you need to change the "encoding" used by the java.io.Console 
class. My understanding
      is that the console encoding is specifically used to "talk" to the 
underlying terminal, it should just
      be the one used by the underlying terminal/console. I don't think 
the proposed change updates
      the underlying console encoding (something like chcp)  when 
-Dwindows.UnicodeConsole=true
      specified, if I read the webrev correctly. Instead, the 
Java_java_io_Console_encoding() probably
      need to be updated to return utf8 if the cp == 65001, so if the 
underlying terminal/console is
      using cp65001, the java.io.Console should encode/decode in utf8.
      I would assume the encoding of java.io.Condole should have nothing 
to do with using
      GetCommandLIneW() to parse the arguments in unicode in launcher?

(2) Why do you need a defaultUnicodeCharset() in Charset class? Seems to 
me the scope should/could
      be limited inside LauncherHelper.java?

Thanks,
-Sherman


On 7/8/15 9:50 AM, Kirk Shoop wrote:
>> -----Original Message-----
>> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
>>
>> Hi Kirk,
>>
>> Thanks for proposing this change.
>>
>> If you notice all the posix calls are wrapped in JLI_* this  gives us the
>> ability to use "W" functions.  I almost got it done, several years ago,
>> but we upgraded to VS2010 and my work based on VS2003 keeled over,
>> meanwhile my focus was  "shifted" to something else.
>>
>> main.c: is really envisioned to be a stub  compiled by the tool launchers,
>> like java, javac, javah, jar etc. I prefer to see all the heavy logic in
>> this file moved to the platform specific file windows/java_md.*
>>
> Heavy logic is moved out of main.c file.
>
>> For the reason specified above we need to move fprintf or any naked posix
>> calls to JLI_* indirections.
>>
> Posix calls are wrapped in JLI_* functions.
>
>> I don't see any tests ? The tests must be written in java and placed in
>> jdk/test/tools/launcher, there is a helper framework TestHelper.java.
>>
> A new test for our changes is added.
>
>> There are other changes in nio, charsets etc, this will be reviewed by my
>> colleague specializing in that area (Sherman) cc'ed.
>>
>>
>> Thanks
>>
>> Kumar
> Thank you for the feedback!
>
> Valery prepared a new webrev which I placed here:
>    http://cr.openjdk.java.net/~kshoop/8124977/webrev.01
>
> Thanks,
> Kirk



From spliterator at gmail.com  Sun Jul 12 09:56:15 2015
From: spliterator at gmail.com (Stefan Zobel)
Date: Sun, 12 Jul 2015 11:56:15 +0200
Subject: Typo in AbstractSpliterator Javadoc
Message-ID: 

Hi all,


I just noticed some typos in the
Spliterators.Abstract(Double/Int/Long)Spliterator Javadoc:

a) The forEachRemaining link label is "forEach" instead of
"forEachRemaining" in all AbstractSpliterators.

b) The primitive AbstractSpliterators Javadoc has a surplus "}" just before
the tryAdvance and forEach link labels.



Stefan


From ivan.gerasimov at oracle.com  Sun Jul 12 16:32:17 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sun, 12 Jul 2015 19:32:17 +0300
Subject: RFR [S] 8131034: Cleanup in j.u.regex.Pattern.quote()
Message-ID: <55A29691.5020109@oracle.com>

Hello!

There's a minor issue in the current implementation of Pattern.quote() 
with possible numeric overflow when calculating initial capacity of 
StringBuilder.
With the fix, some slight optimizations were done and a few typos were 
fixed.

Would you please help review the fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8131034
WEBREV: http://cr.openjdk.java.net/~igerasim/8131034/00/webrev/

Sincerely yours,
Ivan


From ivan.gerasimov at oracle.com  Sun Jul 12 21:01:48 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 13 Jul 2015 00:01:48 +0300
Subject: RFR [S] 6854417: TESTBUG: java/util/regex/RegExTest.java fails
	intermittently
Message-ID: <55A2D5BC.8050700@oracle.com>

Hello!

RegExTest fails sometimes in checking Boyer-Moore search.
This is because it was assumed that after insertion a pattern into a 
string at some position, we'll find it at the same position.
That's not true if we insert 'aa' into 'xxaxx' at index 3, cause then 
we'll find 'aa' at index 2.

The proposed fix is to exclude patterns that start and end with the same 
substring, because only those can cause this kind of problem.

Would you please help review the fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-6854417
WEBREV: http://cr.openjdk.java.net/~igerasim/6854417/00/webrev/

Sincerely yours,
Ivan



From yuka.kamiya at oracle.com  Mon Jul 13 08:20:13 2015
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Mon, 13 Jul 2015 17:20:13 +0900
Subject: RFR: 8032446: Support Unicode 7.0.0 in JDK 9
Message-ID: <55A374BD.6090807@oracle.com>

Hello,

Please review the fix for 8032446 to support Unicode 7 in JDK 9.

https://bugs.openjdk.java.net/browse/JDK-8032446
http://cr.openjdk.java.net/~peytoia/8032446/webrev.00/

- Internal review for both open & closed parts has been completed.
- Changes in sun.text.* packages are mostly porting from ICU4J. (Thank
you very much, ICU4J project.)
- Because Unicode 8 was released last month, this fix will be
overwritten (partially) in near future.

Thanks,
--
Yuka



From paul.sandoz at oracle.com  Mon Jul 13 09:19:23 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 13 Jul 2015 11:19:23 +0200
Subject: RFR 8131052 Documentation of AbstractSpliterator refers to forEach
	rather than forEachRemaining
In-Reply-To: 
References: 
Message-ID: <70C9F5D9-094D-4CDE-B348-E0B364C2747F@oracle.com>

Hi

Stefan, thanks.

See below for a patch to the documentation of all abstract spliterators.

Paul.

diff -r a3175de2e354 src/java.base/share/classes/java/util/Spliterators.java
--- a/src/java.base/share/classes/java/util/Spliterators.java	Tue Jun 09 07:10:03 2015 +0100
+++ b/src/java.base/share/classes/java/util/Spliterators.java	Mon Jul 13 11:16:24 2015 +0200
@@ -1235,8 +1235,8 @@
      * 
An extending class need only
      * implement {@link #tryAdvance(java.util.function.Consumer) tryAdvance}.
      * The extending class should override
-     * {@link #forEachRemaining(java.util.function.Consumer) forEach} if it can
-     * provide a more performant implementation.
+     * {@link #forEachRemaining(java.util.function.Consumer) forEachRemaining}
+     * if it can provide a more performant implementation.
      *
      * @apiNote
      * This class is a useful aid for creating a spliterator when it is not
@@ -1358,8 +1358,8 @@
      * 
To implement a spliterator an extending class need only
      * implement {@link #tryAdvance(java.util.function.IntConsumer)}
      * tryAdvance}.  The extending class should override
-     * {@link #forEachRemaining(java.util.function.IntConsumer)} forEach} if it
-     * can provide a more performant implementation.
+     * {@link #forEachRemaining(java.util.function.IntConsumer)} forEachRemaining}
+     * if it can provide a more performant implementation.
      *
      * @apiNote
      * This class is a useful aid for creating a spliterator when it is not
@@ -1468,8 +1468,8 @@
      * 
To implement a spliterator an extending class need only
      * implement {@link #tryAdvance(java.util.function.LongConsumer)}
      * tryAdvance}.  The extending class should override
-     * {@link #forEachRemaining(java.util.function.LongConsumer)} forEach} if it
-     * can provide a more performant implementation.
+     * {@link #forEachRemaining(java.util.function.LongConsumer)} forEachRemaining}
+     * if it can provide a more performant implementation.
      *
      * @apiNote
      * This class is a useful aid for creating a spliterator when it is not
@@ -1578,8 +1578,8 @@
      * 
To implement a spliterator an extending class need only
      * implement {@link #tryAdvance(java.util.function.DoubleConsumer)}
      * tryAdvance}.  The extending class should override
-     * {@link #forEachRemaining(java.util.function.DoubleConsumer)} forEach} if
-     * it can provide a more performant implementation.
+     * {@link #forEachRemaining(java.util.function.DoubleConsumer)} forEachRemaining}
+     * if it can provide a more performant implementation.
      *
      * @apiNote
      * This class is a useful aid for creating a spliterator when it is not

On Jul 12, 2015, at 11:56 AM, Stefan Zobel  wrote:

> Hi all,
> 
> 
> I just noticed some typos in the
> Spliterators.Abstract(Double/Int/Long)Spliterator Javadoc:
> 
> a) The forEachRemaining link label is "forEach" instead of
> "forEachRemaining" in all AbstractSpliterators.
> 
> b) The primitive AbstractSpliterators Javadoc has a surplus "}" just before
> the tryAdvance and forEach link labels.
> 
> 
> 
> Stefan



From paul.sandoz at oracle.com  Mon Jul 13 09:57:03 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 13 Jul 2015 11:57:03 +0200
Subject: RFR [S] 8131034: Cleanup in j.u.regex.Pattern.quote()
In-Reply-To: <55A29691.5020109@oracle.com>
References: <55A29691.5020109@oracle.com>
Message-ID: <42F6A248-0724-452A-99BC-1327F2F5A30C@oracle.com>


On Jul 12, 2015, at 6:32 PM, Ivan Gerasimov  wrote:

> Hello!
> 
> There's a minor issue in the current implementation of Pattern.quote() with possible numeric overflow when calculating initial capacity of StringBuilder.
> With the fix, some slight optimizations were done and a few typos were fixed.
> 
> Would you please help review the fix?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8131034
> WEBREV: http://cr.openjdk.java.net/~igerasim/8131034/00/webrev/
> 

Looks ok.

     /**
-     * The pattern is converted to normalizedD form and then a pure group
+     * The pattern is converted to normalized form and then a pure group
      * is constructed to match canonical equivalences of the characters.
      */

The "D" in "normalizedD form" may well be short hand for "canonical decomposition" (Normalizer.Form.NFD) as in "normalized canonical decomposition form".

Paul.

> Sincerely yours,
> Ivan



From ivan.gerasimov at oracle.com  Mon Jul 13 11:29:32 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 13 Jul 2015 14:29:32 +0300
Subject: RFR [S] 8131034: Cleanup in j.u.regex.Pattern.quote()
In-Reply-To: <42F6A248-0724-452A-99BC-1327F2F5A30C@oracle.com>
References: <55A29691.5020109@oracle.com>
	<42F6A248-0724-452A-99BC-1327F2F5A30C@oracle.com>
Message-ID: <55A3A11C.2030504@oracle.com>

Thank you Paul for your review!

On 13.07.2015 12:57, Paul Sandoz wrote:
> On Jul 12, 2015, at 6:32 PM, Ivan Gerasimov  wrote:
>
>> Hello!
>>
>> There's a minor issue in the current implementation of Pattern.quote() with possible numeric overflow when calculating initial capacity of StringBuilder.
>> With the fix, some slight optimizations were done and a few typos were fixed.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8131034
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8131034/00/webrev/
>>
> Looks ok.
>
>       /**
> -     * The pattern is converted to normalizedD form and then a pure group
> +     * The pattern is converted to normalized form and then a pure group
>        * is constructed to match canonical equivalences of the characters.
>        */
>
> The "D" in "normalizedD form" may well be short hand for "canonical decomposition" (Normalizer.Form.NFD) as in "normalized canonical decomposition form".
Hm.  Still looks like a typo to me.
A few lines below normalizedPattern has no extra D.
Another normalization form, NFKD, also ends with D, so normalizedD 
wouldn't uniquely identify NFD.
grep didn't find other occurrences of normalizedD abbreviation in JDK :)

Sincerely yours,
Ivan

> Paul.
>
>> Sincerely yours,
>> Ivan
>
>



From paul.sandoz at oracle.com  Mon Jul 13 12:10:42 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 13 Jul 2015 14:10:42 +0200
Subject: Speed optimization of Spliterators.spliteratorUnknownSize for
	parallel case
In-Reply-To: <187983222.20150711000136@gmail.com>
References: <187983222.20150711000136@gmail.com>
Message-ID: <58CD93AB-352F-4622-9507-4979470C9EFE@oracle.com>

Hi Tagir,

Thanks for looking at this. Judging by the results i am guessing your measurements were performed on a 4-core system.

My initial inclination for these scenarios is it is likely better for the developer to split the execution in two parts. The first part, low N and low Q, is to collect sequentially into an array or list. The second part (total size is known), low N and high Q, would then use that array/list as the stream source and operate in parallel.

That, in a sense, is almost what your spliterator does for n < initial batch size -:) but because the target threshold size is derived from the unknown root size (Long.MAX_VALUE) the sub-spliterators are not themselves further split, so the parallelism is better but still limited. It's tricky to adjust the target size dynamically, we could do it for the first split (e.g. unknown size -> two known size), but tracking further splits is harder and may not reliably perform (due to concurrent sub-splitting). I generally don't want to complicate the computation mechanism for poor splitting use-cases.

Your approach also degenerates when N is just over the current batch size.

I like what you have done, but i am hesitating. While we can marginally improve splitting from a sequential source use-cases they are nearly always gonna behave poorly so it feels like putting "lipstick on a pig" :-) Having said that the splitting logic is a little dumb returning null when all elements are consumed, for simplification purposes given that splitting is always poor and it does not matter so much if the size or a good estimate is known. For some additional implementation complexity there are marginal gains to be had, so it can seem like a reasonable thing to do. Just not sure it's enough.

I think larger gains may likely be had if it were possible to pass size estimates to certain stream source methods whose size is unknown e.g. passing in an estimate of the number of expected lines in BufferedReader.lines() to potentially achieve results closer to your base measurement case.

It does not make as much sense to include such an estimate argument for Files.lines for two reasons:

1) I recently improved Files.lines for common character sets where it is efficient to identify encoded line feeds (such as UTF-8); and

2) for other character sets we could derive an estimate from the file size (it could actually be the file size, which is the case for 1).

So i am inclined to do the following:

1) consider adding a size estimate argument for all stream factories that are of unknown size and where no reasonable estimate can be derived.

2) modify the spliterator factories in Spliterators  to accept an estimate e.g.:

public static  Spliterator spliteratorUnknownSize(Iterator iterator,
                                                        long sizeEstimate,
                                                        int characteristics)

3) Possibly improve the final split logic of implementations in Spliterators so that it benefits known size, estimated size [*], and maybe unknown size.

Paul.

[*] if the known or estimated size remaining is less than the next batch size, then split in half as the final splitting action. In this case there is no need for an array field since the iterator can be reused.


On Jul 10, 2015, at 8:01 PM, Tagir F. Valeev  wrote:

> Hello!
> 
> The problem of ineffective parallelization of spliteratorUnknownSize
> for low-N/high-Q tasks was already discussed in the thread "Exploiting
> concurrency with IteratorSpliterator of unknown size"
> [ http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011968.html ]
> It was proposed to modify some heuristics and/or add some parameters
> to control them.
> 
> I have a simpler idea which allows to run in parallel high-Q tasks for
> N <~ 3000 about twice faster without any API changes while having no
> visible impact for high-N or sequential cases. Here's the gist with
> proof-of-concept implementation (UnknownSizeSpliterator.java), JMH
> benchmark (IteratorTest.java) and benchmarking results (performed
> on Quad-Core i5-3340, Win7 64bit):
> https://gist.github.com/amaembo/781c64a3b4f48fdeb196
> 
> The problem which I noticed is the following. When trySplit is
> requested and JDK IteratorSpliterator fills the buffer, it may
> suddenly discover that the source iterator has no more elements. At
> this point the IteratorSpliterator splits in very uneven manner.
> Namely it dumps everything into the ArraySpliterator leaving no
> elements for itself. As it did not report the size previously, the
> pipeline engine assumes that both parts are roughly equal which
> result in very poor performance.
> 
> I merged both IteratorSpliterator and ArraySpliterator into single
> class UnknownSizeSpliterator. When it sees that input spliterator has
> no more elements, it converts itself into array-mode and splits right
> here to two equal parts, thus the first call of trySplit for N < 1024
> performs actual split.
> 
> Note that I did not change the heuristics at all, thus for big-N
> tasks the results should be the same. My implementation is a little
> bit simplified (no additional characteristics, no precondition
> checks, no primitive implementations), but I guess current version is
> ok for preliminary testing to decide whether it's good or bad.
> 
> This implementation might improve the performance of existing methods
> like BufferedReader.lines, Files.lines, Pattern.splitAsStream when
> using the parallel stream as well as user-defined iterator-based
> spliterators. Also it maybe useful for JDK-8072727 feature
> [ https://bugs.openjdk.java.net/browse/JDK-8072727 ].
> 
> What do you think?
> 
> With best regards,
> Tagir Valeev.
> 



From jandam at crcdata.cz  Mon Jul 13 12:20:50 2015
From: jandam at crcdata.cz (Janda Martin)
Date: Mon, 13 Jul 2015 14:20:50 +0200 (CEST)
Subject: What happend to: '(Review ID: 9055455) - RFE: Intristics for asin,
	acos'
Message-ID: <320586531.989.1436790050367.JavaMail.zimbra@crcdata.cz>

Hi all,

  I would like to know what happened to '(Review ID: 9055455) - RFE: Intristics for asin, acos'. I made report on http://bugreport.java.com/. Is it under evaluation or bugreport.java.com is only black hole as somebody complained?

  Thank you for info

  Martin


From felix.yang at oracle.com  Mon Jul 13 12:53:24 2015
From: felix.yang at oracle.com (FELIX YANG)
Date: Mon, 13 Jul 2015 20:53:24 +0800
Subject: [9] RFR 8129833: Need basic tests for rmic
In-Reply-To: <559F7DDA.1080109@oracle.com>
References: <559F7DDA.1080109@oracle.com>
Message-ID: <55A3B4C4.9060000@oracle.com>

Hi Daniel,
      please help to review the change for 8129833.

Issue:    https://bugs.openjdk.java.net/browse/JDK-8129833
Patch:    http://cr.openjdk.java.net/~fyuan/felix/8129833/

The patch add a new class to try rmic with. It covers a problem of locating the class java.awt.Panel in jigsaw build, see https://bugs.openjdk.java.net/browse/JDK-8129779.

thanks,
-Felix









From magnus.ihse.bursie at oracle.com  Mon Jul 13 14:01:00 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 13 Jul 2015 16:01:00 +0200
Subject: RFR - 8027634: Support @argfiles for java command-line tool
In-Reply-To: 
References: 
	
Message-ID: 

Build changes look fine. 

/Magnus

> 10 jul 2015 kl. 05:50 skrev Henry Jen :
> 
> Sigh, forgot the link to the webrev again.
> 
> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/webrev/
> 
> Cheers,
> Henry
> 
>> On Jul 9, 2015, at 8:48 PM, Henry Jen  wrote:
>> 
>> Hi,
>> 
>> Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer.
>> 
>> Some early comment is that we probably don?t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp ?c:\\foo bar\\lib;c:\\lib? instead of -cp c:\?foo bar?\lib;c:\lib.
>> 
>> I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well.
>> 
>> Anyhow, with the patch out, at least developer can build idk and have something to test with to see if this can fulfill their use cases.
>> 
>> Also, for tools other than java that use launcher, it?s possible to use -J at argfile to pass arguments. For example, if want to pass -J options to javac, it?s now possible to do so with javac -J at argfile, and put -J options in the argfile.
>> 
>> If the consensus is that such syntax compatibility is not important, we will go ahead remove the escaping support(except probably enable escape for quote itself) in quote, and maybe add support of quote within a token.
>> 
>> CCing build-dev for build changes, jdk9-dev for wider audience for tools.
>> 
>> Cheers,
>> Henry 
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8027634
>> [2] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#commandlineargfile
>> [3] http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/03e083639ee9/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java
> 


From xueming.shen at oracle.com  Mon Jul 13 16:58:20 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 13 Jul 2015 09:58:20 -0700
Subject: RFR [S] 8131034: Cleanup in j.u.regex.Pattern.quote()
In-Reply-To: <55A29691.5020109@oracle.com>
References: <55A29691.5020109@oracle.com>
Message-ID: <55A3EE2C.8000704@oracle.com>

looks good.

On 07/12/2015 09:32 AM, Ivan Gerasimov wrote:
> Hello!
>
> There's a minor issue in the current implementation of Pattern.quote() with possible numeric overflow when calculating initial capacity of StringBuilder.
> With the fix, some slight optimizations were done and a few typos were fixed.
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8131034
> WEBREV: http://cr.openjdk.java.net/~igerasim/8131034/00/webrev/
>
> Sincerely yours,
> Ivan



From xueming.shen at oracle.com  Mon Jul 13 17:02:50 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 13 Jul 2015 10:02:50 -0700
Subject: RFR [S] 6854417: TESTBUG: java/util/regex/RegExTest.java fails
	intermittently
In-Reply-To: <55A2D5BC.8050700@oracle.com>
References: <55A2D5BC.8050700@oracle.com>
Message-ID: <55A3EF3A.2080105@oracle.com>

On 07/12/2015 02:01 PM, Ivan Gerasimov wrote:
> Hello!
>
> RegExTest fails sometimes in checking Boyer-Moore search.
> This is because it was assumed that after insertion a pattern into a string at some position, we'll find it at the same position.
> That's not true if we insert 'aa' into 'xxaxx' at index 3, cause then we'll find 'aa' at index 2.
>
> The proposed fix is to exclude patterns that start and end with the same substring, because only those can cause this kind of problem.
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-6854417
> WEBREV: http://cr.openjdk.java.net/~igerasim/6854417/00/webrev/
>
> Sincerely yours,
> Ivan
>
looks good.


From martinrb at google.com  Mon Jul 13 18:26:39 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 13 Jul 2015 11:26:39 -0700
Subject: RFR [S] 8131034: Cleanup in j.u.regex.Pattern.quote()
In-Reply-To: <55A3A11C.2030504@oracle.com>
References: <55A29691.5020109@oracle.com>
	<42F6A248-0724-452A-99BC-1327F2F5A30C@oracle.com>
	<55A3A11C.2030504@oracle.com>
Message-ID: 

I agree that normalizedD looks like a typo (but it probably was not), but
"normalized" is too ambiguous (there are too many different kinds of
normalization) so a precise term like NFD should be used.  Maybe we should
add a reference to http://unicode.org/reports/tr15/

On Mon, Jul 13, 2015 at 4:29 AM, Ivan Gerasimov 
wrote:

> Thank you Paul for your review!
>
> On 13.07.2015 12:57, Paul Sandoz wrote:
>
>> On Jul 12, 2015, at 6:32 PM, Ivan Gerasimov 
>> wrote:
>>
>>  Hello!
>>>
>>> There's a minor issue in the current implementation of Pattern.quote()
>>> with possible numeric overflow when calculating initial capacity of
>>> StringBuilder.
>>> With the fix, some slight optimizations were done and a few typos were
>>> fixed.
>>>
>>> Would you please help review the fix?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8131034
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8131034/00/webrev/
>>>
>>>  Looks ok.
>>
>>       /**
>> -     * The pattern is converted to normalizedD form and then a pure group
>> +     * The pattern is converted to normalized form and then a pure group
>>        * is constructed to match canonical equivalences of the characters.
>>        */
>>
>> The "D" in "normalizedD form" may well be short hand for "canonical
>> decomposition" (Normalizer.Form.NFD) as in "normalized canonical
>> decomposition form".
>>
> Hm.  Still looks like a typo to me.
> A few lines below normalizedPattern has no extra D.
> Another normalization form, NFKD, also ends with D, so normalizedD
> wouldn't uniquely identify NFD.
> grep didn't find other occurrences of normalizedD abbreviation in JDK :)
>
> Sincerely yours,
> Ivan
>
>  Paul.
>>
>>  Sincerely yours,
>>> Ivan
>>>
>>
>>
>>
>


From Roger.Riggs at Oracle.com  Mon Jul 13 21:13:20 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 13 Jul 2015 17:13:20 -0400
Subject: RFR 9: JDK-8130877 : (process) java/lang/ProcessHandle/TreeTest test3
	failure - Destroyed process.isAlive
Message-ID: <55A429F0.7020900@Oracle.com>

Please review a testbug to correctly look for destroyed processes.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-isalive-8130877/

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

Thanks, Roger




From ivan.gerasimov at oracle.com  Mon Jul 13 23:51:26 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 14 Jul 2015 02:51:26 +0300
Subject: RFR [S] 8131034: Cleanup in j.u.regex.Pattern.quote()
In-Reply-To: 
References: <55A29691.5020109@oracle.com>	<42F6A248-0724-452A-99BC-1327F2F5A30C@oracle.com>	<55A3A11C.2030504@oracle.com>
	
Message-ID: <55A44EFE.4040802@oracle.com>

Thanks Martin!

On 13.07.2015 21:26, Martin Buchholz wrote:
> I agree that normalizedD looks like a typo (but it probably was not), 
> but "normalized" is too ambiguous (there are too many different kinds 
> of normalization) so a precise term like NFD should be used.  Maybe we 
> should add a reference to http://unicode.org/reports/tr15/
>
Okay, what if we have

      /**
-     * The pattern is converted to normalized form and then a pure group
-     * is constructed to match canonical equivalences of the characters.
+     * The pattern is converted to normalized form (NFD, canonical
+     * decomposition) and then a pure group is constructed to match
+     * canonical equivalences of the characters.
+     *
+     * @see java.text.Normalizer.Form.NFD
        */

We've already got a link to 
http://www.unicode.org/unicode/reports/tr15/tr15-23.html  from the doc 
for java.text.Normalizer.NFD:
http://docs.oracle.com/javase/8/docs/api/java/text/Normalizer.Form.html

I'd rather not duplicate the reference in that comment.

Sincerely yours,
Ivan


> On Mon, Jul 13, 2015 at 4:29 AM, Ivan Gerasimov 
> > wrote:
>
>     Thank you Paul for your review!
>
>     On 13.07.2015 12:57, Paul Sandoz wrote:
>
>         On Jul 12, 2015, at 6:32 PM, Ivan Gerasimov
>         >
>         wrote:
>
>             Hello!
>
>             There's a minor issue in the current implementation of
>             Pattern.quote() with possible numeric overflow when
>             calculating initial capacity of StringBuilder.
>             With the fix, some slight optimizations were done and a
>             few typos were fixed.
>
>             Would you please help review the fix?
>
>             BUGURL: https://bugs.openjdk.java.net/browse/JDK-8131034
>             WEBREV:
>             http://cr.openjdk.java.net/~igerasim/8131034/00/webrev/
>             
>
>         Looks ok.
>
>               /**
>         -     * The pattern is converted to normalizedD form and then
>         a pure group
>         +     * The pattern is converted to normalized form and then a
>         pure group
>                * is constructed to match canonical equivalences of the
>         characters.
>                */
>
>         The "D" in "normalizedD form" may well be short hand for
>         "canonical decomposition" (Normalizer.Form.NFD) as in
>         "normalized canonical decomposition form".
>
>     Hm.  Still looks like a typo to me.
>     A few lines below normalizedPattern has no extra D.
>     Another normalization form, NFKD, also ends with D, so normalizedD
>     wouldn't uniquely identify NFD.
>     grep didn't find other occurrences of normalizedD abbreviation in
>     JDK :)
>
>     Sincerely yours,
>     Ivan
>
>         Paul.
>
>             Sincerely yours,
>             Ivan
>
>
>
>
>



From martinrb at google.com  Mon Jul 13 23:59:25 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 13 Jul 2015 16:59:25 -0700
Subject: RFR [S] 8131034: Cleanup in j.u.regex.Pattern.quote()
In-Reply-To: <55A44EFE.4040802@oracle.com>
References: <55A29691.5020109@oracle.com>
	<42F6A248-0724-452A-99BC-1327F2F5A30C@oracle.com>
	<55A3A11C.2030504@oracle.com>
	
	<55A44EFE.4040802@oracle.com>
Message-ID: 

@see is mostly obsolete, now that we can use

{@linkplain java.text.Normalizer.Form.NFD NFD}

On Mon, Jul 13, 2015 at 4:51 PM, Ivan Gerasimov 
wrote:

>  Thanks Martin!
>
> On 13.07.2015 21:26, Martin Buchholz wrote:
>
> I agree that normalizedD looks like a typo (but it probably was not), but
> "normalized" is too ambiguous (there are too many different kinds of
> normalization) so a precise term like NFD should be used.  Maybe we should
> add a reference to http://unicode.org/reports/tr15/
>
>  Okay, what if we have
>
>      /**
> -     * The pattern is converted to normalized form and then a pure group
> -     * is constructed to match canonical equivalences of the characters.
> +     * The pattern is converted to normalized form (NFD, canonical
> +     * decomposition) and then a pure group is constructed to match
> +     * canonical equivalences of the characters.
> +     *
> +     * @see java.text.Normalizer.Form.NFD
>        */
>
> We've already got a link to
> http://www.unicode.org/unicode/reports/tr15/tr15-23.html  from the doc
> for java.text.Normalizer.NFD:
> http://docs.oracle.com/javase/8/docs/api/java/text/Normalizer.Form.html
>
> I'd rather not duplicate the reference in that comment.
>
> Sincerely yours,
> Ivan
>
>
>
>  On Mon, Jul 13, 2015 at 4:29 AM, Ivan Gerasimov <
> ivan.gerasimov at oracle.com> wrote:
>
>> Thank you Paul for your review!
>>
>> On 13.07.2015 12:57, Paul Sandoz wrote:
>>
>>> On Jul 12, 2015, at 6:32 PM, Ivan Gerasimov 
>>> wrote:
>>>
>>>  Hello!
>>>>
>>>> There's a minor issue in the current implementation of Pattern.quote()
>>>> with possible numeric overflow when calculating initial capacity of
>>>> StringBuilder.
>>>> With the fix, some slight optimizations were done and a few typos were
>>>> fixed.
>>>>
>>>> Would you please help review the fix?
>>>>
>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8131034
>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8131034/00/webrev/
>>>>
>>>>  Looks ok.
>>>
>>>       /**
>>> -     * The pattern is converted to normalizedD form and then a pure
>>> group
>>> +     * The pattern is converted to normalized form and then a pure group
>>>        * is constructed to match canonical equivalences of the
>>> characters.
>>>        */
>>>
>>> The "D" in "normalizedD form" may well be short hand for "canonical
>>> decomposition" (Normalizer.Form.NFD) as in "normalized canonical
>>> decomposition form".
>>>
>>  Hm.  Still looks like a typo to me.
>> A few lines below normalizedPattern has no extra D.
>> Another normalization form, NFKD, also ends with D, so normalizedD
>> wouldn't uniquely identify NFD.
>> grep didn't find other occurrences of normalizedD abbreviation in JDK :)
>>
>> Sincerely yours,
>> Ivan
>>
>>  Paul.
>>>
>>>  Sincerely yours,
>>>> Ivan
>>>>
>>>
>>>
>>>
>>
>
>


From amaembo at gmail.com  Tue Jul 14 02:43:17 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Tue, 14 Jul 2015 08:43:17 +0600
Subject: Speed optimization of Spliterators.spliteratorUnknownSize for
	parallel case
In-Reply-To: <58CD93AB-352F-4622-9507-4979470C9EFE@oracle.com>
References: <187983222.20150711000136@gmail.com>
	<58CD93AB-352F-4622-9507-4979470C9EFE@oracle.com>
Message-ID: <1266064787.20150714084317@gmail.com>

Hello!

Thank you for the detailed answer.

PS> Thanks for looking at this. Judging by the results i am guessing
PS> your measurements were performed on a 4-core system.

Yes, quad-core, I mentioned it before.

PS> My initial inclination for these scenarios is it is likely better
PS> for the developer to split the execution in two parts. The first
PS> part, low N and low Q, is to collect sequentially into an array or
PS> list. The second part (total size is known), low N and high Q,
PS> would then use that array/list as the stream source and operate in parallel.

Probably it would be fine to add such recommendations to the
corresponding methods javaDoc (for example, BufferedReader.lines).

PS> That, in a sense, is almost what your spliterator does for n <
PS> initial batch size -:) but because the target threshold size is
PS> derived from the unknown root size (Long.MAX_VALUE) the
PS> sub-spliterators are not themselves further split, so the
PS> parallelism is better but still limited. It's tricky to adjust the
PS> target size dynamically, we could do it for the first split (e.g.
PS> unknown size -> two known size), but tracking further splits is
PS> harder and may not reliably perform (due to concurrent
PS> sub-splitting). I generally don't want to complicate the
PS> computation mechanism for poor splitting use-cases.

I see. That actually was also the thing which I wanted to suggest.
Still even improving the first split would be great, I'd vote for it.
This way AbstractSpliterator user implementations may also benefit.
My optimization cannot be applied to AbstractSpliterator as we cannot
control the tryAdvance method.

PS> Your approach also degenerates when N is just over the current batch size.

Yes, it becomes bad, but my measurement show that it's still no worse
than current implementation:

Benchmark                (parallel)  (size)  Mode  Cnt    Score    Error  Units
IteratorTest.base             false    1028  avgt   30  659.308 ? 12.618  us/op
IteratorTest.base             false    1100  avgt   30  746.619 ? 21.260  us/op
IteratorTest.base              true    1028  avgt   30  194.800 ?  1.988  us/op
IteratorTest.base              true    1100  avgt   30  228.926 ?  2.923  us/op
IteratorTest.jdkSpliterator   false    1028  avgt   30  648.622 ?  3.857  us/op
IteratorTest.jdkSpliterator   false    1100  avgt   30  750.741 ? 10.279  us/op
IteratorTest.jdkSpliterator    true    1028  avgt   30  673.574 ?  6.469  us/op
IteratorTest.jdkSpliterator    true    1100  avgt   30  679.499 ?  4.310  us/op
IteratorTest.optimized        false    1028  avgt   30  643.209 ?  1.686  us/op
IteratorTest.optimized        false    1100  avgt   30  718.077 ?  8.123  us/op
IteratorTest.optimized         true    1028  avgt   30  674.447 ?  5.153  us/op
IteratorTest.optimized         true    1100  avgt   30  674.622 ?  4.252  us/op

PS> It does not make as much sense to include such an estimate
PS> argument for Files.lines for two reasons:

PS> 1) I recently improved Files.lines for common character sets
PS> where it is efficient to identify encoded line feeds (such as UTF-8); and

PS> 2) for other character sets we could derive an estimate from the
PS> file size (it could actually be the file size, which is the case for 1).

I see. FileChannelLinesSpliterator is a nice improvement. Have you
tested it on device files, named pipes or cases when the file size
is changed in-between by some other process? Also probably it should
be mentioned in BufferedReader.lines documentation, that using
Files.lines for file source is preferred.

PS> So i am inclined to do the following:

PS> 1) consider adding a size estimate argument for all stream
PS> factories that are of unknown size and where no reasonable estimate can be derived.

PS> 2) modify the spliterator factories in Spliterators  to accept an estimate e.g.:

PS> public static  Spliterator
PS> spliteratorUnknownSize(Iterator iterator,
PS>                                                         long sizeEstimate,
PS>                                                         int characteristics)

By the way currently it's possible to create an IteratorSpliterator
with estimated size:

Spliterators.spliterator(iterator, estimatedSize, Spliterator.CONCURRENT);

Of course it's a misuse of CONCURRENT flag, but it's not used
otherwisely by stream API, thus currently it has no unwanted
side-effects.

With best regards,
Tagir Valeev.

PS> 3) Possibly improve the final split logic of implementations in
PS> Spliterators so that it benefits known size, estimated size [*], and maybe unknown size.

PS> Paul.

PS> [*] if the known or estimated size remaining is less than the
PS> next batch size, then split in half as the final splitting action.
PS> In this case there is no need for an array field since the iterator can be reused.


PS> On Jul 10, 2015, at 8:01 PM, Tagir F. Valeev  wrote:

>> Hello!
>> 
>> The problem of ineffective parallelization of spliteratorUnknownSize
>> for low-N/high-Q tasks was already discussed in the thread "Exploiting
>> concurrency with IteratorSpliterator of unknown size"
>> [ http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011968.html ]
>> It was proposed to modify some heuristics and/or add some parameters
>> to control them.
>> 
>> I have a simpler idea which allows to run in parallel high-Q tasks for
>> N <~ 3000 about twice faster without any API changes while having no
>> visible impact for high-N or sequential cases. Here's the gist with
>> proof-of-concept implementation (UnknownSizeSpliterator.java), JMH
>> benchmark (IteratorTest.java) and benchmarking results (performed
>> on Quad-Core i5-3340, Win7 64bit):
>> https://gist.github.com/amaembo/781c64a3b4f48fdeb196
>> 
>> The problem which I noticed is the following. When trySplit is
>> requested and JDK IteratorSpliterator fills the buffer, it may
>> suddenly discover that the source iterator has no more elements. At
>> this point the IteratorSpliterator splits in very uneven manner.
>> Namely it dumps everything into the ArraySpliterator leaving no
>> elements for itself. As it did not report the size previously, the
>> pipeline engine assumes that both parts are roughly equal which
>> result in very poor performance.
>> 
>> I merged both IteratorSpliterator and ArraySpliterator into single
>> class UnknownSizeSpliterator. When it sees that input spliterator has
>> no more elements, it converts itself into array-mode and splits right
>> here to two equal parts, thus the first call of trySplit for N < 1024
>> performs actual split.
>> 
>> Note that I did not change the heuristics at all, thus for big-N
>> tasks the results should be the same. My implementation is a little
>> bit simplified (no additional characteristics, no precondition
>> checks, no primitive implementations), but I guess current version is
>> ok for preliminary testing to decide whether it's good or bad.
>> 
>> This implementation might improve the performance of existing methods
>> like BufferedReader.lines, Files.lines, Pattern.splitAsStream when
>> using the parallel stream as well as user-defined iterator-based
>> spliterators. Also it maybe useful for JDK-8072727 feature
>> [ https://bugs.openjdk.java.net/browse/JDK-8072727 ].
>> 
>> What do you think?
>> 
>> With best regards,
>> Tagir Valeev.
>>



From nelson.dcosta at oracle.com  Tue Jul 14 03:23:04 2015
From: nelson.dcosta at oracle.com (Nelson Dcosta)
Date: Tue, 14 Jul 2015 08:53:04 +0530
Subject: RFE: Intristics for asin, acos
Message-ID: <55A48098.9080409@oracle.com>

Hi Martin,

Thank you reaching out to us regarding this report. This report is under 
evaluation and we have included this in our bug reporting system as 
https://bugs.openjdk.java.net/browse/JDK-8131132 . Feel free to drop me 
a mail at any time if you would like an update on the report.

Regards,
Nelson

>
> -------- Forwarded Message --------
> Subject: 	What happend to: '(Review ID: 9055455) - RFE: Intristics for 
> asin, acos'
> Date: 	Mon, 13 Jul 2015 14:20:50 +0200 (CEST)
> From: 	Janda Martin 
> To: 	core-libs-dev 
>
>
>
> Hi all,
>
>    I would like to know what happened to '(Review ID: 9055455) - RFE: Intristics for asin, acos'. I made report onhttp://bugreport.java.com/. Is it under evaluation or bugreport.java.com is only black hole as somebody complained?
>
>    Thank you for info
>
>    Martin
>



From sundararajan.athijegannathan at oracle.com  Tue Jul 14 04:00:16 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 14 Jul 2015 09:30:16 +0530
Subject: Fwd: Re: [PATCH] javax,script.ScriptEngineFactory Typos
In-Reply-To: <559F5C40.1010504@yahoo.com>
References: <559F5C40.1010504@yahoo.com>
Message-ID: <55A48950.2000509@oracle.com>

Forwarding this contribution from Ahmed to core-libs-dev alias as the 
change is going to be in "jdk/java.scripting/javax.script" code.

PS. I'll send out webrev after build, test.

Thanks Ahmed,
-Sundar


-------- Forwarded Message --------
Subject: 	Re: [PATCH] javax,script.ScriptEngineFactory Typos
Date: 	Fri, 10 Jul 2015 07:46:40 +0200
From: 	Ahmed Ashour 
To: 	nashorn-dev at openjdk.java.net



Dear all,

Please find below a proposed patch based on jdk9/dev.

Thanks,
Ahmed


diff -r b526c2584b4b
src/java.scripting/share/classes/javax/script/ScriptEngineFactory.java
---
a/src/java.scripting/share/classes/javax/script/ScriptEngineFactory.java
Wed Jul 08 21:54:32 2015 -0400
+++
b/src/java.scripting/share/classes/javax/script/ScriptEngineFactory.java
Thu Jul 09 08:10:26 2015 +0200
@@ -160,7 +160,6 @@
       *      }
       *      ret += ")";
       *      return ret;
-     * }
       * } 

       *
       * @param obj The name representing the object whose method is to
be invoked. The
@@ -190,8 +189,6 @@
       *
       * @param toDisplay The String to be displayed by the returned
statement.
       * @return The string used to display the String in the syntax of
the scripting language.
-     *
-     *
       */
      public String getOutputStatement(String toDisplay);

@@ -208,14 +205,12 @@
       *          retval += statements[i] + ";\n";
       *      }
       *      return retval += "?>";
-     * }
       * }

       *
       *  @param statements The statements to be executed.  May be
return values of
       *  calls to the getMethodCallSyntax and
getOutputStatement methods.
       *  @return The Program
       */
-
      public String getProgram(String... statements);

      /**
@@ -225,5 +220,5 @@
       *
       * @return A new ScriptEngine instance.
       */
-    public  ScriptEngine getScriptEngine();
+    public ScriptEngine getScriptEngine();
  }





From amy.lu at oracle.com  Tue Jul 14 08:53:01 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 14 Jul 2015 16:53:01 +0800
Subject: JDK 9 RFR of JDK-8131140: Mark some tests from
	WhileOpStatefulTest.java and WhileOpTest.java as serialization hostile
Message-ID: <55A4CDED.6050406@oracle.com>

Stream tests WhileOpStatefulTest and WhileOpTest were newly introduced 
in JDK-8071597, some test cases should be marked as 
serialization-hostile (such tests will be ignored by lambda 
serialization testing framework).

Please review and sponsor this change:

bug: https://bugs.openjdk.java.net/browse/JDK-8131140
webrev: http://cr.openjdk.java.net/~amlu/8131140/webrev.00/

Thanks,
Amy


From sundararajan.athijegannathan at oracle.com  Tue Jul 14 10:38:55 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 14 Jul 2015 16:08:55 +0530
Subject: Fwd: Re: [PATCH] javax,script.ScriptEngineFactory Typos
In-Reply-To: <55A48950.2000509@oracle.com>
References: <559F5C40.1010504@yahoo.com> <55A48950.2000509@oracle.com>
Message-ID: <55A4E6BF.1080209@oracle.com>

Hi Ahmed,

Did you build the forest with that change or just "found" by code 
reading? Because {@code requires } to end it. So, those were not 'extra' 
'}' chars in doc comments.

Also, you can check javadoc output is correct. i.e., no extra "}". 
http://docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngineFactory.html#getProgram-java.lang.String...-

The other diffs being simple white space removals, I/we'll take care as 
part of another fix.

Thanks,
-Sundar

On Tuesday 14 July 2015 09:30 AM, A. Sundararajan wrote:
> Forwarding this contribution from Ahmed to core-libs-dev alias as the 
> change is going to be in "jdk/java.scripting/javax.script" code.
>
> PS. I'll send out webrev after build, test.
>
> Thanks Ahmed,
> -Sundar
>
>
> -------- Forwarded Message --------
> Subject:     Re: [PATCH] javax,script.ScriptEngineFactory Typos
> Date:     Fri, 10 Jul 2015 07:46:40 +0200
> From:     Ahmed Ashour 
> To:     nashorn-dev at openjdk.java.net
>
>
>
> Dear all,
>
> Please find below a proposed patch based on jdk9/dev.
>
> Thanks,
> Ahmed
>
>
> diff -r b526c2584b4b
> src/java.scripting/share/classes/javax/script/ScriptEngineFactory.java
> ---
> a/src/java.scripting/share/classes/javax/script/ScriptEngineFactory.java
> Wed Jul 08 21:54:32 2015 -0400
> +++
> b/src/java.scripting/share/classes/javax/script/ScriptEngineFactory.java
> Thu Jul 09 08:10:26 2015 +0200
> @@ -160,7 +160,6 @@
>       *      }
>       *      ret += ")";
>       *      return ret;
> -     * }
>       * } 

>       *
>       * @param obj The name representing the object whose method is to
> be invoked. The
> @@ -190,8 +189,6 @@
>       *
>       * @param toDisplay The String to be displayed by the returned
> statement.
>       * @return The string used to display the String in the syntax of
> the scripting language.
> -     *
> -     *
>       */
>      public String getOutputStatement(String toDisplay);
>
> @@ -208,14 +205,12 @@
>       *          retval += statements[i] + ";\n";
>       *      }
>       *      return retval += "?>";
> -     * }
>       * }

>       *
>       *  @param statements The statements to be executed.  May be
> return values of
>       *  calls to the getMethodCallSyntax and
> getOutputStatement methods.
>       *  @return The Program
>       */
> -
>      public String getProgram(String... statements);
>
>      /**
> @@ -225,5 +220,5 @@
>       *
>       * @return A new ScriptEngine instance.
>       */
> -    public  ScriptEngine getScriptEngine();
> +    public ScriptEngine getScriptEngine();
>  }
>
>
>



From asashour at yahoo.com  Tue Jul 14 10:47:37 2015
From: asashour at yahoo.com (Ahmed Ashour)
Date: Tue, 14 Jul 2015 10:47:37 +0000 (UTC)
Subject: [PATCH] javax,script.ScriptEngineFactory Typos
In-Reply-To: <55A4E6BF.1080209@oracle.com>
References: <55A4E6BF.1080209@oracle.com>
Message-ID: <1328462024.302708.1436870857458.JavaMail.yahoo@mail.yahoo.com>

Hi Sidharth,
You are totally right, sorry for that.
Actually, it seems to be Eclipse Mars bug, since it shows double "}". ?I will open a case there.
Thanks,Ahmed      From: A. Sundararajan 
 To: core-libs-dev at openjdk.java.net; Ahmed Ashour ; "nashorn-dev at openjdk.java.net"  
 Sent: Tuesday, July 14, 2015 12:38 PM
 Subject: Re: Fwd: Re: [PATCH] javax,script.ScriptEngineFactory Typos
   
Hi Ahmed,

Did you build the forest with that change or just "found" by code 
reading? Because {@code requires } to end it. So, those were not 'extra' 
'}' chars in doc comments.

Also, you can check javadoc output is correct. i.e., no extra "}". 
http://docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngineFactory.html#getProgram-java.lang.String...-

The other diffs being simple white space removals, I/we'll take care as 
part of another fix.

Thanks,
-Sundar



On Tuesday 14 July 2015 09:30 AM, A. Sundararajan wrote:
> Forwarding this contribution from Ahmed to core-libs-dev alias as the 
> change is going to be in "jdk/java.scripting/javax.script" code.
>
> PS. I'll send out webrev after build, test.
>
> Thanks Ahmed,
> -Sundar
>
>
> -------- Forwarded Message --------
> Subject:? ? Re: [PATCH] javax,script.ScriptEngineFactory Typos
> Date:? ? Fri, 10 Jul 2015 07:46:40 +0200
> From:? ? Ahmed Ashour 
> To:? ? nashorn-dev at openjdk.java.net
>
>
>
> Dear all,
>
> Please find below a proposed patch based on jdk9/dev.
>
> Thanks,
> Ahmed
>
>
> diff -r b526c2584b4b
> src/java.scripting/share/classes/javax/script/ScriptEngineFactory.java
> ---
> a/src/java.scripting/share/classes/javax/script/ScriptEngineFactory.java
> Wed Jul 08 21:54:32 2015 -0400
> +++
> b/src/java.scripting/share/classes/javax/script/ScriptEngineFactory.java
> Thu Jul 09 08:10:26 2015 +0200
> @@ -160,7 +160,6 @@
>? ? ? *? ? ? }
>? ? ? *? ? ? ret += ")";
>? ? ? *? ? ? return ret;
> -? ? * }
>? ? ? * } 

>? ? ? *
>? ? ? * @param obj The name representing the object whose method is to
> be invoked. The
> @@ -190,8 +189,6 @@
>? ? ? *
>? ? ? * @param toDisplay The String to be displayed by the returned
> statement.
>? ? ? * @return The string used to display the String in the syntax of
> the scripting language.
> -? ? *
> -? ? *
>? ? ? */
>? ? ? public String getOutputStatement(String toDisplay);
>
> @@ -208,14 +205,12 @@
>? ? ? *? ? ? ? ? retval += statements[i] + ";\n";
>? ? ? *? ? ? }
>? ? ? *? ? ? return retval += "?>";
> -? ? * }
>? ? ? * }

>? ? ? *
>? ? ? *? @param statements The statements to be executed.? May be
> return values of
>? ? ? *? calls to the getMethodCallSyntax and
> getOutputStatement methods.
>? ? ? *? @return The Program
>? ? ? */
> -
>? ? ? public String getProgram(String... statements);
>
>? ? ? /**
> @@ -225,5 +220,5 @@
>? ? ? *
>? ? ? * @return A new ScriptEngine instance.
>? ? ? */
> -? ? public? ScriptEngine getScriptEngine();
> +? ? public ScriptEngine getScriptEngine();
>? }
>
>
>



  

From kumar.x.srinivasan at oracle.com  Tue Jul 14 13:33:27 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 14 Jul 2015 06:33:27 -0700
Subject: RFR 8124977 cmdline encoding challenges on Windows
In-Reply-To: 
References: 
	
	<558C017A.2020708@oracle.com>
	
Message-ID: <55A50FA7.6020806@oracle.com>

Hi Kirk,

I took another pass over the changes.

IMHO, we need to make it easier for people to use this feature,
and eliminate these two, atleast externally.

"-Dwindows.UnicodeConsole=true",
"-Dfile.encoding.unicode=\"UTF-8\"",

Can we invent a new command line arg ? we can make it an -X
flag, by inspecting the args, we can set the two properties,
preferably one ? and also make the decision to use Wide
character translations etc.

1. java_md.c

a.> + ConvertWinArgsToCommonFormat(cmdLineUtf8, pargc, pargv); + 
JLI_MemFree(cmdLineUtf8); The free may not happen under error 
conditions, though we return immediately memory checking tools are 
likely to complain about memory leak.
b.>

+        if (stricmp(arg, "-Dwindows.UnicodeConsole=true") == 0) {
For consistency sake there there is a wrapper for this.
69 #define JLI_StrCaseCmp(p1, p2)          stricmp((p1), (p2))


As for the test you can delete the shell test and all you need is the
following, I have not tested it, but it should work.
#####################
UnicodeCmdVerifier.java
#####################


/*
* @test
* @bug 8124977
* @summary ensures that the command line argument, passed as Unicode,
* matches the desired value.
* @compile -XDignore.symbol.file UnicodeCmdVerifier.java
* @run main UnicodeCmdVerifier
*/
public class UnicodeCmdVerifier extends TestHelper {
public static void main(String[] args) {
if (!isWindows) { // test is applicable only on Windows
return;
}
if (args != null && args.length > 0) {
String desired = new String("\u042e\u043d\u0438\u043a\u043e\u0434");
if (args[1].equals(desired)) {
System.out.println("The argument matches the desired text: " + args[0]);
return;
} else {
throw new Error("The argument does not match the desired text: "
+ args[0] + " != " + desired);
}
return;
}
TestResult tr = doExec(javaCmd,
"-cp", TEST_CLASSES_DIR.getAbsolutePath(),
"-Dwindows.UnicodeConsole=true",
"-Dfile.encoding.unicode=\"UTF-8\"",
"UnicodeCmdVerifier", "testme", "??????");
if (!tr.isOK()) {
throw new Error("test failed with a non-zero exit");
}
}
}


Thanks
Kumar

On 7/8/2015 9:50 AM, Kirk Shoop wrote:
>> -----Original Message-----
>> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
>>
>> Hi Kirk,
>>
>> Thanks for proposing this change.
>>
>> If you notice all the posix calls are wrapped in JLI_* this  gives us the
>> ability to use "W" functions.  I almost got it done, several years ago,
>> but we upgraded to VS2010 and my work based on VS2003 keeled over,
>> meanwhile my focus was  "shifted" to something else.
>>
>> main.c: is really envisioned to be a stub  compiled by the tool launchers,
>> like java, javac, javah, jar etc. I prefer to see all the heavy logic in
>> this file moved to the platform specific file windows/java_md.*
>>
> Heavy logic is moved out of main.c file.
>
>> For the reason specified above we need to move fprintf or any naked posix
>> calls to JLI_* indirections.
>>
> Posix calls are wrapped in JLI_* functions.
>
>> I don't see any tests ? The tests must be written in java and placed in
>> jdk/test/tools/launcher, there is a helper framework TestHelper.java.
>>
> A new test for our changes is added.
>
>> There are other changes in nio, charsets etc, this will be reviewed by my
>> colleague specializing in that area (Sherman) cc'ed.
>>
>>
>> Thanks
>>
>> Kumar
> Thank you for the feedback!
>
> Valery prepared a new webrev which I placed here:
>    http://cr.openjdk.java.net/~kshoop/8124977/webrev.01
>
> Thanks,
> Kirk



From joe.darcy at oracle.com  Tue Jul 14 21:22:15 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 14 Jul 2015 14:22:15 -0700
Subject: RFR 9: JDK-8130877 : (process) java/lang/ProcessHandle/TreeTest
	test3 failure - Destroyed process.isAlive
In-Reply-To: <55A429F0.7020900@Oracle.com>
References: <55A429F0.7020900@Oracle.com>
Message-ID: <55A57D87.3010604@oracle.com>

Hi Roger,

Looks fine; thanks,

-Joe

On 7/13/2015 2:13 PM, Roger Riggs wrote:
> Please review a testbug to correctly look for destroyed processes.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-isalive-8130877/
>
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8130877
>
> Thanks, Roger
>
>



From Roger.Riggs at Oracle.com  Tue Jul 14 21:22:58 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 14 Jul 2015 17:22:58 -0400
Subject: RFR 9: JDK-8130877 : (process) java/lang/ProcessHandle/TreeTest
	test3 failure - Destroyed process.isAlive
In-Reply-To: <55A57D87.3010604@oracle.com>
References: <55A429F0.7020900@Oracle.com> <55A57D87.3010604@oracle.com>
Message-ID: <55A57DB2.30208@Oracle.com>

Thanks Joe,


On 7/14/2015 5:22 PM, Joseph D. Darcy wrote:
> Hi Roger,
>
> Looks fine; thanks,
>
> -Joe
>
> On 7/13/2015 2:13 PM, Roger Riggs wrote:
>> Please review a testbug to correctly look for destroyed processes.
>>
>> Webrev:
>>    http://cr.openjdk.java.net/~rriggs/webrev-isalive-8130877/
>>
>> Issue:
>>   https://bugs.openjdk.java.net/browse/JDK-8130877
>>
>> Thanks, Roger
>>
>>
>



From naoto.sato at oracle.com  Tue Jul 14 23:16:16 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 14 Jul 2015 16:16:16 -0700
Subject: RFR: 8032446: Support Unicode 7.0.0 in JDK 9
In-Reply-To: <55A374BD.6090807@oracle.com>
References: <55A374BD.6090807@oracle.com>
Message-ID: <55A59840.2050301@oracle.com>

Looks good to me.

Naoto

On 7/13/15 1:20 AM, Yuka Kamiya wrote:
> Hello,
> 
> Please review the fix for 8032446 to support Unicode 7 in JDK 9.
> 
> https://bugs.openjdk.java.net/browse/JDK-8032446
> http://cr.openjdk.java.net/~peytoia/8032446/webrev.00/
> 
> - Internal review for both open & closed parts has been completed.
> - Changes in sun.text.* packages are mostly porting from ICU4J. (Thank
> you very much, ICU4J project.)
> - Because Unicode 8 was released last month, this fix will be
> overwritten (partially) in near future.
> 
> Thanks,
> --
> Yuka
> 


From brian.burkhalter at oracle.com  Wed Jul 15 01:09:57 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 14 Jul 2015 18:09:57 -0700
Subject: [9]RFR 8130394: DatagramChannel tests need to be hardened to
	ignore stray datagrams
In-Reply-To: <559F74E9.2010500@oracle.com>
References: <559F74E9.2010500@oracle.com>
Message-ID: <0531AD85-C5FB-4FE7-BD2B-39AF720A0F36@oracle.com>

On Jul 10, 2015, at 12:31 AM, FELIX YANG  wrote:

> Hi all,
>     please help to review the change for 8130394.
> 
> Issue:     https://bugs.openjdk.java.net/browse/JDK-8130394
> Patch:    http://cr.openjdk.java.net/~fyuan/felix/8130394/
> 
> The patch updates tests to ignore stray datagrams, or at least print more information to ease troubleshooting.
> 
> thanks,
> -Felix

Hi Felix,

This change looks OK to me and I can sponsor it, but it will need a +1 from a JDK 9 Reviewer before it can be pushed.

Thanks,

Brian

From Roger.Riggs at Oracle.com  Wed Jul 15 01:21:28 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 14 Jul 2015 21:21:28 -0400
Subject: [9]RFR 8130394: DatagramChannel tests need to be hardened to
	ignore stray datagrams
In-Reply-To: <0531AD85-C5FB-4FE7-BD2B-39AF720A0F36@oracle.com>
References: <559F74E9.2010500@oracle.com>
	<0531AD85-C5FB-4FE7-BD2B-39AF720A0F36@oracle.com>
Message-ID: <55A5B598.1000100@Oracle.com>

+1,  looks fine.

On 7/14/15 9:09 PM, Brian Burkhalter wrote:
> On Jul 10, 2015, at 12:31 AM, FELIX YANG  wrote:
>
>> Hi all,
>>      please help to review the change for 8130394.
>>
>> Issue:     https://bugs.openjdk.java.net/browse/JDK-8130394
>> Patch:    http://cr.openjdk.java.net/~fyuan/felix/8130394/
>>
>> The patch updates tests to ignore stray datagrams, or at least print more information to ease troubleshooting.
>>
>> thanks,
>> -Felix
> Hi Felix,
>
> This change looks OK to me and I can sponsor it, but it will need a +1 from a JDK 9 Reviewer before it can be pushed.
>
> Thanks,
>
> Brian



From masayoshi.okutsu at oracle.com  Wed Jul 15 03:09:57 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 15 Jul 2015 12:09:57 +0900
Subject:  RFR: 8032446: Support Unicode 7.0.0 in JDK 9
In-Reply-To: <55A59840.2050301@oracle.com>
References: <55A374BD.6090807@oracle.com> <55A59840.2050301@oracle.com>
Message-ID: <55A5CF05.1030909@oracle.com>

Looks OK to me too.

Masayoshi

On 7/15/2015 8:16 AM, Naoto Sato wrote:
> Looks good to me.
>
> Naoto
>
> On 7/13/15 1:20 AM, Yuka Kamiya wrote:
>> Hello,
>>
>> Please review the fix for 8032446 to support Unicode 7 in JDK 9.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8032446
>> http://cr.openjdk.java.net/~peytoia/8032446/webrev.00/
>>
>> - Internal review for both open & closed parts has been completed.
>> - Changes in sun.text.* packages are mostly porting from ICU4J. (Thank
>> you very much, ICU4J project.)
>> - Because Unicode 8 was released last month, this fix will be
>> overwritten (partially) in near future.
>>
>> Thanks,
>> --
>> Yuka
>>



From michael.haupt at oracle.com  Wed Jul 15 08:23:41 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Wed, 15 Jul 2015 10:23:41 +0200
Subject: RFR(S): 8062543: Replace uses of MethodHandleImpl.castReference with
	Class.cast
Message-ID: <4C4D5F89-E8E0-4104-9C55-9643B9732349@oracle.com>

Dear all,

please review and sponsor this change.
RFE: https://bugs.openjdk.java.net/browse/JDK-8062543
Webrev: http://cr.openjdk.java.net/~mhaupt/8062543/webrev.00/

The change removes the no longer needed MethodHandleImpl.castReference method. Its uses are replaced with Class.cast.

Tested with:
* jtreg (java.lang.invoke, java.util.stream)
* JPRT (hotspot and jdk_lang test sets)
* UTE (vm.quick-pcl.testlist, vm.defmeth.testlist)

Thanks,

Michael

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 	Oracle is committed to developing practices and products that help protect the environment



From vladimir.x.ivanov at oracle.com  Wed Jul 15 09:00:47 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 15 Jul 2015 12:00:47 +0300
Subject: RFR(S): 8062543: Replace uses of MethodHandleImpl.castReference
	with Class.cast
In-Reply-To: <4C4D5F89-E8E0-4104-9C55-9643B9732349@oracle.com>
References: <4C4D5F89-E8E0-4104-9C55-9643B9732349@oracle.com>
Message-ID: <55A6213F.4020905@oracle.com>

Looks good.

Have you verified there's no performance regression? I'd suggest to run 
some Octane benchmarks.

Best regards,
Vladimir Ivanov

On 7/15/15 11:23 AM, Michael Haupt wrote:
> Dear all,
>
> please review and sponsor this change.
> RFE: https://bugs.openjdk.java.net/browse/JDK-8062543
> Webrev: http://cr.openjdk.java.net/~mhaupt/8062543/webrev.00/
>
> The change removes the no longer needed MethodHandleImpl.castReference method. Its uses are replaced with Class.cast.
>
> Tested with:
> * jtreg (java.lang.invoke, java.util.stream)
> * JPRT (hotspot and jdk_lang test sets)
> * UTE (vm.quick-pcl.testlist, vm.defmeth.testlist)
>
> Thanks,
>
> Michael
>


From paul.sandoz at oracle.com  Wed Jul 15 10:51:46 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 15 Jul 2015 12:51:46 +0200
Subject: RFR(S): 8062543: Replace uses of MethodHandleImpl.castReference
	with Class.cast
In-Reply-To: <4C4D5F89-E8E0-4104-9C55-9643B9732349@oracle.com>
References: <4C4D5F89-E8E0-4104-9C55-9643B9732349@oracle.com>
Message-ID: 


On Jul 15, 2015, at 10:23 AM, Michael Haupt  wrote:

> Dear all,
> 
> please review and sponsor this change.
> RFE: https://bugs.openjdk.java.net/browse/JDK-8062543
> Webrev: http://cr.openjdk.java.net/~mhaupt/8062543/webrev.00/
> 
> The change removes the no longer needed MethodHandleImpl.castReference method. Its uses are replaced with Class.cast.
> 

Look good. I agree with Vladimir on checking for performance regressions (i suspect/hope! there will not be any).

Paul.

> Tested with:
> * jtreg (java.lang.invoke, java.util.stream)
> * JPRT (hotspot and jdk_lang test sets)
> * UTE (vm.quick-pcl.testlist, vm.defmeth.testlist)
> 
> Thanks,
> 
> Michael
> 
> --
> 
> 
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> Oracle Java Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
> 	Oracle is committed to developing practices and products that help protect the environment
> 



From paul.sandoz at oracle.com  Wed Jul 15 10:55:27 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 15 Jul 2015 12:55:27 +0200
Subject: JDK 9 RFR of JDK-8131140: Mark some tests from
	WhileOpStatefulTest.java and WhileOpTest.java as serialization hostile
In-Reply-To: <55A4CDED.6050406@oracle.com>
References: <55A4CDED.6050406@oracle.com>
Message-ID: 


On Jul 14, 2015, at 10:53 AM, Amy Lu  wrote:

> Stream tests WhileOpStatefulTest and WhileOpTest were newly introduced in JDK-8071597, some test cases should be marked as serialization-hostile (such tests will be ignored by lambda serialization testing framework).
> 

I did it again!


> Please review and sponsor this change:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8131140
> webrev: http://cr.openjdk.java.net/~amlu/8131140/webrev.00/
> 

Looks good.

Want me to commit for you?

Paul.

> Thanks,
> Amy



From daniel.fuchs at oracle.com  Wed Jul 15 11:01:20 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 15 Jul 2015 13:01:20 +0200
Subject: [9] RFR 8129833: Need basic tests for rmic
In-Reply-To: <55A3B4C4.9060000@oracle.com>
References: <559F7DDA.1080109@oracle.com> <55A3B4C4.9060000@oracle.com>
Message-ID: <55A63D80.4050307@oracle.com>

On 13/07/15 14:53, FELIX YANG wrote:
> Hi Daniel,
>       please help to review the change for 8129833.
>
> Issue:    https://bugs.openjdk.java.net/browse/JDK-8129833
> Patch:    http://cr.openjdk.java.net/~fyuan/felix/8129833/
>
> The patch add a new class to try rmic with. It covers a problem of
> locating the class java.awt.Panel in jigsaw build, see
> https://bugs.openjdk.java.net/browse/JDK-8129779.

Hi Felix, it looks good to me.

Would you like me to sponsor it?

best regards,

-- daniel

>
> thanks,
> -Felix
>
>
>
>
>
>
>



From michael.haupt at oracle.com  Wed Jul 15 11:58:48 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Wed, 15 Jul 2015 13:58:48 +0200
Subject: RFR(S): 8062543: Replace uses of MethodHandleImpl.castReference
	with Class.cast
In-Reply-To: 
References: <4C4D5F89-E8E0-4104-9C55-9643B9732349@oracle.com>
	
Message-ID: <37BF5CDF-7F25-4628-833C-87D64D9C5E10@oracle.com>

Hi Paul, Vladimir,

thanks - I'll be back with perf numbers ASAP.

Best,

Michael

> Am 15.07.2015 um 12:51 schrieb Paul Sandoz :
> 
> 
> On Jul 15, 2015, at 10:23 AM, Michael Haupt  wrote:
> 
>> Dear all,
>> 
>> please review and sponsor this change.
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8062543
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8062543/webrev.00/
>> 
>> The change removes the no longer needed MethodHandleImpl.castReference method. Its uses are replaced with Class.cast.
>> 
> 
> Look good. I agree with Vladimir on checking for performance regressions (i suspect/hope! there will not be any).
> 
> Paul.
> 
>> Tested with:
>> * jtreg (java.lang.invoke, java.util.stream)
>> * JPRT (hotspot and jdk_lang test sets)
>> * UTE (vm.quick-pcl.testlist, vm.defmeth.testlist)
>> 
>> Thanks,
>> 
>> Michael


-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 	Oracle is committed to developing practices and products that help protect the environment



From paul.sandoz at oracle.com  Wed Jul 15 12:20:45 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 15 Jul 2015 14:20:45 +0200
Subject: Speed optimization of Spliterators.spliteratorUnknownSize for
	parallel case
In-Reply-To: <1266064787.20150714084317@gmail.com>
References: <187983222.20150711000136@gmail.com>
	<58CD93AB-352F-4622-9507-4979470C9EFE@oracle.com>
	<1266064787.20150714084317@gmail.com>
Message-ID: <2B91FF58-5620-4E30-8416-BFCFC9C8BBEB@oracle.com>

Hi Tagir,

On Jul 14, 2015, at 4:43 AM, Tagir F. Valeev  wrote:

> Hello!
> 
> Thank you for the detailed answer.
> 
> PS> Thanks for looking at this. Judging by the results i am guessing
> PS> your measurements were performed on a 4-core system.
> 
> Yes, quad-core, I mentioned it before.
> 
> PS> My initial inclination for these scenarios is it is likely better
> PS> for the developer to split the execution in two parts. The first
> PS> part, low N and low Q, is to collect sequentially into an array or
> PS> list. The second part (total size is known), low N and high Q,
> PS> would then use that array/list as the stream source and operate in parallel.
> 
> Probably it would be fine to add such recommendations to the
> corresponding methods javaDoc (for example, BufferedReader.lines).
> 

I think it is more suitable for:

  http://gee.cs.oswego.edu/dl/html/StreamParallelGuidance.html


> PS> That, in a sense, is almost what your spliterator does for n <
> PS> initial batch size -:) but because the target threshold size is
> PS> derived from the unknown root size (Long.MAX_VALUE) the
> PS> sub-spliterators are not themselves further split, so the
> PS> parallelism is better but still limited. It's tricky to adjust the
> PS> target size dynamically, we could do it for the first split (e.g.
> PS> unknown size -> two known size), but tracking further splits is
> PS> harder and may not reliably perform (due to concurrent
> PS> sub-splitting). I generally don't want to complicate the
> PS> computation mechanism for poor splitting use-cases.
> 
> I see. That actually was also the thing which I wanted to suggest.
> Still even improving the first split would be great, I'd vote for it.

I am still hesitating. It's not general enough (optimize for poor splitting under fragile scenarios for N elements under batch size) (FWIW the general computation already alternates left/right forking to avoid such spliterators causing out of memory issues where the computation runs away creating tasks).

I also pondered exposing the batch size as an argument, but i don't think developers will generally know what to do with it, where as i suspect a size estimate is much easier to understand (even if guarded language in terms of proportions e.g last least N).

And of course this does not stop us internally using an alternative spliterator implementation for BufferedReader.lines such as suggested by Marko, which i think could be improved if a size estimate is given, as this could also influence the batch size and common difference.


> This way AbstractSpliterator user implementations may also benefit.
> My optimization cannot be applied to AbstractSpliterator as we cannot
> control the tryAdvance method.
> 
> PS> Your approach also degenerates when N is just over the current batch size.
> 
> Yes, it becomes bad, but my measurement show that it's still no worse
> than current implementation:
> 

Yes, no worse.


> Benchmark                (parallel)  (size)  Mode  Cnt    Score    Error  Units
> IteratorTest.base             false    1028  avgt   30  659.308 ? 12.618  us/op
> IteratorTest.base             false    1100  avgt   30  746.619 ? 21.260  us/op
> IteratorTest.base              true    1028  avgt   30  194.800 ?  1.988  us/op
> IteratorTest.base              true    1100  avgt   30  228.926 ?  2.923  us/op
> IteratorTest.jdkSpliterator   false    1028  avgt   30  648.622 ?  3.857  us/op
> IteratorTest.jdkSpliterator   false    1100  avgt   30  750.741 ? 10.279  us/op
> IteratorTest.jdkSpliterator    true    1028  avgt   30  673.574 ?  6.469  us/op
> IteratorTest.jdkSpliterator    true    1100  avgt   30  679.499 ?  4.310  us/op
> IteratorTest.optimized        false    1028  avgt   30  643.209 ?  1.686  us/op
> IteratorTest.optimized        false    1100  avgt   30  718.077 ?  8.123  us/op
> IteratorTest.optimized         true    1028  avgt   30  674.447 ?  5.153  us/op
> IteratorTest.optimized         true    1100  avgt   30  674.622 ?  4.252  us/op
> 
> PS> It does not make as much sense to include such an estimate
> PS> argument for Files.lines for two reasons:
> 
> PS> 1) I recently improved Files.lines for common character sets
> PS> where it is efficient to identify encoded line feeds (such as UTF-8); and
> 
> PS> 2) for other character sets we could derive an estimate from the
> PS> file size (it could actually be the file size, which is the case for 1).
> 
> I see. FileChannelLinesSpliterator is a nice improvement. Have you
> tested it on device files, named pipes or cases when the file size
> is changed in-between by some other process?

No. There is a general clause saying "all bets are off" if the file contents are modified during stream execution. The size is currently snapshot on the Files.lines call. If the file size increases in the interim i suspect it will still work, if it reduces then i would expect an I/O exception.


> Also probably it should
> be mentioned in BufferedReader.lines documentation, that using
> Files.lines for file source is preferred.
> 

Good point a "@see Files.lines ..." would be appropriate.


> PS> So i am inclined to do the following:
> 
> PS> 1) consider adding a size estimate argument for all stream
> PS> factories that are of unknown size and where no reasonable estimate can be derived.
> 
> PS> 2) modify the spliterator factories in Spliterators  to accept an estimate e.g.:
> 
> PS> public static  Spliterator
> PS> spliteratorUnknownSize(Iterator iterator,
> PS>                                                         long sizeEstimate,
> PS>                                                         int characteristics)
> 
> By the way currently it's possible to create an IteratorSpliterator
> with estimated size:
> 
> Spliterators.spliterator(iterator, estimatedSize, Spliterator.CONCURRENT);
> 
> Of course it's a misuse of CONCURRENT flag, but it's not used
> otherwisely by stream API, thus currently it has no unwanted
> side-effects.
> 

Very sneaky :-) but not something we cannot encourage.

Paul.


From paul.sandoz at oracle.com  Wed Jul 15 12:23:57 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 15 Jul 2015 14:23:57 +0200
Subject: Speed optimization of Spliterators.spliteratorUnknownSize for
	parallel case
In-Reply-To: <2B91FF58-5620-4E30-8416-BFCFC9C8BBEB@oracle.com>
References: <187983222.20150711000136@gmail.com>
	<58CD93AB-352F-4622-9507-4979470C9EFE@oracle.com>
	<1266064787.20150714084317@gmail.com>
	<2B91FF58-5620-4E30-8416-BFCFC9C8BBEB@oracle.com>
Message-ID: <6FB07841-CA7E-4ECC-925D-97783304D8AE@oracle.com>

On Jul 15, 2015, at 2:20 PM, Paul Sandoz  wrote:
>> By the way currently it's possible to create an IteratorSpliterator
>> with estimated size:
>> 
>> Spliterators.spliterator(iterator, estimatedSize, Spliterator.CONCURRENT);
>> 
>> Of course it's a misuse of CONCURRENT flag, but it's not used
>> otherwisely by stream API, thus currently it has no unwanted
>> side-effects.
>> 
> 
> Very sneaky :-) but not something we cannot encourage.
> 

I meant to say:

  ... but something we cannot encourage.

Paul.


From felix.yang at oracle.com  Wed Jul 15 13:59:28 2015
From: felix.yang at oracle.com (FELIX YANG)
Date: Wed, 15 Jul 2015 21:59:28 +0800
Subject: [9] RFR 8129833: Need basic tests for rmic
In-Reply-To: <55A63D80.4050307@oracle.com>
References: <559F7DDA.1080109@oracle.com> <55A3B4C4.9060000@oracle.com>
	<55A63D80.4050307@oracle.com>
Message-ID: <55A66740.7030000@oracle.com>


On 7/15/2015 7:01 PM, Daniel Fuchs wrote:
> On 13/07/15 14:53, FELIX YANG wrote:
>> Hi Daniel,
>>       please help to review the change for 8129833.
>>
>> Issue:    https://bugs.openjdk.java.net/browse/JDK-8129833
>> Patch:    http://cr.openjdk.java.net/~fyuan/felix/8129833/
>>
>> The patch add a new class to try rmic with. It covers a problem of
>> locating the class java.awt.Panel in jigsaw build, see
>> https://bugs.openjdk.java.net/browse/JDK-8129779.
>
> Hi Felix, it looks good to me.
>
> Would you like me to sponsor it?
Daniel,
      yes, please!

Thank you,
-Felix
>
> best regards,
>
> -- daniel
>
>>
>> thanks,
>> -Felix
>>
>>
>>
>>
>>
>>
>>
>



From mandy.chung at oracle.com  Wed Jul 15 14:51:52 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 15 Jul 2015 22:51:52 +0800
Subject: RFR - 8027634: Support @argfiles for java command-line tool
In-Reply-To: 
References: 
Message-ID: 


> On Jul 10, 2015, at 11:48 AM, Henry Jen  wrote:
> 
> Hi,
> 
> Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer.
> 
> Some early comment is that we probably don?t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp ?c:\\foo bar\\lib;c:\\lib? instead of -cp c:\?foo bar?\lib;c:\lib.
> 
> I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well.

I have a slight preference to maintain consistent syntax as javac @argfile support in terms of the quotation.  A user could use the same path specified in -cp for both javac @argfile an java @argfile use.

I skimmed on the webrev and looks okay to me.  I?ll leave it for Kumar to do detailed review.  One minor comment:

args.c
   Are you planning to remove the test within #ifdef DEBUG_ARGFILE block?

thanks
Mandy



From xueming.shen at oracle.com  Wed Jul 15 19:10:39 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 15 Jul 2015 12:10:39 -0700
Subject: RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with
	"java.lang.RuntimeException:
	setTime should make getLastModifiedTime return the specified instant:
	3078282244456 got: 3078282244455"
Message-ID: <55A6B02F.9060400@oracle.com>

Hi,

Please help review the change for JDK-8130914.

issue: https://bugs.openjdk.java.net/browse/JDK-8130914
webrev: http://cr.openjdk.java.net/~sherman/8130914/

This is a "regression" triggered by
https://bugs.openjdk.java.net/browse/JDK-8130914
http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/

In which the change is to utilize a high 32-bit of the time value to store
< 2000 ms time piece. It appears the offending timestamp (year 2067...)
triggers the 32-bit "overflow" when converting java time to a 32-bit dos
time.

Thanks,
-Sherman


From claes.redestad at oracle.com  Wed Jul 15 22:33:17 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 16 Jul 2015 00:33:17 +0200
Subject: RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with
	"java.lang.RuntimeException: setTime should make
	getLastModifiedTime return the specified instant: 3078282244456
	got: 3078282244455"
In-Reply-To: <55A6B02F.9060400@oracle.com>
References: <55A6B02F.9060400@oracle.com>
Message-ID: <8858E3BD-F063-40DA-831C-540D3FD92C1A@oracle.com>

Code change looks OK to me, but perhaps there should be an explicit long conversion somewhere around the getYear() part ('d.getYear() - 1980 << 25L') of the expressions to deal properly with even larger values?

Are there added tests missing from the updated TestExtraTime? I guess this is an intermittent issue, but it looks odd to update the test without adding some explicit test that provoke this issue.

/Claes 

Xueming Shen  skrev: (15 juli 2015 21:10:39 CEST)
>Hi,
>
>Please help review the change for JDK-8130914.
>
>issue: https://bugs.openjdk.java.net/browse/JDK-8130914
>webrev: http://cr.openjdk.java.net/~sherman/8130914/
>
>This is a "regression" triggered by
>https://bugs.openjdk.java.net/browse/JDK-8130914
>http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
>
>In which the change is to utilize a high 32-bit of the time value to
>store
>< 2000 ms time piece. It appears the offending timestamp (year 2067...)
>triggers the 32-bit "overflow" when converting java time to a 32-bit
>dos
>time.
>
>Thanks,
>-Sherman


From amy.lu at oracle.com  Thu Jul 16 01:36:34 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 16 Jul 2015 09:36:34 +0800
Subject: JDK 9 RFR of JDK-8131140: Mark some tests from
	WhileOpStatefulTest.java and WhileOpTest.java as serialization hostile
In-Reply-To: 
References: <55A4CDED.6050406@oracle.com>
	
Message-ID: <55A70AA2.3080503@oracle.com>

Thank you Paul for review this.
Yes, please help to push.

Thanks,
Amy

On 7/15/15 6:55 PM, Paul Sandoz wrote:
> On Jul 14, 2015, at 10:53 AM, Amy Lu  wrote:
>
>> Stream tests WhileOpStatefulTest and WhileOpTest were newly introduced in JDK-8071597, some test cases should be marked as serialization-hostile (such tests will be ignored by lambda serialization testing framework).
>>
> I did it again!
>
>
>> Please review and sponsor this change:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8131140
>> webrev: http://cr.openjdk.java.net/~amlu/8131140/webrev.00/
>>
> Looks good.
>
> Want me to commit for you?
>
> Paul.
>
>> Thanks,
>> Amy



From daniel.fuchs at oracle.com  Thu Jul 16 10:00:56 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 Jul 2015 12:00:56 +0200
Subject: RFR 8131052 Documentation of AbstractSpliterator refers to forEach
	rather than forEachRemaining
In-Reply-To: <70C9F5D9-094D-4CDE-B348-E0B364C2747F@oracle.com>
References: 
	<70C9F5D9-094D-4CDE-B348-E0B364C2747F@oracle.com>
Message-ID: <55A780D8.1090909@oracle.com>

On 13/07/15 11:19, Paul Sandoz wrote:
> Hi
>
> Stefan, thanks.
>
> See below for a patch to the documentation of all abstract spliterators.

Looks good to me Paul.

best regards,

-- daniel

>
> Paul.
>
> diff -r a3175de2e354 src/java.base/share/classes/java/util/Spliterators.java
> --- a/src/java.base/share/classes/java/util/Spliterators.java	Tue Jun 09 07:10:03 2015 +0100
> +++ b/src/java.base/share/classes/java/util/Spliterators.java	Mon Jul 13 11:16:24 2015 +0200
> @@ -1235,8 +1235,8 @@
>        * 
An extending class need only
>        * implement {@link #tryAdvance(java.util.function.Consumer) tryAdvance}.
>        * The extending class should override
> -     * {@link #forEachRemaining(java.util.function.Consumer) forEach} if it can
> -     * provide a more performant implementation.
> +     * {@link #forEachRemaining(java.util.function.Consumer) forEachRemaining}
> +     * if it can provide a more performant implementation.
>        *
>        * @apiNote
>        * This class is a useful aid for creating a spliterator when it is not
> @@ -1358,8 +1358,8 @@
>        * 
To implement a spliterator an extending class need only
>        * implement {@link #tryAdvance(java.util.function.IntConsumer)}
>        * tryAdvance}.  The extending class should override
> -     * {@link #forEachRemaining(java.util.function.IntConsumer)} forEach} if it
> -     * can provide a more performant implementation.
> +     * {@link #forEachRemaining(java.util.function.IntConsumer)} forEachRemaining}
> +     * if it can provide a more performant implementation.
>        *
>        * @apiNote
>        * This class is a useful aid for creating a spliterator when it is not
> @@ -1468,8 +1468,8 @@
>        * 
To implement a spliterator an extending class need only
>        * implement {@link #tryAdvance(java.util.function.LongConsumer)}
>        * tryAdvance}.  The extending class should override
> -     * {@link #forEachRemaining(java.util.function.LongConsumer)} forEach} if it
> -     * can provide a more performant implementation.
> +     * {@link #forEachRemaining(java.util.function.LongConsumer)} forEachRemaining}
> +     * if it can provide a more performant implementation.
>        *
>        * @apiNote
>        * This class is a useful aid for creating a spliterator when it is not
> @@ -1578,8 +1578,8 @@
>        * 
To implement a spliterator an extending class need only
>        * implement {@link #tryAdvance(java.util.function.DoubleConsumer)}
>        * tryAdvance}.  The extending class should override
> -     * {@link #forEachRemaining(java.util.function.DoubleConsumer)} forEach} if
> -     * it can provide a more performant implementation.
> +     * {@link #forEachRemaining(java.util.function.DoubleConsumer)} forEachRemaining}
> +     * if it can provide a more performant implementation.
>        *
>        * @apiNote
>        * This class is a useful aid for creating a spliterator when it is not
>
> On Jul 12, 2015, at 11:56 AM, Stefan Zobel  wrote:
>
>> Hi all,
>>
>>
>> I just noticed some typos in the
>> Spliterators.Abstract(Double/Int/Long)Spliterator Javadoc:
>>
>> a) The forEachRemaining link label is "forEach" instead of
>> "forEachRemaining" in all AbstractSpliterators.
>>
>> b) The primitive AbstractSpliterators Javadoc has a surplus "}" just before
>> the tryAdvance and forEach link labels.
>>
>>
>>
>> Stefan
>



From daniel.fuchs at oracle.com  Thu Jul 16 10:07:05 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 Jul 2015 12:07:05 +0200
Subject: RFR 8131052 Documentation of AbstractSpliterator refers to forEach
	rather than forEachRemaining
In-Reply-To: <55A780D8.1090909@oracle.com>
References: 	<70C9F5D9-094D-4CDE-B348-E0B364C2747F@oracle.com>
	<55A780D8.1090909@oracle.com>
Message-ID: <55A78249.4050605@oracle.com>

On 16/07/15 12:00, Daniel Fuchs wrote:
> On 13/07/15 11:19, Paul Sandoz wrote:
>> Hi
>>
>> Stefan, thanks.
>>
>> See below for a patch to the documentation of all abstract spliterators.
>
> Looks good to me Paul.

Sorry - re reading my mail I see that you have an extreneous '}'
at the three last places - just after the closing ')':


 >> +     * {@link #forEachRemaining(java.util.function.IntConsumer)}
 >> forEachRemaining}
 >> +     * if it can provide a more performant implementation.


 >> +     * {@link #forEachRemaining(java.util.function.LongConsumer)}
 >> forEachRemaining}
 >> +     * if it can provide a more performant implementation.


 >> +     * {@link #forEachRemaining(java.util.function.DoubleConsumer)}
 >> forEachRemaining}
 >> +     * if it can provide a more performant implementation.

-- daniel

>
> best regards,
>
> -- daniel
>
>>
>> Paul.
>>
>> diff -r a3175de2e354
>> src/java.base/share/classes/java/util/Spliterators.java
>> --- a/src/java.base/share/classes/java/util/Spliterators.java    Tue
>> Jun 09 07:10:03 2015 +0100
>> +++ b/src/java.base/share/classes/java/util/Spliterators.java    Mon
>> Jul 13 11:16:24 2015 +0200
>> @@ -1235,8 +1235,8 @@
>>        * 
An extending class need only
>>        * implement {@link #tryAdvance(java.util.function.Consumer)
>> tryAdvance}.
>>        * The extending class should override
>> -     * {@link #forEachRemaining(java.util.function.Consumer) forEach}
>> if it can
>> -     * provide a more performant implementation.
>> +     * {@link #forEachRemaining(java.util.function.Consumer)
>> forEachRemaining}
>> +     * if it can provide a more performant implementation.
>>        *
>>        * @apiNote
>>        * This class is a useful aid for creating a spliterator when it
>> is not
>> @@ -1358,8 +1358,8 @@
>>        * 
To implement a spliterator an extending class need only
>>        * implement {@link #tryAdvance(java.util.function.IntConsumer)}
>>        * tryAdvance}.  The extending class should override
>> -     * {@link #forEachRemaining(java.util.function.IntConsumer)}
>> forEach} if it
>> -     * can provide a more performant implementation.
>> +     * {@link #forEachRemaining(java.util.function.IntConsumer)}
>> forEachRemaining}
>> +     * if it can provide a more performant implementation.
>>        *
>>        * @apiNote
>>        * This class is a useful aid for creating a spliterator when it
>> is not
>> @@ -1468,8 +1468,8 @@
>>        * 
To implement a spliterator an extending class need only
>>        * implement {@link #tryAdvance(java.util.function.LongConsumer)}
>>        * tryAdvance}.  The extending class should override
>> -     * {@link #forEachRemaining(java.util.function.LongConsumer)}
>> forEach} if it
>> -     * can provide a more performant implementation.
>> +     * {@link #forEachRemaining(java.util.function.LongConsumer)}
>> forEachRemaining}
>> +     * if it can provide a more performant implementation.
>>        *
>>        * @apiNote
>>        * This class is a useful aid for creating a spliterator when it
>> is not
>> @@ -1578,8 +1578,8 @@
>>        * 
To implement a spliterator an extending class need only
>>        * implement {@link #tryAdvance(java.util.function.DoubleConsumer)}
>>        * tryAdvance}.  The extending class should override
>> -     * {@link #forEachRemaining(java.util.function.DoubleConsumer)}
>> forEach} if
>> -     * it can provide a more performant implementation.
>> +     * {@link #forEachRemaining(java.util.function.DoubleConsumer)}
>> forEachRemaining}
>> +     * if it can provide a more performant implementation.
>>        *
>>        * @apiNote
>>        * This class is a useful aid for creating a spliterator when it
>> is not
>>
>> On Jul 12, 2015, at 11:56 AM, Stefan Zobel  wrote:
>>
>>> Hi all,
>>>
>>>
>>> I just noticed some typos in the
>>> Spliterators.Abstract(Double/Int/Long)Spliterator Javadoc:
>>>
>>> a) The forEachRemaining link label is "forEach" instead of
>>> "forEachRemaining" in all AbstractSpliterators.
>>>
>>> b) The primitive AbstractSpliterators Javadoc has a surplus "}" just
>>> before
>>> the tryAdvance and forEach link labels.
>>>
>>>
>>>
>>> Stefan
>>
>



From paul.sandoz at oracle.com  Thu Jul 16 10:17:44 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 16 Jul 2015 12:17:44 +0200
Subject: RFR 8131052 Documentation of AbstractSpliterator refers to
	forEach rather than forEachRemaining
In-Reply-To: <55A78249.4050605@oracle.com>
References: 	<70C9F5D9-094D-4CDE-B348-E0B364C2747F@oracle.com>
	<55A780D8.1090909@oracle.com> <55A78249.4050605@oracle.com>
Message-ID: <8000442D-8684-4949-8133-745D9CA595E3@oracle.com>


On Jul 16, 2015, at 12:07 PM, Daniel Fuchs  wrote:

> On 16/07/15 12:00, Daniel Fuchs wrote:
>> On 13/07/15 11:19, Paul Sandoz wrote:
>>> Hi
>>> 
>>> Stefan, thanks.
>>> 
>>> See below for a patch to the documentation of all abstract spliterators.
>> 
>> Looks good to me Paul.
> 
> Sorry - re reading my mail I see that you have an extreneous '}'
> at the three last places - just after the closing ')':

Thanks, fixed,
Paul.

> 
> 
> >> +     * {@link #forEachRemaining(java.util.function.IntConsumer)}
> >> forEachRemaining}
> >> +     * if it can provide a more performant implementation.
> 
> 
> >> +     * {@link #forEachRemaining(java.util.function.LongConsumer)}
> >> forEachRemaining}
> >> +     * if it can provide a more performant implementation.
> 
> 
> >> +     * {@link #forEachRemaining(java.util.function.DoubleConsumer)}
> >> forEachRemaining}
> >> +     * if it can provide a more performant implementation.
> 
> -- daniel
> 
>> 
>> best regards,
>> 
>> -- daniel
>> 
>>> 
>>> Paul.
>>> 
>>> diff -r a3175de2e354
>>> src/java.base/share/classes/java/util/Spliterators.java
>>> --- a/src/java.base/share/classes/java/util/Spliterators.java    Tue
>>> Jun 09 07:10:03 2015 +0100
>>> +++ b/src/java.base/share/classes/java/util/Spliterators.java    Mon
>>> Jul 13 11:16:24 2015 +0200
>>> @@ -1235,8 +1235,8 @@
>>>       * 
An extending class need only
>>>       * implement {@link #tryAdvance(java.util.function.Consumer)
>>> tryAdvance}.
>>>       * The extending class should override
>>> -     * {@link #forEachRemaining(java.util.function.Consumer) forEach}
>>> if it can
>>> -     * provide a more performant implementation.
>>> +     * {@link #forEachRemaining(java.util.function.Consumer)
>>> forEachRemaining}
>>> +     * if it can provide a more performant implementation.
>>>       *
>>>       * @apiNote
>>>       * This class is a useful aid for creating a spliterator when it
>>> is not
>>> @@ -1358,8 +1358,8 @@
>>>       * 
To implement a spliterator an extending class need only
>>>       * implement {@link #tryAdvance(java.util.function.IntConsumer)}
>>>       * tryAdvance}.  The extending class should override
>>> -     * {@link #forEachRemaining(java.util.function.IntConsumer)}
>>> forEach} if it
>>> -     * can provide a more performant implementation.
>>> +     * {@link #forEachRemaining(java.util.function.IntConsumer)}
>>> forEachRemaining}
>>> +     * if it can provide a more performant implementation.
>>>       *
>>>       * @apiNote
>>>       * This class is a useful aid for creating a spliterator when it
>>> is not
>>> @@ -1468,8 +1468,8 @@
>>>       * 
To implement a spliterator an extending class need only
>>>       * implement {@link #tryAdvance(java.util.function.LongConsumer)}
>>>       * tryAdvance}.  The extending class should override
>>> -     * {@link #forEachRemaining(java.util.function.LongConsumer)}
>>> forEach} if it
>>> -     * can provide a more performant implementation.
>>> +     * {@link #forEachRemaining(java.util.function.LongConsumer)}
>>> forEachRemaining}
>>> +     * if it can provide a more performant implementation.
>>>       *
>>>       * @apiNote
>>>       * This class is a useful aid for creating a spliterator when it
>>> is not
>>> @@ -1578,8 +1578,8 @@
>>>       * 
To implement a spliterator an extending class need only
>>>       * implement {@link #tryAdvance(java.util.function.DoubleConsumer)}
>>>       * tryAdvance}.  The extending class should override
>>> -     * {@link #forEachRemaining(java.util.function.DoubleConsumer)}
>>> forEach} if
>>> -     * it can provide a more performant implementation.
>>> +     * {@link #forEachRemaining(java.util.function.DoubleConsumer)}
>>> forEachRemaining}
>>> +     * if it can provide a more performant implementation.
>>>       *
>>>       * @apiNote
>>>       * This class is a useful aid for creating a spliterator when it
>>> is not
>>> 
>>> On Jul 12, 2015, at 11:56 AM, Stefan Zobel  wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> 
>>>> I just noticed some typos in the
>>>> Spliterators.Abstract(Double/Int/Long)Spliterator Javadoc:
>>>> 
>>>> a) The forEachRemaining link label is "forEach" instead of
>>>> "forEachRemaining" in all AbstractSpliterators.
>>>> 
>>>> b) The primitive AbstractSpliterators Javadoc has a surplus "}" just
>>>> before
>>>> the tryAdvance and forEach link labels.
>>>> 
>>>> 
>>>> 
>>>> Stefan
>>> 
>> 
> 



From michael.haupt at oracle.com  Thu Jul 16 13:42:22 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Thu, 16 Jul 2015 15:42:22 +0200
Subject: RFR(S): 8062543: Replace uses of MethodHandleImpl.castReference
	with Class.cast
In-Reply-To: <37BF5CDF-7F25-4628-833C-87D64D9C5E10@oracle.com>
References: <4C4D5F89-E8E0-4104-9C55-9643B9732349@oracle.com>
	
	<37BF5CDF-7F25-4628-833C-87D64D9C5E10@oracle.com>
Message-ID: 

Hi Paul, Vladimir,

the data exhibit some decreases and some increases. Please comment.

Best,

Michael

Original JDK:
Benchmark                           Mode  Samples     Score  Score error  Units
o.m.b.s.o.Box2DBench.test           avgt       25    68.136        5.515  ms/op
o.m.b.s.o.CodeLoadBench.test        avgt       25  3827.190       59.335  ms/op
o.m.b.s.o.CryptoBench.test          avgt       25     9.987        0.084  ms/op
o.m.b.s.o.DeltaBlueBench.test       avgt       25   939.489        8.072  us/op
o.m.b.s.o.EarleyBoyerBench.test     avgt       25    21.667        0.369  ms/op
o.m.b.s.o.GbemuBench.test           avgt       25    69.289        1.381  ms/op
o.m.b.s.o.MandreelBench.test        avgt       25  1168.844       22.119  ms/op
o.m.b.s.o.NavierStokesBench.test    avgt       25     7.316        0.019  ms/op
o.m.b.s.o.PdfJSBench.test           avgt       25   108.611        9.979  ms/op
o.m.b.s.o.RaytraceBench.test        avgt       25  7002.523       52.355  us/op
o.m.b.s.o.RegexpBench.test          avgt       25    99.227        2.064  ms/op
o.m.b.s.o.RichardsBench.test        avgt       25   310.353        1.122  us/op
o.m.b.s.o.TypescriptBench.test      avgt       25     5.093        0.092   s/op

Modified JDK:
Benchmark                           Mode  Samples     Score  Score error  Units
o.m.b.s.o.Box2DBench.test           avgt       25    57.906        1.937  ms/op
o.m.b.s.o.CodeLoadBench.test        avgt       25  3789.170       38.922  ms/op
o.m.b.s.o.CryptoBench.test          avgt       25     9.854        0.120  ms/op
o.m.b.s.o.DeltaBlueBench.test       avgt       25   937.746        3.167  us/op
o.m.b.s.o.EarleyBoyerBench.test     avgt       25    20.890        0.428  ms/op
o.m.b.s.o.GbemuBench.test           avgt       25    68.949        0.421  ms/op
o.m.b.s.o.MandreelBench.test        avgt       25  1208.157       18.836  ms/op
o.m.b.s.o.NavierStokesBench.test    avgt       25     6.774        0.017  ms/op
o.m.b.s.o.PdfJSBench.test           avgt       25   111.189       11.428  ms/op
o.m.b.s.o.RaytraceBench.test        avgt       25  6905.455      137.892  us/op
o.m.b.s.o.RegexpBench.test          avgt       25    96.781        1.628  ms/op
o.m.b.s.o.RichardsBench.test        avgt       25   310.157        1.956  us/op
o.m.b.s.o.TypescriptBench.test      avgt       25     4.991        0.054   s/op

> Am 15.07.2015 um 13:58 schrieb Michael Haupt :
> 
> Hi Paul, Vladimir,
> 
> thanks - I'll be back with perf numbers ASAP.
> 
> Best,
> 
> Michael
> 
>> Am 15.07.2015 um 12:51 schrieb Paul Sandoz :
>> 
>> 
>> On Jul 15, 2015, at 10:23 AM, Michael Haupt  wrote:
>> 
>>> Dear all,
>>> 
>>> please review and sponsor this change.
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8062543
>>> Webrev: http://cr.openjdk.java.net/~mhaupt/8062543/webrev.00/
>>> 
>>> The change removes the no longer needed MethodHandleImpl.castReference method. Its uses are replaced with Class.cast.
>>> 
>> 
>> Look good. I agree with Vladimir on checking for performance regressions (i suspect/hope! there will not be any).
>> 
>> Paul.
>> 
>>> Tested with:
>>> * jtreg (java.lang.invoke, java.util.stream)
>>> * JPRT (hotspot and jdk_lang test sets)
>>> * UTE (vm.quick-pcl.testlist, vm.defmeth.testlist)
>>> 
>>> Thanks,
>>> 
>>> Michael


-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 	Oracle is committed to developing practices and products that help protect the environment



From xueming.shen at oracle.com  Thu Jul 16 17:04:31 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 16 Jul 2015 10:04:31 -0700
Subject: RFR JDK-8130914:  java/util/zip/TestExtraTime.java fails with
	"java.lang.RuntimeException: setTime should make getLastModifiedTime
	return the specified instant: 3078282244456 got: 3078282244455"
In-Reply-To: <8858E3BD-F063-40DA-831C-540D3FD92C1A@oracle.com>
References: <55A6B02F.9060400@oracle.com>
	<8858E3BD-F063-40DA-831C-540D3FD92C1A@oracle.com>
Message-ID: <55A7E41F.5010805@oracle.com>

On 07/15/2015 03:33 PM, Claes Redestad wrote:
> Code change looks OK to me, but perhaps there should be an explicit long conversion somewhere around the getYear() part ('d.getYear() - 1980 << 25L') of the expressions to deal properly with even larger values?
>

The spec of the dos time has the up limit, it should not beyond 32-bit. It was
not a problem when anything number overflows into up 32-bit before we tried
to utilize the up bits for the < 2000ms bits.


> Are there added tests missing from the updated TestExtraTime? I guess this is an intermittent issue, but it looks odd to update the test without adding some explicit test that provoke this issue.
>

It appears this existing test can easily catch the bug, so I just add the bugid to indicate that
this regression test can be used for that particular bug.

thanks,
-sherman


> /Claes
>
> Xueming Shen  skrev: (15 juli 2015 21:10:39 CEST)
>
>     Hi,
>
>     Please help review the change for JDK-8130914.
>
>     issue:https://bugs.openjdk.java.net/browse/JDK-8130914
>     webrev:http://cr.openjdk.java.net/~sherman/8130914  /
>
>     This is a "regression" triggered by
>     https://bugs.openjdk.java.net/browse/JDK-8130914
>     http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6  /
>
>     In which the change is to utilize a high 32-bit of the time value to store
>     <  2000 ms time piece. It appears the offending timestamp (year 2067...)
>     triggers the 32-bit "overflow" when converting java time to a 32-bit dos
>     time.
>
>     Thanks,
>     -Sherman
>



From vladimir.x.ivanov at oracle.com  Thu Jul 16 17:24:17 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 16 Jul 2015 20:24:17 +0300
Subject: RFR(S): 8062543: Replace uses of MethodHandleImpl.castReference
	with Class.cast
In-Reply-To: 
References: <4C4D5F89-E8E0-4104-9C55-9643B9732349@oracle.com>		<37BF5CDF-7F25-4628-833C-87D64D9C5E10@oracle.com>
	
Message-ID: <55A7E8C1.5010505@oracle.com>

Thanks for the data, the numbers look fine.

Best regards,
Vladimir Ivanov

PS: as I told you privately, some Octane benchmarks are noisy and 5 
forks aren't enough to get stable results.

On 7/16/15 4:42 PM, Michael Haupt wrote:
> Hi Paul, Vladimir,
>
> the data exhibit some decreases and some increases. Please comment.
>
> Best,
>
> Michael
>
> Original JDK:
> Benchmark                           Mode  Samples     Score  Score error  Units
> o.m.b.s.o.Box2DBench.test           avgt       25    68.136        5.515  ms/op
> o.m.b.s.o.CodeLoadBench.test        avgt       25  3827.190       59.335  ms/op
> o.m.b.s.o.CryptoBench.test          avgt       25     9.987        0.084  ms/op
> o.m.b.s.o.DeltaBlueBench.test       avgt       25   939.489        8.072  us/op
> o.m.b.s.o.EarleyBoyerBench.test     avgt       25    21.667        0.369  ms/op
> o.m.b.s.o.GbemuBench.test           avgt       25    69.289        1.381  ms/op
> o.m.b.s.o.MandreelBench.test        avgt       25  1168.844       22.119  ms/op
> o.m.b.s.o.NavierStokesBench.test    avgt       25     7.316        0.019  ms/op
> o.m.b.s.o.PdfJSBench.test           avgt       25   108.611        9.979  ms/op
> o.m.b.s.o.RaytraceBench.test        avgt       25  7002.523       52.355  us/op
> o.m.b.s.o.RegexpBench.test          avgt       25    99.227        2.064  ms/op
> o.m.b.s.o.RichardsBench.test        avgt       25   310.353        1.122  us/op
> o.m.b.s.o.TypescriptBench.test      avgt       25     5.093        0.092   s/op
>
> Modified JDK:
> Benchmark                           Mode  Samples     Score  Score error  Units
> o.m.b.s.o.Box2DBench.test           avgt       25    57.906        1.937  ms/op
> o.m.b.s.o.CodeLoadBench.test        avgt       25  3789.170       38.922  ms/op
> o.m.b.s.o.CryptoBench.test          avgt       25     9.854        0.120  ms/op
> o.m.b.s.o.DeltaBlueBench.test       avgt       25   937.746        3.167  us/op
> o.m.b.s.o.EarleyBoyerBench.test     avgt       25    20.890        0.428  ms/op
> o.m.b.s.o.GbemuBench.test           avgt       25    68.949        0.421  ms/op
> o.m.b.s.o.MandreelBench.test        avgt       25  1208.157       18.836  ms/op
> o.m.b.s.o.NavierStokesBench.test    avgt       25     6.774        0.017  ms/op
> o.m.b.s.o.PdfJSBench.test           avgt       25   111.189       11.428  ms/op
> o.m.b.s.o.RaytraceBench.test        avgt       25  6905.455      137.892  us/op
> o.m.b.s.o.RegexpBench.test          avgt       25    96.781        1.628  ms/op
> o.m.b.s.o.RichardsBench.test        avgt       25   310.157        1.956  us/op
> o.m.b.s.o.TypescriptBench.test      avgt       25     4.991        0.054   s/op
>
>> Am 15.07.2015 um 13:58 schrieb Michael Haupt :
>>
>> Hi Paul, Vladimir,
>>
>> thanks - I'll be back with perf numbers ASAP.
>>
>> Best,
>>
>> Michael
>>
>>> Am 15.07.2015 um 12:51 schrieb Paul Sandoz :
>>>
>>>
>>> On Jul 15, 2015, at 10:23 AM, Michael Haupt  wrote:
>>>
>>>> Dear all,
>>>>
>>>> please review and sponsor this change.
>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8062543
>>>> Webrev: http://cr.openjdk.java.net/~mhaupt/8062543/webrev.00/
>>>>
>>>> The change removes the no longer needed MethodHandleImpl.castReference method. Its uses are replaced with Class.cast.
>>>>
>>>
>>> Look good. I agree with Vladimir on checking for performance regressions (i suspect/hope! there will not be any).
>>>
>>> Paul.
>>>
>>>> Tested with:
>>>> * jtreg (java.lang.invoke, java.util.stream)
>>>> * JPRT (hotspot and jdk_lang test sets)
>>>> * UTE (vm.quick-pcl.testlist, vm.defmeth.testlist)
>>>>
>>>> Thanks,
>>>>
>>>> Michael
>
>


From stuart.marks at oracle.com  Fri Jul 17 01:16:25 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 16 Jul 2015 18:16:25 -0700
Subject: Idea to Java ArrayLists
In-Reply-To: <559E9F78.20906@univ-mlv.fr>
References: <559E997D.9000606@bibik.de> <559E9F78.20906@univ-mlv.fr>
Message-ID: <55A85769.3030204@oracle.com>



On 7/9/15 9:21 AM, Remi Forax wrote:
> There is an open bug to add a bunch of static methods 'of' to do something
> similar to what you want,
>    https://bugs.openjdk.java.net/browse/JDK-8026106
> this is something that a lot of people will like to have and i hope that this
> can be integrated in 9.

Hi Remi,

Thanks for mentioning this. The main JEP for this effort is

     https://bugs.openjdk.java.net/browse/JDK-8048330

Although this hasn't been updated in some time, I'm intending to return to this 
in the near future with an eye toward integrating it into JDK 9.

The JEP says that we "might" also include static factory methods for the most 
common concrete collections. The current thinking is now that we will definitely 
include them.

s'marks


From peter.levart at gmail.com  Fri Jul 17 08:04:29 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 17 Jul 2015 10:04:29 +0200
Subject: RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with
	"java.lang.RuntimeException: setTime should make getLastModifiedTime
	return the specified instant: 3078282244456 got: 3078282244455"
In-Reply-To: <55A6B02F.9060400@oracle.com>
References: <55A6B02F.9060400@oracle.com>
Message-ID: <55A8B70D.3050406@gmail.com>

Hi Sherman,

On 07/15/2015 09:10 PM, Xueming Shen wrote:
> Hi,
>
> Please help review the change for JDK-8130914.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8130914
> webrev: http://cr.openjdk.java.net/~sherman/8130914/
>
> This is a "regression" triggered by
> https://bugs.openjdk.java.net/browse/JDK-8130914
> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/

And-ing the result with a 32 bit mask (2^32 - 1) does make sure that 
high 32 bits are not touched by year encoding. As I understand, this 
starts to be a problem with year 2044 and beyond when (year - 1980) << 
25 becomes a negative number. Expanding it to long sets the high 32 bits 
too. If we treat the lower 32 bits as unsigned, we accommodate for years 
up to and including 2107. At 2108, the overflow happens and decoding the 
year back gives 1980 instead of 2108. So I wonder:
- will there be a DOS compatible ZIP format after 2108 ?
- will there be Java after 2108 ?
- depending on the above answers, should there be a DOSTIME_AFTER_2107 
in addition to DOSTIME_BEFORE_1980 to which the date is clamped?

Regards, Peter

>
> In which the change is to utilize a high 32-bit of the time value to 
> store
> < 2000 ms time piece. It appears the offending timestamp (year 2067...)
> triggers the 32-bit "overflow" when converting java time to a 32-bit dos
> time.
>
> Thanks,
> -Sherman



From yekaterina.kantserova at oracle.com  Fri Jul 17 12:47:16 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Fri, 17 Jul 2015 14:47:16 +0200
Subject: RFR(XS): 8075658: Mark intermittently failuring core-svc tests
Message-ID: <55A8F954.8050202@oracle.com>

Hi,

Could I please have a review of this fix.

bug: https://bugs.openjdk.java.net/browse/JDK-8075658
webrev: http://cr.openjdk.java.net/~ykantser/8075658/webrev.00

Thanks,
Katja


From yekaterina.kantserova at oracle.com  Fri Jul 17 13:33:27 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Fri, 17 Jul 2015 15:33:27 +0200
Subject: RFR(XS): 8075658: Mark intermittently failuring core-svc tests
In-Reply-To: <55A8FD47.6030404@oracle.com>
References: <55A8F954.8050202@oracle.com> <55A8FD47.6030404@oracle.com>
Message-ID: <55A90427.5040808@oracle.com>

Jaroslav,

Thank you for the review!

It has been a relatively manual process and I'm not aware of a mechanism 
how to sync test-key-bug. What I can do is to mark bugs I went through 
with for example 'key-intermittent' label to distinguish them form the 
new ones.

Are there other suggestions?

// Katja



On 07/17/2015 03:04 PM, Jaroslav Bachorik wrote:
> Looks good.
>
> Is there any way to check that all the issues from the JBS query 
> mentioned in JDK-8075658 are addressed?
>
> -JB-
>
> On 17.7.2015 14:47, Yekaterina Kantserova wrote:
>> Hi,
>>
>> Could I please have a review of this fix.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8075658
>> webrev: http://cr.openjdk.java.net/~ykantser/8075658/webrev.00
>>
>> Thanks,
>> Katja
>



From olivier.lagneau at oracle.com  Fri Jul 17 13:53:47 2015
From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com)
Date: Fri, 17 Jul 2015 15:53:47 +0200
Subject: RFR(XS): 8075658: Mark intermittently failuring core-svc tests
In-Reply-To: <55A90427.5040808@oracle.com>
References: <55A8F954.8050202@oracle.com> <55A8FD47.6030404@oracle.com>
	<55A90427.5040808@oracle.com>
Message-ID: <55A908EB.2030500@oracle.com>

Hi Katja,

Looks ok to me too.

>
> It has been a relatively manual process and I'm not aware of a 
> mechanism how to sync test-key-bug. What I can do is to mark bugs I 
> went through with for example 'key-intermittent' label to distinguish 
> them form the new ones.
That's another additional label, and as I understand Joe's comment most 
important is to mark them intermittent with jtreg flag.
Don't have any other suggestions however.

Olivier.

On 17/07/2015 15:33, Yekaterina Kantserova wrote:
> Jaroslav,
>
> Thank you for the review!
>
> It has been a relatively manual process and I'm not aware of a 
> mechanism how to sync test-key-bug. What I can do is to mark bugs I 
> went through with for example 'key-intermittent' label to distinguish 
> them form the new ones.
>
> Are there other suggestions?
>
> // Katja
>
>
>
> On 07/17/2015 03:04 PM, Jaroslav Bachorik wrote:
>> Looks good.
>>
>> Is there any way to check that all the issues from the JBS query 
>> mentioned in JDK-8075658 are addressed?
>>
>> -JB-
>>
>> On 17.7.2015 14:47, Yekaterina Kantserova wrote:
>>> Hi,
>>>
>>> Could I please have a review of this fix.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075658
>>> webrev: http://cr.openjdk.java.net/~ykantser/8075658/webrev.00
>>>
>>> Thanks,
>>> Katja
>>
>



From xueming.shen at oracle.com  Fri Jul 17 15:45:37 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 17 Jul 2015 08:45:37 -0700
Subject: RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with
	"java.lang.RuntimeException: setTime should make getLastModifiedTime
	return the specified instant: 3078282244456 got: 3078282244455"
In-Reply-To: <55A8B70D.3050406@gmail.com>
References: <55A6B02F.9060400@oracle.com> <55A8B70D.3050406@gmail.com>
Message-ID: <55A92321.1010605@oracle.com>

On 7/17/15 1:04 AM, Peter Levart wrote:
> Hi Sherman,
>
> On 07/15/2015 09:10 PM, Xueming Shen wrote:
>> Hi,
>>
>> Please help review the change for JDK-8130914.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8130914
>> webrev: http://cr.openjdk.java.net/~sherman/8130914/
>>
>> This is a "regression" triggered by
>> https://bugs.openjdk.java.net/browse/JDK-8130914
>> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
>
> And-ing the result with a 32 bit mask (2^32 - 1) does make sure that 
> high 32 bits are not touched by year encoding. As I understand, this 
> starts to be a problem with year 2044 and beyond when (year - 1980) << 
> 25 becomes a negative number. Expanding it to long sets the high 32 
> bits too. If we treat the lower 32 bits as unsigned, we accommodate 
> for years up to and including 2107. At 2108, the overflow happens and 
> decoding the year back gives 1980 instead of 2108. So I wonder:
> - will there be a DOS compatible ZIP format after 2108 ?
> - will there be Java after 2108 ?

Yes, dos timestamp has a 2107 ceiling, given it's 32-bit nature, like 
the unix time has a 2038 ceiling if
the long stays as 32-bit.

> - depending on the above answers, should there be a DOSTIME_AFTER_2107 
> in addition to DOSTIME_BEFORE_1980 to which the date is clamped?
>

If ZIP is still being used on 2107, "we" have a problem.

-Sherman

> Regards, Peter
>
>>
>> In which the change is to utilize a high 32-bit of the time value to 
>> store
>> < 2000 ms time piece. It appears the offending timestamp (year 2067...)
>> triggers the 32-bit "overflow" when converting java time to a 32-bit dos
>> time.
>>
>> Thanks,
>> -Sherman
>



From xueming.shen at oracle.com  Fri Jul 17 16:12:15 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 17 Jul 2015 09:12:15 -0700
Subject: RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with
	"java.lang.RuntimeException: setTime should make getLastModifiedTime
	return the specified instant: 3078282244456 got: 3078282244455"
In-Reply-To: <55A92321.1010605@oracle.com>
References: <55A6B02F.9060400@oracle.com> <55A8B70D.3050406@gmail.com>
	<55A92321.1010605@oracle.com>
Message-ID: <55A9295F.10202@oracle.com>

On 7/17/15 8:45 AM, Xueming Shen wrote:
> On 7/17/15 1:04 AM, Peter Levart wrote:
>> Hi Sherman,
>>
>> On 07/15/2015 09:10 PM, Xueming Shen wrote:
>>> Hi,
>>>
>>> Please help review the change for JDK-8130914.
>>>
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8130914
>>> webrev: http://cr.openjdk.java.net/~sherman/8130914/
>>>
>>> This is a "regression" triggered by
>>> https://bugs.openjdk.java.net/browse/JDK-8130914
>>> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
>>
>> And-ing the result with a 32 bit mask (2^32 - 1) does make sure that 
>> high 32 bits are not touched by year encoding. As I understand, this 
>> starts to be a problem with year 2044 and beyond when (year - 1980) 
>> << 25 becomes a negative number. Expanding it to long sets the high 
>> 32 bits too. If we treat the lower 32 bits as unsigned, we 
>> accommodate for years up to and including 2107. At 2108, the overflow 
>> happens and decoding the year back gives 1980 instead of 2108. So I 
>> wonder:
>> - will there be a DOS compatible ZIP format after 2108 ?
>> - will there be Java after 2108 ?
>
> Yes, dos timestamp has a 2107 ceiling, given it's 32-bit nature, like 
> the unix time has a 2038 ceiling if
> the long stays as 32-bit.
>
>> - depending on the above answers, should there be a 
>> DOSTIME_AFTER_2107 in addition to DOSTIME_BEFORE_1980 to which the 
>> date is clamped?
>>
>
btw, we do have a ZipEntry.UPPER_DOSTIME_BOUND to help save a timestamp 
into the extra field, if necessary.

-sherman


From joe.darcy at oracle.com  Fri Jul 17 16:46:25 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 17 Jul 2015 09:46:25 -0700
Subject: RFR(XS): 8075658: Mark intermittently failuring core-svc tests
In-Reply-To: <55A908EB.2030500@oracle.com>
References: <55A8F954.8050202@oracle.com>
	<55A8FD47.6030404@oracle.com>	<55A90427.5040808@oracle.com>
	<55A908EB.2030500@oracle.com>
Message-ID: <55A93161.6060001@oracle.com>

Hello,

Yes, my general guidance is to make sure flaky tests are marked as 
"intermittent" in the test itself. This lets someone running the test 
easily check if the test is known to be unreliable *in that state of the 
sources*.

There is a upfront overhead to collecting information about the current 
unreliable tests from the bug database, personal notes, etc. However, I 
would expect the marginal cost to keep the intermittent-ness updated to 
be small and marking the tests this way should allow easier analysis of 
failures.

Thanks,

-Joe

On 7/17/2015 6:53 AM, olivier.lagneau at oracle.com wrote:
> Hi Katja,
>
> Looks ok to me too.
>
>>
>> It has been a relatively manual process and I'm not aware of a 
>> mechanism how to sync test-key-bug. What I can do is to mark bugs I 
>> went through with for example 'key-intermittent' label to distinguish 
>> them form the new ones.
> That's another additional label, and as I understand Joe's comment 
> most important is to mark them intermittent with jtreg flag.
> Don't have any other suggestions however.
>
> Olivier.
>
> On 17/07/2015 15:33, Yekaterina Kantserova wrote:
>> Jaroslav,
>>
>> Thank you for the review!
>>
>> It has been a relatively manual process and I'm not aware of a 
>> mechanism how to sync test-key-bug. What I can do is to mark bugs I 
>> went through with for example 'key-intermittent' label to distinguish 
>> them form the new ones.
>>
>> Are there other suggestions?
>>
>> // Katja
>>
>>
>>
>> On 07/17/2015 03:04 PM, Jaroslav Bachorik wrote:
>>> Looks good.
>>>
>>> Is there any way to check that all the issues from the JBS query 
>>> mentioned in JDK-8075658 are addressed?
>>>
>>> -JB-
>>>
>>> On 17.7.2015 14:47, Yekaterina Kantserova wrote:
>>>> Hi,
>>>>
>>>> Could I please have a review of this fix.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075658
>>>> webrev: http://cr.openjdk.java.net/~ykantser/8075658/webrev.00
>>>>
>>>> Thanks,
>>>> Katja
>>>
>>
>



From volker.simonis at gmail.com  Fri Jul 17 18:28:33 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 17 Jul 2015 20:28:33 +0200
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
Message-ID: 

Hi,

I worked on refactoring the native ProcessHandleImpl implementation to
enable more code sharing and make it easier to add support for new
platforms (e.g. AIX) and I think I had a pretty nice version running. But
unfortunately I've just realized that the recent changes to
ProcessHandleImpl (i.e. "8078099: (process) ProcessHandle should uniquely
identify processes" and "8078108: (process) ProcessHandle.isAlive should be
robust") have been massive so I have to start over to merge all my changes
with the new version.

But before doing that I just wanted to post my current changes which
cleanly apply to the repo before 8078099 and ask for your opinion:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v1/

Here's a summary (taken from ProcesHandleImpl_unix.c) of what I've actually
done (if the output appears scrambled in you mail better read it in the
webrev
http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v1/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c.udiff.html
):

/**
 * This file contains the implementation of the native ProcessHandleImpl
 * functions which are common to all Unix variants.
 *
 * The currently supported Unix variants are Solaris, Linux, MaxOS X and
AIX.
 * The various similarities and differences between these systems make it
hard
 * to find a clear boundary between platform specific and shared code.
 *
 * In order to ease code sharing between the pltforms while still keeping
the
 * code as clean as possible (i.e. free of preprocessor macros) we use the
 * following source code layout (remember that ProcessHandleImpl_unix.c will
 * be compiled on EVERY Unix platform while ProcessHandleImpl_.c will be
 * only compiled on the specific OS):
 *
 * - all the JNI wrappers for the ProcessHandleImpl functions go into this
file
 * - if their implementation is common on ALL the supported Unix platforms
it
 *   goes right into the JNI wrappers
 * - if the whole function or substantial parts are platform dependent, the
 *   implementation goes into os_ functions in
 *   ProcessHandleImpl_.c
 * - if at least two platforms implement an os_ function in
the
 *   same way, this implementation is factored out into
unix_,
 *   placed into this file and called from the corresponding
os_
 *   function.
 * - For convenience, all the os_ and unix_ functions are declared in
 *   ProcessHandleImpl_unix.h which is included into every
 *   ProcessHandleImpl_.c file.
 *
 * Example 1:
 * ----------
 * The implementation of
Java_java_lang_ProcessHandleImpl_00024Info_initIDs()
 * is the same on all platforms except on Linux where it initilizes one
 * additional field. So we place the implementation right into
 * Java_java_lang_ProcessHandleImpl_00024Info_initIDs() but add call to
 * os_init() at the end of the function which is empty on all platforms
 * except Linux where it performs the additionally initializations.
 *
 * Example 2:
 * ----------
 * The implementation of Java_java_lang_ProcessHandleImpl_00024Info_info0 is
 * the same on Solaris and AIX but different on Linux and MacOSX. We
therefore
 * simply call the two helpers os_getStatInfo() and os_getCmdlineInfo(). The
 * Linux and MaxOS X versions of these functions (in the corresponding files
 * ProcessHandleImpl_linux.c and ProcessHandleImpl_macosx.c) directly
contain
 * the platform specific implementations while the Solaris and AIX
 * implementations simply call back to unix_getStatInfo() and
 * unix_getCmdlineInfo() which are implemented right in this file.
 *
 * The term "same implementation" is still a question of interpretation. It
my
 * be acceptable to have a few ifdef'ed lines if that allows the sharing of
a
 * huge function. On the other hand, if the platform specific code in a
shared
 * function grows over a certain limit, it may be better to refactor that
 * functionality into corresponding, platform-specific os_ functions.
 */

This resulted in the new file ProcessHandleImpl_linux.c which now only
contains Linux-only code which was previously in ifdefed for Linux in
ProcessHandleImpl_linux.c. The advantage is that we now have only one
version of:

 Java_java_lang_ProcessHandleImpl_00024Info_initIDs
 unix_fillArgArray
 unix_uidToUser

and on version of

 unix_getChildren

which is shared by Solaris, Linux and AIX and one version of

 unix_getStatInfo
 unix_getCmdlineInfo

which are shared by Solaris and Linux.

Additionally I've added the AIX port following the new schema and I've
slightly improved the Solaris port to use the information from
psinfo.pr_psargs for reporting at least the first 80 characters of the
command line arguments. arg[0] from psinfo.pr_psargs is also used as the
"command()" string in the case where "/proc/%d/path/a.out" isn't readable.
This helps to report a command string for all the processes we do not own,
because in that case, "/proc/%d/path/a.out" isn't readable. By the way,
using args[0] as a fall-back for cmd beeing null also helps on MacOS X for
processes we don't own. Finally I've also done some test improvements.

I have tested all my changes on Linux/amd64, Linux/ppc64, MacOS X, Solaris
and AIX.

I'd be happy to forward port my changes to the newest head version if you
generally agree with my approach (and give me a short time frame where you
promise not to do any massive changes :)

What do you think?

Thank you and best regards,
Volker


From rednaxelafx at gmail.com  Fri Jul 17 18:45:17 2015
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Fri, 17 Jul 2015 11:45:17 -0700
Subject: StackOverflowError on HashMap.hashCode() due to self reference
Message-ID: 

Hi everyone,

I'm sure somebody has seen this stack overflow before. My question is: is
it expected (which should be documented to warn people not to do this), or
is it considered a bug (which should be fixed)?

Example:
https://gist.github.com/rednaxelafx/930f8979473185cfc0a0

import java.util.*;

public class HashMapStackOverflow {
  public static void main(String[] args) throws Exception {
    HashMap map = new HashMap<>();
    map.put("self", map);
    System.out.println(map.hashCode());
  }
}

$ ~/sdk/jdk1.8.0/Contents/Home/bin/java HashMapStackOverflow
Exception in thread "main" java.lang.StackOverflowError
at java.util.AbstractMap.hashCode(AbstractMap.java:505)
at java.util.Objects.hashCode(Objects.java:98)
at java.util.HashMap$Node.hashCode(HashMap.java:296)
at java.util.AbstractMap.hashCode(AbstractMap.java:507)
at java.util.Objects.hashCode(Objects.java:98)
at java.util.HashMap$Node.hashCode(HashMap.java:296)
at java.util.AbstractMap.hashCode(AbstractMap.java:507)
at java.util.Objects.hashCode(Objects.java:98)
at java.util.HashMap$Node.hashCode(HashMap.java:296)
at java.util.AbstractMap.hashCode(AbstractMap.java:507)
...

This will cause a stack overflow because HashMap.hashCode() is inherited
from AbstractMap, which sums the hash code of each entry, while one of the
entries is itself so it goes recursive.

Thanks,
Kris


From vitalyd at gmail.com  Fri Jul 17 18:58:15 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 17 Jul 2015 14:58:15 -0400
Subject: StackOverflowError on HashMap.hashCode() due to self reference
In-Reply-To: 
References: 
Message-ID: 

IMHO, this doesn't warrant any special wording -- if someone hits this, I
think it's fairly evident what the issue is.  You can get the same problem
with adding an ArrayList to itself and calling hashCode().

On Fri, Jul 17, 2015 at 2:45 PM, Krystal Mok  wrote:

> Hi everyone,
>
> I'm sure somebody has seen this stack overflow before. My question is: is
> it expected (which should be documented to warn people not to do this), or
> is it considered a bug (which should be fixed)?
>
> Example:
> https://gist.github.com/rednaxelafx/930f8979473185cfc0a0
>
> import java.util.*;
>
> public class HashMapStackOverflow {
>   public static void main(String[] args) throws Exception {
>     HashMap map = new HashMap<>();
>     map.put("self", map);
>     System.out.println(map.hashCode());
>   }
> }
>
> $ ~/sdk/jdk1.8.0/Contents/Home/bin/java HashMapStackOverflow
> Exception in thread "main" java.lang.StackOverflowError
> at java.util.AbstractMap.hashCode(AbstractMap.java:505)
> at java.util.Objects.hashCode(Objects.java:98)
> at java.util.HashMap$Node.hashCode(HashMap.java:296)
> at java.util.AbstractMap.hashCode(AbstractMap.java:507)
> at java.util.Objects.hashCode(Objects.java:98)
> at java.util.HashMap$Node.hashCode(HashMap.java:296)
> at java.util.AbstractMap.hashCode(AbstractMap.java:507)
> at java.util.Objects.hashCode(Objects.java:98)
> at java.util.HashMap$Node.hashCode(HashMap.java:296)
> at java.util.AbstractMap.hashCode(AbstractMap.java:507)
> ...
>
> This will cause a stack overflow because HashMap.hashCode() is inherited
> from AbstractMap, which sums the hash code of each entry, while one of the
> entries is itself so it goes recursive.
>
> Thanks,
> Kris
>


From rednaxelafx at gmail.com  Fri Jul 17 19:10:29 2015
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Fri, 17 Jul 2015 12:10:29 -0700
Subject: StackOverflowError on HashMap.hashCode() due to self reference
In-Reply-To: 
References: 
	
Message-ID: 

Hi Vitaly,

I can buy that argument. It wasn't hard for me to recognize it when I saw
it in real world.

But apparently whoever asked me about it couldn't wrap his head around it
to understand why...

Maybe it's a case for a Pitfalls book instead of for JavaDocs.

Thanks,
Kris

On Friday, July 17, 2015, Vitaly Davidovich > wrote:

> IMHO, this doesn't warrant any special wording -- if someone hits this, I
> think it's fairly evident what the issue is.  You can get the same problem
> with adding an ArrayList to itself and calling hashCode().
>
> On Fri, Jul 17, 2015 at 2:45 PM, Krystal Mok 
> wrote:
>
>> Hi everyone,
>>
>> I'm sure somebody has seen this stack overflow before. My question is: is
>> it expected (which should be documented to warn people not to do this), or
>> is it considered a bug (which should be fixed)?
>>
>> Example:
>> https://gist.github.com/rednaxelafx/930f8979473185cfc0a0
>>
>> import java.util.*;
>>
>> public class HashMapStackOverflow {
>>   public static void main(String[] args) throws Exception {
>>     HashMap map = new HashMap<>();
>>     map.put("self", map);
>>     System.out.println(map.hashCode());
>>   }
>> }
>>
>> $ ~/sdk/jdk1.8.0/Contents/Home/bin/java HashMapStackOverflow
>> Exception in thread "main" java.lang.StackOverflowError
>> at java.util.AbstractMap.hashCode(AbstractMap.java:505)
>> at java.util.Objects.hashCode(Objects.java:98)
>> at java.util.HashMap$Node.hashCode(HashMap.java:296)
>> at java.util.AbstractMap.hashCode(AbstractMap.java:507)
>> at java.util.Objects.hashCode(Objects.java:98)
>> at java.util.HashMap$Node.hashCode(HashMap.java:296)
>> at java.util.AbstractMap.hashCode(AbstractMap.java:507)
>> at java.util.Objects.hashCode(Objects.java:98)
>> at java.util.HashMap$Node.hashCode(HashMap.java:296)
>> at java.util.AbstractMap.hashCode(AbstractMap.java:507)
>> ...
>>
>> This will cause a stack overflow because HashMap.hashCode() is inherited
>> from AbstractMap, which sums the hash code of each entry, while one of the
>> entries is itself so it goes recursive.
>>
>> Thanks,
>> Kris
>>
>
>


From lowasser at google.com  Fri Jul 17 19:25:09 2015
From: lowasser at google.com (Louis Wasserman)
Date: Fri, 17 Jul 2015 19:25:09 +0000
Subject: StackOverflowError on HashMap.hashCode() due to self reference
In-Reply-To: 
References: 
	
	
Message-ID: 

The Javadoc of Map already specifies:

> Note: great care must be exercised if mutable objects are used as map
keys. The behavior of a map is not specified if the value of an object is
changed in a manner that affects equals comparisons while the object is a
key in the map. *A special case of this prohibition is that it is not
permissible for a map to contain itself as a key. While it is permissible
for a map to contain itself as a value, extreme caution is advised:
the **equals and hashCode methods
are no longer well defined on such a map.*

(emphasis added)

On Fri, Jul 17, 2015 at 12:11 PM Krystal Mok  wrote:

> Hi Vitaly,
>
> I can buy that argument. It wasn't hard for me to recognize it when I saw
> it in real world.
>
> But apparently whoever asked me about it couldn't wrap his head around it
> to understand why...
>
> Maybe it's a case for a Pitfalls book instead of for JavaDocs.
>
> Thanks,
> Kris
>
> On Friday, July 17, 2015, Vitaly Davidovich  > wrote:
>
> > IMHO, this doesn't warrant any special wording -- if someone hits this, I
> > think it's fairly evident what the issue is.  You can get the same
> problem
> > with adding an ArrayList to itself and calling hashCode().
> >
> > On Fri, Jul 17, 2015 at 2:45 PM, Krystal Mok 
> > wrote:
> >
> >> Hi everyone,
> >>
> >> I'm sure somebody has seen this stack overflow before. My question is:
> is
> >> it expected (which should be documented to warn people not to do this),
> or
> >> is it considered a bug (which should be fixed)?
> >>
> >> Example:
> >> https://gist.github.com/rednaxelafx/930f8979473185cfc0a0
> >>
> >> import java.util.*;
> >>
> >> public class HashMapStackOverflow {
> >>   public static void main(String[] args) throws Exception {
> >>     HashMap map = new HashMap<>();
> >>     map.put("self", map);
> >>     System.out.println(map.hashCode());
> >>   }
> >> }
> >>
> >> $ ~/sdk/jdk1.8.0/Contents/Home/bin/java HashMapStackOverflow
> >> Exception in thread "main" java.lang.StackOverflowError
> >> at java.util.AbstractMap.hashCode(AbstractMap.java:505)
> >> at java.util.Objects.hashCode(Objects.java:98)
> >> at java.util.HashMap$Node.hashCode(HashMap.java:296)
> >> at java.util.AbstractMap.hashCode(AbstractMap.java:507)
> >> at java.util.Objects.hashCode(Objects.java:98)
> >> at java.util.HashMap$Node.hashCode(HashMap.java:296)
> >> at java.util.AbstractMap.hashCode(AbstractMap.java:507)
> >> at java.util.Objects.hashCode(Objects.java:98)
> >> at java.util.HashMap$Node.hashCode(HashMap.java:296)
> >> at java.util.AbstractMap.hashCode(AbstractMap.java:507)
> >> ...
> >>
> >> This will cause a stack overflow because HashMap.hashCode() is inherited
> >> from AbstractMap, which sums the hash code of each entry, while one of
> the
> >> entries is itself so it goes recursive.
> >>
> >> Thanks,
> >> Kris
> >>
> >
> >
>


From rednaxelafx at gmail.com  Fri Jul 17 19:27:58 2015
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Fri, 17 Jul 2015 12:27:58 -0700
Subject: StackOverflowError on HashMap.hashCode() due to self reference
In-Reply-To: 
References: 
	
	
	
Message-ID: 

Hi Louis,

hanks! I thought I had seen it somewhere but I couldn't recall where.
That's exactly what I need to answer the guys who asked me for a doc
reference.

Thanks,
Kris

On Friday, July 17, 2015, Louis Wasserman  wrote:

> The Javadoc of Map already specifies:
>
> > Note: great care must be exercised if mutable objects are used as map
> keys. The behavior of a map is not specified if the value of an object is
> changed in a manner that affects equals comparisons while the object is a
> key in the map. *A special case of this prohibition is that it is not
> permissible for a map to contain itself as a key. While it is permissible
> for a map to contain itself as a value, extreme caution is advised: the **equals and hashCode methods
> are no longer well defined on such a map.*
>
> (emphasis added)
>
> On Fri, Jul 17, 2015 at 12:11 PM Krystal Mok  > wrote:
>
>> Hi Vitaly,
>>
>> I can buy that argument. It wasn't hard for me to recognize it when I saw
>> it in real world.
>>
>> But apparently whoever asked me about it couldn't wrap his head around it
>> to understand why...
>>
>> Maybe it's a case for a Pitfalls book instead of for JavaDocs.
>>
>> Thanks,
>> Kris
>>
>> On Friday, July 17, 2015, Vitaly Davidovich > 
>> > ');>> wrote:
>>
>> > IMHO, this doesn't warrant any special wording -- if someone hits this,
>> I
>> > think it's fairly evident what the issue is.  You can get the same
>> problem
>> > with adding an ArrayList to itself and calling hashCode().
>> >
>> > On Fri, Jul 17, 2015 at 2:45 PM, Krystal Mok > >
>> > wrote:
>> >
>> >> Hi everyone,
>> >>
>> >> I'm sure somebody has seen this stack overflow before. My question is:
>> is
>> >> it expected (which should be documented to warn people not to do
>> this), or
>> >> is it considered a bug (which should be fixed)?
>> >>
>> >> Example:
>> >> https://gist.github.com/rednaxelafx/930f8979473185cfc0a0
>> >>
>> >> import java.util.*;
>> >>
>> >> public class HashMapStackOverflow {
>> >>   public static void main(String[] args) throws Exception {
>> >>     HashMap map = new HashMap<>();
>> >>     map.put("self", map);
>> >>     System.out.println(map.hashCode());
>> >>   }
>> >> }
>> >>
>> >> $ ~/sdk/jdk1.8.0/Contents/Home/bin/java HashMapStackOverflow
>> >> Exception in thread "main" java.lang.StackOverflowError
>> >> at java.util.AbstractMap.hashCode(AbstractMap.java:505)
>> >> at java.util.Objects.hashCode(Objects.java:98)
>> >> at java.util.HashMap$Node.hashCode(HashMap.java:296)
>> >> at java.util.AbstractMap.hashCode(AbstractMap.java:507)
>> >> at java.util.Objects.hashCode(Objects.java:98)
>> >> at java.util.HashMap$Node.hashCode(HashMap.java:296)
>> >> at java.util.AbstractMap.hashCode(AbstractMap.java:507)
>> >> at java.util.Objects.hashCode(Objects.java:98)
>> >> at java.util.HashMap$Node.hashCode(HashMap.java:296)
>> >> at java.util.AbstractMap.hashCode(AbstractMap.java:507)
>> >> ...
>> >>
>> >> This will cause a stack overflow because HashMap.hashCode() is
>> inherited
>> >> from AbstractMap, which sums the hash code of each entry, while one of
>> the
>> >> entries is itself so it goes recursive.
>> >>
>> >> Thanks,
>> >> Kris
>> >>
>> >
>> >
>>
>


From henry.jen at oracle.com  Fri Jul 17 23:48:38 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 17 Jul 2015 16:48:38 -0700
Subject: RFR v2 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: 
References: 
	
Message-ID: 

Thanks Mandy and Magnus for looking into the patch, and feedbacks from Kumar Srinivasan and Michel Trudeau.

We have an updated version to be reviewed at,

http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v2/webrev/

This version changes the syntax a little bit as following, but pretty much still javac compatible,

1) Whitespace characters are ? ?, ?\t?. ?\n? and ?\r?, not everything from ?\0\ to ? ?.
2) Open quote still stop at EOL unless ?\? is the last character, which will join the next line by removing leading white spaces. This allows multiple line supports in quote. If leading space is significant, add ?\? to escape the white space character.
3) Escape sequences is now only limited to ?\n? and ?\r?. No octal character support.

In terms of javac compatibility, unless octal or \a\b\f\t\v escaping sequence are used, they should be completely compatible. 

I don?t have plan to remove the test as it would be convenient to have it around. Move it into a separate test is probably desirable, though. I am not sure about what is a better place, seems to me test inside implementation file is quite common as in wildcard.c and cmdtoargs.c.

Cheers,
Henry


> On Jul 15, 2015, at 7:51 AM, Mandy Chung  wrote:
> 
> 
>> On Jul 10, 2015, at 11:48 AM, Henry Jen  wrote:
>> 
>> Hi,
>> 
>> Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer.
>> 
>> Some early comment is that we probably don?t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp ?c:\\foo bar\\lib;c:\\lib? instead of -cp c:\?foo bar?\lib;c:\lib.
>> 
>> I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well.
> 
> I have a slight preference to maintain consistent syntax as javac @argfile support in terms of the quotation.  A user could use the same path specified in -cp for both javac @argfile an java @argfile use.
> 
> I skimmed on the webrev and looks okay to me.  I?ll leave it for Kumar to do detailed review.  One minor comment:
> 
> args.c
>   Are you planning to remove the test within #ifdef DEBUG_ARGFILE block?
> 
> thanks
> Mandy
> 



From konstantin.shefov at oracle.com  Mon Jul 20 11:28:07 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Mon, 20 Jul 2015 14:28:07 +0300
Subject: [9] RFR: 8130006: java/lang/invoke/MethodHandles/CatchExceptionTest
	Fails
Message-ID: <55ACDB47.1070807@oracle.com>

Hello,

Please review a test bug fix.
An exception caused by code cache overflow should be re-thrown before 
assertion check in the test.

Bug: https://bugs.openjdk.java.net/browse/JDK-8130006
Webrev: http://cr.openjdk.java.net/~kshefov/8130006/webrev.00/

-Konstantin


From fweimer at redhat.com  Mon Jul 20 12:07:04 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 20 Jul 2015 14:07:04 +0200
Subject: StackOverflowError on HashMap.hashCode() due to self reference
In-Reply-To: 
References: 
	
	
	
Message-ID: <55ACE468.5090907@redhat.com>

On 07/17/2015 09:25 PM, Louis Wasserman wrote:
> The Javadoc of Map already specifies:
> 
>> > Note: great care must be exercised if mutable objects are used as map
> keys. The behavior of a map is not specified if the value of an object is
> changed in a manner that affects equals comparisons while the object is a
> key in the map. *A special case of this prohibition is that it is not
> permissible for a map to contain itself as a key. While it is permissible
> for a map to contain itself as a value, extreme caution is advised:
> the **equals and hashCode methods
> are no longer well defined on such a map.*

The problematic entry had the self-reference in the value, not the key,
so this explanation does not really apply here.

But java.util.Collections does mention this problem:

?
Some collection operations which perform recursive traversal of the
collection may fail with an exception for self-referential instances
where the collection directly or indirectly contains itself. This
includes the clone(), equals(), hashCode() and toString() methods.
Implementations may optionally handle the self-referential scenario,
however most current implementations do not do so.
?

-- 
Florian Weimer / Red Hat Product Security


From Roger.Riggs at Oracle.com  Mon Jul 20 14:01:00 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 20 Jul 2015 10:01:00 -0400
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: 
References: 
Message-ID: <55ACFF1C.4020003@Oracle.com>

Hi Volker,

yes, generally, the approach is an improvement and provides a clearer
model of os specific variations.

More comments inline...

On 7/17/2015 2:28 PM, Volker Simonis wrote:
> Hi,
>
> I worked on refactoring the native ProcessHandleImpl implementation to
> enable more code sharing and make it easier to add support for new
> platforms (e.g. AIX) and I think I had a pretty nice version running. But
> unfortunately I've just realized that the recent changes to
> ProcessHandleImpl (i.e. "8078099: (process) ProcessHandle should uniquely
> identify processes" and "8078108: (process) ProcessHandle.isAlive should be
> robust") have been massive so I have to start over to merge all my changes
> with the new version.
>
> But before doing that I just wanted to post my current changes which
> cleanly apply to the repo before 8078099 and ask for your opinion:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v1/
>
> Here's a summary (taken from ProcesHandleImpl_unix.c) of what I've actually
> done (if the output appears scrambled in you mail better read it in the
> webrev
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v1/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c.udiff.html
> ):
>
> /**
>   * This file contains the implementation of the native ProcessHandleImpl
>   * functions which are common to all Unix variants.
>   *
>   * The currently supported Unix variants are Solaris, Linux, MaxOS X and
> AIX.
>   * The various similarities and differences between these systems make it
> hard
>   * to find a clear boundary between platform specific and shared code.
>   *
>   * In order to ease code sharing between the pltforms while still keeping
> the
>   * code as clean as possible (i.e. free of preprocessor macros) we use the
>   * following source code layout (remember that ProcessHandleImpl_unix.c will
>   * be compiled on EVERY Unix platform while ProcessHandleImpl_.c will be
>   * only compiled on the specific OS):
>   *
>   * - all the JNI wrappers for the ProcessHandleImpl functions go into this
> file
>   * - if their implementation is common on ALL the supported Unix platforms
> it
>   *   goes right into the JNI wrappers
>   * - if the whole function or substantial parts are platform dependent, the
>   *   implementation goes into os_ functions in
>   *   ProcessHandleImpl_.c
>   * - if at least two platforms implement an os_ function in
> the
>   *   same way, this implementation is factored out into
> unix_,
>   *   placed into this file and called from the corresponding
> os_
>   *   function.
>   * - For convenience, all the os_ and unix_ functions are declared in
>   *   ProcessHandleImpl_unix.h which is included into every
>   *   ProcessHandleImpl_.c file.
>   *
>   * Example 1:
>   * ----------
>   * The implementation of
> Java_java_lang_ProcessHandleImpl_00024Info_initIDs()
>   * is the same on all platforms except on Linux where it initilizes one
>   * additional field. So we place the implementation right into
>   * Java_java_lang_ProcessHandleImpl_00024Info_initIDs() but add call to
>   * os_init() at the end of the function which is empty on all platforms
>   * except Linux where it performs the additionally initializations.
>   *
>   * Example 2:
>   * ----------
>   * The implementation of Java_java_lang_ProcessHandleImpl_00024Info_info0 is
>   * the same on Solaris and AIX but different on Linux and MacOSX. We
> therefore
>   * simply call the two helpers os_getStatInfo() and os_getCmdlineInfo(). The
>   * Linux and MaxOS X versions of these functions (in the corresponding files
>   * ProcessHandleImpl_linux.c and ProcessHandleImpl_macosx.c) directly
> contain
>   * the platform specific implementations while the Solaris and AIX
>   * implementations simply call back to unix_getStatInfo() and
>   * unix_getCmdlineInfo() which are implemented right in this file.
>   *
>   * The term "same implementation" is still a question of interpretation. It
> my
>   * be acceptable to have a few ifdef'ed lines if that allows the sharing of
> a
>   * huge function. On the other hand, if the platform specific code in a
> shared
>   * function grows over a certain limit, it may be better to refactor that
>   * functionality into corresponding, platform-specific os_ functions.
>   */
>
> This resulted in the new file ProcessHandleImpl_linux.c which now only
> contains Linux-only code which was previously in ifdefed for Linux in
> ProcessHandleImpl_linux.c. The advantage is that we now have only one
> version of:
>
>   Java_java_lang_ProcessHandleImpl_00024Info_initIDs
>   unix_fillArgArray
>   unix_uidToUser
>
> and on version of
>
>   unix_getChildren
>
> which is shared by Solaris, Linux and AIX and one version of
>
>   unix_getStatInfo
>   unix_getCmdlineInfo
>
> which are shared by Solaris and Linux.
>
> Additionally I've added the AIX port following the new schema and I've
> slightly improved the Solaris port to use the information from
> psinfo.pr_psargs for reporting at least the first 80 characters of the
> command line arguments. arg[0] from psinfo.pr_psargs is also used as the
> "command()" string in the case where "/proc/%d/path/a.out" isn't readable.
> This helps to report a command string for all the processes we do not own,
> because in that case, "/proc/%d/path/a.out" isn't readable. By the way,
> using args[0] as a fall-back for cmd beeing null also helps on MacOS X for
> processes we don't own. Finally I've also done some test improvements.
My bias was toward omitting information that was incomplete or not 
usable programatically.
If the commandline is truncated then it is pretty useless to a program, 
the same with
the executable command.  If the application has to try to guess what's 
missing and how
to use what is present then it should be omitted from the API.  If there 
is a user present
then they can use 'ps' or 'tasklist' and interpret the partial information.

The focus should be on an API that can be used to control/manage a set 
of applications
the run together, usually under the same userid or with root privileges.

Comments on the diffs:

ProcessHandle.java:
  - The notes should probably be use @implNote  (though I disagree with 
providing truncated information)


ProcessHandleImpl_unix:
  - I would not have expected to find the Solaris and AIX 
implementations of getStatInfo
and getCmdlineInfo here; but perhaps it depends on how one considers the 
lineage of the real unix.
   Since the more common platforms are Linux, Redhat, etc I would keep 
those versions in the
   ProcessHandleImpl_unix common file.

Thanks, Roger



>
> I have tested all my changes on Linux/amd64, Linux/ppc64, MacOS X, Solaris
> and AIX.
>
> I'd be happy to forward port my changes to the newest head version if you
> generally agree with my approach (and give me a short time frame where you
> promise not to do any massive changes :)
>
> What do you think?
>
> Thank you and best regards,
> Volker



From volker.simonis at gmail.com  Mon Jul 20 14:46:56 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 20 Jul 2015 16:46:56 +0200
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: <55ACFF1C.4020003@Oracle.com>
References: 
	<55ACFF1C.4020003@Oracle.com>
Message-ID: 

Hi Roger,

thanks for looking at the webrev. Please find my comments inline:

On Mon, Jul 20, 2015 at 4:01 PM, Roger Riggs  wrote:
> Hi Volker,
>
> yes, generally, the approach is an improvement and provides a clearer
> model of os specific variations.
>
> More comments inline...
>
>
> On 7/17/2015 2:28 PM, Volker Simonis wrote:
>>
>> Hi,
>>
>> I worked on refactoring the native ProcessHandleImpl implementation to
>> enable more code sharing and make it easier to add support for new
>> platforms (e.g. AIX) and I think I had a pretty nice version running. But
>> unfortunately I've just realized that the recent changes to
>> ProcessHandleImpl (i.e. "8078099: (process) ProcessHandle should uniquely
>> identify processes" and "8078108: (process) ProcessHandle.isAlive should
>> be
>> robust") have been massive so I have to start over to merge all my changes
>> with the new version.
>>
>> But before doing that I just wanted to post my current changes which
>> cleanly apply to the repo before 8078099 and ask for your opinion:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v1/
>>
>> Here's a summary (taken from ProcesHandleImpl_unix.c) of what I've
>> actually
>> done (if the output appears scrambled in you mail better read it in the
>> webrev
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v1/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c.udiff.html
>> ):
>>
>> /**
>>   * This file contains the implementation of the native ProcessHandleImpl
>>   * functions which are common to all Unix variants.
>>   *
>>   * The currently supported Unix variants are Solaris, Linux, MaxOS X and
>> AIX.
>>   * The various similarities and differences between these systems make it
>> hard
>>   * to find a clear boundary between platform specific and shared code.
>>   *
>>   * In order to ease code sharing between the pltforms while still keeping
>> the
>>   * code as clean as possible (i.e. free of preprocessor macros) we use
>> the
>>   * following source code layout (remember that ProcessHandleImpl_unix.c
>> will
>>   * be compiled on EVERY Unix platform while ProcessHandleImpl_.c will
>> be
>>   * only compiled on the specific OS):
>>   *
>>   * - all the JNI wrappers for the ProcessHandleImpl functions go into
>> this
>> file
>>   * - if their implementation is common on ALL the supported Unix
>> platforms
>> it
>>   *   goes right into the JNI wrappers
>>   * - if the whole function or substantial parts are platform dependent,
>> the
>>   *   implementation goes into os_ functions in
>>   *   ProcessHandleImpl_.c
>>   * - if at least two platforms implement an os_ function
>> in
>> the
>>   *   same way, this implementation is factored out into
>> unix_,
>>   *   placed into this file and called from the corresponding
>> os_
>>   *   function.
>>   * - For convenience, all the os_ and unix_ functions are declared in
>>   *   ProcessHandleImpl_unix.h which is included into every
>>   *   ProcessHandleImpl_.c file.
>>   *
>>   * Example 1:
>>   * ----------
>>   * The implementation of
>> Java_java_lang_ProcessHandleImpl_00024Info_initIDs()
>>   * is the same on all platforms except on Linux where it initilizes one
>>   * additional field. So we place the implementation right into
>>   * Java_java_lang_ProcessHandleImpl_00024Info_initIDs() but add call to
>>   * os_init() at the end of the function which is empty on all platforms
>>   * except Linux where it performs the additionally initializations.
>>   *
>>   * Example 2:
>>   * ----------
>>   * The implementation of Java_java_lang_ProcessHandleImpl_00024Info_info0
>> is
>>   * the same on Solaris and AIX but different on Linux and MacOSX. We
>> therefore
>>   * simply call the two helpers os_getStatInfo() and os_getCmdlineInfo().
>> The
>>   * Linux and MaxOS X versions of these functions (in the corresponding
>> files
>>   * ProcessHandleImpl_linux.c and ProcessHandleImpl_macosx.c) directly
>> contain
>>   * the platform specific implementations while the Solaris and AIX
>>   * implementations simply call back to unix_getStatInfo() and
>>   * unix_getCmdlineInfo() which are implemented right in this file.
>>   *
>>   * The term "same implementation" is still a question of interpretation.
>> It
>> my
>>   * be acceptable to have a few ifdef'ed lines if that allows the sharing
>> of
>> a
>>   * huge function. On the other hand, if the platform specific code in a
>> shared
>>   * function grows over a certain limit, it may be better to refactor that
>>   * functionality into corresponding, platform-specific os_ functions.
>>   */
>>
>> This resulted in the new file ProcessHandleImpl_linux.c which now only
>> contains Linux-only code which was previously in ifdefed for Linux in
>> ProcessHandleImpl_linux.c. The advantage is that we now have only one
>> version of:
>>
>>   Java_java_lang_ProcessHandleImpl_00024Info_initIDs
>>   unix_fillArgArray
>>   unix_uidToUser
>>
>> and on version of
>>
>>   unix_getChildren
>>
>> which is shared by Solaris, Linux and AIX and one version of
>>
>>   unix_getStatInfo
>>   unix_getCmdlineInfo
>>
>> which are shared by Solaris and Linux.
>>
>> Additionally I've added the AIX port following the new schema and I've
>> slightly improved the Solaris port to use the information from
>> psinfo.pr_psargs for reporting at least the first 80 characters of the
>> command line arguments. arg[0] from psinfo.pr_psargs is also used as the
>> "command()" string in the case where "/proc/%d/path/a.out" isn't readable.
>> This helps to report a command string for all the processes we do not own,
>> because in that case, "/proc/%d/path/a.out" isn't readable. By the way,
>> using args[0] as a fall-back for cmd beeing null also helps on MacOS X for
>> processes we don't own. Finally I've also done some test improvements.
>
> My bias was toward omitting information that was incomplete or not usable
> programatically.
> If the commandline is truncated then it is pretty useless to a program, the
> same with
> the executable command.  If the application has to try to guess what's
> missing and how
> to use what is present then it should be omitted from the API.  If there is
> a user present
> then they can use 'ps' or 'tasklist' and interpret the partial information.
>

But 'ps' is limited to 80 characters for arguments and command line as
well on Solaris as far as I know. Moreover, on AIX I haven't found
something better than this for the command line at all. Anyway we have
to live with the fact that this information is extremely platform
dependent. The least common divisor is surely the PID but for this API
I prefer to expose "as much as possible" for a given platform.

I suspect that once this API is out there in the world, people will
use it for all kind of stuff like monitoring or logging and I'd rather
prefer to see a truncated command line in a log file instad of just
seeing a plain PID. So usefull/useless depends pretty much on the use
case :)

> The focus should be on an API that can be used to control/manage a set of
> applications
> the run together, usually under the same userid or with root privileges.
>
> Comments on the diffs:
>
> ProcessHandle.java:
>  - The notes should probably be use @implNote  (though I disagree with
> providing truncated information)
>

Didn't knew that one but I'll use it. Thanks for the hint.
>
> ProcessHandleImpl_unix:
>  - I would not have expected to find the Solaris and AIX implementations of
> getStatInfo
> and getCmdlineInfo here; but perhaps it depends on how one considers the
> lineage of the real unix.
>   Since the more common platforms are Linux, Redhat, etc I would keep those
> versions in the
>   ProcessHandleImpl_unix common file.
>

As I wrote in the summary - I don't think the _unix file should
contain the implementations of the most prominent Unix platform but
rather the implementations shared between most platforms. If a
function implementation is only being used on Linux I think it is
reasonable to put it into a _linux file.

A while ago we discussed if the 'unix' directory should be named
'unix' or 'posix' or whatsoever and ended up with 'unix'. I think
that's a good decision because it honours the fact that there is no
single, true, genuine Unix variant. The 'unix' directory is a
pragmatic approach to share "common" Unix code with "common" in the
sense of "supported by at least two or more Unix variants". At least
that was my understanding.

I'll start to merge in your new changes into my schema and post a new
webrev once I'm done.

Thanks once again for your comments,
Volker

> Thanks, Roger
>
>
>
>
>>
>> I have tested all my changes on Linux/amd64, Linux/ppc64, MacOS X, Solaris
>> and AIX.
>>
>> I'd be happy to forward port my changes to the newest head version if you
>> generally agree with my approach (and give me a short time frame where you
>> promise not to do any massive changes :)
>>
>> What do you think?
>>
>> Thank you and best regards,
>> Volker
>
>


From Roger.Riggs at Oracle.com  Mon Jul 20 14:56:42 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 20 Jul 2015 10:56:42 -0400
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: 
References: 
	<55ACFF1C.4020003@Oracle.com>
	
Message-ID: <55AD0C2A.4050505@Oracle.com>

Hi Volker,

yes, press ahead.

On the _unix topic, I think the most platforms depends on when/how/what 
you count.
I was following the prior pattern that counted OS X as being mostly 
common with Linux
and Oracle Linux as a Redhat derivative.  That counts at least as 2 I think.

I'd be interested in other folks views on the usefulness of 
partial/truncated info from the API.
If the values are so weak they are only useful for logging then that's 
not good enough.

Perhaps the truncated information should be presented from a different 
method
from ProcessHandle.Info object to be able to reflect its poor quality.

Thanks, Roger


On 7/20/2015 10:46 AM, Volker Simonis wrote:
> Hi Roger,
>
> thanks for looking at the webrev. Please find my comments inline:
>
> On Mon, Jul 20, 2015 at 4:01 PM, Roger Riggs  wrote:
>> Hi Volker,
>>
>> yes, generally, the approach is an improvement and provides a clearer
>> model of os specific variations.
>>
>> More comments inline...
>>
>>
>> On 7/17/2015 2:28 PM, Volker Simonis wrote:
>>> Hi,
>>>
>>> I worked on refactoring the native ProcessHandleImpl implementation to
>>> enable more code sharing and make it easier to add support for new
>>> platforms (e.g. AIX) and I think I had a pretty nice version running. But
>>> unfortunately I've just realized that the recent changes to
>>> ProcessHandleImpl (i.e. "8078099: (process) ProcessHandle should uniquely
>>> identify processes" and "8078108: (process) ProcessHandle.isAlive should
>>> be
>>> robust") have been massive so I have to start over to merge all my changes
>>> with the new version.
>>>
>>> But before doing that I just wanted to post my current changes which
>>> cleanly apply to the repo before 8078099 and ask for your opinion:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v1/
>>>
>>> Here's a summary (taken from ProcesHandleImpl_unix.c) of what I've
>>> actually
>>> done (if the output appears scrambled in you mail better read it in the
>>> webrev
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v1/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c.udiff.html
>>> ):
>>>
>>> /**
>>>    * This file contains the implementation of the native ProcessHandleImpl
>>>    * functions which are common to all Unix variants.
>>>    *
>>>    * The currently supported Unix variants are Solaris, Linux, MaxOS X and
>>> AIX.
>>>    * The various similarities and differences between these systems make it
>>> hard
>>>    * to find a clear boundary between platform specific and shared code.
>>>    *
>>>    * In order to ease code sharing between the pltforms while still keeping
>>> the
>>>    * code as clean as possible (i.e. free of preprocessor macros) we use
>>> the
>>>    * following source code layout (remember that ProcessHandleImpl_unix.c
>>> will
>>>    * be compiled on EVERY Unix platform while ProcessHandleImpl_.c will
>>> be
>>>    * only compiled on the specific OS):
>>>    *
>>>    * - all the JNI wrappers for the ProcessHandleImpl functions go into
>>> this
>>> file
>>>    * - if their implementation is common on ALL the supported Unix
>>> platforms
>>> it
>>>    *   goes right into the JNI wrappers
>>>    * - if the whole function or substantial parts are platform dependent,
>>> the
>>>    *   implementation goes into os_ functions in
>>>    *   ProcessHandleImpl_.c
>>>    * - if at least two platforms implement an os_ function
>>> in
>>> the
>>>    *   same way, this implementation is factored out into
>>> unix_,
>>>    *   placed into this file and called from the corresponding
>>> os_
>>>    *   function.
>>>    * - For convenience, all the os_ and unix_ functions are declared in
>>>    *   ProcessHandleImpl_unix.h which is included into every
>>>    *   ProcessHandleImpl_.c file.
>>>    *
>>>    * Example 1:
>>>    * ----------
>>>    * The implementation of
>>> Java_java_lang_ProcessHandleImpl_00024Info_initIDs()
>>>    * is the same on all platforms except on Linux where it initilizes one
>>>    * additional field. So we place the implementation right into
>>>    * Java_java_lang_ProcessHandleImpl_00024Info_initIDs() but add call to
>>>    * os_init() at the end of the function which is empty on all platforms
>>>    * except Linux where it performs the additionally initializations.
>>>    *
>>>    * Example 2:
>>>    * ----------
>>>    * The implementation of Java_java_lang_ProcessHandleImpl_00024Info_info0
>>> is
>>>    * the same on Solaris and AIX but different on Linux and MacOSX. We
>>> therefore
>>>    * simply call the two helpers os_getStatInfo() and os_getCmdlineInfo().
>>> The
>>>    * Linux and MaxOS X versions of these functions (in the corresponding
>>> files
>>>    * ProcessHandleImpl_linux.c and ProcessHandleImpl_macosx.c) directly
>>> contain
>>>    * the platform specific implementations while the Solaris and AIX
>>>    * implementations simply call back to unix_getStatInfo() and
>>>    * unix_getCmdlineInfo() which are implemented right in this file.
>>>    *
>>>    * The term "same implementation" is still a question of interpretation.
>>> It
>>> my
>>>    * be acceptable to have a few ifdef'ed lines if that allows the sharing
>>> of
>>> a
>>>    * huge function. On the other hand, if the platform specific code in a
>>> shared
>>>    * function grows over a certain limit, it may be better to refactor that
>>>    * functionality into corresponding, platform-specific os_ functions.
>>>    */
>>>
>>> This resulted in the new file ProcessHandleImpl_linux.c which now only
>>> contains Linux-only code which was previously in ifdefed for Linux in
>>> ProcessHandleImpl_linux.c. The advantage is that we now have only one
>>> version of:
>>>
>>>    Java_java_lang_ProcessHandleImpl_00024Info_initIDs
>>>    unix_fillArgArray
>>>    unix_uidToUser
>>>
>>> and on version of
>>>
>>>    unix_getChildren
>>>
>>> which is shared by Solaris, Linux and AIX and one version of
>>>
>>>    unix_getStatInfo
>>>    unix_getCmdlineInfo
>>>
>>> which are shared by Solaris and Linux.
>>>
>>> Additionally I've added the AIX port following the new schema and I've
>>> slightly improved the Solaris port to use the information from
>>> psinfo.pr_psargs for reporting at least the first 80 characters of the
>>> command line arguments. arg[0] from psinfo.pr_psargs is also used as the
>>> "command()" string in the case where "/proc/%d/path/a.out" isn't readable.
>>> This helps to report a command string for all the processes we do not own,
>>> because in that case, "/proc/%d/path/a.out" isn't readable. By the way,
>>> using args[0] as a fall-back for cmd beeing null also helps on MacOS X for
>>> processes we don't own. Finally I've also done some test improvements.
>> My bias was toward omitting information that was incomplete or not usable
>> programatically.
>> If the commandline is truncated then it is pretty useless to a program, the
>> same with
>> the executable command.  If the application has to try to guess what's
>> missing and how
>> to use what is present then it should be omitted from the API.  If there is
>> a user present
>> then they can use 'ps' or 'tasklist' and interpret the partial information.
>>
> But 'ps' is limited to 80 characters for arguments and command line as
> well on Solaris as far as I know. Moreover, on AIX I haven't found
> something better than this for the command line at all. Anyway we have
> to live with the fact that this information is extremely platform
> dependent. The least common divisor is surely the PID but for this API
> I prefer to expose "as much as possible" for a given platform.
>
> I suspect that once this API is out there in the world, people will
> use it for all kind of stuff like monitoring or logging and I'd rather
> prefer to see a truncated command line in a log file instad of just
> seeing a plain PID. So usefull/useless depends pretty much on the use
> case :)
>
>> The focus should be on an API that can be used to control/manage a set of
>> applications
>> the run together, usually under the same userid or with root privileges.
>>
>> Comments on the diffs:
>>
>> ProcessHandle.java:
>>   - The notes should probably be use @implNote  (though I disagree with
>> providing truncated information)
>>
> Didn't knew that one but I'll use it. Thanks for the hint.
>> ProcessHandleImpl_unix:
>>   - I would not have expected to find the Solaris and AIX implementations of
>> getStatInfo
>> and getCmdlineInfo here; but perhaps it depends on how one considers the
>> lineage of the real unix.
>>    Since the more common platforms are Linux, Redhat, etc I would keep those
>> versions in the
>>    ProcessHandleImpl_unix common file.
>>
> As I wrote in the summary - I don't think the _unix file should
> contain the implementations of the most prominent Unix platform but
> rather the implementations shared between most platforms. If a
> function implementation is only being used on Linux I think it is
> reasonable to put it into a _linux file.
>
> A while ago we discussed if the 'unix' directory should be named
> 'unix' or 'posix' or whatsoever and ended up with 'unix'. I think
> that's a good decision because it honours the fact that there is no
> single, true, genuine Unix variant. The 'unix' directory is a
> pragmatic approach to share "common" Unix code with "common" in the
> sense of "supported by at least two or more Unix variants". At least
> that was my understanding.
>
> I'll start to merge in your new changes into my schema and post a new
> webrev once I'm done.
>
> Thanks once again for your comments,
> Volker
>
>> Thanks, Roger
>>
>>
>>
>>
>>> I have tested all my changes on Linux/amd64, Linux/ppc64, MacOS X, Solaris
>>> and AIX.
>>>
>>> I'd be happy to forward port my changes to the newest head version if you
>>> generally agree with my approach (and give me a short time frame where you
>>> promise not to do any massive changes :)
>>>
>>> What do you think?
>>>
>>> Thank you and best regards,
>>> Volker
>>



From forax at univ-mlv.fr  Mon Jul 20 17:08:58 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 20 Jul 2015 19:08:58 +0200
Subject: Stream.generate
Message-ID: <55AD2B2A.9070507@univ-mlv.fr>

Hi all, hi Paul,
I've found that the signature of Stream.generate doesn't to use a 
wildcard hence some program are rejected even if there are valid, by 
example:
   public static void main(String[] args) {
       Supplier supplier = () -> "hello";
       Stream s = Stream.generate(supplier);
   }

The fix is simple, in interface Stream, generate should be declared like 
this :
   public static Stream generate(Supplier s)
and
  the field 's' of the InfiniteSupplyingSpliterator.OfRef should be also 
declared as a Supplier.

regards,
R?mi




From Kirk.Shoop at microsoft.com  Mon Jul 20 17:22:53 2015
From: Kirk.Shoop at microsoft.com (Kirk Shoop)
Date: Mon, 20 Jul 2015 17:22:53 +0000
Subject: RFR 8124977 cmdline encoding challenges on Windows
In-Reply-To: <55A16577.8050302@oracle.com>
References: 
	
	<558C017A.2020708@oracle.com>
	
	<55A16577.8050302@oracle.com>
Message-ID: 

Hi,

(1)
Yes, the changes don't update the underlying console encoding. There is guidance that apps should not change the console encoding as it would affect other commands in the same console. A script must explicitly use chcp to change the codepage.

The change has a new option "file.encoding.unicode" to avoid changing the existing ones: "file.encoding" and "sun.jnu.encoding"; as they are used in several places and touching them could break backward compatibility.

The two system properties: "file.encoding" and "sun.jnu.encoding" are set by getEncodingInternal(). Then, during initialization file.encoding is set with the value of sun.jnu.encoding, so the two properties have the same value.

These properties are used to set the default charset for:
*	"platform strings" encoding
*	output streams (encoding of System.out is initialized by this default charset)
*	replacing of unsafe symbols on URL
*	ftp client
*	network client
Any Java application could rely on these properties as well.

On OSX and Linux both these properties are set according to currently active locale, while on Windows they are filled with system default locale.

This behavior could be observed with this simple test:

main.java:
class Main {
    public static void main(String[] args) throws Exception {
        System.out.println("file.encoding=" + System.getProperty("file.encoding"));
        System.out.println("sun.jnu.encoding=" + System.getProperty("sun.jnu.encoding"));
    }
}

Linux test:
$ sudo localedef -c -i ru_RU -f CP1251 ru_RU.CP1251

$ javac main.java

$ java Main
file.encoding=UTF-8
sun.jnu.encoding=UTF-8

$ export LC_ALL=ru_RU.cp1251

$ java Main
file.encoding=CP1251
sun.jnu.encoding=CP1251

Windows test:
>javac main.java

>java Main
file.encoding=Cp1252
sun.jnu.encoding=Cp1252

>chcp 65001
Active code page: 65001

>java Main
file.encoding=Cp1252
sun.jnu.encoding=Cp1252


So when default system locale differs from the active one, we have different behavior on Linux and Windows. The new options allow a windows user to select the same behavior that one would expect on unix. The switches can certainly be removed, if the compatibility impact is acceptable.

(2)
The defaultUnicodeCharset() method because it is called from java.io.Console() constructor as well as from LauncherHelper. So its scope should be wider than just LauncherHelper.java.

Kirk and Valery

> -----Original Message-----
> From: Xueming Shen [mailto:xueming.shen at oracle.com]
> Sent: Saturday, July 11, 2015 11:51 AM
> 
> Hi Kirk,
> 
> Two questions
> 
> (1) Why do you need to change the "encoding" used by the java.io.Console class. My understanding
>       is that the console encoding is specifically used to "talk" to the underlying terminal, it should just
>       be the one used by the underlying terminal/console. I don't think the proposed change updates
>       the underlying console encoding (something like chcp)  when -Dwindows.UnicodeConsole=true
>       specified, if I read the webrev correctly. Instead, the Java_java_io_Console_encoding() probably
>       need to be updated to return utf8 if the cp == 65001, so if the underlying terminal/console is
>       using cp65001, the java.io.Console should encode/decode in utf8.
>       I would assume the encoding of java.io.Condole should have nothing to do with using
>       GetCommandLIneW() to parse the arguments in unicode in launcher?
> 
> (2) Why do you need a defaultUnicodeCharset() in Charset class? Seems to me the scope should/could
>       be limited inside LauncherHelper.java?
> 
> Thanks,
> -Sherman
> 
> 


From Kirk.Shoop at microsoft.com  Mon Jul 20 17:37:09 2015
From: Kirk.Shoop at microsoft.com (Kirk Shoop)
Date: Mon, 20 Jul 2015 17:37:09 +0000
Subject: RFR 8124977 cmdline encoding challenges on Windows
In-Reply-To: <55A50FA7.6020806@oracle.com>
References: 
	
	<558C017A.2020708@oracle.com>
	
	<55A50FA7.6020806@oracle.com>
Message-ID: 

Hi,

The switches were introduced to prevent compatibility impact for existing usage on Windows. If the impact is acceptable then the next webrev will remove both of them and instead change the default behavior on windows to read the commandline in Unicode and to output UTF-8 to a console that has chcp 65001.

How should this JLI_MemFree() call be protected? It seems that the only possible way to leak memory here is abnormal program termination.
Do we have any ways to call JLI_MemFree in that case? There appears to be other places where JLI_MemFree is used in a similar way, a pointer to an example of correct usage would be helpful.

Yes, JLI_StrCaseCmp will be used instead.

Yes, the 'UnicodeCmdVerifier' approach had already been tried, but if the Java test class executes itself an exception occurs in TestHelper:
  java.lang.Error: property test.classes not defined ??
        at TestHelper.(TestHelper.java:117)
  Exception in thread "main"

I tried your code as well and get the same exception. I did not find an existing test calling itself, however there are a lot of tests that call or compile+call other classes.
So it seems we need two files, the caller class and the calling one, and if so is it ok to leave the test as is: shell script + Java class? It appears easier to read and modify.

Kirk and Valery

> -----Original Message-----
> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
> Sent: Tuesday, July 14, 2015 6:33 AM
> To: Kirk Shoop
> Cc: core-libs-dev Libs; Valery Kopylov (Akvelon); Martin Sawicki;
> SHEN,XUEMING; Henry Jen
> Subject: Re: RFR 8124977 cmdline encoding challenges on Windows
> 
> Hi Kirk,
> 
> I took another pass over the changes.
> 
> IMHO, we need to make it easier for people to use this feature, and
> eliminate these two, atleast externally.
> 
> "-Dwindows.UnicodeConsole=true",
> "-Dfile.encoding.unicode=\"UTF-8\"",
> 
> Can we invent a new command line arg ? we can make it an -X flag, by
> inspecting the args, we can set the two properties, preferably one ? and also
> make the decision to use Wide character translations etc.
> 
> 1. java_md.c
> 
> a.> + ConvertWinArgsToCommonFormat(cmdLineUtf8, pargc, pargv); +
> JLI_MemFree(cmdLineUtf8); The free may not happen under error
> conditions, though we return immediately memory checking tools are likely
> to complain about memory leak.
> b.>
> 
> +        if (stricmp(arg, "-Dwindows.UnicodeConsole=true") == 0) {
> For consistency sake there there is a wrapper for this.
> 69 #define JLI_StrCaseCmp(p1, p2)          stricmp((p1), (p2))
> 
> 
> As for the test you can delete the shell test and all you need is the following,
> I have not tested it, but it should work.
> #####################
> UnicodeCmdVerifier.java
> #####################
> 
> 
> /*
> * @test
> * @bug 8124977
> * @summary ensures that the command line argument, passed as Unicode,
> * matches the desired value.
> * @compile -XDignore.symbol.file UnicodeCmdVerifier.java
> * @run main UnicodeCmdVerifier
> */
> public class UnicodeCmdVerifier extends TestHelper { public static void
> main(String[] args) { if (!isWindows) { // test is applicable only on Windows
> return; } if (args != null && args.length > 0) { String desired = new
> String("\u042e\u043d\u0438\u043a\u043e\u0434");
> if (args[1].equals(desired)) {
> System.out.println("The argument matches the desired text: " + args[0]);
> return; } else { throw new Error("The argument does not match the desired
> text: "
> + args[0] + " != " + desired);
> }
> return;
> }
> TestResult tr = doExec(javaCmd,
> "-cp", TEST_CLASSES_DIR.getAbsolutePath(),
> "-Dwindows.UnicodeConsole=true",
> "-Dfile.encoding.unicode=\"UTF-8\"",
> "UnicodeCmdVerifier", "testme", "??????"); if (!tr.isOK()) { throw new
> Error("test failed with a non-zero exit"); } } }
> 
> 
> Thanks
> Kumar
> 


From xueming.shen at oracle.com  Mon Jul 20 18:50:21 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 20 Jul 2015 11:50:21 -0700
Subject: RFR 8124977 cmdline encoding challenges on Windows
In-Reply-To: 
References: 
	
	<558C017A.2020708@oracle.com>
	
	<55A16577.8050302@oracle.com>
	
Message-ID: <55AD42ED.3040102@oracle.com>

On 07/20/2015 10:22 AM, Kirk Shoop wrote:
>
>
> So when default system locale differs from the active one, we have different behavior on Linux and Windows. The new options allow a windows user to select the same behavior that one would expect on unix. The switches can certainly be removed, if the compatibility impact is acceptable.

Kirk, on Windows file.encoding is from the user locale and the sun.jnu.encoding is from
the system locale setting. sun.jnu.encoding is purely for those text encoding sensitive
jnu functiond to communicate with the underlying windows system api, when the system
locale and the user locale are set to different value. On unix/linux/osx, these two are
always set to the same value. Yes, they might be input/output issue if the encoding used
by the console (oem codepage) is not compatible with the encoding used by the "user locale"
and you are trying to use System.in/out/err for the input/output to the console.

Here is the original CCC request regarding the sun.jnu.encoding, which might provide
some background info.

http://cr.openjdk.java.net/~sherman/4958170.html

If you/we are NOT going to change the encoding used by the underlying console, I don't
think we need/should change the "encoding" used by the java.io.Console. As I suggested
in my previously email, the Java_java_io_Console_encoding() implementation probably
need to update to return utf8 if the cp == 65001 (that was 10 years ago, I'm not sure if
the 65001 was really used back then when we wrote this code).  My understanding of
the issue here is that if you continue to use the "A" version of the API to parse/get the
arguments, and try to solve the possible issue triggered by the "incompatibility" of the
oem encoding used by the console and the user locale encoding used by the System.in/
out/err, it's fine to define a new system property to specify a preferred encoding for the
launcher to use, but this "preferred" encoding should not be used by java.io.Console.
But isn't it more reasonable to simply always use the "W" version for this purpose in
launcher?

-Sherman

> (2)
> The defaultUnicodeCharset() method because it is called from java.io.Console() constructor as well as from LauncherHelper. So its scope should be wider than just LauncherHelper.java.
>
> Kirk and Valery
>
>> -----Original Message-----
>> From: Xueming Shen [mailto:xueming.shen at oracle.com]
>> Sent: Saturday, July 11, 2015 11:51 AM
>>
>> Hi Kirk,
>>
>> Two questions
>>
>> (1) Why do you need to change the "encoding" used by the java.io.Console class. My understanding
>>        is that the console encoding is specifically used to "talk" to the underlying terminal, it should just
>>        be the one used by the underlying terminal/console. I don't think the proposed change updates
>>        the underlying console encoding (something like chcp)  when -Dwindows.UnicodeConsole=true
>>        specified, if I read the webrev correctly. Instead, the Java_java_io_Console_encoding() probably
>>        need to be updated to return utf8 if the cp == 65001, so if the underlying terminal/console is
>>        using cp65001, the java.io.Console should encode/decode in utf8.
>>        I would assume the encoding of java.io.Condole should have nothing to do with using
>>        GetCommandLIneW() to parse the arguments in unicode in launcher?
>>
>> (2) Why do you need a defaultUnicodeCharset() in Charset class? Seems to me the scope should/could
>>        be limited inside LauncherHelper.java?
>>
>> Thanks,
>> -Sherman
>>
>>



From joe.darcy at oracle.com  Mon Jul 20 21:15:24 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 20 Jul 2015 14:15:24 -0700
Subject: JDK 9 RFR of JDK-8081734 :
	ConcurrentHashMap/ConcurrentAssociateTest.java, times out 90% of time on
	sparc with 256 cpu.
Message-ID: <55AD64EC.2090909@oracle.com>

Hello,

Please review a small change to adders

     JDK-8081734 : ConcurrentHashMap/ConcurrentAssociateTest.java, times 
out 90% of time on sparc with 256 cpu.
     http://cr.openjdk.java.net/~darcy/8081734.0/

Patch below.

Some background, when run on large machines, 256 processors/threads, 
this test takes many minutes to run due to hitting some degenerate 
conditions. Bounding the concurrency to 32 serves the purposes of 
checking for the conditions the test was written for while also allowing 
a reasonable execution time for a single test.

Thanks,

-Joe

--- 
old/test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java 
2015-07-20 14:08:23.839018642 -0700
+++ 
new/test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java 
2015-07-20 14:08:23.679018638 -0700
@@ -120,7 +120,8 @@
              }
          };

-        int ps = Runtime.getRuntime().availableProcessors();
+        // Bound concurrency to avoid degenerate performance
+        int ps = Math.min(Runtime.getRuntime().availableProcessors(), 32);
          Stream runners = IntStream.range(0, ps)
                  .mapToObj(i -> sr.get())
                  .map(CompletableFuture::runAsync);



From chris.hegarty at oracle.com  Mon Jul 20 21:22:52 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 20 Jul 2015 22:22:52 +0100
Subject: JDK 9 RFR of JDK-8081734 :
	ConcurrentHashMap/ConcurrentAssociateTest.java,
	times out 90% of time on sparc with 256 cpu.
In-Reply-To: <55AD64EC.2090909@oracle.com>
References: <55AD64EC.2090909@oracle.com>
Message-ID: <0EEF19D7-3F79-4F57-9273-AC3019CF0BC3@oracle.com>

This seems reasonable to me Joe.

-Chris.

> On 20 Jul 2015, at 22:15, joe darcy  wrote:
> 
> Hello,
> 
> Please review a small change to adders
> 
>    JDK-8081734 : ConcurrentHashMap/ConcurrentAssociateTest.java, times out 90% of time on sparc with 256 cpu.
>    http://cr.openjdk.java.net/~darcy/8081734.0/
> 
> Patch below.
> 
> Some background, when run on large machines, 256 processors/threads, this test takes many minutes to run due to hitting some degenerate conditions. Bounding the concurrency to 32 serves the purposes of checking for the conditions the test was written for while also allowing a reasonable execution time for a single test.
> 
> Thanks,
> 
> -Joe
> 
> --- old/test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java 2015-07-20 14:08:23.839018642 -0700
> +++ new/test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java 2015-07-20 14:08:23.679018638 -0700
> @@ -120,7 +120,8 @@
>             }
>         };
> 
> -        int ps = Runtime.getRuntime().availableProcessors();
> +        // Bound concurrency to avoid degenerate performance
> +        int ps = Math.min(Runtime.getRuntime().availableProcessors(), 32);
>         Stream runners = IntStream.range(0, ps)
>                 .mapToObj(i -> sr.get())
>                 .map(CompletableFuture::runAsync);
> 



From huizhe.wang at oracle.com  Mon Jul 20 21:47:27 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 20 Jul 2015 14:47:27 -0700
Subject: RFR (jaxp) 8131907 : Numerous threads lock during XML processing
Message-ID: <55AD6C6F.7020001@oracle.com>

Please review a change that removes unnecessary class loading.

http://cr.openjdk.java.net/~joehw/jdk9/8131907/webrev/

Thanks,
Joe


From tristan.yan at oracle.com  Mon Jul 20 22:20:14 2015
From: tristan.yan at oracle.com (Tristan Yan)
Date: Mon, 20 Jul 2015 15:20:14 -0700
Subject: RFR for 8068761 : Test
	java/nio/channels/ServerSocketChannel/AdaptServerSocket.java
	failed with SocketTimeoutException
Message-ID: <7D7CA10E-EB99-4D19-B363-0AB6DFEFD414@oracle.com>

Hi 

Please review small fix for test java/nio/channels/ServerSocketChannel/AdaptServerSocket.java.

webrev: http://cr.openjdk.java.net/~tyan/8068761/webrev/ 
bug: https://bugs.openjdk.java.net/browse/JDK-8068761 

Thanks
Tristan

From konstantin.shefov at oracle.com  Tue Jul 21 08:09:43 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Tue, 21 Jul 2015 11:09:43 +0300
Subject: [9] RFR: 8130006:
	java/lang/invoke/MethodHandles/CatchExceptionTest Fails
In-Reply-To: <55ACDB47.1070807@oracle.com>
References: <55ACDB47.1070807@oracle.com>
Message-ID: <55ADFE47.1030701@oracle.com>

CC'ed more reviewers

On 07/20/2015 02:28 PM, Konstantin Shefov wrote:
> Hello,
>
> Please review a test bug fix.
> An exception caused by code cache overflow should be re-thrown before 
> assertion check in the test.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8130006
> Webrev: http://cr.openjdk.java.net/~kshefov/8130006/webrev.00/
>
> -Konstantin



From paul.sandoz at oracle.com  Tue Jul 21 08:48:12 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 21 Jul 2015 10:48:12 +0200
Subject: [9] RFR: 8130006:
	java/lang/invoke/MethodHandles/CatchExceptionTest Fails
In-Reply-To: <55ACDB47.1070807@oracle.com>
References: <55ACDB47.1070807@oracle.com>
Message-ID: 


On 20 Jul 2015, at 13:28, Konstantin Shefov  wrote:

> Hello,
> 
> Please review a test bug fix.
> An exception caused by code cache overflow should be re-thrown before assertion check in the test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8130006
> Webrev: http://cr.openjdk.java.net/~kshefov/8130006/webrev.00/
> 

Look ok. It might be worth placing a comment before the throwing of the error to say this will be treated differently. No need for another review if you choose to do that.

Paul.


From Roger.Riggs at Oracle.com  Tue Jul 21 13:36:28 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 21 Jul 2015 09:36:28 -0400
Subject: RFR (jaxp) 8131907 : Numerous threads lock during XML processing
In-Reply-To: <55AD6C6F.7020001@oracle.com>
References: <55AD6C6F.7020001@oracle.com>
Message-ID: <55AE4ADC.4000900@Oracle.com>

Hi Joe,

Looks good.

Roger


On 7/20/2015 5:47 PM, huizhe wang wrote:
> Please review a change that removes unnecessary class loading.
>
> http://cr.openjdk.java.net/~joehw/jdk9/8131907/webrev/
>
> Thanks,
> Joe



From Roger.Riggs at Oracle.com  Tue Jul 21 14:31:49 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 21 Jul 2015 10:31:49 -0400
Subject: RFR for 8068761 : Test
	java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed
	with SocketTimeoutException
In-Reply-To: <7D7CA10E-EB99-4D19-B363-0AB6DFEFD414@oracle.com>
References: <7D7CA10E-EB99-4D19-B363-0AB6DFEFD414@oracle.com>
Message-ID: <55AE57D5.1060006@Oracle.com>

Hi Tristan,

Looks ok, extending the timeout should work fine.

Roger


On 7/20/2015 6:20 PM, Tristan Yan wrote:
> Hi
>
> Please review small fix for test java/nio/channels/ServerSocketChannel/AdaptServerSocket.java.
>
> webrev: http://cr.openjdk.java.net/~tyan/8068761/webrev/ 
> bug: https://bugs.openjdk.java.net/browse/JDK-8068761 
>
> Thanks
> Tristan



From paul.sandoz at oracle.com  Tue Jul 21 16:32:12 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 21 Jul 2015 18:32:12 +0200
Subject: Stream.generate
In-Reply-To: <55AD2B2A.9070507@univ-mlv.fr>
References: <55AD2B2A.9070507@univ-mlv.fr>
Message-ID: <124B5125-DBD4-46AF-ABA1-E1E537E454A6@oracle.com>

Hi Remi,

Can you log an issue?

Thanks,
Paul.

On 20 Jul 2015, at 19:08, Remi Forax  wrote:

> Hi all, hi Paul,
> I've found that the signature of Stream.generate doesn't to use a wildcard hence some program are rejected even if there are valid, by example:
>  public static void main(String[] args) {
>      Supplier supplier = () -> "hello";
>      Stream s = Stream.generate(supplier);
>  }
> 
> The fix is simple, in interface Stream, generate should be declared like this :
>  public static Stream generate(Supplier s)
> and
> the field 's' of the InfiniteSupplyingSpliterator.OfRef should be also declared as a Supplier.
> 
> regards,
> R?mi
> 
> 



From huizhe.wang at oracle.com  Tue Jul 21 16:36:23 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 21 Jul 2015 09:36:23 -0700
Subject: RFR (jaxp) 8131907 : Numerous threads lock during XML processing
In-Reply-To: <55AE4ADC.4000900@Oracle.com>
References: <55AD6C6F.7020001@oracle.com> <55AE4ADC.4000900@Oracle.com>
Message-ID: <55AE7507.2040908@oracle.com>

Thanks Roger!

Joe

On 7/21/2015 6:36 AM, Roger Riggs wrote:
> Hi Joe,
>
> Looks good.
>
> Roger
>
>
> On 7/20/2015 5:47 PM, huizhe wang wrote:
>> Please review a change that removes unnecessary class loading.
>>
>> http://cr.openjdk.java.net/~joehw/jdk9/8131907/webrev/
>>
>> Thanks,
>> Joe
>



From daniel.fuchs at oracle.com  Tue Jul 21 16:51:24 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 21 Jul 2015 18:51:24 +0200
Subject: RFR (jaxp) 8131907 : Numerous threads lock during XML processing
In-Reply-To: <55AD6C6F.7020001@oracle.com>
References: <55AD6C6F.7020001@oracle.com>
Message-ID: <55AE788C.7030007@oracle.com>

Hi Joe,

Looks good to me!

nit: the two statics don't agree on style:
    'private static final' vs 'private final static'

best regards,

-- daniel

On 20/07/15 23:47, huizhe wang wrote:
> Please review a change that removes unnecessary class loading.
>
> http://cr.openjdk.java.net/~joehw/jdk9/8131907/webrev/
>
> Thanks,
> Joe



From huizhe.wang at oracle.com  Tue Jul 21 17:14:34 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 21 Jul 2015 10:14:34 -0700
Subject: RFR (jaxp) 8131907 : Numerous threads lock during XML processing
In-Reply-To: <55AE788C.7030007@oracle.com>
References: <55AD6C6F.7020001@oracle.com> <55AE788C.7030007@oracle.com>
Message-ID: <55AE7DFA.3030404@oracle.com>


On 7/21/2015 9:51 AM, Daniel Fuchs wrote:
> Hi Joe,
>
> Looks good to me!
>
> nit: the two statics don't agree on style:
>    'private static final' vs 'private final static'

Good catch!  Fixed.

Thanks!
-Joe
>
> best regards,
>
> -- daniel
>
> On 20/07/15 23:47, huizhe wang wrote:
>> Please review a change that removes unnecessary class loading.
>>
>> http://cr.openjdk.java.net/~joehw/jdk9/8131907/webrev/
>>
>> Thanks,
>> Joe
>



From forax at univ-mlv.fr  Tue Jul 21 21:22:03 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 21 Jul 2015 23:22:03 +0200
Subject: Stream.generate
In-Reply-To: <124B5125-DBD4-46AF-ABA1-E1E537E454A6@oracle.com>
References: <55AD2B2A.9070507@univ-mlv.fr>
	<124B5125-DBD4-46AF-ABA1-E1E537E454A6@oracle.com>
Message-ID: <55AEB7FB.40205@univ-mlv.fr>

On 07/21/2015 06:32 PM, Paul Sandoz wrote:
> Hi Remi,
>
> Can you log an issue?
>
> Thanks,
> Paul.

Hi Paul, yes,
https://bugs.openjdk.java.net/browse/JDK-8132097

regards,
R?mi

>
> On 20 Jul 2015, at 19:08, Remi Forax  wrote:
>
>> Hi all, hi Paul,
>> I've found that the signature of Stream.generate doesn't to use a wildcard hence some program are rejected even if there are valid, by example:
>>   public static void main(String[] args) {
>>       Supplier supplier = () -> "hello";
>>       Stream s = Stream.generate(supplier);
>>   }
>>
>> The fix is simple, in interface Stream, generate should be declared like this :
>>   public static Stream generate(Supplier s)
>> and
>> the field 's' of the InfiniteSupplyingSpliterator.OfRef should be also declared as a Supplier.
>>
>> regards,
>> R?mi
>>
>>



From paul.sandoz at oracle.com  Wed Jul 22 08:10:56 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 22 Jul 2015 10:10:56 +0200
Subject: Stream.generate
In-Reply-To: <55AD2B2A.9070507@univ-mlv.fr>
References: <55AD2B2A.9070507@univ-mlv.fr>
Message-ID: <272D8546-ED72-4640-99AC-271AEC3805A9@oracle.com>


On 20 Jul 2015, at 19:08, Remi Forax  wrote:

> Hi all, hi Paul,
> I've found that the signature of Stream.generate doesn't to use a wildcard hence some program are rejected even if there are valid, by example:
>  public static void main(String[] args) {
>      Supplier supplier = () -> "hello";
>      Stream s = Stream.generate(supplier);
>  }
> 
> The fix is simple, in interface Stream, generate should be declared like this :
>  public static Stream generate(Supplier s)
> and
> the field 's' of the InfiniteSupplyingSpliterator.OfRef should be also declared as a Supplier.
> 

I believe such changes to Stream.generate are backwards compatible because overriding is not possible. (In addition static method on an interface are scoped to that interface, but i am not sure if that matters in this case.)

We could also adjust Stream.iterate as well:

  public static Stream iterate(final S seed, final UnaryOperator f)

Seems appropriate for consistency with Stream.generate. I presume that is backwards compatible as well?

Paul.


From forax at univ-mlv.fr  Wed Jul 22 11:22:14 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 22 Jul 2015 13:22:14 +0200
Subject: Stream.generate
In-Reply-To: <272D8546-ED72-4640-99AC-271AEC3805A9@oracle.com>
References: <55AD2B2A.9070507@univ-mlv.fr>
	<272D8546-ED72-4640-99AC-271AEC3805A9@oracle.com>
Message-ID: <55AF7CE6.5080803@univ-mlv.fr>



On 07/22/2015 10:10 AM, Paul Sandoz wrote:
> On 20 Jul 2015, at 19:08, Remi Forax  wrote:
>
>> Hi all, hi Paul,
>> I've found that the signature of Stream.generate doesn't to use a wildcard hence some program are rejected even if there are valid, by example:
>>   public static void main(String[] args) {
>>       Supplier supplier = () -> "hello";
>>       Stream s = Stream.generate(supplier);
>>   }
>>
>> The fix is simple, in interface Stream, generate should be declared like this :
>>   public static Stream generate(Supplier s)
>> and
>> the field 's' of the InfiniteSupplyingSpliterator.OfRef should be also declared as a Supplier.
>>
> I believe such changes to Stream.generate are backwards compatible because overriding is not possible. (In addition static method on an interface are scoped to that interface, but i am not sure if that matters in this case.)

The fact that a static method on a class is accessible from a subclass 
doesn't help my students to understand how overriding works and i'm glad 
that Kevin Bourillion suggests that for static methods in interface we 
can fix that.

I believe that if Stream was a class, it might cause an issue because i 
remember that the JLS defines name-clash even on static methods i.e. a 
code like this is illegal:

class A {
   static void m(Supplier s) { ... }
}
class B extends A {
   static void m(Supplier s) { ... }  // name clash
}

>
> We could also adjust Stream.iterate as well:
>
>    public static Stream iterate(final S seed, final UnaryOperator f)
>
> Seems appropriate for consistency with Stream.generate. I presume that is backwards compatible as well?

yes !
as you said, these changes are source backward compatible, the static 
methods now accept more potential types and binary backward compatible 
because the erasures are not changed.

BTW, in the body of iterate(), the cast of Stream.NONE to T is plainly 
wrong from the type system point of view, it only works because of 
erasure. A slightly less wrong code is to store the current element in 
an Object and do the cast from Object to T (or S with the new signature) 
when calling f because the parameter is always a T at that point.

          final Iterator iterator = new Iterator() {
             private Object element = Streams.NONE;

             @Override
             public boolean hasNext() {
                 return true;
             }

             @Override
             @SuppressWarnings("unchecked")
             public T next() {
                 Object e = element;
                 S value = (e == Streams.NONE) ? seed : f.apply((S)e);
                 element = value;
                 return value;
             }
         };

The code of next() is less readable because in Java when you write a = b 
= c, the type of b = c is the type of b instead of being the type of c 
(like in Kotlin or Groovy).
A fun hacky solution to simplify the code, and make it obviously not 
readable, is to use a try/finally here :)

             public T next() {
                 T value;
                 try {
                     return value = (element == Streams.NONE) ? seed : 
f.apply((S)element);
                 } finally {
                     element = value;
                 }
             }

>
> Paul.

R?mi



From Roger.Riggs at Oracle.com  Wed Jul 22 16:13:52 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 22 Jul 2015 12:13:52 -0400
Subject: RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with
	"java.lang.RuntimeException: setTime should make getLastModifiedTime
	return the specified instant: 3078282244456 got: 3078282244455"
In-Reply-To: <55A9295F.10202@oracle.com>
References: <55A6B02F.9060400@oracle.com> <55A8B70D.3050406@gmail.com>
	<55A92321.1010605@oracle.com> <55A9295F.10202@oracle.com>
Message-ID: <55AFC140.60509@Oracle.com>

Hi Sherman,

Sorry for the delay,  that looks fine.
If zip is still around that far in the future, everyone will have the 
same problem.

Roger



On 7/17/2015 12:12 PM, Xueming Shen wrote:
> On 7/17/15 8:45 AM, Xueming Shen wrote:
>> On 7/17/15 1:04 AM, Peter Levart wrote:
>>> Hi Sherman,
>>>
>>> On 07/15/2015 09:10 PM, Xueming Shen wrote:
>>>> Hi,
>>>>
>>>> Please help review the change for JDK-8130914.
>>>>
>>>> issue: https://bugs.openjdk.java.net/browse/JDK-8130914
>>>> webrev: http://cr.openjdk.java.net/~sherman/8130914/
>>>>
>>>> This is a "regression" triggered by
>>>> https://bugs.openjdk.java.net/browse/JDK-8130914
>>>> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
>>>
>>> And-ing the result with a 32 bit mask (2^32 - 1) does make sure that 
>>> high 32 bits are not touched by year encoding. As I understand, this 
>>> starts to be a problem with year 2044 and beyond when (year - 1980) 
>>> << 25 becomes a negative number. Expanding it to long sets the high 
>>> 32 bits too. If we treat the lower 32 bits as unsigned, we 
>>> accommodate for years up to and including 2107. At 2108, the 
>>> overflow happens and decoding the year back gives 1980 instead of 
>>> 2108. So I wonder:
>>> - will there be a DOS compatible ZIP format after 2108 ?
>>> - will there be Java after 2108 ?
>>
>> Yes, dos timestamp has a 2107 ceiling, given it's 32-bit nature, like 
>> the unix time has a 2038 ceiling if
>> the long stays as 32-bit.
>>
>>> - depending on the above answers, should there be a 
>>> DOSTIME_AFTER_2107 in addition to DOSTIME_BEFORE_1980 to which the 
>>> date is clamped?
>>>
>>
> btw, we do have a ZipEntry.UPPER_DOSTIME_BOUND to help save a 
> timestamp into the extra field, if necessary.
>
> -sherman



From steve.drach at oracle.com  Wed Jul 22 22:08:28 2015
From: steve.drach at oracle.com (Steve Drach)
Date: Wed, 22 Jul 2015 15:08:28 -0700
Subject: RFR: JDK-8066013 (prefs) Unused variable in
	src/java.prefs/share/classes/java/util/prefs/MacOSXPreferences.java
Message-ID: <1747FD15-C035-4E61-B3B2-43BF1C97CE86@oracle.com>

Hello,

Please review the fix for JDK-8066013, removing two unused variables from MacOSXPreferences.java.

https://bugs.openjdk.java.net/browse/JDK-8066013 
http://slc01hfj.us.oracle.com/webrevs/JDK-8066013/webrev/index.html 

An internal review has been completed.

Thanks,
Steve

From chris.hegarty at oracle.com  Thu Jul 23 09:26:20 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 23 Jul 2015 10:26:20 +0100
Subject: RFR: JDK-8066013 (prefs) Unused variable in
	src/java.prefs/share/classes/java/util/prefs/MacOSXPreferences.java
In-Reply-To: <1747FD15-C035-4E61-B3B2-43BF1C97CE86@oracle.com>
References: <1747FD15-C035-4E61-B3B2-43BF1C97CE86@oracle.com>
Message-ID: <06EFC8B1-B32B-4639-A43E-99CC4AE9065E@oracle.com>

Your change [1] looks fine to me Steve.

-Chris.

[1] diff --git a/src/java.prefs/macosx/classes/java/util/prefs/MacOSXPreferences.java b/src/java.prefs/macosx/classes/java/util/prefs/MacOSXPreferences.java
--- a/src/java.prefs/macosx/classes/java/util/prefs/MacOSXPreferences.java
+++ b/src/java.prefs/macosx/classes/java/util/prefs/MacOSXPreferences.java
@@ -37,9 +37,6 @@
     // true if this node is a child of userRoot or is userRoot
     private final boolean isUser;
 
-    // true if this node is userRoot or systemRoot
-    private final boolean isRoot;
-
     // CF's storage location for this node and its keys
     private final MacOSXPreferencesFile file;
 
@@ -94,7 +91,6 @@
                               boolean isNew, boolean isRoot, boolean isUser)
     {
         super(parent, name);
-        this.isRoot = isRoot;
         if (isRoot)
             this.isUser = isUser;
         else
@@ -115,7 +111,6 @@
         // /one/two/three/four/five/
         // The fourth slash is the end of the first three components.
         // If there is no fourth slash, the name has fewer than 3 components
-        int componentCount = 0;
         int pos = -1;
         for (int i = 0; i < 4; i++) {
             pos = name.indexOf('/', pos+1);

-Chris.

On 22 Jul 2015, at 23:08, Steve Drach  wrote:

> Hello,
> 
> Please review the fix for JDK-8066013, removing two unused variables from MacOSXPreferences.java.
> 
> https://bugs.openjdk.java.net/browse/JDK-8066013 
> http://slc01hfj.us.oracle.com/webrevs/JDK-8066013/webrev/index.html 
> 
> An internal review has been completed.
> 
> Thanks,
> Steve



From daniel.fuchs at oracle.com  Fri Jul 24 08:46:11 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 24 Jul 2015 10:46:11 +0200
Subject: RFR: 8132256: jaxp: Investigate removal of
	com/sun/org/apache/bcel/internal/util/ClassPath.java
Message-ID: <55B1FB53.7030609@oracle.com>

Hi,

Please find below a patch that fixes

8132256: jaxp: Investigate removal of
                com/sun/org/apache/bcel/internal/util/ClassPath.java
https://bugs.openjdk.java.net/browse/JDK-8132256

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8132256/webrev.00


The class com.sun.org.appache.bcel.internal.util.ClassPath does
not seem to serve any useful purpose in JDK 9.

  - There's only one instance created, using its default empty
    constructor.
  - There's only one method called on that instance, from
    SyntheticRepository.java: _path.getInputStream(className);
  - Because _path was created using the default (and deprecated)
    empty constructor, and because ClassPath is loaded from the BCL
    (ClassPath.class.getClassLoader() == null), then
    _path.getInputStream(className) will always throw an IOException.

Therefore - it seems that in the JDK - the use of 
com.sun.org.appache.bcel.internal.util.ClassPath is reduced
to an elaborate means of throwing an IOException.

The patch above arranges for the removal of
com/sun/org/apache/bcel/internal/util/ClassPath.java

best regards,

-- daniel


From volker.simonis at gmail.com  Fri Jul 24 13:30:21 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 24 Jul 2015 15:30:21 +0200
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: <55AD0C2A.4050505@Oracle.com>
References: 
	<55ACFF1C.4020003@Oracle.com>
	
	<55AD0C2A.4050505@Oracle.com>
Message-ID: 

Hi,

so here comes the new webrev which cleanly applies to the current
jdk9-dev/jdk repo:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v2/

The good thing beforehand - although I added the AIX-port and a big
50-line comment the new version is still 60 lines shorter :)
  10 files changed, 829 insertions(+), 999 deletions(-)

The main idea behind the new code layout is as follows (see the
comment in ProcessHandleImpl_unix.c for more details):

The currently supported Unix variants are Solaris, Linux, MaxOS X
and AIX. The various similarities and differences between these
systems make it hard to find a clear boundary between platform
specific and shared code.

In order to ease code sharing between the platforms while still
keeping the code as clean as possible (i.e. free of preprocessor
macros) we use the following source code layout (remember that
ProcessHandleImpl_unix.c will be compiled on EVERY Unix platform
while ProcessHandleImpl_.c will be only compiled on the
specific OS):

 - all the JNI wrappers for the ProcessHandleImpl functions go
   into ProcessHandleImpl_unix.c file

 - if their implementation is common on ALL the supported Unix
   platforms it goes right into the JNI wrappers

 - if the whole function or substantial parts of it are platform
   dependent, the implementation goes into os_
   functions in ProcessHandleImpl_.c

 - if at least two platforms implement an os_
   function in the same way, this implementation is factored out
   into unix_, placed into
   ProcessHandleImpl_unix.c and called from the corresponding
   os_ function.

 - For convenience, all the os_ and unix_ functions are declared
   in ProcessHandleImpl_unix.h which is included into every
   ProcessHandleImpl_.c file.

So ProcessHandleImpl_unix.c only contains code which is shared by at
least two platforms. Code which is specific to one single platform
goes into the corresponding ProcessHandleImpl_.c file (and this
changes adds ProcessHandleImpl_aix.c for AIX-specific code and
ProcessHandleImpl_linux.c for Linux-specific code which was in
ProcessHandleImpl_unix.c previously).

I tried to unify similar functions (e.g.
Java_java_lang_ProcessHandleImpl_00024Info_initIDs,
Java_java_lang_ProcessHandleImpl_isAlive0 or fillArgArray) into a
single instance in ProcessHandleImpl_unix.c.

I renamed and unified getStatInfo() into
os_getParentPid()/unix_getParentPid() with three implemantions for
MacOSX, Linux and Solaris/AIX.

I've factored out Java_java_lang_ProcessHandleImpl_getProcessPids0()
into os_getChildren()/unix_getChildren() with two implemantions - one
for MacOSX and one for Linux/Solaris/AIX.

I've tested the new implementation on MacOSX, Linux (x86_64 and ppc64)
, Solaris 10/11 (x86_64 and Sparc) and AIX.

The final point, which was already mentioned in the first review is
the fact that we can not easily get accurate information fort he
command line and arguments on AIX. I'd prefer to stay with the current
solution which gives "best effort" answers for these attributes but if
everybody?s opinion is that such information is useless I can also
omit it altogether. I haven?t looked at the other platforms which we
have to support (e.g. HPUX, AS/400) but the situation may be similar
there.

Regards,
Volker

On Mon, Jul 20, 2015 at 4:56 PM, Roger Riggs  wrote:
> Hi Volker,
>
> yes, press ahead.
>
> On the _unix topic, I think the most platforms depends on when/how/what you
> count.
> I was following the prior pattern that counted OS X as being mostly common
> with Linux
> and Oracle Linux as a Redhat derivative.  That counts at least as 2 I think.
>
> I'd be interested in other folks views on the usefulness of
> partial/truncated info from the API.
> If the values are so weak they are only useful for logging then that's not
> good enough.
>
> Perhaps the truncated information should be presented from a different
> method
> from ProcessHandle.Info object to be able to reflect its poor quality.
>
> Thanks, Roger
>
>
> On 7/20/2015 10:46 AM, Volker Simonis wrote:
>
> Hi Roger,
>
> thanks for looking at the webrev. Please find my comments inline:
>
> On Mon, Jul 20, 2015 at 4:01 PM, Roger Riggs  wrote:
>
> Hi Volker,
>
> yes, generally, the approach is an improvement and provides a clearer
> model of os specific variations.
>
> More comments inline...
>
>
> On 7/17/2015 2:28 PM, Volker Simonis wrote:
>
> Hi,
>
> I worked on refactoring the native ProcessHandleImpl implementation to
> enable more code sharing and make it easier to add support for new
> platforms (e.g. AIX) and I think I had a pretty nice version running. But
> unfortunately I've just realized that the recent changes to
> ProcessHandleImpl (i.e. "8078099: (process) ProcessHandle should uniquely
> identify processes" and "8078108: (process) ProcessHandle.isAlive should
> be
> robust") have been massive so I have to start over to merge all my changes
> with the new version.
>
> But before doing that I just wanted to post my current changes which
> cleanly apply to the repo before 8078099 and ask for your opinion:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v1/
>
> Here's a summary (taken from ProcesHandleImpl_unix.c) of what I've
> actually
> done (if the output appears scrambled in you mail better read it in the
> webrev
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v1/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c.udiff.html
> ):
>
> /**
>   * This file contains the implementation of the native ProcessHandleImpl
>   * functions which are common to all Unix variants.
>   *
>   * The currently supported Unix variants are Solaris, Linux, MaxOS X and
> AIX.
>   * The various similarities and differences between these systems make it
> hard
>   * to find a clear boundary between platform specific and shared code.
>   *
>   * In order to ease code sharing between the pltforms while still keeping
> the
>   * code as clean as possible (i.e. free of preprocessor macros) we use
> the
>   * following source code layout (remember that ProcessHandleImpl_unix.c
> will
>   * be compiled on EVERY Unix platform while ProcessHandleImpl_.c will
> be
>   * only compiled on the specific OS):
>   *
>   * - all the JNI wrappers for the ProcessHandleImpl functions go into
> this
> file
>   * - if their implementation is common on ALL the supported Unix
> platforms
> it
>   *   goes right into the JNI wrappers
>   * - if the whole function or substantial parts are platform dependent,
> the
>   *   implementation goes into os_ functions in
>   *   ProcessHandleImpl_.c
>   * - if at least two platforms implement an os_ function
> in
> the
>   *   same way, this implementation is factored out into
> unix_,
>   *   placed into this file and called from the corresponding
> os_
>   *   function.
>   * - For convenience, all the os_ and unix_ functions are declared in
>   *   ProcessHandleImpl_unix.h which is included into every
>   *   ProcessHandleImpl_.c file.
>   *
>   * Example 1:
>   * ----------
>   * The implementation of
> Java_java_lang_ProcessHandleImpl_00024Info_initIDs()
>   * is the same on all platforms except on Linux where it initilizes one
>   * additional field. So we place the implementation right into
>   * Java_java_lang_ProcessHandleImpl_00024Info_initIDs() but add call to
>   * os_init() at the end of the function which is empty on all platforms
>   * except Linux where it performs the additionally initializations.
>   *
>   * Example 2:
>   * ----------
>   * The implementation of Java_java_lang_ProcessHandleImpl_00024Info_info0
> is
>   * the same on Solaris and AIX but different on Linux and MacOSX. We
> therefore
>   * simply call the two helpers os_getStatInfo() and os_getCmdlineInfo().
> The
>   * Linux and MaxOS X versions of these functions (in the corresponding
> files
>   * ProcessHandleImpl_linux.c and ProcessHandleImpl_macosx.c) directly
> contain
>   * the platform specific implementations while the Solaris and AIX
>   * implementations simply call back to unix_getStatInfo() and
>   * unix_getCmdlineInfo() which are implemented right in this file.
>   *
>   * The term "same implementation" is still a question of interpretation.
> It
> my
>   * be acceptable to have a few ifdef'ed lines if that allows the sharing
> of
> a
>   * huge function. On the other hand, if the platform specific code in a
> shared
>   * function grows over a certain limit, it may be better to refactor that
>   * functionality into corresponding, platform-specific os_ functions.
>   */
>
> This resulted in the new file ProcessHandleImpl_linux.c which now only
> contains Linux-only code which was previously in ifdefed for Linux in
> ProcessHandleImpl_linux.c. The advantage is that we now have only one
> version of:
>
>   Java_java_lang_ProcessHandleImpl_00024Info_initIDs
>   unix_fillArgArray
>   unix_uidToUser
>
> and on version of
>
>   unix_getChildren
>
> which is shared by Solaris, Linux and AIX and one version of
>
>   unix_getStatInfo
>   unix_getCmdlineInfo
>
> which are shared by Solaris and Linux.
>
> Additionally I've added the AIX port following the new schema and I've
> slightly improved the Solaris port to use the information from
> psinfo.pr_psargs for reporting at least the first 80 characters of the
> command line arguments. arg[0] from psinfo.pr_psargs is also used as the
> "command()" string in the case where "/proc/%d/path/a.out" isn't readable.
> This helps to report a command string for all the processes we do not own,
> because in that case, "/proc/%d/path/a.out" isn't readable. By the way,
> using args[0] as a fall-back for cmd beeing null also helps on MacOS X for
> processes we don't own. Finally I've also done some test improvements.
>
> My bias was toward omitting information that was incomplete or not usable
> programatically.
> If the commandline is truncated then it is pretty useless to a program, the
> same with
> the executable command.  If the application has to try to guess what's
> missing and how
> to use what is present then it should be omitted from the API.  If there is
> a user present
> then they can use 'ps' or 'tasklist' and interpret the partial information.
>
> But 'ps' is limited to 80 characters for arguments and command line as
> well on Solaris as far as I know. Moreover, on AIX I haven't found
> something better than this for the command line at all. Anyway we have
> to live with the fact that this information is extremely platform
> dependent. The least common divisor is surely the PID but for this API
> I prefer to expose "as much as possible" for a given platform.
>
> I suspect that once this API is out there in the world, people will
> use it for all kind of stuff like monitoring or logging and I'd rather
> prefer to see a truncated command line in a log file instad of just
> seeing a plain PID. So usefull/useless depends pretty much on the use
> case :)
>
> The focus should be on an API that can be used to control/manage a set of
> applications
> the run together, usually under the same userid or with root privileges.
>
> Comments on the diffs:
>
> ProcessHandle.java:
>  - The notes should probably be use @implNote  (though I disagree with
> providing truncated information)
>
> Didn't knew that one but I'll use it. Thanks for the hint.
>
> ProcessHandleImpl_unix:
>  - I would not have expected to find the Solaris and AIX implementations of
> getStatInfo
> and getCmdlineInfo here; but perhaps it depends on how one considers the
> lineage of the real unix.
>   Since the more common platforms are Linux, Redhat, etc I would keep those
> versions in the
>   ProcessHandleImpl_unix common file.
>
> As I wrote in the summary - I don't think the _unix file should
> contain the implementations of the most prominent Unix platform but
> rather the implementations shared between most platforms. If a
> function implementation is only being used on Linux I think it is
> reasonable to put it into a _linux file.
>
> A while ago we discussed if the 'unix' directory should be named
> 'unix' or 'posix' or whatsoever and ended up with 'unix'. I think
> that's a good decision because it honours the fact that there is no
> single, true, genuine Unix variant. The 'unix' directory is a
> pragmatic approach to share "common" Unix code with "common" in the
> sense of "supported by at least two or more Unix variants". At least
> that was my understanding.
>
> I'll start to merge in your new changes into my schema and post a new
> webrev once I'm done.
>
> Thanks once again for your comments,
> Volker
>
> Thanks, Roger
>
>
>
>
> I have tested all my changes on Linux/amd64, Linux/ppc64, MacOS X, Solaris
> and AIX.
>
> I'd be happy to forward port my changes to the newest head version if you
> generally agree with my approach (and give me a short time frame where you
> promise not to do any massive changes :)
>
> What do you think?
>
> Thank you and best regards,
> Volker
>
>


From steve.drach at oracle.com  Fri Jul 24 18:16:10 2015
From: steve.drach at oracle.com (Steve Drach)
Date: Fri, 24 Jul 2015 11:16:10 -0700
Subject: RFR: JDK-8114832 it.next on ArrayList throws wrong type of Exception
	after remove(-1)
Message-ID: <788B7264-C303-4784-9D8A-7D7EFFAC5D43@oracle.com>

Hello,

Please review the fix for JDK-8114832.  I did what was suggested in the comments in the bug report, moving the increment of modcount to the ?right? place.

https://bugs.openjdk.java.net/browse/JDK-8114832 
http://slc01hfj.us.oracle.com/webrevs/JDK-8114832/webrev/index.html 

An internal review has been completed.

Thanks,
Steve




From martinrb at google.com  Fri Jul 24 18:30:46 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 24 Jul 2015 11:30:46 -0700
Subject: RFR: JDK-8114832 it.next on ArrayList throws wrong type of
	Exception after remove(-1)
In-Reply-To: <788B7264-C303-4784-9D8A-7D7EFFAC5D43@oracle.com>
References: <788B7264-C303-4784-9D8A-7D7EFFAC5D43@oracle.com>
Message-ID: 

Hi Steve, pleased to meet you!

(are you a new maintainer of java.util collections?)

I'm mildly opposed to this change - I added comments to the bug.

On Fri, Jul 24, 2015 at 11:16 AM, Steve Drach 
wrote:

> Hello,
>
> Please review the fix for JDK-8114832.  I did what was suggested in the
> comments in the bug report, moving the increment of modcount to the ?right?
> place.
>
> https://bugs.openjdk.java.net/browse/JDK-8114832 <
> https://bugs.openjdk.java.net/browse/JDK-8114832>
> http://slc01hfj.us.oracle.com/webrevs/JDK-8114832/webrev/index.html <
> http://slc01hfj.us.oracle.com/webrevs/JDK-8114832/webrev/index.html>
>
> An internal review has been completed.
>
> Thanks,
> Steve
>
>
>


From huizhe.wang at oracle.com  Fri Jul 24 21:21:28 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 24 Jul 2015 14:21:28 -0700
Subject: RFR: 8132256: jaxp: Investigate removal of
	com/sun/org/apache/bcel/internal/util/ClassPath.java
In-Reply-To: <55B1FB53.7030609@oracle.com>
References: <55B1FB53.7030609@oracle.com>
Message-ID: <55B2AC58.6040009@oracle.com>

Looks good to me.

Thanks,
Joe

On 7/24/2015 1:46 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch that fixes
>
> 8132256: jaxp: Investigate removal of
> com/sun/org/apache/bcel/internal/util/ClassPath.java
> https://bugs.openjdk.java.net/browse/JDK-8132256
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8132256/webrev.00
>
>
> The class com.sun.org.appache.bcel.internal.util.ClassPath does
> not seem to serve any useful purpose in JDK 9.
>
>  - There's only one instance created, using its default empty
>    constructor.
>  - There's only one method called on that instance, from
>    SyntheticRepository.java: _path.getInputStream(className);
>  - Because _path was created using the default (and deprecated)
>    empty constructor, and because ClassPath is loaded from the BCL
>    (ClassPath.class.getClassLoader() == null), then
>    _path.getInputStream(className) will always throw an IOException.
>
> Therefore - it seems that in the JDK - the use of 
> com.sun.org.appache.bcel.internal.util.ClassPath is reduced
> to an elaborate means of throwing an IOException.
>
> The patch above arranges for the removal of
> com/sun/org/apache/bcel/internal/util/ClassPath.java
>
> best regards,
>
> -- daniel



From paul.sandoz at oracle.com  Mon Jul 27 08:19:50 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 27 Jul 2015 10:19:50 +0200
Subject: RFR: JDK-8114832 it.next on ArrayList throws wrong type of
	Exception after remove(-1)
In-Reply-To: 
References: <788B7264-C303-4784-9D8A-7D7EFFAC5D43@oracle.com>
	
Message-ID: 


On 24 Jul 2015, at 20:30, Martin Buchholz  wrote:

> Hi Steve, pleased to meet you!
> 
> (are you a new maintainer of java.util collections?)
> 

I suggested that Steve look at some ?simple? issues to build up credits for a committer role, so i threw this and some others over the fence for Steve to review and possibly fix.


> I'm mildly opposed to this change - I added comments to the bug.
> 

It looks like you are not the only one. I am outnumbered :-)

My guiding principle here was that argument validation should not result in side-effects. Thus the state of a collection should remain unchanged if an exception is thrown due to an invalid argument of an operation.

ArrayList.remove is inconsistent with regards to nearly all the other ArrayList methods, add(int, E) and addAll(int, Collection) for an out of bounds index, and addAll(Collection ), removeAll, retainAll, removeIf, replaceAll and sort for a null argument. It?s not inconsistent with ArrayList.removeRange, except for if an invalid range from > t, but is inconsistent with AbstractList.removeRange. It?s also inconsistent LinkedList and CopyOnWriteArrayList *and* sub-lists of ArrayList and AbstractList. And inconsistent more generally for other Collection implementations, such as Queue.add/offer/remove implementations that do not accept null values.

The behaviour of ArrayList.remove, and also ArrayList.removeRange, are outliers [*]. It?s also a rather obscure difference behaviour with likely minimal impact if changed (far less so than the change to Arrays.toList) .

Paul.

[*] While there is a argument to be had for updating concurrent modification state of a collection for an operation that performs structural modification regardless of whether its arguments are valid or not such a behavioural change would have far more impact.


> On Fri, Jul 24, 2015 at 11:16 AM, Steve Drach 
> wrote:
> 
>> Hello,
>> 
>> Please review the fix for JDK-8114832.  I did what was suggested in the
>> comments in the bug report, moving the increment of modcount to the ?right?
>> place.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8114832 <
>> https://bugs.openjdk.java.net/browse/JDK-8114832>
>> http://slc01hfj.us.oracle.com/webrevs/JDK-8114832/webrev/index.html <
>> http://slc01hfj.us.oracle.com/webrevs/JDK-8114832/webrev/index.html>
>> 
>> An internal review has been completed.
>> 
>> Thanks,
>> Steve
>> 
>> 
>> 



From lange.fabian at gmail.com  Mon Jul 27 12:47:00 2015
From: lange.fabian at gmail.com (Fabian Lange)
Date: Mon, 27 Jul 2015 14:47:00 +0200
Subject: RFR: JDK-8114832 it.next on ArrayList throws wrong type of
	Exception after remove(-1)
Message-ID: 

Hi Paul,


> > I'm mildly opposed to this change - I added comments to the bug.
> >
>
> It looks like you are not the only one. I am outnumbered :-)
>
> The behaviour of ArrayList.remove, and also ArrayList.removeRange, are
> outliers [*]. It?s also a rather obscure difference behaviour with likely
> minimal impact if changed (far less so than the change to Arrays.toList) .
>

There are other outliers too,
add and Add all use a dedicated range check method (rangeCheckForAdd) which
validates the argument > 0.

Imho, the the rangeCheck method is incorrectly used in remove(int), because
it says it is intended to be used immediately before the array access.

I personally would vote to inline the rangeCheck methods and do the
appropriate check in the former caller. as it turns out for every method a
slightly different check would make most sense

Fabian


From volker.simonis at gmail.com  Mon Jul 27 12:54:57 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 27 Jul 2015 14:54:57 +0200
Subject: RFR(XS): 8132374: AIX: fix value of os.version property
Message-ID: 

Hi,

can somebody please review this tiny fix to get the value of the
'os.version' property correct on AIX:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8132374/
https://bugs.openjdk.java.net/browse/JDK-8132374

Thank you and best regards,
Volker


From Alan.Bateman at oracle.com  Mon Jul 27 13:02:39 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 Jul 2015 14:02:39 +0100
Subject: RFR(XS): 8132374: AIX: fix value of os.version property
In-Reply-To: 
References: 
Message-ID: <55B62BEF.60504@oracle.com>



On 27/07/2015 13:54, Volker Simonis wrote:
> Hi,
>
> can somebody please review this tiny fix to get the value of the
> 'os.version' property correct on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132374/
> https://bugs.openjdk.java.net/browse/JDK-8132374
>
>
This looks okay to me, assuming applications on AIX looking at 
os.version won't be surprised.

-Alan


From volker.simonis at gmail.com  Mon Jul 27 13:29:47 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 27 Jul 2015 15:29:47 +0200
Subject: RFR(XS): 8132374: AIX: fix value of os.version property
In-Reply-To: <55B62BEF.60504@oracle.com>
References: 
	<55B62BEF.60504@oracle.com>
Message-ID: 

Thanks, Alan.

We've done this correctly in our SAP JVM as well as IBM in their J9
but for some reason we've missed the fixed in the initial OpenJDK
port.

Regards,
Volker


On Mon, Jul 27, 2015 at 3:02 PM, Alan Bateman  wrote:
>
>
> On 27/07/2015 13:54, Volker Simonis wrote:
>>
>> Hi,
>>
>> can somebody please review this tiny fix to get the value of the
>> 'os.version' property correct on AIX:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132374/
>> https://bugs.openjdk.java.net/browse/JDK-8132374
>>
>>
> This looks okay to me, assuming applications on AIX looking at os.version
> won't be surprised.
>
> -Alan


From Roger.Riggs at Oracle.com  Mon Jul 27 13:31:54 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 27 Jul 2015 09:31:54 -0400
Subject: RFR(XS): 8132374: AIX: fix value of os.version property
In-Reply-To: 
References: 
	<55B62BEF.60504@oracle.com>
	
Message-ID: <55B632CA.9000905@Oracle.com>

Hi Volker,

I doubt there is a test for any of the OS's but is it possible to write 
a test that would
compare that string to the version string produced by one of the os 
provided tools.
For example uname?

Thanks, Roger


On 7/27/2015 9:29 AM, Volker Simonis wrote:
> Thanks, Alan.
>
> We've done this correctly in our SAP JVM as well as IBM in their J9
> but for some reason we've missed the fixed in the initial OpenJDK
> port.
>
> Regards,
> Volker
>
>
> On Mon, Jul 27, 2015 at 3:02 PM, Alan Bateman  wrote:
>>
>> On 27/07/2015 13:54, Volker Simonis wrote:
>>> Hi,
>>>
>>> can somebody please review this tiny fix to get the value of the
>>> 'os.version' property correct on AIX:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132374/
>>> https://bugs.openjdk.java.net/browse/JDK-8132374
>>>
>>>
>> This looks okay to me, assuming applications on AIX looking at os.version
>> won't be surprised.
>>
>> -Alan



From Roger.Riggs at Oracle.com  Mon Jul 27 14:48:44 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 27 Jul 2015 10:48:44 -0400
Subject: ProcessBuilder support for pipelines
Message-ID: <55B644CC.2020609@Oracle.com>

On most operating systems, creating pipelines of processes is simple and 
direct.
That same function is missing from the Java Process support and can be 
provided by
java.lang.ProcessBuilder by enabling the pipes created for stdout to be
used for standard input when the processes are created.
Comments and feedback are appreciated on the prototype API and 
implementation.

Javadoc:  java.lang.ProcessBuilder.startPipe:
http://cr.openjdk.java.net/~rriggs/pipedoc/java/lang/ProcessBuilder.html#startPipe-java.lang.ProcessBuilder...-

webrev prototype:
   http://cr.openjdk.java.net/~rriggs//webrev-pipeline-8132394

Thanks, Roger



From steve.drach at oracle.com  Mon Jul 27 16:38:06 2015
From: steve.drach at oracle.com (Steve Drach)
Date: Mon, 27 Jul 2015 09:38:06 -0700
Subject: FYI - fix for JDK-8062849 -- Optimize EnumMap.equals
Message-ID: <12F7454C-FED4-46E5-AD98-0646BAC55169@oracle.com>

Hi,

I?ve fixed the issue reported in https://bugs.openjdk.java.net/browse/JDK-8062849 .  It?s been reviewed by Brent Christian and Paul Sandoz.  Both the changeset and webrev.zip are attached.

Steve



From steve.drach at oracle.com  Mon Jul 27 17:31:30 2015
From: steve.drach at oracle.com (Steve Drach)
Date: Mon, 27 Jul 2015 10:31:30 -0700
Subject: FYI - fix for JDK-8062849 -- Optimize EnumMap.equals
In-Reply-To: <12F7454C-FED4-46E5-AD98-0646BAC55169@oracle.com>
References: <12F7454C-FED4-46E5-AD98-0646BAC55169@oracle.com>
Message-ID: 

Well this is strange.  The attachments seem to have been discarded by some part of the mail system.  I will provide them to anyone who requests them.  Sorry for that.

> On Jul 27, 2015, at 9:38 AM, Steve Drach  wrote:
> 
> Hi,
> 
> I?ve fixed the issue reported in https://bugs.openjdk.java.net/browse/JDK-8062849 .  It?s been reviewed by Brent Christian and Paul Sandoz.  Both the changeset and webrev.zip are attached.
> 
> Steve
> 



From Roger.Riggs at Oracle.com  Mon Jul 27 17:43:43 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 27 Jul 2015 13:43:43 -0400
Subject: FYI - fix for JDK-8062849 -- Optimize EnumMap.equals
In-Reply-To: 
References: <12F7454C-FED4-46E5-AD98-0646BAC55169@oracle.com>
	
Message-ID: <55B66DCF.9090001@Oracle.com>

Hi Steve,

Only a few attachment types, all text, are allowed through to core-libs.
The usual technique is to copy the webrev to cr.openjdk.java.net
frequently with scp.

Roger


On 7/27/2015 1:31 PM, Steve Drach wrote:
> Well this is strange.  The attachments seem to have been discarded by some part of the mail system.  I will provide them to anyone who requests them.  Sorry for that.
>
>> On Jul 27, 2015, at 9:38 AM, Steve Drach  wrote:
>>
>> Hi,
>>
>> I?ve fixed the issue reported in https://bugs.openjdk.java.net/browse/JDK-8062849 .  It?s been reviewed by Brent Christian and Paul Sandoz.  Both the changeset and webrev.zip are attached.
>>
>> Steve
>>



From volker.simonis at gmail.com  Mon Jul 27 17:54:27 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 27 Jul 2015 19:54:27 +0200
Subject: RFR(XS): 8132374: AIX: fix value of os.version property
In-Reply-To: <55B632CA.9000905@Oracle.com>
References: 
	<55B62BEF.60504@oracle.com>
	
	<55B632CA.9000905@Oracle.com>
Message-ID: 

Hi Roger,

I've added the requested test. See:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8132374.v1/

I've tested it on Solaris 10/11, Linux SLES 12/Ubuntu 12.04, MaxOS X
10.9 and 10.10, Windows 7 and AIX 7.1
I think it should work on all supported platforms.

OK now?

Regards,
Volker

On Mon, Jul 27, 2015 at 3:31 PM, Roger Riggs  wrote:
> Hi Volker,
>
> I doubt there is a test for any of the OS's but is it possible to write a
> test that would
> compare that string to the version string produced by one of the os provided
> tools.
> For example uname?
>
> Thanks, Roger
>
>
> On 7/27/2015 9:29 AM, Volker Simonis wrote:
>>
>> Thanks, Alan.
>>
>> We've done this correctly in our SAP JVM as well as IBM in their J9
>> but for some reason we've missed the fixed in the initial OpenJDK
>> port.
>>
>> Regards,
>> Volker
>>
>>
>> On Mon, Jul 27, 2015 at 3:02 PM, Alan Bateman 
>> wrote:
>>>
>>>
>>> On 27/07/2015 13:54, Volker Simonis wrote:
>>>>
>>>> Hi,
>>>>
>>>> can somebody please review this tiny fix to get the value of the
>>>> 'os.version' property correct on AIX:
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132374/
>>>> https://bugs.openjdk.java.net/browse/JDK-8132374
>>>>
>>>>
>>> This looks okay to me, assuming applications on AIX looking at os.version
>>> won't be surprised.
>>>
>>> -Alan
>
>


From david.lloyd at redhat.com  Mon Jul 27 18:09:23 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 27 Jul 2015 13:09:23 -0500
Subject: One more minor addition to ProcessBuilder
Message-ID: <55B673D3.3080905@redhat.com>

Roger & co.:

Since you're already on the topic of manipulating pipes, I thought I'd 
mention one very small yet very useful potential enhancement.

It would be very handy to be able to specify a NULL/bit-bucket 
source/destination for pipes.  For the target process' input, the user 
can generally (I believe) just close the stream, but for output, there 
isn't really a good option.  While this is possible to achieve by 
redirecting to /dev/null on UNIX-likes and NUL (iirc) on Windows, having 
to do platform detection to decide where this device is seems overly 
cumbersome.

Having a ProcessBuilder.Redirect#DISCARD or similar would be quite 
useful, and should be fairly straightforward I think.
-- 
- DML


From Roger.Riggs at Oracle.com  Mon Jul 27 18:15:45 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 27 Jul 2015 14:15:45 -0400
Subject: RFR(XS): 8132374: AIX: fix value of os.version property
In-Reply-To: 
References: 
	<55B62BEF.60504@oracle.com>
	
	<55B632CA.9000905@Oracle.com>
	
Message-ID: <55B67551.405@Oracle.com>

Hi Volker,

Yes,  it looks fine. I did'nt know if it was a reasonable request across 
os versions.

Thanks, Roger


On 7/27/2015 1:54 PM, Volker Simonis wrote:
> Hi Roger,
>
> I've added the requested test. See:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132374.v1/
>
> I've tested it on Solaris 10/11, Linux SLES 12/Ubuntu 12.04, MaxOS X
> 10.9 and 10.10, Windows 7 and AIX 7.1
> I think it should work on all supported platforms.
>
> OK now?
>
> Regards,
> Volker
>
> On Mon, Jul 27, 2015 at 3:31 PM, Roger Riggs  wrote:
>> Hi Volker,
>>
>> I doubt there is a test for any of the OS's but is it possible to write a
>> test that would
>> compare that string to the version string produced by one of the os provided
>> tools.
>> For example uname?
>>
>> Thanks, Roger
>>
>>
>> On 7/27/2015 9:29 AM, Volker Simonis wrote:
>>> Thanks, Alan.
>>>
>>> We've done this correctly in our SAP JVM as well as IBM in their J9
>>> but for some reason we've missed the fixed in the initial OpenJDK
>>> port.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Mon, Jul 27, 2015 at 3:02 PM, Alan Bateman 
>>> wrote:
>>>>
>>>> On 27/07/2015 13:54, Volker Simonis wrote:
>>>>> Hi,
>>>>>
>>>>> can somebody please review this tiny fix to get the value of the
>>>>> 'os.version' property correct on AIX:
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132374/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8132374
>>>>>
>>>>>
>>>> This looks okay to me, assuming applications on AIX looking at os.version
>>>> won't be surprised.
>>>>
>>>> -Alan
>>



From martinrb at google.com  Mon Jul 27 18:53:01 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 27 Jul 2015 11:53:01 -0700
Subject: RFR: JDK-8114832 it.next on ArrayList throws wrong type of
	Exception after remove(-1)
In-Reply-To: 
References: <788B7264-C303-4784-9D8A-7D7EFFAC5D43@oracle.com>
	
	
Message-ID: 

On Mon, Jul 27, 2015 at 1:19 AM, Paul Sandoz  wrote:

>
> My guiding principle here was that argument validation should not result
> in side-effects. Thus the state of a collection should remain unchanged if
> an exception is thrown due to an invalid argument of an operation.
>
>
That is indeed a good principle.  All or nothing!

But in the case of modCount, one might consider it to record both actual
and attempted modifications.
I would be OK if we decided to make this consistent across all JDK
implementations.  Currently we don't have any internal policy on this,
although you can read the spec
https://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#modCount
as requiring successful, not attempted modifications.


> ArrayList.remove is inconsistent with regards to nearly all the other
> ArrayList methods, add(int, E) and addAll(int, Collection) for an out of
> bounds index, and addAll(Collection ), removeAll, retainAll, removeIf,
> replaceAll and sort for a null argument. It?s not inconsistent with
> ArrayList.removeRange, except for if an invalid range from > t, but is
> inconsistent with AbstractList.removeRange. It?s also inconsistent
> LinkedList and CopyOnWriteArrayList *and* sub-lists of ArrayList and
> AbstractList. And inconsistent more generally for other Collection
> implementations, such as Queue.add/offer/remove implementations that do not
> accept null values.
>
> The behaviour of ArrayList.remove, and also ArrayList.removeRange, are
> outliers [*]. It?s also a rather obscure difference behaviour with likely
> minimal impact if changed (far less so than the change to Arrays.toList) .
>

I agree that if we make a policy decision here, we can change it and the
compatibility impact is minimal.


From Roger.Riggs at Oracle.com  Mon Jul 27 20:26:53 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 27 Jul 2015 16:26:53 -0400
Subject: Fwd: Re: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: <55B6938E.2010806@Oracle.com>
References: <55B6938E.2010806@Oracle.com>
Message-ID: <55B6940D.90701@Oracle.com>

Hi Volker,

Thanks for the refactoring and the AIX implementation.

We still need a tie-breaker with respect to the issue of 
truncated/incomplete
argument and executable values.

On 7/24/2015 9:30 AM, Volker Simonis wrote:
> Hi,
>
> so here comes the new webrev which cleanly applies to the current
> jdk9-dev/jdk repo:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v2/

Comments:

os_getParentPid() - the function name doesn't reflect the additional 
values returned.
The time units on the starttime and cputime need should appear in the 
function header
without having to refer to the declaration.

os_getParentPid()  - Within this function can the code that accesses the 
sysctl info be kept together.
    Perhaps move the rusage if/block before the if (sysctl) {...}
    Or just move the start time extraction to just before the return pid..

ProcessHandleImpl_unix.c: 138 and 140 - The macros should not include 
the trailing semicolon ";"
(causes a unreachable compilation warning on Solaris 10)

ProcessHandlmpl_unix.c: 401: extra semicolon  ";;"
(causes a warning about declarations after statements on Solaris 10).

691:  Typo: Solris
730: separeted

ProcessHandleImpl_unix:c: 358 - Info_info0 - it appears that the psinfo 
file is read twice.
Once by unix_getUid and again by unix_getCmdLineInfo
One aspect of the original code  was to avoid opening and reading /proc 
files more than once/necessary.

ProcessHandleImpl_unix.c: 691-700 - There is no point in doing a file 
lookup that is
known to fail.  This should be #ifdef/#ifndef'd to apply only to the 
appropriate OS.

!! ProcessHandleImpl_unix: 709-738:  I still disagree with returning 
truncated or incomplete
values for the executable or arguments.
Can anyone be a tie-breaker  (with a good rational and suggestion for 
how an application can use the data).


InfoTest.java: 139:  Is this the best that can be done for checking the 
times on AIX?

InfoTest.java:285 - mentions /proc/pid/status ;  should that be 
/proc/pid/psinfo?

ProcessHandleImpl_linux.c: 63: getUID and getCmdlineInfo both format the 
/proc file
name and do a lookup of the file.  The original version avoided doing 
the lookup twice
in the same native call.    Perhaps there is a refactoring that puts the 
extraction of
the UID in with getting the command line.
This might address the repeated reading of psinfo in 
ProcessHandleImpl_unix:358 as well.

ProcessHandleImpl_unix.h is a new file and only needs a 2015 copyright date.

Somewhere the unixs for the start and cputimes needs to be documented
at the declaration.

That is  first pass on comments.

Thanks, Roger



> The good thing beforehand - although I added the AIX-port and a big
> 50-line comment the new version is still 60 lines shorter :)
>    10 files changed, 829 insertions(+), 999 deletions(-)
>
> The main idea behind the new code layout is as follows (see the
> comment in ProcessHandleImpl_unix.c for more details):
>
> The currently supported Unix variants are Solaris, Linux, MaxOS X
> and AIX. The various similarities and differences between these
> systems make it hard to find a clear boundary between platform
> specific and shared code.
>
> In order to ease code sharing between the platforms while still
> keeping the code as clean as possible (i.e. free of preprocessor
> macros) we use the following source code layout (remember that
> ProcessHandleImpl_unix.c will be compiled on EVERY Unix platform
> while ProcessHandleImpl_.c will be only compiled on the
> specific OS):
>
>   - all the JNI wrappers for the ProcessHandleImpl functions go
>     into ProcessHandleImpl_unix.c file
>
>   - if their implementation is common on ALL the supported Unix
>     platforms it goes right into the JNI wrappers
>
>   - if the whole function or substantial parts of it are platform
>     dependent, the implementation goes into os_
>     functions in ProcessHandleImpl_.c
>
>   - if at least two platforms implement an os_
>     function in the same way, this implementation is factored out
>     into unix_, placed into
>     ProcessHandleImpl_unix.c and called from the corresponding
>     os_ function.
>
>   - For convenience, all the os_ and unix_ functions are declared
>     in ProcessHandleImpl_unix.h which is included into every
>     ProcessHandleImpl_.c file.
>
> So ProcessHandleImpl_unix.c only contains code which is shared by at
> least two platforms. Code which is specific to one single platform
> goes into the corresponding ProcessHandleImpl_.c file (and this
> changes adds ProcessHandleImpl_aix.c for AIX-specific code and
> ProcessHandleImpl_linux.c for Linux-specific code which was in
> ProcessHandleImpl_unix.c previously).
>
> I tried to unify similar functions (e.g.
> Java_java_lang_ProcessHandleImpl_00024Info_initIDs,
> Java_java_lang_ProcessHandleImpl_isAlive0 or fillArgArray) into a
> single instance in ProcessHandleImpl_unix.c.
>
> I renamed and unified getStatInfo() into
> os_getParentPid()/unix_getParentPid() with three implemantions for
> MacOSX, Linux and Solaris/AIX.
>
> I've factored out Java_java_lang_ProcessHandleImpl_getProcessPids0()
> into os_getChildren()/unix_getChildren() with two implemantions - one
> for MacOSX and one for Linux/Solaris/AIX.
>
> I've tested the new implementation on MacOSX, Linux (x86_64 and ppc64)
> , Solaris 10/11 (x86_64 and Sparc) and AIX.
>
> The final point, which was already mentioned in the first review is
> the fact that we can not easily get accurate information fort he
> command line and arguments on AIX. I'd prefer to stay with the current
> solution which gives "best effort" answers for these attributes but if
> everybody?s opinion is that such information is useless I can also
> omit it altogether. I haven?t looked at the other platforms which we
> have to support (e.g. HPUX, AS/400) but the situation may be similar
> there.
>
> Regards,
> Volker
>





From martinrb at google.com  Tue Jul 28 00:28:34 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 27 Jul 2015 17:28:34 -0700
Subject: One more minor addition to ProcessBuilder
In-Reply-To: <55B673D3.3080905@redhat.com>
References: <55B673D3.3080905@redhat.com>
Message-ID: 

Seems reasonable.

On Mon, Jul 27, 2015 at 11:09 AM, David M. Lloyd 
wrote:

> Roger & co.:
>
> Since you're already on the topic of manipulating pipes, I thought I'd
> mention one very small yet very useful potential enhancement.
>
> It would be very handy to be able to specify a NULL/bit-bucket
> source/destination for pipes.  For the target process' input, the user can
> generally (I believe) just close the stream, but for output, there isn't
> really a good option.  While this is possible to achieve by redirecting to
> /dev/null on UNIX-likes and NUL (iirc) on Windows, having to do platform
> detection to decide where this device is seems overly cumbersome.
>
> Having a ProcessBuilder.Redirect#DISCARD or similar would be quite useful,
> and should be fairly straightforward I think.
> --
> - DML
>


From martinrb at google.com  Tue Jul 28 00:48:57 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 27 Jul 2015 17:48:57 -0700
Subject: ProcessBuilder support for pipelines
In-Reply-To: <55B644CC.2020609@Oracle.com>
References: <55B644CC.2020609@Oracle.com>
Message-ID: 

In the past, when I contemplated doing this, I generally thought that there
wasn't enough value in such a feature for the effort, given that one can
start a subprocess shell that supports pipelines.  Does this feature pull
its weight?

You don't need this to re-implement emacs in java, which has always been my
litmus test.  The missing feature is pty support, that y'all are less
likely to add...

On Mon, Jul 27, 2015 at 7:48 AM, Roger Riggs  wrote:

> On most operating systems, creating pipelines of processes is simple and
> direct.
> That same function is missing from the Java Process support and can be
> provided by
> java.lang.ProcessBuilder by enabling the pipes created for stdout to be
> used for standard input when the processes are created.
> Comments and feedback are appreciated on the prototype API and
> implementation.
>
> Javadoc:  java.lang.ProcessBuilder.startPipe:
>
> http://cr.openjdk.java.net/~rriggs/pipedoc/java/lang/ProcessBuilder.html#startPipe-java.lang.ProcessBuilder...-
>
> webrev prototype:
>   http://cr.openjdk.java.net/~rriggs//webrev-pipeline-8132394
>
> Thanks, Roger
>
>


From david.holmes at oracle.com  Tue Jul 28 01:18:44 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 28 Jul 2015 11:18:44 +1000
Subject: FYI - fix for JDK-8062849 -- Optimize EnumMap.equals
In-Reply-To: <12F7454C-FED4-46E5-AD98-0646BAC55169@oracle.com>
References: <12F7454C-FED4-46E5-AD98-0646BAC55169@oracle.com>
Message-ID: <55B6D874.9050102@oracle.com>

Hi Steve,

Is this an FYI or an actual Request for Review? There are processes that 
need to be followed for official reviews prior to pushing. If you don't 
yet have Author status you will need someone to host your webrev on 
cr.openjdk.java.net for you.

Cheers,
David

On 28/07/2015 2:38 AM, Steve Drach wrote:
> Hi,
>
> I?ve fixed the issue reported in https://bugs.openjdk.java.net/browse/JDK-8062849 .  It?s been reviewed by Brent Christian and Paul Sandoz.  Both the changeset and webrev.zip are attached.
>
> Steve
>


From chris.hegarty at oracle.com  Tue Jul 28 08:11:15 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 28 Jul 2015 09:11:15 +0100
Subject: One more minor addition to ProcessBuilder
In-Reply-To: 
References: <55B673D3.3080905@redhat.com>
	
Message-ID: <9151EBE2-E5ED-4559-9E37-7149BF5A7110@oracle.com>


On 28 Jul 2015, at 01:28, Martin Buchholz  wrote:

> Seems reasonable.

Agreed.

-Chris.

> On Mon, Jul 27, 2015 at 11:09 AM, David M. Lloyd 
> wrote:
> 
>> Roger & co.:
>> 
>> Since you're already on the topic of manipulating pipes, I thought I'd
>> mention one very small yet very useful potential enhancement.
>> 
>> It would be very handy to be able to specify a NULL/bit-bucket
>> source/destination for pipes.  For the target process' input, the user can
>> generally (I believe) just close the stream, but for output, there isn't
>> really a good option.  While this is possible to achieve by redirecting to
>> /dev/null on UNIX-likes and NUL (iirc) on Windows, having to do platform
>> detection to decide where this device is seems overly cumbersome.
>> 
>> Having a ProcessBuilder.Redirect#DISCARD or similar would be quite useful,
>> and should be fairly straightforward I think.
>> --
>> - DML
>> 



From chris.hegarty at oracle.com  Tue Jul 28 08:28:05 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 28 Jul 2015 09:28:05 +0100
Subject: ProcessBuilder support for pipelines
In-Reply-To: <55B644CC.2020609@Oracle.com>
References: <55B644CC.2020609@Oracle.com>
Message-ID: <7426949B-AA9A-42F4-A8CC-118F55C77B79@oracle.com>

I find this kinda cute. Seems like a reasonable addition to me.

-Chris.

On 27 Jul 2015, at 15:48, Roger Riggs  wrote:

> On most operating systems, creating pipelines of processes is simple and direct.
> That same function is missing from the Java Process support and can be provided by
> java.lang.ProcessBuilder by enabling the pipes created for stdout to be
> used for standard input when the processes are created.
> Comments and feedback are appreciated on the prototype API and implementation.
> 
> Javadoc:  java.lang.ProcessBuilder.startPipe:
> http://cr.openjdk.java.net/~rriggs/pipedoc/java/lang/ProcessBuilder.html#startPipe-java.lang.ProcessBuilder...-
> 
> webrev prototype:
>  http://cr.openjdk.java.net/~rriggs//webrev-pipeline-8132394
> 
> Thanks, Roger
> 



From amaembo at gmail.com  Tue Jul 28 08:37:38 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Tue, 28 Jul 2015 14:37:38 +0600
Subject: Custom spliterator for Collections.nCopies(n, obj).stream()
Message-ID: <1767952446.20150728143738@gmail.com>

Hello!

Current implementation of Collections.nCopies().stream() is as
follows:

http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/Collections.java#l5066

public Stream stream() {
    return IntStream.range(0, n).mapToObj(i -> element);
}

@Override
public Stream parallelStream() {
    return IntStream.range(0, n).parallel().mapToObj(i -> element);
}

The problem is that it adds a lambda expression to the
RangeIntSpliterator type profile which can be polluted by some other
code and vice versa: using nCopies().stream() may pollute the type
profile for other code making it slower.

Another thing which is missing in current implementation is unordered
mode. This collection is unordered by nature, its stream is similar to
Stream.generate(), so to my opinion it should be unordered which may
improve the parallel reduction in some cases.

This can be improved by introducing the custom spliterator class which
is quite simple:
https://gist.github.com/amaembo/62f3efee9923b1468e86

On pre-polluted type profile with simple mapping and reduction using
custom spliterator is about 25-30% faster in both parallel and
sequential cases as benchmarking shows (performed on 4-core cpu).

What do you think?

With best regards,
Tagir Valeev.



From amaembo at gmail.com  Tue Jul 28 08:48:18 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Tue, 28 Jul 2015 14:48:18 +0600
Subject: References to non-existing methods in java.util.stream comments
Message-ID: <903568319.20150728144818@gmail.com>

Hello!

Although it's not the part of public API, there are references to
non-existing methods in SliceOps.java and Streams.java:

http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/stream/SliceOps.java#l141
// @@@ OOMEs will occur for LongStream.longs().filter(i -> true).limit(n)

http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/stream/Streams.java#l283
* 
This is optimized for cases such as LongStream.longs() that is ...

There's no method like LongStream.longs().

http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/stream/Streams.java#l159
* 
This is optimized for cases such as IntStream.ints() that is ...

There's no method like IntStream.ints().

Probably these comments should be changed to avoid confusion.

With best regards,
Tagir Valeev.



From fweimer at redhat.com  Tue Jul 28 09:36:04 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 28 Jul 2015 11:36:04 +0200
Subject: ProcessBuilder support for pipelines
In-Reply-To: 
References: <55B644CC.2020609@Oracle.com>
	
Message-ID: <55B74D04.602@redhat.com>

On 07/28/2015 02:48 AM, Martin Buchholz wrote:
> In the past, when I contemplated doing this, I generally thought that there
> wasn't enough value in such a feature for the effort, given that one can
> start a subprocess shell that supports pipelines.  Does this feature pull
> its weight?

Feeding program arguments to command spawned by a shell is difficult.
There is also no good way to obtain the exit status of the first command
in the pipe.  The last command in the pipe determines the shell exit
status, and earlier commands are ignored.

-- 
Florian Weimer / Red Hat Product Security


From chuansheng.lcs at alibaba-inc.com  Tue Jul 28 09:50:46 2015
From: chuansheng.lcs at alibaba-inc.com (=?UTF-8?B?6ZmG5Lyg6IOcKOS8oOiDnCk=?=)
Date: Tue, 28 Jul 2015 17:50:46 +0800
Subject: =?UTF-8?B?UkZSOiA4MTMyNDU5OiBFeGNlcHRpb25JbkluaXRpYWxpemVyRXJyb3IgZnJvbSAnamF2YSAt?=
	=?UTF-8?B?dmVyc2lvbicgb24gTGludXggdW5kZXIgemhfQ04uR0IxODAzMCBsb2NhbGU=?=
In-Reply-To: ----3M------n0YZM$84b047e2-9e11-410d-83a3-6a2a2946b2ba@alibaba.com
References: ----3M------n0YZM$84b047e2-9e11-410d-83a3-6a2a2946b2ba@alibaba.com
Message-ID: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>

Hello,

?

The issue
was found on one of my Linux boxes which uses locale zh_CN.GB18030 by default,

a simple
patch was made to fix it, may I have it reviewed ?

?

webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/

bug: https://bugs.openjdk.java.net/browse/JDK-8132459

?

JBS seems to be down
right now, so just put
related info in this mail.




The problem relates to bug JDK-8038310, and below simple command
will reproduce it,


LANG=zh_CN.GB18030
jdk9/bin/java -version

?

The error message is:

Error occurred
during initialization of VM

java.lang.ExceptionInInitializerError

at
java.nio.charset.Charset.lookupExtendedCharset(Charset.java:449)

at
java.nio.charset.Charset.lookup2(Charset.java:479)

at
java.nio.charset.Charset.lookup(Charset.java:467)

at
java.nio.charset.Charset.isSupported(Charset.java:508)

at
java.io.UnixFileSystem.getBooleanAttributes0(Native Method)

at
java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)

at
java.io.File.isDirectory(File.java:849)

at
sun.misc.Launcher$BootClassPathHolder$1.run(Launcher.java:329)

at
sun.misc.Launcher$BootClassPathHolder$1.run(Launcher.java:316)

at
java.security.AccessController.doPrivileged(Native Method)

at
sun.misc.Launcher$BootClassPathHolder.(Launcher.java:315)

at
sun.misc.Launcher.(Launcher.java:60)

at
java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1443)

at
java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1428)

Caused by:
java.lang.NullPointerException

at
java.lang.ClassLoader.getBootstrapResources(ClassLoader.java:1267)

at
java.lang.ClassLoader.getSystemResources(ClassLoader.java:1246)

at
java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:344)

at
java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:391)

at
java.util.ServiceLoader$1.hasNext(ServiceLoader.java:472)

at
java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:435)

at
java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:429)

at
java.security.AccessController.doPrivileged(Native Method)

at
java.nio.charset.Charset$ExtendedProviderHolder.extendedProviders(Charset.java:429)

at
java.nio.charset.Charset$ExtendedProviderHolder.(Charset.java:426)

at
java.nio.charset.Charset.lookupExtendedCharset(Charset.java:449)

at
java.nio.charset.Charset.lookup2(Charset.java:479)

at
java.nio.charset.Charset.lookup(Charset.java:467)

at
java.nio.charset.Charset.isSupported(Charset.java:508)

at
java.io.UnixFileSystem.getBooleanAttributes0(Native Method)

at
java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)

at
java.io.File.isDirectory(File.java:849)

at
sun.misc.Launcher$BootClassPathHolder$1.run(Launcher.java:329)

at
sun.misc.Launcher$BootClassPathHolder$1.run(Launcher.java:316)

at
java.security.AccessController.doPrivileged(Native Method)

at
sun.misc.Launcher$BootClassPathHolder.(Launcher.java:315)

at
sun.misc.Launcher.(Launcher.java:60)

at
java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1443)

at
java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1428)

?

?

Thanks

Jonathan Lu









From paul.sandoz at oracle.com  Tue Jul 28 11:19:23 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 28 Jul 2015 13:19:23 +0200
Subject: References to non-existing methods in java.util.stream comments
In-Reply-To: <903568319.20150728144818@gmail.com>
References: <903568319.20150728144818@gmail.com>
Message-ID: <7BBD74BF-6BD3-46E9-95FB-2348EC2F1105@oracle.com>


On 28 Jul 2015, at 10:48, Tagir F. Valeev  wrote:

> Hello!
> 
> Although it's not the part of public API, there are references to
> non-existing methods in SliceOps.java and Streams.java:
> 
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/stream/SliceOps.java#l141
> // @@@ OOMEs will occur for LongStream.longs().filter(i -> true).limit(n)
> 
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/stream/Streams.java#l283
> * 
This is optimized for cases such as LongStream.longs() that is ...
> 
> There's no method like LongStream.longs().
> 
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/stream/Streams.java#l159
> * 
This is optimized for cases such as IntStream.ints() that is ...
> 
> There's no method like IntStream.ints().
> 
> Probably these comments should be changed to avoid confusion.
> 

Thanks. The comments should be updated to refer to the Long/IntStream.range(0, Long/Integer.MAX_VALUE).

Paul.

> With best regards,
> Tagir Valeev.
> 



From paul.sandoz at oracle.com  Tue Jul 28 12:50:02 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 28 Jul 2015 14:50:02 +0200
Subject: RFR: JDK-8114832 it.next on ArrayList throws wrong type of
	Exception after remove(-1)
In-Reply-To: 
References: <788B7264-C303-4784-9D8A-7D7EFFAC5D43@oracle.com>
	
	
	
Message-ID: 

On 27 Jul 2015, at 20:53, Martin Buchholz  wrote:
> 
> 
> On Mon, Jul 27, 2015 at 1:19 AM, Paul Sandoz  wrote:
> 
> My guiding principle here was that argument validation should not result in side-effects. Thus the state of a collection should remain unchanged if an exception is thrown due to an invalid argument of an operation.
> 
> 
> That is indeed a good principle.  All or nothing!
> 
> But in the case of modCount, one might consider it to record both actual and attempted modifications.
> I would be OK if we decided to make this consistent across all JDK implementations.  Currently we don't have any internal policy on this, although you can read the spec
> https://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#modCount
> as requiring successful, not attempted modifications.

I just implicitly assumed that was always the case :-) as i assume did many core library implementors.


> 
> ArrayList.remove is inconsistent with regards to nearly all the other ArrayList methods, add(int, E) and addAll(int, Collection) for an out of bounds index, and addAll(Collection ), removeAll, retainAll, removeIf, replaceAll and sort for a null argument. It?s not inconsistent with ArrayList.removeRange, except for if an invalid range from > t, but is inconsistent with AbstractList.removeRange. It?s also inconsistent LinkedList and CopyOnWriteArrayList *and* sub-lists of ArrayList and AbstractList. And inconsistent more generally for other Collection implementations, such as Queue.add/offer/remove implementations that do not accept null values.
> 
> The behaviour of ArrayList.remove, and also ArrayList.removeRange, are outliers [*]. It?s also a rather obscure difference behaviour with likely minimal impact if changed (far less so than the change to Arrays.toList) .
> 
> I agree that if we make a policy decision here, we can change it and the compatibility impact is minimal.


Since there already exists an implicit policy governed by like 99.9% of the existing behaviour i do not see the need to be explicit about that policy for this particular issue, so i suggest we split into two.

Paul.


From paul.sandoz at oracle.com  Tue Jul 28 13:01:57 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 28 Jul 2015 15:01:57 +0200
Subject: Custom spliterator for Collections.nCopies(n, obj).stream()
In-Reply-To: <1767952446.20150728143738@gmail.com>
References: <1767952446.20150728143738@gmail.com>
Message-ID: <9B7C4E11-5FA7-4EEC-9A5F-929AF1DAAE9D@oracle.com>

Hi Tagir,

I would agree with you out about changing to use unordered() except that it is a List that is returned, whose Spliterator is specified to report ORDERED.

I don?t particular want to add a special spliterator for this case to avoid some profile pollution. Will it not just push the pollution further down the road to Spliterator.forEachRemaining? or to within other code?

Alas i think profile pollution is current fact of JDK life when inverting control with lambdas. What we really require is a better way to specialise the hot loops.

Paul.

On 28 Jul 2015, at 10:37, Tagir F. Valeev  wrote:

> Hello!
> 
> Current implementation of Collections.nCopies().stream() is as
> follows:
> 
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/Collections.java#l5066
> 
> public Stream stream() {
>    return IntStream.range(0, n).mapToObj(i -> element);
> }
> 
> @Override
> public Stream parallelStream() {
>    return IntStream.range(0, n).parallel().mapToObj(i -> element);
> }
> 
> The problem is that it adds a lambda expression to the
> RangeIntSpliterator type profile which can be polluted by some other
> code and vice versa: using nCopies().stream() may pollute the type
> profile for other code making it slower.
> 
> Another thing which is missing in current implementation is unordered
> mode. This collection is unordered by nature, its stream is similar to
> Stream.generate(), so to my opinion it should be unordered which may
> improve the parallel reduction in some cases.
> 
> This can be improved by introducing the custom spliterator class which
> is quite simple:
> https://gist.github.com/amaembo/62f3efee9923b1468e86
> 
> On pre-polluted type profile with simple mapping and reduction using
> custom spliterator is about 25-30% faster in both parallel and
> sequential cases as benchmarking shows (performed on 4-core cpu).
> 
> What do you think?
> 
> With best regards,
> Tagir Valeev.
> 



From Roger.Riggs at Oracle.com  Tue Jul 28 13:29:46 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 28 Jul 2015 09:29:46 -0400
Subject: ProcessBuilder support for pipelines
In-Reply-To: 
References: <55B644CC.2020609@Oracle.com>
	
Message-ID: <55B783CA.6030305@Oracle.com>

Hi Martin,

Doing the plumbing for this is pretty minimal as you've noticed from the 
webrev.
No native code is modified and it extends the existing redirect logic.
I think this is pretty useful and cheap and will work across platforms.

I use emacs every day too but somehow it seems dated.

Roger


On 7/27/2015 8:48 PM, Martin Buchholz wrote:
> In the past, when I contemplated doing this, I generally thought that 
> there wasn't enough value in such a feature for the effort, given that 
> one can start a subprocess shell that supports pipelines.  Does this 
> feature pull its weight?
>
> You don't need this to re-implement emacs in java, which has always 
> been my litmus test.  The missing feature is pty support, that y'all 
> are less likely to add...
>
> On Mon, Jul 27, 2015 at 7:48 AM, Roger Riggs  > wrote:
>
>     On most operating systems, creating pipelines of processes is
>     simple and direct.
>     That same function is missing from the Java Process support and
>     can be provided by
>     java.lang.ProcessBuilder by enabling the pipes created for stdout
>     to be
>     used for standard input when the processes are created.
>     Comments and feedback are appreciated on the prototype API and
>     implementation.
>
>     Javadoc:  java.lang.ProcessBuilder.startPipe:
>     http://cr.openjdk.java.net/~rriggs/pipedoc/java/lang/ProcessBuilder.html#startPipe-java.lang.ProcessBuilder...-
>     
>
>     webrev prototype:
>     http://cr.openjdk.java.net/~rriggs//webrev-pipeline-8132394
>     
>
>     Thanks, Roger
>
>



From Roger.Riggs at Oracle.com  Tue Jul 28 13:35:19 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 28 Jul 2015 09:35:19 -0400
Subject: One more minor addition to ProcessBuilder
In-Reply-To: <55B673D3.3080905@redhat.com>
References: <55B673D3.3080905@redhat.com>
Message-ID: <55B78517.1080803@Oracle.com>

Hi David,

ok,  it seems very minimal if implemented like a writeable file:

      public static abstract class Redirect {
+        private static final File nullFile = AccessController.doPrivileged(
+                (PrivilegedAction) () -> {
+                    return new File((System.getProperty("os.name")
+                            .startsWith("Windows") ? "NUL" : "/dev/null"));
+                }
+        );
+

...
+
+        /**
+         * Indicates that subprocess output will be discarded by writting
+         * to the null device.
+         *
+         * 
It will always be true that
+         * 
 {@code
+         * Redirect.DISCARD.file() the null filename appropriate for the OS
+         * Redirect.DISCARD.type() == Redirect.Type.WRITE &&
+         * Redirect.DISCARD.append() == false
+         * }

+         */
+        public static final Redirect DISCARD = new Redirect() {
+                public Type type() { return Type.WRITE; }
+                public String toString() { return type().toString(); }
+                public File file() { return nullFile; }
+                boolean append() { return false; }
+        };
+

You're welcome to drive the addition yourself.
In some cases, writing the tests can take more time than the feature.

Roger


On 7/27/2015 2:09 PM, David M. Lloyd wrote:
> Roger & co.:
>
> Since you're already on the topic of manipulating pipes, I thought I'd 
> mention one very small yet very useful potential enhancement.
>
> It would be very handy to be able to specify a NULL/bit-bucket 
> source/destination for pipes.  For the target process' input, the user 
> can generally (I believe) just close the stream, but for output, there 
> isn't really a good option.  While this is possible to achieve by 
> redirecting to /dev/null on UNIX-likes and NUL (iirc) on Windows, 
> having to do platform detection to decide where this device is seems 
> overly cumbersome.
>
> Having a ProcessBuilder.Redirect#DISCARD or similar would be quite 
> useful, and should be fairly straightforward I think.



From Alan.Bateman at oracle.com  Tue Jul 28 13:48:24 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 28 Jul 2015 14:48:24 +0100
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version'
	on Linux under zh_CN.GB18030 locale
In-Reply-To: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
References: ----3M------n0YZM$84b047e2-9e11-410d-83a3-6a2a2946b2ba@alibaba.com
	<----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
Message-ID: <55B78828.6000600@oracle.com>

On 28/07/2015 10:50, ???(??) wrote:
> Hello,
>
>   
>
> The issue
> was found on one of my Linux boxes which uses locale zh_CN.GB18030 by default,
>
> a simple
> patch was made to fix it, may I have it reviewed ?
>
>   
>
> webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8132459
>
I hope Sherman will have time to look at this and say whether GB18030 is 
supposed java.base and so be listed in 
jdk/make/data/charsetmapping/stdcs-linux.

My concern with this change is that it's bringing back code that was 
deliberately removed as part of JDK-8038310. We want clean separation of 
the java.base and jdk.charsets modules so that charsets that are needed 
for startup in supported locales to be in java.base. Anything that is 
not needed in java.base goes to jdk.charsets and is loaded via the 
extended charset provider.

-Alan.


From daniel.fuchs at oracle.com  Tue Jul 28 15:22:16 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 28 Jul 2015 17:22:16 +0200
Subject: RfR - 8130059: jaxp: Investigate removal of
	com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
Message-ID: <55B79E28.5070702@oracle.com>

Hi,

Please find below a fix for yet another cleanup for jaxp:

8130059: jaxp: Investigate removal of
          com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
https://bugs.openjdk.java.net/browse/JDK-8130059

http://cr.openjdk.java.net/~dfuchs/webrev_8130059/webrev.00/

EnvironmentCheck doesn't seem to serve any purpose in JDK 9.
It is not called anywhere. The proposal is to remove it.
By doing a full grep on the JDK I also identified another
unused class (Hashtree2Node.java) which referred to EnvironmentCheck
inside a comment.
I took the liberty to remove that class as well.

As for the latter cleanup, what triggered this is that EnvironmentCheck
is using sun.boot.class.path...

best regards,

-- daniel


From steve.drach at oracle.com  Tue Jul 28 16:14:22 2015
From: steve.drach at oracle.com (Steve Drach)
Date: Tue, 28 Jul 2015 09:14:22 -0700
Subject: RFR: JDK-8062849 -- Optimize EnumMap.equals
Message-ID: <4DCE139D-0D61-4A88-AED8-F26C18B9A6D3@oracle.com>

Please review the following simple fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8062849 .

-----------------
# HG changeset patch
# User sdrach
# Date 1437777193 25200
#      Fri Jul 24 15:33:13 2015 -0700
# Node ID e57b1569a65ec4dc8c749dedd3345abe5d493054
# Parent  4dd09cb5f7c2a2a23a9958ea7a602dd74d5709b2
8062849: Optimize EnumMap.equals
Summary: In the equals method, if the two EnumMaps are a different size return false since they can't be equal.
Reviewed-by: brent.christian at oracle.com, paul.sandoz at oracle.com
Contributed-by: steve.drach at oracle.com

diff --git a/src/java.base/share/classes/java/util/EnumMap.java b/src/java.base/share/classes/java/util/EnumMap.java
--- a/src/java.base/share/classes/java/util/EnumMap.java
+++ b/src/java.base/share/classes/java/util/EnumMap.java
@@ -681,8 +681,11 @@
     }
 
     private boolean equals(EnumMap em) {
+        if (size != em.size)
+            return false;
+
         if (em.keyType != keyType)
-            return size == 0 && em.size == 0;
+            return size == 0;
 
         // Key types match, compare each value
         for (int i = 0; i < keyUniverse.length; i++) {



From martinrb at google.com  Tue Jul 28 16:21:57 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 28 Jul 2015 09:21:57 -0700
Subject: RFR: JDK-8062849 -- Optimize EnumMap.equals
In-Reply-To: <4DCE139D-0D61-4A88-AED8-F26C18B9A6D3@oracle.com>
References: <4DCE139D-0D61-4A88-AED8-F26C18B9A6D3@oracle.com>
Message-ID: 

Looks good.

It would be slightly more consistent with original author's style to write

if (em.size != size)

On Tue, Jul 28, 2015 at 9:14 AM, Steve Drach  wrote:

> Please review the following simple fix for the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8062849 <
> https://bugs.openjdk.java.net/browse/JDK-8062849>.
>
> -----------------
> # HG changeset patch
> # User sdrach
> # Date 1437777193 25200
> #      Fri Jul 24 15:33:13 2015 -0700
> # Node ID e57b1569a65ec4dc8c749dedd3345abe5d493054
> # Parent  4dd09cb5f7c2a2a23a9958ea7a602dd74d5709b2
> 8062849: Optimize EnumMap.equals
> Summary: In the equals method, if the two EnumMaps are a different size
> return false since they can't be equal.
> Reviewed-by: brent.christian at oracle.com, paul.sandoz at oracle.com
> Contributed-by: steve.drach at oracle.com
>
> diff --git a/src/java.base/share/classes/java/util/EnumMap.java
> b/src/java.base/share/classes/java/util/EnumMap.java
> --- a/src/java.base/share/classes/java/util/EnumMap.java
> +++ b/src/java.base/share/classes/java/util/EnumMap.java
> @@ -681,8 +681,11 @@
>      }
>
>      private boolean equals(EnumMap em) {
> +        if (size != em.size)
> +            return false;
> +
>          if (em.keyType != keyType)
> -            return size == 0 && em.size == 0;
> +            return size == 0;
>
>          // Key types match, compare each value
>          for (int i = 0; i < keyUniverse.length; i++) {
>
>


From martinrb at google.com  Tue Jul 28 16:46:54 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 28 Jul 2015 09:46:54 -0700
Subject: ProcessBuilder support for pipelines
In-Reply-To: <55B74D04.602@redhat.com>
References: <55B644CC.2020609@Oracle.com>
	
	<55B74D04.602@redhat.com>
Message-ID: 

On Tue, Jul 28, 2015 at 2:36 AM, Florian Weimer  wrote:

> On 07/28/2015 02:48 AM, Martin Buchholz wrote:
> > In the past, when I contemplated doing this, I generally thought that
> there
> > wasn't enough value in such a feature for the effort, given that one can
> > start a subprocess shell that supports pipelines.  Does this feature pull
> > its weight?
>
> Feeding program arguments to command spawned by a shell is difficult.
>

You know what would actually be really useful?

String shellQuote(List args)

but that is Unix-shell specific, so historically difficult to convince JDK
maintainers to add.  But culture has changed towards the pragmatic...

I've already written such a thing, but not in Java.

There is also no good way to obtain the exit status of the first command
> in the pipe.  The last command in the pipe determines the shell exit
> status, and earlier commands are ignored.
>

Well, bash does have the "pipefail" feature.


From volker.simonis at gmail.com  Tue Jul 28 16:51:38 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 28 Jul 2015 18:51:38 +0200
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version' on
	Linux under zh_CN.GB18030 locale
In-Reply-To: <55B78828.6000600@oracle.com>
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
Message-ID: 

Hi Jonathan, Alan,

this is a known problem and we've already discussed it intensively.

Please have a look at:

8081674: EmptyStackException at startup if running with extended or
unsupported charset
https://bugs.openjdk.java.net/browse/JDK-8081674

and:

8087161: Fails to start up initialize system class loader running on
unsupported charset
https://bugs.openjdk.java.net/browse/JDK-8087161

8081674 has a long discussion and also detailed description on how
this can be reproduced.
@Jonathan: the problem with your test case is that it is not enough to
only set the appropriate locale, you also have to make sure that the
locale is installed (see bug discussion for more details). 8081674
finally only fixed a part of the problem and left the rest for
8087161.

The mailing list thread about this issue can be found here:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/thread.html#33879

As your bug is an exact copy of 8087161 I've closed it as duplicate.

Regards,
Volker


On Tue, Jul 28, 2015 at 3:48 PM, Alan Bateman  wrote:
> On 28/07/2015 10:50, ???(??) wrote:
>>
>> Hello,
>>
>>
>> The issue
>> was found on one of my Linux boxes which uses locale zh_CN.GB18030 by
>> default,
>>
>> a simple
>> patch was made to fix it, may I have it reviewed ?
>>
>>
>> webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8132459
>>
> I hope Sherman will have time to look at this and say whether GB18030 is
> supposed java.base and so be listed in
> jdk/make/data/charsetmapping/stdcs-linux.
>
> My concern with this change is that it's bringing back code that was
> deliberately removed as part of JDK-8038310. We want clean separation of the
> java.base and jdk.charsets modules so that charsets that are needed for
> startup in supported locales to be in java.base. Anything that is not needed
> in java.base goes to jdk.charsets and is loaded via the extended charset
> provider.
>
> -Alan.


From huizhe.wang at oracle.com  Tue Jul 28 17:20:39 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 28 Jul 2015 10:20:39 -0700
Subject: RfR - 8130059: jaxp: Investigate removal of
	com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
In-Reply-To: <55B79E28.5070702@oracle.com>
References: <55B79E28.5070702@oracle.com>
Message-ID: <55B7B9E7.3060008@oracle.com>

Hi Daniel,


On 7/28/2015 8:22 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for yet another cleanup for jaxp:

Thanks for yet another cleanup! And, there is a lot more to come :-)
>
> 8130059: jaxp: Investigate removal of
> com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
> https://bugs.openjdk.java.net/browse/JDK-8130059
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8130059/webrev.00/
>
> EnvironmentCheck doesn't seem to serve any purpose in JDK 9.

Agree. It'd be a confusion more than anything else if used since it 
produces many irrelevant information.

> It is not called anywhere. The proposal is to remove it.
> By doing a full grep on the JDK I also identified another
> unused class (Hashtree2Node.java) which referred to EnvironmentCheck
> inside a comment.
> I took the liberty to remove that class as well.

Ok.  The webrev looks good to me. If you'd want to remove the two 
Version classes as shown in the test, that would be fine with me too. 
Then you could remove the whole test.

Best regards,
Joe

>
> As for the latter cleanup, what triggered this is that EnvironmentCheck
> is using sun.boot.class.path...
>
> best regards,
>
> -- daniel



From daniel.fuchs at oracle.com  Tue Jul 28 17:32:15 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 28 Jul 2015 19:32:15 +0200
Subject: RfR - 8130059: jaxp: Investigate removal of
	com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
In-Reply-To: <55B7B9E7.3060008@oracle.com>
References: <55B79E28.5070702@oracle.com> <55B7B9E7.3060008@oracle.com>
Message-ID: <55B7BC9F.8030401@oracle.com>

On 28/07/15 19:20, huizhe wang wrote:
> Hi Daniel,
>
>
> On 7/28/2015 8:22 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a fix for yet another cleanup for jaxp:
>
> Thanks for yet another cleanup! And, there is a lot more to come :-)
>>
>> 8130059: jaxp: Investigate removal of
>> com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
>> https://bugs.openjdk.java.net/browse/JDK-8130059
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8130059/webrev.00/
>>
>> EnvironmentCheck doesn't seem to serve any purpose in JDK 9.
>
> Agree. It'd be a confusion more than anything else if used since it
> produces many irrelevant information.
>
>> It is not called anywhere. The proposal is to remove it.
>> By doing a full grep on the JDK I also identified another
>> unused class (Hashtree2Node.java) which referred to EnvironmentCheck
>> inside a comment.
>> I took the liberty to remove that class as well.
>
> Ok.  The webrev looks good to me. If you'd want to remove the two
> Version classes as shown in the test, that would be fine with me too.
> Then you could remove the whole test.

Thanks Joe!

One of the two version classes (xalan) is used by ...xslt.Process.java
I already logged another bug to investigate removing that as
well (JDK-8130058).

Maybe we should remove the two versions classes as part of that
other bug? Or I could update my webrev to just remove the xerces
Version.java now, which as far as I can see is not called anywhere.

As you prefer :-)

cheers,

-- daniel

>
> Best regards,
> Joe
>
>>
>> As for the latter cleanup, what triggered this is that EnvironmentCheck
>> is using sun.boot.class.path...
>>
>> best regards,
>>
>> -- daniel
>



From huizhe.wang at oracle.com  Tue Jul 28 18:15:28 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 28 Jul 2015 11:15:28 -0700
Subject: RfR - 8130059: jaxp: Investigate removal of
	com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
In-Reply-To: <55B7BC9F.8030401@oracle.com>
References: <55B79E28.5070702@oracle.com> <55B7B9E7.3060008@oracle.com>
	<55B7BC9F.8030401@oracle.com>
Message-ID: <55B7C6C0.5030108@oracle.com>


On 7/28/2015 10:32 AM, Daniel Fuchs wrote:
> On 28/07/15 19:20, huizhe wang wrote:
>> Hi Daniel,
>>
>>
>> On 7/28/2015 8:22 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a fix for yet another cleanup for jaxp:
>>
>> Thanks for yet another cleanup! And, there is a lot more to come :-)
>>>
>>> 8130059: jaxp: Investigate removal of
>>> com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
>>> https://bugs.openjdk.java.net/browse/JDK-8130059
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8130059/webrev.00/
>>>
>>> EnvironmentCheck doesn't seem to serve any purpose in JDK 9.
>>
>> Agree. It'd be a confusion more than anything else if used since it
>> produces many irrelevant information.
>>
>>> It is not called anywhere. The proposal is to remove it.
>>> By doing a full grep on the JDK I also identified another
>>> unused class (Hashtree2Node.java) which referred to EnvironmentCheck
>>> inside a comment.
>>> I took the liberty to remove that class as well.
>>
>> Ok.  The webrev looks good to me. If you'd want to remove the two
>> Version classes as shown in the test, that would be fine with me too.
>> Then you could remove the whole test.
>
> Thanks Joe!
>
> One of the two version classes (xalan) is used by ...xslt.Process.java
> I already logged another bug to investigate removing that as
> well (JDK-8130058).

Great!
>
> Maybe we should remove the two versions classes as part of that
> other bug? Or I could update my webrev to just remove the xerces
> Version.java now, which as far as I can see is not called anywhere.
>
> As you prefer :-)

I agree as you planned, considering removing the two version classes in 
JDK-8130058.

Cheers :-)

Joe

>
> cheers,
>
> -- daniel
>
>>
>> Best regards,
>> Joe
>>
>>>
>>> As for the latter cleanup, what triggered this is that EnvironmentCheck
>>> is using sun.boot.class.path...
>>>
>>> best regards,
>>>
>>> -- daniel
>>
>



From volker.simonis at gmail.com  Tue Jul 28 18:32:43 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 28 Jul 2015 20:32:43 +0200
Subject: RFR(XS): 8132475 : The commands in the modular images are executable
	by the owner only (once again)
Message-ID: 

Hi,

could you please review this tiny change:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8132475/
https://bugs.openjdk.java.net/browse/JDK-8132475

After "8080511: Refresh of jimage support" the executable commands in
jdk/bin and jre/bin are only executable by the file owner. This means
that only the user who built the images can execute the programs.

The fix is trivial, but I've also added a test now so this won't
happen a third time :)

Thank you and best regards,
Volker


From Roger.Riggs at Oracle.com  Tue Jul 28 18:54:33 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 28 Jul 2015 14:54:33 -0400
Subject: RFR(XS): 8132475 : The commands in the modular images are
	executable by the owner only (once again)
In-Reply-To: 
References: 
Message-ID: <55B7CFE9.4010403@Oracle.com>

Hi Volker,

Looks good, and thanks for the test.

Roger


On 7/28/2015 2:32 PM, Volker Simonis wrote:
> Hi,
>
> could you please review this tiny change:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132475/
> https://bugs.openjdk.java.net/browse/JDK-8132475
>
> After "8080511: Refresh of jimage support" the executable commands in
> jdk/bin and jre/bin are only executable by the file owner. This means
> that only the user who built the images can execute the programs.
>
> The fix is trivial, but I've also added a test now so this won't
> happen a third time :)
>
> Thank you and best regards,
> Volker



From Alan.Bateman at oracle.com  Tue Jul 28 20:04:58 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 28 Jul 2015 21:04:58 +0100
Subject: RFR(XS): 8132475 : The commands in the modular images are
	executable by the owner only (once again)
In-Reply-To: 
References: 
Message-ID: <55B7E06A.8070508@oracle.com>

On 28/07/2015 19:32, Volker Simonis wrote:
> Hi,
>
> could you please review this tiny change:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132475/
> https://bugs.openjdk.java.net/browse/JDK-8132475
>
> After "8080511: Refresh of jimage support" the executable commands in
> jdk/bin and jre/bin are only executable by the file owner. This means
> that only the user who built the images can execute the programs.
>
> The fix is trivial, but I've also added a test now so this won't
> happen a third time :)
>
This is a new image writer, it's different to what was there previously.

I assume the test can't run if the permissions are not right :-)

-Alan.


From xueming.shen at oracle.com  Tue Jul 28 20:56:43 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 28 Jul 2015 13:56:43 -0700
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version'
	on Linux under zh_CN.GB18030 locale
In-Reply-To: 
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>	<55B78828.6000600@oracle.com>
	
Message-ID: <55B7EC8B.8000508@oracle.com>

yes, gb18030 needs to be in linux/unix std-solaris/unix as well.

-sherman

On 07/28/2015 09:51 AM, Volker Simonis wrote:
> Hi Jonathan, Alan,
>
> this is a known problem and we've already discussed it intensively.
>
> Please have a look at:
>
> 8081674: EmptyStackException at startup if running with extended or
> unsupported charset
> https://bugs.openjdk.java.net/browse/JDK-8081674
>
> and:
>
> 8087161: Fails to start up initialize system class loader running on
> unsupported charset
> https://bugs.openjdk.java.net/browse/JDK-8087161
>
> 8081674 has a long discussion and also detailed description on how
> this can be reproduced.
> @Jonathan: the problem with your test case is that it is not enough to
> only set the appropriate locale, you also have to make sure that the
> locale is installed (see bug discussion for more details). 8081674
> finally only fixed a part of the problem and left the rest for
> 8087161.
>
> The mailing list thread about this issue can be found here:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/thread.html#33879
>
> As your bug is an exact copy of 8087161 I've closed it as duplicate.
>
> Regards,
> Volker
>
>
> On Tue, Jul 28, 2015 at 3:48 PM, Alan Bateman  wrote:
>> On 28/07/2015 10:50, ???(??) wrote:
>>> Hello,
>>>
>>>
>>> The issue
>>> was found on one of my Linux boxes which uses locale zh_CN.GB18030 by
>>> default,
>>>
>>> a simple
>>> patch was made to fix it, may I have it reviewed ?
>>>
>>>
>>> webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132459
>>>
>> I hope Sherman will have time to look at this and say whether GB18030 is
>> supposed java.base and so be listed in
>> jdk/make/data/charsetmapping/stdcs-linux.
>>
>> My concern with this change is that it's bringing back code that was
>> deliberately removed as part of JDK-8038310. We want clean separation of the
>> java.base and jdk.charsets modules so that charsets that are needed for
>> startup in supported locales to be in java.base. Anything that is not needed
>> in java.base goes to jdk.charsets and is loaded via the extended charset
>> provider.
>>
>> -Alan.



From xueming.shen at oracle.com  Tue Jul 28 21:11:17 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 28 Jul 2015 14:11:17 -0700
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version'
	on Linux under zh_CN.GB18030 locale
In-Reply-To: 
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>	<55B78828.6000600@oracle.com>
	
Message-ID: <55B7EFF5.5030006@oracle.com>

Volker,

If fine with you I will re-open  the gb18080 specific bug and fix it by adding the gb18030 into
stdcs-solaris/linux and aix (does aix have a gb18030 locale?). And keep the  8087171 open
for a more general solution, such as using iconv for a "IconvCharset"

-Sherman


On 07/28/2015 09:51 AM, Volker Simonis wrote:
> Hi Jonathan, Alan,
>
> this is a known problem and we've already discussed it intensively.
>
> Please have a look at:
>
> 8081674: EmptyStackException at startup if running with extended or
> unsupported charset
> https://bugs.openjdk.java.net/browse/JDK-8081674
>
> and:
>
> 8087161: Fails to start up initialize system class loader running on
> unsupported charset
> https://bugs.openjdk.java.net/browse/JDK-8087161
>
> 8081674 has a long discussion and also detailed description on how
> this can be reproduced.
> @Jonathan: the problem with your test case is that it is not enough to
> only set the appropriate locale, you also have to make sure that the
> locale is installed (see bug discussion for more details). 8081674
> finally only fixed a part of the problem and left the rest for
> 8087161.
>
> The mailing list thread about this issue can be found here:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/thread.html#33879
>
> As your bug is an exact copy of 8087161 I've closed it as duplicate.
>
> Regards,
> Volker
>
>
> On Tue, Jul 28, 2015 at 3:48 PM, Alan Bateman  wrote:
>> On 28/07/2015 10:50, ???(??) wrote:
>>> Hello,
>>>
>>>
>>> The issue
>>> was found on one of my Linux boxes which uses locale zh_CN.GB18030 by
>>> default,
>>>
>>> a simple
>>> patch was made to fix it, may I have it reviewed ?
>>>
>>>
>>> webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132459
>>>
>> I hope Sherman will have time to look at this and say whether GB18030 is
>> supposed java.base and so be listed in
>> jdk/make/data/charsetmapping/stdcs-linux.
>>
>> My concern with this change is that it's bringing back code that was
>> deliberately removed as part of JDK-8038310. We want clean separation of the
>> java.base and jdk.charsets modules so that charsets that are needed for
>> startup in supported locales to be in java.base. Anything that is not needed
>> in java.base goes to jdk.charsets and is loaded via the extended charset
>> provider.
>>
>> -Alan.



From Roger.Riggs at Oracle.com  Tue Jul 28 21:33:13 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 28 Jul 2015 17:33:13 -0400
Subject: SelectableChannels and Process API
In-Reply-To: <552E05D3.3080807@gmail.com>
References: <552E05D3.3080807@gmail.com>
Message-ID: <55B7F519.8040208@Oracle.com>

Hi Peter,

Sorry to have taken so long to get back to this thread on 
SelectableChannels for process I/O.
Working on the pipelines idea got me back to thinking about this proposal.

One bit of spec/implementation to address is the state of the In/Out/Err 
streams
of the process when using Redirect.PIPE_CHANNEL.   It may be as simple as
specifying, as is done for the other Redirect cases, that they have 
'null' implementations and
setting the respective elements of fds[0..2] to -1 before the call to 
initStreams  (line 383//401).

If this moves forward, there should be more tests especially of the 
Selectable functions
and error cases.  Note that 'assert' is not always checked, it depends 
on how the test is invoked.

I've got a busy August, but could spend time on this later (between all 
the other priorities).

Thanks, Roger



On 4/15/2015 2:31 AM, Peter Levart wrote:
>>>
>>> So I've been playing with the idea of exposing the "real" pipe 
>>> channels in last couple of days. Here's the prototype I came up with:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-sandbox/JDK-8046092-branch/Process.PipeChannel/webrev.01/ 
>>>
>>>
>>> This adds new Redirect type to the API and 3 new methods to Process 
>>> that return Pipe channels when this new Redirect type is used. It's 
>>> interesting that no native code changes were necessary. The behavior 
>>> of pipes on Windows is a little different (perhaps because the Pipe 
>>> NIO API uses sockets under the hood on Windows - why is that? 
>>> Windows does have a pipe equivalent). What bothers me is that file 
>>> handles opened on files (when redirecting to/from File) can be 
>>> closed as soon as the subprocess is started and the subprocess is 
>>> still able to read/write from the files (like with UNIX). It's not 
>>> the same with pipe (i.e. socket) handles on Windows. They must be 
>>> closed only after subprocess exits.
>>>
>>> If this subtle difference between file handles and socket handles on 
>>> Windows could be dealt with (perhaps some options exist that affect 
>>> subprocess spawning), then the extra waiting thread would not be 
>>> needed on Windows.
>>>
>>> So what do you think of this API update?
>> Definitely worthy of a separate thread.  It looks promising and 
>> addresses some of the issues
>> raised, while moving other problems from the implementation to the 
>> application.
>> Such as closing of the channels and cleanup.  I worry about how the 
>> resources are freed
>> if the code spawning the app doesn't do the cleanup.  Will it require 
>> hooks (like a finalizer)
>> to do the cleanup?
>> Also, it doesn't help with Martin's goal of being able to implement
>> emacs in Java since it doesn't provide pty control.
>> As you are aware the complexity in Process is to ensure a timely 
>> cleanup and
>> allowing the Process to terminate and release the process resources
>> when it was done and not having to wait for the stdout/stderr consumer.
>
> I wonder how this automatic stream cleanup really helps in real-world 
> programs. It doesn't help the Process to terminate and release the 
> process resources any sooner as the process terminates on it's own 
> (unless killed) and OS releases it's resources without the outside 
> help anyway. Draining and closing the stream after the process has 
> already exited just releases one file handle (the consuming side of 
> the pipe) in a promptly manner. This could be left to the user and/or 
> finalizer. Draining after the process has already exited does not help 
> the process to exit any sooner as it happens after the fact. A program 
> that doesn't consume the stream can cause the process to hang forever 
> as the pipe's buffer is bounded (64k typically). So draining and 
> closing after the process has exited only potentially helps for the 
> last 64k of the stream and only to release one file handle in a 
> potentially more timely manner.
>
> OTOH now that ProcessImpl for UNIX does that (and why does Windows 
> implementation not do that?) sloppy programs might exist that would 
> potentially break if the status quo is not maintained.
>
> But new functionality need not be so permissive. I'll take a look at 
> how and if Channel(s) do any kind of automatic cleanup based on 
> reachability and whether this can be bolted on for Process use. I 
> doubt it is possible to drain and close a Channel without disturbing 
> the ongoing Selector IO processing...
>
> Regards, Peter 



From stuart.marks at oracle.com  Wed Jul 29 01:45:00 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 28 Jul 2015 18:45:00 -0700
Subject: RFR(s): 8132206: move ScanTest.java into OpenJDK
Message-ID: <55B8301C.7040504@oracle.com>

Hi all,

Please review this small change to add a test for java.util.Scanner into 
OpenJDK. This test was inadvertently omitted from OpenJDK when the regression 
tests were migrated into the open.

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

Webrev:
	http://cr.openjdk.java.net/~smarks/reviews/8132206/webrev.0/

s'marks


From chuansheng.lcs at alibaba-inc.com  Wed Jul 29 03:22:40 2015
From: chuansheng.lcs at alibaba-inc.com (Jonathan Lu)
Date: Wed, 29 Jul 2015 11:22:40 +0800
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version'	on
	Linux under zh_CN.GB18030 locale
In-Reply-To: <55B7EC8B.8000508@oracle.com>
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
	
	<55B7EC8B.8000508@oracle.com>
Message-ID: 

Hi Alan, Sherman,

Thanks for taking a look!

I understand and totally agree with improving module separation.
Another quick test was just done on my Linux box for all available locales, and found several more which will cause
 ExceptionInInitializerError on JDK9, but worked with JDK8.

ar_AE
ar_AE.iso88596
ar_BH
ar_BH.iso88596
ar_DZ
ar_DZ.iso88596
ar_EG
ar_EG.iso88596
ar_IQ
ar_IQ.iso88596
ar_JO
ar_JO.iso88596
ar_KW
ar_KW.iso88596
ar_LB
ar_LB.iso88596
ar_LY
ar_LY.iso88596
ar_MA
ar_MA.iso88596
ar_OM
ar_OM.iso88596
ar_QA
ar_QA.iso88596
ar_SA
ar_SA.iso88596
ar_SD
ar_SD.iso88596
ar_SY
ar_SY.iso88596
ar_TN
ar_TN.iso88596
ar_YE
ar_YE.iso88596
hebrew
he_IL
he_IL.iso88598
iw_IL
iw_IL.iso88598
mt_MT
mt_MT.iso88593
thai
th_TH
th_TH.tis620
yi_US
yi_US.cp1255
zh_CN.gb18030
zh_TW.euctw

@Sherman, so other locales (except gb18030, like euctw) are all supposed to wait for the general solution, right ?
As I read from the scripts, it sounds to be implementation specific decision.

Thanks
Jonathan


> On Jul 29, 2015, at 4:56 AM, Xueming Shen  wrote:
> 
> yes, gb18030 needs to be in linux/unix std-solaris/unix as well.
> 
> -sherman
> 
> On 07/28/2015 09:51 AM, Volker Simonis wrote:
>> Hi Jonathan, Alan,
>> 
>> this is a known problem and we've already discussed it intensively.
>> 
>> Please have a look at:
>> 
>> 8081674: EmptyStackException at startup if running with extended or
>> unsupported charset
>> https://bugs.openjdk.java.net/browse/JDK-8081674
>> 
>> and:
>> 
>> 8087161: Fails to start up initialize system class loader running on
>> unsupported charset
>> https://bugs.openjdk.java.net/browse/JDK-8087161
>> 
>> 8081674 has a long discussion and also detailed description on how
>> this can be reproduced.
>> @Jonathan: the problem with your test case is that it is not enough to
>> only set the appropriate locale, you also have to make sure that the
>> locale is installed (see bug discussion for more details). 8081674
>> finally only fixed a part of the problem and left the rest for
>> 8087161.
>> 
>> The mailing list thread about this issue can be found here:
>> 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/thread.html#33879
>> 
>> As your bug is an exact copy of 8087161 I've closed it as duplicate.
>> 
>> Regards,
>> Volker
>> 
>> 
>> On Tue, Jul 28, 2015 at 3:48 PM, Alan Bateman  wrote:
>>> On 28/07/2015 10:50, ???(??) wrote:
>>>> Hello,
>>>> 
>>>> 
>>>> The issue
>>>> was found on one of my Linux boxes which uses locale zh_CN.GB18030 by
>>>> default,
>>>> 
>>>> a simple
>>>> patch was made to fix it, may I have it reviewed ?
>>>> 
>>>> 
>>>> webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132459
>>>> 
>>> I hope Sherman will have time to look at this and say whether GB18030 is
>>> supposed java.base and so be listed in
>>> jdk/make/data/charsetmapping/stdcs-linux.
>>> 
>>> My concern with this change is that it's bringing back code that was
>>> deliberately removed as part of JDK-8038310. We want clean separation of the
>>> java.base and jdk.charsets modules so that charsets that are needed for
>>> startup in supported locales to be in java.base. Anything that is not needed
>>> in java.base goes to jdk.charsets and is loaded via the extended charset
>>> provider.
>>> 
>>> -Alan.



From kim.barrett at oracle.com  Wed Jul 29 07:57:28 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 29 Jul 2015 03:57:28 -0400
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
Message-ID: 

Please review this fix of a race condition in
j.l.r.Reference/ReferenceQueue.  See comments in the bug report for a
description of the race.  The race is being fixed by reordering a pair
of volatile assignments.

CR:
https://bugs.openjdk.java.net/browse/JDK-8132306

Webrev:
http://cr.openjdk.java.net/~kbarrett/8132306/webrev.00/

Testing:
jprt with default and hotspot testsets

Locally tested race in original code by insertion of sleep in enqueue and
verifying ReferenceEnqueue regression test fails consistently as
described in the bug report.

Locally tested fixed code by insertion of sleeps at various points and
verifying ReferenceEnqueue regression test still passes.



From thomas.schatzl at oracle.com  Wed Jul 29 07:59:41 2015
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 29 Jul 2015 09:59:41 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: 
References: 
Message-ID: <1438156781.2302.17.camel@oracle.com>

Hi Kim,

On Wed, 2015-07-29 at 03:57 -0400, Kim Barrett wrote:
> Please review this fix of a race condition in
> j.l.r.Reference/ReferenceQueue.  See comments in the bug report for a
> description of the race.  The race is being fixed by reordering a pair
> of volatile assignments.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8132306
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8132306/webrev.00/
> 
> Testing:
> jprt with default and hotspot testsets
> 
> Locally tested race in original code by insertion of sleep in enqueue and
> verifying ReferenceEnqueue regression test fails consistently as
> described in the bug report.
> 
> Locally tested fixed code by insertion of sleeps at various points and
> verifying ReferenceEnqueue regression test still passes.

  looks good.

Thanks for taking care of this so quickly,
  Thomas




From paul.sandoz at oracle.com  Wed Jul 29 08:09:26 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 29 Jul 2015 10:09:26 +0200
Subject: RFR(s): 8132206: move ScanTest.java into OpenJDK
In-Reply-To: <55B8301C.7040504@oracle.com>
References: <55B8301C.7040504@oracle.com>
Message-ID: <7E97833B-DE42-4250-A7FC-243D3D7A1D82@oracle.com>


On 29 Jul 2015, at 03:45, Stuart Marks  wrote:

> Hi all,
> 
> Please review this small change to add a test for java.util.Scanner into OpenJDK. This test was inadvertently omitted from OpenJDK when the regression tests were migrated into the open.
> 
> Bug:
> 	https://bugs.openjdk.java.net/browse/JDK-8132206
> 
> Webrev:
> 	http://cr.openjdk.java.net/~smarks/reviews/8132206/webrev.0/
> 

+1

Paul.


From daniel.fuchs at oracle.com  Wed Jul 29 08:25:35 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 Jul 2015 10:25:35 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: 
References: 
Message-ID: <55B88DFF.60204@oracle.com>

Hi Kim,

I agree with your proposed fix.

I see that you have added a comment for future maintainers.
Thanks for that - as the implication of the ordering between
the two volatile writes is not immediately perceptible to
the casual reader.

You have good eyes - I hadn't spotted the race condition, but
it is definitely there. I have tried to see if the proposed
reordering could have other side effects but couldn't find any:
The reference might now temporarily appear unenqueued though
it's already at the head of the queue - but since 'head' is
private in ReferenceQueue and access to the head reference
are adequately protected by 'lock' then it looks like this
is not going to be an issue.

+1

Thanks for finding the cause of the failure and the devising the fix!

best regards,

-- daniel

On 29/07/15 09:57, Kim Barrett wrote:
> Please review this fix of a race condition in
> j.l.r.Reference/ReferenceQueue.  See comments in the bug report for a
> description of the race.  The race is being fixed by reordering a pair
> of volatile assignments.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8132306
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8132306/webrev.00/
>
> Testing:
> jprt with default and hotspot testsets
>
> Locally tested race in original code by insertion of sleep in enqueue and
> verifying ReferenceEnqueue regression test fails consistently as
> described in the bug report.
>
> Locally tested fixed code by insertion of sleeps at various points and
> verifying ReferenceEnqueue regression test still passes.
>



From david.holmes at oracle.com  Wed Jul 29 08:32:43 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 29 Jul 2015 18:32:43 +1000
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: 
References: 
Message-ID: <55B88FAB.4080302@oracle.com>

Hi Kim,

On 29/07/2015 5:57 PM, Kim Barrett wrote:
> Please review this fix of a race condition in
> j.l.r.Reference/ReferenceQueue.  See comments in the bug report for a
> description of the race.  The race is being fixed by reordering a pair
> of volatile assignments.

While this seems logical for the failure at hand it isn't immediately 
obvious to me that setting next before setting the ENQUEUED state won't 
cause a problem for some other piece of code. Really these things need 
to be tightly synchronized - I think the real bug is the unsynchronized 
fast-path for the empty-queue case in poll(). While that change was 
deliberate in 6666739 this side-effect was not realized and would have 
affected the change. I hope Martin and/or Tom see this and chime in.

That aside the commentary is rather verbose, a simple:

// Only set ENQUEUED state after the reference is enqueued

would suffice (and add "volatiles ensure ordering" if you want that to 
be clearer).

Thanks,
David

> CR:
> https://bugs.openjdk.java.net/browse/JDK-8132306
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8132306/webrev.00/
>
> Testing:
> jprt with default and hotspot testsets
>
> Locally tested race in original code by insertion of sleep in enqueue and
> verifying ReferenceEnqueue regression test fails consistently as
> described in the bug report.
>
> Locally tested fixed code by insertion of sleeps at various points and
> verifying ReferenceEnqueue regression test still passes.
>


From scolebourne at joda.org  Wed Jul 29 08:40:34 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 29 Jul 2015 09:40:34 +0100
Subject: ProcessBuilder support for pipelines
In-Reply-To: <7426949B-AA9A-42F4-A8CC-118F55C77B79@oracle.com>
References: <55B644CC.2020609@Oracle.com>
	<7426949B-AA9A-42F4-A8CC-118F55C77B79@oracle.com>
Message-ID: 

Seems like a useful addition to me.
Stephen

On 28 July 2015 at 09:28, Chris Hegarty  wrote:
> I find this kinda cute. Seems like a reasonable addition to me.
>
> -Chris.
>
> On 27 Jul 2015, at 15:48, Roger Riggs  wrote:
>
>> On most operating systems, creating pipelines of processes is simple and direct.
>> That same function is missing from the Java Process support and can be provided by
>> java.lang.ProcessBuilder by enabling the pipes created for stdout to be
>> used for standard input when the processes are created.
>> Comments and feedback are appreciated on the prototype API and implementation.
>>
>> Javadoc:  java.lang.ProcessBuilder.startPipe:
>> http://cr.openjdk.java.net/~rriggs/pipedoc/java/lang/ProcessBuilder.html#startPipe-java.lang.ProcessBuilder...-
>>
>> webrev prototype:
>>  http://cr.openjdk.java.net/~rriggs//webrev-pipeline-8132394
>>
>> Thanks, Roger
>>
>


From volker.simonis at gmail.com  Wed Jul 29 09:23:40 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 29 Jul 2015 11:23:40 +0200
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version' on
	Linux under zh_CN.GB18030 locale
In-Reply-To: <55B7EFF5.5030006@oracle.com>
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
	
	<55B7EFF5.5030006@oracle.com>
Message-ID: 

On Tue, Jul 28, 2015 at 11:11 PM, Xueming Shen  wrote:
> Volker,
>
> If fine with you I will re-open  the gb18080 specific bug and fix it by
> adding the gb18030 into
> stdcs-solaris/linux and aix (does aix have a gb18030 locale?).

In general I'm fine with your proposal. But I don't understand how you
could add gb18030 to stdcs-solaris/linux. As far as I understand that
only works for charsets created from a map/template but gb18030 is
provided in source at
src/jdk.charsets/share/classes/sun/nio/cs/ext/GB18030.java and is
explicitly in the sun.nio.cs.ext package. Maybe I'm missing something?
I'm not really a charset expert :)

Another point is that I thought that you (i.e. Oracle) wanted to keep
the base image small. If we now add every charset for which people
complain that it is not in the standard set to the base image, where
will be the limit? For me that's no problem (I'm doing server VM's :)
but maybe somebody else could comment?

Thanks,
Volker

> And keep the
> 8087171 open
> for a more general solution, such as using iconv for a "IconvCharset"
>
> -Sherman
>
>
> On 07/28/2015 09:51 AM, Volker Simonis wrote:
>>
>> Hi Jonathan, Alan,
>>
>> this is a known problem and we've already discussed it intensively.
>>
>> Please have a look at:
>>
>> 8081674: EmptyStackException at startup if running with extended or
>> unsupported charset
>> https://bugs.openjdk.java.net/browse/JDK-8081674
>>
>> and:
>>
>> 8087161: Fails to start up initialize system class loader running on
>> unsupported charset
>> https://bugs.openjdk.java.net/browse/JDK-8087161
>>
>> 8081674 has a long discussion and also detailed description on how
>> this can be reproduced.
>> @Jonathan: the problem with your test case is that it is not enough to
>> only set the appropriate locale, you also have to make sure that the
>> locale is installed (see bug discussion for more details). 8081674
>> finally only fixed a part of the problem and left the rest for
>> 8087161.
>>
>> The mailing list thread about this issue can be found here:
>>
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/thread.html#33879
>>
>> As your bug is an exact copy of 8087161 I've closed it as duplicate.
>>
>> Regards,
>> Volker
>>
>>
>> On Tue, Jul 28, 2015 at 3:48 PM, Alan Bateman
>> wrote:
>>>
>>> On 28/07/2015 10:50, ???(??) wrote:
>>>>
>>>> Hello,
>>>>
>>>>
>>>> The issue
>>>> was found on one of my Linux boxes which uses locale zh_CN.GB18030 by
>>>> default,
>>>>
>>>> a simple
>>>> patch was made to fix it, may I have it reviewed ?
>>>>
>>>>
>>>> webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132459
>>>>
>>> I hope Sherman will have time to look at this and say whether GB18030 is
>>> supposed java.base and so be listed in
>>> jdk/make/data/charsetmapping/stdcs-linux.
>>>
>>> My concern with this change is that it's bringing back code that was
>>> deliberately removed as part of JDK-8038310. We want clean separation of
>>> the
>>> java.base and jdk.charsets modules so that charsets that are needed for
>>> startup in supported locales to be in java.base. Anything that is not
>>> needed
>>> in java.base goes to jdk.charsets and is loaded via the extended charset
>>> provider.
>>>
>>> -Alan.
>
>


From volker.simonis at gmail.com  Wed Jul 29 09:31:21 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 29 Jul 2015 11:31:21 +0200
Subject: RFR(XS): 8132475 : The commands in the modular images are
	executable by the owner only (once again)
In-Reply-To: <55B7E06A.8070508@oracle.com>
References: 
	<55B7E06A.8070508@oracle.com>
Message-ID: 

On Tue, Jul 28, 2015 at 10:04 PM, Alan Bateman  wrote:
> On 28/07/2015 19:32, Volker Simonis wrote:
>>
>> Hi,
>>
>> could you please review this tiny change:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132475/
>> https://bugs.openjdk.java.net/browse/JDK-8132475
>>
>> After "8080511: Refresh of jimage support" the executable commands in
>> jdk/bin and jre/bin are only executable by the file owner. This means
>> that only the user who built the images can execute the programs.
>>
>> The fix is trivial, but I've also added a test now so this won't
>> happen a third time :)
>>
> This is a new image writer, it's different to what was there previously.
>

Just for the case it is changed once again :)

> I assume the test can't run if the permissions are not right :-)
>

Of coarse it can't run if there are no executable permissions at all,
but it will run and give an error if only the owner of the file has
executable permissions which is what this bug is all about. Obviously,
you (i.e. Oracle) are running all the tests with the same user who
also built the VM that's why you didn't saw this problem two times. We
have a distinct build and test users (which I think is good) so we
always run into this instantly.

Regards,
Volker

> -Alan.


From alexander.fomin at oracle.com  Wed Jul 29 11:59:45 2015
From: alexander.fomin at oracle.com (Alexander Fomin)
Date: Wed, 29 Jul 2015 14:59:45 +0300
Subject: Review request: JDK-8080108: [TEST_BUG] ERROR: No IPv6 address
	returned from platform
Message-ID: <55B8C031.6010802@oracle.com>

Hello,

Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8080108

See webrev here
http://cr.openjdk.java.net/~kshefov/8080108/webrev.00/

The original test 
(com/sun/jndi/dns/IPv6NameserverPlatformParsingTest.java @bug 6991580) 
fails automatically if /etc/resolv.conf file doesn't contain IPv6 
nameserver entries.
It's needed to edit /etc/resolv.conf manually before the test run, so 
this is a manual regression test.
The test is intended to be run on non-Windows systems.

Fix:
- provided standard test machinery for regression manual tests with 
instructions for a user;
- the test excluded for Windows.

Tested on Linux and Windows(to make sure it's excluded).

Thanks,
Alexander


From daniel.fuchs at oracle.com  Wed Jul 29 15:02:28 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 Jul 2015 17:02:28 +0200
Subject: RfR - 8130058: jaxp: Investigate removal of
	com/sun/org/apache/xalan/internal/xslt/Process.java
Message-ID: <55B8EB04.2050209@oracle.com>

Hi,

Please find below a patch that removes a bunch of unused files
in jdk9/dev/jaxp:

https://bugs.openjdk.java.net/browse/JDK-8130058
8130058: jaxp: Investigate removal of
          com/sun/org/apache/xalan/internal/xslt/Process.java

http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.00/

best regards,

-- daniel


From xueming.shen at oracle.com  Wed Jul 29 15:24:53 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 29 Jul 2015 08:24:53 -0700
Subject: RFR(s): 8132206: move ScanTest.java into OpenJDK
In-Reply-To: <55B8301C.7040504@oracle.com>
References: <55B8301C.7040504@oracle.com>
Message-ID: <55B8F045.80202@oracle.com>

On 7/28/15 6:45 PM, Stuart Marks wrote:
> Hi all,
>
> Please review this small change to add a test for java.util.Scanner 
> into OpenJDK. This test was inadvertently omitted from OpenJDK when 
> the regression tests were migrated into the open.
>
> Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8132206
>
> Webrev:
>     http://cr.openjdk.java.net/~smarks/reviews/8132206/webrev.0/
>
> s'marks
looks good.

-sherman


From lance.andersen at oracle.com  Wed Jul 29 15:30:57 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 29 Jul 2015 11:30:57 -0400
Subject: RfR - 8130058: jaxp: Investigate removal of
	com/sun/org/apache/xalan/internal/xslt/Process.java
In-Reply-To: <55B8EB04.2050209@oracle.com>
References: <55B8EB04.2050209@oracle.com>
Message-ID: <4A11FFBB-6B9B-428A-BB3B-6DA1C2C66A34@oracle.com>

Looks OK based on the email thread about this proposed change


On Jul 29, 2015, at 11:02 AM, Daniel Fuchs  wrote:

> http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.00/



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





From paul.sandoz at oracle.com  Wed Jul 29 15:48:39 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 29 Jul 2015 17:48:39 +0200
Subject: RFR: JDK-8062849 -- Optimize EnumMap.equals
In-Reply-To: <4DCE139D-0D61-4A88-AED8-F26C18B9A6D3@oracle.com>
References: <4DCE139D-0D61-4A88-AED8-F26C18B9A6D3@oracle.com>
Message-ID: 


On 28 Jul 2015, at 18:14, Steve Drach  wrote:

> Please review the following simple fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8062849 .
> 

+1

Paul.

> -----------------
> # HG changeset patch
> # User sdrach
> # Date 1437777193 25200
> #      Fri Jul 24 15:33:13 2015 -0700
> # Node ID e57b1569a65ec4dc8c749dedd3345abe5d493054
> # Parent  4dd09cb5f7c2a2a23a9958ea7a602dd74d5709b2
> 8062849: Optimize EnumMap.equals
> Summary: In the equals method, if the two EnumMaps are a different size return false since they can't be equal.
> Reviewed-by: brent.christian at oracle.com, paul.sandoz at oracle.com
> Contributed-by: steve.drach at oracle.com
> 
> diff --git a/src/java.base/share/classes/java/util/EnumMap.java b/src/java.base/share/classes/java/util/EnumMap.java
> --- a/src/java.base/share/classes/java/util/EnumMap.java
> +++ b/src/java.base/share/classes/java/util/EnumMap.java
> @@ -681,8 +681,11 @@
>     }
> 
>     private boolean equals(EnumMap em) {
> +        if (size != em.size)
> +            return false;
> +
>         if (em.keyType != keyType)
> -            return size == 0 && em.size == 0;
> +            return size == 0;
> 
>         // Key types match, compare each value
>         for (int i = 0; i < keyUniverse.length; i++) {
> 



From xueming.shen at oracle.com  Wed Jul 29 15:53:25 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 29 Jul 2015 08:53:25 -0700
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version' on
	Linux under zh_CN.GB18030 locale
In-Reply-To: 
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
	
	<55B7EFF5.5030006@oracle.com>
	
Message-ID: <55B8F6F5.8020101@oracle.com>

On 7/29/15 2:23 AM, Volker Simonis wrote:
> On Tue, Jul 28, 2015 at 11:11 PM, Xueming Shen  wrote:
>> Volker,
>>
>> If fine with you I will re-open  the gb18080 specific bug and fix it by
>> adding the gb18030 into
>> stdcs-solaris/linux and aix (does aix have a gb18030 locale?).
> In general I'm fine with your proposal. But I don't understand how you
> could add gb18030 to stdcs-solaris/linux. As far as I understand that
> only works for charsets created from a map/template but gb18030 is
> provided in source at
> src/jdk.charsets/share/classes/sun/nio/cs/ext/GB18030.java and is
> explicitly in the sun.nio.cs.ext package. Maybe I'm missing something?
> I'm not really a charset expert :)

Nothing is impossible :-)  only need to change that GB18030.java to a 
"source template"
with .template, and then generate the real source code during 
build/compile time with
appropriate package name. We do this for couple charsets already.

>
> Another point is that I thought that you (i.e. Oracle) wanted to keep
> the base image small. If we now add every charset for which people
> complain that it is not in the standard set to the base image, where
> will be the limit? For me that's no problem (I'm doing server VM's :)
> but maybe somebody else could comment?

The "image size" is really not a "concern" on unix/linux platform. But 
it would be preferred
if we can keep the size small, the reason I'm considering the iconv 
approach.

Thanks,
Sherman

>
>
>
>> And keep the
>> 8087171 open
>> for a more general solution, such as using iconv for a "IconvCharset"
>>
>> -Sherman
>>
>>
>> On 07/28/2015 09:51 AM, Volker Simonis wrote:
>>> Hi Jonathan, Alan,
>>>
>>> this is a known problem and we've already discussed it intensively.
>>>
>>> Please have a look at:
>>>
>>> 8081674: EmptyStackException at startup if running with extended or
>>> unsupported charset
>>> https://bugs.openjdk.java.net/browse/JDK-8081674
>>>
>>> and:
>>>
>>> 8087161: Fails to start up initialize system class loader running on
>>> unsupported charset
>>> https://bugs.openjdk.java.net/browse/JDK-8087161
>>>
>>> 8081674 has a long discussion and also detailed description on how
>>> this can be reproduced.
>>> @Jonathan: the problem with your test case is that it is not enough to
>>> only set the appropriate locale, you also have to make sure that the
>>> locale is installed (see bug discussion for more details). 8081674
>>> finally only fixed a part of the problem and left the rest for
>>> 8087161.
>>>
>>> The mailing list thread about this issue can be found here:
>>>
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/thread.html#33879
>>>
>>> As your bug is an exact copy of 8087161 I've closed it as duplicate.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Tue, Jul 28, 2015 at 3:48 PM, Alan Bateman
>>> wrote:
>>>> On 28/07/2015 10:50, ???(??) wrote:
>>>>> Hello,
>>>>>
>>>>>
>>>>> The issue
>>>>> was found on one of my Linux boxes which uses locale zh_CN.GB18030 by
>>>>> default,
>>>>>
>>>>> a simple
>>>>> patch was made to fix it, may I have it reviewed ?
>>>>>
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132459
>>>>>
>>>> I hope Sherman will have time to look at this and say whether GB18030 is
>>>> supposed java.base and so be listed in
>>>> jdk/make/data/charsetmapping/stdcs-linux.
>>>>
>>>> My concern with this change is that it's bringing back code that was
>>>> deliberately removed as part of JDK-8038310. We want clean separation of
>>>> the
>>>> java.base and jdk.charsets modules so that charsets that are needed for
>>>> startup in supported locales to be in java.base. Anything that is not
>>>> needed
>>>> in java.base goes to jdk.charsets and is loaded via the extended charset
>>>> provider.
>>>>
>>>> -Alan.
>>



From paul.sandoz at oracle.com  Wed Jul 29 15:59:05 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 29 Jul 2015 17:59:05 +0200
Subject: RFR: JDK-8066013 (prefs) Unused variable in
	src/java.prefs/share/classes/java/util/prefs/MacOSXPreferences.java
In-Reply-To: <06EFC8B1-B32B-4639-A43E-99CC4AE9065E@oracle.com>
References: <1747FD15-C035-4E61-B3B2-43BF1C97CE86@oracle.com>
	<06EFC8B1-B32B-4639-A43E-99CC4AE9065E@oracle.com>
Message-ID: 

On 23 Jul 2015, at 11:26, Chris Hegarty  wrote:
> Your change [1] looks fine to me Steve.
> 

+1

Paul.


From volker.simonis at gmail.com  Wed Jul 29 18:36:14 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 29 Jul 2015 20:36:14 +0200
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: <55B6940D.90701@Oracle.com>
References: <55B6938E.2010806@Oracle.com>
	<55B6940D.90701@Oracle.com>
Message-ID: 

Hi Roger,

thanks a lot for the review. Please find my comments inline and the
new webrev under:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v3/

On Mon, Jul 27, 2015 at 10:26 PM, Roger Riggs  wrote:
> Hi Volker,
>
> Thanks for the refactoring and the AIX implementation.
>
> We still need a tie-breaker with respect to the issue of
> truncated/incomplete
> argument and executable values.
>

Yes, I agree. Please see my other comments further down.

> On 7/24/2015 9:30 AM, Volker Simonis wrote:
>
> Hi,
>
> so here comes the new webrev which cleanly applies to the current
> jdk9-dev/jdk repo:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v2/
>
>
> Comments:
>
> os_getParentPid() - the function name doesn't reflect the additional values
> returned.

Yes, but the initial name getStatInfo() wasn't perfect either because
for example on MacOS X there is no stat-file at all.

I've changed it to os_getParentPidAndTimings() for now but I'm open
for better suggestions :)

> The time units on the starttime and cputime need should appear in the
> function header
> without having to refer to the declaration.
>

Done.
I've also reordered the function declarations in
ProcessHandleImpl_unix.h to group the corresponding os_ and unix_
functions together.

> os_getParentPid()  - Within this function can the code that accesses the
> sysctl info be kept together.
>    Perhaps move the rusage if/block before the if (sysctl) {...}
>    Or just move the start time extraction to just before the return pid..
>

It was this way in the initial code already, but I've changed it as requested.

> ProcessHandleImpl_unix.c: 138 and 140 - The macros should not include the
> trailing semicolon ";"
> (causes a unreachable compilation warning on Solaris 10)
>
> ProcessHandlmpl_unix.c: 401: extra semicolon  ";;"
> (causes a warning about declarations after statements on Solaris 10).
>

Ah, good catch! I saw these warnings but I thought they are related to
my local compiler.
Fixed.

> 691:  Typo: Solris
> 730: separeted
>

Fixed.

> ProcessHandleImpl_unix:c: 358 - Info_info0 - it appears that the psinfo file
> is read twice.
> Once by unix_getUid and again by unix_getCmdLineInfo
> One aspect of the original code  was to avoid opening and reading /proc
> files more than once/necessary.
>

OK, I removed os/unix_getUid() and merged the call of
unix_getUserInfo() into os/unix_getCmdlineInfo() which I've renamed
into os/unix_getCmdlineAndUserInfo()

> ProcessHandleImpl_unix.c: 691-700 - There is no point in doing a file lookup
> that is
> known to fail.  This should be #ifdef/#ifndef'd to apply only to the
> appropriate OS.
>

Fixed.

> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
> truncated or incomplete
> values for the executable or arguments.
> Can anyone be a tie-breaker  (with a good rational and suggestion for how an
> application can use the data).
>

As I wrote, I agree to hear other opinions here.

All I want to say that this truncated data is actually what 'ps' is
reporting on Solaris since decades and people seem to be happy with
it. As use case I can imagine logging or monitoring (something like
'top' in Java) where this data will be just good enough.

We could specially mark possibly incomplete data by extending the Info
object with functions like commandIsExact() or argumentsIsPrecise().
But notice that we can not statically preset these values per
platform. For example on Solaris, the 'command()' would return a
precise value for processes with the same uid like the VM but only
inaccurate values for all other processes. The "arguments()" would be
always inaccurate on Solaris/AIX.

Maybe we should cast a vote among the initial "8077350: JEP 102
Process API Updates Implementation" reviewers?

>
> InfoTest.java: 139:  Is this the best that can be done for checking the
> times on AIX?
>

Yes, because /proc//status is only updated once a second on AIX
(see: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2015-July/002273.html).
I've slightly updated the comment.

> InfoTest.java:285 - mentions /proc/pid/status ;  should that be
> /proc/pid/psinfo?
>

Yes, you're right. I've updated both occurences.

> ProcessHandleImpl_linux.c: 63: getUID and getCmdlineInfo both format the
> /proc file
> name and do a lookup of the file.  The original version avoided doing the
> lookup twice
> in the same native call.    Perhaps there is a refactoring that puts the
> extraction of
> the UID in with getting the command line.
> This might address the repeated reading of psinfo in
> ProcessHandleImpl_unix:358 as well.
>

Done. See comments for ProcessHandleImpl_unix:358 above.

> ProcessHandleImpl_unix.h is a new file and only needs a 2015 copyright date.
>

Done. Also for ProcessHandleImpl_aix.c and ProcessHandleImpl_linux.c

> Somewhere the unixs for the start and cputimes needs to be documented
> at the declaration.
>

Done.

> That is  first pass on comments.
>
> Thanks, Roger
>

I hope the dispute about the truncated/incomplete Info fields remains
the last open point for now :)

Regards,
Volker

>
>
>
> The good thing beforehand - although I added the AIX-port and a big
> 50-line comment the new version is still 60 lines shorter :)
>   10 files changed, 829 insertions(+), 999 deletions(-)
>
> The main idea behind the new code layout is as follows (see the
> comment in ProcessHandleImpl_unix.c for more details):
>
> The currently supported Unix variants are Solaris, Linux, MaxOS X
> and AIX. The various similarities and differences between these
> systems make it hard to find a clear boundary between platform
> specific and shared code.
>
> In order to ease code sharing between the platforms while still
> keeping the code as clean as possible (i.e. free of preprocessor
> macros) we use the following source code layout (remember that
> ProcessHandleImpl_unix.c will be compiled on EVERY Unix platform
> while ProcessHandleImpl_.c will be only compiled on the
> specific OS):
>
>  - all the JNI wrappers for the ProcessHandleImpl functions go
>    into ProcessHandleImpl_unix.c file
>
>  - if their implementation is common on ALL the supported Unix
>    platforms it goes right into the JNI wrappers
>
>  - if the whole function or substantial parts of it are platform
>    dependent, the implementation goes into os_
>    functions in ProcessHandleImpl_.c
>
>  - if at least two platforms implement an os_
>    function in the same way, this implementation is factored out
>    into unix_, placed into
>    ProcessHandleImpl_unix.c and called from the corresponding
>    os_ function.
>
>  - For convenience, all the os_ and unix_ functions are declared
>    in ProcessHandleImpl_unix.h which is included into every
>    ProcessHandleImpl_.c file.
>
> So ProcessHandleImpl_unix.c only contains code which is shared by at
> least two platforms. Code which is specific to one single platform
> goes into the corresponding ProcessHandleImpl_.c file (and this
> changes adds ProcessHandleImpl_aix.c for AIX-specific code and
> ProcessHandleImpl_linux.c for Linux-specific code which was in
> ProcessHandleImpl_unix.c previously).
>
> I tried to unify similar functions (e.g.
> Java_java_lang_ProcessHandleImpl_00024Info_initIDs,
> Java_java_lang_ProcessHandleImpl_isAlive0 or fillArgArray) into a
> single instance in ProcessHandleImpl_unix.c.
>
> I renamed and unified getStatInfo() into
> os_getParentPid()/unix_getParentPid() with three implemantions for
> MacOSX, Linux and Solaris/AIX.
>
> I've factored out Java_java_lang_ProcessHandleImpl_getProcessPids0()
> into os_getChildren()/unix_getChildren() with two implemantions - one
> for MacOSX and one for Linux/Solaris/AIX.
>
> I've tested the new implementation on MacOSX, Linux (x86_64 and ppc64)
> , Solaris 10/11 (x86_64 and Sparc) and AIX.
>
> The final point, which was already mentioned in the first review is
> the fact that we can not easily get accurate information fort he
> command line and arguments on AIX. I'd prefer to stay with the current
> solution which gives "best effort" answers for these attributes but if
> everybody?s opinion is that such information is useless I can also
> omit it altogether. I haven?t looked at the other platforms which we
> have to support (e.g. HPUX, AS/400) but the situation may be similar
> there.
>
> Regards,
> Volker
>
>
>
>


From martinrb at google.com  Wed Jul 29 18:39:12 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 29 Jul 2015 11:39:12 -0700
Subject: ProcessBuilder support for pipelines
In-Reply-To: <55B644CC.2020609@Oracle.com>
References: <55B644CC.2020609@Oracle.com>
Message-ID: 

Curmudgeon Martin supports this change!

I'm a little surprised we can implement it without native code.

---

The below should probably be in its own paragraph.

+ * The {@link #startPipe startPipe} method can be invoked to create
+ * a pipeline of new processes that send the output of each process
+ * directly to the next process.  Each process has the attributes of
+ * its respective ProcessBuilder.

---

I continue to be opposed to throwing UOE.  But it seems I've lost that
nano-argument.

+     * @throws  UnsupportedOperationException
+     *          If the operating system does not support the creation of
processes.

---

These statements are technically incorrect.

+     * The standard output of all processes except the first process
+     * are null output streams
+     * The standard input of all processes except the last process
+     * are null input streams.

What you mean is that getOutputStream etc return null streams, but that's
not what you say.

---

Should this mention standard error?

+     * @throws IllegalArgumentException any of the redirects except the
+     *          standard input of the first builder and the standard
output of
+     *          the last builder are not {@link Redirect#PIPE}.


From volker.simonis at gmail.com  Wed Jul 29 18:41:01 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 29 Jul 2015 20:41:01 +0200
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version' on
	Linux under zh_CN.GB18030 locale
In-Reply-To: <55B8F6F5.8020101@oracle.com>
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
	
	<55B7EFF5.5030006@oracle.com>
	
	<55B8F6F5.8020101@oracle.com>
Message-ID: 

On Wed, Jul 29, 2015 at 5:53 PM, Xueming Shen  wrote:
> On 7/29/15 2:23 AM, Volker Simonis wrote:
>>
>> On Tue, Jul 28, 2015 at 11:11 PM, Xueming Shen 
>> wrote:
>>>
>>> Volker,
>>>
>>> If fine with you I will re-open  the gb18080 specific bug and fix it by
>>> adding the gb18030 into
>>> stdcs-solaris/linux and aix (does aix have a gb18030 locale?).
>>
>> In general I'm fine with your proposal. But I don't understand how you
>> could add gb18030 to stdcs-solaris/linux. As far as I understand that
>> only works for charsets created from a map/template but gb18030 is
>> provided in source at
>> src/jdk.charsets/share/classes/sun/nio/cs/ext/GB18030.java and is
>> explicitly in the sun.nio.cs.ext package. Maybe I'm missing something?
>> I'm not really a charset expert :)
>
>
> Nothing is impossible :-)  only need to change that GB18030.java to a
> "source template"
> with .template, and then generate the real source code during build/compile
> time with
> appropriate package name. We do this for couple charsets already.
>

That's simple enough :)
Thanks for the explanation.

>>
>> Another point is that I thought that you (i.e. Oracle) wanted to keep
>> the base image small. If we now add every charset for which people
>> complain that it is not in the standard set to the base image, where
>> will be the limit? For me that's no problem (I'm doing server VM's :)
>> but maybe somebody else could comment?
>
>
> The "image size" is really not a "concern" on unix/linux platform. But it
> would be preferred
> if we can keep the size small, the reason I'm considering the iconv
> approach.
>
> Thanks,
> Sherman
>
>>
>>
>>
>>> And keep the
>>> 8087171 open
>>> for a more general solution, such as using iconv for a "IconvCharset"
>>>
>>> -Sherman
>>>
>>>
>>> On 07/28/2015 09:51 AM, Volker Simonis wrote:
>>>>
>>>> Hi Jonathan, Alan,
>>>>
>>>> this is a known problem and we've already discussed it intensively.
>>>>
>>>> Please have a look at:
>>>>
>>>> 8081674: EmptyStackException at startup if running with extended or
>>>> unsupported charset
>>>> https://bugs.openjdk.java.net/browse/JDK-8081674
>>>>
>>>> and:
>>>>
>>>> 8087161: Fails to start up initialize system class loader running on
>>>> unsupported charset
>>>> https://bugs.openjdk.java.net/browse/JDK-8087161
>>>>
>>>> 8081674 has a long discussion and also detailed description on how
>>>> this can be reproduced.
>>>> @Jonathan: the problem with your test case is that it is not enough to
>>>> only set the appropriate locale, you also have to make sure that the
>>>> locale is installed (see bug discussion for more details). 8081674
>>>> finally only fixed a part of the problem and left the rest for
>>>> 8087161.
>>>>
>>>> The mailing list thread about this issue can be found here:
>>>>
>>>>
>>>>
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/thread.html#33879
>>>>
>>>> As your bug is an exact copy of 8087161 I've closed it as duplicate.
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>> On Tue, Jul 28, 2015 at 3:48 PM, Alan Bateman
>>>> wrote:
>>>>>
>>>>> On 28/07/2015 10:50, ???(??) wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>
>>>>>> The issue
>>>>>> was found on one of my Linux boxes which uses locale zh_CN.GB18030 by
>>>>>> default,
>>>>>>
>>>>>> a simple
>>>>>> patch was made to fix it, may I have it reviewed ?
>>>>>>
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132459
>>>>>>
>>>>> I hope Sherman will have time to look at this and say whether GB18030
>>>>> is
>>>>> supposed java.base and so be listed in
>>>>> jdk/make/data/charsetmapping/stdcs-linux.
>>>>>
>>>>> My concern with this change is that it's bringing back code that was
>>>>> deliberately removed as part of JDK-8038310. We want clean separation
>>>>> of
>>>>> the
>>>>> java.base and jdk.charsets modules so that charsets that are needed for
>>>>> startup in supported locales to be in java.base. Anything that is not
>>>>> needed
>>>>> in java.base goes to jdk.charsets and is loaded via the extended
>>>>> charset
>>>>> provider.
>>>>>
>>>>> -Alan.
>>>
>>>
>


From kim.barrett at oracle.com  Wed Jul 29 23:46:39 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 29 Jul 2015 19:46:39 -0400
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55B88FAB.4080302@oracle.com>
References: 
	<55B88FAB.4080302@oracle.com>
Message-ID: <929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>

On Jul 29, 2015, at 4:32 AM, David Holmes  wrote:
> 
> On 29/07/2015 5:57 PM, Kim Barrett wrote:
>> ...  The race is being fixed by reordering a pair
>> of volatile assignments.
> 
> While this seems logical for the failure at hand it isn't immediately obvious to me that setting next before setting the ENQUEUED state won't cause a problem for some other piece of code. Really these things need to be tightly synchronized - I think the real bug is the unsynchronized fast-path for the empty-queue case in poll(). While that change was deliberate in 6666739 this side-effect was not realized and would have affected the change. I hope Martin and/or Tom see this and chime in.

I thought the poll() fast-path from 6666739 was ok at the time it was
made, and that it was the later removal of synchronization on the
reference by 8014890 that lead to the race under discussion, and
reinstating that synchronization on the reference was another way to
fix this race.  Turns out I was wrong about that.

The poll() fast-path introduced the possibility of the following
unexpected behavior when another thread is in r.enqueue() and is in
the problematic window:

    !r.enqueue() && q.poll() == null => true

This can happen because the synchronization on the references is only
in ReferenceQueue.enqueue().  If it was instead in
Reference.enqueue(), or if ReferenceQueue.Null.enqueue() also
synchronized on the reference, this race would be prevented.

The removal of reference synchronization opened the door wider, also
allowing this unexpected behavior:

    r.isEnqueued() && q.poll() == null => true

The combination of those changes is needed for the ReferenceEnqueue
regression test to fail, since it requires

    r.isEnqueued() && !r.enqueue() && q.poll() == null => true

I wouldn't want to revert the poll() fast-path, since that was added
for specific performance reasons.

I don't think I'd want to add back synchronization on the reference,
but might be persuaded otherwise.  8029205 should be looked at in that
case.

I've looked carefully at uses of r.next and I don't think there is a
problem with reordering the r.next and r.queue assignments.  Of
course, the existing code was looked at by a number of people without
spotting the race under discussion.

A way to think about this that helped me (I think) understand the
locking structure used here is that q.head and r.next are part of the
queue associated with the reference.  We can manipulate those using
the queue's lock as the basis for protection, so long as the the
reference's queue isn't changed.  But when we change the reference's
queue, the queue (including r.next) must be in a consistent state.
[This suggests the r.queue = NULL assignment in reallyPoll() should be
moved later, though I think the assignment order in reallyPoll()
doesn't matter.]

> That aside the commentary is rather verbose, a simple:
> 
> // Only set ENQUEUED state after the reference is enqueued
> 
> would suffice (and add "volatiles ensure ordering" if you want that to be clearer).

I do get a bit wordy sometimes.  How about this:

            // Update r.queue *after* adding to queue's list, to avoid
            // race between enqueued checks and poll().  Volatiles
            // ensure ordering.


>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8132306
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8132306/webrev.00/
>> 
>> Testing:
>> jprt with default and hotspot testsets
>> 
>> Locally tested race in original code by insertion of sleep in enqueue and
>> verifying ReferenceEnqueue regression test fails consistently as
>> described in the bug report.
>> 
>> Locally tested fixed code by insertion of sleeps at various points and
>> verifying ReferenceEnqueue regression test still passes.




From david.holmes at oracle.com  Thu Jul 30 02:40:28 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Jul 2015 12:40:28 +1000
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
Message-ID: <55B98E9C.10704@oracle.com>

Hi Kim,

tl;dr: Ship it! :)

On 30/07/2015 9:46 AM, Kim Barrett wrote:
> On Jul 29, 2015, at 4:32 AM, David Holmes  wrote:
>>
>> On 29/07/2015 5:57 PM, Kim Barrett wrote:
>>> ...  The race is being fixed by reordering a pair
>>> of volatile assignments.
>>
>> While this seems logical for the failure at hand it isn't immediately obvious to me that setting next before setting the ENQUEUED state won't cause a problem for some other piece of code. Really these things need to be tightly synchronized - I think the real bug is the unsynchronized fast-path for the empty-queue case in poll(). While that change was deliberate in 6666739 this side-effect was not realized and would have affected the change. I hope Martin and/or Tom see this and chime in.
>
> I thought the poll() fast-path from 6666739 was ok at the time it was
> made, and that it was the later removal of synchronization on the
> reference by 8014890 that lead to the race under discussion, and
> reinstating that synchronization on the reference was another way to
> fix this race.  Turns out I was wrong about that.

Seems there are multiple races present. :(

> The poll() fast-path introduced the possibility of the following
> unexpected behavior when another thread is in r.enqueue() and is in
> the problematic window:
>
>      !r.enqueue() && q.poll() == null => true
>
> This can happen because the synchronization on the references is only
> in ReferenceQueue.enqueue().  If it was instead in
> Reference.enqueue(), or if ReferenceQueue.Null.enqueue() also
> synchronized on the reference, this race would be prevented.

Right - the switching of the queues changes the lock in use and so we no 
longer serialize access to the reference state.

> The removal of reference synchronization opened the door wider, also
> allowing this unexpected behavior:
>
>      r.isEnqueued() && q.poll() == null => true
>
> The combination of those changes is needed for the ReferenceEnqueue
> regression test to fail, since it requires
>
>      r.isEnqueued() && !r.enqueue() && q.poll() == null => true

Yes - all of which can unfortunately run concurrently with the still 
in-progress r.enqueue().

> I wouldn't want to revert the poll() fast-path, since that was added
> for specific performance reasons.

But that was done under an assumption of correctness. If it isn't 
correct then its okay to regress performance. But of course if we can 
fix it some other way ...

> I don't think I'd want to add back synchronization on the reference,
> but might be persuaded otherwise.  8029205 should be looked at in that
> case.

It is a tricky one - as I wrote in the review thread for 8014890. Basic 
synchronization rules say you should lock the Reference whilst mutating 
its state - but that leads to nested locking issues when also trying to 
update the queue's state. So we add a volatile, drop a lock and create 
one or more races - and hope the we have correctly determined that the 
races are benign (which we didn't in this case).

> I've looked carefully at uses of r.next and I don't think there is a
> problem with reordering the r.next and r.queue assignments.  Of
> course, the existing code was looked at by a number of people without
> spotting the race under discussion.

Between your analysis and Daniel's I'm more confident about the change. 
The Java side of things seems fine, but trying to enumerate all the 
possibles races is difficult to say the least.

> A way to think about this that helped me (I think) understand the
> locking structure used here is that q.head and r.next are part of the
> queue associated with the reference.  We can manipulate those using
> the queue's lock as the basis for protection, so long as the the
> reference's queue isn't changed.  But when we change the reference's
> queue, the queue (including r.next) must be in a consistent state.

I'm not 100% sure it sufficiently covers the cases where we switch 
queues, but yes logically the Reference's queue field is guarded by the 
queue's lock.

> [This suggests the r.queue = NULL assignment in reallyPoll() should be
> moved later, though I think the assignment order in reallyPoll()
> doesn't matter.]

I don't see that it matters as the current queue is locked and the only 
interesting actions can happen with the current queue. For the NULL and 
ENQUEUED queues enqueuing is a no-op, and there can only be one "real" 
queue involved.

>> That aside the commentary is rather verbose, a simple:
>>
>> // Only set ENQUEUED state after the reference is enqueued
>>
>> would suffice (and add "volatiles ensure ordering" if you want that to be clearer).
>
> I do get a bit wordy sometimes.  How about this:
>
>              // Update r.queue *after* adding to queue's list, to avoid
>              // race between enqueued checks and poll().  Volatiles
>              // ensure ordering.

Sounds fine.

Thanks,
David
------

>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8132306
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8132306/webrev.00/
>>>
>>> Testing:
>>> jprt with default and hotspot testsets
>>>
>>> Locally tested race in original code by insertion of sleep in enqueue and
>>> verifying ReferenceEnqueue regression test fails consistently as
>>> described in the bug report.
>>>
>>> Locally tested fixed code by insertion of sleeps at various points and
>>> verifying ReferenceEnqueue regression test still passes.
>
>


From xueming.shen at oracle.com  Thu Jul 30 03:54:20 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 29 Jul 2015 20:54:20 -0700
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version' on
	Linux under zh_CN.GB18030 locale
In-Reply-To: 
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
	
	<55B7EC8B.8000508@oracle.com>
	
Message-ID: <55B99FEC.8080602@oracle.com>

Here is the webrev to add those "missing" charsets. The assumption back 
then was that the linux platform has
successfully migrated to the "utf-8 default" world.

http://cr.openjdk.java.net/~sherman/8132459/

thanks,
Sherman

On 7/28/15 8:22 PM, Jonathan Lu wrote:
> Hi Alan, Sherman,
>
> Thanks for taking a look!
>
> I understand and totally agree with improving module separation.
> Another quick test was just done on my Linux box for all available locales, and found several more which will cause
>   ExceptionInInitializerError on JDK9, but worked with JDK8.
>
> ar_AE
> ar_AE.iso88596
> ar_BH
> ar_BH.iso88596
> ar_DZ
> ar_DZ.iso88596
> ar_EG
> ar_EG.iso88596
> ar_IQ
> ar_IQ.iso88596
> ar_JO
> ar_JO.iso88596
> ar_KW
> ar_KW.iso88596
> ar_LB
> ar_LB.iso88596
> ar_LY
> ar_LY.iso88596
> ar_MA
> ar_MA.iso88596
> ar_OM
> ar_OM.iso88596
> ar_QA
> ar_QA.iso88596
> ar_SA
> ar_SA.iso88596
> ar_SD
> ar_SD.iso88596
> ar_SY
> ar_SY.iso88596
> ar_TN
> ar_TN.iso88596
> ar_YE
> ar_YE.iso88596
> hebrew
> he_IL
> he_IL.iso88598
> iw_IL
> iw_IL.iso88598
> mt_MT
> mt_MT.iso88593
> thai
> th_TH
> th_TH.tis620
> yi_US
> yi_US.cp1255
> zh_CN.gb18030
> zh_TW.euctw
>
> @Sherman, so other locales (except gb18030, like euctw) are all supposed to wait for the general solution, right ?
> As I read from the scripts, it sounds to be implementation specific decision.
>
> Thanks
> Jonathan
>
>
>> On Jul 29, 2015, at 4:56 AM, Xueming Shen  wrote:
>>
>> yes, gb18030 needs to be in linux/unix std-solaris/unix as well.
>>
>> -sherman
>>
>> On 07/28/2015 09:51 AM, Volker Simonis wrote:
>>> Hi Jonathan, Alan,
>>>
>>> this is a known problem and we've already discussed it intensively.
>>>
>>> Please have a look at:
>>>
>>> 8081674: EmptyStackException at startup if running with extended or
>>> unsupported charset
>>> https://bugs.openjdk.java.net/browse/JDK-8081674
>>>
>>> and:
>>>
>>> 8087161: Fails to start up initialize system class loader running on
>>> unsupported charset
>>> https://bugs.openjdk.java.net/browse/JDK-8087161
>>>
>>> 8081674 has a long discussion and also detailed description on how
>>> this can be reproduced.
>>> @Jonathan: the problem with your test case is that it is not enough to
>>> only set the appropriate locale, you also have to make sure that the
>>> locale is installed (see bug discussion for more details). 8081674
>>> finally only fixed a part of the problem and left the rest for
>>> 8087161.
>>>
>>> The mailing list thread about this issue can be found here:
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/thread.html#33879
>>>
>>> As your bug is an exact copy of 8087161 I've closed it as duplicate.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Tue, Jul 28, 2015 at 3:48 PM, Alan Bateman  wrote:
>>>> On 28/07/2015 10:50, ???(??) wrote:
>>>>> Hello,
>>>>>
>>>>>
>>>>> The issue
>>>>> was found on one of my Linux boxes which uses locale zh_CN.GB18030 by
>>>>> default,
>>>>>
>>>>> a simple
>>>>> patch was made to fix it, may I have it reviewed ?
>>>>>
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132459
>>>>>
>>>> I hope Sherman will have time to look at this and say whether GB18030 is
>>>> supposed java.base and so be listed in
>>>> jdk/make/data/charsetmapping/stdcs-linux.
>>>>
>>>> My concern with this change is that it's bringing back code that was
>>>> deliberately removed as part of JDK-8038310. We want clean separation of the
>>>> java.base and jdk.charsets modules so that charsets that are needed for
>>>> startup in supported locales to be in java.base. Anything that is not needed
>>>> in java.base goes to jdk.charsets and is loaded via the extended charset
>>>> provider.
>>>>
>>>> -Alan.



From david.holmes at oracle.com  Thu Jul 30 04:53:29 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Jul 2015 14:53:29 +1000
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version' on
	Linux under zh_CN.GB18030 locale
In-Reply-To: <55B99FEC.8080602@oracle.com>
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
	
	<55B7EC8B.8000508@oracle.com>
	
	<55B99FEC.8080602@oracle.com>
Message-ID: <55B9ADC9.7020407@oracle.com>

Hi Sherman,

On 30/07/2015 1:54 PM, Xueming Shen wrote:
> Here is the webrev to add those "missing" charsets. The assumption back
> then was that the linux platform has successfully migrated to the "utf-8 default" world.

This process seems somewhat ad-hoc, what are we using to determine which 
charsets are "core" and which are not?

Thanks,
David

>
> http://cr.openjdk.java.net/~sherman/8132459/
>
> thanks,
> Sherman
>
> On 7/28/15 8:22 PM, Jonathan Lu wrote:
>> Hi Alan, Sherman,
>>
>> Thanks for taking a look!
>>
>> I understand and totally agree with improving module separation.
>> Another quick test was just done on my Linux box for all available
>> locales, and found several more which will cause
>>   ExceptionInInitializerError on JDK9, but worked with JDK8.
>>
>> ar_AE
>> ar_AE.iso88596
>> ar_BH
>> ar_BH.iso88596
>> ar_DZ
>> ar_DZ.iso88596
>> ar_EG
>> ar_EG.iso88596
>> ar_IQ
>> ar_IQ.iso88596
>> ar_JO
>> ar_JO.iso88596
>> ar_KW
>> ar_KW.iso88596
>> ar_LB
>> ar_LB.iso88596
>> ar_LY
>> ar_LY.iso88596
>> ar_MA
>> ar_MA.iso88596
>> ar_OM
>> ar_OM.iso88596
>> ar_QA
>> ar_QA.iso88596
>> ar_SA
>> ar_SA.iso88596
>> ar_SD
>> ar_SD.iso88596
>> ar_SY
>> ar_SY.iso88596
>> ar_TN
>> ar_TN.iso88596
>> ar_YE
>> ar_YE.iso88596
>> hebrew
>> he_IL
>> he_IL.iso88598
>> iw_IL
>> iw_IL.iso88598
>> mt_MT
>> mt_MT.iso88593
>> thai
>> th_TH
>> th_TH.tis620
>> yi_US
>> yi_US.cp1255
>> zh_CN.gb18030
>> zh_TW.euctw
>>
>> @Sherman, so other locales (except gb18030, like euctw) are all
>> supposed to wait for the general solution, right ?
>> As I read from the scripts, it sounds to be implementation specific
>> decision.
>>
>> Thanks
>> Jonathan
>>
>>
>>> On Jul 29, 2015, at 4:56 AM, Xueming Shen 
>>> wrote:
>>>
>>> yes, gb18030 needs to be in linux/unix std-solaris/unix as well.
>>>
>>> -sherman
>>>
>>> On 07/28/2015 09:51 AM, Volker Simonis wrote:
>>>> Hi Jonathan, Alan,
>>>>
>>>> this is a known problem and we've already discussed it intensively.
>>>>
>>>> Please have a look at:
>>>>
>>>> 8081674: EmptyStackException at startup if running with extended or
>>>> unsupported charset
>>>> https://bugs.openjdk.java.net/browse/JDK-8081674
>>>>
>>>> and:
>>>>
>>>> 8087161: Fails to start up initialize system class loader running on
>>>> unsupported charset
>>>> https://bugs.openjdk.java.net/browse/JDK-8087161
>>>>
>>>> 8081674 has a long discussion and also detailed description on how
>>>> this can be reproduced.
>>>> @Jonathan: the problem with your test case is that it is not enough to
>>>> only set the appropriate locale, you also have to make sure that the
>>>> locale is installed (see bug discussion for more details). 8081674
>>>> finally only fixed a part of the problem and left the rest for
>>>> 8087161.
>>>>
>>>> The mailing list thread about this issue can be found here:
>>>>
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/thread.html#33879
>>>>
>>>>
>>>> As your bug is an exact copy of 8087161 I've closed it as duplicate.
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>> On Tue, Jul 28, 2015 at 3:48 PM, Alan
>>>> Bateman  wrote:
>>>>> On 28/07/2015 10:50, ???(??) wrote:
>>>>>> Hello,
>>>>>>
>>>>>>
>>>>>> The issue
>>>>>> was found on one of my Linux boxes which uses locale zh_CN.GB18030 by
>>>>>> default,
>>>>>>
>>>>>> a simple
>>>>>> patch was made to fix it, may I have it reviewed ?
>>>>>>
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132459
>>>>>>
>>>>> I hope Sherman will have time to look at this and say whether
>>>>> GB18030 is
>>>>> supposed java.base and so be listed in
>>>>> jdk/make/data/charsetmapping/stdcs-linux.
>>>>>
>>>>> My concern with this change is that it's bringing back code that was
>>>>> deliberately removed as part of JDK-8038310. We want clean
>>>>> separation of the
>>>>> java.base and jdk.charsets modules so that charsets that are needed
>>>>> for
>>>>> startup in supported locales to be in java.base. Anything that is
>>>>> not needed
>>>>> in java.base goes to jdk.charsets and is loaded via the extended
>>>>> charset
>>>>> provider.
>>>>>
>>>>> -Alan.
>


From xueming.shen at oracle.com  Thu Jul 30 05:21:48 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 29 Jul 2015 22:21:48 -0700
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version' on
	Linux under zh_CN.GB18030 locale
In-Reply-To: <55B9ADC9.7020407@oracle.com>
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
	
	<55B7EC8B.8000508@oracle.com>
	
	<55B99FEC.8080602@oracle.com> <55B9ADC9.7020407@oracle.com>
Message-ID: <55B9B46C.9000003@oracle.com>

On 7/29/15 9:53 PM, David Holmes wrote:
> Hi Sherman,
>
> On 30/07/2015 1:54 PM, Xueming Shen wrote:
>> Here is the webrev to add those "missing" charsets. The assumption back
>> then was that the linux platform has successfully migrated to the 
>> "utf-8 default" world.
>
> This process seems somewhat ad-hoc, what are we using to determine 
> which charsets are "core" and which are not?

Hi David,

Each platform has a list of "supported locale/encoding". All these 
encodings/charsets need to be in
base module for that particular platform, to support the jvm to start 
(in a particular locale/encoding)
under module system. The charsets in our repository can be categorized 
into different groups, solaris/
linux specific, windows specific and IBM specific and couple that are 
shared by different platforms).
The idea here is to build all those platform-specific charsets into the 
base module for that platform.

To use the native platform de/encoding implementation/mechanism, for 
example iconv, for startup only
might be a better solution. Until we have that (and the consensus that 
we go with that approach), the
current approach appears to be the only reasonable&simple choice.

Thanks,
-Sherman

>
> Thanks,
> David
>
>>
>> http://cr.openjdk.java.net/~sherman/8132459/
>>
>> thanks,
>> Sherman
>>
>> On 7/28/15 8:22 PM, Jonathan Lu wrote:
>>> Hi Alan, Sherman,
>>>
>>> Thanks for taking a look!
>>>
>>> I understand and totally agree with improving module separation.
>>> Another quick test was just done on my Linux box for all available
>>> locales, and found several more which will cause
>>>   ExceptionInInitializerError on JDK9, but worked with JDK8.
>>>
>>> ar_AE
>>> ar_AE.iso88596
>>> ar_BH
>>> ar_BH.iso88596
>>> ar_DZ
>>> ar_DZ.iso88596
>>> ar_EG
>>> ar_EG.iso88596
>>> ar_IQ
>>> ar_IQ.iso88596
>>> ar_JO
>>> ar_JO.iso88596
>>> ar_KW
>>> ar_KW.iso88596
>>> ar_LB
>>> ar_LB.iso88596
>>> ar_LY
>>> ar_LY.iso88596
>>> ar_MA
>>> ar_MA.iso88596
>>> ar_OM
>>> ar_OM.iso88596
>>> ar_QA
>>> ar_QA.iso88596
>>> ar_SA
>>> ar_SA.iso88596
>>> ar_SD
>>> ar_SD.iso88596
>>> ar_SY
>>> ar_SY.iso88596
>>> ar_TN
>>> ar_TN.iso88596
>>> ar_YE
>>> ar_YE.iso88596
>>> hebrew
>>> he_IL
>>> he_IL.iso88598
>>> iw_IL
>>> iw_IL.iso88598
>>> mt_MT
>>> mt_MT.iso88593
>>> thai
>>> th_TH
>>> th_TH.tis620
>>> yi_US
>>> yi_US.cp1255
>>> zh_CN.gb18030
>>> zh_TW.euctw
>>>
>>> @Sherman, so other locales (except gb18030, like euctw) are all
>>> supposed to wait for the general solution, right ?
>>> As I read from the scripts, it sounds to be implementation specific
>>> decision.
>>>
>>> Thanks
>>> Jonathan
>>>
>>>
>>>> On Jul 29, 2015, at 4:56 AM, Xueming Shen 
>>>> wrote:
>>>>
>>>> yes, gb18030 needs to be in linux/unix std-solaris/unix as well.
>>>>
>>>> -sherman
>>>>
>>>> On 07/28/2015 09:51 AM, Volker Simonis wrote:
>>>>> Hi Jonathan, Alan,
>>>>>
>>>>> this is a known problem and we've already discussed it intensively.
>>>>>
>>>>> Please have a look at:
>>>>>
>>>>> 8081674: EmptyStackException at startup if running with extended or
>>>>> unsupported charset
>>>>> https://bugs.openjdk.java.net/browse/JDK-8081674
>>>>>
>>>>> and:
>>>>>
>>>>> 8087161: Fails to start up initialize system class loader running on
>>>>> unsupported charset
>>>>> https://bugs.openjdk.java.net/browse/JDK-8087161
>>>>>
>>>>> 8081674 has a long discussion and also detailed description on how
>>>>> this can be reproduced.
>>>>> @Jonathan: the problem with your test case is that it is not 
>>>>> enough to
>>>>> only set the appropriate locale, you also have to make sure that the
>>>>> locale is installed (see bug discussion for more details). 8081674
>>>>> finally only fixed a part of the problem and left the rest for
>>>>> 8087161.
>>>>>
>>>>> The mailing list thread about this issue can be found here:
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/thread.html#33879 
>>>>>
>>>>>
>>>>>
>>>>> As your bug is an exact copy of 8087161 I've closed it as duplicate.
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>>
>>>>> On Tue, Jul 28, 2015 at 3:48 PM, Alan
>>>>> Bateman  wrote:
>>>>>> On 28/07/2015 10:50, ???(??) wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>>
>>>>>>> The issue
>>>>>>> was found on one of my Linux boxes which uses locale 
>>>>>>> zh_CN.GB18030 by
>>>>>>> default,
>>>>>>>
>>>>>>> a simple
>>>>>>> patch was made to fix it, may I have it reviewed ?
>>>>>>>
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~luchsh/webrev-8132459/
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132459
>>>>>>>
>>>>>> I hope Sherman will have time to look at this and say whether
>>>>>> GB18030 is
>>>>>> supposed java.base and so be listed in
>>>>>> jdk/make/data/charsetmapping/stdcs-linux.
>>>>>>
>>>>>> My concern with this change is that it's bringing back code that was
>>>>>> deliberately removed as part of JDK-8038310. We want clean
>>>>>> separation of the
>>>>>> java.base and jdk.charsets modules so that charsets that are needed
>>>>>> for
>>>>>> startup in supported locales to be in java.base. Anything that is
>>>>>> not needed
>>>>>> in java.base goes to jdk.charsets and is loaded via the extended
>>>>>> charset
>>>>>> provider.
>>>>>>
>>>>>> -Alan.
>>



From amaembo at gmail.com  Thu Jul 30 06:08:05 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Thu, 30 Jul 2015 12:08:05 +0600
Subject: Custom spliterator for Collections.nCopies(n, obj).stream()
In-Reply-To: <9B7C4E11-5FA7-4EEC-9A5F-929AF1DAAE9D@oracle.com>
References: <1767952446.20150728143738@gmail.com>
	<9B7C4E11-5FA7-4EEC-9A5F-929AF1DAAE9D@oracle.com>
Message-ID: <1503382816.20150730120805@gmail.com>

Hello!

PS> I don?t particular want to add a special spliterator for this
PS> case to avoid some profile pollution. Will it not just push the
PS> pollution further down the road to Spliterator.forEachRemaining? or to within other code?

I just thought that the current idea is to create specialized
spliterators for most methods returning streams. If not, why
String.chars()/AbstractStringBuilder.chars() in JDK9 use new
IntCharArraySpliterator instead of already existing
CharBuffer.wrap(this).chars() which produce similar performance in
both sequential and parallel cases? Also for String an alternative
would be

return IntStream.range(0, value.length).map(i -> value[i]);

Which is actually similar to Collections.nCopies().stream().

Also note that Collections class already contains singletonSpliterator
which  creates  an  anonymous class. With my proposed change it can be
replaced  with new ConstantSpliterator(1, element) without performance
drop, so actual number of classes will not increase.

At very least why creating two distinct lambdas in CopiesList.stream()
and CopiesList.parallelStream()? They duplicate "i -> element", for
which javac creates two separate methods (like lambda$stream$95(int)
and lambda$parallelStream$96(int)) and in runtime two distinct
anonymous classes may be created. It could be written instead

public Stream parallelStream() {
    return stream().parallel();
}

With best regards,
Tagir Valeev.

PS> Alas i think profile pollution is current fact of JDK life when
PS> inverting control with lambdas. What we really require is a better way to specialise the hot loops.

PS> Paul.

PS> On 28 Jul 2015, at 10:37, Tagir F. Valeev  wrote:

>> Hello!
>> 
>> Current implementation of Collections.nCopies().stream() is as
>> follows:
>> 
>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/Collections.java#l5066
>> 
>> public Stream stream() {
>>    return IntStream.range(0, n).mapToObj(i -> element);
>> }
>> 
>> @Override
>> public Stream parallelStream() {
>>    return IntStream.range(0, n).parallel().mapToObj(i -> element);
>> }
>> 
>> The problem is that it adds a lambda expression to the
>> RangeIntSpliterator type profile which can be polluted by some other
>> code and vice versa: using nCopies().stream() may pollute the type
>> profile for other code making it slower.
>> 
>> Another thing which is missing in current implementation is unordered
>> mode. This collection is unordered by nature, its stream is similar to
>> Stream.generate(), so to my opinion it should be unordered which may
>> improve the parallel reduction in some cases.
>> 
>> This can be improved by introducing the custom spliterator class which
>> is quite simple:
>> https://gist.github.com/amaembo/62f3efee9923b1468e86
>> 
>> On pre-polluted type profile with simple mapping and reduction using
>> custom spliterator is about 25-30% faster in both parallel and
>> sequential cases as benchmarking shows (performed on 4-core cpu).
>> 
>> What do you think?
>> 
>> With best regards,
>> Tagir Valeev.
>> 



From paul.sandoz at oracle.com  Thu Jul 30 07:42:28 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 30 Jul 2015 09:42:28 +0200
Subject: Custom spliterator for Collections.nCopies(n, obj).stream()
In-Reply-To: <1503382816.20150730120805@gmail.com>
References: <1767952446.20150728143738@gmail.com>
	<9B7C4E11-5FA7-4EEC-9A5F-929AF1DAAE9D@oracle.com>
	<1503382816.20150730120805@gmail.com>
Message-ID: <79644D3C-5570-4555-940C-4F8384129877@oracle.com>


On 30 Jul 2015, at 08:08, Tagir F. Valeev  wrote:

> Hello!
> 
> PS> I don?t particular want to add a special spliterator for this
> PS> case to avoid some profile pollution. Will it not just push the
> PS> pollution further down the road to Spliterator.forEachRemaining? or to within other code?
> 
> I just thought that the current idea is to create specialized
> spliterators for most methods returning streams.

Not without some evaluation of the benefits compared to the increased cost of code.


> If not, why
> String.chars()/AbstractStringBuilder.chars() in JDK9 use new
> IntCharArraySpliterator instead of already existing
> CharBuffer.wrap(this).chars() which produce similar performance in
> both sequential and parallel cases? Also for String an alternative
> would be
> 
> return IntStream.range(0, value.length).map(i -> value[i]);
> 

Since String is a commonly used class i opted for the most efficient solution (both for characters and code points, and shared across String and the builders).


> Which is actually similar to Collections.nCopies().stream().
> 

Yes, but i doubt it is as commonly used as String and thus I don?t think the argument of profile pollution is sufficient reason to justify a specific implementation. In this case convenience won over more code.


> Also note that Collections class already contains singletonSpliterator
> which  creates  an  anonymous class. With my proposed change it can be
> replaced  with new ConstantSpliterator(1, element) without performance
> drop, so actual number of classes will not increase.
> 

With reuse it becomes more compelling :-) In both cases of singleton/nCopies the spliterator characteristics can be the same and that of the already existing singleton spliterator implementation.

I would be happy to accept a patch (with tests, if existing tests do not cover this already, i suspect they might but we still need to check). Have you signed the OCA [1]. If so i can accept a patch from you and publish as a webrev for review.


> At very least why creating two distinct lambdas in CopiesList.stream()
> and CopiesList.parallelStream()? They duplicate "i -> element", for
> which javac creates two separate methods (like lambda$stream$95(int)
> and lambda$parallelStream$96(int)) and in runtime two distinct
> anonymous classes may be created. It could be written instead
> 
> public Stream parallelStream() {
>    return stream().parallel();
> }
> 

Yes, good point.

Thanks,
Paul.

[1] http://www.oracle.com/technetwork/community/oca-486395.html


From Alan.Bateman at oracle.com  Thu Jul 30 07:46:43 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 Jul 2015 08:46:43 +0100
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version'
	on Linux under zh_CN.GB18030 locale
In-Reply-To: <55B99FEC.8080602@oracle.com>
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>	<55B78828.6000600@oracle.com>		<55B7EC8B.8000508@oracle.com>	
	<55B99FEC.8080602@oracle.com>
Message-ID: <55B9D663.1080500@oracle.com>



On 30/07/2015 04:54, Xueming Shen wrote:
> Here is the webrev to add those "missing" charsets. The assumption 
> back then was that the linux platform has
> successfully migrated to the "utf-8 default" world.
>
> http://cr.openjdk.java.net/~sherman/8132459/
This looks okay to me.

-Alan


From Alan.Bateman at oracle.com  Thu Jul 30 07:51:19 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 Jul 2015 08:51:19 +0100
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version'
	on Linux under zh_CN.GB18030 locale
In-Reply-To: <55B9B46C.9000003@oracle.com>
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>	<55B78828.6000600@oracle.com>		<55B7EC8B.8000508@oracle.com>		<55B99FEC.8080602@oracle.com>
	<55B9ADC9.7020407@oracle.com> <55B9B46C.9000003@oracle.com>
Message-ID: <55B9D777.5020504@oracle.com>



On 30/07/2015 06:21, Xueming Shen wrote:
> :
>
> Each platform has a list of "supported locale/encoding". All these 
> encodings/charsets need to be in
> base module for that particular platform, to support the jvm to start 
> (in a particular locale/encoding)
> under module system. The charsets in our repository can be categorized 
> into different groups, solaris/
> linux specific, windows specific and IBM specific and couple that are 
> shared by different platforms).
> The idea here is to build all those platform-specific charsets into 
> the base module for that platform.
Right, and furthermore, we should be able to build a compact1 image or 
just an image with the java.base module and it should be able to start 
on platforms when running with a supported locale/encoding. I think the 
main issue we've had is establishing that list, hence it had to be 
extended a few times.

-Alan.


From volker.simonis at gmail.com  Thu Jul 30 08:37:25 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 30 Jul 2015 10:37:25 +0200
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version' on
	Linux under zh_CN.GB18030 locale
In-Reply-To: <55B9D777.5020504@oracle.com>
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
	
	<55B7EC8B.8000508@oracle.com>
	
	<55B99FEC.8080602@oracle.com> <55B9ADC9.7020407@oracle.com>
	<55B9B46C.9000003@oracle.com> <55B9D777.5020504@oracle.com>
Message-ID: 

On Thu, Jul 30, 2015 at 9:51 AM, Alan Bateman  wrote:
>
>
> On 30/07/2015 06:21, Xueming Shen wrote:
>>
>> :
>>
>> Each platform has a list of "supported locale/encoding". All these
>> encodings/charsets need to be in
>> base module for that particular platform, to support the jvm to start (in
>> a particular locale/encoding)
>> under module system. The charsets in our repository can be categorized
>> into different groups, solaris/
>> linux specific, windows specific and IBM specific and couple that are
>> shared by different platforms).
>> The idea here is to build all those platform-specific charsets into the
>> base module for that platform.
>
> Right, and furthermore, we should be able to build a compact1 image or just
> an image with the java.base module and it should be able to start on
> platforms when running with a supported locale/encoding. I think the main
> issue we've had is establishing that list, hence it had to be extended a few
> times.
>

The change looks fine.

But what about the 'supported locale/encoding' list. Is there a
published 'official' version of this list for Oracle/OpenJDK and how
is it maintained.

Regards,
Volker

> -Alan.


From peter.levart at gmail.com  Thu Jul 30 08:38:43 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 30 Jul 2015 10:38:43 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
Message-ID: <55B9E293.80102@gmail.com>

Hi,

Let me chime in and add some comments...

On 07/30/2015 01:46 AM, Kim Barrett wrote:
> On Jul 29, 2015, at 4:32 AM, David Holmes  wrote:
>> On 29/07/2015 5:57 PM, Kim Barrett wrote:
>>> ...  The race is being fixed by reordering a pair
>>> of volatile assignments.
>> While this seems logical for the failure at hand it isn't immediately obvious to me that setting next before setting the ENQUEUED state won't cause a problem for some other piece of code. Really these things need to be tightly synchronized - I think the real bug is the unsynchronized fast-path for the empty-queue case in poll(). While that change was deliberate in 6666739 this side-effect was not realized and would have affected the change. I hope Martin and/or Tom see this and chime in.
> I thought the poll() fast-path from 6666739 was ok at the time it was
> made, and that it was the later removal of synchronization on the
> reference by 8014890 that lead to the race under discussion, and
> reinstating that synchronization on the reference was another way to
> fix this race.  Turns out I was wrong about that.
>
> The poll() fast-path introduced the possibility of the following
> unexpected behavior when another thread is in r.enqueue() and is in
> the problematic window:
>
>      !r.enqueue() && q.poll() == null => true
>
> This can happen because the synchronization on the references is only
> in ReferenceQueue.enqueue().  If it was instead in
> Reference.enqueue(), or if ReferenceQueue.Null.enqueue() also
> synchronized on the reference, this race would be prevented.

Isn't above condition perfectly legal for references that have already 
been de-queued (and when the 'q' is otherwise empty)? But I see what you 
mean. If r.enqueue() grabs the ENQUEUED queue, the method returns false, 
but that does not mean that the reference has already been hooked on the 
'head' chain ('head' can still be null and q.poll() would return null 
because of fast-path).

reversing assignments of 'head' and 'queue' fix this situation too.

>
> The removal of reference synchronization opened the door wider, also
> allowing this unexpected behavior:
>
>      r.isEnqueued() && q.poll() == null => true

This condition is more representative, yes...

>
> The combination of those changes is needed for the ReferenceEnqueue
> regression test to fail, since it requires
>
>      r.isEnqueued() && !r.enqueue() && q.poll() == null => true
>
> I wouldn't want to revert the poll() fast-path, since that was added
> for specific performance reasons.
>
> I don't think I'd want to add back synchronization on the reference,
> but might be persuaded otherwise.  8029205 should be looked at in that
> case.
>
> I've looked carefully at uses of r.next and I don't think there is a
> problem with reordering the r.next and r.queue assignments.  Of
> course, the existing code was looked at by a number of people without
> spotting the race under discussion.
>
> A way to think about this that helped me (I think) understand the
> locking structure used here is that q.head and r.next are part of the
> queue associated with the reference.  We can manipulate those using
> the queue's lock as the basis for protection, so long as the the
> reference's queue isn't changed.  But when we change the reference's
> queue, the queue (including r.next) must be in a consistent state.
> [This suggests the r.queue = NULL assignment in reallyPoll() should be
> moved later, though I think the assignment order in reallyPoll()
> doesn't matter.]

I think the assignment to r.queue = NULL in realyPoll() should be moved 
*before* the assignment to 'head' (which might assign null if 'r' was 
the last element). Here's why:

Suppose we have a Reference 'r' and it's associated ReferenceQueue 'q'. 
Currently it can happen that the following evaluates to true, which is 
surprising:

q.poll() == null && r.isEnqueued()


Regards, Peter


>
>> That aside the commentary is rather verbose, a simple:
>>
>> // Only set ENQUEUED state after the reference is enqueued
>>
>> would suffice (and add "volatiles ensure ordering" if you want that to be clearer).
> I do get a bit wordy sometimes.  How about this:
>
>              // Update r.queue *after* adding to queue's list, to avoid
>              // race between enqueued checks and poll().  Volatiles
>              // ensure ordering.
>
>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8132306
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8132306/webrev.00/
>>>
>>> Testing:
>>> jprt with default and hotspot testsets
>>>
>>> Locally tested race in original code by insertion of sleep in enqueue and
>>> verifying ReferenceEnqueue regression test fails consistently as
>>> described in the bug report.
>>>
>>> Locally tested fixed code by insertion of sleeps at various points and
>>> verifying ReferenceEnqueue regression test still passes.
>



From peter.levart at gmail.com  Thu Jul 30 08:46:41 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 30 Jul 2015 10:46:41 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55B9E293.80102@gmail.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com>
Message-ID: <55B9E471.1000209@gmail.com>



On 07/30/2015 10:38 AM, Peter Levart wrote:
>> [This suggests the r.queue = NULL assignment in reallyPoll() should be
>> moved later, though I think the assignment order in reallyPoll()
>> doesn't matter.]
>
> I think the assignment to r.queue = NULL in realyPoll() should be 
> moved *before* the assignment to 'head' (which might assign null if 
> 'r' was the last element). Here's why:
>
> Suppose we have a Reference 'r' and it's associated ReferenceQueue 
> 'q'. Currently it can happen that the following evaluates to true, 
> which is surprising:
>
> q.poll() == null && r.isEnqueued()
>
>
> Regards, Peter 

Well, the above condition is not very representative of the situation 
I'm trying to describe. It can be perfectly legal when racing with 
enqueueing of the Reference 'r'. But when racing with de-queueing (i.e. 
poll()) it is surprising. So let me re-phrase the expression which is 
always surprising when it evaluates to true:

r.isEnqueued() && q.poll() == null && r.isEnqueued()

Regards, Peter



From daniel.fuchs at oracle.com  Thu Jul 30 09:12:42 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 Jul 2015 11:12:42 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55B9E293.80102@gmail.com>
References: 	<55B88FAB.4080302@oracle.com>	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com>
Message-ID: <55B9EA8A.1080102@oracle.com>

Hi Peter,

I'm glad you're looking at this too! We can't have too many eyes :-)

On 30/07/15 10:38, Peter Levart wrote:
> Suppose we have a Reference 'r' and it's associated ReferenceQueue 'q'.
> Currently it can happen that the following evaluates to true, which is
> surprising:
>
> q.poll() == null && r.isEnqueued()
>

But on the other hand this can only happen if two different
threads are polling the queue - in which case only one of them
will get the reference. In such a situation, the symmetric condition
would not be surprising (as the other thread would
get q.poll() != null):

    r.isEnqueued() && q.poll() == null

The original bug fixed by Kim is more surprising, because there's only
one Thread doing the polling, and it does get:

    r.isEnqueud() && q.poll() == null

although nobody else is polling the queue.
This should no longer occur in this situation with Kim's fix.

cheers,

-- daniel


From peter.levart at gmail.com  Thu Jul 30 10:20:04 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 30 Jul 2015 12:20:04 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55B9EA8A.1080102@oracle.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com> <55B9EA8A.1080102@oracle.com>
Message-ID: <55B9FA54.5040902@gmail.com>



On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
> Hi Peter,
>
> I'm glad you're looking at this too! We can't have too many eyes :-)
>
> On 30/07/15 10:38, Peter Levart wrote:
>> Suppose we have a Reference 'r' and it's associated ReferenceQueue 'q'.
>> Currently it can happen that the following evaluates to true, which is
>> surprising:
>>
>> q.poll() == null && r.isEnqueued()
>>
>
> But on the other hand this can only happen if two different
> threads are polling the queue - in which case only one of them
> will get the reference. In such a situation, the symmetric condition
> would not be surprising (as the other thread would
> get q.poll() != null):
>
>    r.isEnqueued() && q.poll() == null
>
> The original bug fixed by Kim is more surprising, because there's only
> one Thread doing the polling, and it does get:
>
>    r.isEnqueud() && q.poll() == null
>
> although nobody else is polling the queue.
> This should no longer occur in this situation with Kim's fix.
>
> cheers,
>
> -- daniel

Yes, these are two different issues. The one Kim has fixed is the race 
of above expressions with Queue.enqueue() (when the queue is changing 
from the associated instance to ENQUEUED). The one I'm pointing at and 
Kim has already identified as potential issue is the race of the 
following expression:

r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true

....with Queue.[realy]poll() (when the queue is changing from ENQUEUED 
to NULL).

Which only happens if at least two threads are polling the queue, but is 
equally surprising and prone to cause bugs, don't you think?

Regards, Peter




From david.holmes at oracle.com  Thu Jul 30 10:24:16 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Jul 2015 20:24:16 +1000
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55B9FA54.5040902@gmail.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com>
	<55B9EA8A.1080102@oracle.com> <55B9FA54.5040902@gmail.com>
Message-ID: <55B9FB50.8050907@oracle.com>

On 30/07/2015 8:20 PM, Peter Levart wrote:
>
>
> On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
>> Hi Peter,
>>
>> I'm glad you're looking at this too! We can't have too many eyes :-)
>>
>> On 30/07/15 10:38, Peter Levart wrote:
>>> Suppose we have a Reference 'r' and it's associated ReferenceQueue 'q'.
>>> Currently it can happen that the following evaluates to true, which is
>>> surprising:
>>>
>>> q.poll() == null && r.isEnqueued()
>>>
>>
>> But on the other hand this can only happen if two different
>> threads are polling the queue - in which case only one of them
>> will get the reference. In such a situation, the symmetric condition
>> would not be surprising (as the other thread would
>> get q.poll() != null):
>>
>>    r.isEnqueued() && q.poll() == null
>>
>> The original bug fixed by Kim is more surprising, because there's only
>> one Thread doing the polling, and it does get:
>>
>>    r.isEnqueud() && q.poll() == null
>>
>> although nobody else is polling the queue.
>> This should no longer occur in this situation with Kim's fix.
>>
>> cheers,
>>
>> -- daniel
>
> Yes, these are two different issues. The one Kim has fixed is the race
> of above expressions with Queue.enqueue() (when the queue is changing
> from the associated instance to ENQUEUED). The one I'm pointing at and
> Kim has already identified as potential issue is the race of the
> following expression:
>
> r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true
>
> ....with Queue.[realy]poll() (when the queue is changing from ENQUEUED
> to NULL).
>
> Which only happens if at least two threads are polling the queue, but is
> equally surprising and prone to cause bugs, don't you think?

Sorry I'm missing your point. The expression:

r.isEnqueued() && q.poll() == null

is exactly the race the current fix is addressing. Adding a second check 
of r.isEnqueued() which still returns true does not add anything that I 
can see. ??

David

> Regards, Peter
>
>


From peter.levart at gmail.com  Thu Jul 30 10:41:35 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 30 Jul 2015 12:41:35 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55B9FB50.8050907@oracle.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com>
	<55B9EA8A.1080102@oracle.com> <55B9FA54.5040902@gmail.com>
	<55B9FB50.8050907@oracle.com>
Message-ID: <55B9FF5F.2020706@gmail.com>



On 07/30/2015 12:24 PM, David Holmes wrote:
> On 30/07/2015 8:20 PM, Peter Levart wrote:
>>
>>
>> On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
>>> Hi Peter,
>>>
>>> I'm glad you're looking at this too! We can't have too many eyes :-)
>>>
>>> On 30/07/15 10:38, Peter Levart wrote:
>>>> Suppose we have a Reference 'r' and it's associated ReferenceQueue 
>>>> 'q'.
>>>> Currently it can happen that the following evaluates to true, which is
>>>> surprising:
>>>>
>>>> q.poll() == null && r.isEnqueued()
>>>>
>>>
>>> But on the other hand this can only happen if two different
>>> threads are polling the queue - in which case only one of them
>>> will get the reference. In such a situation, the symmetric condition
>>> would not be surprising (as the other thread would
>>> get q.poll() != null):
>>>
>>>    r.isEnqueued() && q.poll() == null
>>>
>>> The original bug fixed by Kim is more surprising, because there's only
>>> one Thread doing the polling, and it does get:
>>>
>>>    r.isEnqueud() && q.poll() == null
>>>
>>> although nobody else is polling the queue.
>>> This should no longer occur in this situation with Kim's fix.
>>>
>>> cheers,
>>>
>>> -- daniel
>>
>> Yes, these are two different issues. The one Kim has fixed is the race
>> of above expressions with Queue.enqueue() (when the queue is changing
>> from the associated instance to ENQUEUED). The one I'm pointing at and
>> Kim has already identified as potential issue is the race of the
>> following expression:
>>
>> r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true
>>
>> ....with Queue.[realy]poll() (when the queue is changing from ENQUEUED
>> to NULL).
>>
>> Which only happens if at least two threads are polling the queue, but is
>> equally surprising and prone to cause bugs, don't you think?
>
> Sorry I'm missing your point. The expression:
>
> r.isEnqueued() && q.poll() == null
>
> is exactly the race the current fix is addressing. Adding a second 
> check of r.isEnqueued() which still returns true does not add anything 
> that I can see. ??
>
> David

The expressions are similar, but the race is different. The one 
addressed by Kim is the race of:

r.isEnqueued() && q.poll() == null ==> true

with q.enqueue(r)

There, the reversal of assignments to q.head and r.queue in 
ReferenceQueue.enqueue() fixes the issue.


The one I'm pointing at is the race of:

r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true

with q.poll()

Here, the fix would be to also revert the assignments to q.head and 
r.queue in ReferenceQueue.reallyPoll() this time.


The 1st race is the race with enqueue-ing and the 2nd race is the race 
with de-queueing. Initially, my "surprising" expression was:

q.poll() == null && r.isEnqueued() ==> true


...but this is not representative, as it is also an expected outcome 
when racing with enqueue-ing. So I added a pre-condition to express the 
fact that it happens when racing with de-queueing only:

r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true


What is surprising in the above expression evaluating to true is the 
fact that 'r' appears to be enqueued before and after the q.poll() 
returns null. I can easily imagine code that would fail because it never 
imagined above expression to evaluate to true. For example:

if (r.isEnqueued()) {
     Reference s = q.poll();
     if (s == null) {
         // somebody else already dequeued 'r'
         assert !r.isEnqueued();
     }
}



Regards, Peter

>
>> Regards, Peter
>>
>>



From daniel.fuchs at oracle.com  Thu Jul 30 10:48:55 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 Jul 2015 12:48:55 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55B9FA54.5040902@gmail.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com> <55B9EA8A.1080102@oracle.com>
	<55B9FA54.5040902@gmail.com>
Message-ID: <55BA0117.6040203@oracle.com>

On 30/07/15 12:20, Peter Levart wrote:
>
>
> On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
>> Hi Peter,
>>
>> I'm glad you're looking at this too! We can't have too many eyes :-)
>>
>> On 30/07/15 10:38, Peter Levart wrote:
>>> Suppose we have a Reference 'r' and it's associated ReferenceQueue 'q'.
>>> Currently it can happen that the following evaluates to true, which is
>>> surprising:
>>>
>>> q.poll() == null && r.isEnqueued()
>>>
>>
>> But on the other hand this can only happen if two different
>> threads are polling the queue - in which case only one of them
>> will get the reference. In such a situation, the symmetric condition
>> would not be surprising (as the other thread would
>> get q.poll() != null):
>>
>>    r.isEnqueued() && q.poll() == null
>>
>> The original bug fixed by Kim is more surprising, because there's only
>> one Thread doing the polling, and it does get:
>>
>>    r.isEnqueud() && q.poll() == null
>>
>> although nobody else is polling the queue.
>> This should no longer occur in this situation with Kim's fix.
>>
>> cheers,
>>
>> -- daniel
>
> Yes, these are two different issues. The one Kim has fixed is the race
> of above expressions with Queue.enqueue() (when the queue is changing
> from the associated instance to ENQUEUED). The one I'm pointing at and
> Kim has already identified as potential issue is the race of the
> following expression:
>
> r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true
>
> ....with Queue.[realy]poll() (when the queue is changing from ENQUEUED
> to NULL).
>
> Which only happens if at least two threads are polling the queue, but is
> equally surprising and prone to cause bugs, don't you think?

Hi Peter,

Yes - this is also surprising. Is it prone to cause bugs?
possibly - but how serious I'm not sure.
Is it 'equally' surprising - well - that was the point of my argument:
there are two threads polling the same queue - so one of them should
get null... Though I agree that in this case - 'r' should be seen
has having changed state...

The question for me is whether this should be fixed in the same
changeset - or whether we should make it in another changeset...

cheers, and thanks for pointing it out!

-- daniel

>
> Regards, Peter
>
>



From peter.levart at gmail.com  Thu Jul 30 11:37:41 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 30 Jul 2015 13:37:41 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55BA0117.6040203@oracle.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com>
	<55B9EA8A.1080102@oracle.com> <55B9FA54.5040902@gmail.com>
	<55BA0117.6040203@oracle.com>
Message-ID: <55BA0C85.7090802@gmail.com>



On 07/30/2015 12:48 PM, Daniel Fuchs wrote:
> On 30/07/15 12:20, Peter Levart wrote:
>>
>>
>> On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
>>> Hi Peter,
>>>
>>> I'm glad you're looking at this too! We can't have too many eyes :-)
>>>
>>> On 30/07/15 10:38, Peter Levart wrote:
>>>> Suppose we have a Reference 'r' and it's associated ReferenceQueue 
>>>> 'q'.
>>>> Currently it can happen that the following evaluates to true, which is
>>>> surprising:
>>>>
>>>> q.poll() == null && r.isEnqueued()
>>>>
>>>
>>> But on the other hand this can only happen if two different
>>> threads are polling the queue - in which case only one of them
>>> will get the reference. In such a situation, the symmetric condition
>>> would not be surprising (as the other thread would
>>> get q.poll() != null):
>>>
>>>    r.isEnqueued() && q.poll() == null
>>>
>>> The original bug fixed by Kim is more surprising, because there's only
>>> one Thread doing the polling, and it does get:
>>>
>>>    r.isEnqueud() && q.poll() == null
>>>
>>> although nobody else is polling the queue.
>>> This should no longer occur in this situation with Kim's fix.
>>>
>>> cheers,
>>>
>>> -- daniel
>>
>> Yes, these are two different issues. The one Kim has fixed is the race
>> of above expressions with Queue.enqueue() (when the queue is changing
>> from the associated instance to ENQUEUED). The one I'm pointing at and
>> Kim has already identified as potential issue is the race of the
>> following expression:
>>
>> r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true
>>
>> ....with Queue.[realy]poll() (when the queue is changing from ENQUEUED
>> to NULL).
>>
>> Which only happens if at least two threads are polling the queue, but is
>> equally surprising and prone to cause bugs, don't you think?
>
> Hi Peter,
>
> Yes - this is also surprising. Is it prone to cause bugs?
> possibly - but how serious I'm not sure.
> Is it 'equally' surprising - well - that was the point of my argument:
> there are two threads polling the same queue - so one of them should
> get null... Though I agree that in this case - 'r' should be seen
> has having changed state...

poll() returning null by itself is not surprising, but if 'r' appears to 
be "enqueued" before and after the fact, this is surprising.

>
> The question for me is whether this should be fixed in the same
> changeset - or whether we should make it in another changeset...

It's a different issue, though very similar.

Regards, Peter

>
> cheers, and thanks for pointing it out!
>
> -- daniel
>
>>
>> Regards, Peter
>>
>>
>



From david.holmes at oracle.com  Thu Jul 30 11:44:44 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Jul 2015 21:44:44 +1000
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55B9FF5F.2020706@gmail.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com>
	<55B9EA8A.1080102@oracle.com> <55B9FA54.5040902@gmail.com>
	<55B9FB50.8050907@oracle.com> <55B9FF5F.2020706@gmail.com>
Message-ID: <55BA0E2B.9050101@oracle.com>



On 30/07/2015 8:41 PM, Peter Levart wrote:
>
>
> On 07/30/2015 12:24 PM, David Holmes wrote:
>> On 30/07/2015 8:20 PM, Peter Levart wrote:
>>>
>>>
>>> On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
>>>> Hi Peter,
>>>>
>>>> I'm glad you're looking at this too! We can't have too many eyes :-)
>>>>
>>>> On 30/07/15 10:38, Peter Levart wrote:
>>>>> Suppose we have a Reference 'r' and it's associated ReferenceQueue
>>>>> 'q'.
>>>>> Currently it can happen that the following evaluates to true, which is
>>>>> surprising:
>>>>>
>>>>> q.poll() == null && r.isEnqueued()
>>>>>
>>>>
>>>> But on the other hand this can only happen if two different
>>>> threads are polling the queue - in which case only one of them
>>>> will get the reference. In such a situation, the symmetric condition
>>>> would not be surprising (as the other thread would
>>>> get q.poll() != null):
>>>>
>>>>    r.isEnqueued() && q.poll() == null
>>>>
>>>> The original bug fixed by Kim is more surprising, because there's only
>>>> one Thread doing the polling, and it does get:
>>>>
>>>>    r.isEnqueud() && q.poll() == null
>>>>
>>>> although nobody else is polling the queue.
>>>> This should no longer occur in this situation with Kim's fix.
>>>>
>>>> cheers,
>>>>
>>>> -- daniel
>>>
>>> Yes, these are two different issues. The one Kim has fixed is the race
>>> of above expressions with Queue.enqueue() (when the queue is changing
>>> from the associated instance to ENQUEUED). The one I'm pointing at and
>>> Kim has already identified as potential issue is the race of the
>>> following expression:
>>>
>>> r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true
>>>
>>> ....with Queue.[realy]poll() (when the queue is changing from ENQUEUED
>>> to NULL).
>>>
>>> Which only happens if at least two threads are polling the queue, but is
>>> equally surprising and prone to cause bugs, don't you think?
>>
>> Sorry I'm missing your point. The expression:
>>
>> r.isEnqueued() && q.poll() == null
>>
>> is exactly the race the current fix is addressing. Adding a second
>> check of r.isEnqueued() which still returns true does not add anything
>> that I can see. ??
>>
>> David
>
> The expressions are similar, but the race is different. The one
> addressed by Kim is the race of:
>
> r.isEnqueued() && q.poll() == null ==> true
>
> with q.enqueue(r)
>
> There, the reversal of assignments to q.head and r.queue in
> ReferenceQueue.enqueue() fixes the issue.
>
>
> The one I'm pointing at is the race of:
>
> r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true
>
> with q.poll()
>
> Here, the fix would be to also revert the assignments to q.head and
> r.queue in ReferenceQueue.reallyPoll() this time.
>
>
> The 1st race is the race with enqueue-ing and the 2nd race is the race
> with de-queueing. Initially, my "surprising" expression was:
>
> q.poll() == null && r.isEnqueued() ==> true
>
>
> ...but this is not representative, as it is also an expected outcome
> when racing with enqueue-ing. So I added a pre-condition to express the
> fact that it happens when racing with de-queueing only:
>
> r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true
>
>
> What is surprising in the above expression evaluating to true is the
> fact that 'r' appears to be enqueued before and after the q.poll()
> returns null. I can easily imagine code that would fail because it never
> imagined above expression to evaluate to true. For example:

So r has been enqueued and one poll() removes it, so the second poll() 
returns NULL, but r still claims to be enqueued. Sorry I'm not seeing 
how that is possible.

David

>
> if (r.isEnqueued()) {
>      Reference s = q.poll();
>      if (s == null) {
>          // somebody else already dequeued 'r'
>          assert !r.isEnqueued();
>      }
> }
>
>
>
> Regards, Peter
>
>>
>>> Regards, Peter
>>>
>>>
>


From peter.levart at gmail.com  Thu Jul 30 11:57:03 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 30 Jul 2015 13:57:03 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55BA0E2B.9050101@oracle.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com>
	<55B9EA8A.1080102@oracle.com> <55B9FA54.5040902@gmail.com>
	<55B9FB50.8050907@oracle.com> <55B9FF5F.2020706@gmail.com>
	<55BA0E2B.9050101@oracle.com>
Message-ID: <55BA110F.2010101@gmail.com>



On 07/30/2015 01:44 PM, David Holmes wrote:
>> r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true
>>
>>
>> What is surprising in the above expression evaluating to true is the
>> fact that 'r' appears to be enqueued before and after the q.poll()
>> returns null. I can easily imagine code that would fail because it never
>> imagined above expression to evaluate to true. For example:
>
> So r has been enqueued and one poll() removes it, so the second poll() 
> returns NULL, but r still claims to be enqueued. Sorry I'm not seeing 
> how that is possible.
>
> David 

'r' has been enqueued.

Thread-1:

r.isEnqueued() &&
q.poll() == null &&
r.isEnqueued()

Thread-2:

q.poll();


Sequence of actions:

T1: r.isEnqueued() ==> true

T2: q.poll() executed to the following point (see HERE) and 'r' was the 
last element in the queue ('head' has been assigned to null):

     public Reference poll() {
         if (head == null)
             return null;
         synchronized (lock) {
             return reallyPoll();
         }
     }

     private Reference reallyPoll() {       /* Must hold 
lock */
         Reference r = head;
         if (r != null) {
             head = (r.next == r) ?
                 null :
                 r.next; // Unchecked due to the next field having a raw 
type in Reference

             // >> HERE <<<

             r.queue = NULL;
             r.next = r;
             queueLength--;
             if (r instanceof FinalReference) {
                 sun.misc.VM.addFinalRefCount(-1);
             }
             return r;
         }
         return null;
     }

T1: q.poll() finds head == null and returns null;

T1: r.isEnqueued() ==> true since r.queue is still ENQUEUED


Regards, Peter



From david.holmes at oracle.com  Thu Jul 30 12:09:12 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Jul 2015 22:09:12 +1000
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55BA110F.2010101@gmail.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com>
	<55B9EA8A.1080102@oracle.com> <55B9FA54.5040902@gmail.com>
	<55B9FB50.8050907@oracle.com> <55B9FF5F.2020706@gmail.com>
	<55BA0E2B.9050101@oracle.com> <55BA110F.2010101@gmail.com>
Message-ID: <55BA13E8.1050606@oracle.com>

On 30/07/2015 9:57 PM, Peter Levart wrote:
>
>
> On 07/30/2015 01:44 PM, David Holmes wrote:
>>> r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true
>>>
>>>
>>> What is surprising in the above expression evaluating to true is the
>>> fact that 'r' appears to be enqueued before and after the q.poll()
>>> returns null. I can easily imagine code that would fail because it never
>>> imagined above expression to evaluate to true. For example:
>>
>> So r has been enqueued and one poll() removes it, so the second poll()
>> returns NULL, but r still claims to be enqueued. Sorry I'm not seeing
>> how that is possible.
>>
>> David
>
> 'r' has been enqueued.
>
> Thread-1:
>
> r.isEnqueued() &&
> q.poll() == null &&
> r.isEnqueued()
>
> Thread-2:
>
> q.poll();
>
>
> Sequence of actions:
>
> T1: r.isEnqueued() ==> true
>
> T2: q.poll() executed to the following point (see HERE) and 'r' was the
> last element in the queue ('head' has been assigned to null):

Yeah thanks - just realized it is that darned unsynchronized "fast-path" 
again. What a mess.

It a kind of inverse of the original problem.

Original: don't update reference state to enqueued before the queue is 
updated
This one: don't update the queue state to empty before the reference 
state shows it is de-queued.

So yes the fix here is to move "r.queue = null" to before the assignment 
to head.

Bring on the next race ;-)

Thanks,
David

>      public Reference poll() {
>          if (head == null)
>              return null;
>          synchronized (lock) {
>              return reallyPoll();
>          }
>      }
>
>      private Reference reallyPoll() {       /* Must hold
> lock */
>          Reference r = head;
>          if (r != null) {
>              head = (r.next == r) ?
>                  null :
>                  r.next; // Unchecked due to the next field having a raw
> type in Reference
>
>              // >> HERE <<<
>
>              r.queue = NULL;
>              r.next = r;
>              queueLength--;
>              if (r instanceof FinalReference) {
>                  sun.misc.VM.addFinalRefCount(-1);
>              }
>              return r;
>          }
>          return null;
>      }
>
> T1: q.poll() finds head == null and returns null;
>
> T1: r.isEnqueued() ==> true since r.queue is still ENQUEUED
>
>
> Regards, Peter
>


From daniel.fuchs at oracle.com  Thu Jul 30 12:38:18 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 Jul 2015 14:38:18 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55BA0C85.7090802@gmail.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com> <55B9EA8A.1080102@oracle.com>
	<55B9FA54.5040902@gmail.com> <55BA0117.6040203@oracle.com>
	<55BA0C85.7090802@gmail.com>
Message-ID: <55BA1ABA.9080104@oracle.com>

On 30/07/15 13:37, Peter Levart wrote:
> poll() returning null by itself is not surprising, but if 'r' appears to
> be "enqueued" before and after the fact, this is surprising.

Agreed - not disputing this.

>> The question for me is whether this should be fixed in the same
>> changeset - or whether we should make it in another changeset...
>
> It's a different issue, though very similar.

Agreed on both counts :-)

-- daniel


From daniel.fuchs at oracle.com  Thu Jul 30 13:38:05 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 Jul 2015 15:38:05 +0200
Subject: RfR - 8130058: jaxp: Investigate removal of
	com/sun/org/apache/xalan/internal/xslt/Process.java
In-Reply-To: <55B8EB04.2050209@oracle.com>
References: <55B8EB04.2050209@oracle.com>
Message-ID: <55BA28BD.7030309@oracle.com>

Hi,

Please find below an updated webrev:

http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/

Instead of removing the CLITest.java - I copied
Process.java into the test hierarchy, renamed it to
ProcessXSLT.java, modified it so that it no longer uses
internal APIs, and changed the CLITest.java to use that.

The only adherence is with
com.sun.org.apache.xml.internal.utils.DefaultErrorHandler
that the new ProcessXSLT class tries to instantiate
through reflection - as that error handler has access to
jaxp internals and can give a better error diagnostic.

However - the ProcessXSLT will use its own dummy ErrorHandler
if it can't managed to instantiate the internal class.

This way - we can keep the test :-)

best regards,

-- daniel

On 29/07/15 17:02, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch that removes a bunch of unused files
> in jdk9/dev/jaxp:
>
> https://bugs.openjdk.java.net/browse/JDK-8130058
> 8130058: jaxp: Investigate removal of
>           com/sun/org/apache/xalan/internal/xslt/Process.java
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.00/
>
> best regards,
>
> -- daniel



From Roger.Riggs at Oracle.com  Thu Jul 30 14:49:13 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 30 Jul 2015 10:49:13 -0400
Subject: RFR 9: JDK-8132705 : Refactor SharedSecrets in sun.misc.JavaNetAccess
Message-ID: <55BA3969.8090903@Oracle.com>

Please review this refactoring of SharedSecret initialization to create and
InetAddressAccess access that is independent of the initialization
of JavaNetAccess in URLClassLoader.

(jprt in progress)

Webrev:
      http://cr.openjdk.java.net/~rriggs/webrev-inetaccess-8132705/

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

Roger




From chris.hegarty at oracle.com  Thu Jul 30 14:53:34 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 30 Jul 2015 15:53:34 +0100
Subject: RFR 9: JDK-8132705 : Refactor SharedSecrets in
	sun.misc.JavaNetAccess
In-Reply-To: <55BA3969.8090903@Oracle.com>
References: <55BA3969.8090903@Oracle.com>
Message-ID: <4CC20C78-F076-42FF-A192-30834A5FC4D7@oracle.com>

Thanks for doing this Roger. The changes look good to me.

-Chris.

On 30 Jul 2015, at 15:49, Roger Riggs  wrote:

> Please review this refactoring of SharedSecret initialization to create and
> InetAddressAccess access that is independent of the initialization
> of JavaNetAccess in URLClassLoader.
> 
> (jprt in progress)
> 
> Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-inetaccess-8132705/
> 
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8132705
> 
> Roger
> 
> 



From michael.x.mcmahon at oracle.com  Thu Jul 30 14:59:52 2015
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 30 Jul 2015 15:59:52 +0100
Subject: RFR 9: JDK-8132705 : Refactor SharedSecrets in
	sun.misc.JavaNetAccess
In-Reply-To: <55BA3969.8090903@Oracle.com>
References: <55BA3969.8090903@Oracle.com>
Message-ID: <55BA3BE8.9010708@oracle.com>

Looks good Roger. Only minor quibble would be the name of the new type

JavaInetAddressAccess could be JavaNetInetAddressAccess to be consistent.

Michael


On 30/07/15 15:49, Roger Riggs wrote:
> Please review this refactoring of SharedSecret initialization to 
> create and
> InetAddressAccess access that is independent of the initialization
> of JavaNetAccess in URLClassLoader.
>
> (jprt in progress)
>
> Webrev:
>      http://cr.openjdk.java.net/~rriggs/webrev-inetaccess-8132705/
>
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8132705
>
> Roger
>
>



From paul.sandoz at oracle.com  Thu Jul 30 15:08:22 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 30 Jul 2015 17:08:22 +0200
Subject: RFR Collector.finisher refers to IDENTITY_TRANSFORM rather than
	INDENTITY_FINISH
Message-ID: <496DA2CB-EDFD-4E65-8EEE-89830C87FD70@oracle.com>

Hi,

Please review this simple fix to the JavaDoc on j.u.stream.Collector.finisher.

I am also opportunistically fixing some internal comments identified by Tagir.

Paul.

diff -r 4e3135fac8cc src/java.base/share/classes/java/util/stream/Collector.java
--- a/src/java.base/share/classes/java/util/stream/Collector.java	Fri Jul 24 15:33:13 2015 -0700
+++ b/src/java.base/share/classes/java/util/stream/Collector.java	Thu Jul 30 17:05:13 2015 +0200
@@ -223,7 +223,7 @@
      * Perform the final transformation from the intermediate accumulation type
      * {@code A} to the final result type {@code R}.
      *
-     * 
If the characteristic {@code IDENTITY_TRANSFORM} is
+     * 
If the characteristic {@code IDENTITY_FINISH} is
      * set, this function may be presumed to be an identity transform with an
      * unchecked cast from {@code A} to {@code R}.
      *
diff -r 4e3135fac8cc src/java.base/share/classes/java/util/stream/SliceOps.java
--- a/src/java.base/share/classes/java/util/stream/SliceOps.java	Fri Jul 24 15:33:13 2015 -0700
+++ b/src/java.base/share/classes/java/util/stream/SliceOps.java	Thu Jul 30 17:05:13 2015 +0200
@@ -138,7 +138,7 @@
                             skip, limit, size);
                 }
                 else {
-                    // @@@ OOMEs will occur for LongStream.longs().filter(i -> true).limit(n)
+                    // @@@ OOMEs will occur for LongStream.range(0, Long.MAX_VALUE)).filter(i -> true).limit(n)
                     //     regardless of the value of n
                     //     Need to adjust the target size of splitting for the
                     //     SliceTask from say (size / k) to say min(size / k, 1 << 14)
diff -r 4e3135fac8cc src/java.base/share/classes/java/util/stream/Streams.java
--- a/src/java.base/share/classes/java/util/stream/Streams.java	Fri Jul 24 15:33:13 2015 -0700
+++ b/src/java.base/share/classes/java/util/stream/Streams.java	Thu Jul 30 17:05:13 2015 +0200
@@ -156,10 +156,9 @@
          * than a balanced tree at the expense of a higher-depth for the right
          * side of the range.
          *
-         * 
This is optimized for cases such as IntStream.ints() that is
-         * implemented as range of 0 to Integer.MAX_VALUE but is likely to be
-         * augmented with a limit operation that limits the number of elements
-         * to a count lower than this threshold.
+         * 
This is optimized for cases such as IntStream.range(0, Integer.MAX_VALUE)
+         * that is likely to be augmented with a limit operation that limits the
+         * number of elements to a count lower than this threshold.
          */
         private static final int BALANCED_SPLIT_THRESHOLD = 1 << 24;

@@ -280,10 +279,9 @@
          * than a balanced tree at the expense of a higher-depth for the right
          * side of the range.
          *
-         * 
This is optimized for cases such as LongStream.longs() that is
-         * implemented as range of 0 to Long.MAX_VALUE but is likely to be
-         * augmented with a limit operation that limits the number of elements
-         * to a count lower than this threshold.
+         * 
This is optimized for cases such as LongStream.range(0, Long.MAX_VALUE)
+         * that is likely to be augmented with a limit operation that limits the
+         * number of elements to a count lower than this threshold.
          */
         private static final long BALANCED_SPLIT_THRESHOLD = 1 << 24;


From Alan.Bateman at oracle.com  Thu Jul 30 15:08:28 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 Jul 2015 16:08:28 +0100
Subject: RFR 9: JDK-8132705 : Refactor SharedSecrets in
	sun.misc.JavaNetAccess
In-Reply-To: <55BA3969.8090903@Oracle.com>
References: <55BA3969.8090903@Oracle.com>
Message-ID: <55BA3DEC.90101@oracle.com>

On 30/07/2015 15:49, Roger Riggs wrote:
> Please review this refactoring of SharedSecret initialization to 
> create and
> InetAddressAccess access that is independent of the initialization
> of JavaNetAccess in URLClassLoader.
>
> (jprt in progress)
>
> Webrev:
>      http://cr.openjdk.java.net/~rriggs/webrev-inetaccess-8132705/
I assume this should JavaNetInetAddressAccess to be consistent.

I also wondering if JavaNetAccess should be renamed as it is URLClass* 
specific.

-Alan.




From Roger.Riggs at Oracle.com  Thu Jul 30 15:21:16 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 30 Jul 2015 11:21:16 -0400
Subject: RFR 9: JDK-8132705 : Refactor SharedSecrets in
	sun.misc.JavaNetAccess
In-Reply-To: <55BA3DEC.90101@oracle.com>
References: <55BA3969.8090903@Oracle.com> <55BA3DEC.90101@oracle.com>
Message-ID: <55BA40EC.3070808@Oracle.com>

Hi,

I renamed the new interface and its uses as recommended.

The webrev updated in place:

    http://cr.openjdk.java.net/~rriggs/webrev-inetaccess-8132705/

I deferred renaming JavaNetAccess because it (getURLClassPath) is used 
in install and deploy
and I was not certain it would still be needed with the module system in 
place.
It can be renamed (in a separate changeset) if that's useful.

Roger


On 7/30/2015 11:08 AM, Alan Bateman wrote:
> On 30/07/2015 15:49, Roger Riggs wrote:
>> Please review this refactoring of SharedSecret initialization to 
>> create and
>> InetAddressAccess access that is independent of the initialization
>> of JavaNetAccess in URLClassLoader.
>>
>> (jprt in progress)
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-inetaccess-8132705/
> I assume this should JavaNetInetAddressAccess to be consistent.
>
> I also wondering if JavaNetAccess should be renamed as it is URLClass* 
> specific.
>
> -Alan.
>
>



From volker.simonis at gmail.com  Thu Jul 30 15:28:18 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 30 Jul 2015 17:28:18 +0200
Subject: RFR(S): 8132704: [TESTBUG] jdk/internal/jimage/ExecutableTest.java
	incorrectly asserts all files to be executable
Message-ID: 

Hi,

can somebody please review this test fix:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704/
https://bugs.openjdk.java.net/browse/JDK-8132704

The initial test checked that all the files in the bin/ directory are
executable by everybody. Unfortunately this was too optimistic because
in the closed build the bin/ directory contains configuration files
which are not executable.

The new version of the test uses a predefined static list of
executables which are checked for the executable permissions if the
corresponding files exist.

Thank you and best regards,
Volker


From Roger.Riggs at Oracle.com  Thu Jul 30 15:34:06 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 30 Jul 2015 11:34:06 -0400
Subject: RFR(S): 8132704: [TESTBUG]
	jdk/internal/jimage/ExecutableTest.java incorrectly asserts all files
	to be executable
In-Reply-To: 
References: 
Message-ID: <55BA43EE.7070508@Oracle.com>

Hi Volker,

Possibly the real bug is that there is non-executable file in the bin 
directory.
There is a /conf directory which would probably be a better place for that.

Roger





On 7/30/2015 11:28 AM, Volker Simonis wrote:
> Hi,
>
> can somebody please review this test fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704/
> https://bugs.openjdk.java.net/browse/JDK-8132704
>
> The initial test checked that all the files in the bin/ directory are
> executable by everybody. Unfortunately this was too optimistic because
> in the closed build the bin/ directory contains configuration files
> which are not executable.
>
> The new version of the test uses a predefined static list of
> executables which are checked for the executable permissions if the
> corresponding files exist.
>
> Thank you and best regards,
> Volker



From xueming.shen at oracle.com  Thu Jul 30 15:41:28 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 30 Jul 2015 08:41:28 -0700
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version'
	on Linux under zh_CN.GB18030 locale
In-Reply-To: 
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>	<55B78828.6000600@oracle.com>		<55B7EC8B.8000508@oracle.com>		<55B99FEC.8080602@oracle.com>	<55B9ADC9.7020407@oracle.com>	<55B9B46C.9000003@oracle.com>	<55B9D777.5020504@oracle.com>
	
Message-ID: <55BA45A8.6050600@oracle.com>

On 07/30/2015 01:37 AM, Volker Simonis wrote:
> On Thu, Jul 30, 2015 at 9:51 AM, Alan Bateman  wrote:
>>
>> On 30/07/2015 06:21, Xueming Shen wrote:
>>> :
>>>
>>> Each platform has a list of "supported locale/encoding". All these
>>> encodings/charsets need to be in
>>> base module for that particular platform, to support the jvm to start (in
>>> a particular locale/encoding)
>>> under module system. The charsets in our repository can be categorized
>>> into different groups, solaris/
>>> linux specific, windows specific and IBM specific and couple that are
>>> shared by different platforms).
>>> The idea here is to build all those platform-specific charsets into the
>>> base module for that platform.
>> Right, and furthermore, we should be able to build a compact1 image or just
>> an image with the java.base module and it should be able to start on
>> platforms when running with a supported locale/encoding. I think the main
>> issue we've had is establishing that list, hence it had to be extended a few
>> times.
>>
> The change looks fine.
>
> But what about the 'supported locale/encoding' list. Is there a
> published 'official' version of this list for Oracle/OpenJDK and how
> is it maintained.

I meant to say "all the supported/native locale+encoding" of the platform/OS. If we have those
charsets in our repository, they all need go into the base module.

We do have a jdk "supported locale and encoding" list, but they are for the supported java
locale and encoding.

-Sherman


> Regards,
> Volker
>
>> -Alan.



From volker.simonis at gmail.com  Thu Jul 30 15:40:54 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 30 Jul 2015 17:40:54 +0200
Subject: RFR(S): 8132704: [TESTBUG] jdk/internal/jimage/ExecutableTest.java
	incorrectly asserts all files to be executable
In-Reply-To: <55BA43EE.7070508@Oracle.com>
References: 
	<55BA43EE.7070508@Oracle.com>
Message-ID: 

On Thu, Jul 30, 2015 at 5:34 PM, Roger Riggs  wrote:
> Hi Volker,
>
> Possibly the real bug is that there is non-executable file in the bin
> directory.
> There is a /conf directory which would probably be a better place for that.
>

Yes, I agree. But I thought you want a fast fix for the test failure :)
Moving that config file is probably a bigger effort.

Moreover the bin/ directory on Windows also contains .dll and .diz
files. However on Windows, all the files seem to be executable (at
least the test did succeed before). Nevertheless, checking only a
known subset of executables seems safer and "good enough".

What do you think?
Volker

> Roger
>
>
>
>
>
>
> On 7/30/2015 11:28 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> can somebody please review this test fix:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704/
>> https://bugs.openjdk.java.net/browse/JDK-8132704
>>
>> The initial test checked that all the files in the bin/ directory are
>> executable by everybody. Unfortunately this was too optimistic because
>> in the closed build the bin/ directory contains configuration files
>> which are not executable.
>>
>> The new version of the test uses a predefined static list of
>> executables which are checked for the executable permissions if the
>> corresponding files exist.
>>
>> Thank you and best regards,
>> Volker
>
>


From Roger.Riggs at Oracle.com  Thu Jul 30 15:47:08 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 30 Jul 2015 11:47:08 -0400
Subject: RFR(S): 8132704: [TESTBUG]
	jdk/internal/jimage/ExecutableTest.java incorrectly asserts all files
	to be executable
In-Reply-To: 
References: 
	<55BA43EE.7070508@Oracle.com>
	
Message-ID: <55BA46FC.9070205@Oracle.com>

Hi Volker,

There is already as task for JMC to move that file but who knows exactly 
when.

A list of exception(s) would be better I think, because generally, 
everything in bin should be executable.
WDYT?

Roger


On 7/30/2015 11:40 AM, Volker Simonis wrote:
> On Thu, Jul 30, 2015 at 5:34 PM, Roger Riggs  wrote:
>> Hi Volker,
>>
>> Possibly the real bug is that there is non-executable file in the bin
>> directory.
>> There is a /conf directory which would probably be a better place for that.
>>
> Yes, I agree. But I thought you want a fast fix for the test failure :)
> Moving that config file is probably a bigger effort.
>
> Moreover the bin/ directory on Windows also contains .dll and .diz
> files. However on Windows, all the files seem to be executable (at
> least the test did succeed before). Nevertheless, checking only a
> known subset of executables seems safer and "good enough".
>
> What do you think?
> Volker
>
>> Roger
>>
>>
>>
>>
>>
>>
>> On 7/30/2015 11:28 AM, Volker Simonis wrote:
>>> Hi,
>>>
>>> can somebody please review this test fix:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704/
>>> https://bugs.openjdk.java.net/browse/JDK-8132704
>>>
>>> The initial test checked that all the files in the bin/ directory are
>>> executable by everybody. Unfortunately this was too optimistic because
>>> in the closed build the bin/ directory contains configuration files
>>> which are not executable.
>>>
>>> The new version of the test uses a predefined static list of
>>> executables which are checked for the executable permissions if the
>>> corresponding files exist.
>>>
>>> Thank you and best regards,
>>> Volker
>>



From volker.simonis at gmail.com  Thu Jul 30 15:49:33 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 30 Jul 2015 17:49:33 +0200
Subject: RFR(S): 8132704: [TESTBUG] jdk/internal/jimage/ExecutableTest.java
	incorrectly asserts all files to be executable
In-Reply-To: <55BA46FC.9070205@Oracle.com>
References: 
	<55BA43EE.7070508@Oracle.com>
	
	<55BA46FC.9070205@Oracle.com>
Message-ID: 

On Thu, Jul 30, 2015 at 5:47 PM, Roger Riggs  wrote:
> Hi Volker,
>
> There is already as task for JMC to move that file but who knows exactly
> when.
>
> A list of exception(s) would be better I think, because generally,
> everything in bin should be executable.
> WDYT?
>

OK, I'm fine with that.
Unfortunately I'll have to hurry home now.
I'll do the change tomorrow (or you can take over if it's urgent).

Regards,
Volker

> Roger
>
>
>
> On 7/30/2015 11:40 AM, Volker Simonis wrote:
>
> On Thu, Jul 30, 2015 at 5:34 PM, Roger Riggs  wrote:
>
> Hi Volker,
>
> Possibly the real bug is that there is non-executable file in the bin
> directory.
> There is a /conf directory which would probably be a better place for that.
>
> Yes, I agree. But I thought you want a fast fix for the test failure :)
> Moving that config file is probably a bigger effort.
>
> Moreover the bin/ directory on Windows also contains .dll and .diz
> files. However on Windows, all the files seem to be executable (at
> least the test did succeed before). Nevertheless, checking only a
> known subset of executables seems safer and "good enough".
>
> What do you think?
> Volker
>
> Roger
>
>
>
>
>
>
> On 7/30/2015 11:28 AM, Volker Simonis wrote:
>
> Hi,
>
> can somebody please review this test fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704/
> https://bugs.openjdk.java.net/browse/JDK-8132704
>
> The initial test checked that all the files in the bin/ directory are
> executable by everybody. Unfortunately this was too optimistic because
> in the closed build the bin/ directory contains configuration files
> which are not executable.
>
> The new version of the test uses a predefined static list of
> executables which are checked for the executable permissions if the
> corresponding files exist.
>
> Thank you and best regards,
> Volker
>
>


From Alan.Bateman at oracle.com  Thu Jul 30 15:54:54 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 Jul 2015 16:54:54 +0100
Subject: RFR 9: JDK-8132705 : Refactor SharedSecrets in
	sun.misc.JavaNetAccess
In-Reply-To: <55BA40EC.3070808@Oracle.com>
References: <55BA3969.8090903@Oracle.com> <55BA3DEC.90101@oracle.com>
	<55BA40EC.3070808@Oracle.com>
Message-ID: <55BA48CE.7000704@oracle.com>

On 30/07/2015 16:21, Roger Riggs wrote:
> Hi,
>
> I renamed the new interface and its uses as recommended.
>
> The webrev updated in place:
>
> http://cr.openjdk.java.net/~rriggs/webrev-inetaccess-8132705/
>
> I deferred renaming JavaNetAccess because it (getURLClassPath) is used 
> in install and deploy
> and I was not certain it would still be needed with the module system 
> in place.
> It can be renamed (in a separate changeset) if that's useful.
Thanks for the rename, looks good now.

I don't think the getURLClassPath method will be relevant when we bring 
in the module system, mostly because the app class loader has not need 
to be a URLClassLoader.

-Alan


From huizhe.wang at oracle.com  Thu Jul 30 15:55:43 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 30 Jul 2015 08:55:43 -0700
Subject: RfR - 8130058: jaxp: Investigate removal of
	com/sun/org/apache/xalan/internal/xslt/Process.java
In-Reply-To: <55BA28BD.7030309@oracle.com>
References: <55B8EB04.2050209@oracle.com> <55BA28BD.7030309@oracle.com>
Message-ID: <55BA48FF.1070507@oracle.com>

Hi Daniel,

On 7/30/2015 6:38 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below an updated webrev:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/

Looks good to me. The only nit is it seems createDefaultErrorHandler 
method is a dup of createDefaultErrorListener?

>
> Instead of removing the CLITest.java - I copied
> Process.java into the test hierarchy, renamed it to
> ProcessXSLT.java, modified it so that it no longer uses
> internal APIs, and changed the CLITest.java to use that.

This is a good idea as it keeps the Process utility around.
>
> The only adherence is with
> com.sun.org.apache.xml.internal.utils.DefaultErrorHandler
> that the new ProcessXSLT class tries to instantiate
> through reflection - as that error handler has access to
> jaxp internals and can give a better error diagnostic.
>
> However - the ProcessXSLT will use its own dummy ErrorHandler
> if it can't managed to instantiate the internal class.
>
> This way - we can keep the test :-)

Perfect indeed, and if others (Yuri) want to use it, it's readily usable.

best,
Joe

>
> best regards,
>
> -- daniel
>
> On 29/07/15 17:02, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a patch that removes a bunch of unused files
>> in jdk9/dev/jaxp:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8130058
>> 8130058: jaxp: Investigate removal of
>>           com/sun/org/apache/xalan/internal/xslt/Process.java
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.00/
>>
>> best regards,
>>
>> -- daniel
>



From spliterator at gmail.com  Thu Jul 30 16:08:00 2015
From: spliterator at gmail.com (Stefan Zobel)
Date: Thu, 30 Jul 2015 18:08:00 +0200
Subject: RFR Collector.finisher refers to IDENTITY_TRANSFORM rather than
	INDENTITY_FINISH
In-Reply-To: <496DA2CB-EDFD-4E65-8EEE-89830C87FD70@oracle.com>
References: <496DA2CB-EDFD-4E65-8EEE-89830C87FD70@oracle.com>
Message-ID: 

Hi Paul,

perhaps you could take the opportunity and also add the missing "@since
1.9" tags to all the new dropWhile() / takeWhile() methods (JDK-8071597).

Also in dropWhile() / takeWhile() there is a small typo (I guess) in the
Javadoc:


takeWhile: "takes all elements (the result is the same is the input)"

dropWhile: "the stream match the given predicate then no elements are
dropped (the result is the same is the input)"


I guess that should read: "(the result is the same as is the input)"?


Stefan


2015-07-30 17:08 GMT+02:00 Paul Sandoz :

> Hi,
>
> Please review this simple fix to the JavaDoc on
> j.u.stream.Collector.finisher.
>
> I am also opportunistically fixing some internal comments identified by
> Tagir.
>
> Paul.
>
> diff -r 4e3135fac8cc
> src/java.base/share/classes/java/util/stream/Collector.java
> --- a/src/java.base/share/classes/java/util/stream/Collector.java
>  Fri Jul 24 15:33:13 2015 -0700
> +++ b/src/java.base/share/classes/java/util/stream/Collector.java
>  Thu Jul 30 17:05:13 2015 +0200
> @@ -223,7 +223,7 @@
>       * Perform the final transformation from the intermediate
> accumulation type
>       * {@code A} to the final result type {@code R}.
>       *
> -     * 
If the characteristic {@code IDENTITY_TRANSFORM} is
> +     * 
If the characteristic {@code IDENTITY_FINISH} is
>       * set, this function may be presumed to be an identity transform
> with an
>       * unchecked cast from {@code A} to {@code R}.
>       *
> diff -r 4e3135fac8cc
> src/java.base/share/classes/java/util/stream/SliceOps.java
> --- a/src/java.base/share/classes/java/util/stream/SliceOps.java
> Fri Jul 24 15:33:13 2015 -0700
> +++ b/src/java.base/share/classes/java/util/stream/SliceOps.java
> Thu Jul 30 17:05:13 2015 +0200
> @@ -138,7 +138,7 @@
>                              skip, limit, size);
>                  }
>                  else {
> -                    // @@@ OOMEs will occur for
> LongStream.longs().filter(i -> true).limit(n)
> +                    // @@@ OOMEs will occur for LongStream.range(0,
> Long.MAX_VALUE)).filter(i -> true).limit(n)
>                      //     regardless of the value of n
>                      //     Need to adjust the target size of splitting
> for the
>                      //     SliceTask from say (size / k) to say min(size
> / k, 1 << 14)
> diff -r 4e3135fac8cc
> src/java.base/share/classes/java/util/stream/Streams.java
> --- a/src/java.base/share/classes/java/util/stream/Streams.java Fri Jul 24
> 15:33:13 2015 -0700
> +++ b/src/java.base/share/classes/java/util/stream/Streams.java Thu Jul 30
> 17:05:13 2015 +0200
> @@ -156,10 +156,9 @@
>           * than a balanced tree at the expense of a higher-depth for the
> right
>           * side of the range.
>           *
> -         * 
This is optimized for cases such as IntStream.ints() that is
> -         * implemented as range of 0 to Integer.MAX_VALUE but is likely
> to be
> -         * augmented with a limit operation that limits the number of
> elements
> -         * to a count lower than this threshold.
> +         * 
This is optimized for cases such as IntStream.range(0,
> Integer.MAX_VALUE)
> +         * that is likely to be augmented with a limit operation that
> limits the
> +         * number of elements to a count lower than this threshold.
>           */
>          private static final int BALANCED_SPLIT_THRESHOLD = 1 << 24;
>
> @@ -280,10 +279,9 @@
>           * than a balanced tree at the expense of a higher-depth for the
> right
>           * side of the range.
>           *
> -         * 
This is optimized for cases such as LongStream.longs() that
> is
> -         * implemented as range of 0 to Long.MAX_VALUE but is likely to be
> -         * augmented with a limit operation that limits the number of
> elements
> -         * to a count lower than this threshold.
> +         * 
This is optimized for cases such as LongStream.range(0,
> Long.MAX_VALUE)
> +         * that is likely to be augmented with a limit operation that
> limits the
> +         * number of elements to a count lower than this threshold.
>           */
>          private static final long BALANCED_SPLIT_THRESHOLD = 1 << 24;
>


From daniel.fuchs at oracle.com  Thu Jul 30 16:08:36 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 Jul 2015 18:08:36 +0200
Subject: RfR - 8130058: jaxp: Investigate removal of
	com/sun/org/apache/xalan/internal/xslt/Process.java
In-Reply-To: <55BA48FF.1070507@oracle.com>
References: <55B8EB04.2050209@oracle.com> <55BA28BD.7030309@oracle.com>
	<55BA48FF.1070507@oracle.com>
Message-ID: <55BA4C04.90409@oracle.com>

On 30/07/15 17:55, huizhe wang wrote:
> Hi Daniel,
>
> On 7/30/2015 6:38 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below an updated webrev:
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/
>
> Looks good to me. The only nit is it seems createDefaultErrorHandler
> method is a dup of createDefaultErrorListener?

Yes it is - but the return type is different.

>> Instead of removing the CLITest.java - I copied
>> Process.java into the test hierarchy, renamed it to
>> ProcessXSLT.java, modified it so that it no longer uses
>> internal APIs, and changed the CLITest.java to use that.
>
> This is a good idea as it keeps the Process utility around.
>>
>> The only adherence is with
>> com.sun.org.apache.xml.internal.utils.DefaultErrorHandler
>> that the new ProcessXSLT class tries to instantiate
>> through reflection - as that error handler has access to
>> jaxp internals and can give a better error diagnostic.
>>
>> However - the ProcessXSLT will use its own dummy ErrorHandler
>> if it can't managed to instantiate the internal class.
>>
>> This way - we can keep the test :-)
>
> Perfect indeed, and if others (Yuri) want to use it, it's readily usable.

Thanks Joe!

-- daniel

>
> best,
> Joe
>
>>
>> best regards,
>>
>> -- daniel
>>
>> On 29/07/15 17:02, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a patch that removes a bunch of unused files
>>> in jdk9/dev/jaxp:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8130058
>>> 8130058: jaxp: Investigate removal of
>>>           com/sun/org/apache/xalan/internal/xslt/Process.java
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.00/
>>>
>>> best regards,
>>>
>>> -- daniel
>>
>



From huizhe.wang at oracle.com  Thu Jul 30 16:16:30 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 30 Jul 2015 09:16:30 -0700
Subject: RfR - 8130058: jaxp: Investigate removal of
	com/sun/org/apache/xalan/internal/xslt/Process.java
In-Reply-To: <55BA4C04.90409@oracle.com>
References: <55B8EB04.2050209@oracle.com> <55BA28BD.7030309@oracle.com>
	<55BA48FF.1070507@oracle.com> <55BA4C04.90409@oracle.com>
Message-ID: <55BA4DDE.2000201@oracle.com>


On 7/30/2015 9:08 AM, Daniel Fuchs wrote:
> On 30/07/15 17:55, huizhe wang wrote:
>> Hi Daniel,
>>
>> On 7/30/2015 6:38 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below an updated webrev:
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/
>>
>> Looks good to me. The only nit is it seems createDefaultErrorHandler
>> method is a dup of createDefaultErrorListener?
>
> Yes it is - but the return type is different.

Yes, but didn't see it's used.

Joe

>
>>> Instead of removing the CLITest.java - I copied
>>> Process.java into the test hierarchy, renamed it to
>>> ProcessXSLT.java, modified it so that it no longer uses
>>> internal APIs, and changed the CLITest.java to use that.
>>
>> This is a good idea as it keeps the Process utility around.
>>>
>>> The only adherence is with
>>> com.sun.org.apache.xml.internal.utils.DefaultErrorHandler
>>> that the new ProcessXSLT class tries to instantiate
>>> through reflection - as that error handler has access to
>>> jaxp internals and can give a better error diagnostic.
>>>
>>> However - the ProcessXSLT will use its own dummy ErrorHandler
>>> if it can't managed to instantiate the internal class.
>>>
>>> This way - we can keep the test :-)
>>
>> Perfect indeed, and if others (Yuri) want to use it, it's readily 
>> usable.
>
> Thanks Joe!
>
> -- daniel
>
>>
>> best,
>> Joe
>>
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 29/07/15 17:02, Daniel Fuchs wrote:
>>>> Hi,
>>>>
>>>> Please find below a patch that removes a bunch of unused files
>>>> in jdk9/dev/jaxp:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8130058
>>>> 8130058: jaxp: Investigate removal of
>>>> com/sun/org/apache/xalan/internal/xslt/Process.java
>>>>
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.00/
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>
>>
>



From daniel.fuchs at oracle.com  Thu Jul 30 16:20:31 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 Jul 2015 18:20:31 +0200
Subject: RfR - 8130058: jaxp: Investigate removal of
	com/sun/org/apache/xalan/internal/xslt/Process.java
In-Reply-To: <55BA4DDE.2000201@oracle.com>
References: <55B8EB04.2050209@oracle.com> <55BA28BD.7030309@oracle.com>
	<55BA48FF.1070507@oracle.com> <55BA4C04.90409@oracle.com>
	<55BA4DDE.2000201@oracle.com>
Message-ID: <55BA4ECF.90905@oracle.com>

On 30/07/15 18:16, huizhe wang wrote:
>
> On 7/30/2015 9:08 AM, Daniel Fuchs wrote:
>> On 30/07/15 17:55, huizhe wang wrote:
>>> Hi Daniel,
>>>
>>> On 7/30/2015 6:38 AM, Daniel Fuchs wrote:
>>>> Hi,
>>>>
>>>> Please find below an updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/
>>>
>>> Looks good to me. The only nit is it seems createDefaultErrorHandler
>>> method is a dup of createDefaultErrorListener?
>>
>> Yes it is - but the return type is different.
>
> Yes, but didn't see it's used.

Good point! Removed.

-- daniel

>
> Joe
>
>>
>>>> Instead of removing the CLITest.java - I copied
>>>> Process.java into the test hierarchy, renamed it to
>>>> ProcessXSLT.java, modified it so that it no longer uses
>>>> internal APIs, and changed the CLITest.java to use that.
>>>
>>> This is a good idea as it keeps the Process utility around.
>>>>
>>>> The only adherence is with
>>>> com.sun.org.apache.xml.internal.utils.DefaultErrorHandler
>>>> that the new ProcessXSLT class tries to instantiate
>>>> through reflection - as that error handler has access to
>>>> jaxp internals and can give a better error diagnostic.
>>>>
>>>> However - the ProcessXSLT will use its own dummy ErrorHandler
>>>> if it can't managed to instantiate the internal class.
>>>>
>>>> This way - we can keep the test :-)
>>>
>>> Perfect indeed, and if others (Yuri) want to use it, it's readily
>>> usable.
>>
>> Thanks Joe!
>>
>> -- daniel
>>
>>>
>>> best,
>>> Joe
>>>
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>> On 29/07/15 17:02, Daniel Fuchs wrote:
>>>>> Hi,
>>>>>
>>>>> Please find below a patch that removes a bunch of unused files
>>>>> in jdk9/dev/jaxp:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8130058
>>>>> 8130058: jaxp: Investigate removal of
>>>>> com/sun/org/apache/xalan/internal/xslt/Process.java
>>>>>
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.00/
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>
>>>
>>
>



From amaembo at gmail.com  Thu Jul 30 16:25:21 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Thu, 30 Jul 2015 22:25:21 +0600
Subject: RFR Collector.finisher refers to IDENTITY_TRANSFORM rather than
	INDENTITY_FINISH
In-Reply-To: <496DA2CB-EDFD-4E65-8EEE-89830C87FD70@oracle.com>
References: <496DA2CB-EDFD-4E65-8EEE-89830C87FD70@oracle.com>
Message-ID: <8710158352.20150730222521@gmail.com>

Hello!

Seems that you have an extra parenthesis here:

diff -r 4e3135fac8cc src/java.base/share/classes/java/util/stream/SliceOps.java
--- a/src/java.base/share/classes/java/util/stream/SliceOps.java        Fri Jul 24 15:33:13 2015 -0700
+++ b/src/java.base/share/classes/java/util/stream/SliceOps.java        Thu Jul 30 17:05:13 2015 +0200
@@ -138,7 +138,7 @@
                             skip, limit, size);
                 }
                 else {
-                    // @@@ OOMEs will occur for LongStream.longs().filter(i -> true).limit(n)
+                    // @@@ OOMEs will occur for LongStream.range(0, Long.MAX_VALUE)).filter(i -> true).limit(n)

Should be

+                    // @@@ OOMEs will occur for LongStream.range(0, Long.MAX_VALUE).filter(i -> true).limit(n)

With best regards,
Tagir Valeev.



From paul.sandoz at oracle.com  Thu Jul 30 16:32:56 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 30 Jul 2015 18:32:56 +0200
Subject: RFR 8130828: Fix some typos and omissions in the the j.u.stream
	JavaDoc
In-Reply-To: 
References: <496DA2CB-EDFD-4E65-8EEE-89830C87FD70@oracle.com>
	
Message-ID: <541E9EF8-FB31-4261-B23C-69CEED58DE54@oracle.com>

Hi Stefan, Tagir,

Updated:

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130828-stream-doc-typos/webrev/

Paul.

On 30 Jul 2015, at 18:08, Stefan Zobel  wrote:

> Hi Paul,
> 
> perhaps you could take the opportunity and also add the missing "@since
> 1.9" tags to all the new dropWhile() / takeWhile() methods (JDK-8071597).
> 
> Also in dropWhile() / takeWhile() there is a small typo (I guess) in the
> Javadoc:
> 
> 
> takeWhile: "takes all elements (the result is the same is the input)"
> 
> dropWhile: "the stream match the given predicate then no elements are
> dropped (the result is the same is the input)"
> 
> 
> I guess that should read: "(the result is the same as is the input)"?
> 
> 
> Stefan



From xueming.shen at oracle.com  Thu Jul 30 17:34:26 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 30 Jul 2015 10:34:26 -0700
Subject: RFR JDK-8080252: java.util.Formatter documentation of %n converter is
	misleading
Message-ID: <55BA6022.9070106@oracle.com>

Hi,

Please help review the change for

issue: https://bugs.openjdk.java.net/browse/JDK-8080252
webrev: http://cr.openjdk.java.net/~sherman/8080252/

It appears we updated the j.u.Formatter implementation to use the newly 
introduced
method System.lineSeparator() in jdk7, but did not update the doc 
accordingly.

For the old the behavior, I would assume the initial intent is to treat 
the system property
line.separator as a read-only/informative property.

Given the fact the it has been 2 major releases (7, 8), I would assume 
this change is now
a kind of change to "update the javadoc to describe the existing 
implementation correctly".
So a CCC is not needed.

Thanks,
Sherman




From spliterator at gmail.com  Thu Jul 30 18:58:34 2015
From: spliterator at gmail.com (Stefan Zobel)
Date: Thu, 30 Jul 2015 20:58:34 +0200
Subject: RFR 8130828: Fix some typos and omissions in the the j.u.stream
	JavaDoc
In-Reply-To: <541E9EF8-FB31-4261-B23C-69CEED58DE54@oracle.com>
References: <496DA2CB-EDFD-4E65-8EEE-89830C87FD70@oracle.com>
	
	<541E9EF8-FB31-4261-B23C-69CEED58DE54@oracle.com>
Message-ID: 

Hi Paul,

looks good.


Stefan


2015-07-30 18:32 GMT+02:00 Paul Sandoz :

> Hi Stefan, Tagir,
>
> Updated:
>
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130828-stream-doc-typos/webrev/
>
> Paul.
>
>


From kim.barrett at oracle.com  Thu Jul 30 19:54:11 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 30 Jul 2015 15:54:11 -0400
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55BA13E8.1050606@oracle.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com> <55B9EA8A.1080102@oracle.com>
	<55B9FA54.5040902@gmail.com> <55B9FB50.8050907@oracle.com>
	<55B9FF5F.2020706@gmail.com> <55BA0E2B.9050101@oracle.com>
	<55BA110F.2010101@gmail.com> <55BA13E8.1050606@oracle.com>
Message-ID: 

On Jul 30, 2015, at 8:09 AM, David Holmes  wrote:
> 
> On 30/07/2015 9:57 PM, Peter Levart wrote:
>> 'r' has been enqueued.
>> 
>> Thread-1:
>> 
>> r.isEnqueued() &&
>> q.poll() == null &&
>> r.isEnqueued()
>> 
>> Thread-2:
>> 
>> q.poll();
>> 
>> 
>> Sequence of actions:
>> 
>> T1: r.isEnqueued() ==> true
>> 
>> T2: q.poll() executed to the following point (see HERE) and 'r' was the
>> last element in the queue ('head' has been assigned to null):
> 
> Yeah thanks - just realized it is that darned unsynchronized "fast-path" again. What a mess.
> 
> It a kind of inverse of the original problem.
> 
> Original: don't update reference state to enqueued before the queue is updated
> This one: don't update the queue state to empty before the reference state shows it is de-queued.
> 
> So yes the fix here is to move "r.queue = null" to before the assignment to head.
> 
> Bring on the next race ;-)

I agree with everything David said above.  Bleh!

So I think I can either:

1. Go ahead with my change + Peter's change.

2. Give this back to core-libs while I step carefully away :-)

I *think* option (1) is at least an improvement.  But I completely
missed Peter's race, despite having specifically looked for problems
there, so take my opinion with an appropriate quantity of salt.




From daniel.fuchs at oracle.com  Thu Jul 30 20:12:12 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 Jul 2015 22:12:12 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: 
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com>
	<55B9EA8A.1080102@oracle.com> <55B9FA54.5040902@gmail.com>
	<55B9FB50.8050907@oracle.com> <55B9FF5F.2020706@gmail.com>
	<55BA0E2B.9050101@oracle.com> <55BA110F.2010101@gmail.com>
	<55BA13E8.1050606@oracle.com>
	
Message-ID: <55BA851C.5080706@oracle.com>

I vote for 1.

:-)

cheers,

-- daniel

On 7/30/15 9:54 PM, Kim Barrett wrote:
> On Jul 30, 2015, at 8:09 AM, David Holmes  wrote:
>> On 30/07/2015 9:57 PM, Peter Levart wrote:
>>> 'r' has been enqueued.
>>>
>>> Thread-1:
>>>
>>> r.isEnqueued() &&
>>> q.poll() == null &&
>>> r.isEnqueued()
>>>
>>> Thread-2:
>>>
>>> q.poll();
>>>
>>>
>>> Sequence of actions:
>>>
>>> T1: r.isEnqueued() ==> true
>>>
>>> T2: q.poll() executed to the following point (see HERE) and 'r' was the
>>> last element in the queue ('head' has been assigned to null):
>> Yeah thanks - just realized it is that darned unsynchronized "fast-path" again. What a mess.
>>
>> It a kind of inverse of the original problem.
>>
>> Original: don't update reference state to enqueued before the queue is updated
>> This one: don't update the queue state to empty before the reference state shows it is de-queued.
>>
>> So yes the fix here is to move "r.queue = null" to before the assignment to head.
>>
>> Bring on the next race ;-)
> I agree with everything David said above.  Bleh!
>
> So I think I can either:
>
> 1. Go ahead with my change + Peter's change.
>
> 2. Give this back to core-libs while I step carefully away :-)
>
> I *think* option (1) is at least an improvement.  But I completely
> missed Peter's race, despite having specifically looked for problems
> there, so take my opinion with an appropriate quantity of salt.
>
>



From david.holmes at oracle.com  Thu Jul 30 21:33:36 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 31 Jul 2015 07:33:36 +1000
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: 
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com>
	<55B9EA8A.1080102@oracle.com> <55B9FA54.5040902@gmail.com>
	<55B9FB50.8050907@oracle.com> <55B9FF5F.2020706@gmail.com>
	<55BA0E2B.9050101@oracle.com> <55BA110F.2010101@gmail.com>
	<55BA13E8.1050606@oracle.com>
	
Message-ID: <55BA9830.8030308@oracle.com>

On 31/07/2015 5:54 AM, Kim Barrett wrote:
> On Jul 30, 2015, at 8:09 AM, David Holmes  wrote:
>>
>> On 30/07/2015 9:57 PM, Peter Levart wrote:
>>> 'r' has been enqueued.
>>>
>>> Thread-1:
>>>
>>> r.isEnqueued() &&
>>> q.poll() == null &&
>>> r.isEnqueued()
>>>
>>> Thread-2:
>>>
>>> q.poll();
>>>
>>>
>>> Sequence of actions:
>>>
>>> T1: r.isEnqueued() ==> true
>>>
>>> T2: q.poll() executed to the following point (see HERE) and 'r' was the
>>> last element in the queue ('head' has been assigned to null):
>>
>> Yeah thanks - just realized it is that darned unsynchronized "fast-path" again. What a mess.
>>
>> It a kind of inverse of the original problem.
>>
>> Original: don't update reference state to enqueued before the queue is updated
>> This one: don't update the queue state to empty before the reference state shows it is de-queued.
>>
>> So yes the fix here is to move "r.queue = null" to before the assignment to head.
>>
>> Bring on the next race ;-)
>
> I agree with everything David said above.  Bleh!
>
> So I think I can either:
>
> 1. Go ahead with my change + Peter's change.
>
> 2. Give this back to core-libs while I step carefully away :-)
>
> I *think* option (1) is at least an improvement.  But I completely
> missed Peter's race, despite having specifically looked for problems
> there, so take my opinion with an appropriate quantity of salt.

I vote for 1 as well. I think we have now given good coverage to the two 
sources of problems (the two lock-free regions):
- reference queue state can be seen while queue state is in transition
- queue empty state can be seen while reference state is in transition

Oh for a tool that would do this analysis for us :(

Thanks,
David

>


From david.holmes at oracle.com  Thu Jul 30 22:01:16 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 31 Jul 2015 08:01:16 +1000
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version' on
	Linux under zh_CN.GB18030 locale
In-Reply-To: <55BA45A8.6050600@oracle.com>
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
	
	<55B7EC8B.8000508@oracle.com>
	
	<55B99FEC.8080602@oracle.com> <55B9ADC9.7020407@oracle.com>
	<55B9B46C.9000003@oracle.com> <55B9D777.5020504@oracle.com>
	
	<55BA45A8.6050600@oracle.com>
Message-ID: <55BA9EAC.5000907@oracle.com>

On 31/07/2015 1:41 AM, Xueming Shen wrote:
> On 07/30/2015 01:37 AM, Volker Simonis wrote:
>> On Thu, Jul 30, 2015 at 9:51 AM, Alan
>> Bateman  wrote:
>>>
>>> On 30/07/2015 06:21, Xueming Shen wrote:
>>>> :
>>>>
>>>> Each platform has a list of "supported locale/encoding". All these
>>>> encodings/charsets need to be in
>>>> base module for that particular platform, to support the jvm to
>>>> start (in
>>>> a particular locale/encoding)
>>>> under module system. The charsets in our repository can be categorized
>>>> into different groups, solaris/
>>>> linux specific, windows specific and IBM specific and couple that are
>>>> shared by different platforms).
>>>> The idea here is to build all those platform-specific charsets into the
>>>> base module for that platform.
>>> Right, and furthermore, we should be able to build a compact1 image
>>> or just
>>> an image with the java.base module and it should be able to start on
>>> platforms when running with a supported locale/encoding. I think the
>>> main
>>> issue we've had is establishing that list, hence it had to be
>>> extended a few
>>> times.
>>>
>> The change looks fine.
>>
>> But what about the 'supported locale/encoding' list. Is there a
>> published 'official' version of this list for Oracle/OpenJDK and how
>> is it maintained.
>
> I meant to say "all the supported/native locale+encoding" of the
> platform/OS. If we have those
> charsets in our repository, they all need go into the base module.

Now I'm confused again. Do the platforms we officially support have set 
lists of such locales/encodings? If so getting our list correct seems 
trivial. If not, then how can we support an unknown target??

Thanks,
David


> We do have a jdk "supported locale and encoding" list, but they are for
> the supported java
> locale and encoding.
>
> -Sherman
>
>
>> Regards,
>> Volker
>>
>>> -Alan.
>


From xueming.shen at oracle.com  Thu Jul 30 22:24:44 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 30 Jul 2015 15:24:44 -0700
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version'
	on Linux under zh_CN.GB18030 locale
In-Reply-To: <55BA9EAC.5000907@oracle.com>
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
	
	<55B7EC8B.8000508@oracle.com>
	
	<55B99FEC.8080602@oracle.com> <55B9ADC9.7020407@oracle.com>
	<55B9B46C.9000003@oracle.com> <55B9D777.5020504@oracle.com>
	
	<55BA45A8.6050600@oracle.com> <55BA9EAC.5000907@oracle.com>
Message-ID: <55BAA42C.6000406@oracle.com>

On 07/30/2015 03:01 PM, David Holmes wrote:
> On 31/07/2015 1:41 AM, Xueming Shen wrote:
>> On 07/30/2015 01:37 AM, Volker Simonis wrote:
>>> On Thu, Jul 30, 2015 at 9:51 AM, Alan
>>> Bateman  wrote:
>>>>
>>>> On 30/07/2015 06:21, Xueming Shen wrote:
>>>>> :
>>>>>
>>>>> Each platform has a list of "supported locale/encoding". All these
>>>>> encodings/charsets need to be in
>>>>> base module for that particular platform, to support the jvm to
>>>>> start (in
>>>>> a particular locale/encoding)
>>>>> under module system. The charsets in our repository can be categorized
>>>>> into different groups, solaris/
>>>>> linux specific, windows specific and IBM specific and couple that are
>>>>> shared by different platforms).
>>>>> The idea here is to build all those platform-specific charsets into the
>>>>> base module for that platform.
>>>> Right, and furthermore, we should be able to build a compact1 image
>>>> or just
>>>> an image with the java.base module and it should be able to start on
>>>> platforms when running with a supported locale/encoding. I think the
>>>> main
>>>> issue we've had is establishing that list, hence it had to be
>>>> extended a few
>>>> times.
>>>>
>>> The change looks fine.
>>>
>>> But what about the 'supported locale/encoding' list. Is there a
>>> published 'official' version of this list for Oracle/OpenJDK and how
>>> is it maintained.
>>
>> I meant to say "all the supported/native locale+encoding" of the
>> platform/OS. If we have those
>> charsets in our repository, they all need go into the base module.
>
> Now I'm confused again. Do the platforms we officially support have set lists of such locales/encodings? If so getting our list correct seems trivial. If not, then how can we support an unknown target??
>

it's a "known" target. we know the list of the locale/encoding solais /linux supports and the list
of charsets Java supports.

-sherman



From stuart.marks at oracle.com  Thu Jul 30 22:39:47 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 30 Jul 2015 15:39:47 -0700
Subject: RFR(xs): 8132745: minor cleanup of java/util/Scanner/ScanTest.java
Message-ID: <55BAA7B3.1040905@oracle.com>

Hi all,

Please review this quick cleanup to this test I moved into the open yesterday. 
It changes the JVM's locale, and out of an abundance of caution it's safer to 
run things that change JVM global state in /othervm mode.

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

Patch appended below.

Thanks,

s'marks



# HG changeset patch
# User smarks
# Date 1438295744 25200
#      Thu Jul 30 15:35:44 2015 -0700
# Node ID 4ce7979b7610574075bd4ade3b73004cde5e9ac3
# Parent  d23203801b5369603d2dda21a6aff6225195001d
8132745: minor cleanup of java/util/Scanner/ScanTest.java
Reviewed-by: XXX

diff -r d23203801b53 -r 4ce7979b7610 test/java/util/Scanner/ScanTest.java
--- a/test/java/util/Scanner/ScanTest.java	Thu Jul 30 14:16:58 2015 -0400
+++ b/test/java/util/Scanner/ScanTest.java	Thu Jul 30 15:35:44 2015 -0700
@@ -26,6 +26,7 @@
   * @bug 4313885 4926319 4927634 5032610 5032622 5049968 5059533 6223711 
6277261 6269946 6288823
   * @summary Basic tests of java.util.Scanner methods
   * @key randomness
+ * @run main/othervm ScanTest
   */

  import java.util.*;


From joe.darcy at oracle.com  Thu Jul 30 22:40:57 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 30 Jul 2015 15:40:57 -0700
Subject: RFR(xs): 8132745: minor cleanup of java/util/Scanner/ScanTest.java
In-Reply-To: <55BAA7B3.1040905@oracle.com>
References: <55BAA7B3.1040905@oracle.com>
Message-ID: <55BAA7F9.7080800@oracle.com>

Looks fine Stuart,

-Joe

On 7/30/2015 3:39 PM, Stuart Marks wrote:
> Hi all,
>
> Please review this quick cleanup to this test I moved into the open 
> yesterday. It changes the JVM's locale, and out of an abundance of 
> caution it's safer to run things that change JVM global state in 
> /othervm mode.
>
> Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8132745
>
> Patch appended below.
>
> Thanks,
>
> s'marks
>
>
>
> # HG changeset patch
> # User smarks
> # Date 1438295744 25200
> #      Thu Jul 30 15:35:44 2015 -0700
> # Node ID 4ce7979b7610574075bd4ade3b73004cde5e9ac3
> # Parent  d23203801b5369603d2dda21a6aff6225195001d
> 8132745: minor cleanup of java/util/Scanner/ScanTest.java
> Reviewed-by: XXX
>
> diff -r d23203801b53 -r 4ce7979b7610 test/java/util/Scanner/ScanTest.java
> --- a/test/java/util/Scanner/ScanTest.java    Thu Jul 30 14:16:58 2015 
> -0400
> +++ b/test/java/util/Scanner/ScanTest.java    Thu Jul 30 15:35:44 2015 
> -0700
> @@ -26,6 +26,7 @@
>   * @bug 4313885 4926319 4927634 5032610 5032622 5049968 5059533 
> 6223711 6277261 6269946 6288823
>   * @summary Basic tests of java.util.Scanner methods
>   * @key randomness
> + * @run main/othervm ScanTest
>   */
>
>  import java.util.*;



From xueming.shen at oracle.com  Thu Jul 30 22:43:48 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 30 Jul 2015 15:43:48 -0700
Subject: RFR(xs): 8132745: minor cleanup of java/util/Scanner/ScanTest.java
In-Reply-To: <55BAA7F9.7080800@oracle.com>
References: <55BAA7B3.1040905@oracle.com> <55BAA7F9.7080800@oracle.com>
Message-ID: <55BAA8A4.70503@oracle.com>

+1

On 07/30/2015 03:40 PM, Joseph D. Darcy wrote:
> Looks fine Stuart,
>
> -Joe
>
> On 7/30/2015 3:39 PM, Stuart Marks wrote:
>> Hi all,
>>
>> Please review this quick cleanup to this test I moved into the open yesterday. It changes the JVM's locale, and out of an abundance of caution it's safer to run things that change JVM global state in /othervm mode.
>>
>> Bug:
>>     https://bugs.openjdk.java.net/browse/JDK-8132745
>>
>> Patch appended below.
>>
>> Thanks,
>>
>> s'marks
>>
>>
>>
>> # HG changeset patch
>> # User smarks
>> # Date 1438295744 25200
>> #      Thu Jul 30 15:35:44 2015 -0700
>> # Node ID 4ce7979b7610574075bd4ade3b73004cde5e9ac3
>> # Parent  d23203801b5369603d2dda21a6aff6225195001d
>> 8132745: minor cleanup of java/util/Scanner/ScanTest.java
>> Reviewed-by: XXX
>>
>> diff -r d23203801b53 -r 4ce7979b7610 test/java/util/Scanner/ScanTest.java
>> --- a/test/java/util/Scanner/ScanTest.java    Thu Jul 30 14:16:58 2015 -0400
>> +++ b/test/java/util/Scanner/ScanTest.java    Thu Jul 30 15:35:44 2015 -0700
>> @@ -26,6 +26,7 @@
>>   * @bug 4313885 4926319 4927634 5032610 5032622 5049968 5059533 6223711 6277261 6269946 6288823
>>   * @summary Basic tests of java.util.Scanner methods
>>   * @key randomness
>> + * @run main/othervm ScanTest
>>   */
>>
>>  import java.util.*;
>



From kim.barrett at oracle.com  Thu Jul 30 22:56:25 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 30 Jul 2015 18:56:25 -0400
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55BA9830.8030308@oracle.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com> <55B9EA8A.1080102@oracle.com>
	<55B9FA54.5040902@gmail.com> <55B9FB50.8050907@oracle.com>
	<55B9FF5F.2020706@gmail.com> <55BA0E2B.9050101@oracle.com>
	<55BA110F.2010101@gmail.com> <55BA13E8.1050606@oracle.com>
	
	<55BA9830.8030308@oracle.com>
Message-ID: 

On Jul 30, 2015, at 5:33 PM, David Holmes  wrote:
> 
>> So I think I can either:
>> 
>> 1. Go ahead with my change + Peter's change.
>> 
>> 2. Give this back to core-libs while I step carefully away :-)
>> 
>> I *think* option (1) is at least an improvement.  But I completely
>> missed Peter's race, despite having specifically looked for problems
>> there, so take my opinion with an appropriate quantity of salt.
> 
> I vote for 1 as well. I think we have now given good coverage to the two sources of problems (the two lock-free regions):
> - reference queue state can be seen while queue state is in transition
> - queue empty state can be seen while reference state is in transition

New webrev, with both changes:

http://cr.openjdk.java.net/~kbarrett/8132306/webrev.01/



From stuart.marks at oracle.com  Thu Jul 30 23:32:01 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 30 Jul 2015 16:32:01 -0700
Subject: RFR 8130828: Fix some typos and omissions in the the j.u.stream
	JavaDoc
In-Reply-To: <541E9EF8-FB31-4261-B23C-69CEED58DE54@oracle.com>
References: <496DA2CB-EDFD-4E65-8EEE-89830C87FD70@oracle.com>
	
	<541E9EF8-FB31-4261-B23C-69CEED58DE54@oracle.com>
Message-ID: <55BAB3F1.5070506@oracle.com>

Hi Paul,

Changes look good. (The webrev changesets are a bit odd, though; are you running 
webrev on a branchy repo or something?)

Stefan, Tagir, thanks for spotting these issues.

s'marks

On 7/30/15 9:32 AM, Paul Sandoz wrote:
> Hi Stefan, Tagir,
>
> Updated:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130828-stream-doc-typos/webrev/
>
> Paul.
>
> On 30 Jul 2015, at 18:08, Stefan Zobel  wrote:
>
>> Hi Paul,
>>
>> perhaps you could take the opportunity and also add the missing "@since
>> 1.9" tags to all the new dropWhile() / takeWhile() methods (JDK-8071597).
>>
>> Also in dropWhile() / takeWhile() there is a small typo (I guess) in the
>> Javadoc:
>>
>>
>> takeWhile: "takes all elements (the result is the same is the input)"
>>
>> dropWhile: "the stream match the given predicate then no elements are
>> dropped (the result is the same is the input)"
>>
>>
>> I guess that should read: "(the result is the same as is the input)"?
>>
>>
>> Stefan
>


From ecki at zusammenkunft.net  Thu Jul 30 23:55:13 2015
From: ecki at zusammenkunft.net (Bernd)
Date: Thu, 30 Jul 2015 23:55:13 +0000
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version' on
	Linux under zh_CN.GB18030 locale
In-Reply-To: <55BAA42C.6000406@oracle.com>
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
	
	<55B7EC8B.8000508@oracle.com>
	
	<55B99FEC.8080602@oracle.com> <55B9ADC9.7020407@oracle.com>
	<55B9B46C.9000003@oracle.com> <55B9D777.5020504@oracle.com>
	
	<55BA45A8.6050600@oracle.com> <55BA9EAC.5000907@oracle.com>
	<55BAA42C.6000406@oracle.com>
Message-ID: 

Hello,

I doubt you can compile a list of all charsets supported by the various
(national) linux distributions and versions (and installed runtime
packages). Especially not for OpenJDK which can be much less restrictive in
picking supported (non enterprise) distributions.

And I also wonder why it is needed, if a locale is not known just fall back
to a sane default. The OpenJDK should define a reasonable list (especially
for compact profiles) and not declare to support all platforms fully.

Gruss
Bernd

Xueming Shen  schrieb am Fr., 31. Juli 2015 00:35:

> On 07/30/2015 03:01 PM, David Holmes wrote:
> > On 31/07/2015 1:41 AM, Xueming Shen wrote:
> >> On 07/30/2015 01:37 AM, Volker Simonis wrote:
> >>> On Thu, Jul 30, 2015 at 9:51 AM, Alan
> >>> Bateman  wrote:
> >>>>
> >>>> On 30/07/2015 06:21, Xueming Shen wrote:
> >>>>> :
> >>>>>
> >>>>> Each platform has a list of "supported locale/encoding". All these
> >>>>> encodings/charsets need to be in
> >>>>> base module for that particular platform, to support the jvm to
> >>>>> start (in
> >>>>> a particular locale/encoding)
> >>>>> under module system. The charsets in our repository can be
> categorized
> >>>>> into different groups, solaris/
> >>>>> linux specific, windows specific and IBM specific and couple that are
> >>>>> shared by different platforms).
> >>>>> The idea here is to build all those platform-specific charsets into
> the
> >>>>> base module for that platform.
> >>>> Right, and furthermore, we should be able to build a compact1 image
> >>>> or just
> >>>> an image with the java.base module and it should be able to start on
> >>>> platforms when running with a supported locale/encoding. I think the
> >>>> main
> >>>> issue we've had is establishing that list, hence it had to be
> >>>> extended a few
> >>>> times.
> >>>>
> >>> The change looks fine.
> >>>
> >>> But what about the 'supported locale/encoding' list. Is there a
> >>> published 'official' version of this list for Oracle/OpenJDK and how
> >>> is it maintained.
> >>
> >> I meant to say "all the supported/native locale+encoding" of the
> >> platform/OS. If we have those
> >> charsets in our repository, they all need go into the base module.
> >
> > Now I'm confused again. Do the platforms we officially support have set
> lists of such locales/encodings? If so getting our list correct seems
> trivial. If not, then how can we support an unknown target??
> >
>
> it's a "known" target. we know the list of the locale/encoding solais
> /linux supports and the list
> of charsets Java supports.
>
> -sherman
>
>


From stuart.marks at oracle.com  Fri Jul 31 00:51:05 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 30 Jul 2015 17:51:05 -0700
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: 
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
Message-ID: <55BAC679.7010108@oracle.com>



On 7/29/15 11:36 AM, Volker Simonis wrote:
>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>> truncated or incomplete
>> values for the executable or arguments.
>> Can anyone be a tie-breaker  (with a good rational and suggestion for how an
>> application can use the data).
>
> As I wrote, I agree to hear other opinions here.
>
> All I want to say that this truncated data is actually what 'ps' is
> reporting on Solaris since decades and people seem to be happy with
> it. As use case I can imagine logging or monitoring (something like
> 'top' in Java) where this data will be just good enough.
>
> We could specially mark possibly incomplete data by extending the Info
> object with functions like commandIsExact() or argumentsIsPrecise().
> But notice that we can not statically preset these values per
> platform. For example on Solaris, the 'command()' would return a
> precise value for processes with the same uid like the VM but only
> inaccurate values for all other processes. The "arguments()" would be
> always inaccurate on Solaris/AIX.

It seems like there are cases where either exact or only approximate information 
is available. And as you observed, you might get one or the other on the same 
platform, depending on the UID. It also might depend on process state; I believe 
that some information becomes inaccessible when the process enters the zombie state.

I don't think we should simply ignore one case or the other, but I also don't 
think we should try to cram the different information into the same API.

The current ProcessHandle.Info api has

     Optional command()
     Optional arguments()

It sounds to me like Roger wants these to contain only exact information. That 
seems reasonable, and this probably needs to be specified more clearly to 
contrast with what's below.

On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a single 
string which appears to be the concatenation of the arguments (maybe including 
the command name). It's also truncated to fit PRARGSZ. It doesn't make sense to 
me to try to return this as a String[], as the zeroth element of that array, and 
certainly not parsed out into "words". So maybe instead we should have a 
different API that returns an imprecise command line as a single string:

     Optional cmdline()

(Naming bikeshed TBS). The semantics would be that this is the process' command 
and arguments concatenated into a single string (thus potentially losing 
argument boundaries) and also possibly truncated based on platform 
(COUGHsolarisCOUGH) limitations. It's certainly useful for printing out in a ps, 
top, or Activity Monitor style application, for informational purposes.

If this were implemented, then on Solaris, command() and arguments() would 
always return empty optionals.

I'm not sure what this should be if the exact information is available. It would 
be inconvenient if something that just wanted to print out an approximate 
command line had to check several different APIs to get the information. Maybe 
cmdline() could assemble the information from exact data if it's is available, 
by concatenating the Strings from command() and arguments(), as a convenience to 
the caller. But I could go either way on this.

Not sure this counts as a tie-breaker, but it might be a reasonable way forward.

s'marks





  might be convenient if this


From david.holmes at oracle.com  Fri Jul 31 02:22:54 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 31 Jul 2015 12:22:54 +1000
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: 
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com>
	<55B9EA8A.1080102@oracle.com> <55B9FA54.5040902@gmail.com>
	<55B9FB50.8050907@oracle.com> <55B9FF5F.2020706@gmail.com>
	<55BA0E2B.9050101@oracle.com> <55BA110F.2010101@gmail.com>
	<55BA13E8.1050606@oracle.com>
	
	<55BA9830.8030308@oracle.com>
	
Message-ID: <55BADBFE.2000808@oracle.com>

Looks good!

Thanks,
David

On 31/07/2015 8:56 AM, Kim Barrett wrote:
> On Jul 30, 2015, at 5:33 PM, David Holmes  wrote:
>>
>>> So I think I can either:
>>>
>>> 1. Go ahead with my change + Peter's change.
>>>
>>> 2. Give this back to core-libs while I step carefully away :-)
>>>
>>> I *think* option (1) is at least an improvement.  But I completely
>>> missed Peter's race, despite having specifically looked for problems
>>> there, so take my opinion with an appropriate quantity of salt.
>>
>> I vote for 1 as well. I think we have now given good coverage to the two sources of problems (the two lock-free regions):
>> - reference queue state can be seen while queue state is in transition
>> - queue empty state can be seen while reference state is in transition
>
> New webrev, with both changes:
>
> http://cr.openjdk.java.net/~kbarrett/8132306/webrev.01/
>


From stuart.marks at oracle.com  Fri Jul 31 02:37:51 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 30 Jul 2015 19:37:51 -0700
Subject: RFR JDK-8080252: java.util.Formatter documentation of %n
	converter is misleading
In-Reply-To: <55BA6022.9070106@oracle.com>
References: <55BA6022.9070106@oracle.com>
Message-ID: <55BADF7F.6060208@oracle.com>

Hi Sherman,

The change looks fine to me.

s'marks

On 7/30/15 10:34 AM, Xueming Shen wrote:
> Hi,
>
> Please help review the change for
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8080252
> webrev: http://cr.openjdk.java.net/~sherman/8080252/
>
> It appears we updated the j.u.Formatter implementation to use the newly introduced
> method System.lineSeparator() in jdk7, but did not update the doc accordingly.
>
> For the old the behavior, I would assume the initial intent is to treat the
> system property
> line.separator as a read-only/informative property.
>
> Given the fact the it has been 2 major releases (7, 8), I would assume this
> change is now
> a kind of change to "update the javadoc to describe the existing implementation
> correctly".
> So a CCC is not needed.
>
> Thanks,
> Sherman
>
>


From stuart.marks at oracle.com  Fri Jul 31 02:47:00 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 30 Jul 2015 19:47:00 -0700
Subject: RFR: JDK-8114832 it.next on ArrayList throws wrong type of
	Exception after remove(-1)
In-Reply-To: 
References: <788B7264-C303-4784-9D8A-7D7EFFAC5D43@oracle.com>
	
	
	
	
Message-ID: <55BAE1A4.7010308@oracle.com>

On 7/28/15 5:50 AM, Paul Sandoz wrote:
>> I agree that if we make a policy decision here, we can change it and the compatibility impact is minimal.
>
> Since there already exists an implicit policy governed by like 99.9% of the existing behaviour i do not see the need to be explicit about that policy for this particular issue, so i suggest we split into two.

I followed this thread up until the last sentence. What's the resolution here?

s'marks


From xueming.shen at oracle.com  Fri Jul 31 02:53:01 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 30 Jul 2015 19:53:01 -0700
Subject: RFR: 8132459: ExceptionInInitializerError from 'java -version' on
	Linux under zh_CN.GB18030 locale
In-Reply-To: 
References: <----3M------n0YZM$95b453aa-acba-43c2-aa51-369dd44e4c5f@alibaba-inc.com>
	<55B78828.6000600@oracle.com>
	
	<55B7EC8B.8000508@oracle.com>
	
	<55B99FEC.8080602@oracle.com> <55B9ADC9.7020407@oracle.com>
	<55B9B46C.9000003@oracle.com> <55B9D777.5020504@oracle.com>
	
	<55BA45A8.6050600@oracle.com> <55BA9EAC.5000907@oracle.com>
	<55BAA42C.6000406@oracle.com>
	
Message-ID: <55BAE30D.2060302@oracle.com>

On 7/30/15 4:55 PM, Bernd wrote:
>
> Hello,
>
> I doubt you can compile a list of all charsets supported by the 
> various (national) linux distributions and versions (and installed 
> runtime packages). Especially not for OpenJDK which can be much less 
> restrictive in picking supported (non enterprise) distributions.
>
> And I also wonder why it is needed, if a locale is not known just fall 
> back to a sane default. The OpenJDK should define a reasonable list 
> (especially for compact profiles) and not declare to support all 
> platforms fully.
>

Bernd, it's the other way around. Instead of addding all charsets 
supported by the various linux
distributions/versions into the base module, we are selecting/building 
all charsets from our
existing repository (originally in jdk's standard charsets and extended 
charsets) that might be
used for a particular platform (linux, solaris, macos, windows) into the 
base module for that
platform.

The configuration is pretty straightforward, you can easily define a 
reasonable list of charsets
and build the OpenJDK for your specified platform/profile.

As discussed in other email, we are working on the best approach for the 
use  scenario that a
charset is "unsupported" from our repository.

-sherman

>
> Xueming Shen  > schrieb am Fr., 31. Juli 2015 00:35:
>
>     On 07/30/2015 03:01 PM, David Holmes wrote:
>     > On 31/07/2015 1:41 AM, Xueming Shen wrote:
>     >> On 07/30/2015 01:37 AM, Volker Simonis wrote:
>     >>> On Thu, Jul 30, 2015 at 9:51 AM, Alan
>     >>> Bateman     > wrote:
>     >>>>
>     >>>> On 30/07/2015 06:21, Xueming Shen wrote:
>     >>>>> :
>     >>>>>
>     >>>>> Each platform has a list of "supported locale/encoding". All
>     these
>     >>>>> encodings/charsets need to be in
>     >>>>> base module for that particular platform, to support the jvm to
>     >>>>> start (in
>     >>>>> a particular locale/encoding)
>     >>>>> under module system. The charsets in our repository can be
>     categorized
>     >>>>> into different groups, solaris/
>     >>>>> linux specific, windows specific and IBM specific and couple
>     that are
>     >>>>> shared by different platforms).
>     >>>>> The idea here is to build all those platform-specific
>     charsets into the
>     >>>>> base module for that platform.
>     >>>> Right, and furthermore, we should be able to build a compact1
>     image
>     >>>> or just
>     >>>> an image with the java.base module and it should be able to
>     start on
>     >>>> platforms when running with a supported locale/encoding. I
>     think the
>     >>>> main
>     >>>> issue we've had is establishing that list, hence it had to be
>     >>>> extended a few
>     >>>> times.
>     >>>>
>     >>> The change looks fine.
>     >>>
>     >>> But what about the 'supported locale/encoding' list. Is there a
>     >>> published 'official' version of this list for Oracle/OpenJDK
>     and how
>     >>> is it maintained.
>     >>
>     >> I meant to say "all the supported/native locale+encoding" of the
>     >> platform/OS. If we have those
>     >> charsets in our repository, they all need go into the base module.
>     >
>     > Now I'm confused again. Do the platforms we officially support
>     have set lists of such locales/encodings? If so getting our list
>     correct seems trivial. If not, then how can we support an unknown
>     target??
>     >
>
>     it's a "known" target. we know the list of the locale/encoding
>     solais /linux supports and the list
>     of charsets Java supports.
>
>     -sherman
>



From paul.sandoz at oracle.com  Fri Jul 31 07:47:07 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 31 Jul 2015 09:47:07 +0200
Subject: RFR: JDK-8114832 it.next on ArrayList throws wrong type of
	Exception after remove(-1)
In-Reply-To: <55BAE1A4.7010308@oracle.com>
References: <788B7264-C303-4784-9D8A-7D7EFFAC5D43@oracle.com>
	
	
	
	
	<55BAE1A4.7010308@oracle.com>
Message-ID: 


On 31 Jul 2015, at 04:47, Stuart Marks  wrote:

> On 7/28/15 5:50 AM, Paul Sandoz wrote:
>>> I agree that if we make a policy decision here, we can change it and the compatibility impact is minimal.
>> 
>> Since there already exists an implicit policy governed by like 99.9% of the existing behaviour i do not see the need to be explicit about that policy for this particular issue, so i suggest we split into two.
> 
> I followed this thread up until the last sentence. What's the resolution here?
> 

I think we should go ahead with the fix (and file a CCC just for formality), the file another issue for clarifying the current implicit behaviour.

Paul.


From paul.sandoz at oracle.com  Fri Jul 31 07:49:03 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 31 Jul 2015 09:49:03 +0200
Subject: RFR 8130828: Fix some typos and omissions in the the j.u.stream
	JavaDoc
In-Reply-To: <55BAB3F1.5070506@oracle.com>
References: <496DA2CB-EDFD-4E65-8EEE-89830C87FD70@oracle.com>
	
	<541E9EF8-FB31-4261-B23C-69CEED58DE54@oracle.com>
	<55BAB3F1.5070506@oracle.com>
Message-ID: <7D59AD92-78EE-4C6B-808A-9B085E903F4E@oracle.com>


On 31 Jul 2015, at 01:32, Stuart Marks  wrote:

> Hi Paul,
> 
> Changes look good.

Thanks.


> (The webrev changesets are a bit odd, though; are you running webrev on a branchy repo or something?)
> 

No, nothing special, but something has changed that is making the webrev script behave differently.

Paul.

> Stefan, Tagir, thanks for spotting these issues.
> 
> s'marks
> 
> On 7/30/15 9:32 AM, Paul Sandoz wrote:
>> Hi Stefan, Tagir,
>> 
>> Updated:
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130828-stream-doc-typos/webrev/
>> 
>> Paul.
>> 
>> On 30 Jul 2015, at 18:08, Stefan Zobel  wrote:
>> 
>>> Hi Paul,
>>> 
>>> perhaps you could take the opportunity and also add the missing "@since
>>> 1.9" tags to all the new dropWhile() / takeWhile() methods (JDK-8071597).
>>> 
>>> Also in dropWhile() / takeWhile() there is a small typo (I guess) in the
>>> Javadoc:
>>> 
>>> 
>>> takeWhile: "takes all elements (the result is the same is the input)"
>>> 
>>> dropWhile: "the stream match the given predicate then no elements are
>>> dropped (the result is the same is the input)"
>>> 
>>> 
>>> I guess that should read: "(the result is the same as is the input)"?
>>> 
>>> 
>>> Stefan
>> 



From volker.simonis at gmail.com  Fri Jul 31 09:03:15 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 31 Jul 2015 11:03:15 +0200
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: <55BAC679.7010108@oracle.com>
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
	<55BAC679.7010108@oracle.com>
Message-ID: 

On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks  wrote:
>
>
> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>>
>>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>>> truncated or incomplete
>>> values for the executable or arguments.
>>> Can anyone be a tie-breaker  (with a good rational and suggestion for how
>>> an
>>> application can use the data).
>>
>>
>> As I wrote, I agree to hear other opinions here.
>>
>> All I want to say that this truncated data is actually what 'ps' is
>> reporting on Solaris since decades and people seem to be happy with
>> it. As use case I can imagine logging or monitoring (something like
>> 'top' in Java) where this data will be just good enough.
>>
>> We could specially mark possibly incomplete data by extending the Info
>> object with functions like commandIsExact() or argumentsIsPrecise().
>> But notice that we can not statically preset these values per
>> platform. For example on Solaris, the 'command()' would return a
>> precise value for processes with the same uid like the VM but only
>> inaccurate values for all other processes. The "arguments()" would be
>> always inaccurate on Solaris/AIX.
>
>
> It seems like there are cases where either exact or only approximate
> information is available. And as you observed, you might get one or the
> other on the same platform, depending on the UID. It also might depend on
> process state; I believe that some information becomes inaccessible when the
> process enters the zombie state.
>
> I don't think we should simply ignore one case or the other, but I also
> don't think we should try to cram the different information into the same
> API.
>
> The current ProcessHandle.Info api has
>
>     Optional command()
>     Optional arguments()
>
> It sounds to me like Roger wants these to contain only exact information.
> That seems reasonable, and this probably needs to be specified more clearly
> to contrast with what's below.
>
> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
> single string which appears to be the concatenation of the arguments (maybe
> including the command name). It's also truncated to fit PRARGSZ. It doesn't
> make sense to me to try to return this as a String[], as the zeroth element
> of that array, and certainly not parsed out into "words". So maybe instead
> we should have a different API that returns an imprecise command line as a
> single string:
>
>     Optional cmdline()
>
> (Naming bikeshed TBS). The semantics would be that this is the process'
> command and arguments concatenated into a single string (thus potentially
> losing argument boundaries) and also possibly truncated based on platform
> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out in a
> ps, top, or Activity Monitor style application, for informational purposes.
>
> If this were implemented, then on Solaris, command() and arguments() would
> always return empty optionals.
>
> I'm not sure what this should be if the exact information is available. It
> would be inconvenient if something that just wanted to print out an
> approximate command line had to check several different APIs to get the
> information. Maybe cmdline() could assemble the information from exact data
> if it's is available, by concatenating the Strings from command() and
> arguments(), as a convenience to the caller. But I could go either way on
> this.
>
> Not sure this counts as a tie-breaker, but it might be a reasonable way
> forward.
>
> s'marks
>

Hi Stuart,

thanks a lot for your comments - I like your proposal. For me this
sounds like a good compromise.

@Roger: should I go and add a new field commandLine and the
corresponding getter to the Info class? As Stuart proposed, the getter
could check if 'command' and 'arguments' are available and assemble
the command line from them. Otherwise it could use the content of the
commandLine field if that is available.

Regards,
Volker


From daniel.fuchs at oracle.com  Fri Jul 31 09:10:32 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 31 Jul 2015 11:10:32 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: 
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com> <55B9EA8A.1080102@oracle.com>
	<55B9FA54.5040902@gmail.com> <55B9FB50.8050907@oracle.com>
	<55B9FF5F.2020706@gmail.com> <55BA0E2B.9050101@oracle.com>
	<55BA110F.2010101@gmail.com> <55BA13E8.1050606@oracle.com>
	
	<55BA9830.8030308@oracle.com>
	
Message-ID: <55BB3B88.8070902@oracle.com>

On 31/07/15 00:56, Kim Barrett wrote:
> On Jul 30, 2015, at 5:33 PM, David Holmes  wrote:
>>
>>> So I think I can either:
>>>
>>> 1. Go ahead with my change + Peter's change.
>>>
>>> 2. Give this back to core-libs while I step carefully away :-)
>>>
>>> I *think* option (1) is at least an improvement.  But I completely
>>> missed Peter's race, despite having specifically looked for problems
>>> there, so take my opinion with an appropriate quantity of salt.
>>
>> I vote for 1 as well. I think we have now given good coverage to the two sources of problems (the two lock-free regions):
>> - reference queue state can be seen while queue state is in transition
>> - queue empty state can be seen while reference state is in transition
>
> New webrev, with both changes:
>
> http://cr.openjdk.java.net/~kbarrett/8132306/webrev.01/
>

+ 1

Thanks for taking care of this one!

PS: you might want to add @bug 8132306 to
     jdk/test/java/lang/ref/ReferenceEnqueue.java

best regards,

-- daniel


From volker.simonis at gmail.com  Fri Jul 31 10:12:07 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 31 Jul 2015 12:12:07 +0200
Subject: RFR(S): 8132704: [TESTBUG] jdk/internal/jimage/ExecutableTest.java
	incorrectly asserts all files to be executable
In-Reply-To: 
References: 
	<55BA43EE.7070508@Oracle.com>
	
	<55BA46FC.9070205@Oracle.com>
	
Message-ID: 

On Thu, Jul 30, 2015 at 5:49 PM, Volker Simonis
 wrote:
> On Thu, Jul 30, 2015 at 5:47 PM, Roger Riggs  wrote:
>> Hi Volker,
>>
>> There is already as task for JMC to move that file but who knows exactly
>> when.
>>
>> A list of exception(s) would be better I think, because generally,
>> everything in bin should be executable.
>> WDYT?
>>
>
> OK, I'm fine with that.
> Unfortunately I'll have to hurry home now.
> I'll do the change tomorrow (or you can take over if it's urgent).
>

So here comes the new version:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704.v2

I've added 'jmc.ini' to the exclude list for now.
Could you please check if there are other files I should add to the
list before pushing?

Do you have a bug ID for the task to move 'jmc.ini' out of the bin
direcotry. I think it should be updated with a link to this bug and
with the info to remove 'jmc.ini' from the exclude list once the file
has been moved away from bin.

Regards,
Volker

> Regards,
> Volker
>
>> Roger
>>
>>
>>
>> On 7/30/2015 11:40 AM, Volker Simonis wrote:
>>
>> On Thu, Jul 30, 2015 at 5:34 PM, Roger Riggs  wrote:
>>
>> Hi Volker,
>>
>> Possibly the real bug is that there is non-executable file in the bin
>> directory.
>> There is a /conf directory which would probably be a better place for that.
>>
>> Yes, I agree. But I thought you want a fast fix for the test failure :)
>> Moving that config file is probably a bigger effort.
>>
>> Moreover the bin/ directory on Windows also contains .dll and .diz
>> files. However on Windows, all the files seem to be executable (at
>> least the test did succeed before). Nevertheless, checking only a
>> known subset of executables seems safer and "good enough".
>>
>> What do you think?
>> Volker
>>
>> Roger
>>
>>
>>
>>
>>
>>
>> On 7/30/2015 11:28 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> can somebody please review this test fix:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704/
>> https://bugs.openjdk.java.net/browse/JDK-8132704
>>
>> The initial test checked that all the files in the bin/ directory are
>> executable by everybody. Unfortunately this was too optimistic because
>> in the closed build the bin/ directory contains configuration files
>> which are not executable.
>>
>> The new version of the test uses a predefined static list of
>> executables which are checked for the executable permissions if the
>> corresponding files exist.
>>
>> Thank you and best regards,
>> Volker
>>
>>


From Alan.Bateman at oracle.com  Fri Jul 31 10:30:09 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 31 Jul 2015 11:30:09 +0100
Subject: RFR(S): 8132704: [TESTBUG] jdk/internal/jimage/ExecutableTest.java
	incorrectly asserts all files to be executable
In-Reply-To: 
References: 	<55BA43EE.7070508@Oracle.com>		<55BA46FC.9070205@Oracle.com>	
	
Message-ID: <55BB4E31.6060403@oracle.com>

On 31/07/2015 11:12, Volker Simonis wrote:
> :
>
> So here comes the new version:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704.v2
>
> I've added 'jmc.ini' to the exclude list for now.
> Could you please check if there are other files I should add to the
> list before pushing?
>
> Do you have a bug ID for the task to move 'jmc.ini' out of the bin
> direcotry. I think it should be updated with a link to this bug and
> with the info to remove 'jmc.ini' from the exclude list once the file
> has been moved away from bin.
>
There is a linked issue but it's to a proprietary product that you won't 
see in JIRA so I think you won't see the link. Products that get overlay 
over the modular image need to respect the layout but I don't know the 
ETA on when this will be moved to the conf directory.

Your patch looks okay but a bit embarrassing that you've had to do this.

-Alan.


From chris.hegarty at oracle.com  Fri Jul 31 10:32:20 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 31 Jul 2015 11:32:20 +0100
Subject: RFR(S): 8132704: [TESTBUG]
	jdk/internal/jimage/ExecutableTest.java incorrectly asserts all
	files to be executable
In-Reply-To: 
References: 
	<55BA43EE.7070508@Oracle.com>
	
	<55BA46FC.9070205@Oracle.com>
	
	
Message-ID: 


> On 31 Jul 2015, at 11:12, Volker Simonis  wrote:
> 
> On Thu, Jul 30, 2015 at 5:49 PM, Volker Simonis
> > wrote:
>> On Thu, Jul 30, 2015 at 5:47 PM, Roger Riggs  wrote:
>>> Hi Volker,
>>> 
>>> There is already as task for JMC to move that file but who knows exactly
>>> when.
>>> 
>>> A list of exception(s) would be better I think, because generally,
>>> everything in bin should be executable.
>>> WDYT?
>>> 
>> 
>> OK, I'm fine with that.
>> Unfortunately I'll have to hurry home now.
>> I'll do the change tomorrow (or you can take over if it's urgent).
>> 
> 
> So here comes the new version:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704.v2 

This change looks good to me Volker.

> I've added 'jmc.ini' to the exclude list for now.
> Could you please check if there are other files I should add to the
> list before pushing?

I believe that jmc.ini is the only one.

> Do you have a bug ID for the task to move 'jmc.ini' out of the bin
> direcotry. I think it should be updated with a link to this bug and
> with the info to remove 'jmc.ini' from the exclude list once the file
> has been moved away from bin.

-Chris.

> Regards,
> Volker
> 
>> Regards,
>> Volker
>> 
>>> Roger
>>> 
>>> 
>>> 
>>> On 7/30/2015 11:40 AM, Volker Simonis wrote:
>>> 
>>> On Thu, Jul 30, 2015 at 5:34 PM, Roger Riggs  wrote:
>>> 
>>> Hi Volker,
>>> 
>>> Possibly the real bug is that there is non-executable file in the bin
>>> directory.
>>> There is a /conf directory which would probably be a better place for that.
>>> 
>>> Yes, I agree. But I thought you want a fast fix for the test failure :)
>>> Moving that config file is probably a bigger effort.
>>> 
>>> Moreover the bin/ directory on Windows also contains .dll and .diz
>>> files. However on Windows, all the files seem to be executable (at
>>> least the test did succeed before). Nevertheless, checking only a
>>> known subset of executables seems safer and "good enough".
>>> 
>>> What do you think?
>>> Volker
>>> 
>>> Roger
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 7/30/2015 11:28 AM, Volker Simonis wrote:
>>> 
>>> Hi,
>>> 
>>> can somebody please review this test fix:
>>> 
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704/
>>> https://bugs.openjdk.java.net/browse/JDK-8132704
>>> 
>>> The initial test checked that all the files in the bin/ directory are
>>> executable by everybody. Unfortunately this was too optimistic because
>>> in the closed build the bin/ directory contains configuration files
>>> which are not executable.
>>> 
>>> The new version of the test uses a predefined static list of
>>> executables which are checked for the executable permissions if the
>>> corresponding files exist.
>>> 
>>> Thank you and best regards,
>>> Volker



From daniel.fuchs at oracle.com  Fri Jul 31 10:48:16 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 31 Jul 2015 12:48:16 +0200
Subject: RfR - 8132550: java/util/logging/LoggingDeadlock2.java times out
Message-ID: <55BB5270.4010106@oracle.com>

Hi,

Please find below a fix for:

https://bugs.openjdk.java.net/browse/JDK-8132550
8132550: java/util/logging/LoggingDeadlock2.java times out

I was able to reproduce the deadlock consistently by inserting
some Thread.sleep() statements at the critical places.
The webrev still shows that (as commented code) - but I will remove
those comments before pushing:

http://cr.openjdk.java.net/~dfuchs/webrev_8132550/webrev.00/

This issue here is that LogManager should also use the
configurationLock when reading its primordial configuration
(and not a simple synchronized(this)).

That should remove all uses of synchronized((LogManager)this) from 
LogManager, and ensure that reset(), readConfiguration(), and 
ensureLogManagerInitialized() all use the same lock.

When we moved to using a ReantrantLock object for configuration I had
already considered doing this - but at the time I deemed it unnecessary,
thinking you couldn't obtain a reference on LogManager through
getLogManager() before it had initialized. But this was counting
without System.exit() being called and starting the Cleaner thread 
before the first call to LogManager.getLogManager() had finished.
This introduced a small time window in which the deadlock became
possible - at exit time, if something happened to initialize the
LogManager right at that time.

best regards

-- daniel


From volker.simonis at gmail.com  Fri Jul 31 13:14:50 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 31 Jul 2015 15:14:50 +0200
Subject: RFR(S): 8132704: [TESTBUG] jdk/internal/jimage/ExecutableTest.java
	incorrectly asserts all files to be executable
In-Reply-To: <55BB4E31.6060403@oracle.com>
References: 
	<55BA43EE.7070508@Oracle.com>
	
	<55BA46FC.9070205@Oracle.com>
	
	
	<55BB4E31.6060403@oracle.com>
Message-ID: 

On Fri, Jul 31, 2015 at 12:30 PM, Alan Bateman 
wrote:

> On 31/07/2015 11:12, Volker Simonis wrote:
>
>> :
>>
>> So here comes the new version:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704.v2
>>
>> I've added 'jmc.ini' to the exclude list for now.
>> Could you please check if there are other files I should add to the
>> list before pushing?
>>
>> Do you have a bug ID for the task to move 'jmc.ini' out of the bin
>> direcotry. I think it should be updated with a link to this bug and
>> with the info to remove 'jmc.ini' from the exclude list once the file
>> has been moved away from bin.
>>
>> There is a linked issue but it's to a proprietary product that you won't
> see in JIRA so I think you won't see the link. Products that get overlay
> over the modular image need to respect the layout but I don't know the ETA
> on when this will be moved to the conf directory.
>
> Your patch looks okay but a bit embarrassing that you've had to do this.
>
>
That's no problem - you're welcome.
Sometimes you're helping out with AIX as well :)

Regards,
Volker

-Alan.
>


From volker.simonis at gmail.com  Fri Jul 31 13:15:37 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 31 Jul 2015 15:15:37 +0200
Subject: RFR(S): 8132704: [TESTBUG] jdk/internal/jimage/ExecutableTest.java
	incorrectly asserts all files to be executable
In-Reply-To: 
References: 
	<55BA43EE.7070508@Oracle.com>
	
	<55BA46FC.9070205@Oracle.com>
	
	
	
Message-ID: 

On Fri, Jul 31, 2015 at 12:32 PM, Chris Hegarty 
wrote:

>
> On 31 Jul 2015, at 11:12, Volker Simonis  wrote:
>
> On Thu, Jul 30, 2015 at 5:49 PM, Volker Simonis
>  wrote:
>
> On Thu, Jul 30, 2015 at 5:47 PM, Roger Riggs 
> wrote:
>
> Hi Volker,
>
> There is already as task for JMC to move that file but who knows exactly
> when.
>
> A list of exception(s) would be better I think, because generally,
> everything in bin should be executable.
> WDYT?
>
>
> OK, I'm fine with that.
> Unfortunately I'll have to hurry home now.
> I'll do the change tomorrow (or you can take over if it's urgent).
>
>
> So here comes the new version:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704.v2
>
>
> This change looks good to me Volker.
>
> Thanks. I'll push it now.

Regards,
Volker


> I've added 'jmc.ini' to the exclude list for now.
> Could you please check if there are other files I should add to the
> list before pushing?
>
>
> I believe that jmc.ini is the only one.
>
> Do you have a bug ID for the task to move 'jmc.ini' out of the bin
> direcotry. I think it should be updated with a link to this bug and
> with the info to remove 'jmc.ini' from the exclude list once the file
> has been moved away from bin.
>
>
> -Chris.
>
> Regards,
> Volker
>
> Regards,
> Volker
>
> Roger
>
>
>
> On 7/30/2015 11:40 AM, Volker Simonis wrote:
>
> On Thu, Jul 30, 2015 at 5:34 PM, Roger Riggs 
> wrote:
>
> Hi Volker,
>
> Possibly the real bug is that there is non-executable file in the bin
> directory.
> There is a /conf directory which would probably be a better place for that.
>
> Yes, I agree. But I thought you want a fast fix for the test failure :)
> Moving that config file is probably a bigger effort.
>
> Moreover the bin/ directory on Windows also contains .dll and .diz
> files. However on Windows, all the files seem to be executable (at
> least the test did succeed before). Nevertheless, checking only a
> known subset of executables seems safer and "good enough".
>
> What do you think?
> Volker
>
> Roger
>
>
>
>
>
>
> On 7/30/2015 11:28 AM, Volker Simonis wrote:
>
> Hi,
>
> can somebody please review this test fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704/
> https://bugs.openjdk.java.net/browse/JDK-8132704
>
> The initial test checked that all the files in the bin/ directory are
> executable by everybody. Unfortunately this was too optimistic because
> in the closed build the bin/ directory contains configuration files
> which are not executable.
>
> The new version of the test uses a predefined static list of
> executables which are checked for the executable permissions if the
> corresponding files exist.
>
> Thank you and best regards,
> Volker
>
>
>


From peter.levart at gmail.com  Fri Jul 31 13:23:58 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 31 Jul 2015 15:23:58 +0200
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: 
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com>
	<55B9EA8A.1080102@oracle.com> <55B9FA54.5040902@gmail.com>
	<55B9FB50.8050907@oracle.com> <55B9FF5F.2020706@gmail.com>
	<55BA0E2B.9050101@oracle.com> <55BA110F.2010101@gmail.com>
	<55BA13E8.1050606@oracle.com>
	
	<55BA9830.8030308@oracle.com>
	
Message-ID: <55BB76EE.2070306@gmail.com>



On 07/31/2015 12:56 AM, Kim Barrett wrote:
> On Jul 30, 2015, at 5:33 PM, David Holmes  wrote:
>>> So I think I can either:
>>>
>>> 1. Go ahead with my change + Peter's change.
>>>
>>> 2. Give this back to core-libs while I step carefully away :-)
>>>
>>> I *think* option (1) is at least an improvement.  But I completely
>>> missed Peter's race, despite having specifically looked for problems
>>> there, so take my opinion with an appropriate quantity of salt.
>> I vote for 1 as well. I think we have now given good coverage to the two sources of problems (the two lock-free regions):
>> - reference queue state can be seen while queue state is in transition
>> - queue empty state can be seen while reference state is in transition
> New webrev, with both changes:
>
> http://cr.openjdk.java.net/~kbarrett/8132306/webrev.01/
>

This looks good now. Thanks for taking both of the issues together. I 
wonder if a similar racy test could be devised for the 2nd race. I doubt 
the ReferenceEnqueue test was meant to catch invalid races specifically. 
It was more a coincidence that it failed.

I tried to create a reproducer for 2nd race, but it is not reliable and 
sometimes needs several minutes to fail.

Now I have to check if my prototype for improved Reference handling:

http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.06/

suffers from these or similar races too. From 1st look it seems so.

Regards, Peter



From konstantin.shefov at oracle.com  Fri Jul 31 16:37:29 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 31 Jul 2015 19:37:29 +0300
Subject: [9] RFR: 8060717: [TESTBUG] Improve test coverage of
	MethodHandles.explicitCastArguments()
Message-ID: <55BBA449.1030603@oracle.com>

Hello,

Please review a test improvement. Covered more cases for 
MethodHandles.explicitCastArguments().

Bug: https://bugs.openjdk.java.net/browse/JDK-8060717
Webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.00/

-Konstantin


From Roger.Riggs at Oracle.com  Fri Jul 31 16:55:20 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 31 Jul 2015 12:55:20 -0400
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: 
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
	<55BAC679.7010108@oracle.com>
	
Message-ID: <55BBA878.3090509@Oracle.com>

Hi Volker,

I agree that adding an Info.commandline() method would be a good way
to make the command line available and be able to describe that it is
OS dependent and may be truncated.
And having it assemble the command and arguments when they are available 
makes sense.
As an API addition it will need a clear spec and I can run it through 
CCC so it gets
another review and compatibility tests.

Thanks, Roger




On 7/31/2015 5:03 AM, Volker Simonis wrote:
> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks  wrote:
>>
>> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>>>> truncated or incomplete
>>>> values for the executable or arguments.
>>>> Can anyone be a tie-breaker  (with a good rational and suggestion for how
>>>> an
>>>> application can use the data).
>>>
>>> As I wrote, I agree to hear other opinions here.
>>>
>>> All I want to say that this truncated data is actually what 'ps' is
>>> reporting on Solaris since decades and people seem to be happy with
>>> it. As use case I can imagine logging or monitoring (something like
>>> 'top' in Java) where this data will be just good enough.
>>>
>>> We could specially mark possibly incomplete data by extending the Info
>>> object with functions like commandIsExact() or argumentsIsPrecise().
>>> But notice that we can not statically preset these values per
>>> platform. For example on Solaris, the 'command()' would return a
>>> precise value for processes with the same uid like the VM but only
>>> inaccurate values for all other processes. The "arguments()" would be
>>> always inaccurate on Solaris/AIX.
>>
>> It seems like there are cases where either exact or only approximate
>> information is available. And as you observed, you might get one or the
>> other on the same platform, depending on the UID. It also might depend on
>> process state; I believe that some information becomes inaccessible when the
>> process enters the zombie state.
>>
>> I don't think we should simply ignore one case or the other, but I also
>> don't think we should try to cram the different information into the same
>> API.
>>
>> The current ProcessHandle.Info api has
>>
>>      Optional command()
>>      Optional arguments()
>>
>> It sounds to me like Roger wants these to contain only exact information.
>> That seems reasonable, and this probably needs to be specified more clearly
>> to contrast with what's below.
>>
>> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
>> single string which appears to be the concatenation of the arguments (maybe
>> including the command name). It's also truncated to fit PRARGSZ. It doesn't
>> make sense to me to try to return this as a String[], as the zeroth element
>> of that array, and certainly not parsed out into "words". So maybe instead
>> we should have a different API that returns an imprecise command line as a
>> single string:
>>
>>      Optional cmdline()
>>
>> (Naming bikeshed TBS). The semantics would be that this is the process'
>> command and arguments concatenated into a single string (thus potentially
>> losing argument boundaries) and also possibly truncated based on platform
>> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out in a
>> ps, top, or Activity Monitor style application, for informational purposes.
>>
>> If this were implemented, then on Solaris, command() and arguments() would
>> always return empty optionals.
>>
>> I'm not sure what this should be if the exact information is available. It
>> would be inconvenient if something that just wanted to print out an
>> approximate command line had to check several different APIs to get the
>> information. Maybe cmdline() could assemble the information from exact data
>> if it's is available, by concatenating the Strings from command() and
>> arguments(), as a convenience to the caller. But I could go either way on
>> this.
>>
>> Not sure this counts as a tie-breaker, but it might be a reasonable way
>> forward.
>>
>> s'marks
>>
> Hi Stuart,
>
> thanks a lot for your comments - I like your proposal. For me this
> sounds like a good compromise.
>
> @Roger: should I go and add a new field commandLine and the
> corresponding getter to the Info class? As Stuart proposed, the getter
> could check if 'command' and 'arguments' are available and assemble
> the command line from them. Otherwise it could use the content of the
> commandLine field if that is available.
>
> Regards,
> Volker



From huizhe.wang at oracle.com  Fri Jul 31 17:09:28 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 31 Jul 2015 10:09:28 -0700
Subject: RfR - 8132550: java/util/logging/LoggingDeadlock2.java times out
In-Reply-To: <55BB5270.4010106@oracle.com>
References: <55BB5270.4010106@oracle.com>
Message-ID: <55BBABC8.5060603@oracle.com>

Looks good to me, Daniel.

-Joe

On 7/31/2015 3:48 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for:
>
> https://bugs.openjdk.java.net/browse/JDK-8132550
> 8132550: java/util/logging/LoggingDeadlock2.java times out
>
> I was able to reproduce the deadlock consistently by inserting
> some Thread.sleep() statements at the critical places.
> The webrev still shows that (as commented code) - but I will remove
> those comments before pushing:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8132550/webrev.00/
>
> This issue here is that LogManager should also use the
> configurationLock when reading its primordial configuration
> (and not a simple synchronized(this)).
>
> That should remove all uses of synchronized((LogManager)this) from 
> LogManager, and ensure that reset(), readConfiguration(), and 
> ensureLogManagerInitialized() all use the same lock.
>
> When we moved to using a ReantrantLock object for configuration I had
> already considered doing this - but at the time I deemed it unnecessary,
> thinking you couldn't obtain a reference on LogManager through
> getLogManager() before it had initialized. But this was counting
> without System.exit() being called and starting the Cleaner thread 
> before the first call to LogManager.getLogManager() had finished.
> This introduced a small time window in which the deadlock became
> possible - at exit time, if something happened to initialize the
> LogManager right at that time.
>
> best regards
>
> -- daniel



From lance.andersen at oracle.com  Fri Jul 31 17:38:15 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 31 Jul 2015 13:38:15 -0400
Subject: RFR:  8132801: Fix typo in javax.sql.RowSet.setBlob
Message-ID: <883CAD40-C8CF-403E-8D6C-DF5F3857A795@oracle.com>

Hi all,

Need a review of this minor javadoc clean-up:

hg diff RowSet.java 
diff -r 6db2a5a855ec src/java.sql/share/classes/javax/sql/RowSet.java
--- a/src/java.sql/share/classes/javax/sql/RowSet.java	Fri Jul 31 07:48:34 2015 -0700
+++ b/src/java.sql/share/classes/javax/sql/RowSet.java	Fri Jul 31 13:28:12 2015 -0400
@@ -1477,7 +1477,7 @@
 
   /**
      * Sets the designated parameter to a InputStream object.
-     * The "{@code InputStream} must contain  the number
+     * The {@code InputStream} must contain  the number
      * of characters specified by length, otherwise a SQLException will be
      * generated when the CallableStatement is executed.
      * This method differs from the setBinaryStream (int, InputStream, int)


Best
Lance


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





From joe.darcy at oracle.com  Fri Jul 31 17:40:41 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 31 Jul 2015 10:40:41 -0700
Subject: RFR: 8132801: Fix typo in javax.sql.RowSet.setBlob
In-Reply-To: <883CAD40-C8CF-403E-8D6C-DF5F3857A795@oracle.com>
References: <883CAD40-C8CF-403E-8D6C-DF5F3857A795@oracle.com>
Message-ID: <55BBB319.4080807@oracle.com>

Looks good; cheers,

-Joe

On 7/31/2015 10:38 AM, Lance Andersen wrote:
> Hi all,
>
> Need a review of this minor javadoc clean-up:
>
> hg diff RowSet.java
> diff -r 6db2a5a855ec src/java.sql/share/classes/javax/sql/RowSet.java
> --- a/src/java.sql/share/classes/javax/sql/RowSet.java	Fri Jul 31 07:48:34 2015 -0700
> +++ b/src/java.sql/share/classes/javax/sql/RowSet.java	Fri Jul 31 13:28:12 2015 -0400
> @@ -1477,7 +1477,7 @@
>   
>     /**
>        * Sets the designated parameter to a InputStream object.
> -     * The "{@code InputStream} must contain  the number
> +     * The {@code InputStream} must contain  the number
>        * of characters specified by length, otherwise a SQLException will be
>        * generated when the CallableStatement is executed.
>        * This method differs from the setBinaryStream (int, InputStream, int)
>
>
> Best
> Lance
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>



From joerg.schaible at gmx.de  Fri Jul 31 17:33:20 2015
From: joerg.schaible at gmx.de (=?UTF-8?B?SsO2cmc=?= Schaible)
Date: Fri, 31 Jul 2015 19:33:20 +0200
Subject: Replacement for sun.misc.Unsafe.allocateInstance(Class) ?
Message-ID: 

Hello guys,

there's a lot of talk about making sun.misc.Unsafe unaccessible in JDK 9 ... 
however, there seems no replacement for the allocateInstance method.

XStream is relying heavily on this functionality and without it the library 
will no longer be able to deserialize a lot of objects from XML. What are 
the long-term options? 

Cheers,
j?rg



From me at noctarius.com  Fri Jul 31 20:12:45 2015
From: me at noctarius.com (Christoph Engelbert)
Date: Fri, 31 Jul 2015 23:12:45 +0300
Subject: Replacement for sun.misc.Unsafe.allocateInstance(Class) ?
In-Reply-To: 
References: 
Message-ID: <9F920A89-70D7-40B1-A930-193BA605E0A5@noctarius.com>

Hey J?rg,

It will not yet be unaccessible, you just have to force JDK 9 to export the sun.misc package to be visible to user code. There will be a command line flag for that purpose, however I agree eventually we?ll need a replacement, whatever it looks like.

Chris

> Am 31.07.2015 um 20:33 schrieb J?rg Schaible :
> 
> Hello guys,
> 
> there's a lot of talk about making sun.misc.Unsafe unaccessible in JDK 9 ... 
> however, there seems no replacement for the allocateInstance method.
> 
> XStream is relying heavily on this functionality and without it the library 
> will no longer be able to deserialize a lot of objects from XML. What are 
> the long-term options? 
> 
> Cheers,
> j?rg
> 



From stuart.marks at oracle.com  Fri Jul 31 21:02:25 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 31 Jul 2015 14:02:25 -0700
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: <55BBA878.3090509@Oracle.com>
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
	<55BAC679.7010108@oracle.com>
	
	<55BBA878.3090509@Oracle.com>
Message-ID: <55BBE261.4060902@oracle.com>

Hi Roger, Volker,

Glad to see you guys are receptive to this and that it can move forward. Let me 
know if you'd like me to help out, for example with reviews or something.

s'marks

On 7/31/15 9:55 AM, Roger Riggs wrote:
> Hi Volker,
>
> I agree that adding an Info.commandline() method would be a good way
> to make the command line available and be able to describe that it is
> OS dependent and may be truncated.
> And having it assemble the command and arguments when they are available makes
> sense.
> As an API addition it will need a clear spec and I can run it through CCC so it
> gets
> another review and compatibility tests.
>
> Thanks, Roger
>
>
>
>
> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks  wrote:
>>>
>>> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>>>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>>>>> truncated or incomplete
>>>>> values for the executable or arguments.
>>>>> Can anyone be a tie-breaker  (with a good rational and suggestion for how
>>>>> an
>>>>> application can use the data).
>>>>
>>>> As I wrote, I agree to hear other opinions here.
>>>>
>>>> All I want to say that this truncated data is actually what 'ps' is
>>>> reporting on Solaris since decades and people seem to be happy with
>>>> it. As use case I can imagine logging or monitoring (something like
>>>> 'top' in Java) where this data will be just good enough.
>>>>
>>>> We could specially mark possibly incomplete data by extending the Info
>>>> object with functions like commandIsExact() or argumentsIsPrecise().
>>>> But notice that we can not statically preset these values per
>>>> platform. For example on Solaris, the 'command()' would return a
>>>> precise value for processes with the same uid like the VM but only
>>>> inaccurate values for all other processes. The "arguments()" would be
>>>> always inaccurate on Solaris/AIX.
>>>
>>> It seems like there are cases where either exact or only approximate
>>> information is available. And as you observed, you might get one or the
>>> other on the same platform, depending on the UID. It also might depend on
>>> process state; I believe that some information becomes inaccessible when the
>>> process enters the zombie state.
>>>
>>> I don't think we should simply ignore one case or the other, but I also
>>> don't think we should try to cram the different information into the same
>>> API.
>>>
>>> The current ProcessHandle.Info api has
>>>
>>>      Optional command()
>>>      Optional arguments()
>>>
>>> It sounds to me like Roger wants these to contain only exact information.
>>> That seems reasonable, and this probably needs to be specified more clearly
>>> to contrast with what's below.
>>>
>>> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
>>> single string which appears to be the concatenation of the arguments (maybe
>>> including the command name). It's also truncated to fit PRARGSZ. It doesn't
>>> make sense to me to try to return this as a String[], as the zeroth element
>>> of that array, and certainly not parsed out into "words". So maybe instead
>>> we should have a different API that returns an imprecise command line as a
>>> single string:
>>>
>>>      Optional cmdline()
>>>
>>> (Naming bikeshed TBS). The semantics would be that this is the process'
>>> command and arguments concatenated into a single string (thus potentially
>>> losing argument boundaries) and also possibly truncated based on platform
>>> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out in a
>>> ps, top, or Activity Monitor style application, for informational purposes.
>>>
>>> If this were implemented, then on Solaris, command() and arguments() would
>>> always return empty optionals.
>>>
>>> I'm not sure what this should be if the exact information is available. It
>>> would be inconvenient if something that just wanted to print out an
>>> approximate command line had to check several different APIs to get the
>>> information. Maybe cmdline() could assemble the information from exact data
>>> if it's is available, by concatenating the Strings from command() and
>>> arguments(), as a convenience to the caller. But I could go either way on
>>> this.
>>>
>>> Not sure this counts as a tie-breaker, but it might be a reasonable way
>>> forward.
>>>
>>> s'marks
>>>
>> Hi Stuart,
>>
>> thanks a lot for your comments - I like your proposal. For me this
>> sounds like a good compromise.
>>
>> @Roger: should I go and add a new field commandLine and the
>> corresponding getter to the Info class? As Stuart proposed, the getter
>> could check if 'command' and 'arguments' are available and assemble
>> the command line from them. Otherwise it could use the content of the
>> commandLine field if that is available.
>>
>> Regards,
>> Volker
>


From stuart.marks at oracle.com  Fri Jul 31 21:19:41 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 31 Jul 2015 14:19:41 -0700
Subject: RFR(s): 8132800: clarify stream package documentation regarding
	sequential vs parallel modes
Message-ID: <55BBE66D.2060009@oracle.com>

Hi all,

The sequential() and parallel() methods on a stream set the execution mode for 
the entire pipeline. Unfortunately this isn't particularly clear from the 
documentation. This has been a recurring question. Please review this change to 
the java.util.stream package documentation to help clarify this point.

I've also added a couple anchor tags that were missing from various sections.

This is intended to be a purely editorial change, not a specification change.

Bug:

	https://bugs.openjdk.java.net/browse/JDK-8132800

Webrev:

	http://cr.openjdk.java.net/~smarks/reviews/8132800/webrev.0/

Thanks,

s'marks