From miroslav.kos at oracle.com Tue Apr 1 08:34:32 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Tue, 01 Apr 2014 10:34:32 +0200 Subject: RFR: 8038307: JAX-WS conformance tests fail when running JCK-devtools-8 suite against RI in EBCDIC emulation mode In-Reply-To: References: <53396B71.5010104@oracle.com> <53396EF9.7050500@oracle.com> <5339760F.5040703@oracle.com> <53397CBF.8090200@oracle.com> Message-ID: <533A7A18.1090806@oracle.com> No problem, let's move it - should I prepare another webrev, or will you move it by yourself? Thanks Miran On 31/03/14 18:38, Chris Hegarty wrote: > Miran, > > If you agree, I would like to move the test ( before pushing ) to jdk/test/javax/xml/ws (/ebcdic). This is where other jaxws tests live, and will be picked up in the usual developer cycle by the jdk_other test group. > > -Chris. > > On 31 Mar 2014, at 15:33, Chris Hegarty wrote: > >> On 31/03/14 15:05, Miroslav Kos wrote: >>> Thanks Chris, the code adjusted: >>> http://cr.openjdk.java.net/~mkos/8038307/jaxws.02/ >> Approved. >> >>> Glad, if you can sponsor it for me. >> I'll push this later today. >> >> -Chris. >> >>> Regards >>> Miran >>> >>> On 31/03/14 15:34, Chris Hegarty wrote: >>>> Looks ok to me Miran. >>>> >>>> You can use String.getBytes(StandardCharsets.UTF_8) if you don't want >>>> to handle UnsupportedEncodingException. >>>> >>>> I can sponsor this for you, if you need a sponsor. >>>> >>>> -Chris. >>>> >>>> [1] >>>> http://docs.oracle.com/javase/8/docs/api/java/nio/charset/StandardCharsets.html#UTF_8 >>>> >>>> >>>> On 31/03/14 14:19, Miroslav Kos wrote: >>>>> Hi there, >>>>> please review folowing simple fix - >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038307 >>>>> Fix: http://cr.openjdk.java.net/~mkos/8038307/jaxws.01/ >>>>> Test: http://cr.openjdk.java.net/~mkos/8038307/jdk.01/ >>>>> >>>>> Issue related to EBCDIC encoding/WsImport tool. >>>>> >>>>> Thanks >>>>> Miran >>>>> >>>>> From chris.hegarty at oracle.com Tue Apr 1 08:35:14 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 1 Apr 2014 09:35:14 +0100 Subject: RFR: 8038307: JAX-WS conformance tests fail when running JCK-devtools-8 suite against RI in EBCDIC emulation mode In-Reply-To: <533A7A18.1090806@oracle.com> References: <53396B71.5010104@oracle.com> <53396EF9.7050500@oracle.com> <5339760F.5040703@oracle.com> <53397CBF.8090200@oracle.com> <533A7A18.1090806@oracle.com> Message-ID: <3C90987D-C39B-4F1B-B126-964C1DAA83D9@oracle.com> On 1 Apr 2014, at 09:34, Miroslav Kos wrote: > No problem, let's move it - should I prepare another webrev, or will you move it by yourself? No webrev update needed. I?ll just move it. Thanks, -Chris. > > Thanks > Miran > > On 31/03/14 18:38, Chris Hegarty wrote: >> Miran, >> >> If you agree, I would like to move the test ( before pushing ) to jdk/test/javax/xml/ws (/ebcdic). This is where other jaxws tests live, and will be picked up in the usual developer cycle by the jdk_other test group. >> >> -Chris. >> >> On 31 Mar 2014, at 15:33, Chris Hegarty wrote: >> >>> On 31/03/14 15:05, Miroslav Kos wrote: >>>> Thanks Chris, the code adjusted: >>>> http://cr.openjdk.java.net/~mkos/8038307/jaxws.02/ >>> Approved. >>> >>>> Glad, if you can sponsor it for me. >>> I'll push this later today. >>> >>> -Chris. >>> >>>> Regards >>>> Miran >>>> >>>> On 31/03/14 15:34, Chris Hegarty wrote: >>>>> Looks ok to me Miran. >>>>> >>>>> You can use String.getBytes(StandardCharsets.UTF_8) if you don't want >>>>> to handle UnsupportedEncodingException. >>>>> >>>>> I can sponsor this for you, if you need a sponsor. >>>>> >>>>> -Chris. >>>>> >>>>> [1] >>>>> http://docs.oracle.com/javase/8/docs/api/java/nio/charset/StandardCharsets.html#UTF_8 >>>>> >>>>> >>>>> On 31/03/14 14:19, Miroslav Kos wrote: >>>>>> Hi there, >>>>>> please review folowing simple fix - >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038307 >>>>>> Fix: http://cr.openjdk.java.net/~mkos/8038307/jaxws.01/ >>>>>> Test: http://cr.openjdk.java.net/~mkos/8038307/jdk.01/ >>>>>> >>>>>> Issue related to EBCDIC encoding/WsImport tool. >>>>>> >>>>>> Thanks >>>>>> Miran >>>>>> >>>>>> > From brucechapman at paradise.net.nz Tue Apr 1 09:28:01 2014 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Tue, 01 Apr 2014 22:28:01 +1300 Subject: Implicit 'this' return for void methods In-Reply-To: References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> Message-ID: <533A86A1.9020708@paradise.net.nz> Slightly preceding Ulf's coin proposal by a few hours was http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html Where I suggested the "naked dot" notation (coined in http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html) has better value as ".. a syntax for referring to the receiver of a method inside arguments to the method." More formally, the naked dot (at the start of an expression, not following an invocation to a void method) would refer to the receiver of the innermost surrounding invocation expression. and so to answer Guy's question below in terms of my original intention rather than Ulf's proposal, .indexof("Q") would use myVeryLongNamedString as its receiver. I see particular value for these naked dot expressions in creating fluent APIs such as builder patterns. As suggested in my coin post, there is also value for passing enums or named constants to methods when (as is often the case) these named constants are defined in the same class as the method being invoked. In a highly informal sense, the naked dot enables on demand changing of the scope to be that of the invocation expression's receiver, I think with this interpretation of the meaning of naked or leading dot, Guy's compromise restriction below is not required. Bruce On 27/03/2014 4:51 a.m., Guy Steele wrote: > > I am a bit more skeptical about expressions that begin with a dot because of potential > confusion about which expression is referred to: > > myVeryLongNamedString.subString(.indexOf("C?), .indexOf("Q?)) > > seems clear enough, but what about: > > myVeryLongNamedString.subString(.indexOf("C?) + otherString.length(), .indexOf("Q?)) > > Does the second occurrence of .indexOf use myVeryLongNamedString or otherString? > > A compromise would be to allow leading-dot expressions to occur only within the arguments > of the method call whose target is the object which the leading-dot expressions are expected > to use as their target, and if there are such leading-dot expressions within the arguments > then the arguments must not contain any non-leading-dot field references or method calls. > Just a thought for discussion. This would be considered a separate mechanism from the > chaining-of-void-methods mechanism (it was a very clever idea to try to unify them in Ulf's > original proposal, though). > > ?Guy > > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From paul.sandoz at oracle.com Tue Apr 1 09:44:38 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Apr 2014 11:44:38 +0200 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <53305D76.7080009@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> <53305D76.7080009@oracle.com> Message-ID: <15133BFB-B289-41AE-A530-1D34FC64EF72@oracle.com> Hi Vladimir, This looks good. Minor stuff below. I too prefer *_TYPE instead of Int/Float/Void etc as those are not v. friendly for static imports. Paul. LambaForm: -- private static int fixResult(int result, Name[] names) { if (result == LAST_RESULT) result = names.length - 1; // might still be void if (result >= 0 && names[result].type == V_TYPE) result = -1; return result; } change to "result = -1" to: result = VOID_RESULT; ? Change: LambdaForm addArguments(int pos, List> types) { BasicType[] basicTypes = new BasicType[types.size()]; for (int i = 0; i < basicTypes.length; i++) basicTypes[i] = basicType(types.get(i)); return addArguments(pos, basicTypes); } to: LambdaForm addArguments(int pos, List> types) { return addArguments(pos, basicTypes(types)); } ? Methods not used, i cannot tell which may be there for future code or are referenced indirectly: String basicTypeSignature() { //return LambdaForm.basicTypeSignature(resolvedHandle.type()); return LambdaForm.basicTypeSignature(methodType()); } void resolve() { for (Name n : names) n.resolve(); } static LambdaForm identityForm(BasicType type) { return LF_identityForm[type.ordinal()]; } static LambdaForm zeroForm(BasicType type) { return LF_zeroForm[type.ordinal()]; } BoundMethodHandle: -- Methods not used: SpeciesData extendWith(Class type) { return extendWith(basicType(type)); } SpeciesData extendWithChar(char type) { return extendWith(basicType(type)); } static void initStatics() {} static { SpeciesData.initStatics(); } Deprecated method in ASM (there are also a few others): mv.visitMethodInsn(INVOKESPECIAL, className, "", makeSignature(types, true)); I think you need to append false as the last parameter. Unused first parameter "cbmhClass": static NamedFunction[] makeNominalGetters(Class cbmhClass, String types, NamedFunction[] nfs, MethodHandle[] getters) { InvokerByteCodeGenerator -- private int loadInsnOpcode(BasicType type) throws InternalError { int opcode; switch (type) { case I_TYPE: opcode = Opcodes.ILOAD; break; case J_TYPE: opcode = Opcodes.LLOAD; break; case F_TYPE: opcode = Opcodes.FLOAD; break; case D_TYPE: opcode = Opcodes.DLOAD; break; case L_TYPE: opcode = Opcodes.ALOAD; break; default: throw new InternalError("unknown type: " + type); } return opcode; } Could just do: case I_TYPE: return Opcodes.ILOAD; etc. Same for "storeInsnOpcode" method. Unused? static int nfi = 0; MethodHandle -- Unused? /*non-public*/ MethodHandle bindImmediate(int pos, BasicType basicType, Object value) { // Bind an immediate value to a position in the arguments. // This means, elide the respective argument, // and replace all references to it in NamedFunction args with the specified value. // CURRENT RESTRICTIONS // * only for pos 0 and UNSAFE (position is adjusted in MHImpl to make API usable for others) assert pos == 0 && basicType == L_TYPE && value instanceof Unsafe; MethodType type2 = type.dropParameterTypes(pos, pos + 1); // adjustment: ignore receiver! LambdaForm form2 = form.bindImmediate(pos + 1, basicType, value); // adjust pos to form-relative pos return copyWith(type2, form2); } On Mar 24, 2014, at 5:29 PM, Vladimir Ivanov wrote: > Updated version: > http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03/ > > - changed the way how arrays of types are created: > static final BasicType[] ALL_TYPES = BasicType.values(); > static final BasicType[] ARG_TYPES = Arrays.copyOf(ALL_TYPES, ALL_TYPES.length-1); > > - added a test for BasicType (LambdaFormTest.testBasicType). > > Best regards, > Vladimir Ivanov From paul.sandoz at oracle.com Tue Apr 1 09:55:22 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Apr 2014 11:55:22 +0200 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <53232FF3.9020803@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> Message-ID: <6562A055-4B0E-4992-8BF9-A16EFDB09CD6@oracle.com> On Mar 14, 2014, at 5:36 PM, Vladimir Ivanov wrote: >> Doh! crossed webrevs, thanks. >> >> Just had a quick look, this looks like a really nice improvement to the array setter/getter support, definitely simplified. IIUC the mh.viewAsType will now handle the appropriate casting. I believe it might reduce the "ceremony" for array setter/getter MHs [1]. >> >> I see there is a PROFILE_LEVEL option, by default set to 0, that results in casts not being emitted: >> >> + if (VerifyType.isNullConversion(Object.class, pclass, false)) { >> + if (PROFILE_LEVEL > 0) >> + emitReferenceCast(Object.class, arg); >> + return; >> + } >> ... >> + mv.visitLdcInsn(constantPlaceholder(cls)); >> + mv.visitTypeInsn(Opcodes.CHECKCAST, CLS); >> + mv.visitInsn(Opcodes.SWAP); >> + mv.visitMethodInsn(Opcodes.INVOKESTATIC, MHI, "castReference", CLL_SIG, false); >> + if (Object[].class.isAssignableFrom(cls)) >> + mv.visitTypeInsn(Opcodes.CHECKCAST, OBJARY); >> + else if (PROFILE_LEVEL > 0) >> + mv.visitTypeInsn(Opcodes.CHECKCAST, OBJ); >> >> Can you explain a bit the rational for that? > These casts are redundant - they aren't required for bytecode correctness. The idea behind PROFILE_LEVEL is to provide more type information to JIT-compiler. Right now, type profiling occurs on every checkcast instruction. So, having these additional instructions we can feed C2 with more accurate information about types. > > Consider this as a hack to overcome some of the limitations of current profiling implementation in VM. > Apologies for the late reply this dropped off my radar... Ah! i may have just had a minor epiphany :-) So that is why in DirectMethodHandle there are casts for fields, via say Accessor.checkCast? @Override Object checkCast(Object obj) { return fieldType.cast(obj); } if so could PROFILE_LEVEL be supported in that code too? Perhaps the JIT could derive some profile information from the MethodType of the MethodHandle? I notice that in my experiments for enhanced access to instances of fields that casts are almost optimized away but a null-check is left [*], which is also seems redundant and could impact performance get/set of null values. Paul. [*] 0x000000010d050f70: test %r10d,%r10d 0x000000010d050f73: je 0x000000010d050f9d ... 0x000000010d050f9d: mov %rsi,%rbp 0x000000010d050fa0: mov %r10d,0x4(%rsp) 0x000000010d050fa5: mov $0xffffffad,%esi 0x000000010d050faa: nop 0x000000010d050fab: callq 0x000000010d0163e0 ; OopMap{rbp=Oop [4]=NarrowOop off=112} ;*ifnull ; - java.lang.Class::cast at 1 (line 3253) ; - java.lang.invoke.InstanceFieldHandle::checkCast at 2 (line 133) ; - java.lang.invoke.InstanceFieldHandle::set at 19 (line 153) ; - java.lang.invoke.VarHandle::set at 21 (line 127) ; - VarHandleTest::testLoopOne at 8 (line 157) ; {runtime_call} 0x000000010d050fb0: callq 0x000000010c39d330 ;*ifnull ; - java.lang.Class::cast at 1 (line 3253) ; - java.lang.invoke.InstanceFieldHandle::checkCast at 2 (line 133) ; - java.lang.invoke.InstanceFieldHandle::set at 19 (line 153) ; - java.lang.invoke.VarHandle::set at 21 (line 127) ; - VarHandleTest::testLoopOne at 8 (line 157) ; {runtime_call} From Ulf.Zibis at CoSoCo.de Tue Apr 1 11:26:22 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 01 Apr 2014 13:26:22 +0200 Subject: Implicit 'this' return for void methods In-Reply-To: <533A86A1.9020708@paradise.net.nz> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> Message-ID: <533AA25E.9060507@CoSoCo.de> Am 01.04.2014 11:28, schrieb Bruce Chapman: > Slightly preceding Ulf's coin proposal by a few hours was > > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html > > Where I suggested the "naked dot" notation (coined in > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html) has better value as ".. a > syntax for referring to the receiver of a method inside arguments to the > method." > > More formally, the naked dot (at the start of an expression, not following an invocation to a > void method) would refer to the receiver of the innermost surrounding invocation expression. > > and so to answer Guy's question below in terms of my original intention rather than Ulf's > proposal, .indexof("Q") would use myVeryLongNamedString as its receiver. +1 My proposal was meant exactly as that. Maybe my wording was not clear enough in that. -Ulf From lance.andersen at oracle.com Tue Apr 1 11:35:23 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 1 Apr 2014 07:35:23 -0400 Subject: RFR 8038653 Time.toLocalTime, Time.valueOf javadoc clarification Message-ID: <904F9535-9D05-4027-BA4A-2EB7251538DB@oracle.com> HI all, Looking for a reviewer for the following javadoc clarification when using java.sql.Time.toLocalTime/ValueOf. Here is the webrev which has been had its ccc approved ljanders-mac:sql ljanders$ hg diff diff -r fab6896b880f src/share/classes/java/sql/Time.java --- a/src/share/classes/java/sql/Time.java Fri Mar 28 18:03:40 2014 +0100 +++ b/src/share/classes/java/sql/Time.java Tue Apr 01 07:31:36 2014 -0400 @@ -254,6 +254,9 @@ * Obtains an instance of {@code Time} from a {@link LocalTime} object * with the same hour, minute and second time value as the given * {@code LocalTime}. + *

+ * Note:The nanosecond field from {@code LocalTime} is + * not part of the newly created {@code Time} object. * * @param time a {@code LocalTime} to convert * @return a {@code Time} object @@ -269,7 +272,8 @@ * Converts this {@code Time} object to a {@code LocalTime}. *

* The conversion creates a {@code LocalTime} that represents the same - * hour, minute, and second time value as this {@code Time}. + * hour, minute, and second time value as this {@code Time}. The + * nanosecond {@code LocalTime} field will be set to zero. * * @return a {@code LocalTime} object representing the same time value * @since 1.8 ljanders-mac:sql ljanders$ 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 alexander.v.stepanov at oracle.com Tue Apr 1 12:51:12 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Tue, 01 Apr 2014 16:51:12 +0400 Subject: [9] Review Request for 8038795: tidy warnings cleanup for javax.management Message-ID: <533AB640.4010608@oracle.com> Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8038795 Webrev corresponding: http://cr.openjdk.java.net/~yan/8038795/webrev.00/ Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. Thanks. Regards, Alexander From Alan.Bateman at oracle.com Tue Apr 1 12:57:03 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Apr 2014 13:57:03 +0100 Subject: [9] Review Request for 8038795: tidy warnings cleanup for javax.management In-Reply-To: <533AB640.4010608@oracle.com> References: <533AB640.4010608@oracle.com> Message-ID: <533AB79F.9060303@oracle.com> I think you are looking for jmx-dev so forwarding to that list. On 01/04/2014 13:51, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8038795 > > Webrev corresponding: > http://cr.openjdk.java.net/~yan/8038795/webrev.00/ > > Just a minor cleanup of javadoc to avoid tidy warnings; no other code > affected. > > Thanks. > > Regards, > Alexander From peter.levart at gmail.com Tue Apr 1 13:16:04 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 01 Apr 2014 15:16:04 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> Message-ID: <533ABC14.50304@gmail.com> Hi Alan, Volker, Thanks for sharing the info and for testing on AIX. Here's the updated webrev that hopefully includes the correct "dispatch on os.name" logic. I included "Solaris" as an alternative to "SunOS" since I saw this in some documents on Internet. If this is superfluous, I can remove it: http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.03/ I tested this on Linux and Solaris and the java/lang/ProcessBuilder jtreg tests pass. So with Volker's test on AIX, the only OS platform left for testing is Mac OS X. Would someone volunteer? Regards, Peter On 03/27/2014 11:18 AM, Volker Simonis wrote: > Hi Peter, > > thanks for applying these changes to the AIX files as well. > > With the additional line: > > if (osName.equals("AIX")) { return AIX; } > > in Os.get() your change compiles cleanly on AIX and runs the > java/lang/ProcessBuilder tests without any errors. > > So from an AIX perspective, thumbs up. > > Regards, > Volker > > > On Wed, Mar 26, 2014 at 5:18 PM, Alan Bateman wrote: >> On 26/03/2014 15:19, Peter Levart wrote: >>> I couldn't find any official document about possible os.name values for >>> different supported OSes. Does anyone have a pointer? >> I don't know if there is a definite list but I assume we don't need to be >> concerned with anything beyond the 4 that we have in OpenJDK, which is >> "Linux", "SunOS", "AIX" and contains("OS X"). >> >> If we get to the point in JDK 9 where src/solaris is renamed to src/unix (or >> something equivalent) then it could mean that the Os enum can be replaced >> with an OS specific class in src/linux, src/solaris, ... and this would >> avoid the need for an os.name check at runtime. >> >> -Alan. >> From rob.mckenna at oracle.com Tue Apr 1 13:26:02 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 01 Apr 2014 14:26:02 +0100 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533ABC14.50304@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> Message-ID: <533ABE6A.7040308@oracle.com> Hi Peter, Yup, I'll give this a whirl. -Rob On 01/04/14 14:16, Peter Levart wrote: > Hi Alan, Volker, > > Thanks for sharing the info and for testing on AIX. Here's the updated > webrev that hopefully includes the correct "dispatch on os.name" > logic. I included "Solaris" as an alternative to "SunOS" since I saw > this in some documents on Internet. If this is superfluous, I can > remove it: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.03/ > > I tested this on Linux and Solaris and the java/lang/ProcessBuilder > jtreg tests pass. So with Volker's test on AIX, the only OS platform > left for testing is Mac OS X. Would someone volunteer? > > Regards, Peter > > On 03/27/2014 11:18 AM, Volker Simonis wrote: >> Hi Peter, >> >> thanks for applying these changes to the AIX files as well. >> >> With the additional line: >> >> if (osName.equals("AIX")) { return AIX; } >> >> in Os.get() your change compiles cleanly on AIX and runs the >> java/lang/ProcessBuilder tests without any errors. >> >> So from an AIX perspective, thumbs up. >> >> Regards, >> Volker >> >> >> On Wed, Mar 26, 2014 at 5:18 PM, Alan Bateman >> wrote: >>> On 26/03/2014 15:19, Peter Levart wrote: >>>> I couldn't find any official document about possible os.name values >>>> for >>>> different supported OSes. Does anyone have a pointer? >>> I don't know if there is a definite list but I assume we don't need >>> to be >>> concerned with anything beyond the 4 that we have in OpenJDK, which is >>> "Linux", "SunOS", "AIX" and contains("OS X"). >>> >>> If we get to the point in JDK 9 where src/solaris is renamed to >>> src/unix (or >>> something equivalent) then it could mean that the Os enum can be >>> replaced >>> with an OS specific class in src/linux, src/solaris, ... and this would >>> avoid the need for an os.name check at runtime. >>> >>> -Alan. >>> > From Alan.Bateman at oracle.com Tue Apr 1 13:30:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Apr 2014 14:30:40 +0100 Subject: RFR 8038653 Time.toLocalTime, Time.valueOf javadoc clarification In-Reply-To: <904F9535-9D05-4027-BA4A-2EB7251538DB@oracle.com> References: <904F9535-9D05-4027-BA4A-2EB7251538DB@oracle.com> Message-ID: <533ABF80.1040902@oracle.com> On 01/04/2014 12:35, Lance Andersen wrote: > HI all, > > Looking for a reviewer for the following javadoc clarification when using java.sql.Time.toLocalTime/ValueOf. The wording looks okay to me, I just wondering whether the "Note" might be better as an @apiNote. -Alan. From alexander.v.stepanov at oracle.com Tue Apr 1 13:31:24 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Tue, 01 Apr 2014 17:31:24 +0400 Subject: [9] Review Request for 8038795: tidy warnings cleanup for javax.management In-Reply-To: <533AB79F.9060303@oracle.com> References: <533AB640.4010608@oracle.com> <533AB79F.9060303@oracle.com> Message-ID: <533ABFAC.2020302@oracle.com> Thanks! On 01.04.2014 16:57, Alan Bateman wrote: > > I think you are looking for jmx-dev so forwarding to that list. > > On 01/04/2014 13:51, alexander stepanov wrote: >> Hello, >> >> Could you please review the fix for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8038795 >> >> Webrev corresponding: >> http://cr.openjdk.java.net/~yan/8038795/webrev.00/ >> >> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >> affected. >> >> Thanks. >> >> Regards, >> Alexander > From Alan.Bateman at oracle.com Tue Apr 1 13:35:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Apr 2014 14:35:20 +0100 Subject: [9] Review Request for 8038795: tidy warnings cleanup for javax.management In-Reply-To: <533ABFAC.2020302@oracle.com> References: <533AB640.4010608@oracle.com> <533AB79F.9060303@oracle.com> <533ABFAC.2020302@oracle.com> Message-ID: <533AC098.3010305@oracle.com> On 01/04/2014 14:31, alexander stepanov wrote: > Thanks! I should have said that the changes look okay to me. I just assume the removal of the

isn't really necessary. -Alan. From daniel.fuchs at oracle.com Tue Apr 1 13:44:20 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 01 Apr 2014 15:44:20 +0200 Subject: jmx-dev [9] Review Request for 8038795: tidy warnings cleanup for javax.management In-Reply-To: <533AB79F.9060303@oracle.com> References: <533AB640.4010608@oracle.com> <533AB79F.9060303@oracle.com> Message-ID: <533AC2B4.8070205@oracle.com> Hi Alexander, Looks good. I think I would remove the leading

in http://cr.openjdk.java.net/~yan/8038795/webrev.00/src/share/classes/javax/management/remote/JMXPrincipal.java.frames.html as well. If you don't please check that the generated javadoc for JMXPrincipal.java still looks good. While you're at it maybe you should remove the strange
  between the @param tags in such as: 86 *
  best regards, -- daniel On 4/1/14 2:57 PM, Alan Bateman wrote: > > I think you are looking for jmx-dev so forwarding to that list. > > On 01/04/2014 13:51, alexander stepanov wrote: >> Hello, >> >> Could you please review the fix for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8038795 >> >> Webrev corresponding: >> http://cr.openjdk.java.net/~yan/8038795/webrev.00/ >> >> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >> affected. >> >> Thanks. >> >> Regards, >> Alexander > From roger.riggs at oracle.com Tue Apr 1 13:49:29 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 01 Apr 2014 09:49:29 -0400 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533ABC14.50304@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> Message-ID: <533AC3E9.3060406@oracle.com> Hi Peter, The design using enum for the os dependencies does not make it possible to include only the support needed for a particular platform at build time. Every implementation will be carrying around the support for all the other platforms. A build time binding would be more efficient. Roger On 4/1/2014 9:16 AM, Peter Levart wrote: > Hi Alan, Volker, > > Thanks for sharing the info and for testing on AIX. Here's the updated > webrev that hopefully includes the correct "dispatch on os.name" > logic. I included "Solaris" as an alternative to "SunOS" since I saw > this in some documents on Internet. If this is superfluous, I can > remove it: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.03/ > > I tested this on Linux and Solaris and the java/lang/ProcessBuilder > jtreg tests pass. So with Volker's test on AIX, the only OS platform > left for testing is Mac OS X. Would someone volunteer? > > Regards, Peter > > On 03/27/2014 11:18 AM, Volker Simonis wrote: >> Hi Peter, >> >> thanks for applying these changes to the AIX files as well. >> >> With the additional line: >> >> if (osName.equals("AIX")) { return AIX; } >> >> in Os.get() your change compiles cleanly on AIX and runs the >> java/lang/ProcessBuilder tests without any errors. >> >> So from an AIX perspective, thumbs up. >> >> Regards, >> Volker >> >> >> On Wed, Mar 26, 2014 at 5:18 PM, Alan Bateman >> wrote: >>> On 26/03/2014 15:19, Peter Levart wrote: >>>> I couldn't find any official document about possible os.name values >>>> for >>>> different supported OSes. Does anyone have a pointer? >>> I don't know if there is a definite list but I assume we don't need >>> to be >>> concerned with anything beyond the 4 that we have in OpenJDK, which is >>> "Linux", "SunOS", "AIX" and contains("OS X"). >>> >>> If we get to the point in JDK 9 where src/solaris is renamed to >>> src/unix (or >>> something equivalent) then it could mean that the Os enum can be >>> replaced >>> with an OS specific class in src/linux, src/solaris, ... and this would >>> avoid the need for an os.name check at runtime. >>> >>> -Alan. >>> > From Alan.Bateman at oracle.com Tue Apr 1 13:49:52 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Apr 2014 14:49:52 +0100 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533ABC14.50304@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> Message-ID: <533AC400.5070101@oracle.com> On 01/04/2014 14:16, Peter Levart wrote: > Hi Alan, Volker, > > Thanks for sharing the info and for testing on AIX. Here's the updated > webrev that hopefully includes the correct "dispatch on os.name" > logic. I included "Solaris" as an alternative to "SunOS" since I saw > this in some documents on Internet. If this is superfluous, I can > remove it: AFAIK, it's always been "SunOS". As regards OS X then contains("OS X") is what we have been using after discussing with the Apple folks on macosx-port-dev some time ago. I see Rob has agreed to test this platform for you. I'll look at the webrev in detail later but if the name "Os" looks a bit odd then a "Platform" might work here. -Alan From vladimir.x.ivanov at oracle.com Tue Apr 1 13:57:35 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 01 Apr 2014 17:57:35 +0400 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <15133BFB-B289-41AE-A530-1D34FC64EF72@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> <53305D76.7080009@oracle.com> <15133BFB-B289-41AE-A530-1D34FC64EF72@oracle.com> Message-ID: <533AC5CF.5060404@oracle.com> Paul, thanks for review. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8037210/webrev.04/ Best regards, Vladimir Ivanov On 4/1/14 1:44 PM, Paul Sandoz wrote: > Hi Vladimir, > > This looks good. Minor stuff below. > > I too prefer *_TYPE instead of Int/Float/Void etc as those are not v. friendly for static imports. > > Paul. > > LambaForm: > -- > > private static int fixResult(int result, Name[] names) { > if (result == LAST_RESULT) > result = names.length - 1; // might still be void > if (result >= 0 && names[result].type == V_TYPE) > result = -1; > return result; > } > > change to "result = -1" to: > > result = VOID_RESULT; > > ? Done. > > > Change: > > LambdaForm addArguments(int pos, List> types) { > BasicType[] basicTypes = new BasicType[types.size()]; > for (int i = 0; i < basicTypes.length; i++) > basicTypes[i] = basicType(types.get(i)); > return addArguments(pos, basicTypes); > } > > to: > > LambdaForm addArguments(int pos, List> types) { > return addArguments(pos, basicTypes(types)); > } > > ? Done. > > > Methods not used, i cannot tell which may be there for future code or are referenced indirectly: > > String basicTypeSignature() { > //return LambdaForm.basicTypeSignature(resolvedHandle.type()); > return LambdaForm.basicTypeSignature(methodType()); > } > > void resolve() { > for (Name n : names) n.resolve(); > } > > static LambdaForm identityForm(BasicType type) { > return LF_identityForm[type.ordinal()]; > } > static LambdaForm zeroForm(BasicType type) { > return LF_zeroForm[type.ordinal()]; > } > Removed. > > > BoundMethodHandle: > -- > > Methods not used: > > SpeciesData extendWith(Class type) { > return extendWith(basicType(type)); > } > > SpeciesData extendWithChar(char type) { > return extendWith(basicType(type)); > } > > static void initStatics() {} > static { SpeciesData.initStatics(); } Removed. > > > Deprecated method in ASM (there are also a few others): > > mv.visitMethodInsn(INVOKESPECIAL, className, "", makeSignature(types, true)); > > I think you need to append false as the last parameter. Fixed. > > > Unused first parameter "cbmhClass": > > static NamedFunction[] makeNominalGetters(Class cbmhClass, String types, NamedFunction[] nfs, MethodHandle[] getters) { Removed. > InvokerByteCodeGenerator > -- > > private int loadInsnOpcode(BasicType type) throws InternalError { > int opcode; > switch (type) { > case I_TYPE: opcode = Opcodes.ILOAD; break; > case J_TYPE: opcode = Opcodes.LLOAD; break; > case F_TYPE: opcode = Opcodes.FLOAD; break; > case D_TYPE: opcode = Opcodes.DLOAD; break; > case L_TYPE: opcode = Opcodes.ALOAD; break; > default: > throw new InternalError("unknown type: " + type); > } > return opcode; > } > > Could just do: > > case I_TYPE: return Opcodes.ILOAD; > > etc. Same for "storeInsnOpcode" method. Changed as you suggest. > > > Unused? > > static int nfi = 0; Removed. > MethodHandle > -- > > Unused? > > /*non-public*/ > MethodHandle bindImmediate(int pos, BasicType basicType, Object value) { > // Bind an immediate value to a position in the arguments. > // This means, elide the respective argument, > // and replace all references to it in NamedFunction args with the specified value. > > // CURRENT RESTRICTIONS > // * only for pos 0 and UNSAFE (position is adjusted in MHImpl to make API usable for others) > assert pos == 0 && basicType == L_TYPE && value instanceof Unsafe; > MethodType type2 = type.dropParameterTypes(pos, pos + 1); // adjustment: ignore receiver! > LambdaForm form2 = form.bindImmediate(pos + 1, basicType, value); // adjust pos to form-relative pos > return copyWith(type2, form2); > } Removed. Best regards, Vladimir Ivanov > > > On Mar 24, 2014, at 5:29 PM, Vladimir Ivanov wrote: > >> Updated version: >> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03/ >> >> - changed the way how arrays of types are created: >> static final BasicType[] ALL_TYPES = BasicType.values(); >> static final BasicType[] ARG_TYPES = Arrays.copyOf(ALL_TYPES, ALL_TYPES.length-1); >> >> - added a test for BasicType (LambdaFormTest.testBasicType). >> >> Best regards, >> Vladimir Ivanov > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From vladimir.x.ivanov at oracle.com Tue Apr 1 14:10:12 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 01 Apr 2014 18:10:12 +0400 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <6562A055-4B0E-4992-8BF9-A16EFDB09CD6@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> <6562A055-4B0E-4992-8BF9-A16EFDB09CD6@oracle.com> Message-ID: <533AC8C4.9080601@oracle.com> Paul, Unfortunately, additional profiling doesn't work for Accessor.checkCast case. The problem is Accessor.checkCast is called from multiple places, so type profile is very likely to be polluted. And it kills the benefits. I don't think MethodType helps with profiling in any way. It represents type info which is necessary for correctness checks. Profiling collects more fine-grained information (e.g. exact types, values). Regarding redundant null check, do you have a test case so I can play with it myself? Best regards, Vladimir Ivanov On 4/1/14 1:55 PM, Paul Sandoz wrote: > On Mar 14, 2014, at 5:36 PM, Vladimir Ivanov wrote: >>> Doh! crossed webrevs, thanks. >>> >>> Just had a quick look, this looks like a really nice improvement to the array setter/getter support, definitely simplified. IIUC the mh.viewAsType will now handle the appropriate casting. I believe it might reduce the "ceremony" for array setter/getter MHs [1]. >>> >>> I see there is a PROFILE_LEVEL option, by default set to 0, that results in casts not being emitted: >>> >>> + if (VerifyType.isNullConversion(Object.class, pclass, false)) { >>> + if (PROFILE_LEVEL > 0) >>> + emitReferenceCast(Object.class, arg); >>> + return; >>> + } >>> ... >>> + mv.visitLdcInsn(constantPlaceholder(cls)); >>> + mv.visitTypeInsn(Opcodes.CHECKCAST, CLS); >>> + mv.visitInsn(Opcodes.SWAP); >>> + mv.visitMethodInsn(Opcodes.INVOKESTATIC, MHI, "castReference", CLL_SIG, false); >>> + if (Object[].class.isAssignableFrom(cls)) >>> + mv.visitTypeInsn(Opcodes.CHECKCAST, OBJARY); >>> + else if (PROFILE_LEVEL > 0) >>> + mv.visitTypeInsn(Opcodes.CHECKCAST, OBJ); >>> >>> Can you explain a bit the rational for that? >> These casts are redundant - they aren't required for bytecode correctness. The idea behind PROFILE_LEVEL is to provide more type information to JIT-compiler. Right now, type profiling occurs on every checkcast instruction. So, having these additional instructions we can feed C2 with more accurate information about types. >> >> Consider this as a hack to overcome some of the limitations of current profiling implementation in VM. >> > > Apologies for the late reply this dropped off my radar... > > Ah! i may have just had a minor epiphany :-) > > So that is why in DirectMethodHandle there are casts for fields, via say Accessor.checkCast? > > @Override Object checkCast(Object obj) { > return fieldType.cast(obj); > } > > if so could PROFILE_LEVEL be supported in that code too? > > Perhaps the JIT could derive some profile information from the MethodType of the MethodHandle? > > I notice that in my experiments for enhanced access to instances of fields that casts are almost optimized away but a null-check is left [*], which is also seems redundant and could impact performance get/set of null values. > > Paul. > > [*] > > 0x000000010d050f70: test %r10d,%r10d > 0x000000010d050f73: je 0x000000010d050f9d > ... > 0x000000010d050f9d: mov %rsi,%rbp > 0x000000010d050fa0: mov %r10d,0x4(%rsp) > 0x000000010d050fa5: mov $0xffffffad,%esi > 0x000000010d050faa: nop > 0x000000010d050fab: callq 0x000000010d0163e0 ; OopMap{rbp=Oop [4]=NarrowOop off=112} > ;*ifnull > ; - java.lang.Class::cast at 1 (line 3253) > ; - java.lang.invoke.InstanceFieldHandle::checkCast at 2 (line 133) > ; - java.lang.invoke.InstanceFieldHandle::set at 19 (line 153) > ; - java.lang.invoke.VarHandle::set at 21 (line 127) > ; - VarHandleTest::testLoopOne at 8 (line 157) > ; {runtime_call} > 0x000000010d050fb0: callq 0x000000010c39d330 ;*ifnull > ; - java.lang.Class::cast at 1 (line 3253) > ; - java.lang.invoke.InstanceFieldHandle::checkCast at 2 (line 133) > ; - java.lang.invoke.InstanceFieldHandle::set at 19 (line 153) > ; - java.lang.invoke.VarHandle::set at 21 (line 127) > ; - VarHandleTest::testLoopOne at 8 (line 157) > ; {runtime_call} > From Lance.Andersen at oracle.com Tue Apr 1 14:11:41 2014 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Tue, 1 Apr 2014 10:11:41 -0400 Subject: RFR 8038653 Time.toLocalTime, Time.valueOf javadoc clarification In-Reply-To: <533ABF80.1040902@oracle.com> References: <904F9535-9D05-4027-BA4A-2EB7251538DB@oracle.com> <533ABF80.1040902@oracle.com> Message-ID: I did not think apiNote was for spec specific clarifications? -- 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 iPhone On Apr 1, 2014, at 9:30 AM, Alan Bateman wrote: > On 01/04/2014 12:35, Lance Andersen wrote: >> HI all, >> >> Looking for a reviewer for the following javadoc clarification when using java.sql.Time.toLocalTime/ValueOf. > The wording looks okay to me, I just wondering whether the "Note" might be better as an @apiNote. > > -Alan. > > From alexander.v.stepanov at oracle.com Tue Apr 1 14:41:32 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Tue, 01 Apr 2014 18:41:32 +0400 Subject: jmx-dev [9] Review Request for 8038795: tidy warnings cleanup for javax.management In-Reply-To: <533AC2B4.8070205@oracle.com> References: <533AB640.4010608@oracle.com> <533AB79F.9060303@oracle.com> <533AC2B4.8070205@oracle.com> Message-ID: <533AD01C.2050209@oracle.com> Hello, Please see the updated webrev here: http://cr.openjdk.java.net/~yan/8038795/webrev.01/ > I just assume the removal of the

isn't really necessary. Yes, probably. That was done just to make tidy happy. Thanks, Alexander On 01.04.2014 17:44, Daniel Fuchs wrote: > Hi Alexander, > > Looks good. > > I think I would remove the leading

in > http://cr.openjdk.java.net/~yan/8038795/webrev.00/src/share/classes/javax/management/remote/JMXPrincipal.java.frames.html > > as well. If you don't please check that the generated javadoc for > JMXPrincipal.java still looks good. > > While you're at it maybe you should remove the strange
  > between the @param tags in > > > > such as: > > 86 *
  > > best regards, > > -- daniel > > > On 4/1/14 2:57 PM, Alan Bateman wrote: >> >> I think you are looking for jmx-dev so forwarding to that list. >> >> On 01/04/2014 13:51, alexander stepanov wrote: >>> Hello, >>> >>> Could you please review the fix for the following bug: >>> https://bugs.openjdk.java.net/browse/JDK-8038795 >>> >>> Webrev corresponding: >>> http://cr.openjdk.java.net/~yan/8038795/webrev.00/ >>> >>> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >>> affected. >>> >>> Thanks. >>> >>> Regards, >>> Alexander >> > From peter.levart at gmail.com Tue Apr 1 14:48:23 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 01 Apr 2014 16:48:23 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533ABE6A.7040308@oracle.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533ABE6A.7040308@oracle.com> Message-ID: <533AD1B7.1020600@gmail.com> On 04/01/2014 03:26 PM, Rob McKenna wrote: > Hi Peter, > > Yup, I'll give this a whirl. > > -Rob Thanks Rob. > > On 01/04/14 14:16, Peter Levart wrote: >> Hi Alan, Volker, >> >> Thanks for sharing the info and for testing on AIX. Here's the >> updated webrev that hopefully includes the correct "dispatch on >> os.name" logic. I included "Solaris" as an alternative to "SunOS" >> since I saw this in some documents on Internet. If this is >> superfluous, I can remove it: I checked the code that obtains the value for os.name system property in current OpenJDK. Here's the relevant part of src/solaris/native/java/lang/java_props_md.c: #ifdef MACOSX setOSNameAndVersion(&sprops); #else struct utsname name; uname(&name); sprops.os_name = strdup(name.sysname); sprops.os_version = strdup(name.release); #endif The uname() system function is used to obtain the OS name on all UNIXes except MACOSX, where a constant "Mac OS X" is used in src/solaris/native/java/lang/java_props_macosx.c: void setOSNameAndVersion(java_props_t *sprops) { /* Don't rely on JRSCopyOSName because there's no guarantee the value will * remain the same, or even if the JRS functions will continue to be part of * Mac OS X. So hardcode os_name, and fill in os_version if we can. */ sprops->os_name = strdup("Mac OS X"); void *jrsFwk = getJRSFramework(); if (jrsFwk != NULL) { char *(*copyOSVersion)() = dlsym(jrsFwk, "JRSCopyOSVersion"); if (copyOSVersion != NULL) { sprops->os_version = copyOSVersion(); return; } } sprops->os_version = strdup("Unknown"); } The value of os.name for Linux is, I belive, always "Linux". The value for AIX is "AIX" and for Mac OS X is fixed to "Max OS X" at compile time. But what about all Solaris(es)? Thinking about OpenSolaris and forks... Would their uname() return "SunOS" too? Regards, Peter >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.03/ >> >> I tested this on Linux and Solaris and the java/lang/ProcessBuilder >> jtreg tests pass. So with Volker's test on AIX, the only OS platform >> left for testing is Mac OS X. Would someone volunteer? >> >> Regards, Peter >> >> On 03/27/2014 11:18 AM, Volker Simonis wrote: >>> Hi Peter, >>> >>> thanks for applying these changes to the AIX files as well. >>> >>> With the additional line: >>> >>> if (osName.equals("AIX")) { return AIX; } >>> >>> in Os.get() your change compiles cleanly on AIX and runs the >>> java/lang/ProcessBuilder tests without any errors. >>> >>> So from an AIX perspective, thumbs up. >>> >>> Regards, >>> Volker >>> >>> >>> On Wed, Mar 26, 2014 at 5:18 PM, Alan Bateman >>> wrote: >>>> On 26/03/2014 15:19, Peter Levart wrote: >>>>> I couldn't find any official document about possible os.name >>>>> values for >>>>> different supported OSes. Does anyone have a pointer? >>>> I don't know if there is a definite list but I assume we don't need >>>> to be >>>> concerned with anything beyond the 4 that we have in OpenJDK, which is >>>> "Linux", "SunOS", "AIX" and contains("OS X"). >>>> >>>> If we get to the point in JDK 9 where src/solaris is renamed to >>>> src/unix (or >>>> something equivalent) then it could mean that the Os enum can be >>>> replaced >>>> with an OS specific class in src/linux, src/solaris, ... and this >>>> would >>>> avoid the need for an os.name check at runtime. >>>> >>>> -Alan. >>>> >> > From luchsh at linux.vnet.ibm.com Tue Apr 1 14:52:27 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 1 Apr 2014 22:52:27 +0800 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Volker, Masayoshi, Thanks a lot for your review, here's the updated patch, could you pls take a look? http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis wrote: > Hi Jonathan, > > thanks for doing this change. Please find some comments below: > > 1. please update the copyright year to 2014 in every file you touch > Updated in new patch. > 2. in CopyFiles.gmk you can simplify the change by joining the windows > and aix cases because on Windows OPENJDK_TARGET_OS is the same like > OPENJDK_TARGET_OS_API_DIR. So you can write: > > ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) > > TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib > > $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings > $(call install-file) > > COPY_FILES += $(LIBDIR)/tzmappings > > endif > I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris' as I observed on my AIX box, solaris/lib is not the directory where tzmappings was stored for AIX. So I'm keeping this change, please fix me if I was wrong about the config. > > 3. regarding the changes proposed by Masayoshi: I agree that we should > put the AIX timezone mapping code in its own function, but I don't > think that getPlatformTimeZoneID() would be the right place. As far as > I understand, getPlatformTimeZoneID() is used to get a platform time > zone id if the environment variable "TZ" is not set. I don't know a > way how this could be done on AIX (@Jonathan: maybe you know?). If > there would be a way to get the time zone from some system files or > so, then we should put this code into the AIX version of > getPlatformTimeZoneID(). > I guess we may try to use /etc/envrionment file, which is basic setting for all processes, see http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm The implementation of getPlatformTimeZoneID() has been updated. > > But the current AIX code contributed by Jonathan, actually uses the > time zone id from the "TZ" environment variable and just maps it to a > Java compatible time zone id. So I'd suggest to refactor this code > into a function like for example "static const char* > mapPlatformToJavaTimzone(const char* tz)" and call that from > findJavaTZ_md(). I think that would make the code easier to > understand. > Agree, and have split the code into a separate static method to do the mapping work. > > @Masayoshi: what do you think, would you agree with such a solution. > > 4. I agree with Masayoshi that you should use the existing getGMTOffsetID() > Updated in new patch to eliminate duplication. > > 5. Please notice that your change breaks all Unix builds except AIX > because of: > > 759 } > 760 tzerr: > 761 if (javatz == NULL) { > 762 time_t offset; > ... > 782 } > 783 #endif > > I think that should read: > > 759 > 760 tzerr: > 761 if (javatz == NULL) { > 762 time_t offset; > ... > 782 } > 783 #endif > 784 } > > Refactoring the code in an extra function will make that error more > evident anyway. > > But please always build at least on one different platform (i.e. > Linux) to prevent such errors in the future. > My fault, sorry for the failure, should take no chance after any manual alteration. > > Regards, > Volker > > > On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu > wrote: > > Hi Jonathan, > > > > The AIX specific code looks OK to me. But I'd suggest the code be moved > to > > getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also > > there's a function for producing a fallback ID in "GMT?hh:mm", > > getGMTOffsetID() which can be called in tzerr. > > > > Thanks, > > Masayoshi > > > > > > On 3/26/2014 3:47 PM, Jonathan Lu wrote: > >> > >> Hi ppc-aix-port-dev, core-libs-dev, > >> > >> Here's a patch for JDK-8034220, > >> > >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ > >> > >> It is trying to add the a more complete timezone mapping mechanism for > AIX > >> platform. > >> the changes are primarily based on IBM's commercial JDK code, which > >> includes: > >> > >> - A new timezone mapping file added under directory jdk/src/aix/lib/ > >> - Code to parse above config file, changed file is > >> src/solaris/native/java/util/TimeZone_md.c > >> - And also makefile change in make/CopyFiles.gmk to copy the config file > >> > >> Could you pls help to review and give comments ? > >> > >> Cheers > >> - Jonathan > > > > > Many thanks Jonathan From daniel.fuchs at oracle.com Tue Apr 1 14:53:47 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 01 Apr 2014 16:53:47 +0200 Subject: jmx-dev [9] Review Request for 8038795: tidy warnings cleanup for javax.management In-Reply-To: <533AD01C.2050209@oracle.com> References: <533AB640.4010608@oracle.com> <533AB79F.9060303@oracle.com> <533AC2B4.8070205@oracle.com> <533AD01C.2050209@oracle.com> Message-ID: <533AD2FB.1020600@oracle.com> On 4/1/14 4:41 PM, alexander stepanov wrote: > Hello, > > Please see the updated webrev here: > http://cr.openjdk.java.net/~yan/8038795/webrev.01/ Thanks Alexander, It looks good! -- daniel > > > I just assume the removal of the

isn't really necessary. > Yes, probably. That was done just to make tidy happy. > > Thanks, > Alexander > > On 01.04.2014 17:44, Daniel Fuchs wrote: >> Hi Alexander, >> >> Looks good. >> >> I think I would remove the leading

in >> http://cr.openjdk.java.net/~yan/8038795/webrev.00/src/share/classes/javax/management/remote/JMXPrincipal.java.frames.html >> >> as well. If you don't please check that the generated javadoc for >> JMXPrincipal.java still looks good. >> >> While you're at it maybe you should remove the strange
  >> between the @param tags in >> >> >> >> such as: >> >> 86 *
  >> >> best regards, >> >> -- daniel >> >> >> On 4/1/14 2:57 PM, Alan Bateman wrote: >>> >>> I think you are looking for jmx-dev so forwarding to that list. >>> >>> On 01/04/2014 13:51, alexander stepanov wrote: >>>> Hello, >>>> >>>> Could you please review the fix for the following bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8038795 >>>> >>>> Webrev corresponding: >>>> http://cr.openjdk.java.net/~yan/8038795/webrev.00/ >>>> >>>> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >>>> affected. >>>> >>>> Thanks. >>>> >>>> Regards, >>>> Alexander >>> >> > From miroslav.kos at oracle.com Tue Apr 1 15:21:34 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Tue, 01 Apr 2014 17:21:34 +0200 Subject: RFR: tests for JDK-8032884 Message-ID: <533AD97E.8080102@oracle.com> Hi everybody, I'd like to ask for review of following tests: http://cr.openjdk.java.net/~mkos/8032884/jdk.01/ Original bug (already fixed): Bug: https://bugs.openjdk.java.net/browse/JDK-8032884 Issue fixing the bug (bulk update): https://bugs.openjdk.java.net/browse/JDK-8036030 The test verifies the source code generated by xjc tool. Thanks Miran From paul.sandoz at oracle.com Tue Apr 1 15:29:31 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Apr 2014 17:29:31 +0200 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <533AC8C4.9080601@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> <6562A055-4B0E-4992-8BF9-A16EFDB09CD6@oracle.com> <533AC8C4.9080601@oracle.com> Message-ID: On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov wrote: > Paul, > > Unfortunately, additional profiling doesn't work for Accessor.checkCast case. The problem is Accessor.checkCast is called from multiple places, so type profile is very likely to be polluted. And it kills the benefits. > So is there any point in doing such a cast in this case? The type performing the cast is the field type declared as a parameter in the MethodType of the MethodHandle and also held by the Accessor. IIUC the Invokers.checkExactType should ensure no "unsavoury" instances of the wrong type gets through? (the holder instance is only checked for null, via checkBase). > I don't think MethodType helps with profiling in any way. It represents type info which is necessary for correctness checks. Profiling collects more fine-grained information (e.g. exact types, values). > OK. > Regarding redundant null check, do you have a test case so I can play with it myself? > I will send something to you later today or tomorrow. Paul. From paul.sandoz at oracle.com Tue Apr 1 15:42:37 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Apr 2014 17:42:37 +0200 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <533AC5CF.5060404@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> <53305D76.7080009@oracle.com> <15133BFB-B289-41AE-A530-1D34FC64EF72@oracle.com> <533AC5CF.5060404@oracle.com> Message-ID: On Apr 1, 2014, at 3:57 PM, Vladimir Ivanov wrote: > Paul, thanks for review. > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8037210/webrev.04/ > +1 Paul. From peter.levart at gmail.com Tue Apr 1 15:43:47 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 01 Apr 2014 17:43:47 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533AC3E9.3060406@oracle.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> Message-ID: <533ADEB3.2040306@gmail.com> On 04/01/2014 03:49 PM, roger riggs wrote: > Hi Peter, > > The design using enum for the os dependencies does not make it possible > to include only the support needed for a particular platform at build > time. > Every implementation will be carrying around the support for all the > other platforms. > A build time binding would be more efficient. > > Roger That's true. A trade-off between maintainability and efficiency. The efficiency has two categories here. One is the size of the distributable and the other is run-time efficiency. I've been thinking to improve both efficiencies (the run-time in particular) with a little re-design. Since nearly each OS platform requires a sub-class of UNIXProcess to implement the differences, I can move the implementations of various methods now in Os enum to the UNIXProcess subclasses and get rid of Os enum per-instance subclasses. Let me try this and see what comes out. Regards, Peter > > > > On 4/1/2014 9:16 AM, Peter Levart wrote: >> Hi Alan, Volker, >> >> Thanks for sharing the info and for testing on AIX. Here's the >> updated webrev that hopefully includes the correct "dispatch on >> os.name" logic. I included "Solaris" as an alternative to "SunOS" >> since I saw this in some documents on Internet. If this is >> superfluous, I can remove it: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.03/ >> >> I tested this on Linux and Solaris and the java/lang/ProcessBuilder >> jtreg tests pass. So with Volker's test on AIX, the only OS platform >> left for testing is Mac OS X. Would someone volunteer? >> >> Regards, Peter >> >> On 03/27/2014 11:18 AM, Volker Simonis wrote: >>> Hi Peter, >>> >>> thanks for applying these changes to the AIX files as well. >>> >>> With the additional line: >>> >>> if (osName.equals("AIX")) { return AIX; } >>> >>> in Os.get() your change compiles cleanly on AIX and runs the >>> java/lang/ProcessBuilder tests without any errors. >>> >>> So from an AIX perspective, thumbs up. >>> >>> Regards, >>> Volker >>> >>> >>> On Wed, Mar 26, 2014 at 5:18 PM, Alan Bateman >>> wrote: >>>> On 26/03/2014 15:19, Peter Levart wrote: >>>>> I couldn't find any official document about possible os.name >>>>> values for >>>>> different supported OSes. Does anyone have a pointer? >>>> I don't know if there is a definite list but I assume we don't need >>>> to be >>>> concerned with anything beyond the 4 that we have in OpenJDK, which is >>>> "Linux", "SunOS", "AIX" and contains("OS X"). >>>> >>>> If we get to the point in JDK 9 where src/solaris is renamed to >>>> src/unix (or >>>> something equivalent) then it could mean that the Os enum can be >>>> replaced >>>> with an OS specific class in src/linux, src/solaris, ... and this >>>> would >>>> avoid the need for an os.name check at runtime. >>>> >>>> -Alan. >>>> >> > From vladimir.x.ivanov at oracle.com Tue Apr 1 15:47:34 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 01 Apr 2014 19:47:34 +0400 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> <53305D76.7080009@oracle.com> <15133BFB-B289-41AE-A530-1D34FC64EF72@oracle.com> <533AC5CF.5060404@oracle.com> Message-ID: <533ADF96.4010602@oracle.com> Thank you, Paul. Best regards, Vladimir Ivanov On 4/1/14 7:42 PM, Paul Sandoz wrote: > > On Apr 1, 2014, at 3:57 PM, Vladimir Ivanov wrote: > >> Paul, thanks for review. >> >> Updated webrev: >> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.04/ >> > > +1 > > Paul. > From rob.mckenna at oracle.com Tue Apr 1 15:51:57 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 01 Apr 2014 16:51:57 +0100 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533ADEB3.2040306@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> Message-ID: <533AE09D.90803@oracle.com> Mac OSX testing was clean. -Rob On 01/04/14 16:43, Peter Levart wrote: > On 04/01/2014 03:49 PM, roger riggs wrote: >> Hi Peter, >> >> The design using enum for the os dependencies does not make it possible >> to include only the support needed for a particular platform at build >> time. >> Every implementation will be carrying around the support for all the >> other platforms. >> A build time binding would be more efficient. >> >> Roger > > That's true. A trade-off between maintainability and efficiency. The > efficiency has two categories here. One is the size of the > distributable and the other is run-time efficiency. I've been thinking > to improve both efficiencies (the run-time in particular) with a > little re-design. Since nearly each OS platform requires a sub-class > of UNIXProcess to implement the differences, I can move the > implementations of various methods now in Os enum to the UNIXProcess > subclasses and get rid of Os enum per-instance subclasses. > > Let me try this and see what comes out. > > Regards, Peter > >> >> >> >> On 4/1/2014 9:16 AM, Peter Levart wrote: >>> Hi Alan, Volker, >>> >>> Thanks for sharing the info and for testing on AIX. Here's the >>> updated webrev that hopefully includes the correct "dispatch on >>> os.name" logic. I included "Solaris" as an alternative to "SunOS" >>> since I saw this in some documents on Internet. If this is >>> superfluous, I can remove it: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.03/ >>> >>> I tested this on Linux and Solaris and the java/lang/ProcessBuilder >>> jtreg tests pass. So with Volker's test on AIX, the only OS platform >>> left for testing is Mac OS X. Would someone volunteer? >>> >>> Regards, Peter >>> >>> On 03/27/2014 11:18 AM, Volker Simonis wrote: >>>> Hi Peter, >>>> >>>> thanks for applying these changes to the AIX files as well. >>>> >>>> With the additional line: >>>> >>>> if (osName.equals("AIX")) { return AIX; } >>>> >>>> in Os.get() your change compiles cleanly on AIX and runs the >>>> java/lang/ProcessBuilder tests without any errors. >>>> >>>> So from an AIX perspective, thumbs up. >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Wed, Mar 26, 2014 at 5:18 PM, Alan Bateman >>>> wrote: >>>>> On 26/03/2014 15:19, Peter Levart wrote: >>>>>> I couldn't find any official document about possible os.name >>>>>> values for >>>>>> different supported OSes. Does anyone have a pointer? >>>>> I don't know if there is a definite list but I assume we don't >>>>> need to be >>>>> concerned with anything beyond the 4 that we have in OpenJDK, >>>>> which is >>>>> "Linux", "SunOS", "AIX" and contains("OS X"). >>>>> >>>>> If we get to the point in JDK 9 where src/solaris is renamed to >>>>> src/unix (or >>>>> something equivalent) then it could mean that the Os enum can be >>>>> replaced >>>>> with an OS specific class in src/linux, src/solaris, ... and this >>>>> would >>>>> avoid the need for an os.name check at runtime. >>>>> >>>>> -Alan. >>>>> >>> >> > From Alan.Bateman at oracle.com Tue Apr 1 16:00:08 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Apr 2014 17:00:08 +0100 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533AC3E9.3060406@oracle.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> Message-ID: <533AE288.90705@oracle.com> On 01/04/2014 14:49, roger riggs wrote: > Hi Peter, > > The design using enum for the os dependencies does not make it possible > to include only the support needed for a particular platform at build > time. > Every implementation will be carrying around the support for all the > other platforms. > A build time binding would be more efficient. > > Roger I think the approach is okay for now [ assuming we find a better name than "Os" :-) ] but if src/solaris is renamed in JDK 9 to src/unix or some such name then it provides an opportunity to re-visit this is that there is a factory per platform in a platform specific tree. -Alan From vladimir.x.ivanov at oracle.com Tue Apr 1 16:21:10 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 01 Apr 2014 20:21:10 +0400 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> <6562A055-4B0E-4992-8BF9-A16EFDB09CD6@oracle.com> <533AC8C4.9080601@oracle.com> Message-ID: <533AE776.20209@oracle.com> Best regards, Vladimir Ivanov On 4/1/14 7:29 PM, Paul Sandoz wrote: > > On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov wrote: > >> Paul, >> >> Unfortunately, additional profiling doesn't work for Accessor.checkCast case. The problem is Accessor.checkCast is called from multiple places, so type profile is very likely to be polluted. And it kills the benefits. >> > > So is there any point in doing such a cast in this case? > > The type performing the cast is the field type declared as a parameter in the MethodType of the MethodHandle and also held by the Accessor. > > IIUC the Invokers.checkExactType should ensure no "unsavoury" instances of the wrong type gets through? (the holder instance is only checked for null, via checkBase). I don't see any point in doing profiling for this particular case. Such shape should be well optimized by JIT if it sees that an instance of Accessor is a constant. As I understand, it should be the case for most of the usage scenarios. Best regards, Vladimir Ivanov > > >> I don't think MethodType helps with profiling in any way. It represents type info which is necessary for correctness checks. Profiling collects more fine-grained information (e.g. exact types, values). >> > > OK. > > >> Regarding redundant null check, do you have a test case so I can play with it myself? >> > > I will send something to you later today or tomorrow. > > Paul. > From guy.steele at oracle.com Tue Apr 1 16:37:21 2014 From: guy.steele at oracle.com (Guy Steele) Date: Tue, 1 Apr 2014 12:37:21 -0400 Subject: Implicit 'this' return for void methods In-Reply-To: <533AA25E.9060507@CoSoCo.de> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> <533AA25E.9060507@CoSoCo.de> Message-ID: Then it sounds as if the three of us, at least, are very much in agreement about what is the appropriate scope for such a ?naked dot? feature. ?Guy On Apr 1, 2014, at 7:26 AM, Ulf Zibis wrote: > > Am 01.04.2014 11:28, schrieb Bruce Chapman: >> Slightly preceding Ulf's coin proposal by a few hours was >> >> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html >> >> Where I suggested the "naked dot" notation (coined in http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html) has better value as ".. a >> syntax for referring to the receiver of a method inside arguments to the >> method." >> >> More formally, the naked dot (at the start of an expression, not following an invocation to a void method) would refer to the receiver of the innermost surrounding invocation expression. >> >> and so to answer Guy's question below in terms of my original intention rather than Ulf's proposal, .indexof("Q") would use myVeryLongNamedString as its receiver. > > +1 > My proposal was meant exactly as that. Maybe my wording was not clear enough in that. > > -Ulf > From chris.hegarty at oracle.com Tue Apr 1 16:50:28 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 1 Apr 2014 17:50:28 +0100 Subject: RFR: tests for JDK-8032884 In-Reply-To: <533AD97E.8080102@oracle.com> References: <533AD97E.8080102@oracle.com> Message-ID: <8E460A98-F87F-48A0-A6DB-9320081054CC@oracle.com> The tests looks fine to me. Trivially, you could eliminate the shell script and run xic from ProcessBuilder? Also, does it make sense to move the test to jdk/test/javax/xml/ws/xjc? With the other jaxws tests, or is xjc different. -Chris,. On 1 Apr 2014, at 16:21, Miroslav Kos wrote: > Hi everybody, > > I'd like to ask for review of following tests: > http://cr.openjdk.java.net/~mkos/8032884/jdk.01/ > > Original bug (already fixed): Bug: https://bugs.openjdk.java.net/browse/JDK-8032884 > Issue fixing the bug (bulk update): https://bugs.openjdk.java.net/browse/JDK-8036030 > > The test verifies the source code generated by xjc tool. > > Thanks > Miran From peter.levart at gmail.com Tue Apr 1 17:04:26 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 01 Apr 2014 19:04:26 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533ADEB3.2040306@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> Message-ID: <533AF19A.1060709@gmail.com> On 04/01/2014 05:43 PM, Peter Levart wrote: > On 04/01/2014 03:49 PM, roger riggs wrote: >> Hi Peter, >> >> The design using enum for the os dependencies does not make it possible >> to include only the support needed for a particular platform at build >> time. >> Every implementation will be carrying around the support for all the >> other platforms. >> A build time binding would be more efficient. >> >> Roger > > That's true. A trade-off between maintainability and efficiency. The > efficiency has two categories here. One is the size of the > distributable and the other is run-time efficiency. I've been thinking > to improve both efficiencies (the run-time in particular) with a > little re-design. Since nearly each OS platform requires a sub-class > of UNIXProcess to implement the differences, I can move the > implementations of various methods now in Os enum to the UNIXProcess > subclasses and get rid of Os enum per-instance subclasses. > > Let me try this and see what comes out. Hi Roger, Well, it turns out the methods would like to stay in Os (renamed to Platform), but there is no need for per-enum-instance subclasses. Using enum constructor parameters and switch statements makes code even more compact and easy to follow... http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.04/ I belive there is still room for consolidating logic in various Input/OutputStream wrappers used in UNIXProcess variants. But in the first round I tried to preserve the exact behaviour. If the wrapping of streams could be made more-or-less equal in all UNIX platforms, then the need for UNIXProcess subclasses and/or overhead of support classes included but not used goes away... Regards, Peter > >> >> >> >> On 4/1/2014 9:16 AM, Peter Levart wrote: >>> Hi Alan, Volker, >>> >>> Thanks for sharing the info and for testing on AIX. Here's the >>> updated webrev that hopefully includes the correct "dispatch on >>> os.name" logic. I included "Solaris" as an alternative to "SunOS" >>> since I saw this in some documents on Internet. If this is >>> superfluous, I can remove it: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.03/ >>> >>> I tested this on Linux and Solaris and the java/lang/ProcessBuilder >>> jtreg tests pass. So with Volker's test on AIX, the only OS platform >>> left for testing is Mac OS X. Would someone volunteer? >>> >>> Regards, Peter >>> >>> On 03/27/2014 11:18 AM, Volker Simonis wrote: >>>> Hi Peter, >>>> >>>> thanks for applying these changes to the AIX files as well. >>>> >>>> With the additional line: >>>> >>>> if (osName.equals("AIX")) { return AIX; } >>>> >>>> in Os.get() your change compiles cleanly on AIX and runs the >>>> java/lang/ProcessBuilder tests without any errors. >>>> >>>> So from an AIX perspective, thumbs up. >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Wed, Mar 26, 2014 at 5:18 PM, Alan Bateman >>>> wrote: >>>>> On 26/03/2014 15:19, Peter Levart wrote: >>>>>> I couldn't find any official document about possible os.name >>>>>> values for >>>>>> different supported OSes. Does anyone have a pointer? >>>>> I don't know if there is a definite list but I assume we don't >>>>> need to be >>>>> concerned with anything beyond the 4 that we have in OpenJDK, >>>>> which is >>>>> "Linux", "SunOS", "AIX" and contains("OS X"). >>>>> >>>>> If we get to the point in JDK 9 where src/solaris is renamed to >>>>> src/unix (or >>>>> something equivalent) then it could mean that the Os enum can be >>>>> replaced >>>>> with an OS specific class in src/linux, src/solaris, ... and this >>>>> would >>>>> avoid the need for an os.name check at runtime. >>>>> >>>>> -Alan. >>>>> >>> >> > From peter.levart at gmail.com Tue Apr 1 17:05:17 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 01 Apr 2014 19:05:17 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533AE09D.90803@oracle.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AE09D.90803@oracle.com> Message-ID: <533AF1CD.90609@gmail.com> On 04/01/2014 05:51 PM, Rob McKenna wrote: > Mac OSX testing was clean. > > -Rob Thanks again Rob. Regards, Peter > > On 01/04/14 16:43, Peter Levart wrote: >> On 04/01/2014 03:49 PM, roger riggs wrote: >>> Hi Peter, >>> >>> The design using enum for the os dependencies does not make it possible >>> to include only the support needed for a particular platform at >>> build time. >>> Every implementation will be carrying around the support for all the >>> other platforms. >>> A build time binding would be more efficient. >>> >>> Roger >> >> That's true. A trade-off between maintainability and efficiency. The >> efficiency has two categories here. One is the size of the >> distributable and the other is run-time efficiency. I've been >> thinking to improve both efficiencies (the run-time in particular) >> with a little re-design. Since nearly each OS platform requires a >> sub-class of UNIXProcess to implement the differences, I can move the >> implementations of various methods now in Os enum to the UNIXProcess >> subclasses and get rid of Os enum per-instance subclasses. >> >> Let me try this and see what comes out. >> >> Regards, Peter >> >>> >>> >>> >>> On 4/1/2014 9:16 AM, Peter Levart wrote: >>>> Hi Alan, Volker, >>>> >>>> Thanks for sharing the info and for testing on AIX. Here's the >>>> updated webrev that hopefully includes the correct "dispatch on >>>> os.name" logic. I included "Solaris" as an alternative to "SunOS" >>>> since I saw this in some documents on Internet. If this is >>>> superfluous, I can remove it: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.03/ >>>> >>>> I tested this on Linux and Solaris and the java/lang/ProcessBuilder >>>> jtreg tests pass. So with Volker's test on AIX, the only OS >>>> platform left for testing is Mac OS X. Would someone volunteer? >>>> >>>> Regards, Peter >>>> >>>> On 03/27/2014 11:18 AM, Volker Simonis wrote: >>>>> Hi Peter, >>>>> >>>>> thanks for applying these changes to the AIX files as well. >>>>> >>>>> With the additional line: >>>>> >>>>> if (osName.equals("AIX")) { return AIX; } >>>>> >>>>> in Os.get() your change compiles cleanly on AIX and runs the >>>>> java/lang/ProcessBuilder tests without any errors. >>>>> >>>>> So from an AIX perspective, thumbs up. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Wed, Mar 26, 2014 at 5:18 PM, Alan Bateman >>>>> wrote: >>>>>> On 26/03/2014 15:19, Peter Levart wrote: >>>>>>> I couldn't find any official document about possible os.name >>>>>>> values for >>>>>>> different supported OSes. Does anyone have a pointer? >>>>>> I don't know if there is a definite list but I assume we don't >>>>>> need to be >>>>>> concerned with anything beyond the 4 that we have in OpenJDK, >>>>>> which is >>>>>> "Linux", "SunOS", "AIX" and contains("OS X"). >>>>>> >>>>>> If we get to the point in JDK 9 where src/solaris is renamed to >>>>>> src/unix (or >>>>>> something equivalent) then it could mean that the Os enum can be >>>>>> replaced >>>>>> with an OS specific class in src/linux, src/solaris, ... and this >>>>>> would >>>>>> avoid the need for an os.name check at runtime. >>>>>> >>>>>> -Alan. >>>>>> >>>> >>> >> > From david.lloyd at redhat.com Tue Apr 1 17:23:16 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 01 Apr 2014 12:23:16 -0500 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533AF19A.1060709@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> Message-ID: <533AF604.4060609@redhat.com> On 04/01/2014 12:04 PM, Peter Levart wrote: > On 04/01/2014 05:43 PM, Peter Levart wrote: >> On 04/01/2014 03:49 PM, roger riggs wrote: >>> Hi Peter, >>> >>> The design using enum for the os dependencies does not make it possible >>> to include only the support needed for a particular platform at build >>> time. >>> Every implementation will be carrying around the support for all the >>> other platforms. >>> A build time binding would be more efficient. >>> >>> Roger >> >> That's true. A trade-off between maintainability and efficiency. The >> efficiency has two categories here. One is the size of the >> distributable and the other is run-time efficiency. I've been thinking >> to improve both efficiencies (the run-time in particular) with a >> little re-design. Since nearly each OS platform requires a sub-class >> of UNIXProcess to implement the differences, I can move the >> implementations of various methods now in Os enum to the UNIXProcess >> subclasses and get rid of Os enum per-instance subclasses. >> >> Let me try this and see what comes out. > > Hi Roger, > > Well, it turns out the methods would like to stay in Os (renamed to > Platform), but there is no need for per-enum-instance subclasses. Using > enum constructor parameters and switch statements makes code even more > compact and easy to follow... Is the concern source classes or compiled classes? IIRC every switch-on-enum produces an additional .class file. -- - DML From roger.riggs at oracle.com Tue Apr 1 19:47:22 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 01 Apr 2014 15:47:22 -0400 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533AF19A.1060709@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> Message-ID: <533B17CA.6030203@oracle.com> Hi, A minor point, but the Enum for LaunchMechanism can be simpler; the defined enum values (1,2,3) are never used and can be removed along with the extra constructor. With the refactoring so f0ar, this seems more complex and harder to understand. At least in the non-merged version all (and only) the code for a platform was in a single class. The static UNIXProcess subclasses for the various platforms are always kept around. Other alternatives would have been to factor the common code (Streams handling) into a utilities class or ProcessImpl and retain the 1st class subclasses (with different names) for each platform or merge more up into ProcessImpl. Maybe it will be clearer with additional refactoring. $.02, Roger On 4/1/2014 1:04 PM, Peter Levart wrote: > On 04/01/2014 05:43 PM, Peter Levart wrote: >> On 04/01/2014 03:49 PM, roger riggs wrote: >>> Hi Peter, >>> >>> The design using enum for the os dependencies does not make it possible >>> to include only the support needed for a particular platform at >>> build time. >>> Every implementation will be carrying around the support for all the >>> other platforms. >>> A build time binding would be more efficient. >>> >>> Roger >> >> That's true. A trade-off between maintainability and efficiency. The >> efficiency has two categories here. One is the size of the >> distributable and the other is run-time efficiency. I've been >> thinking to improve both efficiencies (the run-time in particular) >> with a little re-design. Since nearly each OS platform requires a >> sub-class of UNIXProcess to implement the differences, I can move the >> implementations of various methods now in Os enum to the UNIXProcess >> subclasses and get rid of Os enum per-instance subclasses. >> >> Let me try this and see what comes out. > > Hi Roger, > > Well, it turns out the methods would like to stay in Os (renamed to > Platform), but there is no need for per-enum-instance subclasses. > Using enum constructor parameters and switch statements makes code > even more compact and easy to follow... > > http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.04/ > > > I belive there is still room for consolidating logic in various > Input/OutputStream wrappers used in UNIXProcess variants. But in the > first round I tried to preserve the exact behaviour. If the wrapping > of streams could be made more-or-less equal in all UNIX platforms, > then the need for UNIXProcess subclasses and/or overhead of support > classes included but not used goes away... > > Regards, Peter > >> >>> >>> >>> >>> On 4/1/2014 9:16 AM, Peter Levart wrote: >>>> Hi Alan, Volker, >>>> >>>> Thanks for sharing the info and for testing on AIX. Here's the >>>> updated webrev that hopefully includes the correct "dispatch on >>>> os.name" logic. I included "Solaris" as an alternative to "SunOS" >>>> since I saw this in some documents on Internet. If this is >>>> superfluous, I can remove it: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.03/ >>>> >>>> I tested this on Linux and Solaris and the java/lang/ProcessBuilder >>>> jtreg tests pass. So with Volker's test on AIX, the only OS >>>> platform left for testing is Mac OS X. Would someone volunteer? >>>> >>>> Regards, Peter >>>> >>>> On 03/27/2014 11:18 AM, Volker Simonis wrote: >>>>> Hi Peter, >>>>> >>>>> thanks for applying these changes to the AIX files as well. >>>>> >>>>> With the additional line: >>>>> >>>>> if (osName.equals("AIX")) { return AIX; } >>>>> >>>>> in Os.get() your change compiles cleanly on AIX and runs the >>>>> java/lang/ProcessBuilder tests without any errors. >>>>> >>>>> So from an AIX perspective, thumbs up. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Wed, Mar 26, 2014 at 5:18 PM, Alan Bateman >>>>> wrote: >>>>>> On 26/03/2014 15:19, Peter Levart wrote: >>>>>>> I couldn't find any official document about possible os.name >>>>>>> values for >>>>>>> different supported OSes. Does anyone have a pointer? >>>>>> I don't know if there is a definite list but I assume we don't >>>>>> need to be >>>>>> concerned with anything beyond the 4 that we have in OpenJDK, >>>>>> which is >>>>>> "Linux", "SunOS", "AIX" and contains("OS X"). >>>>>> >>>>>> If we get to the point in JDK 9 where src/solaris is renamed to >>>>>> src/unix (or >>>>>> something equivalent) then it could mean that the Os enum can be >>>>>> replaced >>>>>> with an OS specific class in src/linux, src/solaris, ... and this >>>>>> would >>>>>> avoid the need for an os.name check at runtime. >>>>>> >>>>>> -Alan. >>>>>> >>>> >>> >> > From eirik.lygre at gmail.com Tue Apr 1 21:20:34 2014 From: eirik.lygre at gmail.com (Eirik Lygre) Date: Tue, 1 Apr 2014 23:20:34 +0200 Subject: Implicit 'this' return for void methods In-Reply-To: References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> <533AA25E.9060507@CoSoCo.de> Message-ID: On Tue, Apr 1, 2014 at 6:37 PM, Guy Steele wrote: > Then it sounds as if the three of us, at least, are very much in agreement > about what is the appropriate scope for such a "naked dot" feature. > > > Am 01.04.2014 11:28, schrieb Bruce Chapman: > >> More formally, the naked dot (at the start of an expression, not > following an invocation to a void method) would refer to the receiver of > the innermost surrounding invocation expression. > >> > >> and so to answer Guy's question below in terms of my original intention > rather than Ulf's proposal, .indexof("Q") would use myVeryLongNamedString > as its receiver. > > > > My proposal was meant exactly as that. Maybe my wording was not clear > enough in that. > > -Ulf > > > > What is the relationship between this "naked dot" proposal and the "chaining of void methods" proposal? The reason for asking is not to be negative, but rather to find out if these issues are best dealt with together, or as independent proposals. I think that if either of these are going to happen, then they must be specified with the appropriate level of isolation: That which belongs together must be processed together; that which belongs apart must be processed apart. From martinrb at google.com Tue Apr 1 22:40:49 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 1 Apr 2014 15:40:49 -0700 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533B17CA.6030203@oracle.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> Message-ID: In general, you can expect different LaunchMechanisms to be workable for different Unix flavors at different times. It would be good to have them available via a flag for future maintainability. E.g. if vfork ends up being as troublesome as everyone says, we can fall back for fork, etc... So I rather like having different LaunchMechanisms available on different platforms - just the default would be different. fork should work everywhere. On Tue, Apr 1, 2014 at 12:47 PM, roger riggs wrote: > Hi, > > A minor point, but the Enum for LaunchMechanism can be simpler; the > defined enum values (1,2,3) > are never used and can be removed along with the extra constructor. > > From joe.darcy at oracle.com Tue Apr 1 23:20:43 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 01 Apr 2014 16:20:43 -0700 Subject: JDK 9 RFR of 8039022: Fix serial lint warnings in sun.tools.java Message-ID: <533B49CB.3040104@oracle.com> Hello, The plague of serial warnings in the jdk repo is nearly eradicated. Please review the fix below if address to a few of the holdouts. Thanks, -Joe diff -r b6997dd0667e src/share/classes/sun/tools/java/AmbiguousClass.java --- a/src/share/classes/sun/tools/java/AmbiguousClass.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/java/AmbiguousClass.java Tue Apr 01 16:19:44 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1994, 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2014, 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 @@ -34,6 +34,7 @@ * they are subject to change or removal without notice. */ + at SuppressWarnings("serial") // JDK implementation class public class AmbiguousClass extends ClassNotFound { /** diff -r b6997dd0667e src/share/classes/sun/tools/java/AmbiguousMember.java --- a/src/share/classes/sun/tools/java/AmbiguousMember.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/java/AmbiguousMember.java Tue Apr 01 16:19:44 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1994, 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2014, 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 @@ -35,6 +35,7 @@ * supported API. Code that depends on them does so at its own risk: * they are subject to change or removal without notice. */ + at SuppressWarnings("serial") // JDK implementation class public class AmbiguousMember extends Exception { /** diff -r b6997dd0667e src/share/classes/sun/tools/java/ClassNotFound.java --- a/src/share/classes/sun/tools/java/ClassNotFound.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/java/ClassNotFound.java Tue Apr 01 16:19:44 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1994, 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2014, 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 @@ -33,6 +33,7 @@ * supported API. Code that depends on them does so at its own risk: * they are subject to change or removal without notice. */ + at SuppressWarnings("serial") // JDK implementation class public class ClassNotFound extends Exception { /** diff -r b6997dd0667e src/share/classes/sun/tools/java/CompilerError.java --- a/src/share/classes/sun/tools/java/CompilerError.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/java/CompilerError.java Tue Apr 01 16:19:44 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1994, 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2014, 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 @@ -32,7 +32,7 @@ * supported API. Code that depends on them does so at its own risk: * they are subject to change or removal without notice. */ - + at SuppressWarnings("serial") // JDK implementation class public class CompilerError extends Error { Throwable e; diff -r b6997dd0667e src/share/classes/sun/tools/java/SyntaxError.java --- a/src/share/classes/sun/tools/java/SyntaxError.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/java/SyntaxError.java Tue Apr 01 16:19:44 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1994, 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2014, 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 @@ -33,7 +33,7 @@ * supported API. Code that depends on them does so at its own risk: * they are subject to change or removal without notice. */ - + at SuppressWarnings("serial") // JDK implementation class public class SyntaxError extends Exception { } From joe.darcy at oracle.com Wed Apr 2 01:20:35 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 01 Apr 2014 18:20:35 -0700 Subject: JDK 9 RFR of 8039027: Fix serial lint warnings in jconsole and jstat Message-ID: <533B65E3.6090903@oracle.com> Hello, With the serial warnings cleanup of the JDK drawing to completion, please review the patch below which addresses some lingering issues in jconsole and jstat. Thanks, -Joe diff -r b6997dd0667e src/share/classes/sun/tools/jconsole/Tab.java --- a/src/share/classes/sun/tools/jconsole/Tab.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/Tab.java Tue Apr 01 18:20:03 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2014, 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 @@ -28,6 +28,7 @@ import java.awt.*; import javax.swing.*; + at SuppressWarnings("serial") // JDK implementation class public abstract class Tab extends JPanel { private String name; private Worker worker; diff -r b6997dd0667e src/share/classes/sun/tools/jconsole/inspector/XOperations.java --- a/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Tue Apr 01 18:20:03 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2014, 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 @@ -39,6 +39,7 @@ import sun.tools.jconsole.JConsole; import sun.tools.jconsole.Messages; + at SuppressWarnings("serial") // JDK implementation class public abstract class XOperations extends JPanel implements ActionListener { public final static String OPERATION_INVOCATION_EVENT = diff -r b6997dd0667e src/share/classes/sun/tools/jconsole/inspector/XTable.java --- a/src/share/classes/sun/tools/jconsole/inspector/XTable.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/XTable.java Tue Apr 01 18:20:03 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2014, 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 @@ -33,6 +33,7 @@ import javax.swing.table.DefaultTableModel; import javax.swing.table.TableCellRenderer; + at SuppressWarnings("serial") // JDK implementation class public abstract class XTable extends JTable { static final int NAME_COLUMN = 0; static final int VALUE_COLUMN = 1; diff -r b6997dd0667e src/share/classes/sun/tools/jstat/ParserException.java --- a/src/share/classes/sun/tools/jstat/ParserException.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/jstat/ParserException.java Tue Apr 01 18:20:03 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2014, 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 @@ -31,6 +31,7 @@ * @author Brian Doherty * @since 1.5 */ + at SuppressWarnings("serial") // JDK implementation class public class ParserException extends Exception { public ParserException() { diff -r b6997dd0667e src/share/classes/sun/tools/jstat/SyntaxException.java --- a/src/share/classes/sun/tools/jstat/SyntaxException.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/jstat/SyntaxException.java Tue Apr 01 18:20:03 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2014, 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 @@ -36,6 +36,7 @@ * @author Brian Doherty * @since 1.5 */ + at SuppressWarnings("serial") // JDK implementation class public class SyntaxException extends ParserException { private String message; From joe.darcy at oracle.com Wed Apr 2 06:39:39 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 01 Apr 2014 23:39:39 -0700 Subject: JDK 9 RFR of JDK-8039038: Fix serial lint warnings in com.sun.jmx.snmp Message-ID: <533BB0AB.8010802@oracle.com> Hello, *fingers crossed* The patch below should be the last change needed to fully clear the JDK 9 jdk repo of serialization warnings. Thanks, -Joe diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/Enumerated.java --- a/src/share/classes/com/sun/jmx/snmp/Enumerated.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/Enumerated.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2014, 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 @@ -45,7 +45,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class abstract public class Enumerated implements Serializable { /** diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, 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 @@ -44,6 +44,7 @@ * The class defines an abstract representation of a host. * */ + at SuppressWarnings("serial") // JDK implementation class abstract class Host extends SimpleNode implements Serializable { public Host(int id) { diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpPdu.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpPdu.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpPdu.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2014, 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 @@ -45,6 +45,7 @@ * * @since 1.5 */ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpPdu implements SnmpDefinitions, Serializable { /** diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2014, 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 @@ -47,6 +47,7 @@ * * @since 1.5 */ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpScopedPduPacket extends SnmpPdu implements Serializable { /** diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, 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 @@ -34,7 +34,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpUnsignedInt extends SnmpInt { /** diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpValue.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpValue.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpValue.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, 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 @@ -38,7 +38,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpValue implements Cloneable, Serializable, SnmpDataTypeEnums { /** diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, 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 @@ -59,6 +59,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpMib extends SnmpMibAgent implements Serializable { /** diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2014, 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 @@ -59,7 +59,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpMibAgent implements SnmpMibAgentMBean, MBeanRegistration, Serializable { diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2014, 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 @@ -41,7 +41,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpMibEntry extends SnmpMibNode implements Serializable { diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2014, 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 @@ -49,7 +49,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpMibGroup extends SnmpMibOid implements Serializable { diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, 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 @@ -53,7 +53,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpMibNode implements Serializable { // --------------------------------------------------------------------- diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, 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 @@ -84,7 +84,7 @@ * @see com.sun.jmx.snmp.agent.SnmpTableSupport * */ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpMibTable extends SnmpMibNode implements NotificationBroadcaster, Serializable { diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2014, 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 @@ -80,6 +80,7 @@ * @see com.sun.jmx.snmp.agent.SnmpMibTable * */ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpTableSupport implements SnmpTableEntryFactory, // NPCTE fix for bugId 4499265, esc 0, MR 04 sept 2001 // SnmpTableCallbackHandler { diff -r b6997dd0667e src/share/classes/sun/management/snmp/util/SnmpListTableCache.java --- a/src/share/classes/sun/management/snmp/util/SnmpListTableCache.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/management/snmp/util/SnmpListTableCache.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2014, 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 @@ -43,6 +43,7 @@ *

NOTE: This class is not synchronized, subclasses must implement * the appropriate synchronization whwn needed.

**/ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpListTableCache extends SnmpTableCache { diff -r b6997dd0667e src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java --- a/src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2014, 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 @@ -49,6 +49,7 @@ *

NOTE: This class is not synchronized, subclasses must implement * the appropriate synchronization whwn needed.

**/ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpNamedListTableCache extends SnmpListTableCache { /** diff -r b6997dd0667e src/share/classes/sun/management/snmp/util/SnmpTableCache.java --- a/src/share/classes/sun/management/snmp/util/SnmpTableCache.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/management/snmp/util/SnmpTableCache.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2014, 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 @@ -45,6 +45,7 @@ *

NOTE: This class is not synchronized, subclasses must implement * the appropriate synchronization when needed.

**/ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpTableCache implements Serializable { /** From Alan.Bateman at oracle.com Wed Apr 2 07:30:18 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Apr 2014 08:30:18 +0100 Subject: JDK 9 RFR of 8039022: Fix serial lint warnings in sun.tools.java In-Reply-To: <533B49CB.3040104@oracle.com> References: <533B49CB.3040104@oracle.com> Message-ID: <533BBC8A.5090708@oracle.com> On 02/04/2014 00:20, Joe Darcy wrote: > Hello, > > The plague of serial warnings in the jdk repo is nearly eradicated. > Please review the fix below if address to a few of the holdouts. > This looks okay, assuming of course that none of these types leak into the serialized form by some other means. -Alan. From Alan.Bateman at oracle.com Wed Apr 2 07:31:06 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Apr 2014 08:31:06 +0100 Subject: JDK 9 RFR of 8039027: Fix serial lint warnings in jconsole and jstat In-Reply-To: <533B65E3.6090903@oracle.com> References: <533B65E3.6090903@oracle.com> Message-ID: <533BBCBA.9010301@oracle.com> On 02/04/2014 02:20, Joe Darcy wrote: > Hello, > > With the serial warnings cleanup of the JDK drawing to completion, > please review the patch below which addresses some lingering issues in > jconsole and jstat. This looks okay too. -Alan From Alan.Bateman at oracle.com Wed Apr 2 07:32:16 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Apr 2014 08:32:16 +0100 Subject: JDK 9 RFR of JDK-8039038: Fix serial lint warnings in com.sun.jmx.snmp In-Reply-To: <533BB0AB.8010802@oracle.com> References: <533BB0AB.8010802@oracle.com> Message-ID: <533BBD00.9090103@oracle.com> On 02/04/2014 07:39, Joe Darcy wrote: > Hello, > > *fingers crossed* The patch below should be the last change needed to > fully clear the JDK 9 jdk repo of serialization warnings. > > Thanks, > > -Joe This looks okay too. -Alan From Alan.Bateman at oracle.com Wed Apr 2 07:36:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Apr 2014 08:36:55 +0100 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> Message-ID: <533BBE17.5060906@oracle.com> On 01/04/2014 23:40, Martin Buchholz wrote: > So I rather like having different LaunchMechanisms available on different > platforms - just the default would be different. fork should work > everywhere. > I agree that is important to keep the ability to configure this, it was particularly useful with the transition from fork1 to posix_spawn on OS X and Solaris where it needed time to be completely confident that there aren't side effects or subtle behavior differences. -Alan. From daniel.fuchs at oracle.com Wed Apr 2 09:04:49 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 02 Apr 2014 11:04:49 +0200 Subject: JDK 9 RFR of JDK-8039038: Fix serial lint warnings in com.sun.jmx.snmp In-Reply-To: <533BB0AB.8010802@oracle.com> References: <533BB0AB.8010802@oracle.com> Message-ID: <533BD2B1.8060106@oracle.com> On 4/2/14 8:39 AM, Joe Darcy wrote: > Hello, > > *fingers crossed* The patch below should be the last change needed to > fully clear the JDK 9 jdk repo of serialization warnings. Looks good Joe! best regards, -- daniel > > Thanks, > > -Joe > > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/Enumerated.java > --- a/src/share/classes/com/sun/jmx/snmp/Enumerated.java Tue Apr 01 > 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/Enumerated.java Tue Apr 01 > 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1999, 2014, 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 > @@ -45,7 +45,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > abstract public class Enumerated implements Serializable { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java > --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java Tue Apr 01 > 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java Tue Apr 01 > 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2014, 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 > @@ -44,6 +44,7 @@ > * The class defines an abstract representation of a host. > * > */ > + at SuppressWarnings("serial") // JDK implementation class > abstract class Host extends SimpleNode implements Serializable { > > public Host(int id) { > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpPdu.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpPdu.java Tue Apr 01 > 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpPdu.java Tue Apr 01 > 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2001, 2014, 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 > @@ -45,6 +45,7 @@ > * > * @since 1.5 > */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpPdu implements SnmpDefinitions, Serializable { > > /** > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue > Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue > Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2001, 2014, 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 > @@ -47,6 +47,7 @@ > * > * @since 1.5 > */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpScopedPduPacket extends SnmpPdu > implements Serializable { > /** > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2014, 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 > @@ -34,7 +34,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpUnsignedInt extends SnmpInt { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpValue.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpValue.java Tue Apr 01 > 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpValue.java Tue Apr 01 > 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2014, 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 > @@ -38,7 +38,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpValue implements Cloneable, Serializable, > SnmpDataTypeEnums { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2014, 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 > @@ -59,6 +59,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMib extends SnmpMibAgent implements > Serializable { > > /** > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1998, 2014, 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 > @@ -59,7 +59,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibAgent > implements SnmpMibAgentMBean, MBeanRegistration, Serializable { > > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2000, 2014, 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 > @@ -41,7 +41,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibEntry extends SnmpMibNode > implements Serializable { > > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1999, 2014, 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 > @@ -49,7 +49,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibGroup extends SnmpMibOid > implements Serializable { > > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2014, 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 > @@ -53,7 +53,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibNode implements Serializable { > > // > --------------------------------------------------------------------- > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2014, 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 > @@ -84,7 +84,7 @@ > * @see com.sun.jmx.snmp.agent.SnmpTableSupport > * > */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibTable extends SnmpMibNode > implements NotificationBroadcaster, Serializable { > > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java Tue > Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java Tue > Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2000, 2014, 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 > @@ -80,6 +80,7 @@ > * @see com.sun.jmx.snmp.agent.SnmpMibTable > * > */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpTableSupport implements SnmpTableEntryFactory, > // NPCTE fix for bugId 4499265, esc 0, MR 04 sept 2001 > // SnmpTableCallbackHandler { > diff -r b6997dd0667e > src/share/classes/sun/management/snmp/util/SnmpListTableCache.java > --- a/src/share/classes/sun/management/snmp/util/SnmpListTableCache.java > Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/sun/management/snmp/util/SnmpListTableCache.java > Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2014, 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 > @@ -43,6 +43,7 @@ > *

NOTE: This class is not synchronized, subclasses must implement > * the appropriate synchronization whwn needed.

> **/ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpListTableCache extends SnmpTableCache { > > > diff -r b6997dd0667e > src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java > --- > a/src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java Tue > Apr 01 09:12:51 2014 -0700 > +++ > b/src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java Tue > Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2014, 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 > @@ -49,6 +49,7 @@ > *

NOTE: This class is not synchronized, subclasses must implement > * the appropriate synchronization whwn needed.

> **/ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpNamedListTableCache extends > SnmpListTableCache { > > /** > diff -r b6997dd0667e > src/share/classes/sun/management/snmp/util/SnmpTableCache.java > --- a/src/share/classes/sun/management/snmp/util/SnmpTableCache.java Tue > Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/sun/management/snmp/util/SnmpTableCache.java Tue > Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2014, 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 > @@ -45,6 +45,7 @@ > *

NOTE: This class is not synchronized, subclasses must implement > * the appropriate synchronization when needed.

> **/ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpTableCache implements Serializable { > > /** > From aph at redhat.com Wed Apr 2 09:08:02 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 02 Apr 2014 10:08:02 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> <533AA25E.9060507@CoSoCo.de> Message-ID: <533BD372.3000302@redhat.com> On 04/01/2014 10:20 PM, Eirik Lygre wrote: >> > > What is the relationship between this "naked dot" proposal and the > "chaining of void methods" proposal? The reason for asking is not to be > negative, but rather to find out if these issues are best dealt with > together, or as independent proposals. > > I think that if either of these are going to happen, then they must be > specified with the appropriate level of isolation: That which belongs > together must be processed together; that which belongs apart must be > processed apart. Point taken, but Project Coin (small language changes) worked well. Andrew. From sean.coffey at oracle.com Wed Apr 2 10:42:10 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 02 Apr 2014 11:42:10 +0100 Subject: RFR: 8035618 : Four api/org_omg/CORBA TCK tests fail under plugin only Message-ID: <533BE982.60004@oracle.com> I'm looking to port this fix from JDK 8 to 9. Other changes were made for JDK 9 given that we have access to the javaAwtAccess.getAppletContext() method when using JDK 8 as the boot strap JDK for CORBA. Direct access to the sun.awt.AppContect class has been removed. bug : https://bugs.openjdk.java.net/browse/JDK-8035618 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8035618.jdk9.v3/webrev/ Regards, Sean. From lance.andersen at oracle.com Wed Apr 2 10:49:15 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Wed, 2 Apr 2014 06:49:15 -0400 Subject: JDK 9 RFR of JDK-8039038: Fix serial lint warnings in com.sun.jmx.snmp In-Reply-To: <533BB0AB.8010802@oracle.com> References: <533BB0AB.8010802@oracle.com> Message-ID: <47902F98-E909-42F0-A2C6-F80F6F561340@oracle.com> +1 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 Apr 2, 2014, at 2:39 AM, Joe Darcy wrote: > Hello, > > *fingers crossed* The patch below should be the last change needed to fully clear the JDK 9 jdk repo of serialization warnings. > > Thanks, > > -Joe > > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/Enumerated.java > --- a/src/share/classes/com/sun/jmx/snmp/Enumerated.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/Enumerated.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1999, 2014, 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 > @@ -45,7 +45,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > abstract public class Enumerated implements Serializable { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java > --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, 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 > @@ -44,6 +44,7 @@ > * The class defines an abstract representation of a host. > * > */ > + at SuppressWarnings("serial") // JDK implementation class > abstract class Host extends SimpleNode implements Serializable { > > public Host(int id) { > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpPdu.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpPdu.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpPdu.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2001, 2014, 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 > @@ -45,6 +45,7 @@ > * > * @since 1.5 > */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpPdu implements SnmpDefinitions, Serializable { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2001, 2014, 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 > @@ -47,6 +47,7 @@ > * > * @since 1.5 > */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpScopedPduPacket extends SnmpPdu > implements Serializable { > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, 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 > @@ -34,7 +34,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpUnsignedInt extends SnmpInt { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpValue.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpValue.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpValue.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, 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 > @@ -38,7 +38,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpValue implements Cloneable, Serializable, SnmpDataTypeEnums { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, 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 > @@ -59,6 +59,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMib extends SnmpMibAgent implements Serializable { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1998, 2014, 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 > @@ -59,7 +59,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibAgent > implements SnmpMibAgentMBean, MBeanRegistration, Serializable { > > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2000, 2014, 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 > @@ -41,7 +41,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibEntry extends SnmpMibNode > implements Serializable { > > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1999, 2014, 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 > @@ -49,7 +49,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibGroup extends SnmpMibOid > implements Serializable { > > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, 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 > @@ -53,7 +53,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibNode implements Serializable { > > // --------------------------------------------------------------------- > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, 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 > @@ -84,7 +84,7 @@ > * @see com.sun.jmx.snmp.agent.SnmpTableSupport > * > */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibTable extends SnmpMibNode > implements NotificationBroadcaster, Serializable { > > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2000, 2014, 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 > @@ -80,6 +80,7 @@ > * @see com.sun.jmx.snmp.agent.SnmpMibTable > * > */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpTableSupport implements SnmpTableEntryFactory, > // NPCTE fix for bugId 4499265, esc 0, MR 04 sept 2001 > // SnmpTableCallbackHandler { > diff -r b6997dd0667e src/share/classes/sun/management/snmp/util/SnmpListTableCache.java > --- a/src/share/classes/sun/management/snmp/util/SnmpListTableCache.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/sun/management/snmp/util/SnmpListTableCache.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2014, 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 > @@ -43,6 +43,7 @@ > *

NOTE: This class is not synchronized, subclasses must implement > * the appropriate synchronization whwn needed.

> **/ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpListTableCache extends SnmpTableCache { > > > diff -r b6997dd0667e src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java > --- a/src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2014, 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 > @@ -49,6 +49,7 @@ > *

NOTE: This class is not synchronized, subclasses must implement > * the appropriate synchronization whwn needed.

> **/ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpNamedListTableCache extends SnmpListTableCache { > > /** > diff -r b6997dd0667e src/share/classes/sun/management/snmp/util/SnmpTableCache.java > --- a/src/share/classes/sun/management/snmp/util/SnmpTableCache.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/sun/management/snmp/util/SnmpTableCache.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2014, 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 > @@ -45,6 +45,7 @@ > *

NOTE: This class is not synchronized, subclasses must implement > * the appropriate synchronization when needed.

> **/ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpTableCache implements Serializable { > > /** > From peter.levart at gmail.com Wed Apr 2 10:49:21 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Apr 2014 12:49:21 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533B17CA.6030203@oracle.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> Message-ID: <533BEB31.6050307@gmail.com> On 04/01/2014 09:47 PM, roger riggs wrote: > Hi, > > A minor point, but the Enum for LaunchMechanism can be simpler; the > defined enum values (1,2,3) > are never used and can be removed along with the extra constructor. They are used for the "mode" parameter of forkAndExec() native method. > > With the refactoring so f0ar, this seems more complex and harder to > understand. Are you comparing webrev.03 with webrev.04 or original code with webrev.0[34] ? I agree that one individual original source is simpler than merged single source, but there are 4 of them to be kept in-sync and still be different in places. I find it more convenient to see the differences in one place without using a diff tool pair-wisely. It's also friendlier to IDEs if they "understand" the code instead of just treating those 4 files as texts. Some of the IDEs can be teached to understand the various (.java.bsd, .java.linux, .java.solaris, .java.aix) extensions as Java sources, but then they get confused because they see 4 sources for the same class... > At least in the non-merged version all (and only) the code for a > platform was in a single class. > The static UNIXProcess subclasses for the various platforms are always > kept around. We could bring them to the upper level as package-private subclasses and arrange in makefile to just include the ones that are needed. But then this knowledge of mapping is in two places: the makefiles and the code. > > Other alternatives would have been to factor the common code (Streams > handling) > into a utilities class or ProcessImpl and retain the 1st class > subclasses (with different names) > for each platform or merge more up into ProcessImpl. > > Maybe it will be clearer with additional refactoring. As I said, I believe the consolidation of various Input/OutputStream wrappers could bring the class files number and size further down. > > $.02, Roger If you're concerned about class files included in the distributable, but not used, we can compensate this a bit by reducing the number of anonymous inner classes generated by javac just by replacing them with lambdas. Here's new webrev that does that too: http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.05/ If UNIXProcess.java in above webrev is compiled, the following class files are produced: -rw-rw-r--. 1 peter peter 772 Apr 2 12:33 UNIXProcess$1.class// SwitchMap for Platform enum -rw-rw-r--. 1 peter peter 2706 Apr 2 12:33 UNIXProcess$AixProcess.class -rw-rw-r--. 1 peter peter 2155 Apr 2 12:33 UNIXProcess$DeferredCloseInputStream.class -rw-rw-r--. 1 peter peter 2930 Apr 2 12:33 UNIXProcess$DeferredCloseProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 1166 Apr 2 12:33 UNIXProcess$LaunchMechanism.class -rw-rw-r--. 1 peter peter 2701 Apr 2 12:33 UNIXProcess$LinuxOrBsdProcess.class -rw-rw-r--. 1 peter peter 4762 Apr 2 12:33 UNIXProcess$Platform.class -rw-rw-r--. 1 peter peter 1711 Apr 2 12:33 UNIXProcess$ProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 949 Apr 2 12:33 UNIXProcess$ProcessPipeOutputStream.class -rw-rw-r--. 1 peter peter 1902 Apr 2 12:33 UNIXProcess$ProcessReaperThreadFactory.class -rw-rw-r--. 1 peter peter 2935 Apr 2 12:33 UNIXProcess$SolarisProcess.class -rw-rw-r--. 1 peter peter 6260 Apr 2 12:33 UNIXProcess.class ...12 class files totaling 30.2 KiB. If original UNIXProcess.java.linux is compiled, for example, the following files are produced: -rw-rw-r--. 1 peter peter 1648 Apr 2 12:25 UNIXProcess$1.class -rw-rw-r--. 1 peter peter 926 Apr 2 12:25 UNIXProcess$2.class -rw-rw-r--. 1 peter peter 865 Apr 2 12:25 UNIXProcess$3.class -rw-rw-r--. 1 peter peter 648 Apr 2 12:25 UNIXProcess$4.class -rw-rw-r--. 1 peter peter 1200 Apr 2 12:25 UNIXProcess$LaunchMechanism.class -rw-rw-r--. 1 peter peter 1711 Apr 2 12:25 UNIXProcess$ProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 949 Apr 2 12:25 UNIXProcess$ProcessPipeOutputStream.class -rw-rw-r--. 1 peter peter 939 Apr 2 12:25 UNIXProcess$ProcessReaperThreadFactory$1.class -rw-rw-r--. 1 peter peter 1233 Apr 2 12:25 UNIXProcess$ProcessReaperThreadFactory.class -rw-rw-r--. 1 peter peter 5626 Apr 2 12:25 UNIXProcess.class ...10 class files totaling 15,4 KiB So it's ~15 KiB that we are talking about at this moment. Regards, Peter > > > On 4/1/2014 1:04 PM, Peter Levart wrote: >> On 04/01/2014 05:43 PM, Peter Levart wrote: >>> On 04/01/2014 03:49 PM, roger riggs wrote: >>>> Hi Peter, >>>> >>>> The design using enum for the os dependencies does not make it >>>> possible >>>> to include only the support needed for a particular platform at >>>> build time. >>>> Every implementation will be carrying around the support for all >>>> the other platforms. >>>> A build time binding would be more efficient. >>>> >>>> Roger >>> >>> That's true. A trade-off between maintainability and efficiency. The >>> efficiency has two categories here. One is the size of the >>> distributable and the other is run-time efficiency. I've been >>> thinking to improve both efficiencies (the run-time in particular) >>> with a little re-design. Since nearly each OS platform requires a >>> sub-class of UNIXProcess to implement the differences, I can move >>> the implementations of various methods now in Os enum to the >>> UNIXProcess subclasses and get rid of Os enum per-instance subclasses. >>> >>> Let me try this and see what comes out. >> >> Hi Roger, >> >> Well, it turns out the methods would like to stay in Os (renamed to >> Platform), but there is no need for per-enum-instance subclasses. >> Using enum constructor parameters and switch statements makes code >> even more compact and easy to follow... >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.04/ >> >> >> I belive there is still room for consolidating logic in various >> Input/OutputStream wrappers used in UNIXProcess variants. But in the >> first round I tried to preserve the exact behaviour. If the wrapping >> of streams could be made more-or-less equal in all UNIX platforms, >> then the need for UNIXProcess subclasses and/or overhead of support >> classes included but not used goes away... >> >> Regards, Peter >> >>> >>>> >>>> >>>> >>>> On 4/1/2014 9:16 AM, Peter Levart wrote: >>>>> Hi Alan, Volker, >>>>> >>>>> Thanks for sharing the info and for testing on AIX. Here's the >>>>> updated webrev that hopefully includes the correct "dispatch on >>>>> os.name" logic. I included "Solaris" as an alternative to "SunOS" >>>>> since I saw this in some documents on Internet. If this is >>>>> superfluous, I can remove it: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.03/ >>>>> >>>>> I tested this on Linux and Solaris and the >>>>> java/lang/ProcessBuilder jtreg tests pass. So with Volker's test >>>>> on AIX, the only OS platform left for testing is Mac OS X. Would >>>>> someone volunteer? >>>>> >>>>> Regards, Peter >>>>> >>>>> On 03/27/2014 11:18 AM, Volker Simonis wrote: >>>>>> Hi Peter, >>>>>> >>>>>> thanks for applying these changes to the AIX files as well. >>>>>> >>>>>> With the additional line: >>>>>> >>>>>> if (osName.equals("AIX")) { return AIX; } >>>>>> >>>>>> in Os.get() your change compiles cleanly on AIX and runs the >>>>>> java/lang/ProcessBuilder tests without any errors. >>>>>> >>>>>> So from an AIX perspective, thumbs up. >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Wed, Mar 26, 2014 at 5:18 PM, Alan Bateman >>>>>> wrote: >>>>>>> On 26/03/2014 15:19, Peter Levart wrote: >>>>>>>> I couldn't find any official document about possible os.name >>>>>>>> values for >>>>>>>> different supported OSes. Does anyone have a pointer? >>>>>>> I don't know if there is a definite list but I assume we don't >>>>>>> need to be >>>>>>> concerned with anything beyond the 4 that we have in OpenJDK, >>>>>>> which is >>>>>>> "Linux", "SunOS", "AIX" and contains("OS X"). >>>>>>> >>>>>>> If we get to the point in JDK 9 where src/solaris is renamed to >>>>>>> src/unix (or >>>>>>> something equivalent) then it could mean that the Os enum can be >>>>>>> replaced >>>>>>> with an OS specific class in src/linux, src/solaris, ... and >>>>>>> this would >>>>>>> avoid the need for an os.name check at runtime. >>>>>>> >>>>>>> -Alan. >>>>>>> >>>>> >>>> >>> >> > From aleksej.efimov at oracle.com Wed Apr 2 10:55:10 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 02 Apr 2014 14:55:10 +0400 Subject: RFR: 8038306: (tz) Support tzdata2014b Message-ID: <533BEC8E.8080106@oracle.com> Hello, Can I have a review for the latest (2014b) TZ data integration to JDK9. The webrev can be located here [1]. The following set of tests were executed without failures: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter test/closed/java/util/Calendar\ test/closed/java/util/TimeZone Thank you, Aleksej [1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/ [2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306 From Ulf.Zibis at CoSoCo.de Wed Apr 2 10:58:29 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 02 Apr 2014 12:58:29 +0200 Subject: Implicit 'this' return for void methods In-Reply-To: <533BD372.3000302@redhat.com> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> <533AA25E.9060507@CoSoCo.de> <533BD372.3000302@redhat.com> Message-ID: <533BED55.6000503@CoSoCo.de> Hi, Am 02.04.2014 11:08, schrieb Andrew Haley: > On 04/01/2014 10:20 PM, Eirik Lygre wrote: >> What is the relationship between this "naked dot" proposal and the >> "chaining of void methods" proposal? The reason for asking is not to be >> negative, but rather to find out if these issues are best dealt with >> together, or as independent proposals. >> >> I think that if either of these are going to happen, then they must be >> specified with the appropriate level of isolation: That which belongs >> together must be processed together; that which belongs apart must be >> processed apart. > Point taken, but Project Coin (small language changes) worked well. > > Andrew. If that would help to make things happen, I support the idea to separate both steps to different proposals. -Ulf From aph at redhat.com Wed Apr 2 11:05:50 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 02 Apr 2014 12:05:50 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: <533BED55.6000503@CoSoCo.de> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> <533AA25E.9060507@CoSoCo.de> <533BD372.3000302@redhat.com> <533BED55.6000503@CoSoCo.de> Message-ID: <533BEF0E.3090101@redhat.com> On 04/02/2014 11:58 AM, Ulf Zibis wrote: > Hi, > > Am 02.04.2014 11:08, schrieb Andrew Haley: >> On 04/01/2014 10:20 PM, Eirik Lygre wrote: >>> What is the relationship between this "naked dot" proposal and the >>> "chaining of void methods" proposal? The reason for asking is not to be >>> negative, but rather to find out if these issues are best dealt with >>> together, or as independent proposals. >>> >>> I think that if either of these are going to happen, then they must be >>> specified with the appropriate level of isolation: That which belongs >>> together must be processed together; that which belongs apart must be >>> processed apart. >> Point taken, but Project Coin (small language changes) worked well. > > If that would help to make things happen, I support the idea to separate both steps to different > proposals. Here's how it works: Start a project to do small language changes, or join an existing one. Form an EG for the JSR. It may be be that there is already a suitable JSR in progress. Discuss. Make spec changes, make an implementation, make TCK changes. Propose the change to the umbrella Java SE EG for inclusion in JDK N. If this sounds like a lot of work, that's because it is. Andrew. From sean.coffey at oracle.com Wed Apr 2 11:26:39 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 02 Apr 2014 12:26:39 +0100 Subject: RFR: 8038306: (tz) Support tzdata2014b In-Reply-To: <533BEC8E.8080106@oracle.com> References: <533BEC8E.8080106@oracle.com> Message-ID: <533BF3EF.6060904@oracle.com> Looks fine to me. regards, Sean. On 02/04/14 11:55, Aleksej Efimov wrote: > Hello, > > Can I have a review for the latest (2014b) TZ data integration to > JDK9. The webrev can be located here [1]. > > The following set of tests were executed without failures: > test/sun/util/calendar test/java/util/Calendar > test/sun/util/resources/TimeZone test/sun/util/calendar > test/java/util/TimeZone test/java/time test/java/util/Formatter > test/closed/java/util/Calendar\ test/closed/java/util/TimeZone > > Thank you, > Aleksej > > [1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/ > [2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306 From develop4lasu at gmail.com Wed Apr 2 11:52:01 2014 From: develop4lasu at gmail.com (=?UTF-8?Q?Marek_Kozie=C5=82?=) Date: Wed, 2 Apr 2014 13:52:01 +0200 Subject: Implicit 'this' return for void methods In-Reply-To: <533BD372.3000302@redhat.com> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> <533AA25E.9060507@CoSoCo.de> <533BD372.3000302@redhat.com> Message-ID: In my opinion Project Coin was meant only to push some earlier chosen changes into language. "Naked dot" in language where long name are preferred is pure evil: I would have to look pairing ";" for every dot ? > someVeryLongName()/* explanation*/.otherLongNameMethod(); > someVeryLongName();/* explanation*/.otherLongNameMethod(); When dot would be first sign i would have to: check end of previous line, or check last sign before comment, some time i would have to use scroll for each line (like when comparing code while commit). > someVeryLongName().call().call().call().call().call().call().call().call().call().call().call(); // comment >.otherLongNameMethod(); > someVeryLongName().call().call().call().call().call().call().call().call().call().call().call() // comment > .otherLongNameMethod(); The things go even worse if code have to be compared without without syntax highlighting. It's really hard to find anything good about this proposal. The most scary is fact that .. or ... would be consumed to support such change. because i hope for anything near: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000680.html 2014-04-02 11:08 GMT+02:00 Andrew Haley : > On 04/01/2014 10:20 PM, Eirik Lygre wrote: >>> > >> What is the relationship between this "naked dot" proposal and the >> "chaining of void methods" proposal? The reason for asking is not to be >> negative, but rather to find out if these issues are best dealt with >> together, or as independent proposals. >> >> I think that if either of these are going to happen, then they must be >> specified with the appropriate level of isolation: That which belongs >> together must be processed together; that which belongs apart must be >> processed apart. > > Point taken, but Project Coin (small language changes) worked well. > > Andrew. > -- Pozdrawiam Marek Kozie? ( Lasu ) http://na-chlodno.blogspot.com/ http://lasu2string.blogspot.com/ From roger.riggs at oracle.com Wed Apr 2 13:17:51 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 02 Apr 2014 09:17:51 -0400 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533BEB31.6050307@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> Message-ID: <533C0DFF.5020508@oracle.com> Hi, On 4/2/2014 6:49 AM, Peter Levart wrote: > On 04/01/2014 09:47 PM, roger riggs wrote: >> Hi, >> >> A minor point, but the Enum for LaunchMechanism can be simpler; the >> defined enum values (1,2,3) >> are never used and can be removed along with the extra constructor. > > They are used for the "mode" parameter of forkAndExec() native method. yes, and could just as easily use the default ordinals (0,1,2). > >> >> With the refactoring so far, this seems more complex and harder to >> understand. > ... > >> >> Other alternatives would have been to factor the common code (Streams >> handling) >> into a utilities class or ProcessImpl and retain the 1st class >> subclasses (with different names) >> for each platform or merge more up into ProcessImpl. >> >> Maybe it will be clearer with additional refactoring. > > As I said, I believe the consolidation of various Input/OutputStream > wrappers could bring the class files number and size further down. yes, we can't stop yet. The only difference between the inner classes per platform is the choice of initializing the streams which could be handled with a switch instead of a subclass. Please continue, Roger > >> >> $.02, Roger > > If you're concerned about class files included in the distributable, > but not used, we can compensate this a bit by reducing the number of > anonymous inner classes generated by javac just by replacing them with > lambdas. Here's new webrev that does that too: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.05/ > > If UNIXProcess.java in above webrev is compiled, the following class > files are produced: > > -rw-rw-r--. 1 peter peter 772 Apr 2 12:33 UNIXProcess$1.class// > SwitchMap for Platform enum I would have hoped that the extra class would not be needed for the private static enum, but then private isn't private when it is visible to inner classes! It is needed for separate compilation. > -rw-rw-r--. 1 peter peter 2706 Apr 2 12:33 UNIXProcess$AixProcess.class > -rw-rw-r--. 1 peter peter 2155 Apr 2 12:33 > UNIXProcess$DeferredCloseInputStream.class > -rw-rw-r--. 1 peter peter 2930 Apr 2 12:33 > UNIXProcess$DeferredCloseProcessPipeInputStream.class > -rw-rw-r--. 1 peter peter 1166 Apr 2 12:33 > UNIXProcess$LaunchMechanism.class > -rw-rw-r--. 1 peter peter 2701 Apr 2 12:33 > UNIXProcess$LinuxOrBsdProcess.class > -rw-rw-r--. 1 peter peter 4762 Apr 2 12:33 UNIXProcess$Platform.class > -rw-rw-r--. 1 peter peter 1711 Apr 2 12:33 > UNIXProcess$ProcessPipeInputStream.class > -rw-rw-r--. 1 peter peter 949 Apr 2 12:33 > UNIXProcess$ProcessPipeOutputStream.class > -rw-rw-r--. 1 peter peter 1902 Apr 2 12:33 > UNIXProcess$ProcessReaperThreadFactory.class > -rw-rw-r--. 1 peter peter 2935 Apr 2 12:33 > UNIXProcess$SolarisProcess.class > -rw-rw-r--. 1 peter peter 6260 Apr 2 12:33 UNIXProcess.class > > ...12 class files totaling 30.2 KiB. > > If original UNIXProcess.java.linux is compiled, for example, the > following files are produced: > > -rw-rw-r--. 1 peter peter 1648 Apr 2 12:25 UNIXProcess$1.class > -rw-rw-r--. 1 peter peter 926 Apr 2 12:25 UNIXProcess$2.class > -rw-rw-r--. 1 peter peter 865 Apr 2 12:25 UNIXProcess$3.class > -rw-rw-r--. 1 peter peter 648 Apr 2 12:25 UNIXProcess$4.class > -rw-rw-r--. 1 peter peter 1200 Apr 2 12:25 > UNIXProcess$LaunchMechanism.class > -rw-rw-r--. 1 peter peter 1711 Apr 2 12:25 > UNIXProcess$ProcessPipeInputStream.class > -rw-rw-r--. 1 peter peter 949 Apr 2 12:25 > UNIXProcess$ProcessPipeOutputStream.class > -rw-rw-r--. 1 peter peter 939 Apr 2 12:25 > UNIXProcess$ProcessReaperThreadFactory$1.class > -rw-rw-r--. 1 peter peter 1233 Apr 2 12:25 > UNIXProcess$ProcessReaperThreadFactory.class > -rw-rw-r--. 1 peter peter 5626 Apr 2 12:25 UNIXProcess.class > > ...10 class files totaling 15,4 KiB > > So it's ~15 KiB that we are talking about at this moment. > > > Regards, Peter > >> >> >> On 4/1/2014 1:04 PM, Peter Levart wrote: >>> On 04/01/2014 05:43 PM, Peter Levart wrote: >>>> On 04/01/2014 03:49 PM, roger riggs wrote: >>>>> Hi Peter, >>>>> >>>>> The design using enum for the os dependencies does not make it >>>>> possible >>>>> to include only the support needed for a particular platform at >>>>> build time. >>>>> Every implementation will be carrying around the support for all >>>>> the other platforms. >>>>> A build time binding would be more efficient. >>>>> >>>>> Roger >>>> >>>> That's true. A trade-off between maintainability and efficiency. >>>> The efficiency has two categories here. One is the size of the >>>> distributable and the other is run-time efficiency. I've been >>>> thinking to improve both efficiencies (the run-time in particular) >>>> with a little re-design. Since nearly each OS platform requires a >>>> sub-class of UNIXProcess to implement the differences, I can move >>>> the implementations of various methods now in Os enum to the >>>> UNIXProcess subclasses and get rid of Os enum per-instance subclasses. >>>> >>>> Let me try this and see what comes out. >>> >>> Hi Roger, >>> >>> Well, it turns out the methods would like to stay in Os (renamed to >>> Platform), but there is no need for per-enum-instance subclasses. >>> Using enum constructor parameters and switch statements makes code >>> even more compact and easy to follow... >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.04/ >>> >>> >>> I belive there is still room for consolidating logic in various >>> Input/OutputStream wrappers used in UNIXProcess variants. But in the >>> first round I tried to preserve the exact behaviour. If the wrapping >>> of streams could be made more-or-less equal in all UNIX platforms, >>> then the need for UNIXProcess subclasses and/or overhead of support >>> classes included but not used goes away... >>> >>> Regards, Peter >>> >>>> >>>>> >>>>> >>>>> >>>>> On 4/1/2014 9:16 AM, Peter Levart wrote: >>>>>> Hi Alan, Volker, >>>>>> >>>>>> Thanks for sharing the info and for testing on AIX. Here's the >>>>>> updated webrev that hopefully includes the correct "dispatch on >>>>>> os.name" logic. I included "Solaris" as an alternative to "SunOS" >>>>>> since I saw this in some documents on Internet. If this is >>>>>> superfluous, I can remove it: >>>>>> >>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.03/ >>>>>> >>>>>> I tested this on Linux and Solaris and the >>>>>> java/lang/ProcessBuilder jtreg tests pass. So with Volker's test >>>>>> on AIX, the only OS platform left for testing is Mac OS X. Would >>>>>> someone volunteer? >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> On 03/27/2014 11:18 AM, Volker Simonis wrote: >>>>>>> Hi Peter, >>>>>>> >>>>>>> thanks for applying these changes to the AIX files as well. >>>>>>> >>>>>>> With the additional line: >>>>>>> >>>>>>> if (osName.equals("AIX")) { return AIX; } >>>>>>> >>>>>>> in Os.get() your change compiles cleanly on AIX and runs the >>>>>>> java/lang/ProcessBuilder tests without any errors. >>>>>>> >>>>>>> So from an AIX perspective, thumbs up. >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 26, 2014 at 5:18 PM, Alan Bateman >>>>>>> wrote: >>>>>>>> On 26/03/2014 15:19, Peter Levart wrote: >>>>>>>>> I couldn't find any official document about possible os.name >>>>>>>>> values for >>>>>>>>> different supported OSes. Does anyone have a pointer? >>>>>>>> I don't know if there is a definite list but I assume we don't >>>>>>>> need to be >>>>>>>> concerned with anything beyond the 4 that we have in OpenJDK, >>>>>>>> which is >>>>>>>> "Linux", "SunOS", "AIX" and contains("OS X"). >>>>>>>> >>>>>>>> If we get to the point in JDK 9 where src/solaris is renamed to >>>>>>>> src/unix (or >>>>>>>> something equivalent) then it could mean that the Os enum can >>>>>>>> be replaced >>>>>>>> with an OS specific class in src/linux, src/solaris, ... and >>>>>>>> this would >>>>>>>> avoid the need for an os.name check at runtime. >>>>>>>> >>>>>>>> -Alan. >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From miroslav.kos at oracle.com Wed Apr 2 13:32:31 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Wed, 02 Apr 2014 15:32:31 +0200 Subject: RFR: tests for JDK-8032884 In-Reply-To: <8E460A98-F87F-48A0-A6DB-9320081054CC@oracle.com> References: <533AD97E.8080102@oracle.com> <8E460A98-F87F-48A0-A6DB-9320081054CC@oracle.com> Message-ID: <533C116F.20201@oracle.com> In the test, I need to do following steps: 1. compile schema file using xjc tool 2. compile generated sources 3. load generated class and via reflection API verify generated methods Although I know how to run tool directly from the test, it seems to me not very elegant to run compiler directly from the test - or is there other way how to compile generated sources from the test? Regrading moving test - no problem, but I would suggest javax/xml/bind/xjc in this case - xjc is JAXB tool, not JAX-WS. Do you agree? Thanks Miran On 01/04/14 18:50, Chris Hegarty wrote: > The tests looks fine to me. > > Trivially, you could eliminate the shell script and run xic from ProcessBuilder? > > Also, does it make sense to move the test to jdk/test/javax/xml/ws/xjc? With the other jaxws tests, or is xjc different. > > -Chris,. > > On 1 Apr 2014, at 16:21, Miroslav Kos wrote: > >> Hi everybody, >> >> I'd like to ask for review of following tests: >> http://cr.openjdk.java.net/~mkos/8032884/jdk.01/ >> >> Original bug (already fixed): Bug: https://bugs.openjdk.java.net/browse/JDK-8032884 >> Issue fixing the bug (bulk update): https://bugs.openjdk.java.net/browse/JDK-8036030 >> >> The test verifies the source code generated by xjc tool. >> >> Thanks >> Miran From chris.hegarty at oracle.com Wed Apr 2 13:47:16 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 02 Apr 2014 14:47:16 +0100 Subject: RFR: tests for JDK-8032884 In-Reply-To: <533C116F.20201@oracle.com> References: <533AD97E.8080102@oracle.com> <8E460A98-F87F-48A0-A6DB-9320081054CC@oracle.com> <533C116F.20201@oracle.com> Message-ID: <533C14E4.9030209@oracle.com> On 02/04/14 14:32, Miroslav Kos wrote: > In the test, I need to do following steps: > > 1. compile schema file using xjc tool > 2. compile generated sources > 3. load generated class and via reflection API verify generated methods In which case, what you have is fine then. > Although I know how to run tool directly from the test, it seems to me > not very elegant to run compiler directly from the test - or is there > other way how to compile generated sources from the test? > > Regrading moving test - no problem, but I would suggest > javax/xml/bind/xjc in this case - xjc is JAXB tool, not JAX-WS. Do you > agree? Agreed. -Chris. > > Thanks > Miran > > > > On 01/04/14 18:50, Chris Hegarty wrote: >> The tests looks fine to me. >> >> Trivially, you could eliminate the shell script and run xic from >> ProcessBuilder? >> >> Also, does it make sense to move the test to >> jdk/test/javax/xml/ws/xjc? With the other jaxws tests, or is xjc >> different. >> >> -Chris,. >> >> On 1 Apr 2014, at 16:21, Miroslav Kos wrote: >> >>> Hi everybody, >>> >>> I'd like to ask for review of following tests: >>> http://cr.openjdk.java.net/~mkos/8032884/jdk.01/ >>> >>> Original bug (already fixed): Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8032884 >>> Issue fixing the bug (bulk update): >>> https://bugs.openjdk.java.net/browse/JDK-8036030 >>> >>> The test verifies the source code generated by xjc tool. >>> >>> Thanks >>> Miran > From pdoubleya at gmail.com Wed Apr 2 13:55:19 2014 From: pdoubleya at gmail.com (Patrick Wright) Date: Wed, 2 Apr 2014 15:55:19 +0200 Subject: Implicit 'this' return for void methods In-Reply-To: References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> <533AA25E.9060507@CoSoCo.de> <533BD372.3000302@redhat.com> Message-ID: Hi, Just adding some perspective after following these language-feature discussions for several years now. > In my opinion Project Coin was meant only to push some earlier chosen > changes into language. > The initial Project Coin process actually invited proposals from the community. There were many, and the majority were rejected (following varying amounts of analysis and discussion). IIRC, the "underscore in number literals" was one that had not been on the table before, but for which a sound proposal, use-cases, specification, and code were provided by a community member. Bob Lee also submitted a proposal related to generics that made it in, IIRC. That said, the Oracle Java team has made it clear that there are many, many more feature requests than there are time or resources to implement them, even if you could decide which were really worth it. That's been true for many years now, basically since the 90s. Brian Goetz (among others) has addressed this topic - of language changes - to death in various mailing lists over the last few years. His email from 2011 on how the language changes may be handled in the future is probably useful to re-read http://mail.openjdk.java.net/pipermail/coin-dev/2011-October/003373.html IMO, the chances are low that a loose agreement from a handful of people on this mailing thread will incite the kind folks at Oracle to take action. At this point, someone, perhaps Ulf, could summarize and formalize the proposal in a draft JEP. That said, as far as I know, there has been no open "call for proposed changes to the language" in Java 9. There might be a better outlet for these discussions than the core-libs mailing list. Perhaps a new group on Stack Exchange could be used to flesh proposals out first. Each of our emails here, including this one, takes time away from the members of the core-libs team. My 0.02, Patrick From Alan.Bateman at oracle.com Wed Apr 2 14:05:13 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Apr 2014 15:05:13 +0100 Subject: RFR: 8035618 : Four api/org_omg/CORBA TCK tests fail under plugin only In-Reply-To: <533BE982.60004@oracle.com> References: <533BE982.60004@oracle.com> Message-ID: <533C1919.4020509@oracle.com> On 02/04/2014 11:42, Se?n Coffey wrote: > I'm looking to port this fix from JDK 8 to 9. Other changes were made > for JDK 9 given that we have access to the > javaAwtAccess.getAppletContext() method when using JDK 8 as the boot > strap JDK for CORBA. Direct access to the sun.awt.AppContect class has > been removed. > > bug : https://bugs.openjdk.java.net/browse/JDK-8035618 > webrev : > http://cr.openjdk.java.net/~coffeys/webrev.8035618.jdk9.v3/webrev/ This mostly looks okay to me except that pmContexts should be final. It looks like this code is also a candidate to use computeIfAbsent so you could replace L251-254 with one statement. -Alan. From paul.sandoz at oracle.com Wed Apr 2 14:16:21 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Apr 2014 16:16:21 +0200 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <533AE776.20209@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> <6562A055-4B0E-4992-8BF9-A16EFDB09CD6@oracle.com> <533AC8C4.9080601@oracle.com> <533AE776.20209@oracle.com> Message-ID: <4C2465F9-CE7B-4B43-AD73-A822C6B86F97@oracle.com> On Apr 1, 2014, at 6:21 PM, Vladimir Ivanov wrote: > On 4/1/14 7:29 PM, Paul Sandoz wrote: >> >> On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov wrote: >> >>> Paul, >>> >>> Unfortunately, additional profiling doesn't work for Accessor.checkCast case. The problem is Accessor.checkCast is called from multiple places, so type profile is very likely to be polluted. And it kills the benefits. >>> >> Though... i wonder why the accessor cast is any more or less unique than casts performed for lambda form. >> So is there any point in doing such a cast in this case? >> >> The type performing the cast is the field type declared as a parameter in the MethodType of the MethodHandle and also held by the Accessor. >> >> IIUC the Invokers.checkExactType should ensure no "unsavoury" instances of the wrong type gets through? (the holder instance is only checked for null, via checkBase). > I don't see any point in doing profiling for this particular case. Such shape should be well optimized by JIT if it sees that an instance of Accessor is a constant. As I understand, it should be the case for most of the usage scenarios. > Perhaps conservatively we could retain the existing casts if PROFILE > 0. I can provide a patch if that helps? Also, just double checking, i would presume the same would be applicable for MH setter/getters to arrays as per your patch improving those? >>> Regarding redundant null check, do you have a test case so I can play with it myself? >>> >> >> I will send something to you later today or tomorrow. >> Still plan to send you something today :-) but later on... Paul. From aph at redhat.com Wed Apr 2 14:32:55 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 02 Apr 2014 15:32:55 +0100 Subject: Implicit 'this' return for void methods In-Reply-To: <533BEF0E.3090101@redhat.com> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> <533AA25E.9060507@CoSoCo.de> <533BD372.3000302@redhat.com> <533BED55.6000503@CoSoCo.de> <533BEF0E.3090101@redhat.com> Message-ID: <533C1F97.8040003@redhat.com> On 04/02/2014 12:05 PM, Andrew Haley wrote: > On 04/02/2014 11:58 AM, Ulf Zibis wrote: >> Hi, >> >> Am 02.04.2014 11:08, schrieb Andrew Haley: >>> On 04/01/2014 10:20 PM, Eirik Lygre wrote: >>>> What is the relationship between this "naked dot" proposal and the >>>> "chaining of void methods" proposal? The reason for asking is not to be >>>> negative, but rather to find out if these issues are best dealt with >>>> together, or as independent proposals. >>>> >>>> I think that if either of these are going to happen, then they must be >>>> specified with the appropriate level of isolation: That which belongs >>>> together must be processed together; that which belongs apart must be >>>> processed apart. >>> Point taken, but Project Coin (small language changes) worked well. >> >> If that would help to make things happen, I support the idea to separate both steps to different >> proposals. > > Here's how it works: > > Start a project to do small language changes, or join an existing one. > Form an EG for the JSR. It may be be that there is already a suitable > JSR in progress. > > Discuss. Make spec changes, make an implementation, make TCK changes. > > Propose the change to the umbrella Java SE EG for inclusion in JDK N. As Patrick Wright has pointed out, this would be a JEP. See http://openjdk.java.net/jeps/1 Andrew. From sean.coffey at oracle.com Wed Apr 2 14:44:22 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 02 Apr 2014 15:44:22 +0100 Subject: RFR: 8035618 : Four api/org_omg/CORBA TCK tests fail under plugin only In-Reply-To: <533C1919.4020509@oracle.com> References: <533BE982.60004@oracle.com> <533C1919.4020509@oracle.com> Message-ID: <533C2246.3080601@oracle.com> On 02/04/14 15:05, Alan Bateman wrote: > On 02/04/2014 11:42, Se?n Coffey wrote: >> I'm looking to port this fix from JDK 8 to 9. Other changes were made >> for JDK 9 given that we have access to the >> javaAwtAccess.getAppletContext() method when using JDK 8 as the boot >> strap JDK for CORBA. Direct access to the sun.awt.AppContect class >> has been removed. >> >> bug : https://bugs.openjdk.java.net/browse/JDK-8035618 >> webrev : >> http://cr.openjdk.java.net/~coffeys/webrev.8035618.jdk9.v3/webrev/ > This mostly looks okay to me except that pmContexts should be final. > It looks like this code is also a candidate to use computeIfAbsent so > you could replace L251-254 with one statement. I'll make pmContexts final before pushing. Thanks for the lambda tip. As per trial though, it looks like CORBA code is still compiled with -source 1.7, we can revisit after this changes. regards, Sean. > > -Alan. From lance.andersen at oracle.com Wed Apr 2 14:53:09 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 2 Apr 2014 10:53:09 -0400 Subject: RFR 8039088: Fix broken URLs in package.html Message-ID: <63DCBD6F-D886-4F6B-AE19-827C09C45820@oracle.com> Good morning, Here is another trivial change to address some broken links Best Lance ljanders-mac:sql ljanders$ hg diff diff -r 31541b9a5a4a src/share/classes/java/sql/package.html --- a/src/share/classes/java/sql/package.html Wed Apr 02 10:20:14 2014 -0400 +++ b/src/share/classes/java/sql/package.html Wed Apr 02 10:50:21 2014 -0400 @@ -316,24 +316,18 @@

Package Specification

Related Documentation

- at since 1.1 diff -r 31541b9a5a4a src/share/classes/javax/sql/package.html --- a/src/share/classes/javax/sql/package.html Wed Apr 02 10:20:14 2014 -0400 +++ b/src/share/classes/javax/sql/package.html Wed Apr 02 10:50:21 2014 -0400 @@ -296,8 +296,7 @@

Package Specification

Related Documentation

@@ -307,10 +306,8 @@ package: -

- at since 1.4 ljanders-mac:sql ljanders$ 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 chris.hegarty at oracle.com Wed Apr 2 15:02:38 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 02 Apr 2014 16:02:38 +0100 Subject: RFR 8039088: Fix broken URLs in package.html In-Reply-To: <63DCBD6F-D886-4F6B-AE19-827C09C45820@oracle.com> References: <63DCBD6F-D886-4F6B-AE19-827C09C45820@oracle.com> Message-ID: <533C268E.4050901@oracle.com> Looks ok to me Lance. -Chris. On 02/04/14 15:53, Lance Andersen wrote: > Good morning, > > Here is another trivial change to address some broken links > > > Best > Lance > > ljanders-mac:sql ljanders$ hg diff > diff -r 31541b9a5a4a src/share/classes/java/sql/package.html > --- a/src/share/classes/java/sql/package.html Wed Apr 02 10:20:14 2014 -0400 > +++ b/src/share/classes/java/sql/package.html Wed Apr 02 10:50:21 2014 -0400 > @@ -316,24 +316,18 @@ >

Package Specification

> > > >

Related Documentation

> > > > - at since 1.1 > > > diff -r 31541b9a5a4a src/share/classes/javax/sql/package.html > --- a/src/share/classes/javax/sql/package.html Wed Apr 02 10:20:14 2014 -0400 > +++ b/src/share/classes/javax/sql/package.html Wed Apr 02 10:50:21 2014 -0400 > @@ -296,8 +296,7 @@ >

Package Specification

> > > >

Related Documentation

> @@ -307,10 +306,8 @@ > package: > > > -

> - at since 1.4 > > > ljanders-mac:sql ljanders$ > > > 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 volker.simonis at gmail.com Wed Apr 2 15:07:14 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 Apr 2014 17:07:14 +0200 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Jonathan, thanks for updating the change. Please find my comments inline: On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu wrote: > Hi Volker, Masayoshi, > > Thanks a lot for your review, here's the updated patch, could you pls take a > look? > > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ > > > On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis > wrote: >> >> Hi Jonathan, >> >> thanks for doing this change. Please find some comments below: >> >> 1. please update the copyright year to 2014 in every file you touch > > > Updated in new patch. > >> >> 2. in CopyFiles.gmk you can simplify the change by joining the windows >> and aix cases because on Windows OPENJDK_TARGET_OS is the same like >> OPENJDK_TARGET_OS_API_DIR. So you can write: >> >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) >> >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib >> >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings >> $(call install-file) >> >> COPY_FILES += $(LIBDIR)/tzmappings >> >> endif > > > I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris' > as I observed on my AIX box, > solaris/lib is not the directory where tzmappings was stored for AIX. > So I'm keeping this change, please fix me if I was wrong about the config. > Yes, but my point was to actually use OPENJDK_TARGET_OS for the construction of TZMAPPINGS_SRC as shown in the code snippet above. OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX and that should be just enough here. >> >> >> 3. regarding the changes proposed by Masayoshi: I agree that we should >> put the AIX timezone mapping code in its own function, but I don't >> think that getPlatformTimeZoneID() would be the right place. As far as >> I understand, getPlatformTimeZoneID() is used to get a platform time >> zone id if the environment variable "TZ" is not set. I don't know a >> way how this could be done on AIX (@Jonathan: maybe you know?). If >> there would be a way to get the time zone from some system files or >> so, then we should put this code into the AIX version of >> getPlatformTimeZoneID(). > > > I guess we may try to use /etc/envrionment file, which is basic setting for > all processes, > see > http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm > The implementation of getPlatformTimeZoneID() has been updated. > That's good! >> >> >> But the current AIX code contributed by Jonathan, actually uses the >> time zone id from the "TZ" environment variable and just maps it to a >> Java compatible time zone id. So I'd suggest to refactor this code >> into a function like for example "static const char* >> mapPlatformToJavaTimzone(const char* tz)" and call that from >> findJavaTZ_md(). I think that would make the code easier to >> understand. > > > Agree, and have split the code into a separate static method to do the > mapping work. > Good. But there's still one error in findJavaTZ_md(): 706 #ifdef _AIX 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); 708 #endif This should read: 706 #ifdef _AIX 707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz); 708 #endif because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came from getPlatformTimeZoneID(). With the above fixed I'll push this one we get one more review from a reviewer (I'm currently not an official reviewer). Regards, Volker >> >> >> @Masayoshi: what do you think, would you agree with such a solution. >> >> 4. I agree with Masayoshi that you should use the existing >> getGMTOffsetID() > > > Updated in new patch to eliminate duplication. > >> >> >> 5. Please notice that your change breaks all Unix builds except AIX >> because of: >> >> 759 } >> 760 tzerr: >> 761 if (javatz == NULL) { >> 762 time_t offset; >> ... >> 782 } >> 783 #endif >> >> I think that should read: >> >> 759 >> 760 tzerr: >> 761 if (javatz == NULL) { >> 762 time_t offset; >> ... >> 782 } >> 783 #endif >> 784 } >> >> Refactoring the code in an extra function will make that error more >> evident anyway. >> >> But please always build at least on one different platform (i.e. >> Linux) to prevent such errors in the future. > > > My fault, sorry for the failure, should take no chance after any manual > alteration. > >> >> >> Regards, >> Volker >> >> >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu >> wrote: >> > Hi Jonathan, >> > >> > The AIX specific code looks OK to me. But I'd suggest the code be moved >> > to >> > getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also >> > there's a function for producing a fallback ID in "GMT?hh:mm", >> > getGMTOffsetID() which can be called in tzerr. >> > >> > Thanks, >> > Masayoshi >> > >> > >> > On 3/26/2014 3:47 PM, Jonathan Lu wrote: >> >> >> >> Hi ppc-aix-port-dev, core-libs-dev, >> >> >> >> Here's a patch for JDK-8034220, >> >> >> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ >> >> >> >> It is trying to add the a more complete timezone mapping mechanism for >> >> AIX >> >> platform. >> >> the changes are primarily based on IBM's commercial JDK code, which >> >> includes: >> >> >> >> - A new timezone mapping file added under directory jdk/src/aix/lib/ >> >> - Code to parse above config file, changed file is >> >> src/solaris/native/java/util/TimeZone_md.c >> >> - And also makefile change in make/CopyFiles.gmk to copy the config >> >> file >> >> >> >> Could you pls help to review and give comments ? >> >> >> >> Cheers >> >> - Jonathan >> > >> > > > > Many thanks > Jonathan From xueming.shen at oracle.com Wed Apr 2 15:10:23 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 02 Apr 2014 08:10:23 -0700 Subject: RFR: 8038306: (tz) Support tzdata2014b In-Reply-To: <533BEC8E.8080106@oracle.com> References: <533BEC8E.8080106@oracle.com> Message-ID: <533C285F.8070602@oracle.com> looks fine. On 4/2/14 3:55 AM, Aleksej Efimov wrote: > Hello, > > Can I have a review for the latest (2014b) TZ data integration to > JDK9. The webrev can be located here [1]. > > The following set of tests were executed without failures: > test/sun/util/calendar test/java/util/Calendar > test/sun/util/resources/TimeZone test/sun/util/calendar > test/java/util/TimeZone test/java/time test/java/util/Formatter > test/closed/java/util/Calendar\ test/closed/java/util/TimeZone > > Thank you, > Aleksej > > [1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/ > [2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306 From Alan.Bateman at oracle.com Wed Apr 2 15:15:50 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Apr 2014 16:15:50 +0100 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533AF19A.1060709@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> Message-ID: <533C29A6.2060309@oracle.com> On 01/04/2014 18:04, Peter Levart wrote: > > Hi Roger, > > Well, it turns out the methods would like to stay in Os (renamed to > Platform), but there is no need for per-enum-instance subclasses. > Using enum constructor parameters and switch statements makes code > even more compact and easy to follow... > > http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.04/ > > > I belive there is still room for consolidating logic in various > Input/OutputStream wrappers used in UNIXProcess variants. But in the > first round I tried to preserve the exact behaviour. If the wrapping > of streams could be made more-or-less equal in all UNIX platforms, > then the need for UNIXProcess subclasses and/or overhead of support > classes included but not used goes away... > I went through webrev.05 and the new Platform enum looks reasonable to me (and thanks for the rename too). I checked the os.name mapping and it looks right. Whether it's Error or InternalError for an unrecognized platform probably doesn't matter here. If Roger is okay with this version then I think we should get this merge done and look at other refactoring with a later change. Also if src/solaris is renamed (and I know many of want do this) then it's another opportunity to come back to the topic too. -Alan. From mandy.chung at oracle.com Wed Apr 2 15:46:21 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 02 Apr 2014 08:46:21 -0700 Subject: RFR: 8035618 : Four api/org_omg/CORBA TCK tests fail under plugin only In-Reply-To: <533C2246.3080601@oracle.com> References: <533BE982.60004@oracle.com> <533C1919.4020509@oracle.com> <533C2246.3080601@oracle.com> Message-ID: <533C30CD.2010407@oracle.com> On 4/2/2014 7:44 AM, Se?n Coffey wrote: > > On 02/04/14 15:05, Alan Bateman wrote: >> On 02/04/2014 11:42, Se?n Coffey wrote: >>> I'm looking to port this fix from JDK 8 to 9. Other changes were >>> made for JDK 9 given that we have access to the >>> javaAwtAccess.getAppletContext() method when using JDK 8 as the boot >>> strap JDK for CORBA. Direct access to the sun.awt.AppContect class >>> has been removed. >>> >>> bug : https://bugs.openjdk.java.net/browse/JDK-8035618 >>> webrev : >>> http://cr.openjdk.java.net/~coffeys/webrev.8035618.jdk9.v3/webrev/ >> This mostly looks okay to me except that pmContexts should be final. >> It looks like this code is also a candidate to use computeIfAbsent so >> you could replace L251-254 with one statement. > I'll make pmContexts final before pushing. Thanks for the lambda tip. > As per trial though, it looks like CORBA code is still compiled with > -source 1.7, we can revisit after this changes. Looks good to me too. Corba's use of lambda would need to wait until the boot jdk for jdk9 will be updated to jdk8? Mandy From peter.levart at gmail.com Wed Apr 2 16:05:29 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Apr 2014 18:05:29 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533C0DFF.5020508@oracle.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> Message-ID: <533C3549.3030602@gmail.com> On 04/02/2014 03:17 PM, roger riggs wrote: > Hi, > > On 4/2/2014 6:49 AM, Peter Levart wrote: >> On 04/01/2014 09:47 PM, roger riggs wrote: >>> Hi, >>> >>> A minor point, but the Enum for LaunchMechanism can be simpler; the >>> defined enum values (1,2,3) >>> are never used and can be removed along with the extra constructor. >> >> They are used for the "mode" parameter of forkAndExec() native method. > yes, and could just as easily use the default ordinals (0,1,2). >> >>> >>> With the refactoring so far, this seems more complex and harder to >>> understand. >> > ... >> >>> >>> Other alternatives would have been to factor the common code >>> (Streams handling) >>> into a utilities class or ProcessImpl and retain the 1st class >>> subclasses (with different names) >>> for each platform or merge more up into ProcessImpl. >>> >>> Maybe it will be clearer with additional refactoring. >> >> As I said, I believe the consolidation of various Input/OutputStream >> wrappers could bring the class files number and size further down. > > yes, we can't stop yet. The only difference between the inner classes > per platform > is the choice of initializing the streams which could be handled with > a switch instead > of a subclass. > > Please continue, Roger > Right, Here it is: http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.06/ This one does away with UNIXProcess subclasses. This allowed me to restore private modifier on all fields and methods that were previously accessed from subclasses and were changed to package-private to avoid compiler generating access methods. I also replaced process reaper thread factory with a lambda. Class files produced by compiling now are: -rw-rw-r--. 1 peter peter 772 Apr 2 17:45 UNIXProcess$1.class -rw-rw-r--. 1 peter peter 2155 Apr 2 17:45 UNIXProcess$DeferredCloseInputStream.class -rw-rw-r--. 1 peter peter 2930 Apr 2 17:45 UNIXProcess$DeferredCloseProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 1082 Apr 2 17:45 UNIXProcess$LaunchMechanism.class -rw-rw-r--. 1 peter peter 4762 Apr 2 17:45 UNIXProcess$Platform.class -rw-rw-r--. 1 peter peter 1711 Apr 2 17:45 UNIXProcess$ProcessPipeInputStream.class -rw-rw-r--. 1 peter peter 949 Apr 2 17:45 UNIXProcess$ProcessPipeOutputStream.class -rw-rw-r--. 1 peter peter 9401 Apr 2 17:45 UNIXProcess.class ...8 class files totaling 23.2 KiB. Getting close to original code. Regards, Peter From luchsh at linux.vnet.ibm.com Wed Apr 2 16:34:02 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Thu, 3 Apr 2014 00:34:02 +0800 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Volker, On 2014?04?02? 23:07, Volker Simonis wrote: Hi Jonathan, thanks for updating the change. Please find my comments inline: On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu wrote: Hi Volker, Masayoshi, Thanks a lot for your review, here's the updated patch, could you pls take a look? http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis wrote: Hi Jonathan, thanks for doing this change. Please find some comments below: 1. please update the copyright year to 2014 in every file you touch Updated in new patch. 2. in CopyFiles.gmk you can simplify the change by joining the windows and aix cases because on Windows OPENJDK_TARGET_OS is the same like OPENJDK_TARGET_OS_API_DIR. So you can write: ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings $(call install-file) COPY_FILES += $(LIBDIR)/tzmappings endif I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris' as I observed on my AIX box, solaris/lib is not the directory where tzmappings was stored for AIX. So I'm keeping this change, please fix me if I was wrong about the config. Yes, but my point was to actually use OPENJDK_TARGET_OS for the construction of TZMAPPINGS_SRC as shown in the code snippet above. OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX and that should be just enough here. That's right, let me try that and also build/test on Windows platform. 3. regarding the changes proposed by Masayoshi: I agree that we should put the AIX timezone mapping code in its own function, but I don't think that getPlatformTimeZoneID() would be the right place. As far as I understand, getPlatformTimeZoneID() is used to get a platform time zone id if the environment variable "TZ" is not set. I don't know a way how this could be done on AIX (@Jonathan: maybe you know?). If there would be a way to get the time zone from some system files or so, then we should put this code into the AIX version of getPlatformTimeZoneID(). I guess we may try to use /etc/envrionment file, which is basic setting for all processes, seehttp://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm The implementation of getPlatformTimeZoneID() has been updated. That's good! But the current AIX code contributed by Jonathan, actually uses the time zone id from the "TZ" environment variable and just maps it to a Java compatible time zone id. So I'd suggest to refactor this code into a function like for example "static const char* mapPlatformToJavaTimzone(const char* tz)" and call that from findJavaTZ_md(). I think that would make the code easier to understand. Agree, and have split the code into a separate static method to do the mapping work. Good. But there's still one error in findJavaTZ_md(): 706 #ifdef _AIX 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); 708 #endif This should read: 706 #ifdef _AIX 707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz); 708 #endif because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came from getPlatformTimeZoneID(). Right, but with the second approach, there may be a minor memory leak here, as javatz was not freed before being overwritten on AIX. will post another patch on this soon. With the above fixed I'll push this one we get one more review from a reviewer (I'm currently not an official reviewer). Regards, Volker @Masayoshi: what do you think, would you agree with such a solution. 4. I agree with Masayoshi that you should use the existing getGMTOffsetID() Updated in new patch to eliminate duplication. 5. Please notice that your change breaks all Unix builds except AIX because of: 759 } 760 tzerr: 761 if (javatz == NULL) { 762 time_t offset; ... 782 } 783 #endif I think that should read: 759 760 tzerr: 761 if (javatz == NULL) { 762 time_t offset; ... 782 } 783 #endif 784 } Refactoring the code in an extra function will make that error more evident anyway. But please always build at least on one different platform (i.e. Linux) to prevent such errors in the future. My fault, sorry for the failure, should take no chance after any manual alteration. Regards, Volker On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu wrote: Hi Jonathan, The AIX specific code looks OK to me. But I'd suggest the code be moved to getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also there's a function for producing a fallback ID in "GMT?hh:mm", getGMTOffsetID() which can be called in tzerr. Thanks, Masayoshi On 3/26/2014 3:47 PM, Jonathan Lu wrote: Hi ppc-aix-port-dev, core-libs-dev, Here's a patch for JDK-8034220, http://cr.openjdk.java.net/~luchsh/JDK-8034220/ It is trying to add the a more complete timezone mapping mechanism for AIX platform. the changes are primarily based on IBM's commercial JDK code, which includes: - A new timezone mapping file added under directory jdk/src/aix/lib/ - Code to parse above config file, changed file is src/solaris/native/java/util/TimeZone_md.c - And also makefile change in make/CopyFiles.gmk to copy the config file Could you pls help to review and give comments ? Cheers - Jonathan Many thanks Jonathan Regards Jonathan From paul.sandoz at oracle.com Wed Apr 2 19:19:01 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Apr 2014 21:19:01 +0200 Subject: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms In-Reply-To: <4C2465F9-CE7B-4B43-AD73-A822C6B86F97@oracle.com> References: <5322EBF2.7030209@oracle.com> <5322F3D7.9010103@oracle.com> <94F61B19-8904-42FA-9E16-CC0A6B30FD79@oracle.com> <53230184.9090007@oracle.com> <2FCC64E3-3753-4CE0-9CC6-849FF737BFB5@oracle.com> <53232FF3.9020803@oracle.com> <6562A055-4B0E-4992-8BF9-A16EFDB09CD6@oracle.com> <533AC8C4.9080601@oracle.com> <533AE776.20209@oracle.com> <4C2465F9-CE7B-4B43-AD73-A822C6B86F97@oracle.com> Message-ID: On Apr 2, 2014, at 4:16 PM, Paul Sandoz wrote: > >>>> Regarding redundant null check, do you have a test case so I can play with it myself? >>>> >>> >>> I will send something to you later today or tomorrow. >>> > > > Still plan to send you something today :-) but later on... > See below for an inline trace, the assembler and the class that was executed with -XX:-TieredCompilation using Java 8. Paul. Inlining _isInstance on constant Class java/lang/String ! @ 9 MHFieldTest::testLoopOne (25 bytes) inline (hot) @ 8 java.lang.invoke.LambdaForm$MH/617901222::invokeExact_MT (15 bytes) inline (hot) @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) inline (hot) @ 11 java.lang.invoke.MethodHandle::type (5 bytes) accessor @ 11 java.lang.invoke.LambdaForm$MH/523429237::putObjectFieldCast (32 bytes) inline (hot) @ 1 java.lang.invoke.DirectMethodHandle::fieldOffset (9 bytes) inline (hot) @ 6 java.lang.invoke.DirectMethodHandle::checkBase (7 bytes) inline (hot) @ 1 java.lang.Object::getClass (0 bytes) (intrinsic) @ 13 java.lang.invoke.DirectMethodHandle::checkCast (9 bytes) inline (hot) @ 5 java.lang.invoke.DirectMethodHandle$Accessor::checkCast (9 bytes) inline (hot) @ 5 java.lang.Class::cast (27 bytes) inline (hot) @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) @ 28 sun.misc.Unsafe::putObject (0 bytes) (intrinsic) [Verified Entry Point] 0x000000010ccf0da0: mov %eax,-0x14000(%rsp) 0x000000010ccf0da7: push %rbp 0x000000010ccf0da8: sub $0x20,%rsp ;*synchronization entry ; - MHFieldTest::testLoopOne at -1 (line 57) 0x000000010ccf0dac: mov 0xc(%rsi),%r10d ;*getfield a ; - MHFieldTest::testLoopOne at 5 (line 57) 0x000000010ccf0db0: test %r10d,%r10d 0x000000010ccf0db3: je 0x000000010ccf0ddd ;*ifnull ; - java.lang.Class::cast at 1 (line 3257) ; - java.lang.invoke.DirectMethodHandle$Accessor::checkCast at 5 (line 441) ; - java.lang.invoke.DirectMethodHandle::checkCast at 5 (line 510) ; - java.lang.invoke.LambdaForm$MH/640070680::putObjectFieldCast at 13 ; - java.lang.invoke.LambdaForm$MH/789451787::invokeExact_MT at 11 ; - MHFieldTest::testLoopOne at 8 (line 57) 0x000000010ccf0db5: add $0x10,%rsi 0x000000010ccf0db9: mov %r10d,(%rsi) 0x000000010ccf0dbc: mov %rsi,%r10 0x000000010ccf0dbf: shr $0x9,%r10 0x000000010ccf0dc3: mov $0x18f780000,%r11 0x000000010ccf0dcd: mov %r12b,(%r11,%r10,1) ;*getfield a ; - MHFieldTest::testLoopOne at 5 (line 57) 0x000000010ccf0dd1: add $0x20,%rsp 0x000000010ccf0dd5: pop %rbp 0x000000010ccf0dd6: test %eax,-0x113ddc(%rip) # 0x000000010cbdd000 ; {poll_return} 0x000000010ccf0ddc: retq 0x000000010ccf0ddd: mov %rsi,%rbp 0x000000010ccf0de0: mov %r10d,0x4(%rsp) 0x000000010ccf0de5: mov $0xffffffad,%esi 0x000000010ccf0dea: nop 0x000000010ccf0deb: callq 0x000000010ccbc120 ; OopMap{rbp=Oop [4]=NarrowOop off=112} ;*ifnull ; - java.lang.Class::cast at 1 (line 3257) ; - java.lang.invoke.DirectMethodHandle$Accessor::checkCast at 5 (line 441) ; - java.lang.invoke.DirectMethodHandle::checkCast at 5 (line 510) ; - java.lang.invoke.LambdaForm$MH/640070680::putObjectFieldCast at 13 ; - java.lang.invoke.LambdaForm$MH/789451787::invokeExact_MT at 11 ; - MHFieldTest::testLoopOne at 8 (line 57) ; {runtime_call} 0x000000010ccf0df0: callq 0x000000010c07ace4 ;*ifnull ; - java.lang.Class::cast at 1 (line 3257) ; - java.lang.invoke.DirectMethodHandle$Accessor::checkCast at 5 (line 441) ; - java.lang.invoke.DirectMethodHandle::checkCast at 5 (line 510) ; - java.lang.invoke.LambdaForm$MH/640070680::putObjectFieldCast at 13 ; - java.lang.invoke.LambdaForm$MH/789451787::invokeExact_MT at 11 ; - MHFieldTest::testLoopOne at 8 (line 57) ; {runtime_call} import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; public class MHFieldTest { volatile String a = "A"; public String b; static final MethodHandle b_setter; static { try { b_setter = MethodHandles.lookup().findSetter(MHFieldTest.class, "b", String.class); } catch (Exception e) { throw new Error(e); } } public static void main(String[] args) { new MHFieldTest().testLoop(); } void testLoop() { for (int i = 0; i < 1000000; i++) { testLoopOne(); } } void testLoopOne() { try { b_setter.invokeExact(this, a); } catch (Throwable t) { throw new Error(t); } } } From peter.levart at gmail.com Thu Apr 3 05:01:49 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 03 Apr 2014 07:01:49 +0200 Subject: Implicit 'this' return for void methods In-Reply-To: <533A86A1.9020708@paradise.net.nz> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> Message-ID: <533CEB3D.8020501@gmail.com> On 04/01/2014 11:28 AM, Bruce Chapman wrote: > Slightly preceding Ulf's coin proposal by a few hours was > > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html > > Where I suggested the "naked dot" notation (coined in > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html) has > better value as ".. a > syntax for referring to the receiver of a method inside arguments to the > method." > > More formally, the naked dot (at the start of an expression, not > following an invocation to a void method) would refer to the receiver > of the innermost surrounding invocation expression. A: What is the receiver of the invocation of a static method? B: What is the receiver of the invocation of a constructor? Regards, Peter > > and so to answer Guy's question below in terms of my original > intention rather than Ulf's proposal, .indexof("Q") would use > myVeryLongNamedString as its receiver. > > I see particular value for these naked dot expressions in creating > fluent APIs such as builder patterns. As suggested in my coin post, > there is also value for passing enums or named constants to methods > when (as is often the case) these named constants are defined in the > same class as the method being invoked. In a highly informal sense, > the naked dot enables on demand changing of the scope to be that of > the invocation expression's receiver, > > I think with this interpretation of the meaning of naked or leading > dot, Guy's compromise restriction below is not required. > > Bruce > > > On 27/03/2014 4:51 a.m., Guy Steele wrote: >> >> I am a bit more skeptical about expressions that begin with a dot >> because of potential >> confusion about which expression is referred to: >> >> myVeryLongNamedString.subString(.indexOf("C?), .indexOf("Q?)) >> >> seems clear enough, but what about: >> >> myVeryLongNamedString.subString(.indexOf("C?) + >> otherString.length(), .indexOf("Q?)) >> >> Does the second occurrence of .indexOf use myVeryLongNamedString or >> otherString? >> >> A compromise would be to allow leading-dot expressions to occur only >> within the arguments >> of the method call whose target is the object which the leading-dot >> expressions are expected >> to use as their target, and if there are such leading-dot expressions >> within the arguments >> then the arguments must not contain any non-leading-dot field >> references or method calls. >> Just a thought for discussion. This would be considered a separate >> mechanism from the >> chaining-of-void-methods mechanism (it was a very clever idea to try >> to unify them in Ulf's >> original proposal, though). >> >> ?Guy >> >> > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > From brucechapman at paradise.net.nz Thu Apr 3 07:54:13 2014 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Thu, 03 Apr 2014 20:54:13 +1300 Subject: Implicit 'this' return for void methods In-Reply-To: <533CEB3D.8020501@gmail.com> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> <533CEB3D.8020501@gmail.com> Message-ID: <533D13A5.9000204@paradise.net.nz> On 3/04/2014 6:01 p.m., Peter Levart wrote: > On 04/01/2014 11:28 AM, Bruce Chapman wrote: >> Slightly preceding Ulf's coin proposal by a few hours was >> >> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html >> >> Where I suggested the "naked dot" notation (coined in >> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html) >> has better value as ".. a >> syntax for referring to the receiver of a method inside arguments to the >> method." >> >> More formally, the naked dot (at the start of an expression, not >> following an invocation to a void method) would refer to the receiver >> of the innermost surrounding invocation expression. > > A: What is the receiver of the invocation of a static method? > > B: What is the receiver of the invocation of a constructor? Peter, I haven't checked the JLS formal terminology but in both cases it is the class's static context, such that a naked dot could only precede static methods and fields. Bruce > > > Regards, Peter > > >> >> and so to answer Guy's question below in terms of my original >> intention rather than Ulf's proposal, .indexof("Q") would use >> myVeryLongNamedString as its receiver. >> >> I see particular value for these naked dot expressions in creating >> fluent APIs such as builder patterns. As suggested in my coin post, >> there is also value for passing enums or named constants to methods >> when (as is often the case) these named constants are defined in the >> same class as the method being invoked. In a highly informal sense, >> the naked dot enables on demand changing of the scope to be that of >> the invocation expression's receiver, >> >> I think with this interpretation of the meaning of naked or leading >> dot, Guy's compromise restriction below is not required. >> >> Bruce >> >> >> On 27/03/2014 4:51 a.m., Guy Steele wrote: >>> >>> I am a bit more skeptical about expressions that begin with a dot >>> because of potential >>> confusion about which expression is referred to: >>> >>> myVeryLongNamedString.subString(.indexOf("C?), .indexOf("Q?)) >>> >>> seems clear enough, but what about: >>> >>> myVeryLongNamedString.subString(.indexOf("C?) + >>> otherString.length(), .indexOf("Q?)) >>> >>> Does the second occurrence of .indexOf use myVeryLongNamedString or >>> otherString? >>> >>> A compromise would be to allow leading-dot expressions to occur only >>> within the arguments >>> of the method call whose target is the object which the leading-dot >>> expressions are expected >>> to use as their target, and if there are such leading-dot >>> expressions within the arguments >>> then the arguments must not contain any non-leading-dot field >>> references or method calls. >>> Just a thought for discussion. This would be considered a separate >>> mechanism from the >>> chaining-of-void-methods mechanism (it was a very clever idea to try >>> to unify them in Ulf's >>> original proposal, though). >>> >>> ?Guy >>> >>> >> >> >> --- >> This email is free from viruses and malware because avast! Antivirus >> protection is active. >> http://www.avast.com >> >> > > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From miroslav.kos at oracle.com Thu Apr 3 08:58:50 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Thu, 03 Apr 2014 10:58:50 +0200 Subject: RFR: tests for JDK-8032884 In-Reply-To: <533C14E4.9030209@oracle.com> References: <533AD97E.8080102@oracle.com> <8E460A98-F87F-48A0-A6DB-9320081054CC@oracle.com> <533C116F.20201@oracle.com> <533C14E4.9030209@oracle.com> Message-ID: <533D22CA.6000608@oracle.com> Hi Chris, the test moved: http://cr.openjdk.java.net/~mkos/8032884/jdk.02/ Thanks Miran On 02/04/14 15:47, Chris Hegarty wrote: > On 02/04/14 14:32, Miroslav Kos wrote: >> In the test, I need to do following steps: >> >> 1. compile schema file using xjc tool >> 2. compile generated sources >> 3. load generated class and via reflection API verify generated methods > > In which case, what you have is fine then. > >> Although I know how to run tool directly from the test, it seems to me >> not very elegant to run compiler directly from the test - or is there >> other way how to compile generated sources from the test? >> >> Regrading moving test - no problem, but I would suggest >> javax/xml/bind/xjc in this case - xjc is JAXB tool, not JAX-WS. Do you >> agree? > > Agreed. > > -Chris. > >> >> Thanks >> Miran >> >> >> >> On 01/04/14 18:50, Chris Hegarty wrote: >>> The tests looks fine to me. >>> >>> Trivially, you could eliminate the shell script and run xic from >>> ProcessBuilder? >>> >>> Also, does it make sense to move the test to >>> jdk/test/javax/xml/ws/xjc? With the other jaxws tests, or is xjc >>> different. >>> >>> -Chris,. >>> >>> On 1 Apr 2014, at 16:21, Miroslav Kos wrote: >>> >>>> Hi everybody, >>>> >>>> I'd like to ask for review of following tests: >>>> http://cr.openjdk.java.net/~mkos/8032884/jdk.01/ >>>> >>>> Original bug (already fixed): Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8032884 >>>> Issue fixing the bug (bulk update): >>>> https://bugs.openjdk.java.net/browse/JDK-8036030 >>>> >>>> The test verifies the source code generated by xjc tool. >>>> >>>> Thanks >>>> Miran >> From alexander.v.stepanov at oracle.com Thu Apr 3 09:01:30 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Thu, 03 Apr 2014 13:01:30 +0400 Subject: [9] Review request for 8039041: tidy warnings cleanup for javax.naming Message-ID: <533D236A.2070707@oracle.com> Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8039041 Webrev corresponding: http://cr.openjdk.java.net/~yan/8039041/webrev.00/ Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. Thanks. Regards, Alexander From Sergey.Bylokhov at oracle.com Thu Apr 3 09:17:53 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 03 Apr 2014 13:17:53 +0400 Subject: [9] Review request for 8039041: tidy warnings cleanup for javax.naming In-Reply-To: <533D236A.2070707@oracle.com> References: <533D236A.2070707@oracle.com> Message-ID: <533D2741.8050202@oracle.com> Hello, I think doclint should checks this type of issues? On 03.04.2014 13:01, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8039041 > > Webrev corresponding: > http://cr.openjdk.java.net/~yan/8039041/webrev.00/ > > Just a minor cleanup of javadoc to avoid tidy warnings; no other code > affected. > > Thanks. > > Regards, > Alexander -- Best regards, Sergey. From sean.coffey at oracle.com Thu Apr 3 09:43:56 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 03 Apr 2014 10:43:56 +0100 Subject: RFR : 8039131: CORBA build issue : sun.misc.JavaAWTAccess Message-ID: <533D2D5C.20503@oracle.com> The CORBA build issue continues. I was incorrectly using 7u40 as the bootstrap JDK. 7u7 is still the version that RE uses and that causes an issue since sun.misc.JavaAWTAccess wasn't introduced until 7u9. The fix proposed is short term. There's a discussion underway on build-dev to bump the JDK bootstrap version to JDK 8 for JDK 9 builds. Build and tests are good. I've used 7u7 this time for bootstrap! bug : https://bugs.openjdk.java.net/browse/JDK-8039131 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8039131/webrev/ regards, Sean. From chris.hegarty at oracle.com Thu Apr 3 09:54:34 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 3 Apr 2014 10:54:34 +0100 Subject: RFR : 8039131: CORBA build issue : sun.misc.JavaAWTAccess In-Reply-To: <533D2D5C.20503@oracle.com> References: <533D2D5C.20503@oracle.com> Message-ID: The change looks ok to me. We really need to get of 7u7 as the bootstrap. You could simply catch ReflectiveOpertionException, but what you have is more specific. -Chris. On 3 Apr 2014, at 10:43, Se?n Coffey wrote: > The CORBA build issue continues. I was incorrectly using 7u40 as the bootstrap JDK. 7u7 is still the version that RE uses and that causes an issue since sun.misc.JavaAWTAccess wasn't introduced until 7u9. > > The fix proposed is short term. There's a discussion underway on build-dev to bump the JDK bootstrap version to JDK 8 for JDK 9 builds. > > Build and tests are good. I've used 7u7 this time for bootstrap! > > bug : https://bugs.openjdk.java.net/browse/JDK-8039131 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8039131/webrev/ > > regards, > Sean. From Alan.Bateman at oracle.com Thu Apr 3 09:59:10 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Apr 2014 10:59:10 +0100 Subject: RFR : 8039131: CORBA build issue : sun.misc.JavaAWTAccess In-Reply-To: <533D2D5C.20503@oracle.com> References: <533D2D5C.20503@oracle.com> Message-ID: <533D30EE.3030900@oracle.com> I'd suggest holding off a bit until there is a conclusion on the build-dev list (Folks using 7u7 will need to update anyway, if not today then maybe very soon). -Alan On 03/04/2014 10:43, Se?n Coffey wrote: > The CORBA build issue continues. I was incorrectly using 7u40 as the > bootstrap JDK. 7u7 is still the version that RE uses and that causes > an issue since sun.misc.JavaAWTAccess wasn't introduced until 7u9. > > The fix proposed is short term. There's a discussion underway on > build-dev to bump the JDK bootstrap version to JDK 8 for JDK 9 builds. > > Build and tests are good. I've used 7u7 this time for bootstrap! > > bug : https://bugs.openjdk.java.net/browse/JDK-8039131 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8039131/webrev/ > > regards, > Sean. From sean.coffey at oracle.com Thu Apr 3 10:17:40 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 03 Apr 2014 11:17:40 +0100 Subject: RFR : 8039131: CORBA build issue : sun.misc.JavaAWTAccess In-Reply-To: <533D30EE.3030900@oracle.com> References: <533D2D5C.20503@oracle.com> <533D30EE.3030900@oracle.com> Message-ID: <533D3544.9020009@oracle.com> Thanks for the reviews. Let's see how the build-dev thread [1] progresses over the next few hours then. I don't think we'll be able to make a decision to flip the bootstrap JDK that quickly but let's see. I'd like to push this later today if no bootstrap decision is made. I don't want to affect another nightly build run. This push should be cheap and in any case - I want to revert the current use of reflection when we do get the bootstrap version bumped. regards, Sean. [1] http://mail.openjdk.java.net/pipermail/build-dev/2014-April/012283.html On 03/04/2014 10:59, Alan Bateman wrote: > > I'd suggest holding off a bit until there is a conclusion on the > build-dev list (Folks using 7u7 will need to update anyway, if not > today then maybe very soon). > > -Alan > > > On 03/04/2014 10:43, Se?n Coffey wrote: >> The CORBA build issue continues. I was incorrectly using 7u40 as the >> bootstrap JDK. 7u7 is still the version that RE uses and that causes >> an issue since sun.misc.JavaAWTAccess wasn't introduced until 7u9. >> >> The fix proposed is short term. There's a discussion underway on >> build-dev to bump the JDK bootstrap version to JDK 8 for JDK 9 builds. >> >> Build and tests are good. I've used 7u7 this time for bootstrap! >> >> bug : https://bugs.openjdk.java.net/browse/JDK-8039131 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8039131/webrev/ >> >> regards, >> Sean. > From peter.levart at gmail.com Thu Apr 3 10:45:09 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 03 Apr 2014 12:45:09 +0200 Subject: Implicit 'this' return for void methods In-Reply-To: <533D13A5.9000204@paradise.net.nz> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> <533CEB3D.8020501@gmail.com> <533D13A5.9000204@paradise.net.nz> Message-ID: <533D3BB5.3000702@gmail.com> On 04/03/2014 09:54 AM, Bruce Chapman wrote: > On 3/04/2014 6:01 p.m., Peter Levart wrote: >> On 04/01/2014 11:28 AM, Bruce Chapman wrote: >>> Slightly preceding Ulf's coin proposal by a few hours was >>> >>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html >>> >>> Where I suggested the "naked dot" notation (coined in >>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html) >>> has better value as ".. a >>> syntax for referring to the receiver of a method inside arguments to >>> the >>> method." >>> >>> More formally, the naked dot (at the start of an expression, not >>> following an invocation to a void method) would refer to the >>> receiver of the innermost surrounding invocation expression. >> >> A: What is the receiver of the invocation of a static method? >> >> B: What is the receiver of the invocation of a constructor? > > Peter, > > I haven't checked the JLS formal terminology but in both cases it is > the class's static context, such that a naked dot could only precede > static methods and fields. > > Bruce I'm asking about the meaning of the following (not very optimal) example: myVeryLongNamedString.substring(Math.min(.indexOf("A"), .indexOf("B")), Math.max(.indexOf("A"), .indexOf("B"))); You're suggesting that invocations of static methods don't count towards the innermost invocation, since they don't have a "receiver" therefore the search for innermost receiver skips them? If so, then the following code: myVeryLongNamedString.substring(min(.indexOf("A"), .indexOf("B")), max(.indexOf("A"), .indexOf("B"))); could have two different meanings depending on whether unqualified min() and max() are invocation of static vs. instance methods. That's very hard to read then. Regards, Peter > >> >> >> Regards, Peter >> >> >>> >>> and so to answer Guy's question below in terms of my original >>> intention rather than Ulf's proposal, .indexof("Q") would use >>> myVeryLongNamedString as its receiver. >>> >>> I see particular value for these naked dot expressions in creating >>> fluent APIs such as builder patterns. As suggested in my coin post, >>> there is also value for passing enums or named constants to methods >>> when (as is often the case) these named constants are defined in the >>> same class as the method being invoked. In a highly informal sense, >>> the naked dot enables on demand changing of the scope to be that of >>> the invocation expression's receiver, >>> >>> I think with this interpretation of the meaning of naked or leading >>> dot, Guy's compromise restriction below is not required. >>> >>> Bruce >>> >>> >>> On 27/03/2014 4:51 a.m., Guy Steele wrote: >>>> >>>> I am a bit more skeptical about expressions that begin with a dot >>>> because of potential >>>> confusion about which expression is referred to: >>>> >>>> myVeryLongNamedString.subString(.indexOf("C?), .indexOf("Q?)) >>>> >>>> seems clear enough, but what about: >>>> >>>> myVeryLongNamedString.subString(.indexOf("C?) + >>>> otherString.length(), .indexOf("Q?)) >>>> >>>> Does the second occurrence of .indexOf use myVeryLongNamedString or >>>> otherString? >>>> >>>> A compromise would be to allow leading-dot expressions to occur >>>> only within the arguments >>>> of the method call whose target is the object which the leading-dot >>>> expressions are expected >>>> to use as their target, and if there are such leading-dot >>>> expressions within the arguments >>>> then the arguments must not contain any non-leading-dot field >>>> references or method calls. >>>> Just a thought for discussion. This would be considered a separate >>>> mechanism from the >>>> chaining-of-void-methods mechanism (it was a very clever idea to >>>> try to unify them in Ulf's >>>> original proposal, though). >>>> >>>> ?Guy >>>> >>>> >>> >>> >>> --- >>> This email is free from viruses and malware because avast! Antivirus >>> protection is active. >>> http://www.avast.com >>> >>> >> >> > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > From peter.levart at gmail.com Thu Apr 3 10:49:48 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 03 Apr 2014 12:49:48 +0200 Subject: Implicit 'this' return for void methods In-Reply-To: <533D13A5.9000204@paradise.net.nz> References: <1395777807.766976527.vkqsk9qi@frv39.fwdcdn.com> <53328D08.1000307@CoSoCo.de> <533A86A1.9020708@paradise.net.nz> <533CEB3D.8020501@gmail.com> <533D13A5.9000204@paradise.net.nz> Message-ID: <533D3CCC.4060204@gmail.com> On 04/03/2014 09:54 AM, Bruce Chapman wrote: > On 3/04/2014 6:01 p.m., Peter Levart wrote: >> On 04/01/2014 11:28 AM, Bruce Chapman wrote: >>> Slightly preceding Ulf's coin proposal by a few hours was >>> >>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html >>> >>> Where I suggested the "naked dot" notation (coined in >>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html) >>> has better value as ".. a >>> syntax for referring to the receiver of a method inside arguments to >>> the >>> method." >>> >>> More formally, the naked dot (at the start of an expression, not >>> following an invocation to a void method) would refer to the >>> receiver of the innermost surrounding invocation expression. >> >> A: What is the receiver of the invocation of a static method? >> >> B: What is the receiver of the invocation of a constructor? > > Peter, > > I haven't checked the JLS formal terminology but in both cases it is > the class's static context, such that a naked dot could only precede > static methods and fields. > > Bruce Sorry Bruce, I've got it now. That sounds reasonable. Regards, Peter > >> >> >> Regards, Peter >> >> >>> >>> and so to answer Guy's question below in terms of my original >>> intention rather than Ulf's proposal, .indexof("Q") would use >>> myVeryLongNamedString as its receiver. >>> >>> I see particular value for these naked dot expressions in creating >>> fluent APIs such as builder patterns. As suggested in my coin post, >>> there is also value for passing enums or named constants to methods >>> when (as is often the case) these named constants are defined in the >>> same class as the method being invoked. In a highly informal sense, >>> the naked dot enables on demand changing of the scope to be that of >>> the invocation expression's receiver, >>> >>> I think with this interpretation of the meaning of naked or leading >>> dot, Guy's compromise restriction below is not required. >>> >>> Bruce >>> >>> >>> On 27/03/2014 4:51 a.m., Guy Steele wrote: >>>> >>>> I am a bit more skeptical about expressions that begin with a dot >>>> because of potential >>>> confusion about which expression is referred to: >>>> >>>> myVeryLongNamedString.subString(.indexOf("C?), .indexOf("Q?)) >>>> >>>> seems clear enough, but what about: >>>> >>>> myVeryLongNamedString.subString(.indexOf("C?) + >>>> otherString.length(), .indexOf("Q?)) >>>> >>>> Does the second occurrence of .indexOf use myVeryLongNamedString or >>>> otherString? >>>> >>>> A compromise would be to allow leading-dot expressions to occur >>>> only within the arguments >>>> of the method call whose target is the object which the leading-dot >>>> expressions are expected >>>> to use as their target, and if there are such leading-dot >>>> expressions within the arguments >>>> then the arguments must not contain any non-leading-dot field >>>> references or method calls. >>>> Just a thought for discussion. This would be considered a separate >>>> mechanism from the >>>> chaining-of-void-methods mechanism (it was a very clever idea to >>>> try to unify them in Ulf's >>>> original proposal, though). >>>> >>>> ?Guy >>>> >>>> >>> >>> >>> --- >>> This email is free from viruses and malware because avast! Antivirus >>> protection is active. >>> http://www.avast.com >>> >>> >> >> > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > From lance.andersen at oracle.com Thu Apr 3 10:59:45 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Thu, 3 Apr 2014 06:59:45 -0400 Subject: [9] Review request for 8039041: tidy warnings cleanup for javax.naming In-Reply-To: <533D236A.2070707@oracle.com> References: <533D236A.2070707@oracle.com> Message-ID: Looks fine 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 Apr 3, 2014, at 5:01 AM, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8039041 > > Webrev corresponding: > http://cr.openjdk.java.net/~yan/8039041/webrev.00/ > > Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. > > Thanks. > > Regards, > Alexander From Alan.Bateman at oracle.com Thu Apr 3 11:14:53 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Apr 2014 12:14:53 +0100 Subject: [9] Review request for 8039041: tidy warnings cleanup for javax.naming In-Reply-To: <533D236A.2070707@oracle.com> References: <533D236A.2070707@oracle.com> Message-ID: <533D42AD.4040506@oracle.com> On 03/04/2014 10:01, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8039041 > > Webrev corresponding: > http://cr.openjdk.java.net/~yan/8039041/webrev.00/ > > Just a minor cleanup of javadoc to avoid tidy warnings; no other code > affected. This looks okay to me. -Alan. From aleksej.efimov at oracle.com Thu Apr 3 12:13:14 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Thu, 03 Apr 2014 16:13:14 +0400 Subject: RFR: 8029073: (corba) New connection reclaimed when number of connection is greater than highwatermark Message-ID: <533D505A.7060109@oracle.com> Hello, Can I have a review [1] for a problem [2] in CORBA connections pool implementation: There is a reclamation possibility of newly created connections. The root cause of such behavior is that newly created connections are not timestamped (timestamp = 0) before addition to connection cache. When the reclamation is in process it searches for connection with lowest timestamp value and as a result the new connection will be reclaimed if there was no read/write activity. The proposed fix simply timestamps the connection before adding it to the cache, similar to the CorbaClientRequestDispatcherImpl. Thank you, Aleksej [1] webrev: http://cr.openjdk.java.net/~aefimov/8029073/webrev.00 [2] bug: https://bugs.openjdk.java.net/browse/JDK-8029073 From chris.hegarty at oracle.com Thu Apr 3 12:52:35 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 3 Apr 2014 13:52:35 +0100 Subject: RFR: tests for JDK-8032884 In-Reply-To: <533D22CA.6000608@oracle.com> References: <533AD97E.8080102@oracle.com> <8E460A98-F87F-48A0-A6DB-9320081054CC@oracle.com> <533C116F.20201@oracle.com> <533C14E4.9030209@oracle.com> <533D22CA.6000608@oracle.com> Message-ID: On 3 Apr 2014, at 09:58, Miroslav Kos wrote: > Hi Chris, > the test moved: http://cr.openjdk.java.net/~mkos/8032884/jdk.02/ Pushed to jdk9/dev http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f6c3cb79d761 -Chris. > Thanks > Miran > > > > On 02/04/14 15:47, Chris Hegarty wrote: >> On 02/04/14 14:32, Miroslav Kos wrote: >>> In the test, I need to do following steps: >>> >>> 1. compile schema file using xjc tool >>> 2. compile generated sources >>> 3. load generated class and via reflection API verify generated methods >> >> In which case, what you have is fine then. >> >>> Although I know how to run tool directly from the test, it seems to me >>> not very elegant to run compiler directly from the test - or is there >>> other way how to compile generated sources from the test? >>> >>> Regrading moving test - no problem, but I would suggest >>> javax/xml/bind/xjc in this case - xjc is JAXB tool, not JAX-WS. Do you >>> agree? >> >> Agreed. >> >> -Chris. >> >>> >>> Thanks >>> Miran >>> >>> >>> >>> On 01/04/14 18:50, Chris Hegarty wrote: >>>> The tests looks fine to me. >>>> >>>> Trivially, you could eliminate the shell script and run xic from >>>> ProcessBuilder? >>>> >>>> Also, does it make sense to move the test to >>>> jdk/test/javax/xml/ws/xjc? With the other jaxws tests, or is xjc >>>> different. >>>> >>>> -Chris,. >>>> >>>> On 1 Apr 2014, at 16:21, Miroslav Kos wrote: >>>> >>>>> Hi everybody, >>>>> >>>>> I'd like to ask for review of following tests: >>>>> http://cr.openjdk.java.net/~mkos/8032884/jdk.01/ >>>>> >>>>> Original bug (already fixed): Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8032884 >>>>> Issue fixing the bug (bulk update): >>>>> https://bugs.openjdk.java.net/browse/JDK-8036030 >>>>> >>>>> The test verifies the source code generated by xjc tool. >>>>> >>>>> Thanks >>>>> Miran >>> > From sean.coffey at oracle.com Thu Apr 3 13:57:24 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 03 Apr 2014 14:57:24 +0100 Subject: RFR: 8029073: (corba) New connection reclaimed when number of connection is greater than highwatermark In-Reply-To: <533D505A.7060109@oracle.com> References: <533D505A.7060109@oracle.com> Message-ID: <533D68C4.60600@oracle.com> Looks good to me Aleksej. regards, Sean. On 03/04/2014 13:13, Aleksej Efimov wrote: > Hello, > Can I have a review [1] for a problem [2] in CORBA connections pool > implementation: There is a reclamation possibility of newly created > connections. The root cause of such behavior is that newly created > connections are not timestamped (timestamp = 0) before addition to > connection cache. When the reclamation is in process it searches for > connection with lowest timestamp value and as a result the new > connection will be reclaimed if there was no read/write activity. > The proposed fix simply timestamps the connection before adding it to > the cache, similar to the CorbaClientRequestDispatcherImpl. > > Thank you, > Aleksej > > [1] webrev: http://cr.openjdk.java.net/~aefimov/8029073/webrev.00 > [2] bug: https://bugs.openjdk.java.net/browse/JDK-8029073 From masayoshi.okutsu at oracle.com Thu Apr 3 14:21:57 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 03 Apr 2014 23:21:57 +0900 Subject: RFR: 8038306: (tz) Support tzdata2014b In-Reply-To: <533BEC8E.8080106@oracle.com> References: <533BEC8E.8080106@oracle.com> Message-ID: <533D6E85.3030108@oracle.com> Hi Aleksej, Sorry, but I forgot about the generic names. "Coordinated Universal Time" and "UTC"shouldn't be the generic names. You will need to "invent" the names, something like "Troll Time". Thanks, Masayoshi On 4/2/2014 7:55 PM, Aleksej Efimov wrote: > Hello, > > Can I have a review for the latest (2014b) TZ data integration to > JDK9. The webrev can be located here [1]. > > The following set of tests were executed without failures: > test/sun/util/calendar test/java/util/Calendar > test/sun/util/resources/TimeZone test/sun/util/calendar > test/java/util/TimeZone test/java/time test/java/util/Formatter > test/closed/java/util/Calendar\ test/closed/java/util/TimeZone > > Thank you, > Aleksej > > [1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/ > [2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306 From aleksej.efimov at oracle.com Thu Apr 3 14:29:00 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Thu, 03 Apr 2014 18:29:00 +0400 Subject: RFR: 8038306: (tz) Support tzdata2014b In-Reply-To: <533D6E85.3030108@oracle.com> References: <533BEC8E.8080106@oracle.com> <533D6E85.3030108@oracle.com> Message-ID: <533D702C.50100@oracle.com> Masayoshi, How about "Troll Time" and "ATT" for generic long and short names across all locales? The "TT" is used as generic name for "Asia/Taipei" in "zh_TW" locale, because of that I propose "ATT" (A - for Antractica) - it's not used anywhere. Thanks, Aleksej On 04/03/2014 06:21 PM, Masayoshi Okutsu wrote: > Hi Aleksej, > > Sorry, but I forgot about the generic names. "Coordinated Universal > Time" and "UTC"shouldn't be the generic names. You will need to > "invent" the names, something like "Troll Time". > > Thanks, > Masayoshi > > On 4/2/2014 7:55 PM, Aleksej Efimov wrote: >> Hello, >> >> Can I have a review for the latest (2014b) TZ data integration to >> JDK9. The webrev can be located here [1]. >> >> The following set of tests were executed without failures: >> test/sun/util/calendar test/java/util/Calendar >> test/sun/util/resources/TimeZone test/sun/util/calendar >> test/java/util/TimeZone test/java/time test/java/util/Formatter >> test/closed/java/util/Calendar\ test/closed/java/util/TimeZone >> >> Thank you, >> Aleksej >> >> [1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/ >> [2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306 > From xueming.shen at oracle.com Thu Apr 3 21:27:12 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 03 Apr 2014 14:27:12 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: References: <532AA782.5030809@gmail.com> <532B246F.20302@oracle.com> <532CF69A.3060301@oracle.com> Message-ID: <533DD230.1050105@oracle.com> On 03/25/2014 02:07 PM, Jeremy Manson wrote: > Okay. Thanks, Sherman. Here's an updated version. > > I've diverged a bit from Peter's version. In this version, appendExpandedReplacement takes a StringBuilder. The implications is that In the StringBuilder case, it saves creating a new StringBuilder object. In the StringBuffer case, it creates a new StringBuilder, but it doesn't have to acquire and release all of those locks. Hi Jeremy, It appears the "optimized" StringBuilder version will cause following test case failure, in which the "xyz" will be copied into the result buffer, even when the replacement string triggers a IAE. // Check nothing has been appended into the output buffer if // the replacement string triggers IllegalArgumentException. Pattern p = Pattern.compile("(abc)"); Matcher m = p.matcher("abcd"); StringBuilder result = new StringBuilder(); try { m.appendReplacement(result, ("xyz$g")); } catch (IllegalArgumentException iae) { if (result.length() != 0) System.err.println(" FAILED"); } We may have to either catch the IAE and reset the sb, or create a new sb, as the StringBuffer does. -Sherman > > I also noticed a redundant cast to (int), which I removed. > > Jeremy > > > On Fri, Mar 21, 2014 at 7:34 PM, Xueming Shen > wrote: > > let's add the StringBuilder method(s), if you can provide an updated version, I can run the rest (since it's > to add new api, there is an internal CCC process need to go through). > > -Sherman > > > On 3/21/14 5:18 PM, Jeremy Manson wrote: >> So, this is all a little opaque to me. How do we make the go/no-go decision on something like this? Everyone who has chimed in seems to think it is a good idea. >> >> Jeremy >> >> >> On Thu, Mar 20, 2014 at 10:38 AM, Jeremy Manson > wrote: >> >> Sherman, >> >> If you had released it then (which you wouldn't have been able to do, because you would have to wait another two years for Java 7), you would have found that it improved performance even with C2. It is only post-escape-analysis that the performance in C2 equalized. >> >> Anyway, I think adding the StringBuilder variant and deferring / dealing with the Appendable differently is the right approach, FWIW. >> >> Jeremy >> >> >> On Thu, Mar 20, 2014 at 10:25 AM, Xueming Shen > wrote: >> >> 2009? I do have something similar back to 2009 :-) >> >> http://cr.openjdk.java.net/~sherman/regex_replace/webrev/ >> >> Then the ball was dropped around the discussion of whether or not >> the IOE should be thrown. >> >> But if we are going to/have to have explicit StringBuilder/Buffer pair >> anyway, then we can keep the Appendable version as private for now >> and deal with the StringBuilder and Appendable as two separate >> issues. >> >> -Sherman >> >> >> On 03/20/2014 09:52 AM, Jeremy Manson wrote: >> >> That's definitely an improvement - I think that when I wrote this (circa >> 2009), I didn't think about Appendable. >> >> I take it my argument convinced someone? :) >> >> Jeremy >> >> >> On Thu, Mar 20, 2014 at 1:32 AM, Peter Levart>wrote: >> >> On 03/19/2014 06:51 PM, Jeremy Manson wrote: >> >> I'm told that the diff didn't make it. I've put it in a Google drive >> folder... >> >> https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ >> edit?usp=sharing >> >> Jeremy >> >> Hi Jeremy, >> >> Your factoring-out of expandReplacement() method exposed an opportunity to >> further optimize the code. Instead of creating intermediate StringBuilder >> instance for each expandReplacement() call, this method could append >> directly to resulting StringBuffer/StringBuilder, like in the following: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ >> webrev.01/ >> >> >> Regards, Peter >> >> >> >> On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson> >> wrote: >> >> Hi folks, >> >> We've had this internally for a while, and I keep meaning to bring it up >> here. The Matcher class has a few public methods that take >> StringBuffers, >> and we've found it useful to add similar versions that take >> StringBuilders. >> >> It has two benefits: >> >> - Users don't have to convert from one to the other when they want to use >> the method in question. The symmetry is nice. >> >> - The StringBuilder variants are faster (if lock optimizations don't kick >> in, which happens in the interpreter and the client compiler). For >> interpreted / client-compiled code, we saw something like a 25% speedup >> on >> String.replaceAll(), which calls into this code. >> >> Any interest? Diff attached. >> >> Jeremy >> >> >> >> >> > > From christian.thalinger at oracle.com Thu Apr 3 22:33:36 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Apr 2014 15:33:36 -0700 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <5332EBD5.8090100@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> <53305D76.7080009@oracle.com> <5332EBD5.8090100@oracle.com> Message-ID: <433BC760-0B2E-4894-988B-7B4D388A9F71@oracle.com> On Mar 26, 2014, at 8:01 AM, Vladimir Ivanov wrote: > Here's a version with the new naming scheme: > http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03.naming > > I like existing naming scheme and OBJECT/VOID/LONG/etc names are quite popular(e.g. Wrapper & ASM (Opcodes) use them). Of course they are popular because these are the type names. There is no type L; it?s an object. I don?t understand why we have to use different names just because they are used in other namespaces. This is not a C define. > So, I'm in favor of leaving it as is. > > Best regards, > Vladimir Ivanov > > On 3/26/14 12:24 AM, Christian Thalinger wrote: >> + enum BasicType { >> + L_TYPE('L', Object.class, Wrapper.OBJECT), // all reference types >> + I_TYPE('I', int.class, Wrapper.INT), >> + J_TYPE('J', long.class, Wrapper.LONG), >> + F_TYPE('F', float.class, Wrapper.FLOAT), >> + D_TYPE('D', double.class, Wrapper.DOUBLE), // all primitive types >> + V_TYPE('V', void.class, Wrapper.VOID); // not valid in all contexts >> >> I would suggest to not name them X_TYPE but give them meaningful names like Int, Float, Void. The enum BasicType already infers that it?s a type. If you think it?s not clear that it?s a type just use BasicType.Double in that places. >> >> On Mar 24, 2014, at 9:29 AM, Vladimir Ivanov wrote: >> >>> Updated version: >>> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03/ >>> >>> - changed the way how arrays of types are created: >>> static final BasicType[] ALL_TYPES = BasicType.values(); >>> static final BasicType[] ARG_TYPES = Arrays.copyOf(ALL_TYPES, ALL_TYPES.length-1); >>> >>> - added a test for BasicType (LambdaFormTest.testBasicType). >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 3/22/14 2:08 AM, Vladimir Ivanov wrote: >>>> John, thanks for the feedback. >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.02 >>>> >>>> Also moved LambdaForm.testShortenSignature() into a stand-alone unit test. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 3/21/14 10:54 PM, John Rose wrote: >>>>> On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov >>>>> > >>>>> wrote: >>>>> >>>>>> Thanks for the feedback. >>>>>> >>>>>> What do you think about the following: >>>>>> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/ >>>>> >>>>> That looks nice. Strong typing; who woulda' thunk it. :-) >>>>> >>>>> The uses of ".ordinal()" are the extra cost relative to using just small >>>>> integers. They seem totally reasonable in the code. >>>>> >>>>> I suggest either wrapping "ordinal" as something like "id" or else >>>>> changing temp names like "id" to "ord", to reinforce the use of a common >>>>> name. >>>>> >>>>> Don't make the enum class public. And especially don't make the mutable >>>>> arrays public: >>>>> >>>>> + public static final BasicType[] ALL_TYPES = { L_TYPE, I_TYPE, >>>>> J_TYPE, F_TYPE, D_TYPE, V_TYPE }; >>>>> + public static final BasicType[] ARG_TYPES = { L_TYPE, I_TYPE, >>>>> J_TYPE, F_TYPE, D_TYPE }; >>>>> >>>>> ? John >>>>> >>>>> P.S. That would only be safe if we had (what we don't yet) a notion of >>>>> frozen arrays like: >>>>> >>>>> + public static final BasicType final[] ALL_TYPES = { L_TYPE, >>>>> I_TYPE, J_TYPE, F_TYPE, D_TYPE, V_TYPE }; >>>>> + public static final BasicType final[] ARG_TYPES = { L_TYPE, >>>>> I_TYPE, J_TYPE, F_TYPE, D_TYPE }; >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From mike.duigou at oracle.com Thu Apr 3 23:42:23 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 3 Apr 2014 16:42:23 -0700 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: <533255B1.7020400@oracle.com> References: <533255B1.7020400@oracle.com> Message-ID: <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> On Mar 25 2014, at 21:21 , David Holmes wrote: > Mike, > > On 26/03/2014 6:37 AM, Mike Duigou wrote: >> Hello all; >> >> Recently HotSpot gained additional support for transactional memory, . This patch is a libraries followon to that change. RTM and other transactional memory implementations benefit from clustering writes towards the end of the transaction whenever possible. This change optimizes the behaviour of two collection classes, Hashtable and Vector by moving several field updates to cluster them together near the end of the transaction. Yes, we know, these are obsolete collections but these two classes were used as the basis for the original benchmarking and evaluation during the development of the transactional memory JVM features. Future changes providing similar optimizations to other collections will be pursued when it can be shown they offer value and don't add a cost to non TM performance (TM is not yet a mainstream feature). >> >> https://bugs.openjdk.java.net/browse/JDK-8020860 >> http://cr.openjdk.java.net/~mduigou/JDK-8020860/0/webrev/ >> >> It is not expected that this change will have any meaningful impact upon performance (either positive or negative) outside of TM-enabled configurations. The main change is to move existing field updates towards the end of the transaction and avoid conditionals between field updates. >> >> There is a slight behaviour change introduced in this changeset. Previously some methods updated the modcount unconditionally updated even when an ArrayIndexOutOfBoundsException was subsequently thrown for an invalid index and the Vector was not modified. With this change the modcount will only be updated if the Vector is actually changed. It is not expected that applications will have relied or should have relied on this behaviour. > > I could live with that change in behaviour, but this change completely breaks the fail-fast semantics of the iterators in some cases! If you don't update modCount until after the change is complete, the iterator may access the updated state and not throw CME!. For Vector I don't see this. The Iterator accesses to the data structures is always done with the Vector.this lock held. The re-ordering would only be observable to another thread if it is reading the Vector fields without holding the lock. I am not sure we should worry about that case. For Hashtable Iterator there is no synchronization on the owning Hashtable except during the remove() method. It is unclear why the Hashtable iterators were not written in the same way as Vector. It seems like there would be massive disruption to adding synchronization to Hashtable's itertors. Are the Hashtable iterators actually fast-fail? Without synchronization this is not guaranteed since the writes may not be visible and Hashtable iterator failure behaviour is already likely to vary between platforms/architectures. With RTM it's presumed that the writes will NOT be visible until the transaction completes. This implies that the failure mode from Hashtable iterators is likely to change just by turning RTM locking on whether we make this code change or not. :-( > I think this change is misguided. I think we are fine for Vector, but Hashtable gives me concerns even in it's current state. Suggestions welcome. Mike > > David > ----- > > >> Mike >> From jeremymanson at google.com Thu Apr 3 23:43:44 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 3 Apr 2014 16:43:44 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: <533DD230.1050105@oracle.com> References: <532AA782.5030809@gmail.com> <532B246F.20302@oracle.com> <532CF69A.3060301@oracle.com> <533DD230.1050105@oracle.com> Message-ID: Good catch, thanks. I think we should probably just go with the (equivalent to the) StringBuffer variant. I'm pretty loathe to modify the StringBuilder directly if we are going to back that change out. Do you want me to generate a new patch? Jeremy On Thu, Apr 3, 2014 at 2:27 PM, Xueming Shen wrote: > On 03/25/2014 02:07 PM, Jeremy Manson wrote: > > Okay. Thanks, Sherman. Here's an updated version. > > I've diverged a bit from Peter's version. In this version, > appendExpandedReplacement takes a StringBuilder. The implications is that > In the StringBuilder case, it saves creating a new StringBuilder object. > In the StringBuffer case, it creates a new StringBuilder, but it doesn't > have to acquire and release all of those locks. > > > Hi Jeremy, > > It appears the "optimized" StringBuilder version will cause following test > case failure, > in which the "xyz" will be copied into the result buffer, even when the > replacement > string triggers a IAE. > > // Check nothing has been appended into the output buffer if > // the replacement string triggers IllegalArgumentException. > Pattern p = Pattern.compile("(abc)"); > Matcher m = p.matcher("abcd"); > StringBuilder result = new StringBuilder(); > try { > m.appendReplacement(result, ("xyz$g")); > } catch (IllegalArgumentException iae) { > if (result.length() != 0) > System.err.println(" FAILED"); > > } > > We may have to either catch the IAE and reset the sb, or create > a new sb, as the StringBuffer does. > > -Sherman > > > > > I also noticed a redundant cast to (int), which I removed. > > Jeremy > > > On Fri, Mar 21, 2014 at 7:34 PM, Xueming Shen wrote: > > let's add the StringBuilder method(s), if you can provide an updated > version, I can run the rest (since it's > to add new api, there is an internal CCC process need to go through). > > -Sherman > > > On 3/21/14 5:18 PM, Jeremy Manson wrote: > > So, this is all a little opaque to me. How do we make the go/no-go > decision on something like this? Everyone who has chimed in seems to think > it is a good idea. > > Jeremy > > > On Thu, Mar 20, 2014 at 10:38 AM, Jeremy Manson wrote: > > Sherman, > > If you had released it then (which you wouldn't have been able to do, > because you would have to wait another two years for Java 7), you would > have found that it improved performance even with C2. It is only > post-escape-analysis that the performance in C2 equalized. > > Anyway, I think adding the StringBuilder variant and deferring / dealing > with the Appendable differently is the right approach, FWIW. > > Jeremy > > > On Thu, Mar 20, 2014 at 10:25 AM, Xueming Shen wrote: > > 2009? I do have something similar back to 2009 :-) > > http://cr.openjdk.java.net/~sherman/regex_replace/webrev/ > > Then the ball was dropped around the discussion of whether or not > the IOE should be thrown. > > But if we are going to/have to have explicit StringBuilder/Buffer pair > anyway, then we can keep the Appendable version as private for now > and deal with the StringBuilder and Appendable as two separate > issues. > > -Sherman > > > On 03/20/2014 09:52 AM, Jeremy Manson wrote: > > That's definitely an improvement - I think that when I wrote this (circa > 2009), I didn't think about Appendable. > > I take it my argument convinced someone? :) > > Jeremy > > > On Thu, Mar 20, 2014 at 1:32 AM, Peter Levart >wrote: > > On 03/19/2014 06:51 PM, Jeremy Manson wrote: > > I'm told that the diff didn't make it. I've put it in a Google drive > folder... > > https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ > edit?usp=sharing > > Jeremy > > Hi Jeremy, > > Your factoring-out of expandReplacement() method exposed an opportunity to > further optimize the code. Instead of creating intermediate StringBuilder > instance for each expandReplacement() call, this method could append > directly to resulting StringBuffer/StringBuilder, like in the following: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ > webrev.01/ > > > Regards, Peter > > > > On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson > wrote: > > Hi folks, > > We've had this internally for a while, and I keep meaning to bring it up > here. The Matcher class has a few public methods that take > StringBuffers, > and we've found it useful to add similar versions that take > StringBuilders. > > It has two benefits: > > - Users don't have to convert from one to the other when they want to use > the method in question. The symmetry is nice. > > - The StringBuilder variants are faster (if lock optimizations don't kick > in, which happens in the interpreter and the client compiler). For > interpreted / client-compiled code, we saw something like a 25% speedup > on > String.replaceAll(), which calls into this code. > > Any interest? Diff attached. > > Jeremy > > > > > > > > > From john.r.rose at oracle.com Fri Apr 4 04:44:49 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 4 Apr 2014 00:44:49 -0400 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <433BC760-0B2E-4894-988B-7B4D388A9F71@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> <53305D76.7080009@oracle.com> <5332EBD5.8090100@oracle.com> <433BC760-0B2E-4894-988B-7B4D388A9F71@oracle.com> Message-ID: On Apr 3, 2014, at 6:33 PM, Christian Thalinger wrote: > Of course they are popular because these are the type names. There is no type L; it?s an object. I don?t understand why we have to use different names just because they are used in other namespaces. This is not a C define. They stand for JVM signatures as well as basic types. The letters are signature letters. Can we move on from this? ? John From luchsh at linux.vnet.ibm.com Fri Apr 4 08:18:32 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 4 Apr 2014 16:18:32 +0800 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Volker, Masayoshi, I made another patch which fixed the problems mentioned in last mail, http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ Could you pls help to take a look? Many thanks Jonathan On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu wrote: > Hi Volker, > > > On 2014?04?02? 23:07, Volker Simonis wrote: > > Hi Jonathan, > > thanks for updating the change. Please find my comments inline: > > On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu wrote: > > Hi Volker, Masayoshi, > > Thanks a lot for your review, here's the updated patch, could you pls take a > look? > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ > > > On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis > wrote: > > Hi Jonathan, > > thanks for doing this change. Please find some comments below: > > 1. please update the copyright year to 2014 in every file you touch > > Updated in new patch. > > > 2. in CopyFiles.gmk you can simplify the change by joining the windows > and aix cases because on Windows OPENJDK_TARGET_OS is the same like > OPENJDK_TARGET_OS_API_DIR. So you can write: > > ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) > > TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib > > $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings > $(call install-file) > > COPY_FILES += $(LIBDIR)/tzmappings > > endif > > I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris' > as I observed on my AIX box, > solaris/lib is not the directory where tzmappings was stored for AIX. > So I'm keeping this change, please fix me if I was wrong about the config. > > > Yes, but my point was to actually use OPENJDK_TARGET_OS for the > construction of TZMAPPINGS_SRC as shown in the code snippet above. > OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX > and that should be just enough here. > > > That's right, let me try that and also build/test on Windows platform. > > > 3. regarding the changes proposed by Masayoshi: I agree that we should > put the AIX timezone mapping code in its own function, but I don't > think that getPlatformTimeZoneID() would be the right place. As far as > I understand, getPlatformTimeZoneID() is used to get a platform time > zone id if the environment variable "TZ" is not set. I don't know a > way how this could be done on AIX (@Jonathan: maybe you know?). If > there would be a way to get the time zone from some system files or > so, then we should put this code into the AIX version of > getPlatformTimeZoneID(). > > I guess we may try to use /etc/envrionment file, which is basic setting for > all processes, > seehttp://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm > The implementation of getPlatformTimeZoneID() has been updated. > > > That's good! > > > But the current AIX code contributed by Jonathan, actually uses the > time zone id from the "TZ" environment variable and just maps it to a > Java compatible time zone id. So I'd suggest to refactor this code > into a function like for example "static const char* > mapPlatformToJavaTimzone(const char* tz)" and call that from > findJavaTZ_md(). I think that would make the code easier to > understand. > > Agree, and have split the code into a separate static method to do the > mapping work. > > > Good. But there's still one error in findJavaTZ_md(): > > 706 #ifdef _AIX > 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); > 708 #endif > > This should read: > > 706 #ifdef _AIX > 707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz); > 708 #endif > > because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came > from getPlatformTimeZoneID(). > > > Right, but with the second approach, there may be a minor memory leak here, > as javatz was not freed before being overwritten on AIX. will post another > patch on this soon. > > > With the above fixed I'll push this one we get one more review from a > reviewer (I'm currently not an official reviewer). > > Regards, > Volker > > > > @Masayoshi: what do you think, would you agree with such a solution. > > 4. I agree with Masayoshi that you should use the existing > getGMTOffsetID() > > Updated in new patch to eliminate duplication. > > > 5. Please notice that your change breaks all Unix builds except AIX > because of: > > 759 } > 760 tzerr: > 761 if (javatz == NULL) { > 762 time_t offset; > ... > 782 } > 783 #endif > > I think that should read: > > 759 > 760 tzerr: > 761 if (javatz == NULL) { > 762 time_t offset; > ... > 782 } > 783 #endif > 784 } > > Refactoring the code in an extra function will make that error more > evident anyway. > > But please always build at least on one different platform (i.e. > Linux) to prevent such errors in the future. > > My fault, sorry for the failure, should take no chance after any manual > alteration. > > > Regards, > Volker > > > On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu wrote: > > Hi Jonathan, > > The AIX specific code looks OK to me. But I'd suggest the code be moved > to > getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also > there's a function for producing a fallback ID in "GMT?hh:mm", > getGMTOffsetID() which can be called in tzerr. > > Thanks, > Masayoshi > > > On 3/26/2014 3:47 PM, Jonathan Lu wrote: > > Hi ppc-aix-port-dev, core-libs-dev, > > Here's a patch for JDK-8034220, > http://cr.openjdk.java.net/~luchsh/JDK-8034220/ > > It is trying to add the a more complete timezone mapping mechanism for > AIX > platform. > the changes are primarily based on IBM's commercial JDK code, which > includes: > > - A new timezone mapping file added under directory jdk/src/aix/lib/ > - Code to parse above config file, changed file is > src/solaris/native/java/util/TimeZone_md.c > - And also makefile change in make/CopyFiles.gmk to copy the config > file > > Could you pls help to review and give comments ? > > Cheers > - Jonathan > > Many thanks > Jonathan > > Regards > Jonathan > From alexander.v.stepanov at oracle.com Fri Apr 4 08:55:33 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Fri, 04 Apr 2014 12:55:33 +0400 Subject: [9] Review request for 8039172: Tidy warnings cleanup for java.net, java.math, java.time, java.rmi Message-ID: <533E7385.10409@oracle.com> Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8039172 Webrev corresponding: http://cr.openjdk.java.net/~yan/8039172/webrev.00/ Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. Thanks. Regards, Alexander From paul.sandoz at oracle.com Fri Apr 4 09:07:48 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Apr 2014 11:07:48 +0200 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> References: <533255B1.7020400@oracle.com> <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> Message-ID: On Apr 4, 2014, at 1:42 AM, Mike Duigou wrote: >> >> I could live with that change in behaviour, but this change completely breaks the fail-fast semantics of the iterators in some cases! If you don't update modCount until after the change is complete, the iterator may access the updated state and not throw CME!. > > For Vector I don't see this. The Iterator accesses to the data structures is always done with the Vector.this lock held. The re-ordering would only be observable to another thread if it is reading the Vector fields without holding the lock. I am not sure we should worry about that case. > Agreed, i don't see how that can happen. > For Hashtable Iterator there is no synchronization on the owning Hashtable except during the remove() method. It is unclear why the Hashtable iterators were not written in the same way as Vector. Dunno. > It seems like there would be massive disruption to adding synchronization to Hashtable's itertors. Are the Hashtable iterators actually fast-fail? They are fail fast only from within the same thread when the control is inverted via iterator (like that for non-synchronized HashMap etc), otherwise it is necessary to explicitly synchronize on the iterator, much like that for Collections.synchronized* methods, see the implementation: public Set keySet() { if (keySet == null) keySet = Collections.synchronizedSet(new KeySet(), this); return keySet; } The documentation for keySet etc. states: * reflected in the set, and vice-versa. If the map is modified * while an iteration over the set is in progress (except through * the iterator's own remove operation), the results of * the iteration are undefined. The set supports element removal, The documentation on the enumeration methods does not say anything. We should probably update the documentation to additionally say something like that on Collections.synchronized* methods. > Without synchronization this is not guaranteed since the writes may not be visible and Hashtable iterator failure behaviour is already likely to vary between platforms/architectures. With RTM it's presumed that the writes will NOT be visible until the transaction completes. This implies that the failure mode from Hashtable iterators is likely to change just by turning RTM locking on whether we make this code change or not. :-( > >> I think this change is misguided. > > I think we are fine for Vector, but Hashtable gives me concerns even in it's current state. > I don't think the current situation is made any worse by your changes. The are some subtle changes with regards parameter checking and throwing exceptions, but that does not seems to be very important behaviour to preserve. Paul. From lance.andersen at oracle.com Fri Apr 4 11:16:16 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Fri, 4 Apr 2014 07:16:16 -0400 Subject: [9] Review request for 8039172: Tidy warnings cleanup for java.net, java.math, java.time, java.rmi In-Reply-To: <533E7385.10409@oracle.com> References: <533E7385.10409@oracle.com> Message-ID: Looks ok but have one concern/question as to why you added the summary attribute to the table tag as it has been deprecated and believe it is not supported in HTML 5. I would probably not include it 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 Apr 4, 2014, at 4:55 AM, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8039172 > > Webrev corresponding: > http://cr.openjdk.java.net/~yan/8039172/webrev.00/ > > Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. > > Thanks. > > Regards, > Alexander From staffan.larsen at oracle.com Fri Apr 4 11:33:16 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 4 Apr 2014 13:33:16 +0200 Subject: RFR: 8039256 Add sun/jvmstat/monitor/MonitoredVm/CR6672135.java to ProblemList.txt Message-ID: <62E765EE-6B7F-4D80-A0F2-66D02BEEC1BB@oracle.com> Please review the change below to add a test to ProblemList.txt. For details, see https://bugs.openjdk.java.net/browse/JDK-8033104 Thanks, /Staffan diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -273,4 +273,7 @@ # 8031482 sun/tools/jcmd/TestJcmdSanity.java windows-all +# 8033104 +sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all + ############################################################################ From paul.sandoz at oracle.com Fri Apr 4 11:33:42 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Apr 2014 13:33:42 +0200 Subject: Review of MH/LF patches in the review queue Message-ID: <0ACCC33E-798A-484C-938C-6CDD689345CD@oracle.com> Hi, Reviews of two patches in the queue. Paul. http://cr.openjdk.java.net/~vlivanov/8037209/webrev.02/ Looks good, though I don't claim to understand all the nuances around casts and JVM/bytecode correctness. Minor stuff below. InvokerByteCodeGenerator: -- Unused method: static boolean match(MemberName member, MethodHandle fn) { if (member == null || fn == null) return false; return member.equals(fn.internalMemberName()); } MethodHandleImpl -- If you are gonna remove the weakly typed wrapper methods for array access, you might as well remove USE_WEAKLY_TYPED_ARRAY_ACCESSORS and it's use? - // Weakly typed wrappers of Object[] accessors: - static Object getElementL(Object a, int i) { return getElementL((Object[])a, i); } - static void setElementL(Object a, int i, Object x) { setElementL((Object[]) a, i, x); } - static Object getElementL(Object arrayClass, Object a, int i) { return getElementL((Class) arrayClass, (Object[])a, i); } - static void setElementL(Object arrayClass, Object a, int i, Object x) { setElementL((Class) arrayClass, (Object[])a, i, x); } - Or otherwise for expediency just leave it in until the array improvements patch follows? IMHO better to be consistent either way. VerifyType -- Typo in docs: *

* The primitive type 'void' does not interconvert with any other type, * even though it is legal to drop any type from the stack and "return void". * The stack effects, though are difference between void and any other type, * so it is safer to report a non-trivial conversion. s/difference/different http://cr.openjdk.java.net/~vlivanov/8038261/webrev.01/ To re-iterate this is a nice improvement over the previous approach. InvokerByteCodeGenerator -- For this specialization: if (defc == ArrayAccessor.class && match(member, ArrayAccessor.OBJECT_ARRAY_GETTER)) { mv.visitInsn(Opcodes.AALOAD); } else if (defc == ArrayAccessor.class && match(member, ArrayAccessor.OBJECT_ARRAY_SETTER)) { mv.visitInsn(Opcodes.AASTORE); } else if (member.isMethod()) { IIUC all stuff on the stack is correctly placed for the substitution of the invokestatic instruction to ArrayAccessor.set/getElementL with an aastore/load instruction. This makes we wonder if there is a more general approach for direct or direct-like MHs to be visited and provide their own snippets of ASM producing code. Is it worthwhile introducing such direct coupling for a specific case, as that tends to increase the inter-connective complexity of the code. How much performance gain is achieved? The last two re-assigments are never used and are reassigned again at the top of the loop: // Update cached form name's info in case an intrinsic spanning multiple names was encountered. name = lambdaForm.names[i]; member = name.function.member(); rtype = name.function.methodType().returnType(); From alexander.v.stepanov at oracle.com Fri Apr 4 11:53:53 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Fri, 04 Apr 2014 15:53:53 +0400 Subject: [9] Review request for 8039172: Tidy warnings cleanup for java.net, java.math, java.time, java.rmi In-Reply-To: References: <533E7385.10409@oracle.com> Message-ID: <533E9D51.7010609@oracle.com> Hello Lance, Thank you for the note; the summaries were removed, please see the updated webrev: http://cr.openjdk.java.net/~yan/8039172/webrev.01/ Regards, Alexander On 04.04.2014 15:16, Lance @ Oracle wrote: > Looks ok but have one concern/question as to why you added the summary > attribute to the table tag as it has been deprecated and believe it is > not supported in HTML 5. > > I would probably not include it > > 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 Apr 4, 2014, at 4:55 AM, alexander stepanov > > wrote: > >> Hello, >> >> Could you please review the fix for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8039172 >> >> Webrev corresponding: >> http://cr.openjdk.java.net/~yan/8039172/webrev.00/ >> >> >> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >> affected. >> >> Thanks. >> >> Regards, >> Alexander From aleksej.efimov at oracle.com Fri Apr 4 12:19:03 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 04 Apr 2014 16:19:03 +0400 Subject: RFR: 8038306: (tz) Support tzdata2014b In-Reply-To: <533D702C.50100@oracle.com> References: <533BEC8E.8080106@oracle.com> <533D6E85.3030108@oracle.com> <533D702C.50100@oracle.com> Message-ID: <533EA337.4040109@oracle.com> Masayoshi, The new webrev with proposed generic names for Antarctica/Troll can be found here: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.01 Thank you, Aleksej On 04/03/2014 06:29 PM, Aleksej Efimov wrote: > Masayoshi, > How about "Troll Time" and "ATT" for generic long and short names > across all locales? The "TT" is used as generic name for "Asia/Taipei" > in "zh_TW" locale, because of that I propose "ATT" (A - for > Antractica) - it's not used anywhere. > > Thanks, > Aleksej > > On 04/03/2014 06:21 PM, Masayoshi Okutsu wrote: >> Hi Aleksej, >> >> Sorry, but I forgot about the generic names. "Coordinated Universal >> Time" and "UTC"shouldn't be the generic names. You will need to >> "invent" the names, something like "Troll Time". >> >> Thanks, >> Masayoshi >> >> On 4/2/2014 7:55 PM, Aleksej Efimov wrote: >>> Hello, >>> >>> Can I have a review for the latest (2014b) TZ data integration to >>> JDK9. The webrev can be located here [1]. >>> >>> The following set of tests were executed without failures: >>> test/sun/util/calendar test/java/util/Calendar >>> test/sun/util/resources/TimeZone test/sun/util/calendar >>> test/java/util/TimeZone test/java/time test/java/util/Formatter >>> test/closed/java/util/Calendar\ test/closed/java/util/TimeZone >>> >>> Thank you, >>> Aleksej >>> >>> [1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/ >>> [2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306 >> > From lance.andersen at oracle.com Fri Apr 4 12:27:10 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Fri, 4 Apr 2014 08:27:10 -0400 Subject: [9] Review request for 8039172: Tidy warnings cleanup for java.net, java.math, java.time, java.rmi In-Reply-To: <533E9D51.7010609@oracle.com> References: <533E7385.10409@oracle.com> <533E9D51.7010609@oracle.com> Message-ID: <2695C051-AEA4-404D-AE7E-7DC329F58227@oracle.com> Looks fine 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 Apr 4, 2014, at 7:53 AM, alexander stepanov wrote: > Hello Lance, > > Thank you for the note; the summaries were removed, please see the updated webrev: > http://cr.openjdk.java.net/~yan/8039172/webrev.01/ > > Regards, > Alexander > > On 04.04.2014 15:16, Lance @ Oracle wrote: >> Looks ok but have one concern/question as to why you added the summary attribute to the table tag as it has been deprecated and believe it is not supported in HTML 5. >> >> I would probably not include it >> >> 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 Apr 4, 2014, at 4:55 AM, alexander stepanov > wrote: >> >>> Hello, >>> >>> Could you please review the fix for the following bug: >>> https://bugs.openjdk.java.net/browse/JDK-8039172 >>> >>> Webrev corresponding: >>> http://cr.openjdk.java.net/~yan/8039172/webrev.00/ >>> >>> Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. >>> >>> Thanks. >>> >>> Regards, >>> Alexander > From markus.gronlund at oracle.com Fri Apr 4 12:45:02 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 4 Apr 2014 05:45:02 -0700 (PDT) Subject: RFR: 8039256 Add sun/jvmstat/monitor/MonitoredVm/CR6672135.java to ProblemList.txt In-Reply-To: <62E765EE-6B7F-4D80-A0F2-66D02BEEC1BB@oracle.com> References: <62E765EE-6B7F-4D80-A0F2-66D02BEEC1BB@oracle.com> Message-ID: <9d433983-6ce7-4894-acfc-7b32e6e0ed1d@default> Looks good. /Markus -----Original Message----- From: Staffan Larsen Sent: den 4 april 2014 13:33 To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; core-libs-dev Libs Subject: RFR: 8039256 Add sun/jvmstat/monitor/MonitoredVm/CR6672135.java to ProblemList.txt Please review the change below to add a test to ProblemList.txt. For details, see https://bugs.openjdk.java.net/browse/JDK-8033104 Thanks, /Staffan diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -273,4 +273,7 @@ # 8031482 sun/tools/jcmd/TestJcmdSanity.java windows-all +# 8033104 +sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all + ############################################################################ From volker.simonis at gmail.com Fri Apr 4 13:22:33 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 4 Apr 2014 15:22:33 +0200 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Jonathan, sorry, but I found a few more issues: - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise somebody could easily crash the VM by specifying a TZ with more than 100 characters. - you can delete the lines 871-872 because the variables are actually not used and you can also remove the handling for "timezone == 0" because that is actually done in getGMTOffsetID() anyway. - could you please avoid the usage of strtok. It is not intended for usage in a multithreaded environment (see for example "man strtok" on AIX). strtok_r is probably overkill, but you could use for example strchr. did you check the build on Windows? Thank you and best regards, Volker On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu wrote: > Hi Volker, Masayoshi, > > I made another patch which fixed the problems mentioned in last mail, > > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ > > Could you pls help to take a look? > > Many thanks > Jonathan > > > > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu > wrote: >> >> Hi Volker, >> >> >> On 2014?04?02? 23:07, Volker Simonis wrote: >> >> Hi Jonathan, >> >> thanks for updating the change. Please find my comments inline: >> >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu >> wrote: >> >> Hi Volker, Masayoshi, >> >> Thanks a lot for your review, here's the updated patch, could you pls take >> a >> look? >> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ >> >> >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis >> wrote: >> >> Hi Jonathan, >> >> thanks for doing this change. Please find some comments below: >> >> 1. please update the copyright year to 2014 in every file you touch >> >> Updated in new patch. >> >> 2. in CopyFiles.gmk you can simplify the change by joining the windows >> and aix cases because on Windows OPENJDK_TARGET_OS is the same like >> OPENJDK_TARGET_OS_API_DIR. So you can write: >> >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) >> >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib >> >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings >> $(call install-file) >> >> COPY_FILES += $(LIBDIR)/tzmappings >> >> endif >> >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is >> 'solaris' >> as I observed on my AIX box, >> solaris/lib is not the directory where tzmappings was stored for AIX. >> So I'm keeping this change, please fix me if I was wrong about the config. >> >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the >> construction of TZMAPPINGS_SRC as shown in the code snippet above. >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX >> and that should be just enough here. >> >> >> That's right, let me try that and also build/test on Windows platform. >> >> >> 3. regarding the changes proposed by Masayoshi: I agree that we should >> put the AIX timezone mapping code in its own function, but I don't >> think that getPlatformTimeZoneID() would be the right place. As far as >> I understand, getPlatformTimeZoneID() is used to get a platform time >> zone id if the environment variable "TZ" is not set. I don't know a >> way how this could be done on AIX (@Jonathan: maybe you know?). If >> there would be a way to get the time zone from some system files or >> so, then we should put this code into the AIX version of >> getPlatformTimeZoneID(). >> >> I guess we may try to use /etc/envrionment file, which is basic setting >> for >> all processes, >> see >> >> http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm >> The implementation of getPlatformTimeZoneID() has been updated. >> >> That's good! >> >> But the current AIX code contributed by Jonathan, actually uses the >> time zone id from the "TZ" environment variable and just maps it to a >> Java compatible time zone id. So I'd suggest to refactor this code >> into a function like for example "static const char* >> mapPlatformToJavaTimzone(const char* tz)" and call that from >> findJavaTZ_md(). I think that would make the code easier to >> understand. >> >> Agree, and have split the code into a separate static method to do the >> mapping work. >> >> Good. But there's still one error in findJavaTZ_md(): >> >> 706 #ifdef _AIX >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); >> 708 #endif >> >> This should read: >> >> 706 #ifdef _AIX >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz); >> 708 #endif >> >> because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came >> from getPlatformTimeZoneID(). >> >> >> Right, but with the second approach, there may be a minor memory leak >> here, >> as javatz was not freed before being overwritten on AIX. will post another >> patch on this soon. >> >> >> With the above fixed I'll push this one we get one more review from a >> reviewer (I'm currently not an official reviewer). >> >> Regards, >> Volker >> >> >> @Masayoshi: what do you think, would you agree with such a solution. >> >> 4. I agree with Masayoshi that you should use the existing >> getGMTOffsetID() >> >> Updated in new patch to eliminate duplication. >> >> 5. Please notice that your change breaks all Unix builds except AIX >> because of: >> >> 759 } >> 760 tzerr: >> 761 if (javatz == NULL) { >> 762 time_t offset; >> ... >> 782 } >> 783 #endif >> >> I think that should read: >> >> 759 >> 760 tzerr: >> 761 if (javatz == NULL) { >> 762 time_t offset; >> ... >> 782 } >> 783 #endif >> 784 } >> >> Refactoring the code in an extra function will make that error more >> evident anyway. >> >> But please always build at least on one different platform (i.e. >> Linux) to prevent such errors in the future. >> >> My fault, sorry for the failure, should take no chance after any manual >> alteration. >> >> Regards, >> Volker >> >> >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu >> wrote: >> >> Hi Jonathan, >> >> The AIX specific code looks OK to me. But I'd suggest the code be moved >> to >> getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also >> there's a function for producing a fallback ID in "GMT?hh:mm", >> getGMTOffsetID() which can be called in tzerr. >> >> Thanks, >> Masayoshi >> >> >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: >> >> Hi ppc-aix-port-dev, core-libs-dev, >> >> Here's a patch for JDK-8034220, >> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ >> >> It is trying to add the a more complete timezone mapping mechanism for >> AIX >> platform. >> the changes are primarily based on IBM's commercial JDK code, which >> includes: >> >> - A new timezone mapping file added under directory jdk/src/aix/lib/ >> - Code to parse above config file, changed file is >> src/solaris/native/java/util/TimeZone_md.c >> - And also makefile change in make/CopyFiles.gmk to copy the config >> file >> >> Could you pls help to review and give comments ? >> >> Cheers >> - Jonathan >> >> Many thanks >> Jonathan >> >> Regards >> Jonathan > > From masayoshi.okutsu at oracle.com Fri Apr 4 14:25:51 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 04 Apr 2014 23:25:51 +0900 Subject: RFR: 8038306: (tz) Support tzdata2014b In-Reply-To: <533EA337.4040109@oracle.com> References: <533BEC8E.8080106@oracle.com> <533D6E85.3030108@oracle.com> <533D702C.50100@oracle.com> <533EA337.4040109@oracle.com> Message-ID: <533EC0EF.2030107@oracle.com> Another option would be "Troll Station Time" and "TST". But your invention is fine with me. Thanks, Masayoshi On 4/4/2014 9:19 PM, Aleksej Efimov wrote: > Masayoshi, > > The new webrev with proposed generic names for Antarctica/Troll can be > found here: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.01 > > Thank you, > Aleksej > > On 04/03/2014 06:29 PM, Aleksej Efimov wrote: >> Masayoshi, >> How about "Troll Time" and "ATT" for generic long and short names >> across all locales? The "TT" is used as generic name for >> "Asia/Taipei" in "zh_TW" locale, because of that I propose "ATT" (A - >> for Antractica) - it's not used anywhere. >> >> Thanks, >> Aleksej >> >> On 04/03/2014 06:21 PM, Masayoshi Okutsu wrote: >>> Hi Aleksej, >>> >>> Sorry, but I forgot about the generic names. "Coordinated Universal >>> Time" and "UTC"shouldn't be the generic names. You will need to >>> "invent" the names, something like "Troll Time". >>> >>> Thanks, >>> Masayoshi >>> >>> On 4/2/2014 7:55 PM, Aleksej Efimov wrote: >>>> Hello, >>>> >>>> Can I have a review for the latest (2014b) TZ data integration to >>>> JDK9. The webrev can be located here [1]. >>>> >>>> The following set of tests were executed without failures: >>>> test/sun/util/calendar test/java/util/Calendar >>>> test/sun/util/resources/TimeZone test/sun/util/calendar >>>> test/java/util/TimeZone test/java/time test/java/util/Formatter >>>> test/closed/java/util/Calendar\ test/closed/java/util/TimeZone >>>> >>>> Thank you, >>>> Aleksej >>>> >>>> [1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/ >>>> [2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306 >>> >> > From kissziszi at gmail.com Fri Apr 4 14:49:58 2014 From: kissziszi at gmail.com (Zoltan Sziladi) Date: Fri, 4 Apr 2014 16:49:58 +0200 Subject: String.indexOf optimization Message-ID: Hi, I am new to this mailing list so please forgive me if this has been discussed before. I was looking at the implementation of String.indexOf and I see that it uses the O(n^2) naive implementation. I have been trying to find out why it does not use some kind of a modern, sophisticated O(n) algorithm but I have no clear answer as of now. My guess is that the average case should be quite good for this algorithm because in practice the partial matches are actually quite rare, so it should work well... usually. Also, I saw that this code was last touched about 6 years ago, so maybe it was just left like this? My concern is actually the worst case scenario. If we compared two long strings with lots of partial matches, then this would perform quite poorly. Wouldn't it be worth having an O(n) implementation here then? Modern O(n) pattern matching algorithms don't use much extra space either. The Collections.sort method also uses an algorithm that prepares for worst case. Maybe a highly optimized quicksort could outperform the current mergesort implementation but I suppose one of the design principles behind that was also to prepare for the worst case. (Even though a nicely implemented quicksort has an expected average case runtime of O(nlogn) regardless of the input). If anyone knows why it is implemented this way or if it were possible to change the implementation, I'd be happy to hear your opinion. Thanks! Regards, Zoltan From yasuenag at gmail.com Fri Apr 4 14:55:54 2014 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 04 Apr 2014 23:55:54 +0900 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <20140303190102.GE2045@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53144E4D.8080606@redhat.com> <20140303190102.GE2045@redhat.com> Message-ID: <533EC7FA.9030700@gmail.com> Hi all, > This should fix it: > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb I updated OpenJDK8 to java-1.8.0-openjdk-1.8.0.0-0.34.b132.fc20 . However, debuginfo files are not contained ELF sections for debugging. (I checked libjvm.so.debug and libnio.so.debug with "readelf -S") According to SPEC file of OpenJDK8, following options are passed to "make": ----------------- make \ SCTP_WERROR= \ DEBUG_BINARIES=true \ FULL_DEBUG_SYMBOLS=0 \ STRIP_POLICY=none \ ALT_OBJCOPY=/does_not_exist \ LOG=trace \ all ----------------- I ran "grep" with DEBUG_BINARIES in jdk makefiles, however I could not find it. At least, DEBUG_BINARIES does not affect to jdk sources, and also does not affect to hotspot sources. I've succeeded to make binaries which are contained debuginfo as following: http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012037.html $ make images STRIP_POLICY=no_strip POST_STRIP_CMD="" I guess that we should run "make" above options to avoid this issue in currently. Thanks, Yasumasa On 03/04/2014 04:01 AM, Omair Majid wrote: > * Andrew Haley [2014-03-03 04:43]: >> On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote: >>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . >>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not >>> contain debug information. Actual debug information is shipped by OpenJDK >>> debuginfo package. >> That's a bug in Fedora's build. We should fix it. > This should fix it: > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb > > Thanks, > Omair > From Alan.Bateman at oracle.com Fri Apr 4 15:18:13 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Apr 2014 16:18:13 +0100 Subject: String.indexOf optimization In-Reply-To: References: Message-ID: <533ECD35.9070904@oracle.com> On 04/04/2014 15:49, Zoltan Sziladi wrote: > Hi, > > I am new to this mailing list so please forgive me if this has been > discussed before. > > I was looking at the implementation of String.indexOf and I see that > it uses the O(n^2) naive implementation. I have been trying to find > out why it does not use some kind of a modern, sophisticated O(n) > algorithm but I have no clear answer as of now. > > My guess is that the average case should be quite good for this > algorithm because in practice the partial matches are actually quite > rare, so it should work well... usually. Also, I saw that this code > was last touched about 6 years ago, so maybe it was just left like > this? > My concern is actually the worst case scenario. If we compared two > long strings with lots of partial matches, then this would perform > quite poorly. Wouldn't it be worth having an O(n) implementation here > then? Modern O(n) pattern matching algorithms don't use much extra > space either. > The Collections.sort method also uses an algorithm that prepares for > worst case. Maybe a highly optimized quicksort could outperform the > current mergesort implementation but I suppose one of the design > principles behind that was also to prepare for the worst case. (Even > though a nicely implemented quicksort has an expected average case > runtime of O(nlogn) regardless of the input). > > If anyone knows why it is implemented this way or if it were possible > to change the implementation, I'd be happy to hear your opinion. > Thanks! > Here's a previous thread where someone else asked about String.indexOf http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018062.html If you are interested in this topic and can do better then go ahead, I'm sure there would be a lot of people here would be interested in space and time numbers. -Alan. From aleksej.efimov at oracle.com Fri Apr 4 15:19:45 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 04 Apr 2014 19:19:45 +0400 Subject: RFR: 8038306: (tz) Support tzdata2014b In-Reply-To: <533EC0EF.2030107@oracle.com> References: <533BEC8E.8080106@oracle.com> <533D6E85.3030108@oracle.com> <533D702C.50100@oracle.com> <533EA337.4040109@oracle.com> <533EC0EF.2030107@oracle.com> Message-ID: <533ECD91.4040608@oracle.com> Masayoshi, Thank you for the review. The "TST" is already used by "Asia/Taipei" in "zh_TW". I'll leave the naming as it is, because I suppose that we probably should see an official short name abbreviation for this time zone in near future. -Aleksej On 04/04/2014 06:25 PM, Masayoshi Okutsu wrote: > Another option would be "Troll Station Time" and "TST". But your > invention is fine with me. > > Thanks, > Masayoshi > > On 4/4/2014 9:19 PM, Aleksej Efimov wrote: >> Masayoshi, >> >> The new webrev with proposed generic names for Antarctica/Troll can >> be found here: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.01 >> >> Thank you, >> Aleksej >> >> On 04/03/2014 06:29 PM, Aleksej Efimov wrote: >>> Masayoshi, >>> How about "Troll Time" and "ATT" for generic long and short names >>> across all locales? The "TT" is used as generic name for >>> "Asia/Taipei" in "zh_TW" locale, because of that I propose "ATT" (A >>> - for Antractica) - it's not used anywhere. >>> >>> Thanks, >>> Aleksej >>> >>> On 04/03/2014 06:21 PM, Masayoshi Okutsu wrote: >>>> Hi Aleksej, >>>> >>>> Sorry, but I forgot about the generic names. "Coordinated Universal >>>> Time" and "UTC"shouldn't be the generic names. You will need to >>>> "invent" the names, something like "Troll Time". >>>> >>>> Thanks, >>>> Masayoshi >>>> >>>> On 4/2/2014 7:55 PM, Aleksej Efimov wrote: >>>>> Hello, >>>>> >>>>> Can I have a review for the latest (2014b) TZ data integration to >>>>> JDK9. The webrev can be located here [1]. >>>>> >>>>> The following set of tests were executed without failures: >>>>> test/sun/util/calendar test/java/util/Calendar >>>>> test/sun/util/resources/TimeZone test/sun/util/calendar >>>>> test/java/util/TimeZone test/java/time test/java/util/Formatter >>>>> test/closed/java/util/Calendar\ test/closed/java/util/TimeZone >>>>> >>>>> Thank you, >>>>> Aleksej >>>>> >>>>> [1] Webrev: http://cr.openjdk.java.net/~aefimov/8038306/9/webrev.00/ >>>>> [2] BUG: https://bugs.openjdk.java.net/browse/JDK-8038306 >>>> >>> >> > From Alan.Bateman at oracle.com Fri Apr 4 15:25:32 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Apr 2014 16:25:32 +0100 Subject: [9] Review request for 8039172: Tidy warnings cleanup for java.net, java.math, java.time, java.rmi In-Reply-To: <533E9D51.7010609@oracle.com> References: <533E7385.10409@oracle.com> <533E9D51.7010609@oracle.com> Message-ID: <533ECEEC.3020106@oracle.com> On 04/04/2014 12:53, alexander stepanov wrote: > Hello Lance, > > Thank you for the note; the summaries were removed, please see the > updated webrev: > http://cr.openjdk.java.net/~yan/8039172/webrev.01/ I looked through the updated webrev and it looks okay to me. One suggestion for net-properties.html is to split line 38 as it's very long compared to all the rest. -Alan. From Alan.Bateman at oracle.com Fri Apr 4 15:30:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Apr 2014 16:30:40 +0100 Subject: RFR: 8039256 Add sun/jvmstat/monitor/MonitoredVm/CR6672135.java to ProblemList.txt In-Reply-To: <62E765EE-6B7F-4D80-A0F2-66D02BEEC1BB@oracle.com> References: <62E765EE-6B7F-4D80-A0F2-66D02BEEC1BB@oracle.com> Message-ID: <533ED020.6010902@oracle.com> On 04/04/2014 12:33, Staffan Larsen wrote: > Please review the change below to add a test to ProblemList.txt. For details, see https://bugs.openjdk.java.net/browse/JDK-8033104 > > Thanks, > /Staffan > > > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -273,4 +273,7 @@ > # 8031482 > sun/tools/jcmd/TestJcmdSanity.java windows-all > > +# 8033104 > +sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all > + > ############################################################################ Excluding this test until the issue running with java.io.tmpdir set is resolved seem okay to me. -Alan From alexander.v.stepanov at oracle.com Fri Apr 4 15:35:47 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Fri, 04 Apr 2014 19:35:47 +0400 Subject: [9] Review request for 8039172: Tidy warnings cleanup for java.net, java.math, java.time, java.rmi In-Reply-To: <533ECEEC.3020106@oracle.com> References: <533E7385.10409@oracle.com> <533E9D51.7010609@oracle.com> <533ECEEC.3020106@oracle.com> Message-ID: <533ED153.8020700@oracle.com> Thanks; the line in net-properties.html was splitted. Regards, Alexander On 04.04.2014 19:25, Alan Bateman wrote: > On 04/04/2014 12:53, alexander stepanov wrote: >> Hello Lance, >> >> Thank you for the note; the summaries were removed, please see the >> updated webrev: >> http://cr.openjdk.java.net/~yan/8039172/webrev.01/ > I looked through the updated webrev and it looks okay to me. One > suggestion for net-properties.html is to split line 38 as it's very > long compared to all the rest. > > -Alan. From forax at univ-mlv.fr Fri Apr 4 15:47:38 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 04 Apr 2014 17:47:38 +0200 Subject: String.indexOf optimization In-Reply-To: <533ECD35.9070904@oracle.com> References: <533ECD35.9070904@oracle.com> Message-ID: <533ED41A.3080705@univ-mlv.fr> On 04/04/2014 05:18 PM, Alan Bateman wrote: > On 04/04/2014 15:49, Zoltan Sziladi wrote: >> Hi, >> >> I am new to this mailing list so please forgive me if this has been >> discussed before. >> >> I was looking at the implementation of String.indexOf and I see that >> it uses the O(n^2) naive implementation. I have been trying to find >> out why it does not use some kind of a modern, sophisticated O(n) >> algorithm but I have no clear answer as of now. >> >> My guess is that the average case should be quite good for this >> algorithm because in practice the partial matches are actually quite >> rare, so it should work well... usually. Also, I saw that this code >> was last touched about 6 years ago, so maybe it was just left like >> this? >> My concern is actually the worst case scenario. If we compared two >> long strings with lots of partial matches, then this would perform >> quite poorly. Wouldn't it be worth having an O(n) implementation here >> then? Modern O(n) pattern matching algorithms don't use much extra >> space either. >> The Collections.sort method also uses an algorithm that prepares for >> worst case. Maybe a highly optimized quicksort could outperform the >> current mergesort implementation but I suppose one of the design >> principles behind that was also to prepare for the worst case. (Even >> though a nicely implemented quicksort has an expected average case >> runtime of O(nlogn) regardless of the input). >> >> If anyone knows why it is implemented this way or if it were possible >> to change the implementation, I'd be happy to hear your opinion. >> Thanks! >> > Here's a previous thread where someone else asked about String.indexOf > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018062.html > > > If you are interested in this topic and can do better then go ahead, > I'm sure there would be a lot of people here would be interested in > space and time numbers. > > -Alan. You may also want to test against the couple Pattern + Matcher, which use BoyerMoore (at least the last time i have read the source) R?mi From dmitry.samersoff at oracle.com Fri Apr 4 17:03:47 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 04 Apr 2014 21:03:47 +0400 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53301478.8000809@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> <532BFEE2.6080802@oracle.com> <532C080A.9020002@oracle.com> <53301478.8000809@oracle.com> Message-ID: <533EE5F3.1020806@oracle.com> Magnus, Not, we are not doing it now. But we should consider doing it in a future and therefore keep it in mind when designing option to choose debug symbol mode. -Dmitry On 2014-03-24 15:18, Magnus Ihse Bursie wrote: > On 2014-03-21 10:36, Dmitry Samersoff wrote: >> >> (c) Compression mode: >> >> 1. none >> 2. per-section compression, SHF_GNU_COMPRESSED [1] >> 3. zip entire file >> > > Is 2 something we're doing? I couldn't find any references to it in the > code. Or is it something we're planning to do? > > /Magnus -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From xueming.shen at oracle.com Fri Apr 4 17:08:18 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 04 Apr 2014 10:08:18 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: References: <532AA782.5030809@gmail.com> <532B246F.20302@oracle.com> <532CF69A.3060301@oracle.com> <533DD230.1050105@oracle.com> Message-ID: <533EE702.2080203@oracle.com> On 4/3/14 4:43 PM, Jeremy Manson wrote: > Good catch, thanks. > > I think we should probably just go with the (equivalent to the) > StringBuffer variant. I'm pretty loathe to modify the StringBuilder > directly if we are going to back that change out. > > Do you want me to generate a new patch? I can/will send out an updated webrev before push. -Sherman > > Jeremy > > > On Thu, Apr 3, 2014 at 2:27 PM, Xueming Shen > wrote: > > On 03/25/2014 02:07 PM, Jeremy Manson wrote: >> Okay. Thanks, Sherman. Here's an updated version. >> >> I've diverged a bit from Peter's version. In this version, >> appendExpandedReplacement takes a StringBuilder. The >> implications is that In the StringBuilder case, it saves creating >> a new StringBuilder object. In the StringBuffer case, it creates >> a new StringBuilder, but it doesn't have to acquire and release >> all of those locks. > > Hi Jeremy, > > It appears the "optimized" StringBuilder version will cause > following test case failure, > in which the "xyz" will be copied into the result buffer, even > when the replacement > string triggers a IAE. > > // Check nothing has been appended into the output buffer if > // the replacement string triggers IllegalArgumentException. > Pattern p = Pattern.compile("(abc)"); > Matcher m = p.matcher("abcd"); > StringBuilder result = new StringBuilder(); > try { > m.appendReplacement(result, ("xyz$g")); > } catch (IllegalArgumentException iae) { > if (result.length() != 0) > System.err.println(" FAILED"); > > } > > We may have to either catch the IAE and reset the sb, or create > a new sb, as the StringBuffer does. > > -Sherman > > > >> >> I also noticed a redundant cast to (int), which I removed. >> >> Jeremy >> >> >> On Fri, Mar 21, 2014 at 7:34 PM, Xueming Shen >> > wrote: >> >> let's add the StringBuilder method(s), if you can provide an >> updated version, I can run the rest (since it's >> to add new api, there is an internal CCC process need to go >> through). >> >> -Sherman >> >> >> On 3/21/14 5:18 PM, Jeremy Manson wrote: >>> So, this is all a little opaque to me. How do we make the >>> go/no-go decision on something like this? Everyone who has >>> chimed in seems to think it is a good idea. >>> >>> Jeremy >>> >>> >>> On Thu, Mar 20, 2014 at 10:38 AM, Jeremy Manson >>> > >>> wrote: >>> >>> Sherman, >>> >>> If you had released it then (which you wouldn't have >>> been able to do, because you would have to wait another >>> two years for Java 7), you would have found that it >>> improved performance even with C2. It is only >>> post-escape-analysis that the performance in C2 equalized. >>> >>> Anyway, I think adding the StringBuilder variant and >>> deferring / dealing with the Appendable differently is >>> the right approach, FWIW. >>> >>> Jeremy >>> >>> >>> On Thu, Mar 20, 2014 at 10:25 AM, Xueming Shen >>> >> > wrote: >>> >>> 2009? I do have something similar back to 2009 :-) >>> >>> http://cr.openjdk.java.net/~sherman/regex_replace/webrev/ >>> >>> >>> Then the ball was dropped around the discussion of >>> whether or not >>> the IOE should be thrown. >>> >>> But if we are going to/have to have explicit >>> StringBuilder/Buffer pair >>> anyway, then we can keep the Appendable version as >>> private for now >>> and deal with the StringBuilder and Appendable as >>> two separate >>> issues. >>> >>> -Sherman >>> >>> >>> On 03/20/2014 09:52 AM, Jeremy Manson wrote: >>> >>> That's definitely an improvement - I think that >>> when I wrote this (circa >>> 2009), I didn't think about Appendable. >>> >>> I take it my argument convinced someone? :) >>> >>> Jeremy >>> >>> >>> On Thu, Mar 20, 2014 at 1:32 AM, Peter >>> Levart>> >wrote: >>> >>> On 03/19/2014 06:51 PM, Jeremy Manson wrote: >>> >>> I'm told that the diff didn't make it. >>> I've put it in a Google drive >>> folder... >>> >>> https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ >>> edit?usp=sharing >>> >>> Jeremy >>> >>> Hi Jeremy, >>> >>> Your factoring-out of expandReplacement() >>> method exposed an opportunity to >>> further optimize the code. Instead of >>> creating intermediate StringBuilder >>> instance for each expandReplacement() call, >>> this method could append >>> directly to resulting >>> StringBuffer/StringBuilder, like in the >>> following: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ >>> >>> webrev.01/ >>> >>> >>> Regards, Peter >>> >>> >>> >>> On Wed, Mar 19, 2014 at 10:41 AM, Jeremy >>> Manson>> > >>> wrote: >>> >>> Hi folks, >>> >>> We've had this internally for a >>> while, and I keep meaning to bring it up >>> here. The Matcher class has a few >>> public methods that take >>> StringBuffers, >>> and we've found it useful to add >>> similar versions that take >>> StringBuilders. >>> >>> It has two benefits: >>> >>> - Users don't have to convert from >>> one to the other when they want to use >>> the method in question. The >>> symmetry is nice. >>> >>> - The StringBuilder variants are >>> faster (if lock optimizations don't kick >>> in, which happens in the interpreter >>> and the client compiler). For >>> interpreted / client-compiled code, >>> we saw something like a 25% speedup >>> on >>> String.replaceAll(), which calls >>> into this code. >>> >>> Any interest? Diff attached. >>> >>> Jeremy >>> >>> >>> >>> >>> >> >> > > From martinrb at google.com Fri Apr 4 17:13:14 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 4 Apr 2014 10:13:14 -0700 Subject: String.indexOf optimization In-Reply-To: References: Message-ID: Summary: Many people (myself included) have looked at this problem. It's unlikely that String.indexOf will change. It's hard to beat the naive implementation in the typical case. The 64k size of the character set will make Boyer-Moore harder to implement efficiently. On Fri, Apr 4, 2014 at 7:49 AM, Zoltan Sziladi wrote: > Hi, > > I am new to this mailing list so please forgive me if this has been > discussed before. > > I was looking at the implementation of String.indexOf and I see that > it uses the O(n^2) naive implementation. I have been trying to find > out why it does not use some kind of a modern, sophisticated O(n) > algorithm but I have no clear answer as of now. > > My guess is that the average case should be quite good for this > algorithm because in practice the partial matches are actually quite > rare, so it should work well... usually. Also, I saw that this code > was last touched about 6 years ago, so maybe it was just left like > this? > My concern is actually the worst case scenario. If we compared two > long strings with lots of partial matches, then this would perform > quite poorly. Wouldn't it be worth having an O(n) implementation here > then? Modern O(n) pattern matching algorithms don't use much extra > space either. > The Collections.sort method also uses an algorithm that prepares for > worst case. Maybe a highly optimized quicksort could outperform the > current mergesort implementation but I suppose one of the design > principles behind that was also to prepare for the worst case. (Even > though a nicely implemented quicksort has an expected average case > runtime of O(nlogn) regardless of the input). > > If anyone knows why it is implemented this way or if it were possible > to change the implementation, I'd be happy to hear your opinion. > Thanks! > > Regards, > Zoltan > From roger.riggs at oracle.com Fri Apr 4 19:24:44 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 04 Apr 2014 15:24:44 -0400 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533C3549.3030602@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> Message-ID: <533F06FC.40102@oracle.com> Hi Peter, I ran into one test problem when running this through its paces. The test: test/java/lang/ProcessBuilder/SecurityManagerClinit.java throws a package access exception while creating a lambda due to the wacky security manager and forbidding of access to java.util. I hacked the test to remove the limitation on java.util. This looks good to me but a more experienced Reviewer should look at it. Thanks, Roger > Right, > > Here it is: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.06/ Stack dump from test: java.lang.ExceptionInInitializerError at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:256) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:221) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:210) at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:82) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1638) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1602) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1778) at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1727) at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:442) at java.lang.UNIXProcess$Platform.get(UNIXProcess.java:147) at java.lang.UNIXProcess.(UNIXProcess.java:160) at java.lang.ProcessImpl.start(ProcessImpl.java:130) at java.lang.ProcessBuilder.start(ProcessBuilder.java:1023) at java.lang.Runtime.exec(Runtime.java:620) at java.lang.Runtime.exec(Runtime.java:485) at SecurityManagerClinit.main(SecurityManagerClinit.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:484) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:744) Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.java.util") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:541) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1481) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305) at java.lang.ClassLoader.loadClass(ClassLoader.java:359) at sun.invoke.util.BytecodeDescriptor.parseSig(BytecodeDescriptor.java:83) at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:54) at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:41) at java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:911) at java.lang.invoke.MemberName.getMethodType(MemberName.java:144) at java.lang.invoke.LambdaForm.computeInitialPreparedForms(LambdaForm.java:477) at java.lang.invoke.LambdaForm.(LambdaForm.java:1641) From christian.thalinger at oracle.com Fri Apr 4 23:31:53 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Apr 2014 16:31:53 -0700 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> <53305D76.7080009@oracle.com> <5332EBD5.8090100@oracle.com> <433BC760-0B2E-4894-988B-7B4D388A9F71@oracle.com> Message-ID: On Apr 3, 2014, at 9:44 PM, John Rose wrote: > On Apr 3, 2014, at 6:33 PM, Christian Thalinger wrote: > >> Of course they are popular because these are the type names. There is no type L; it?s an object. I don?t understand why we have to use different names just because they are used in other namespaces. This is not a C define. > > They stand for JVM signatures as well as basic types. The letters are signature letters. Can we move on from this? Sure. Push it. > > ? John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From david.holmes at oracle.com Mon Apr 7 01:16:19 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 Apr 2014 11:16:19 +1000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <533EC7FA.9030700@gmail.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53144E4D.8080606@redhat.com> <20140303190102.GE2045@redhat.com> <533EC7FA.9030700@gmail.com> Message-ID: <5341FC63.60602@oracle.com> On 5/04/2014 12:55 AM, Yasumasa Suenaga wrote: > Hi all, > >> This should fix it: >> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb >> > > I updated OpenJDK8 to java-1.8.0-openjdk-1.8.0.0-0.34.b132.fc20 . > However, debuginfo files are not contained ELF sections for debugging. > (I checked libjvm.so.debug and libnio.so.debug with "readelf -S") > > According to SPEC file of OpenJDK8, following options are passed to "make": > ----------------- > make \ > SCTP_WERROR= \ > DEBUG_BINARIES=true \ > FULL_DEBUG_SYMBOLS=0 \ > STRIP_POLICY=none \ > ALT_OBJCOPY=/does_not_exist \ > LOG=trace \ > all > ----------------- > > I ran "grep" with DEBUG_BINARIES in jdk makefiles, however I could not > find it. > At least, DEBUG_BINARIES does not affect to jdk sources, and also does not > affect to hotspot sources. DEBUG_BINARIES is used in the hotspot makefiles. ./linux/makefiles/gcc.make ifeq ($(DEBUG_BINARIES), true) CFLAGS += -g else David ----- > > I've succeeded to make binaries which are contained debuginfo as following: > > http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012037.html > $ make images STRIP_POLICY=no_strip POST_STRIP_CMD="" > > > I guess that we should run "make" above options to avoid this issue in > currently. > > > Thanks, > > Yasumasa > > > On 03/04/2014 04:01 AM, Omair Majid wrote: >> * Andrew Haley [2014-03-03 04:43]: >>> On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote: >>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and >>>> libjvm.debuginfo . >>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it >>>> does not >>>> contain debug information. Actual debug information is shipped by >>>> OpenJDK >>>> debuginfo package. >>> That's a bug in Fedora's build. We should fix it. >> This should fix it: >> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb >> >> >> Thanks, >> Omair >> > From kissziszi at gmail.com Mon Apr 7 07:56:17 2014 From: kissziszi at gmail.com (Zoltan Sziladi) Date: Mon, 7 Apr 2014 09:56:17 +0200 Subject: String.indexOf optimization In-Reply-To: References: Message-ID: Thanks everyone for the input. Even though many people who are way smarter than me already tried to beat the naive implementation, I'll try too, just for the fun of it. I'll post my updates here if I find something worthy of mentioning. Zoltan On Fri, Apr 4, 2014 at 7:13 PM, Martin Buchholz wrote: > Summary: > > Many people (myself included) have looked at this problem. It's unlikely > that String.indexOf will change. It's hard to beat the naive implementation > in the typical case. The 64k size of the character set will make > Boyer-Moore harder to implement efficiently. > > > On Fri, Apr 4, 2014 at 7:49 AM, Zoltan Sziladi wrote: >> >> Hi, >> >> I am new to this mailing list so please forgive me if this has been >> discussed before. >> >> I was looking at the implementation of String.indexOf and I see that >> it uses the O(n^2) naive implementation. I have been trying to find >> out why it does not use some kind of a modern, sophisticated O(n) >> algorithm but I have no clear answer as of now. >> >> My guess is that the average case should be quite good for this >> algorithm because in practice the partial matches are actually quite >> rare, so it should work well... usually. Also, I saw that this code >> was last touched about 6 years ago, so maybe it was just left like >> this? >> My concern is actually the worst case scenario. If we compared two >> long strings with lots of partial matches, then this would perform >> quite poorly. Wouldn't it be worth having an O(n) implementation here >> then? Modern O(n) pattern matching algorithms don't use much extra >> space either. >> The Collections.sort method also uses an algorithm that prepares for >> worst case. Maybe a highly optimized quicksort could outperform the >> current mergesort implementation but I suppose one of the design >> principles behind that was also to prepare for the worst case. (Even >> though a nicely implemented quicksort has an expected average case >> runtime of O(nlogn) regardless of the input). >> >> If anyone knows why it is implemented this way or if it were possible >> to change the implementation, I'd be happy to hear your opinion. >> Thanks! >> >> Regards, >> Zoltan > > From yekaterina.kantserova at oracle.com Mon Apr 7 08:49:20 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 7 Apr 2014 01:49:20 -0700 (PDT) Subject: Testlibrary changes need their own changesets Message-ID: <2b65a081-b79b-4ee6-b3d2-d4c501cbb64f@default> Since the testlibrary exists even in the JDK part I would like to add the Serviceability and Corelibs teams to this discussion. Thanks, Katja ----- Original Message ----- From: david.holmes at oracle.com To: hotspot-dev at openjdk.java.net Sent: Monday, April 7, 2014 3:50:14 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Testlibrary changes need their own changesets Unfortunately enhancements to the testlibrary infrastructure code tend to be done in conjunction with the changes to the tests (and sometimes corresponding VM changes) that need the enhancement. This makes it very difficult (sometimes impossible) to backport updates to the testlibrary. Can I suggest that all updates to the testlibrary classes be done under their own CR (they can still be reviewed alongside the main changes) and committed into a distinct changeset so that they can be readily backported. Thanks, David From paul.sandoz at oracle.com Mon Apr 7 10:49:56 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 7 Apr 2014 12:49:56 +0200 Subject: UUID.compareTo broken? Message-ID: <9473DBFE-49BF-4AC9-B290-9F7D56B09A24@oracle.com> Hi, https://github.com/cowtowncoder/java-uuid-generator "JDK's java.util.UUID has flawed implementation of compareTo(), which uses naive comparison of 64-bit values. " Anyone familiar with the JDK UUID implementation care to comment? Paul. From miroslav.kos at oracle.com Mon Apr 7 16:22:46 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Mon, 07 Apr 2014 18:22:46 +0200 Subject: RFR: 8033113: wsimport fails on WSDL:header parameter name customization Message-ID: <5342D0D6.7050804@oracle.com> Hi, I'd like to ask for approval and sponsoring fix for following issue (escalation from customer): JBS: https://bugs.openjdk.java.net/browse/JDK-8033113 BugDB: https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=17348912 jaxws changeset: http://cr.openjdk.java.net/~mkos/8033113/jaxws.01/ jdk reg tests: http://cr.openjdk.java.net/~mkos/8033113/jdk.01/ This fix addresses situation when there are conflicting parameter names (wsimport fails) and those need to be customized. Thanks Miran From chris.hegarty at oracle.com Mon Apr 7 16:48:36 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 7 Apr 2014 17:48:36 +0100 Subject: RFR: 8033113: wsimport fails on WSDL:header parameter name customization In-Reply-To: <5342D0D6.7050804@oracle.com> References: <5342D0D6.7050804@oracle.com> Message-ID: <8CDB60C4-0BD2-4B60-BD5D-9805BD151EA6@oracle.com> This looks good to me Miran. I can sponsor it for you. -Chris. On 7 Apr 2014, at 17:22, Miroslav Kos wrote: > Hi, > I'd like to ask for approval and sponsoring fix for following issue (escalation from customer): > > JBS: https://bugs.openjdk.java.net/browse/JDK-8033113 > BugDB: https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=17348912 > > jaxws changeset: http://cr.openjdk.java.net/~mkos/8033113/jaxws.01/ > jdk reg tests: http://cr.openjdk.java.net/~mkos/8033113/jdk.01/ > > This fix addresses situation when there are conflicting parameter names (wsimport fails) and those need to be customized. > > Thanks > Miran > > From xueming.shen at oracle.com Mon Apr 7 17:00:51 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 07 Apr 2014 10:00:51 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: <533EE702.2080203@oracle.com> References: <532AA782.5030809@gmail.com> <532B246F.20302@oracle.com> <532CF69A.3060301@oracle.com> <533DD230.1050105@oracle.com> <533EE702.2080203@oracle.com> Message-ID: <5342D9C3.5080002@oracle.com> On 04/04/2014 10:08 AM, Xueming Shen wrote: > On 4/3/14 4:43 PM, Jeremy Manson wrote: >> Good catch, thanks. >> >> I think we should probably just go with the (equivalent to the) StringBuffer variant. I'm pretty loathe to modify the StringBuilder directly if we are going to back that change out. >> >> Do you want me to generate a new patch? > > I can/will send out an updated webrev before push. the latest webrev. http://cr.openjdk.java.net/~sherman/8039124/webrev -Sherman > > -Sherman > >> >> Jeremy >> >> >> On Thu, Apr 3, 2014 at 2:27 PM, Xueming Shen > wrote: >> >> On 03/25/2014 02:07 PM, Jeremy Manson wrote: >>> Okay. Thanks, Sherman. Here's an updated version. >>> >>> I've diverged a bit from Peter's version. In this version, appendExpandedReplacement takes a StringBuilder. The implications is that In the StringBuilder case, it saves creating a new StringBuilder object. In the StringBuffer case, it creates a new StringBuilder, but it doesn't have to acquire and release all of those locks. >> >> Hi Jeremy, >> >> It appears the "optimized" StringBuilder version will cause following test case failure, >> in which the "xyz" will be copied into the result buffer, even when the replacement >> string triggers a IAE. >> >> // Check nothing has been appended into the output buffer if >> // the replacement string triggers IllegalArgumentException. >> Pattern p = Pattern.compile("(abc)"); >> Matcher m = p.matcher("abcd"); >> StringBuilder result = new StringBuilder(); >> try { >> m.appendReplacement(result, ("xyz$g")); >> } catch (IllegalArgumentException iae) { >> if (result.length() != 0) >> System.err.println(" FAILED"); >> >> } >> >> We may have to either catch the IAE and reset the sb, or create >> a new sb, as the StringBuffer does. >> >> -Sherman >> >> >> >>> >>> I also noticed a redundant cast to (int), which I removed. >>> >>> Jeremy >>> >>> >>> On Fri, Mar 21, 2014 at 7:34 PM, Xueming Shen > wrote: >>> >>> let's add the StringBuilder method(s), if you can provide an updated version, I can run the rest (since it's >>> to add new api, there is an internal CCC process need to go through). >>> >>> -Sherman >>> >>> >>> On 3/21/14 5:18 PM, Jeremy Manson wrote: >>>> So, this is all a little opaque to me. How do we make the go/no-go decision on something like this? Everyone who has chimed in seems to think it is a good idea. >>>> >>>> Jeremy >>>> >>>> >>>> On Thu, Mar 20, 2014 at 10:38 AM, Jeremy Manson > wrote: >>>> >>>> Sherman, >>>> >>>> If you had released it then (which you wouldn't have been able to do, because you would have to wait another two years for Java 7), you would have found that it improved performance even with C2. It is only post-escape-analysis that the performance in C2 equalized. >>>> >>>> Anyway, I think adding the StringBuilder variant and deferring / dealing with the Appendable differently is the right approach, FWIW. >>>> >>>> Jeremy >>>> >>>> >>>> On Thu, Mar 20, 2014 at 10:25 AM, Xueming Shen > wrote: >>>> >>>> 2009? I do have something similar back to 2009 :-) >>>> >>>> http://cr.openjdk.java.net/~sherman/regex_replace/webrev/ >>>> >>>> Then the ball was dropped around the discussion of whether or not >>>> the IOE should be thrown. >>>> >>>> But if we are going to/have to have explicit StringBuilder/Buffer pair >>>> anyway, then we can keep the Appendable version as private for now >>>> and deal with the StringBuilder and Appendable as two separate >>>> issues. >>>> >>>> -Sherman >>>> >>>> >>>> On 03/20/2014 09:52 AM, Jeremy Manson wrote: >>>> >>>> That's definitely an improvement - I think that when I wrote this (circa >>>> 2009), I didn't think about Appendable. >>>> >>>> I take it my argument convinced someone? :) >>>> >>>> Jeremy >>>> >>>> >>>> On Thu, Mar 20, 2014 at 1:32 AM, Peter Levart>wrote: >>>> >>>> On 03/19/2014 06:51 PM, Jeremy Manson wrote: >>>> >>>> I'm told that the diff didn't make it. I've put it in a Google drive >>>> folder... >>>> >>>> https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ >>>> edit?usp=sharing >>>> >>>> Jeremy >>>> >>>> Hi Jeremy, >>>> >>>> Your factoring-out of expandReplacement() method exposed an opportunity to >>>> further optimize the code. Instead of creating intermediate StringBuilder >>>> instance for each expandReplacement() call, this method could append >>>> directly to resulting StringBuffer/StringBuilder, like in the following: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ >>>> webrev.01/ >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> >>>> On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson> >>>> wrote: >>>> >>>> Hi folks, >>>> >>>> We've had this internally for a while, and I keep meaning to bring it up >>>> here. The Matcher class has a few public methods that take >>>> StringBuffers, >>>> and we've found it useful to add similar versions that take >>>> StringBuilders. >>>> >>>> It has two benefits: >>>> >>>> - Users don't have to convert from one to the other when they want to use >>>> the method in question. The symmetry is nice. >>>> >>>> - The StringBuilder variants are faster (if lock optimizations don't kick >>>> in, which happens in the interpreter and the client compiler). For >>>> interpreted / client-compiled code, we saw something like a 25% speedup >>>> on >>>> String.replaceAll(), which calls into this code. >>>> >>>> Any interest? Diff attached. >>>> >>>> Jeremy >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > From mike.duigou at oracle.com Mon Apr 7 17:23:38 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 7 Apr 2014 10:23:38 -0700 Subject: UUID.compareTo broken? In-Reply-To: <9473DBFE-49BF-4AC9-B290-9F7D56B09A24@oracle.com> References: <9473DBFE-49BF-4AC9-B290-9F7D56B09A24@oracle.com> Message-ID: <20A90CCF-FE95-4CAE-8596-BA717D71C133@oracle.com> The issue is that the comparison is done upon the signed most significant and least significant long values. At minimum UUIDs should be compared as if they were 128-bit unsigned values. Beyond that, version (which is a "type" not a version) 1 and 2 UUIDs (time based and DCE), should have a more sophisticated comparison which orders the UUIDs by their creation time. This is one of those cases where sloppiness/laziness/ignorance in the original implementation version sticks around forever. We could provide static methods to return appropriate comparators for version 1 and version 2 UUIDs--I've actually written them before for other projects. I also note that UUID does not currently support version 5, SHA-1, which it should. I am hoping to do other performance work on UUID within the scope of Java 9. Adding additional Comparators would fit right in with that. Mike On Apr 7 2014, at 03:49 , Paul Sandoz wrote: > Hi, > > https://github.com/cowtowncoder/java-uuid-generator > > "JDK's java.util.UUID has flawed implementation of compareTo(), which uses naive comparison of 64-bit values. " > > Anyone familiar with the JDK UUID implementation care to comment? > > Paul. From roger.riggs at oracle.com Mon Apr 7 20:36:16 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 07 Apr 2014 16:36:16 -0400 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> Message-ID: <53430C40.4090605@oracle.com> Hi Martin, Can you suggest some example libraries or programs that we should be testing against? Thanks, Roger On 3/26/2014 1:54 PM, Martin Buchholz wrote: > Peter and Roger, please stop going down this road until you have a > solution for my show-stopper problem, that in the below you are > reaping children that don't belong to java.lang.Process > > + pid = waitpid(-1, &exitValue, 0); > > From vladimir.x.ivanov at oracle.com Mon Apr 7 23:53:15 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Apr 2014 03:53:15 +0400 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> <53305D76.7080009@oracle.com> <5332EBD5.8090100@oracle.com> <433BC760-0B2E-4894-988B-7B4D388A9F71@oracle.com> Message-ID: <53433A6B.50203@oracle.com> Thanks, Chris. I have to do one more iteration: http://cr.openjdk.java.net/~vlivanov/8037210/webrev.05/ I have to revert changes related to BMH::reinvokerTarget. Removal of reinvokerTarget in generated concrete BMH classes introduces serious performance regression, since BMH::reinvokerTarget is much more complex than an accessor and it disturbs inlining decisions in too many places. Best regards, Vladimir Ivanov On 4/5/14 3:31 AM, Christian Thalinger wrote: > > On Apr 3, 2014, at 9:44 PM, John Rose > wrote: > >> On Apr 3, 2014, at 6:33 PM, Christian Thalinger >> > > wrote: >> >>> Of course they are popular because these are the type names. There >>> is no type L; it?s an object. I don?t understand why we have to use >>> different names just because they are used in other namespaces. This >>> is not a C define. >> >> They stand for JVM signatures as well as basic types. The letters are >> signature letters. Can we move on from this? > > Sure. Push it. > >> >> ? John >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From paul.sandoz at oracle.com Tue Apr 8 08:03:00 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Apr 2014 10:03:00 +0200 Subject: UUID.compareTo broken? In-Reply-To: <20A90CCF-FE95-4CAE-8596-BA717D71C133@oracle.com> References: <9473DBFE-49BF-4AC9-B290-9F7D56B09A24@oracle.com> <20A90CCF-FE95-4CAE-8596-BA717D71C133@oracle.com> Message-ID: <99E17723-83AB-43FC-BA63-E1700C8C8889@oracle.com> On Apr 7, 2014, at 7:23 PM, Mike Duigou wrote: > The issue is that the comparison is done upon the signed most significant and least significant long values. > > At minimum UUIDs should be compared as if they were 128-bit unsigned values. > Thanks. > Beyond that, version (which is a "type" not a version) 1 and 2 UUIDs (time based and DCE), should have a more sophisticated comparison which orders the UUIDs by their creation time. > > This is one of those cases where sloppiness/laziness/ignorance in the original implementation version sticks around forever. > For the case of incorrect signed comparison is it sticking around because there is code dependent on the current broken behaviour? or do you think it would be possible to change that? i have my suspicious that code dependent compareTo may not break if the total ordering changes, since many cases are likely to be for randomly generated UUIDs. > We could provide static methods to return appropriate comparators for version 1 and version 2 UUIDs--I've actually written them before for other projects. > It would be nice to just have one compareTo that does the right thing based of the UUID types being compared. > I also note that UUID does not currently support version 5, SHA-1, which it should. > > I am hoping to do other performance work on UUID within the scope of Java 9. Adding additional Comparators would fit right in with that. > OK, although it might be nice to bash this on the head sooner? as it might be possible to get into an 8u release depending on what we conclude about backwards compatibility. Paul. From vladimir.x.ivanov at oracle.com Tue Apr 8 09:20:11 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Apr 2014 13:20:11 +0400 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <433BC760-0B2E-4894-988B-7B4D388A9F71@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> <53305D76.7080009@oracle.com> <5332EBD5.8090100@oracle.com> <433BC760-0B2E-4894-988B-7B4D388A9F71@oracle.com> Message-ID: <5343BF4B.2000104@oracle.com> Chris, sorry for the late reply. >> Here's a version with the new naming scheme: >> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03.naming >> >> I like existing naming scheme and OBJECT/VOID/LONG/etc names are quite popular(e.g. Wrapper & ASM (Opcodes) use them). > > Of course they are popular because these are the type names. There is no type L; it?s an object. I don?t understand why we have to use different names just because they are used in other namespaces. This is not a C define. I see 2 problems with the naming scheme you propose. (1) Wrapper, Opcodes & BasicType collide in some places. If element names are the same, static import doesn't work and all usages should be disambiguated. (2) BasicType.I_TYPE corresponds to 5 primitive types. It's misleading to call it BasicType.INT (or BasicType.INTEGER) (consider Wrapper.INT vs BasicType.INT). Current naming scheme makes correspondence with JVM basic types explicit. Best regards, Vladimir Ivanov > >> So, I'm in favor of leaving it as is. >> >> Best regards, >> Vladimir Ivanov >> >> On 3/26/14 12:24 AM, Christian Thalinger wrote: >>> + enum BasicType { >>> + L_TYPE('L', Object.class, Wrapper.OBJECT), // all reference types >>> + I_TYPE('I', int.class, Wrapper.INT), >>> + J_TYPE('J', long.class, Wrapper.LONG), >>> + F_TYPE('F', float.class, Wrapper.FLOAT), >>> + D_TYPE('D', double.class, Wrapper.DOUBLE), // all primitive types >>> + V_TYPE('V', void.class, Wrapper.VOID); // not valid in all contexts >>> >>> I would suggest to not name them X_TYPE but give them meaningful names like Int, Float, Void. The enum BasicType already infers that it?s a type. If you think it?s not clear that it?s a type just use BasicType.Double in that places. >>> >>> On Mar 24, 2014, at 9:29 AM, Vladimir Ivanov wrote: >>> >>>> Updated version: >>>> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03/ >>>> >>>> - changed the way how arrays of types are created: >>>> static final BasicType[] ALL_TYPES = BasicType.values(); >>>> static final BasicType[] ARG_TYPES = Arrays.copyOf(ALL_TYPES, ALL_TYPES.length-1); >>>> >>>> - added a test for BasicType (LambdaFormTest.testBasicType). >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 3/22/14 2:08 AM, Vladimir Ivanov wrote: >>>>> John, thanks for the feedback. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.02 >>>>> >>>>> Also moved LambdaForm.testShortenSignature() into a stand-alone unit test. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 3/21/14 10:54 PM, John Rose wrote: >>>>>> On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov >>>>>> > >>>>>> wrote: >>>>>> >>>>>>> Thanks for the feedback. >>>>>>> >>>>>>> What do you think about the following: >>>>>>> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/ >>>>>> >>>>>> That looks nice. Strong typing; who woulda' thunk it. :-) >>>>>> >>>>>> The uses of ".ordinal()" are the extra cost relative to using just small >>>>>> integers. They seem totally reasonable in the code. >>>>>> >>>>>> I suggest either wrapping "ordinal" as something like "id" or else >>>>>> changing temp names like "id" to "ord", to reinforce the use of a common >>>>>> name. >>>>>> >>>>>> Don't make the enum class public. And especially don't make the mutable >>>>>> arrays public: >>>>>> >>>>>> + public static final BasicType[] ALL_TYPES = { L_TYPE, I_TYPE, >>>>>> J_TYPE, F_TYPE, D_TYPE, V_TYPE }; >>>>>> + public static final BasicType[] ARG_TYPES = { L_TYPE, I_TYPE, >>>>>> J_TYPE, F_TYPE, D_TYPE }; >>>>>> >>>>>> ? John >>>>>> >>>>>> P.S. That would only be safe if we had (what we don't yet) a notion of >>>>>> frozen arrays like: >>>>>> >>>>>> + public static final BasicType final[] ALL_TYPES = { L_TYPE, >>>>>> I_TYPE, J_TYPE, F_TYPE, D_TYPE, V_TYPE }; >>>>>> + public static final BasicType final[] ARG_TYPES = { L_TYPE, >>>>>> I_TYPE, J_TYPE, F_TYPE, D_TYPE }; >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mlvm-dev mailing list >>>>>> mlvm-dev at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>>> >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From paul.sandoz at oracle.com Tue Apr 8 12:47:09 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Apr 2014 14:47:09 +0200 Subject: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types In-Reply-To: <53433A6B.50203@oracle.com> References: <5322E7C6.3050603@oracle.com> <659B1DAF-A57F-457F-9F68-8856795555BF@oracle.com> <532C5F6D.30500@oracle.com> <0C91BFD6-57CA-47B1-8DD3-88E0E4B9D252@oracle.com> <532CB847.3080809@oracle.com> <53305D76.7080009@oracle.com> <5332EBD5.8090100@oracle.com> <433BC760-0B2E-4894-988B-7B4D388A9F71@oracle.com> <53433A6B.50203@oracle.com> Message-ID: On Apr 8, 2014, at 1:53 AM, Vladimir Ivanov wrote: > Thanks, Chris. > > I have to do one more iteration: > http://cr.openjdk.java.net/~vlivanov/8037210/webrev.05/ > > I have to revert changes related to BMH::reinvokerTarget. > > Removal of reinvokerTarget in generated concrete BMH classes introduces serious performance regression, since BMH::reinvokerTarget is much more complex than an accessor and it disturbs inlining decisions in too many places. > OK, IIUC it's just reintroducing some original code back into BMH, nothing else has changed. If so +1 , lets get this pushed :-) I can now see why it might cause a perf issue if the following was used instead: @Override MethodHandle reinvokerTarget() { try { return (MethodHandle) argL(0); } catch (Throwable ex) { throw newInternalError(ex); } } Paul. [1] http://www.diffnow.com/?report=biopj From peter.levart at gmail.com Tue Apr 8 12:54:23 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Apr 2014 14:54:23 +0200 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: <5342D9C3.5080002@oracle.com> References: <532AA782.5030809@gmail.com> <532B246F.20302@oracle.com> <532CF69A.3060301@oracle.com> <533DD230.1050105@oracle.com> <533EE702.2080203@oracle.com> <5342D9C3.5080002@oracle.com> Message-ID: <5343F17F.8030905@gmail.com> On 04/07/2014 07:00 PM, Xueming Shen wrote: > On 04/04/2014 10:08 AM, Xueming Shen wrote: >> On 4/3/14 4:43 PM, Jeremy Manson wrote: >>> Good catch, thanks. >>> >>> I think we should probably just go with the (equivalent to the) >>> StringBuffer variant. I'm pretty loathe to modify the StringBuilder >>> directly if we are going to back that change out. >>> >>> Do you want me to generate a new patch? >> >> I can/will send out an updated webrev before push. > > the latest webrev. > > http://cr.openjdk.java.net/~sherman/8039124/webrev > > -Sherman Hi Sherman, This seems most straight-forward and simple. My proposed variant of appending directly to StringBuffer/StringBuilder (thus to AbstractStringBuilder) had also a performance disadvantage, since code in appendExpandedReplacement() could see at least two different subclasses of AbstractStringBuilder and therefore could not inline calls to AbstractStringBuilder's virtual methods and had to use duo or even megamorphic calls. I measured and it appears that this has more overhead than an additional StringBuilder copy for common-sized replacements... One thing to note. Matcher.appendReplacement(StringBuffer, ...) has never been specified as or implemented to be an atomic operation from the StringBuffer's perspective. But this could easily be achieved: 795 public Matcher appendReplacement(StringBuffer sb, String replacement) { 796 // If no match, return error 797 if (first < 0) 798 throw new IllegalStateException("No match available"); 799 StringBuilder result = new StringBuilder(); 800 appendExpandedReplacement(replacement, result); + synchronized(sb) { 801 // Append the intervening text 802 sb.append(text, lastAppendPosition, first); 803 // Append the match substitution 804 sb.append(result); + } 805 lastAppendPosition = last; 806 return this; 807 } ...I don't know if this makes uncontended locking exhibit any performance penalties since the "sb" monitor is locked twice (nested). I haven't measured, sorry. Peter > >> >> -Sherman >> >>> >>> Jeremy >>> >>> >>> On Thu, Apr 3, 2014 at 2:27 PM, Xueming Shen >>> > wrote: >>> >>> On 03/25/2014 02:07 PM, Jeremy Manson wrote: >>>> Okay. Thanks, Sherman. Here's an updated version. >>>> >>>> I've diverged a bit from Peter's version. In this version, >>>> appendExpandedReplacement takes a StringBuilder. The implications >>>> is that In the StringBuilder case, it saves creating a new >>>> StringBuilder object. In the StringBuffer case, it creates a new >>>> StringBuilder, but it doesn't have to acquire and release all of >>>> those locks. >>> >>> Hi Jeremy, >>> >>> It appears the "optimized" StringBuilder version will cause >>> following test case failure, >>> in which the "xyz" will be copied into the result buffer, even >>> when the replacement >>> string triggers a IAE. >>> >>> // Check nothing has been appended into the output >>> buffer if >>> // the replacement string triggers >>> IllegalArgumentException. >>> Pattern p = Pattern.compile("(abc)"); >>> Matcher m = p.matcher("abcd"); >>> StringBuilder result = new StringBuilder(); >>> try { >>> m.appendReplacement(result, ("xyz$g")); >>> } catch (IllegalArgumentException iae) { >>> if (result.length() != 0) >>> System.err.println(" FAILED"); >>> >>> } >>> >>> We may have to either catch the IAE and reset the sb, or create >>> a new sb, as the StringBuffer does. >>> >>> -Sherman >>> >>> >>> >>>> >>>> I also noticed a redundant cast to (int), which I removed. >>>> >>>> Jeremy >>>> >>>> >>>> On Fri, Mar 21, 2014 at 7:34 PM, Xueming Shen >>>> > wrote: >>>> >>>> let's add the StringBuilder method(s), if you can provide >>>> an updated version, I can run the rest (since it's >>>> to add new api, there is an internal CCC process need to go >>>> through). >>>> >>>> -Sherman >>>> >>>> >>>> On 3/21/14 5:18 PM, Jeremy Manson wrote: >>>>> So, this is all a little opaque to me. How do we make the >>>>> go/no-go decision on something like this? Everyone who has chimed >>>>> in seems to think it is a good idea. >>>>> >>>>> Jeremy >>>>> >>>>> >>>>> On Thu, Mar 20, 2014 at 10:38 AM, Jeremy Manson >>>>> > wrote: >>>>> >>>>> Sherman, >>>>> >>>>> If you had released it then (which you wouldn't have >>>>> been able to do, because you would have to wait another two years >>>>> for Java 7), you would have found that it improved performance >>>>> even with C2. It is only post-escape-analysis that the >>>>> performance in C2 equalized. >>>>> >>>>> Anyway, I think adding the StringBuilder variant and >>>>> deferring / dealing with the Appendable differently is the right >>>>> approach, FWIW. >>>>> >>>>> Jeremy >>>>> >>>>> >>>>> On Thu, Mar 20, 2014 at 10:25 AM, Xueming Shen >>>>> > wrote: >>>>> >>>>> 2009? I do have something similar back to 2009 :-) >>>>> >>>>> http://cr.openjdk.java.net/~sherman/regex_replace/webrev/ >>>>> >>>>> >>>>> Then the ball was dropped around the discussion of >>>>> whether or not >>>>> the IOE should be thrown. >>>>> >>>>> But if we are going to/have to have explicit >>>>> StringBuilder/Buffer pair >>>>> anyway, then we can keep the Appendable version as >>>>> private for now >>>>> and deal with the StringBuilder and Appendable as >>>>> two separate >>>>> issues. >>>>> >>>>> -Sherman >>>>> >>>>> >>>>> On 03/20/2014 09:52 AM, Jeremy Manson wrote: >>>>> >>>>> That's definitely an improvement - I think >>>>> that when I wrote this (circa >>>>> 2009), I didn't think about Appendable. >>>>> >>>>> I take it my argument convinced someone? :) >>>>> >>>>> Jeremy >>>>> >>>>> >>>>> On Thu, Mar 20, 2014 at 1:32 AM, Peter >>>>> Levart>wrote: >>>>> >>>>> On 03/19/2014 06:51 PM, Jeremy Manson wrote: >>>>> >>>>> I'm told that the diff didn't make >>>>> it. I've put it in a Google drive >>>>> folder... >>>>> >>>>> https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ >>>>> edit?usp=sharing >>>>> >>>>> Jeremy >>>>> >>>>> Hi Jeremy, >>>>> >>>>> Your factoring-out of expandReplacement() >>>>> method exposed an opportunity to >>>>> further optimize the code. Instead of >>>>> creating intermediate StringBuilder >>>>> instance for each expandReplacement() >>>>> call, this method could append >>>>> directly to resulting >>>>> StringBuffer/StringBuilder, like in the following: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ >>>>> >>>>> >>>>> webrev.01/ >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> >>>>> On Wed, Mar 19, 2014 at 10:41 AM, >>>>> Jeremy Manson>>>> > >>>>> wrote: >>>>> >>>>> Hi folks, >>>>> >>>>> We've had this internally for a >>>>> while, and I keep meaning to bring it up >>>>> here. The Matcher class has a few >>>>> public methods that take >>>>> StringBuffers, >>>>> and we've found it useful to add >>>>> similar versions that take >>>>> StringBuilders. >>>>> >>>>> It has two benefits: >>>>> >>>>> - Users don't have to convert from >>>>> one to the other when they want to use >>>>> the method in question. The >>>>> symmetry is nice. >>>>> >>>>> - The StringBuilder variants are >>>>> faster (if lock optimizations don't kick >>>>> in, which happens in the >>>>> interpreter and the client compiler). For >>>>> interpreted / client-compiled >>>>> code, we saw something like a 25% speedup >>>>> on >>>>> String.replaceAll(), which calls >>>>> into this code. >>>>> >>>>> Any interest? Diff attached. >>>>> >>>>> Jeremy >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > From vladimir.x.ivanov at oracle.com Tue Apr 8 14:53:11 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Apr 2014 18:53:11 +0400 Subject: Review of MH/LF patches in the review queue In-Reply-To: <0ACCC33E-798A-484C-938C-6CDD689345CD@oracle.com> References: <0ACCC33E-798A-484C-938C-6CDD689345CD@oracle.com> Message-ID: <53440D57.9000500@oracle.com> Paul, thanks for the feedback! See my answers inline. Updated webrevs: http://cr.openjdk.java.net/~vlivanov/8037209/webrev.03/ http://cr.openjdk.java.net/~vlivanov/8038261/webrev.02/ On 4/4/14 3:33 PM, Paul Sandoz wrote: > Hi, > > Reviews of two patches in the queue. > > Paul. > > > http://cr.openjdk.java.net/~vlivanov/8037209/webrev.02/ > > Looks good, though I don't claim to understand all the nuances around casts and JVM/bytecode correctness. Minor stuff below. > > InvokerByteCodeGenerator: > -- > > Unused method: > > static boolean match(MemberName member, MethodHandle fn) { > if (member == null || fn == null) return false; > return member.equals(fn.internalMemberName()); > } Done. > > MethodHandleImpl > -- > > If you are gonna remove the weakly typed wrapper methods for array access, you might as well remove USE_WEAKLY_TYPED_ARRAY_ACCESSORS and it's use? > > - // Weakly typed wrappers of Object[] accessors: > - static Object getElementL(Object a, int i) { return getElementL((Object[])a, i); } > - static void setElementL(Object a, int i, Object x) { setElementL((Object[]) a, i, x); } > - static Object getElementL(Object arrayClass, Object a, int i) { return getElementL((Class) arrayClass, (Object[])a, i); } > - static void setElementL(Object arrayClass, Object a, int i, Object x) { setElementL((Class) arrayClass, (Object[])a, i, x); } > - > > Or otherwise for expediency just leave it in until the array improvements patch follows? IMHO better to be consistent either way. Moved to 8038261. > > VerifyType > -- > > Typo in docs: > > *

> * The primitive type 'void' does not interconvert with any other type, > * even though it is legal to drop any type from the stack and "return void". > * The stack effects, though are difference between void and any other type, > * so it is safer to report a non-trivial conversion. > > s/difference/different > Done. > > > http://cr.openjdk.java.net/~vlivanov/8038261/webrev.01/ > > To re-iterate this is a nice improvement over the previous approach. > > InvokerByteCodeGenerator > -- > > For this specialization: > > if (defc == ArrayAccessor.class && > match(member, ArrayAccessor.OBJECT_ARRAY_GETTER)) { > mv.visitInsn(Opcodes.AALOAD); > } else if (defc == ArrayAccessor.class && > match(member, ArrayAccessor.OBJECT_ARRAY_SETTER)) { > mv.visitInsn(Opcodes.AASTORE); > } else if (member.isMethod()) { > > IIUC all stuff on the stack is correctly placed for the substitution of the invokestatic instruction to ArrayAccessor.set/getElementL with an aastore/load instruction. Correct. setElementL/getElementL are interchangeable with aastore/aaload bytecode instructions w.r.t. stack layout. > This makes we wonder if there is a more general approach for direct or direct-like MHs to be visited and provide their own snippets of ASM producing code. It's an interesting idea. I'm not aware of existing logic to achieve it, but I'll definitely experiment to see how it shapes out. There's an alternative approach using intrinsics, but it doesn't introduce direct coupling between MHs and bytecode shapes. > Is it worthwhile introducing such direct coupling for a specific case, as that tends to increase the inter-connective complexity of the code. How much performance gain is achieved? Setters/getters for primitive arrays can be special-cased in the same manner, but these special cases don't buy much. Accessors (ArrayAccessor.getElement*/setElement*) are very simple anyway. I haven't seen any significant performance difference on octane. I'll experiment with that further. > > The last two re-assigments are never used and are reassigned again at the top of the loop: > > // Update cached form name's info in case an intrinsic spanning multiple names was encountered. > name = lambdaForm.names[i]; > member = name.function.member(); > rtype = name.function.methodType().returnType(); I did it intentionally. There were bugs when cached values become stale due to processing of multi-name intrinsics and they were erroneously used. There's a refactoring of how intrinsics are implemented waiting in the queue, so I'd like to leave it as is for now. Best regards, Vladimir Ivanov From pbenedict at apache.org Tue Apr 8 15:15:01 2014 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 8 Apr 2014 10:15:01 -0500 Subject: Question on the per-build release notes Message-ID: Regarding: http://download.java.net/jdk9/changes/jdk9-b06.html?q=download/jdk9/changes/jdk9-b06.html Currently the release notes have all the bug tickets pointing to bugs.java.com. At least when I try, none of the tickets load; I think this may have something to do with the move to JIRA. So, my question is, should these release notes actually be pointing to JIRA now? -- Cheers, Paul From sean.coffey at oracle.com Tue Apr 8 15:21:11 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 08 Apr 2014 16:21:11 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() Message-ID: <534413E7.3030505@oracle.com> A recently reported bug shows a race condition is possible on the rem == 0 check in ZipFile.read(byte b[], int off, int len). A bad check can result in referencing a jzentry structure that might already be freed and hence result in a SEGV. The fix is trivial and involves moving the rem == 0 check into a synchronized block. The ZipFile API itself is not thread safe so having mutiple threads operate on the same ZipFileInputStream is something that should never be performed. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8038491/webrev/ regards, Sean. From xueming.shen at oracle.com Tue Apr 8 15:59:38 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 08 Apr 2014 08:59:38 -0700 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <534413E7.3030505@oracle.com> References: <534413E7.3030505@oracle.com> Message-ID: <53441CEA.30008@oracle.com> Hi Sean, It might be more explicit to check "if (zentry == 0)" here? -Sherman On 4/8/14 8:21 AM, Se?n Coffey wrote: > A recently reported bug shows a race condition is possible on the rem > == 0 check in ZipFile.read(byte b[], int off, int len). A bad check > can result in referencing a jzentry structure that might already be > freed and hence result in a SEGV. The fix is trivial and involves > moving the rem == 0 check into a synchronized block. The ZipFile API > itself is not thread safe so having mutiple threads operate on the > same ZipFileInputStream is something that should never be performed. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8038491/webrev/ > > regards, > Sean. From stevenschlansker at gmail.com Tue Apr 8 16:34:50 2014 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Tue, 8 Apr 2014 09:34:50 -0700 Subject: UUID.compareTo broken? In-Reply-To: <99E17723-83AB-43FC-BA63-E1700C8C8889@oracle.com> References: <9473DBFE-49BF-4AC9-B290-9F7D56B09A24@oracle.com> <20A90CCF-FE95-4CAE-8596-BA717D71C133@oracle.com> <99E17723-83AB-43FC-BA63-E1700C8C8889@oracle.com> Message-ID: <9A944EBC-82B8-47BC-A619-CB4EF3364AD4@gmail.com> On Apr 8, 2014, at 1:03 AM, Paul Sandoz wrote: > > On Apr 7, 2014, at 7:23 PM, Mike Duigou wrote: > >> I also note that UUID does not currently support version 5, SHA-1, which it should. >> >> I am hoping to do other performance work on UUID within the scope of Java 9. Adding additional Comparators would fit right in with that. >> > > OK, although it might be nice to bash this on the head sooner? as it might be possible to get into an 8u release depending on what we conclude about backwards compatibility. If random-end-user opinions count for anything, I would strongly +1 for an 8u update with this. We are still porting around routines to bypass UUID?s from/toString because they are embarrassingly inefficient, and it would be nice to ditch that code before 9 ships :) From mike.duigou at oracle.com Tue Apr 8 16:53:35 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 8 Apr 2014 09:53:35 -0700 Subject: UUID.compareTo broken? In-Reply-To: <9A944EBC-82B8-47BC-A619-CB4EF3364AD4@gmail.com> References: <9473DBFE-49BF-4AC9-B290-9F7D56B09A24@oracle.com> <20A90CCF-FE95-4CAE-8596-BA717D71C133@oracle.com> <99E17723-83AB-43FC-BA63-E1700C8C8889@oracle.com> <9A944EBC-82B8-47BC-A619-CB4EF3364AD4@gmail.com> Message-ID: <265ABB36-B052-473A-BCC0-1FE3A5B0D5B9@oracle.com> I am targeting to have the performance improvements you contributed to UUID into 8u40 (around the end of the year). I expect to contribute the work into OpenJDK 9 in June-Julyish. Mike On Apr 8 2014, at 09:34 , Steven Schlansker wrote: > > On Apr 8, 2014, at 1:03 AM, Paul Sandoz wrote: > >> >> On Apr 7, 2014, at 7:23 PM, Mike Duigou wrote: >> >>> I also note that UUID does not currently support version 5, SHA-1, which it should. >>> >>> I am hoping to do other performance work on UUID within the scope of Java 9. Adding additional Comparators would fit right in with that. >>> >> >> OK, although it might be nice to bash this on the head sooner? as it might be possible to get into an 8u release depending on what we conclude about backwards compatibility. > > If random-end-user opinions count for anything, I would strongly +1 for an 8u update with this. We are still porting around routines to bypass UUID?s from/toString because they are embarrassingly inefficient, and it would be nice to ditch that code before 9 ships :) > From sean.coffey at oracle.com Tue Apr 8 17:29:35 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 08 Apr 2014 18:29:35 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <53441CEA.30008@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> Message-ID: <534431FF.6060609@oracle.com> Sherman, I see rem == 0 condition becoming true before the zentry variable is set to 0 (in close()) - in a multi threaded scenario like this one, we could have zero remaining bytes in zentry and yet have a zentry != 0 - your suggestion would prevent the SEGV (since we're in the sync block) but we would needlessly cycle into the ensureOpenOrZipException() and ZipFile.read code (line 713) if another thread tasked with the close() call was knocked off by the dispatcher during the various rem == 0 checks that we make : e.g 722 if (rem == 0) { 723 close(); 724 } Am I reading this correctly ? regards, Sean. On 08/04/2014 16:59, Xueming Shen wrote: > Hi Sean, > > It might be more explicit to check "if (zentry == 0)" here? > > -Sherman > > On 4/8/14 8:21 AM, Se?n Coffey wrote: >> A recently reported bug shows a race condition is possible on the rem >> == 0 check in ZipFile.read(byte b[], int off, int len). A bad check >> can result in referencing a jzentry structure that might already be >> freed and hence result in a SEGV. The fix is trivial and involves >> moving the rem == 0 check into a synchronized block. The ZipFile API >> itself is not thread safe so having mutiple threads operate on the >> same ZipFileInputStream is something that should never be performed. >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8038491/webrev/ >> >> regards, >> Sean. > From jeremymanson at google.com Tue Apr 8 17:47:15 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 8 Apr 2014 10:47:15 -0700 Subject: StringBuilder version of java.util.regex.Matcher.append* In-Reply-To: <5342D9C3.5080002@oracle.com> References: <532AA782.5030809@gmail.com> <532B246F.20302@oracle.com> <532CF69A.3060301@oracle.com> <533DD230.1050105@oracle.com> <533EE702.2080203@oracle.com> <5342D9C3.5080002@oracle.com> Message-ID: This looks fine to me, Sherman. Thanks for the hard work! Jeremy On Mon, Apr 7, 2014 at 10:00 AM, Xueming Shen wrote: > On 04/04/2014 10:08 AM, Xueming Shen wrote: > > On 4/3/14 4:43 PM, Jeremy Manson wrote: > > Good catch, thanks. > > I think we should probably just go with the (equivalent to the) > StringBuffer variant. I'm pretty loathe to modify the StringBuilder > directly if we are going to back that change out. > > Do you want me to generate a new patch? > > > I can/will send out an updated webrev before push. > > > the latest webrev. > > http://cr.openjdk.java.net/~sherman/8039124/webrev > > -Sherman > > > > -Sherman > > > Jeremy > > > On Thu, Apr 3, 2014 at 2:27 PM, Xueming Shen wrote: > >> On 03/25/2014 02:07 PM, Jeremy Manson wrote: >> >> Okay. Thanks, Sherman. Here's an updated version. >> >> I've diverged a bit from Peter's version. In this version, >> appendExpandedReplacement takes a StringBuilder. The implications is that >> In the StringBuilder case, it saves creating a new StringBuilder object. >> In the StringBuffer case, it creates a new StringBuilder, but it doesn't >> have to acquire and release all of those locks. >> >> >> Hi Jeremy, >> >> It appears the "optimized" StringBuilder version will cause following >> test case failure, >> in which the "xyz" will be copied into the result buffer, even when the >> replacement >> string triggers a IAE. >> >> // Check nothing has been appended into the output buffer if >> // the replacement string triggers IllegalArgumentException. >> Pattern p = Pattern.compile("(abc)"); >> Matcher m = p.matcher("abcd"); >> StringBuilder result = new StringBuilder(); >> try { >> m.appendReplacement(result, ("xyz$g")); >> } catch (IllegalArgumentException iae) { >> if (result.length() != 0) >> System.err.println(" FAILED"); >> >> } >> >> We may have to either catch the IAE and reset the sb, or create >> a new sb, as the StringBuffer does. >> >> -Sherman >> >> >> >> >> I also noticed a redundant cast to (int), which I removed. >> >> Jeremy >> >> >> On Fri, Mar 21, 2014 at 7:34 PM, Xueming Shen wrote: >> >> let's add the StringBuilder method(s), if you can provide an updated >> version, I can run the rest (since it's >> to add new api, there is an internal CCC process need to go through). >> >> -Sherman >> >> >> On 3/21/14 5:18 PM, Jeremy Manson wrote: >> >> So, this is all a little opaque to me. How do we make the go/no-go >> decision on something like this? Everyone who has chimed in seems to think >> it is a good idea. >> >> Jeremy >> >> >> On Thu, Mar 20, 2014 at 10:38 AM, Jeremy Manson wrote: >> >> Sherman, >> >> If you had released it then (which you wouldn't have been able to do, >> because you would have to wait another two years for Java 7), you would >> have found that it improved performance even with C2. It is only >> post-escape-analysis that the performance in C2 equalized. >> >> Anyway, I think adding the StringBuilder variant and deferring / >> dealing with the Appendable differently is the right approach, FWIW. >> >> Jeremy >> >> >> On Thu, Mar 20, 2014 at 10:25 AM, Xueming Shen wrote: >> >> 2009? I do have something similar back to 2009 :-) >> >> http://cr.openjdk.java.net/~sherman/regex_replace/webrev/ >> >> Then the ball was dropped around the discussion of whether or not >> the IOE should be thrown. >> >> But if we are going to/have to have explicit StringBuilder/Buffer pair >> anyway, then we can keep the Appendable version as private for now >> and deal with the StringBuilder and Appendable as two separate >> issues. >> >> -Sherman >> >> >> On 03/20/2014 09:52 AM, Jeremy Manson wrote: >> >> That's definitely an improvement - I think that when I wrote this (circa >> 2009), I didn't think about Appendable. >> >> I take it my argument convinced someone? :) >> >> Jeremy >> >> >> On Thu, Mar 20, 2014 at 1:32 AM, Peter Levart> >wrote: >> >> On 03/19/2014 06:51 PM, Jeremy Manson wrote: >> >> I'm told that the diff didn't make it. I've put it in a Google drive >> folder... >> >> https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/ >> edit?usp=sharing >> >> Jeremy >> >> Hi Jeremy, >> >> Your factoring-out of expandReplacement() method exposed an opportunity to >> further optimize the code. Instead of creating intermediate StringBuilder >> instance for each expandReplacement() call, this method could append >> directly to resulting StringBuffer/StringBuilder, like in the following: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ >> webrev.01/ >> >> >> Regards, Peter >> >> >> >> On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson >> wrote: >> >> Hi folks, >> >> We've had this internally for a while, and I keep meaning to bring it up >> here. The Matcher class has a few public methods that take >> StringBuffers, >> and we've found it useful to add similar versions that take >> StringBuilders. >> >> It has two benefits: >> >> - Users don't have to convert from one to the other when they want to use >> the method in question. The symmetry is nice. >> >> - The StringBuilder variants are faster (if lock optimizations don't kick >> in, which happens in the interpreter and the client compiler). For >> interpreted / client-compiled code, we saw something like a 25% speedup >> on >> String.replaceAll(), which calls into this code. >> >> Any interest? Diff attached. >> >> Jeremy >> >> >> >> >> >> >> >> >> > > > From martinrb at google.com Tue Apr 8 17:48:36 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Apr 2014 10:48:36 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: <5343A8B6.8030303@gmail.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> Message-ID: Peter, thank you very much for your deep analysis. TIL and am horrified: signals on Unix are not queued, not even if you specify SA_SIGINFO. Providing siginfo turns signals into proper "messages" each with unique content, and it is unacceptable to simply drop some (Especially when proper queueing seems required for so-called real-time signals), but at least the Linux kernel does so very deliberately. 45 years later, we are still fighting with unreliable Unix signals... We can't call waitpid(WAIT_ANY, ) because we can only wait for processes owned by the j.l.Process subsystem. We can't override libc functions like waitpid because the JVM may be a "guest" in some other process. I don't know of any public examples, but it is reasonable to add a JVM to a previously pure native code application, similarly to the way tcl or lua is often used to provide a higher-level safer programming api to native code, and some programs at Google use this strategy. What problem are we actually trying to solve? The army of reaper threads is ugly, but the inefficiency is greatly mitigated by the use of small explicit stack sizes. Redoing the process code is always risky, as we have already seen in this thread. Maintaining a single child helper process which spawns all the (grand)child processes seems reasonable, although it would create a permanent intermediate entry in the process table (pstree?) which might confuse some sysadmin scripts. Is it worth it? From xueming.shen at oracle.com Tue Apr 8 17:57:22 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 08 Apr 2014 10:57:22 -0700 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <534431FF.6060609@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> Message-ID: <53443882.4010304@oracle.com> On 4/8/14 10:29 AM, Se?n Coffey wrote: > Sherman, > > I see rem == 0 condition becoming true before the zentry variable is > set to 0 (in close()) - in a multi threaded scenario like this one, we > could have zero remaining bytes in zentry and yet have a zentry != 0 - > your suggestion would prevent the SEGV (since we're in the sync block) > but we would needlessly cycle into the ensureOpenOrZipException() and > ZipFile.read code (line 713) if another thread tasked with the close() > call was knocked off by the dispatcher during the various rem == 0 > checks that we make : e.g > > 722 if (rem == 0) { > 723 close(); > 724 } > > Am I reading this correctly ? > My take is that the performance is not a concern here, the only real problem is the SEGV. Given "num" is not a volatile and is not updated under synchronized block, check "num == 0" is not going to make ZFIS work for mult-thread usage. It also makes me nervous to check it inside the synchronized block as a global "flag". I'm also concerned that the change to check the rem == 0 after the check of "len" may also change the behavior of someone's code in certain circumstance... -Sherman > regards, > Sean. > > On 08/04/2014 16:59, Xueming Shen wrote: >> Hi Sean, >> >> It might be more explicit to check "if (zentry == 0)" here? >> >> -Sherman >> >> On 4/8/14 8:21 AM, Se?n Coffey wrote: >>> A recently reported bug shows a race condition is possible on the >>> rem == 0 check in ZipFile.read(byte b[], int off, int len). A bad >>> check can result in referencing a jzentry structure that might >>> already be freed and hence result in a SEGV. The fix is trivial and >>> involves moving the rem == 0 check into a synchronized block. The >>> ZipFile API itself is not thread safe so having mutiple threads >>> operate on the same ZipFileInputStream is something that should >>> never be performed. >>> >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8038491/webrev/ >>> >>> regards, >>> Sean. >> > From pavel.rappo at oracle.com Tue Apr 8 18:12:31 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 8 Apr 2014 19:12:31 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <534431FF.6060609@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> Message-ID: Hi Sean, Sherman as far as the client is using ZipFileInputStream in a multithreaded fashion (de facto), don't we have to rethink synchronization for the machinery of ZipFileInputStream.read? As far as I understand it's not enough to put this particular read of 'rem' into the synchronized block, as there are at least 2 more accesses to it (and only in the 'read' method). We're reading it in the synchronized block, fine, but all the corresponding reads/writes have to be done with respect to 'happens-before' relationship between them. -Pavel On 8 Apr 2014, at 18:29, Se?n Coffey wrote: > Sherman, > > I see rem == 0 condition becoming true before the zentry variable is set to 0 (in close()) - in a multi threaded scenario like this one, we could have zero remaining bytes in zentry and yet have a zentry != 0 - your suggestion would prevent the SEGV (since we're in the sync block) but we would needlessly cycle into the ensureOpenOrZipException() and ZipFile.read code (line 713) if another thread tasked with the close() call was knocked off by the dispatcher during the various rem == 0 checks that we make : e.g > > 722 if (rem == 0) { > 723 close(); > 724 } > > Am I reading this correctly ? > > regards, > Sean. > > On 08/04/2014 16:59, Xueming Shen wrote: >> Hi Sean, >> >> It might be more explicit to check "if (zentry == 0)" here? >> >> -Sherman >> >> On 4/8/14 8:21 AM, Se?n Coffey wrote: >>> A recently reported bug shows a race condition is possible on the rem == 0 check in ZipFile.read(byte b[], int off, int len). A bad check can result in referencing a jzentry structure that might already be freed and hence result in a SEGV. The fix is trivial and involves moving the rem == 0 check into a synchronized block. The ZipFile API itself is not thread safe so having mutiple threads operate on the same ZipFileInputStream is something that should never be performed. >>> >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8038491/webrev/ >>> >>> regards, >>> Sean. >> > From sean.coffey at oracle.com Tue Apr 8 18:32:19 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 08 Apr 2014 19:32:19 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> Message-ID: <534440B3.6090305@oracle.com> On 08/04/2014 19:12, Pavel Rappo wrote: > Hi Sean, Sherman > > as far as the client is using ZipFileInputStream in a multithreaded fashion (de facto), don't we have to rethink synchronization for the machinery of ZipFileInputStream.read? As far as I understand it's not enough to put this particular read of 'rem' into the synchronized block, as there are > at least 2 more accesses to it (and only in the 'read' method). We're reading it in the synchronized block, fine, but all the corresponding reads/writes have to be done with respect to 'happens-before' relationship between them. The ZipFile API itself is not thread safe and the example given would be buggy application code. However - we should cover this case. As per Sherman's last mail then, I'll make the change and check for zentry == 0 instead of rem variable. zentry is read and set under synchronization. just need to run it through JPRT. One other note on the ZipFileInputStream.read(..) method : if (len <= 0) { return 0; } It looks like the above check is not necessary since a negative len check is make in the native ZIP_READ function which this ends up calling (and has same behaviour / return value) Regards, Sean. > > -Pavel > > On 8 Apr 2014, at 18:29, Se?n Coffey wrote: > >> Sherman, >> >> I see rem == 0 condition becoming true before the zentry variable is set to 0 (in close()) - in a multi threaded scenario like this one, we could have zero remaining bytes in zentry and yet have a zentry != 0 - your suggestion would prevent the SEGV (since we're in the sync block) but we would needlessly cycle into the ensureOpenOrZipException() and ZipFile.read code (line 713) if another thread tasked with the close() call was knocked off by the dispatcher during the various rem == 0 checks that we make : e.g >> >> 722 if (rem == 0) { >> 723 close(); >> 724 } >> >> Am I reading this correctly ? >> >> regards, >> Sean. >> >> On 08/04/2014 16:59, Xueming Shen wrote: >>> Hi Sean, >>> >>> It might be more explicit to check "if (zentry == 0)" here? >>> >>> -Sherman >>> >>> On 4/8/14 8:21 AM, Se?n Coffey wrote: >>>> A recently reported bug shows a race condition is possible on the rem == 0 check in ZipFile.read(byte b[], int off, int len). A bad check can result in referencing a jzentry structure that might already be freed and hence result in a SEGV. The fix is trivial and involves moving the rem == 0 check into a synchronized block. The ZipFile API itself is not thread safe so having mutiple threads operate on the same ZipFileInputStream is something that should never be performed. >>>> >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8038491/webrev/ >>>> >>>> regards, >>>> Sean. From chris.hegarty at oracle.com Tue Apr 8 18:33:02 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 8 Apr 2014 19:33:02 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> Message-ID: <4362897C-F455-48C5-A164-CD779F19467F@oracle.com> On 8 Apr 2014, at 19:12, Pavel Rappo wrote: > Hi Sean, Sherman > > as far as the client is using ZipFileInputStream in a multithreaded fashion (de facto), don't we have to rethink synchronization for the machinery of ZipFileInputStream.read? As far as I understand it's not enough to put this particular read of 'rem' into the synchronized block, as there are > at least 2 more accesses to it (and only in the 'read' method). We're reading it in the synchronized block, fine, but all the corresponding reads/writes have to be done with respect to 'happens-before' relationship between them. Agreed. There doesn?t appear, or at least I cannot find, any statement in ZipFile about its thread-safety ( or lack there of ), but the implementation of ZipFile appears to be ?somewhat? thread-safe. The InputStreams returned by getInputStream(ZipEntry) are not. Sean?s testcase clearly shows that a single InputStream is being shared across multiple threads. Unless we want to make these streams thread-safe then we probably should not make any changes here. -Chris. > > -Pavel > > On 8 Apr 2014, at 18:29, Se?n Coffey wrote: > >> Sherman, >> >> I see rem == 0 condition becoming true before the zentry variable is set to 0 (in close()) - in a multi threaded scenario like this one, we could have zero remaining bytes in zentry and yet have a zentry != 0 - your suggestion would prevent the SEGV (since we're in the sync block) but we would needlessly cycle into the ensureOpenOrZipException() and ZipFile.read code (line 713) if another thread tasked with the close() call was knocked off by the dispatcher during the various rem == 0 checks that we make : e.g >> >> 722 if (rem == 0) { >> 723 close(); >> 724 } >> >> Am I reading this correctly ? >> >> regards, >> Sean. >> >> On 08/04/2014 16:59, Xueming Shen wrote: >>> Hi Sean, >>> >>> It might be more explicit to check "if (zentry == 0)" here? >>> >>> -Sherman >>> >>> On 4/8/14 8:21 AM, Se?n Coffey wrote: >>>> A recently reported bug shows a race condition is possible on the rem == 0 check in ZipFile.read(byte b[], int off, int len). A bad check can result in referencing a jzentry structure that might already be freed and hence result in a SEGV. The fix is trivial and involves moving the rem == 0 check into a synchronized block. The ZipFile API itself is not thread safe so having mutiple threads operate on the same ZipFileInputStream is something that should never be performed. >>>> >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8038491/webrev/ >>>> >>>> regards, >>>> Sean. >>> >> > From xueming.shen at oracle.com Tue Apr 8 18:41:22 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 08 Apr 2014 11:41:22 -0700 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <4362897C-F455-48C5-A164-CD779F19467F@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <4362897C-F455-48C5-A164-CD779F19467F@oracle.com> Message-ID: <534442D2.1020109@oracle.com> On 4/8/14 11:33 AM, Chris Hegarty wrote: > On 8 Apr 2014, at 19:12, Pavel Rappo wrote: > >> Hi Sean, Sherman >> >> as far as the client is using ZipFileInputStream in a multithreaded fashion (de facto), don't we have to rethink synchronization for the machinery of ZipFileInputStream.read? As far as I understand it's not enough to put this particular read of 'rem' into the synchronized block, as there are >> at least 2 more accesses to it (and only in the 'read' method). We're reading it in the synchronized block, fine, but all the corresponding reads/writes have to be done with respect to 'happens-before' relationship between them. > Agreed. There doesn?t appear, or at least I cannot find, any statement in ZipFile about its thread-safety ( or lack there of ), but the implementation of ZipFile appears to be ?somewhat? thread-safe. The InputStreams returned by getInputStream(ZipEntry) are not. Sean?s testcase clearly shows that a single InputStream is being shared across multiple threads. Unless we want to make these streams thread-safe then we probably should not make any changes here. > It is a reasonable use scenario to close a java.io.InputStream via a different thread and it definitely should not lead to a SEGV. But java.io.InputStream itself is not "thread-safe". To read from a java.io.InputStream via multiple thread is kinda of useless use scenario, which normally means unpredictable reading result for those read operation. -Sherman > >> -Pavel >> >> On 8 Apr 2014, at 18:29, Se?n Coffey wrote: >> >>> Sherman, >>> >>> I see rem == 0 condition becoming true before the zentry variable is set to 0 (in close()) - in a multi threaded scenario like this one, we could have zero remaining bytes in zentry and yet have a zentry != 0 - your suggestion would prevent the SEGV (since we're in the sync block) but we would needlessly cycle into the ensureOpenOrZipException() and ZipFile.read code (line 713) if another thread tasked with the close() call was knocked off by the dispatcher during the various rem == 0 checks that we make : e.g >>> >>> 722 if (rem == 0) { >>> 723 close(); >>> 724 } >>> >>> Am I reading this correctly ? >>> >>> regards, >>> Sean. >>> >>> On 08/04/2014 16:59, Xueming Shen wrote: >>>> Hi Sean, >>>> >>>> It might be more explicit to check "if (zentry == 0)" here? >>>> >>>> -Sherman >>>> >>>> On 4/8/14 8:21 AM, Se?n Coffey wrote: >>>>> A recently reported bug shows a race condition is possible on the rem == 0 check in ZipFile.read(byte b[], int off, int len). A bad check can result in referencing a jzentry structure that might already be freed and hence result in a SEGV. The fix is trivial and involves moving the rem == 0 check into a synchronized block. The ZipFile API itself is not thread safe so having mutiple threads operate on the same ZipFileInputStream is something that should never be performed. >>>>> >>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8038491/webrev/ >>>>> >>>>> regards, >>>>> Sean. From chris.hegarty at oracle.com Tue Apr 8 18:44:35 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 8 Apr 2014 19:44:35 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <534442D2.1020109@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <4362897C-F455-48C5-A164-CD779F19467F@oracle.com> <534442D2.1020109@oracle.com> Message-ID: <3618CF28-4C28-44D0-A0F6-A1241CAE0B31@oracle.com> On 8 Apr 2014, at 19:41, Xueming Shen wrote: > On 4/8/14 11:33 AM, Chris Hegarty wrote: >> On 8 Apr 2014, at 19:12, Pavel Rappo wrote: >> >>> Hi Sean, Sherman >>> >>> as far as the client is using ZipFileInputStream in a multithreaded fashion (de facto), don't we have to rethink synchronization for the machinery of ZipFileInputStream.read? As far as I understand it's not enough to put this particular read of 'rem' into the synchronized block, as there are >>> at least 2 more accesses to it (and only in the 'read' method). We're reading it in the synchronized block, fine, but all the corresponding reads/writes have to be done with respect to 'happens-before' relationship between them. >> Agreed. There doesn?t appear, or at least I cannot find, any statement in ZipFile about its thread-safety ( or lack there of ), but the implementation of ZipFile appears to be ?somewhat? thread-safe. The InputStreams returned by getInputStream(ZipEntry) are not. Sean?s testcase clearly shows that a single InputStream is being shared across multiple threads. Unless we want to make these streams thread-safe then we probably should not make any changes here. >> > > It is a reasonable use scenario to close a java.io.InputStream via a different thread and it > definitely should not lead to a SEGV. But java.io.InputStream itself is not "thread-safe". To > read from a java.io.InputStream via multiple thread is kinda of useless use scenario, which > normally means unpredictable reading result for those read operation. Ok, sounds reasonable. -Chris. > > -Sherman > >> >>> -Pavel >>> >>> On 8 Apr 2014, at 18:29, Se?n Coffey wrote: >>> >>>> Sherman, >>>> >>>> I see rem == 0 condition becoming true before the zentry variable is set to 0 (in close()) - in a multi threaded scenario like this one, we could have zero remaining bytes in zentry and yet have a zentry != 0 - your suggestion would prevent the SEGV (since we're in the sync block) but we would needlessly cycle into the ensureOpenOrZipException() and ZipFile.read code (line 713) if another thread tasked with the close() call was knocked off by the dispatcher during the various rem == 0 checks that we make : e.g >>>> >>>> 722 if (rem == 0) { >>>> 723 close(); >>>> 724 } >>>> >>>> Am I reading this correctly ? >>>> >>>> regards, >>>> Sean. >>>> >>>> On 08/04/2014 16:59, Xueming Shen wrote: >>>>> Hi Sean, >>>>> >>>>> It might be more explicit to check "if (zentry == 0)" here? >>>>> >>>>> -Sherman >>>>> >>>>> On 4/8/14 8:21 AM, Se?n Coffey wrote: >>>>>> A recently reported bug shows a race condition is possible on the rem == 0 check in ZipFile.read(byte b[], int off, int len). A bad check can result in referencing a jzentry structure that might already be freed and hence result in a SEGV. The fix is trivial and involves moving the rem == 0 check into a synchronized block. The ZipFile API itself is not thread safe so having mutiple threads operate on the same ZipFileInputStream is something that should never be performed. >>>>>> >>>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8038491/webrev/ >>>>>> >>>>>> regards, >>>>>> Sean. > From chris.hegarty at oracle.com Tue Apr 8 18:52:23 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 8 Apr 2014 19:52:23 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <53443882.4010304@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> Message-ID: On 8 Apr 2014, at 18:57, Xueming Shen wrote: > > On 4/8/14 10:29 AM, Se?n Coffey wrote: >> Sherman, >> >> I see rem == 0 condition becoming true before the zentry variable is set to 0 (in close()) - in a multi threaded scenario like this one, we could have zero remaining bytes in zentry and yet have a zentry != 0 - your suggestion would prevent the SEGV (since we're in the sync block) but we would needlessly cycle into the ensureOpenOrZipException() and ZipFile.read code (line 713) if another thread tasked with the close() call was knocked off by the dispatcher during the various rem == 0 checks that we make : e.g >> >> 722 if (rem == 0) { >> 723 close(); >> 724 } >> >> Am I reading this correctly ? >> > My take is that the performance is not a concern here, the only real problem is the SEGV. > Given "num" is not a volatile and is not updated under synchronized block, check "num == 0" > is not going to make ZFIS work for mult-thread usage. It also makes me nervous to check it > inside the synchronized block as a global "flag". I'm also concerned that the change to check > the rem == 0 after the check of "len" may also change the behavior of someone's code in > certain circumstance? To make this safe and simple, why not just move the close inside the synchronized block to ensure no concurrent access before close completes ( if needed ). There is very little computation overhead added to the synchronized block, but guarantees serial access to close. synchronized (ZipFile.this) { ensureOpenOrZipException(); len = ZipFile.read(ZipFile.this.jzfile, jzentry, pos, b, off, len); if (len > 0) { pos += len; rem -= len; } if (rem == 0) { close(); } } -Chris. > > -Sherman > >> regards, >> Sean. >> >> On 08/04/2014 16:59, Xueming Shen wrote: >>> Hi Sean, >>> >>> It might be more explicit to check "if (zentry == 0)" here? >>> >>> -Sherman >>> >>> On 4/8/14 8:21 AM, Se?n Coffey wrote: >>>> A recently reported bug shows a race condition is possible on the rem == 0 check in ZipFile.read(byte b[], int off, int len). A bad check can result in referencing a jzentry structure that might already be freed and hence result in a SEGV. The fix is trivial and involves moving the rem == 0 check into a synchronized block. The ZipFile API itself is not thread safe so having mutiple threads operate on the same ZipFileInputStream is something that should never be performed. >>>> >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8038491/webrev/ >>>> >>>> regards, >>>> Sean. >>> >> > From mike.duigou at oracle.com Tue Apr 8 19:15:28 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 8 Apr 2014 12:15:28 -0700 Subject: UUID.compareTo broken? In-Reply-To: <99E17723-83AB-43FC-BA63-E1700C8C8889@oracle.com> References: <9473DBFE-49BF-4AC9-B290-9F7D56B09A24@oracle.com> <20A90CCF-FE95-4CAE-8596-BA717D71C133@oracle.com> <99E17723-83AB-43FC-BA63-E1700C8C8889@oracle.com> Message-ID: <59FFB1A3-1B99-4018-A7C4-AD8ED3A95C4A@oracle.com> On Apr 8 2014, at 01:03 , Paul Sandoz wrote: > > On Apr 7, 2014, at 7:23 PM, Mike Duigou wrote: > >> The issue is that the comparison is done upon the signed most significant and least significant long values. >> >> At minimum UUIDs should be compared as if they were 128-bit unsigned values. >> > > Thanks. > > >> Beyond that, version (which is a "type" not a version) 1 and 2 UUIDs (time based and DCE), should have a more sophisticated comparison which orders the UUIDs by their creation time. >> >> This is one of those cases where sloppiness/laziness/ignorance in the original implementation version sticks around forever. >> > > For the case of incorrect signed comparison is it sticking around because there is code dependent on the current broken behaviour? Probably even if the dependence is implicit such as expecting a particular iteration order > or do you think it would be possible to change that? I requested fixing the compareTo long ago (back when I was a mere user of the JDK) and was told that it could not be changed. > i have my suspicious that code dependent compareTo may not break if the total ordering changes, since many cases are likely to be for randomly generated UUIDs. I agree that most code would probably be fine. I worry though that there will be cases that either explicitly or implicitly depend upon current ordering. Surprisingly there a lot of cases where UUIDs are created using the UUID(long, long) constructor with non-random data such as incrementing numbers: UUID myUUID = new UUID(SOME_CONSTANT, atomicSerial.incrementAndGet()); This usage exists, I believe, because we haven't provided direct support for MAC version UUIDs. Unfortunately the UUID(long,long) constructor does not check that the UUID constructed is even valid and usually they are not. This usage, while egregious, is common. These people would probably be impacted by changes in ordering. >> We could provide static methods to return appropriate comparators for version 1 and version 2 UUIDs--I've actually written them before for other projects. >> > > It would be nice to just have one compareTo that does the right thing based of the UUID types being compared. If it were up to me only the time and DCE UUIDs would be comparable, there's no ordering relationship for other versions. The comparators I've considered adding would only allow comparisons within the same version. >> I also note that UUID does not currently support version 5, SHA-1, which it should. >> >> I am hoping to do other performance work on UUID within the scope of Java 9. Adding additional Comparators would fit right in with that. >> > > OK, although it might be nice to bash this on the head sooner? as it might be possible to get into an 8u release depending on what we conclude about backwards compatibility. Any change to the ordering of the compareTo would have to happen in a major version if at all. I am very reluctant to change this behaviour when providing alternative comparators might just be a better choice. Mike From sean.coffey at oracle.com Tue Apr 8 20:28:41 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Tue, 08 Apr 2014 21:28:41 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> Message-ID: <53445BF9.6010902@oracle.com> Chris, ZipFileInputStream.skip(..) can also close out the stream and free up the underlying jzentry resources. Per Sherman's suggestion I substituted rem for jzentry == 0 check but ran into issues with other tests [1] Another simple change (and to preserve old behaviour) might be just to extend the synchronized block to start at top of the read method and to check for both (rem == 0 || jzentry == 0) [2] tests running. regards, Sean. [1] > java.util.zip.ZipException: ZIP_Read: specified offset out of range > at java.util.zip.ZipFile.read(Native Method) > at java.util.zip.ZipFile.access$1400(ZipFile.java:61) > at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:715) > at java.io.InputStream.read(InputStream.java:101) > at com.sun.java.util.jar.pack.Package$File.readFrom(Package.java:849) > at com.sun.java.util.jar.pack.PackerImpl$DoPack.readFile(PackerImpl.java:517) > at com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:466) > at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:97) > at sun.tools.jar.Main.run(Main.java:228) > at sun.tools.jar.Main.main(Main.java:1233) > Exception in thread "main" java.util.zip.ZipException: ZIP_Read: specified offset out of range > at java.util.zip.ZipFile.read(Native Method) > at java.util.zip.ZipFile.access$1400(ZipFile.java:61) > at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:715) > at java.io.InputStream.read(InputStream.java:101) > at com.sun.java.util.jar.pack.Package$File.readFrom(Package.java:849) > at com.sun.java.util.jar.pack.PackerImpl$DoPack.readFile(PackerImpl.java:517) > at com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:466) > at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:97) > at com.sun.java.util.jar.pack.Driver.main(Driver.java:313) > java.util.zip.ZipException: zip file is empty > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.(ZipFile.java:220) > at java.util.zip.ZipFile.(ZipFile.java:150) > at java.util.jar.JarFile.(JarFile.java:166) > at java.util.jar.JarFile.(JarFile.java:103) > at TestNormal.main(TestNormal.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:484) > at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) > at java.lang.Thread.run(Thread.java:744) [2] > diff --git a/src/share/classes/java/util/zip/ZipFile.java > b/src/share/classes/java/util/zip/ZipFile.java > --- a/src/share/classes/java/util/zip/ZipFile.java > +++ b/src/share/classes/java/util/zip/ZipFile.java > @@ -700,7 +700,8 @@ > } > > public int read(byte b[], int off, int len) throws IOException { > - if (rem == 0) { > + synchronized (ZipFile.this) { > + if (jzentry == 0 || rem == 0) { > return -1; > } > if (len <= 0) { > @@ -709,9 +710,8 @@ > if (len > rem) { > len = (int) rem; > } > - synchronized (ZipFile.this) { > + > ensureOpenOrZipException(); > - > len = ZipFile.read(ZipFile.this.jzfile, jzentry, pos, b, > off, len); > } On 08/04/2014 19:52, Chris Hegarty wrote: >> My take is that the performance is not a concern here, the only real problem is the SEGV. >> >Given "num" is not a volatile and is not updated under synchronized block, check "num == 0" >> >is not going to make ZFIS work for mult-thread usage. It also makes me nervous to check it >> >inside the synchronized block as a global "flag". I'm also concerned that the change to check >> >the rem == 0 after the check of "len" may also change the behavior of someone's code in >> >certain circumstance? > To make this safe and simple, why not just move the close inside the synchronized block to ensure no concurrent access before close completes ( if needed ). There is very little computation overhead added to the synchronized block, but guarantees serial access to close. > > synchronized (ZipFile.this) { > ensureOpenOrZipException(); > > len = ZipFile.read(ZipFile.this.jzfile, jzentry, pos, b, > off, len); > if (len > 0) { > pos += len; > rem -= len; > } > if (rem == 0) { > close(); > } > } > > -Chris. > From peter.levart at gmail.com Wed Apr 9 06:08:08 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 09 Apr 2014 08:08:08 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> Message-ID: <5344E3C8.5080501@gmail.com> Hi Martin, As you might have seen in my later reply to Roger, there's still hope on that front: setpgid() + wait(-pgid, ...) might be the answer. I'm exploring in that direction. Shells are doing it, so why can't JDK? It's a little trickier for Process API, since I imagine that shells form a group of processes from a pipeline which is known in-advance while Process API will have to add processes to the live group dynamically. So some races will have to be resolved, but I think it's doable. Stay tuned. Regards, Peter On 04/08/2014 07:48 PM, Martin Buchholz wrote: > Peter, thank you very much for your deep analysis. > > TIL and am horrified: signals on Unix are not queued, not even if you > specify SA_SIGINFO. Providing siginfo turns signals into proper > "messages" each with unique content, and it is unacceptable to simply > drop some (Especially when proper queueing seems required for > so-called real-time signals), but at least the Linux kernel does so > very deliberately. 45 years later, we are still fighting with > unreliable Unix signals... > > We can't call waitpid(WAIT_ANY, ) because we can only wait for > processes owned by the j.l.Process subsystem. We can't override libc > functions like waitpid because the JVM may be a "guest" in some other > process. > > I don't know of any public examples, but it is reasonable to add a JVM > to a previously pure native code application, similarly to the way tcl > or lua is often used to provide a higher-level safer programming api > to native code, and some programs at Google use this strategy. > > What problem are we actually trying to solve? The army of reaper > threads is ugly, but the inefficiency is greatly mitigated by the use > of small explicit stack sizes. Redoing the process code is always > risky, as we have already seen in this thread. > > Maintaining a single child helper process which spawns all the > (grand)child processes seems reasonable, although it would create a > permanent intermediate entry in the process table (pstree?) which > might confuse some sysadmin scripts. Is it worth it? > From paul.sandoz at oracle.com Wed Apr 9 09:21:23 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 Apr 2014 11:21:23 +0200 Subject: UUID.compareTo broken? In-Reply-To: <59FFB1A3-1B99-4018-A7C4-AD8ED3A95C4A@oracle.com> References: <9473DBFE-49BF-4AC9-B290-9F7D56B09A24@oracle.com> <20A90CCF-FE95-4CAE-8596-BA717D71C133@oracle.com> <99E17723-83AB-43FC-BA63-E1700C8C8889@oracle.com> <59FFB1A3-1B99-4018-A7C4-AD8ED3A95C4A@oracle.com> Message-ID: <6E659508-7CC6-4906-AABB-59D511B4D728@oracle.com> On Apr 8, 2014, at 9:15 PM, Mike Duigou wrote: >> For the case of incorrect signed comparison is it sticking around because there is code dependent on the current broken behaviour? > > Probably even if the dependence is implicit such as expecting a particular iteration order > >> or do you think it would be possible to change that? > > I requested fixing the compareTo long ago (back when I was a mere user of the JDK) and was told that it could not be changed. Any more details on that? > >> i have my suspicious that code dependent compareTo may not break if the total ordering changes, since many cases are likely to be for randomly generated UUIDs. > > I agree that most code would probably be fine. I worry though that there will be cases that either explicitly or implicitly depend upon current ordering. Surprisingly there a lot of cases where UUIDs are created using the UUID(long, long) constructor with non-random data such as incrementing numbers: > > UUID myUUID = new UUID(SOME_CONSTANT, atomicSerial.incrementAndGet()); > That seems a terribly broken usage of UUID for 128 bit numbers or a pair of signed 64 bit numbers :-) Part of me thinks we should not be supporting such broken usage. Might be worth getting some usage data from grepcode or maven central. > This usage exists, I believe, because we haven't provided direct support for MAC version UUIDs. Unfortunately the UUID(long,long) constructor does not check that the UUID constructed is even valid and usually they are not. This usage, while egregious, is common. These people would probably be impacted by changes in ordering. > For correct usage the lsb long will for practical purposes always be -ve, since the msb is 1, as per the variant [1]. For time-based (MAC) UUIDs the comparison is totally broken as the time_low field bits will cycle often (~ every 3.5 mins by my calculation), so i doubt anyone would be using the comparator for such UUIDs to derive any meaningful order, for example, try this: UUID a = UUID.fromString("a938c470-bfc1-11e3-8a33-0800200c9a66"); UUID b = UUID.fromString("14857ca0-bfc2-11e3-8a33-0800200c9a66"); UUID c = UUID.fromString("d7a34910-bfc2-11e3-8a33-0800200c9a66"); System.out.println(a.timestamp() < b.timestamp()); System.out.println(b.timestamp() < c.timestamp()); System.out.println(a.timestamp() < c.timestamp()); System.out.println(a.compareTo(b)); System.out.println(b.compareTo(c)); System.out.println(a.compareTo(c)); >>> We could provide static methods to return appropriate comparators for version 1 and version 2 UUIDs--I've actually written them before for other projects. >>> >> >> It would be nice to just have one compareTo that does the right thing based of the UUID types being compared. > > If it were up to me only the time and DCE UUIDs would be comparable, there's no ordering relationship for other versions. I think it is fine for random UUIDs to be comparable with each other. > The comparators I've considered adding would only allow comparisons within the same version. > Yes, although for a general comparator the primary sort key could be the version value. >>> I also note that UUID does not currently support version 5, SHA-1, which it should. >>> >>> I am hoping to do other performance work on UUID within the scope of Java 9. Adding additional Comparators would fit right in with that. >>> >> >> OK, although it might be nice to bash this on the head sooner? as it might be possible to get into an 8u release depending on what we conclude about backwards compatibility. > > Any change to the ordering of the compareTo would have to happen in a major version if at all. I am very reluctant to change this behaviour when providing alternative comparators might just be a better choice. > Here is an alternative, deprecate UUID and create a new UUID class that is not broken. If we cannot fix the existing class lets just recognize it for what it is, a defective implementation for 128 bit numbers. Paul. [1] https://tools.ietf.org/html/rfc4122#section-4.1.1 From alexander.v.stepanov at oracle.com Wed Apr 9 09:45:18 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Wed, 09 Apr 2014 13:45:18 +0400 Subject: [9] Review Request for 8039488: tidy warnings cleanup for javax.sql In-Reply-To: <533555D1.2060900@oracle.com> References: <533555D1.2060900@oracle.com> Message-ID: <534516AE.3090709@oracle.com> Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8039488 Webrev corresponding: http://cr.openjdk.java.net/~yan/8039488/webrev.00/ Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. Thanks. Regards, Alexander From lance.andersen at oracle.com Wed Apr 9 10:10:44 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Wed, 9 Apr 2014 06:10:44 -0400 Subject: [9] Review Request for 8039488: tidy warnings cleanup for javax.sql In-Reply-To: <534516AE.3090709@oracle.com> References: <533555D1.2060900@oracle.com> <534516AE.3090709@oracle.com> Message-ID: I think this looks ok but a couple of suggestions src/share/classes/javax/sql/rowset/spi/package.html - The URL links at the bottom of the page need updated, please address them as part of this putback if possible src/share/classes/javax/sql/package.html - I would use ™ as part of the change on lines 40 and 42 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 Apr 9, 2014, at 5:45 AM, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8039488 > > Webrev corresponding: > http://cr.openjdk.java.net/~yan/8039488/webrev.00/ > > Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. > > Thanks. > > Regards, > Alexander From paul.sandoz at oracle.com Wed Apr 9 11:08:04 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 Apr 2014 13:08:04 +0200 Subject: Review of MH/LF patches in the review queue In-Reply-To: <53440D57.9000500@oracle.com> References: <0ACCC33E-798A-484C-938C-6CDD689345CD@oracle.com> <53440D57.9000500@oracle.com> Message-ID: On Apr 8, 2014, at 4:53 PM, Vladimir Ivanov wrote: > Paul, thanks for the feedback! > See my answers inline. > > Updated webrevs: > http://cr.openjdk.java.net/~vlivanov/8037209/webrev.03/ > http://cr.openjdk.java.net/~vlivanov/8038261/webrev.02/ > Both look OK. >> Is it worthwhile introducing such direct coupling for a specific case, as that tends to increase the inter-connective complexity of the code. How much performance gain is achieved? > Setters/getters for primitive arrays can be special-cased in the same manner, but these special cases don't buy much. Accessors (ArrayAccessor.getElement*/setElement*) are very simple anyway. I haven't seen any significant performance difference on octane. > > I'll experiment with that further. > OK. >> >> The last two re-assigments are never used and are reassigned again at the top of the loop: >> >> // Update cached form name's info in case an intrinsic spanning multiple names was encountered. >> name = lambdaForm.names[i]; >> member = name.function.member(); >> rtype = name.function.methodType().returnType(); > I did it intentionally. There were bugs when cached values become stale due to processing of multi-name intrinsics and they were erroneously used. There's a refactoring of how intrinsics are implemented waiting in the queue, so I'd like to leave it as is for now. > OK. Paul. From alexander.v.stepanov at oracle.com Wed Apr 9 11:58:53 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Wed, 09 Apr 2014 15:58:53 +0400 Subject: [9] Review Request for 8039488: tidy warnings cleanup for javax.sql In-Reply-To: References: <533555D1.2060900@oracle.com> <534516AE.3090709@oracle.com> Message-ID: <534535FD.3080505@oracle.com> Hello Lance, Thanks; please see the updated webrev: http://cr.openjdk.java.net/~yan/8039488/webrev.01/ Regards, Alexander On 09.04.2014 14:10, Lance @ Oracle wrote: > I think this looks ok but a couple of suggestions > > *src/share/classes/javax/sql/rowset/spi/package.html - *The URL links > at the bottom of the page need updated, please address them as part of > this putback if possible > * > * > *src/share/classes/javax/sql/package.html *- I would use ™ as > part of the change on lines 40 and 42 > > 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 Apr 9, 2014, at 5:45 AM, alexander stepanov > > wrote: > >> Hello, >> >> Could you please review the fix for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8039488 >> >> Webrev corresponding: >> http://cr.openjdk.java.net/~yan/8039488/webrev.00/ >> >> >> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >> affected. >> >> Thanks. >> >> Regards, >> Alexander From roger.riggs at oracle.com Wed Apr 9 13:20:22 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 09 Apr 2014 09:20:22 -0400 Subject: ProcessReaper: single thread reaper In-Reply-To: <5344E3C8.5080501@gmail.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.co! m> Message-ID: <53454916.5010104@oracle.com> Hi Peter, On a related topic, the request to be able to destroy a Process and all of its children might also want to used the group pid to be able to identify all of the children. Roger On 4/9/2014 2:08 AM, Peter Levart wrote: > Hi Martin, > > As you might have seen in my later reply to Roger, there's still hope > on that front: setpgid() + wait(-pgid, ...) might be the answer. I'm > exploring in that direction. Shells are doing it, so why can't JDK? > > It's a little trickier for Process API, since I imagine that shells > form a group of processes from a pipeline which is known in-advance > while Process API will have to add processes to the live group > dynamically. So some races will have to be resolved, but I think it's > doable. > > Stay tuned. > > Regards, Peter > > On 04/08/2014 07:48 PM, Martin Buchholz wrote: >> Peter, thank you very much for your deep analysis. >> >> TIL and am horrified: signals on Unix are not queued, not even if you >> specify SA_SIGINFO. Providing siginfo turns signals into proper >> "messages" each with unique content, and it is unacceptable to simply >> drop some (Especially when proper queueing seems required for >> so-called real-time signals), but at least the Linux kernel does so >> very deliberately. 45 years later, we are still fighting with >> unreliable Unix signals... >> >> We can't call waitpid(WAIT_ANY, ) because we can only wait for >> processes owned by the j.l.Process subsystem. We can't override libc >> functions like waitpid because the JVM may be a "guest" in some other >> process. >> >> I don't know of any public examples, but it is reasonable to add a >> JVM to a previously pure native code application, similarly to the >> way tcl or lua is often used to provide a higher-level safer >> programming api to native code, and some programs at Google use this >> strategy. >> >> What problem are we actually trying to solve? The army of reaper >> threads is ugly, but the inefficiency is greatly mitigated by the use >> of small explicit stack sizes. Redoing the process code is always >> risky, as we have already seen in this thread. >> >> Maintaining a single child helper process which spawns all the >> (grand)child processes seems reasonable, although it would create a >> permanent intermediate entry in the process table (pstree?) which >> might confuse some sysadmin scripts. Is it worth it? >> > From chris.hegarty at oracle.com Wed Apr 9 14:07:35 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Apr 2014 15:07:35 +0100 Subject: RFR [9] 8039527: Broken links in ConcurrentMap javadoc Message-ID: <53455427.8020201@oracle.com> java.util.concurrent.ConcurrentMap contains several broken links to Collection.html#optional-restrictions. See http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentMap.html The issue is caused by the use of '{@inheritDoc}' in many '@throws' definitions. ConcurrentMap's superType Map, is in the java.util package. Map has documentation references to Collection.html, which is in the same package as Map, java.util, but since ConcurrentMap is not in java.util it needs different relative links, or better still links relative to the docRoot. Trivial diffs inline: diff --git a/src/share/classes/java/util/Map.java b/src/share/classes/java/util/Map.java --- a/src/share/classes/java/util/Map.java +++ b/src/share/classes/java/util/Map.java @@ -157,10 +157,10 @@ * key * @throws ClassCastException if the key is of an inappropriate type for * this map - * (optional) + * (optional) * @throws NullPointerException if the specified key is null and this map * does not permit null keys - * (optional) + * (optional) */ boolean containsKey(Object key); @@ -177,10 +177,10 @@ * specified value * @throws ClassCastException if the value is of an inappropriate type for * this map - * (optional) + * (optional) * @throws NullPointerException if the specified value is null and this * map does not permit null values - * (optional) + * (optional) */ boolean containsValue(Object value); @@ -204,10 +204,10 @@ * {@code null} if this map contains no mapping for the key * @throws ClassCastException if the key is of an inappropriate type for * this map - * (optional) + * (optional) * @throws NullPointerException if the specified key is null and this map * does not permit null keys - * (optional) + * (optional) */ V get(Object key); @@ -264,10 +264,10 @@ * is not supported by this map * @throws ClassCastException if the key is of an inappropriate type for * this map - * (optional) + * (optional) * @throws NullPointerException if the specified key is null and this * map does not permit null keys - * (optional) + * (optional) */ V remove(Object key); @@ -577,10 +577,10 @@ * {@code defaultValue} if this map contains no mapping for the key * @throws ClassCastException if the key is of an inappropriate type for * this map - * (optional) + * (optional) * @throws NullPointerException if the specified key is null and this map * does not permit null keys - * (optional) + * (optional) * @since 1.8 */ default V getOrDefault(Object key, V defaultValue) { @@ -659,13 +659,13 @@ * values * @throws ClassCastException if a replacement value is of an inappropriate * type for this map - * (optional) + * (optional) * @throws NullPointerException if function or a replacement value is null, * and this map does not permit null keys or values - * (optional) + * (optional) * @throws IllegalArgumentException if some property of a replacement value * prevents it from being stored in this map - * (optional) + * (optional) * @throws ConcurrentModificationException if an entry is found to be * removed during iteration * @since 1.8 @@ -726,16 +726,16 @@ * if the implementation supports null values.) * @throws UnsupportedOperationException if the {@code put} operation * is not supported by this map - * (optional) + * (optional) * @throws ClassCastException if the key or value is of an inappropriate * type for this map - * (optional) + * (optional) * @throws NullPointerException if the specified key or value is null, * and this map does not permit null keys or values - * (optional) + * (optional) * @throws IllegalArgumentException if some property of the specified key * or value prevents it from being stored in this map - * (optional) + * (optional) * @since 1.8 */ default V putIfAbsent(K key, V value) { @@ -772,13 +772,13 @@ * @return {@code true} if the value was removed * @throws UnsupportedOperationException if the {@code remove} operation * is not supported by this map - * (optional) + * (optional) * @throws ClassCastException if the key or value is of an inappropriate * type for this map - * (optional) + * (optional) * @throws NullPointerException if the specified key or value is null, * and this map does not permit null keys or values - * (optional) + * (optional) * @since 1.8 */ default boolean remove(Object key, Object value) { @@ -821,14 +821,14 @@ * @return {@code true} if the value was replaced * @throws UnsupportedOperationException if the {@code put} operation * is not supported by this map - * (optional) + * (optional) * @throws ClassCastException if the class of a specified key or value * prevents it from being stored in this map * @throws NullPointerException if a specified key or newValue is null, * and this map does not permit null keys or values * @throws NullPointerException if oldValue is null and this map does not * permit null values - * (optional) + * (optional) * @throws IllegalArgumentException if some property of a specified key * or value prevents it from being stored in this map * @since 1.8 @@ -871,10 +871,10 @@ * if the implementation supports null values.) * @throws UnsupportedOperationException if the {@code put} operation * is not supported by this map - * (optional) + * (optional) * @throws ClassCastException if the class of the specified key or value * prevents it from being stored in this map - * (optional) + * (optional) * @throws NullPointerException if the specified key or value is null, * and this map does not permit null keys or values * @throws IllegalArgumentException if some property of the specified key @@ -942,10 +942,10 @@ * is null * @throws UnsupportedOperationException if the {@code put} operation * is not supported by this map - * (optional) + * (optional) * @throws ClassCastException if the class of the specified key or value * prevents it from being stored in this map - * (optional) + * (optional) * @since 1.8 */ default V computeIfAbsent(K key, @@ -1003,10 +1003,10 @@ * remappingFunction is null * @throws UnsupportedOperationException if the {@code put} operation * is not supported by this map - * (optional) + * (optional) * @throws ClassCastException if the class of the specified key or value * prevents it from being stored in this map - * (optional) + * (optional) * @since 1.8 */ default V computeIfPresent(K key, @@ -1079,10 +1079,10 @@ * remappingFunction is null * @throws UnsupportedOperationException if the {@code put} operation * is not supported by this map - * (optional) + * (optional) * @throws ClassCastException if the class of the specified key or value * prevents it from being stored in this map - * (optional) + * (optional) * @since 1.8 */ default V compute(K key, @@ -1157,10 +1157,10 @@ * value is associated with the key * @throws UnsupportedOperationException if the {@code put} operation * is not supported by this map - * (optional) + * (optional) * @throws ClassCastException if the class of the specified key or value * prevents it from being stored in this map - * (optional) + * (optional) * @throws NullPointerException if the specified key is null and this map * does not support null keys or the value or remappingFunction is * null -Chris. From lance.andersen at oracle.com Wed Apr 9 14:04:48 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 9 Apr 2014 10:04:48 -0400 Subject: [9] Review Request for 8039488: tidy warnings cleanup for javax.sql In-Reply-To: <534535FD.3080505@oracle.com> References: <533555D1.2060900@oracle.com> <534516AE.3090709@oracle.com> <534535FD.3080505@oracle.com> Message-ID: <2306D4C9-5B2E-4D15-913C-F363B8615E6E@oracle.com> Hi Alexander, looks fine. Best Lance On Apr 9, 2014, at 7:58 AM, alexander stepanov wrote: > Hello Lance, > > Thanks; please see the updated webrev: http://cr.openjdk.java.net/~yan/8039488/webrev.01/ > > Regards, > Alexander > > On 09.04.2014 14:10, Lance @ Oracle wrote: >> I think this looks ok but a couple of suggestions >> >> *src/share/classes/javax/sql/rowset/spi/package.html - *The URL links at the bottom of the page need updated, please address them as part of this putback if possible >> * >> * >> *src/share/classes/javax/sql/package.html *- I would use ™ as part of the change on lines 40 and 42 >> >> 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 Apr 9, 2014, at 5:45 AM, alexander stepanov > wrote: >> >>> Hello, >>> >>> Could you please review the fix for the following bug: >>> https://bugs.openjdk.java.net/browse/JDK-8039488 >>> >>> Webrev corresponding: >>> http://cr.openjdk.java.net/~yan/8039488/webrev.00/ >>> >>> Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. >>> >>> Thanks. >>> >>> Regards, >>> Alexander > 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 martinrb at google.com Wed Apr 9 14:08:59 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 9 Apr 2014 07:08:59 -0700 Subject: RFR [9] 8039527: Broken links in ConcurrentMap javadoc In-Reply-To: <53455427.8020201@oracle.com> References: <53455427.8020201@oracle.com> Message-ID: Looks Good To Me! On Wed, Apr 9, 2014 at 7:07 AM, Chris Hegarty wrote: > java.util.concurrent.ConcurrentMap contains several broken links to > Collection.html#optional-restrictions. See > > http://docs.oracle.com/javase/8/docs/api/java/util/ > concurrent/ConcurrentMap.html > > The issue is caused by the use of '{@inheritDoc}' in many '@throws' > definitions. ConcurrentMap's superType Map, is in the java.util package. > Map has documentation references to Collection.html, which is in the same > package as Map, java.util, but since ConcurrentMap is not in java.util it > needs different relative links, or better still links relative to the > docRoot. > > Trivial diffs inline: > > diff --git a/src/share/classes/java/util/Map.java > b/src/share/classes/java/util/Map.java > --- a/src/share/classes/java/util/Map.java > +++ b/src/share/classes/java/util/Map.java > @@ -157,10 +157,10 @@ > * key > * @throws ClassCastException if the key is of an inappropriate type > for > * this map > - * (optional) > + * (optional) > * @throws NullPointerException if the specified key is null and this > map > * does not permit null keys > - * (optional) > + * (optional) > */ > boolean containsKey(Object key); > > @@ -177,10 +177,10 @@ > * specified value > * @throws ClassCastException if the value is of an inappropriate > type for > * this map > - * (optional) > + * (optional) > * @throws NullPointerException if the specified value is null and > this > * map does not permit null values > - * (optional) > + * (optional) > */ > boolean containsValue(Object value); > > @@ -204,10 +204,10 @@ > * {@code null} if this map contains no mapping for the key > * @throws ClassCastException if the key is of an inappropriate type > for > * this map > - * (optional) > + * (optional) > * @throws NullPointerException if the specified key is null and this > map > * does not permit null keys > - * (optional) > + * (optional) > */ > V get(Object key); > > @@ -264,10 +264,10 @@ > * is not supported by this map > * @throws ClassCastException if the key is of an inappropriate type > for > * this map > - * (optional) > + * (optional) > * @throws NullPointerException if the specified key is null and this > * map does not permit null keys > - * (optional) > + * (optional) > */ > V remove(Object key); > > @@ -577,10 +577,10 @@ > * {@code defaultValue} if this map contains no mapping for the key > * @throws ClassCastException if the key is of an inappropriate type > for > * this map > - * (optional) > + * (optional) > * @throws NullPointerException if the specified key is null and this > map > * does not permit null keys > - * (optional) > + * (optional) > * @since 1.8 > */ > default V getOrDefault(Object key, V defaultValue) { > @@ -659,13 +659,13 @@ > * values > * @throws ClassCastException if a replacement value is of an > inappropriate > * type for this map > - * ( > optional) > + * (optional) > * @throws NullPointerException if function or a replacement value is > null, > * and this map does not permit null keys or values > - * ( > optional) > + * (optional) > * @throws IllegalArgumentException if some property of a replacement > value > * prevents it from being stored in this map > - * ( > optional) > + * (optional) > * @throws ConcurrentModificationException if an entry is found to be > * removed during iteration > * @since 1.8 > @@ -726,16 +726,16 @@ > * if the implementation supports null values.) > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( > optional) > + * (optional) > * @throws ClassCastException if the key or value is of an > inappropriate > * type for this map > - * ( > optional) > + * (optional) > * @throws NullPointerException if the specified key or value is null, > * and this map does not permit null keys or values > - * ( > optional) > + * (optional) > * @throws IllegalArgumentException if some property of the specified > key > * or value prevents it from being stored in this map > - * ( > optional) > + * (optional) > * @since 1.8 > */ > default V putIfAbsent(K key, V value) { > @@ -772,13 +772,13 @@ > * @return {@code true} if the value was removed > * @throws UnsupportedOperationException if the {@code remove} > operation > * is not supported by this map > - * ( > optional) > + * (optional) > * @throws ClassCastException if the key or value is of an > inappropriate > * type for this map > - * ( > optional) > + * (optional) > * @throws NullPointerException if the specified key or value is null, > * and this map does not permit null keys or values > - * ( > optional) > + * (optional) > * @since 1.8 > */ > default boolean remove(Object key, Object value) { > @@ -821,14 +821,14 @@ > * @return {@code true} if the value was replaced > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( > optional) > + * (optional) > * @throws ClassCastException if the class of a specified key or value > * prevents it from being stored in this map > * @throws NullPointerException if a specified key or newValue is > null, > * and this map does not permit null keys or values > * @throws NullPointerException if oldValue is null and this map does > not > * permit null values > - * ( > optional) > + * (optional) > * @throws IllegalArgumentException if some property of a specified > key > * or value prevents it from being stored in this map > * @since 1.8 > @@ -871,10 +871,10 @@ > * if the implementation supports null values.) > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( > optional) > + * (optional) > * @throws ClassCastException if the class of the specified key or > value > * prevents it from being stored in this map > - * ( > optional) > + * (optional) > * @throws NullPointerException if the specified key or value is null, > * and this map does not permit null keys or values > * @throws IllegalArgumentException if some property of the specified > key > @@ -942,10 +942,10 @@ > * is null > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( > optional) > + * (optional) > * @throws ClassCastException if the class of the specified key or > value > * prevents it from being stored in this map > - * ( > optional) > + * (optional) > * @since 1.8 > */ > default V computeIfAbsent(K key, > @@ -1003,10 +1003,10 @@ > * remappingFunction is null > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( > optional) > + * (optional) > * @throws ClassCastException if the class of the specified key or > value > * prevents it from being stored in this map > - * ( > optional) > + * (optional) > * @since 1.8 > */ > default V computeIfPresent(K key, > @@ -1079,10 +1079,10 @@ > * remappingFunction is null > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( > optional) > + * (optional) > * @throws ClassCastException if the class of the specified key or > value > * prevents it from being stored in this map > - * ( > optional) > + * (optional) > * @since 1.8 > */ > default V compute(K key, > @@ -1157,10 +1157,10 @@ > * value is associated with the key > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( > optional) > + * (optional) > * @throws ClassCastException if the class of the specified key or > value > * prevents it from being stored in this map > - * ( > optional) > + * (optional) > * @throws NullPointerException if the specified key is null and this > map > * does not support null keys or the value or > remappingFunction is > * null > > -Chris. > From alexandre.iline at oracle.com Wed Apr 9 16:00:20 2014 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 09 Apr 2014 20:00:20 +0400 Subject: RFR: 8039438: Some tests depend on internal API sun.misc.IOUtils Message-ID: <53456E94.1020409@oracle.com> Hi. I'd like to ask for review of this fix: http://cr.openjdk.java.net/~shurailine/8039438/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8039438 Thank you. Shura From martinrb at google.com Wed Apr 9 17:02:47 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 9 Apr 2014 10:02:47 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: <5344E3C8.5080501@gmail.com> References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> Message-ID: On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart wrote: > Hi Martin, > > As you might have seen in my later reply to Roger, there's still hope on > that front: setpgid() + wait(-pgid, ...) might be the answer. I'm exploring > in that direction. Shells are doing it, so why can't JDK? > > It's a little trickier for Process API, since I imagine that shells form a > group of processes from a pipeline which is known in-advance while Process > API will have to add processes to the live group dynamically. So some races > will have to be resolved, but I think it's doable. > This is a clever idea, and it's arguably better to design subprocesses so they live in separate process groups (emacs does that), but: Every time you create a process group, you change the effect of a user signal like Ctrl-C, since it's sent to only one group. Maybe propagate signals to the subprocess group? It's starting to get complicated... From martinrb at google.com Wed Apr 9 17:05:30 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 9 Apr 2014 10:05:30 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <532CA33D.3030502@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> Message-ID: Here's a practical (but untested) simple improvement: don't set SIGCHLD unless it's already set to SIG_IGN. Please take ownership. --- a/src/solaris/native/java/lang/UNIXProcess_md.c +++ b/src/solaris/native/java/lang/UNIXProcess_md.c @@ -108,7 +108,8 @@ /* There is a subtle difference between having the signal handler * for SIGCHLD be SIG_DFL and SIG_IGN. We cannot obtain process * termination information for child processes if the signal - * handler is SIG_IGN. It must be SIG_DFL. + * handler is SIG_IGN. Any other value, notably SIG_DFL, is fine. + * If there's already a signal handler for SIGCHLD, let it be. * * We used to set the SIGCHLD handler only on Linux, but it's * safest to set it unconditionally. @@ -124,11 +125,15 @@ * http://www.pasc.org/interps/unofficial/db/p1003.1/pasc-1003.1-132.html */ struct sigaction sa; - sa.sa_handler = SIG_DFL; - sigemptyset(&sa.sa_mask); - sa.sa_flags = SA_NOCLDSTOP | SA_RESTART; - if (sigaction(SIGCHLD, &sa, NULL) < 0) - JNU_ThrowInternalError(env, "Can't set SIGCHLD handler"); + if (sigaction(SIGCHLD, NULL, &sa) < 0) { + JNU_ThrowInternalError(env, "Can't get SIGCHLD handler"); + } else if (sa.sa_handler == SIG_IGN) { + sa.sa_handler = SIG_DFL; + sigemptyset(&sa.sa_mask); + sa.sa_flags = SA_RESTART; + if (sigaction(SIGCHLD, &sa, NULL) < 0) + JNU_ThrowInternalError(env, "Can't set SIGCHLD handler"); + } } static void* On Wed, Apr 9, 2014 at 10:02 AM, Martin Buchholz wrote: > > > > On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart wrote: > >> Hi Martin, >> >> As you might have seen in my later reply to Roger, there's still hope on >> that front: setpgid() + wait(-pgid, ...) might be the answer. I'm exploring >> in that direction. Shells are doing it, so why can't JDK? >> >> It's a little trickier for Process API, since I imagine that shells form >> a group of processes from a pipeline which is known in-advance while >> Process API will have to add processes to the live group dynamically. So >> some races will have to be resolved, but I think it's doable. >> > > This is a clever idea, and it's arguably better to design subprocesses so > they live in separate process groups (emacs does that), but: > Every time you create a process group, you change the effect of a user > signal like Ctrl-C, since it's sent to only one group. > Maybe propagate signals to the subprocess group? It's starting to get > complicated... > > From mandy.chung at oracle.com Wed Apr 9 17:22:53 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Apr 2014 10:22:53 -0700 Subject: RFR: 8039438: Some tests depend on internal API sun.misc.IOUtils In-Reply-To: <53456E94.1020409@oracle.com> References: <53456E94.1020409@oracle.com> Message-ID: <534581ED.4060604@oracle.com> Hi Shura, On 4/9/2014 9:00 AM, Alexandre (Shura) Iline wrote: > Hi. > > I'd like to ask for review of this fix: > http://cr.openjdk.java.net/~shurailine/8039438/webrev.00/ > It's good to see this dependency be removed from the tests. Looks reasonable. I'll sponsor this change. Mandy From sean.coffey at oracle.com Wed Apr 9 17:39:03 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Wed, 09 Apr 2014 18:39:03 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <53445BF9.6010902@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> <53445BF9.6010902@oracle.com> Message-ID: <534585B7.40409@oracle.com> On re-read, I believe extending the sync block in read(..) to cover the reading and setting of the rem variable works to resolve this fix. It should preserve behaviour as well. http://cr.openjdk.java.net/~coffeys/webrev.8038491.v2/webrev/ regards, Sean. On 08/04/14 21:28, Se?n Coffey wrote: > Chris, > > ZipFileInputStream.skip(..) can also close out the stream and free up > the underlying jzentry resources. > > Per Sherman's suggestion I substituted rem for jzentry == 0 check but > ran into issues with other tests [1] > Another simple change (and to preserve old behaviour) might be just to > extend the synchronized block to start at top of the read method and > to check for both (rem == 0 || jzentry == 0) [2] > > tests running. > > regards, > Sean. > > [1] > >> java.util.zip.ZipException: ZIP_Read: specified offset out of range >> at java.util.zip.ZipFile.read(Native Method) >> at java.util.zip.ZipFile.access$1400(ZipFile.java:61) >> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:715) >> at java.io.InputStream.read(InputStream.java:101) >> at >> com.sun.java.util.jar.pack.Package$File.readFrom(Package.java:849) >> at >> com.sun.java.util.jar.pack.PackerImpl$DoPack.readFile(PackerImpl.java:517) >> at >> com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:466) >> at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:97) >> at sun.tools.jar.Main.run(Main.java:228) >> at sun.tools.jar.Main.main(Main.java:1233) >> Exception in thread "main" java.util.zip.ZipException: ZIP_Read: >> specified offset out of range >> at java.util.zip.ZipFile.read(Native Method) >> at java.util.zip.ZipFile.access$1400(ZipFile.java:61) >> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:715) >> at java.io.InputStream.read(InputStream.java:101) >> at >> com.sun.java.util.jar.pack.Package$File.readFrom(Package.java:849) >> at >> com.sun.java.util.jar.pack.PackerImpl$DoPack.readFile(PackerImpl.java:517) >> at >> com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:466) >> at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:97) >> at com.sun.java.util.jar.pack.Driver.main(Driver.java:313) >> java.util.zip.ZipException: zip file is empty >> at java.util.zip.ZipFile.open(Native Method) >> at java.util.zip.ZipFile.(ZipFile.java:220) >> at java.util.zip.ZipFile.(ZipFile.java:150) >> at java.util.jar.JarFile.(JarFile.java:166) >> at java.util.jar.JarFile.(JarFile.java:103) >> at TestNormal.main(TestNormal.java:59) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:484) >> at >> com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) >> at java.lang.Thread.run(Thread.java:744) > > [2] >> diff --git a/src/share/classes/java/util/zip/ZipFile.java >> b/src/share/classes/java/util/zip/ZipFile.java >> --- a/src/share/classes/java/util/zip/ZipFile.java >> +++ b/src/share/classes/java/util/zip/ZipFile.java >> @@ -700,7 +700,8 @@ >> } >> >> public int read(byte b[], int off, int len) throws >> IOException { >> - if (rem == 0) { >> + synchronized (ZipFile.this) { >> + if (jzentry == 0 || rem == 0) { >> return -1; >> } >> if (len <= 0) { >> @@ -709,9 +710,8 @@ >> if (len > rem) { >> len = (int) rem; >> } >> - synchronized (ZipFile.this) { >> + >> ensureOpenOrZipException(); >> - >> len = ZipFile.read(ZipFile.this.jzfile, jzentry, >> pos, b, >> off, len); >> } > > > On 08/04/2014 19:52, Chris Hegarty wrote: >>> My take is that the performance is not a concern here, the only real >>> problem is the SEGV. >>> >Given "num" is not a volatile and is not updated under synchronized >>> block, check "num == 0" >>> >is not going to make ZFIS work for mult-thread usage. It also makes >>> me nervous to check it >>> >inside the synchronized block as a global "flag". I'm also >>> concerned that the change to check >>> >the rem == 0 after the check of "len" may also change the behavior >>> of someone's code in >>> >certain circumstance? >> To make this safe and simple, why not just move the close inside the >> synchronized block to ensure no concurrent access before close >> completes ( if needed ). There is very little computation overhead >> added to the synchronized block, but guarantees serial access to close. >> >> synchronized (ZipFile.this) { >> ensureOpenOrZipException(); >> len = ZipFile.read(ZipFile.this.jzfile, jzentry, >> pos, b, >> off, len); >> if (len > 0) { >> pos += len; >> rem -= len; >> } >> if (rem == 0) { >> close(); >> } >> } >> >> -Chris. >> > From chris.hegarty at oracle.com Wed Apr 9 17:49:28 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Apr 2014 18:49:28 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <534585B7.40409@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> <53445BF9.6010902@oracle.com> <534585B7.40409@oracle.com> Message-ID: <53458828.5090005@oracle.com> Approved. Looks good to me. -Chris On 09/04/14 18:39, Se?n Coffey wrote: > On re-read, I believe extending the sync block in read(..) to cover the > reading and setting of the rem variable works to resolve this fix. It > should preserve behaviour as well. > > http://cr.openjdk.java.net/~coffeys/webrev.8038491.v2/webrev/ > > regards, > Sean. > > On 08/04/14 21:28, Se?n Coffey wrote: >> Chris, >> >> ZipFileInputStream.skip(..) can also close out the stream and free up >> the underlying jzentry resources. >> >> Per Sherman's suggestion I substituted rem for jzentry == 0 check but >> ran into issues with other tests [1] >> Another simple change (and to preserve old behaviour) might be just to >> extend the synchronized block to start at top of the read method and >> to check for both (rem == 0 || jzentry == 0) [2] >> >> tests running. >> >> regards, >> Sean. >> >> [1] >> >>> java.util.zip.ZipException: ZIP_Read: specified offset out of range >>> at java.util.zip.ZipFile.read(Native Method) >>> at java.util.zip.ZipFile.access$1400(ZipFile.java:61) >>> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:715) >>> at java.io.InputStream.read(InputStream.java:101) >>> at >>> com.sun.java.util.jar.pack.Package$File.readFrom(Package.java:849) >>> at >>> com.sun.java.util.jar.pack.PackerImpl$DoPack.readFile(PackerImpl.java:517) >>> >>> at >>> com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:466) >>> at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:97) >>> at sun.tools.jar.Main.run(Main.java:228) >>> at sun.tools.jar.Main.main(Main.java:1233) >>> Exception in thread "main" java.util.zip.ZipException: ZIP_Read: >>> specified offset out of range >>> at java.util.zip.ZipFile.read(Native Method) >>> at java.util.zip.ZipFile.access$1400(ZipFile.java:61) >>> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:715) >>> at java.io.InputStream.read(InputStream.java:101) >>> at >>> com.sun.java.util.jar.pack.Package$File.readFrom(Package.java:849) >>> at >>> com.sun.java.util.jar.pack.PackerImpl$DoPack.readFile(PackerImpl.java:517) >>> >>> at >>> com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:466) >>> at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:97) >>> at com.sun.java.util.jar.pack.Driver.main(Driver.java:313) >>> java.util.zip.ZipException: zip file is empty >>> at java.util.zip.ZipFile.open(Native Method) >>> at java.util.zip.ZipFile.(ZipFile.java:220) >>> at java.util.zip.ZipFile.(ZipFile.java:150) >>> at java.util.jar.JarFile.(JarFile.java:166) >>> at java.util.jar.JarFile.(JarFile.java:103) >>> at TestNormal.main(TestNormal.java:59) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> at java.lang.reflect.Method.invoke(Method.java:484) >>> at >>> com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) >>> >>> at java.lang.Thread.run(Thread.java:744) >> >> [2] >>> diff --git a/src/share/classes/java/util/zip/ZipFile.java >>> b/src/share/classes/java/util/zip/ZipFile.java >>> --- a/src/share/classes/java/util/zip/ZipFile.java >>> +++ b/src/share/classes/java/util/zip/ZipFile.java >>> @@ -700,7 +700,8 @@ >>> } >>> >>> public int read(byte b[], int off, int len) throws >>> IOException { >>> - if (rem == 0) { >>> + synchronized (ZipFile.this) { >>> + if (jzentry == 0 || rem == 0) { >>> return -1; >>> } >>> if (len <= 0) { >>> @@ -709,9 +710,8 @@ >>> if (len > rem) { >>> len = (int) rem; >>> } >>> - synchronized (ZipFile.this) { >>> + >>> ensureOpenOrZipException(); >>> - >>> len = ZipFile.read(ZipFile.this.jzfile, jzentry, >>> pos, b, >>> off, len); >>> } >> >> >> On 08/04/2014 19:52, Chris Hegarty wrote: >>>> My take is that the performance is not a concern here, the only real >>>> problem is the SEGV. >>>> >Given "num" is not a volatile and is not updated under synchronized >>>> block, check "num == 0" >>>> >is not going to make ZFIS work for mult-thread usage. It also makes >>>> me nervous to check it >>>> >inside the synchronized block as a global "flag". I'm also >>>> concerned that the change to check >>>> >the rem == 0 after the check of "len" may also change the behavior >>>> of someone's code in >>>> >certain circumstance? >>> To make this safe and simple, why not just move the close inside the >>> synchronized block to ensure no concurrent access before close >>> completes ( if needed ). There is very little computation overhead >>> added to the synchronized block, but guarantees serial access to close. >>> >>> synchronized (ZipFile.this) { >>> ensureOpenOrZipException(); >>> len = ZipFile.read(ZipFile.this.jzfile, jzentry, >>> pos, b, >>> off, len); >>> if (len > 0) { >>> pos += len; >>> rem -= len; >>> } >>> if (rem == 0) { >>> close(); >>> } >>> } >>> >>> -Chris. >>> >> > From chris.hegarty at oracle.com Wed Apr 9 18:01:33 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Apr 2014 19:01:33 +0100 Subject: RFR: 8039438: Some tests depend on internal API sun.misc.IOUtils In-Reply-To: <534581ED.4060604@oracle.com> References: <53456E94.1020409@oracle.com> <534581ED.4060604@oracle.com> Message-ID: <53458AFD.9050208@oracle.com> On 09/04/14 18:22, Mandy Chung wrote: > Hi Shura, > > On 4/9/2014 9:00 AM, Alexandre (Shura) Iline wrote: >> Hi. >> >> I'd like to ask for review of this fix: >> http://cr.openjdk.java.net/~shurailine/8039438/webrev.00/ >> > > It's good to see this dependency be removed from the tests. +1. -Chris. > Looks > reasonable. I'll sponsor this change. > > Mandy From Alan.Bateman at oracle.com Wed Apr 9 18:36:15 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Apr 2014 19:36:15 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <534585B7.40409@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> <53445BF9.6010902@oracle.com> <534585B7.40409@oracle.com> Message-ID: <5345931F.6010502@oracle.com> On 09/04/2014 18:39, Se?n Coffey wrote: > On re-read, I believe extending the sync block in read(..) to cover > the reading and setting of the rem variable works to resolve this fix. > It should preserve behaviour as well. > > http://cr.openjdk.java.net/~coffeys/webrev.8038491.v2/webrev/ This is probably okay for a test case that attempts concurrent reads but as it's not synchronized with skip then I don't think you can trust the value of rem or pos without taking copies and validating. -Alan. From Alan.Bateman at oracle.com Wed Apr 9 18:42:16 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Apr 2014 19:42:16 +0100 Subject: RFR: 8039438: Some tests depend on internal API sun.misc.IOUtils In-Reply-To: <53456E94.1020409@oracle.com> References: <53456E94.1020409@oracle.com> Message-ID: <53459488.4000606@oracle.com> On 09/04/2014 17:00, Alexandre (Shura) Iline wrote: > Hi. > > I'd like to ask for review of this fix: > http://cr.openjdk.java.net/~shurailine/8039438/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8039438 Looks okay to me. For the class description then maybe something like "Defines useful I/O methods" might be a bit better than "Holds useful io shortcuts" but it's a minor point. I guess I would probably make it final and/or a private constructor to make it obvious that it just defines static methods. A minor comment on LambdaClassLoaderSerialization.java is that would be good to indeed the tags so that they are consistent with other tests (pre-dates your change but more noticable now). -Alan From Alan.Bateman at oracle.com Wed Apr 9 18:43:46 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Apr 2014 19:43:46 +0100 Subject: RFR [9] 8039527: Broken links in ConcurrentMap javadoc In-Reply-To: <53455427.8020201@oracle.com> References: <53455427.8020201@oracle.com> Message-ID: <534594E2.9000402@oracle.com> On 09/04/2014 15:07, Chris Hegarty wrote: > java.util.concurrent.ConcurrentMap contains several broken links to > Collection.html#optional-restrictions. See > > http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentMap.html > > > The issue is caused by the use of '{@inheritDoc}' in many '@throws' > definitions. ConcurrentMap's superType Map, is in the java.util > package. Map has documentation references to Collection.html, which is > in the same package as Map, java.util, but since ConcurrentMap is not > in java.util it needs different relative links, or better still links > relative to the docRoot. > Looks good to me too. -Alan From sean.coffey at oracle.com Wed Apr 9 19:10:46 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Wed, 09 Apr 2014 20:10:46 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <5345931F.6010502@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> <53445BF9.6010902@oracle.com> <534585B7.40409@oracle.com> <5345931F.6010502@oracle.com> Message-ID: <53459B36.5090602@oracle.com> On 09/04/14 19:36, Alan Bateman wrote: > On 09/04/2014 18:39, Se?n Coffey wrote: >> On re-read, I believe extending the sync block in read(..) to cover >> the reading and setting of the rem variable works to resolve this >> fix. It should preserve behaviour as well. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8038491.v2/webrev/ > This is probably okay for a test case that attempts concurrent reads > but as it's not synchronized with skip then I don't think you can > trust the value of rem or pos without taking copies and validating. I played around with adding some skip testing Alan but didn't see it increase the rate of failure on an unpatched binary. Since ZipFileInputStream.read(..) is the trouble method and now has better synchronized access to reading and updating rem, I believe we're good. skip(long) can trigger a close() but close() can't free up the resources without the ZipFile.this lock. As mentioned, having multiples threads reading from the one zip stream would make no sense anyhow. Let me know if I need to make changes. I don't think we want to add extra sync costs to the class. regards, Sean. > > -Alan. From chris.hegarty at oracle.com Wed Apr 9 20:56:05 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 9 Apr 2014 21:56:05 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <53459B36.5090602@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> <53445BF9.6010902@oracle.com> <534585B7.40409@oracle.com> <5345931F.6010502@oracle.com> <53459B36.5090602@oracle.com> Message-ID: > On 9 Apr 2014, at 20:10, Se?n Coffey wrote: >> On 09/04/14 19:36, Alan Bateman wrote: >>> On 09/04/2014 18:39, Se?n Coffey wrote: >>> On re-read, I believe extending the sync block in read(..) to cover the reading and setting of the rem variable works to resolve this fix. It should preserve behaviour as well. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8038491.v2/webrev/ >> This is probably okay for a test case that attempts concurrent reads but as it's not synchronized with skip then I don't think you can trust the value of rem or pos without taking copies and validating. > I played around with adding some skip testing Alan but didn't see it increase the rate of failure on an unpatched binary. Since ZipFileInputStream.read(..) is the trouble method and now has better synchronized access to reading and updating rem, I believe we're good. skip(long) can trigger a close() but close() can't free up the resources without the ZipFile.this lock. As mentioned, having multiples threads reading from the one zip stream would make no sense anyhow. Right. This is still NOT thread-safe, but just enough to "support" async close and prevent the potential of a crash. Maybe a comment would help, or maybe not. -Chris. > Let me know if I need to make changes. I don't think we want to add extra sync costs to the class. > > regards, > Sean. > >> >> -Alan. > From Alan.Bateman at oracle.com Wed Apr 9 21:16:09 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Apr 2014 22:16:09 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <53459B36.5090602@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> <53445BF9.6010902@oracle.com> <534585B7.40409@oracle.com> <5345931F.6010502@oracle.com> <53459B36.5090602@oracle.com> Message-ID: <5345B899.2020407@oracle.com> On 09/04/2014 20:10, Se?n Coffey wrote: > > I played around with adding some skip testing Alan but didn't see it > increase the rate of failure on an unpatched binary. Since > ZipFileInputStream.read(..) is the trouble method and now has better > synchronized access to reading and updating rem, I believe we're good. > skip(long) can trigger a close() but close() can't free up the > resources without the ZipFile.this lock. As mentioned, having > multiples threads reading from the one zip stream would make no sense > anyhow. > > Let me know if I need to make changes. I don't think we want to add > extra sync costs to the class. If you are only going to synchronize read then you will need to take a copy of rem and pos, otherwise you have to assume that the check and limiting of len isn't reliable, same thing for pos which could be way out of range due to concurrent usages of skip. -Alan. From xueming.shen at oracle.com Wed Apr 9 21:51:53 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 09 Apr 2014 14:51:53 -0700 Subject: RFR: JDK-8039751: UTF-8 decoder fails to handle some edge cases correctly Message-ID: <5345C0F9.8020601@oracle.com> Hi, Please help review the fix for JDK-8039751. Issue: https://bugs.openjdk.java.net/browse/JDK-8039751 webrev: http://cr.openjdk.java.net/~sherman/8039751/webrev/ This is the corner case (in 4 bytes sequence) we missed when fixing 7096080 [1]. The UTF_8 decoder correctly returns the malformed length for some malformed 4-byte illegal byte sequence (via Decoder.malformedN(...)), but it fails to do so if there is no enough (< 4 bytes) bytes in input buffer (via isMalfromed4_2(...)) The proposed change fixes these corner cases. Hey Mark, my reading of tomcat's test case suggests "malformed 4-byte sequence" is the only thing left after the jdk8 fix, right? Thanks! -Sherman [1] https://bugs.openjdk.java.net/browse/JDK-7096080 From sean.coffey at oracle.com Wed Apr 9 21:52:53 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Wed, 09 Apr 2014 22:52:53 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <5345B899.2020407@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> <53445BF9.6010902@oracle.com> <534585B7.40409@oracle.com> <5345931F.6010502@oracle.com> <53459B36.5090602@oracle.com> <5345B899.2020407@oracle.com> Message-ID: <5345C135.9040405@oracle.com> On 09/04/14 22:16, Alan Bateman wrote: > On 09/04/2014 20:10, Se?n Coffey wrote: >> >> I played around with adding some skip testing Alan but didn't see it >> increase the rate of failure on an unpatched binary. Since >> ZipFileInputStream.read(..) is the trouble method and now has better >> synchronized access to reading and updating rem, I believe we're >> good. skip(long) can trigger a close() but close() can't free up the >> resources without the ZipFile.this lock. As mentioned, having >> multiples threads reading from the one zip stream would make no sense >> anyhow. >> >> Let me know if I need to make changes. I don't think we want to add >> extra sync costs to the class. > If you are only going to synchronize read then you will need to take a > copy of rem and pos, otherwise you have to assume that the check and > limiting of len isn't reliable, same thing for pos which could be way > out of range due to concurrent usages of skip. Let me catch up with you in the morning on this Alan. In the interest of keeping the code optimal, I think we can skip these checks. The native ZIP_Read function runs a range check on the len and pos values passed in. regards, Sean. > > -Alan. From brian.burkhalter at oracle.com Thu Apr 10 01:19:06 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Apr 2014 18:19:06 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) Message-ID: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> Hello, Issue: https://bugs.openjdk.java.net/browse/JDK-8039474 Patch: http://cr.openjdk.java.net/~bpb/8039474/webrev.00/ The change is to specify the charset for the String where none had been before. The extant test sun/misc/Encode/GetBytes.java appears to suffice for this. Thanks, Brian From joe.darcy at oracle.com Thu Apr 10 05:02:35 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Apr 2014 22:02:35 -0700 Subject: JDK 9 RFR of JDK-8039864: Fix fallthrough lint warnings in other libs Message-ID: <534625EB.5030005@oracle.com> Hello, I've started looking at cleaning up the fallthrough lint warnings in the jdk repo. Please review the affected files in the "other libs" area: JDK-8039864: Fix fallthrough lint warnings in other libs http://cr.openjdk.java.net/~darcy/8039864.0/ Thanks, -Joe --- old/src/share/classes/sun/tools/java/Environment.java 2014-04-09 21:57:38.000000000 -0700 +++ new/src/share/classes/sun/tools/java/Environment.java 2014-04-09 21:57:38.000000000 -0700 @@ -648,6 +648,7 @@ * Return true if an implicit cast from this type to * the given type is allowed. */ + @SuppressWarnings("fallthrough") public boolean implicitCast(Type from, Type to) throws ClassNotFound { if (from == to) return true; --- old/src/share/classes/sun/tools/java/Scanner.java 2014-04-09 21:57:39.000000000 -0700 +++ new/src/share/classes/sun/tools/java/Scanner.java 2014-04-09 21:57:39.000000000 -0700 @@ -511,6 +511,7 @@ * Scan a number. The first digit of the number should be the current * character. We may be scanning hex, decimal, or octal at this point */ + @SuppressWarnings("fallthrough") private void scanNumber() throws IOException { boolean seenNonOctal = false; boolean overflow = false; @@ -532,6 +533,7 @@ // We can't yet throw an error if reading an octal. We might // discover we're really reading a real. seenNonOctal = true; + // Fall through case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': seenDigit = true; @@ -668,6 +670,7 @@ * Scan a float. Should be called with the current character is either * the 'e', 'E' or '.' */ + @SuppressWarnings("fallthrough") private void scanReal() throws IOException { boolean seenExponent = false; boolean isSingleFloat = false; @@ -984,6 +987,7 @@ return xscan(); } + @SuppressWarnings("fallthrough") protected long xscan() throws IOException { final ScannerInputReader in = this.in; long retPos = pos; @@ -1006,6 +1010,7 @@ token = COMMENT; return retPos; } + // Fall through case ' ': case '\t': case '\f': --- old/src/share/classes/sun/tools/javac/Main.java 2014-04-09 21:57:40.000000000 -0700 +++ new/src/share/classes/sun/tools/javac/Main.java 2014-04-09 21:57:39.000000000 -0700 @@ -192,6 +192,7 @@ /** * Run the compiler */ + @SuppressWarnings("fallthrough") public synchronized boolean compile(String argv[]) { String sourcePathArg = null; String classPathArg = null; --- old/src/share/classes/sun/tools/jinfo/JInfo.java 2014-04-09 21:57:40.000000000 -0700 +++ new/src/share/classes/sun/tools/jinfo/JInfo.java 2014-04-09 21:57:40.000000000 -0700 @@ -41,6 +41,7 @@ */ public class JInfo { + @SuppressWarnings("fallthrough") public static void main(String[] args) throws Exception { if (args.length == 0) { usage(1); // no arguments @@ -118,6 +119,7 @@ case "-help": case "-h": usage(0); + // Fall through default: if (args.length == 1) { // no flags specified, we do -sysprops and -flags --- old/src/share/classes/sun/tools/tree/AssignOpExpression.java 2014-04-09 21:57:41.000000000 -0700 +++ new/src/share/classes/sun/tools/tree/AssignOpExpression.java 2014-04-09 21:57:40.000000000 -0700 @@ -53,7 +53,7 @@ * Select the type * */ - + @SuppressWarnings("fallthrough") final void selectType(Environment env, Context ctx, int tm) { Type rtype = null; // special conversion type for RHS switch(op) { --- old/src/share/classes/sun/tools/tree/NewInstanceExpression.java 2014-04-09 21:57:41.000000000 -0700 +++ new/src/share/classes/sun/tools/tree/NewInstanceExpression.java 2014-04-09 21:57:41.000000000 -0700 @@ -487,6 +487,7 @@ public void codeValue(Environment env, Context ctx, Assembler asm) { codeCommon(env, ctx, asm, true); } + @SuppressWarnings("fallthrough") private void codeCommon(Environment env, Context ctx, Assembler asm, boolean forValue) { asm.add(where, opc_new, field.getClassDeclaration()); From Alan.Bateman at oracle.com Thu Apr 10 06:56:17 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Apr 2014 07:56:17 +0100 Subject: JDK 9 RFR of JDK-8039864: Fix fallthrough lint warnings in other libs In-Reply-To: <534625EB.5030005@oracle.com> References: <534625EB.5030005@oracle.com> Message-ID: <53464091.9070507@oracle.com> On 10/04/2014 06:02, Joe Darcy wrote: > Hello, > > I've started looking at cleaning up the fallthrough lint warnings in > the jdk repo. Please review the affected files in the "other libs" area: > > JDK-8039864: Fix fallthrough lint warnings in other libs > http://cr.openjdk.java.net/~darcy/8039864.0/ This looks okay to me. -Alan From alexander.v.stepanov at oracle.com Thu Apr 10 08:23:45 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Thu, 10 Apr 2014 12:23:45 +0400 Subject: [9] Review Request for 8030709: Tidy warnings cleanup for java.lang package Message-ID: <53465511.5090606@oracle.com> Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8030709 Webrev corresponding: http://cr.openjdk.java.net/~yan/8030709/webrev.00/ Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. BigInteger.java from java.lang was also touched. Thanks. Regards, Alexander From alexander.v.stepanov at oracle.com Thu Apr 10 08:24:37 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Thu, 10 Apr 2014 12:24:37 +0400 Subject: [9] Review Request for 8030709: Tidy warnings cleanup for java.lang package In-Reply-To: <53465511.5090606@oracle.com> References: <53465511.5090606@oracle.com> Message-ID: <53465545.4060307@oracle.com> > BigInteger.java from java.lang was also touched. sorry, from java.math On 10.04.2014 12:23, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8030709 > > Webrev corresponding: > http://cr.openjdk.java.net/~yan/8030709/webrev.00/ > > Just a minor cleanup of javadoc to avoid tidy warnings; no other code > affected. > > BigInteger.java from java.lang was also touched. > > Thanks. > > Regards, > Alexander From chris.hegarty at oracle.com Thu Apr 10 09:04:26 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Apr 2014 10:04:26 +0100 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> Message-ID: <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> On 10 Apr 2014, at 02:19, Brian Burkhalter wrote: > Hello, > > Issue: https://bugs.openjdk.java.net/browse/JDK-8039474 > Patch: http://cr.openjdk.java.net/~bpb/8039474/webrev.00/ The change looks fine to me Brian. Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. -Chris, > > The change is to specify the charset for the String where none had been before. The extant test sun/misc/Encode/GetBytes.java appears to suffice for this. > > Thanks, > > Brian From luchsh at linux.vnet.ibm.com Thu Apr 10 09:44:16 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Thu, 10 Apr 2014 17:44:16 +0800 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Volker, Thanks a lot for your comments, I've made another patch, http://cr.openjdk.java.net/~luchsh/JDK-8034220.v4/ On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis wrote: > Hi Jonathan, > > sorry, but I found a few more issues: > > - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise > somebody could easily crash the VM by specifying a TZ with more than > 100 characters. > Right, I've fix it by using strncpy, and also updated another usage of strcmp(). > > - you can delete the lines 871-872 because the variables are actually > not used and you can also remove the handling for "timezone == 0" > because that is actually done in getGMTOffsetID() anyway. > Nice catch, have deleted those in latest patch. > > - could you please avoid the usage of strtok. It is not intended for > usage in a multithreaded environment (see for example "man strtok" on > AIX). strtok_r is probably overkill, but you could use for example > strchr. > I've changed it to strtok_r in this patch, although strtok was only used once here, it may still impact other threads. > did you check the build on Windows? > Yes, both patches got built on Windows. > > Thank you and best regards, > Volker > > > On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu > wrote: > > Hi Volker, Masayoshi, > > > > I made another patch which fixed the problems mentioned in last mail, > > > > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ > > > > Could you pls help to take a look? > > > > Many thanks > > Jonathan > > > > > > > > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu > > wrote: > >> > >> Hi Volker, > >> > >> > >> On 2014?04?02? 23:07, Volker Simonis wrote: > >> > >> Hi Jonathan, > >> > >> thanks for updating the change. Please find my comments inline: > >> > >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu > >> wrote: > >> > >> Hi Volker, Masayoshi, > >> > >> Thanks a lot for your review, here's the updated patch, could you pls > take > >> a > >> look? > >> > >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ > >> > >> > >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis < > volker.simonis at gmail.com> > >> wrote: > >> > >> Hi Jonathan, > >> > >> thanks for doing this change. Please find some comments below: > >> > >> 1. please update the copyright year to 2014 in every file you touch > >> > >> Updated in new patch. > >> > >> 2. in CopyFiles.gmk you can simplify the change by joining the windows > >> and aix cases because on Windows OPENJDK_TARGET_OS is the same like > >> OPENJDK_TARGET_OS_API_DIR. So you can write: > >> > >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) > >> > >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib > >> > >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings > >> $(call install-file) > >> > >> COPY_FILES += $(LIBDIR)/tzmappings > >> > >> endif > >> > >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is > >> 'solaris' > >> as I observed on my AIX box, > >> solaris/lib is not the directory where tzmappings was stored for AIX. > >> So I'm keeping this change, please fix me if I was wrong about the > config. > >> > >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the > >> construction of TZMAPPINGS_SRC as shown in the code snippet above. > >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX > >> and that should be just enough here. > >> > >> > >> That's right, let me try that and also build/test on Windows platform. > >> > >> > >> 3. regarding the changes proposed by Masayoshi: I agree that we should > >> put the AIX timezone mapping code in its own function, but I don't > >> think that getPlatformTimeZoneID() would be the right place. As far as > >> I understand, getPlatformTimeZoneID() is used to get a platform time > >> zone id if the environment variable "TZ" is not set. I don't know a > >> way how this could be done on AIX (@Jonathan: maybe you know?). If > >> there would be a way to get the time zone from some system files or > >> so, then we should put this code into the AIX version of > >> getPlatformTimeZoneID(). > >> > >> I guess we may try to use /etc/envrionment file, which is basic setting > >> for > >> all processes, > >> see > >> > >> > http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm > >> The implementation of getPlatformTimeZoneID() has been updated. > >> > >> That's good! > >> > >> But the current AIX code contributed by Jonathan, actually uses the > >> time zone id from the "TZ" environment variable and just maps it to a > >> Java compatible time zone id. So I'd suggest to refactor this code > >> into a function like for example "static const char* > >> mapPlatformToJavaTimzone(const char* tz)" and call that from > >> findJavaTZ_md(). I think that would make the code easier to > >> understand. > >> > >> Agree, and have split the code into a separate static method to do the > >> mapping work. > >> > >> Good. But there's still one error in findJavaTZ_md(): > >> > >> 706 #ifdef _AIX > >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); > >> 708 #endif > >> > >> This should read: > >> > >> 706 #ifdef _AIX > >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz); > >> 708 #endif > >> > >> because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came > >> from getPlatformTimeZoneID(). > >> > >> > >> Right, but with the second approach, there may be a minor memory leak > >> here, > >> as javatz was not freed before being overwritten on AIX. will post > another > >> patch on this soon. > >> > >> > >> With the above fixed I'll push this one we get one more review from a > >> reviewer (I'm currently not an official reviewer). > >> > >> Regards, > >> Volker > >> > >> > >> @Masayoshi: what do you think, would you agree with such a solution. > >> > >> 4. I agree with Masayoshi that you should use the existing > >> getGMTOffsetID() > >> > >> Updated in new patch to eliminate duplication. > >> > >> 5. Please notice that your change breaks all Unix builds except AIX > >> because of: > >> > >> 759 } > >> 760 tzerr: > >> 761 if (javatz == NULL) { > >> 762 time_t offset; > >> ... > >> 782 } > >> 783 #endif > >> > >> I think that should read: > >> > >> 759 > >> 760 tzerr: > >> 761 if (javatz == NULL) { > >> 762 time_t offset; > >> ... > >> 782 } > >> 783 #endif > >> 784 } > >> > >> Refactoring the code in an extra function will make that error more > >> evident anyway. > >> > >> But please always build at least on one different platform (i.e. > >> Linux) to prevent such errors in the future. > >> > >> My fault, sorry for the failure, should take no chance after any manual > >> alteration. > >> > >> Regards, > >> Volker > >> > >> > >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu > >> wrote: > >> > >> Hi Jonathan, > >> > >> The AIX specific code looks OK to me. But I'd suggest the code be moved > >> to > >> getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also > >> there's a function for producing a fallback ID in "GMT?hh:mm", > >> getGMTOffsetID() which can be called in tzerr. > >> > >> Thanks, > >> Masayoshi > >> > >> > >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: > >> > >> Hi ppc-aix-port-dev, core-libs-dev, > >> > >> Here's a patch for JDK-8034220, > >> > >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ > >> > >> It is trying to add the a more complete timezone mapping mechanism for > >> AIX > >> platform. > >> the changes are primarily based on IBM's commercial JDK code, which > >> includes: > >> > >> - A new timezone mapping file added under directory jdk/src/aix/lib/ > >> - Code to parse above config file, changed file is > >> src/solaris/native/java/util/TimeZone_md.c > >> - And also makefile change in make/CopyFiles.gmk to copy the config > >> file > >> > >> Could you pls help to review and give comments ? > >> > >> Cheers > >> - Jonathan > >> > >> Many thanks > >> Jonathan > >> > >> Regards > >> Jonathan > > > > > Regards Jonathan From david.holmes at oracle.com Thu Apr 10 10:03:15 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Apr 2014 20:03:15 +1000 Subject: RFR [9] 8039527: Broken links in ConcurrentMap javadoc In-Reply-To: <53455427.8020201@oracle.com> References: <53455427.8020201@oracle.com> Message-ID: <53466C63.3080507@oracle.com> Looks good to me too Chris. But I can't help wonder if there is a design flaw in javadoc here, as this means you should never use relative links in any doc element that might be inherited. Which almost reduces to never use relative links. :( David On 10/04/2014 12:07 AM, Chris Hegarty wrote: > java.util.concurrent.ConcurrentMap contains several broken links to > Collection.html#optional-restrictions. See > > http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentMap.html > > > The issue is caused by the use of '{@inheritDoc}' in many '@throws' > definitions. ConcurrentMap's superType Map, is in the java.util package. > Map has documentation references to Collection.html, which is in the > same package as Map, java.util, but since ConcurrentMap is not in > java.util it needs different relative links, or better still links > relative to the docRoot. > > Trivial diffs inline: > > diff --git a/src/share/classes/java/util/Map.java > b/src/share/classes/java/util/Map.java > --- a/src/share/classes/java/util/Map.java > +++ b/src/share/classes/java/util/Map.java > @@ -157,10 +157,10 @@ > * key > * @throws ClassCastException if the key is of an inappropriate > type for > * this map > - * (optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws NullPointerException if the specified key is null and > this map > * does not permit null keys > - * (optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > */ > boolean containsKey(Object key); > > @@ -177,10 +177,10 @@ > * specified value > * @throws ClassCastException if the value is of an inappropriate > type for > * this map > - * (optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws NullPointerException if the specified value is null and > this > * map does not permit null values > - * (optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > */ > boolean containsValue(Object value); > > @@ -204,10 +204,10 @@ > * {@code null} if this map contains no mapping for the key > * @throws ClassCastException if the key is of an inappropriate > type for > * this map > - * (optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws NullPointerException if the specified key is null and > this map > * does not permit null keys > - * (optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > */ > V get(Object key); > > @@ -264,10 +264,10 @@ > * is not supported by this map > * @throws ClassCastException if the key is of an inappropriate > type for > * this map > - * (optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws NullPointerException if the specified key is null and this > * map does not permit null keys > - * (optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > */ > V remove(Object key); > > @@ -577,10 +577,10 @@ > * {@code defaultValue} if this map contains no mapping for the key > * @throws ClassCastException if the key is of an inappropriate > type for > * this map > - * (optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws NullPointerException if the specified key is null and > this map > * does not permit null keys > - * (optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @since 1.8 > */ > default V getOrDefault(Object key, V defaultValue) { > @@ -659,13 +659,13 @@ > * values > * @throws ClassCastException if a replacement value is of an > inappropriate > * type for this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws NullPointerException if function or a replacement value > is null, > * and this map does not permit null keys or values > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws IllegalArgumentException if some property of a > replacement value > * prevents it from being stored in this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws ConcurrentModificationException if an entry is found to be > * removed during iteration > * @since 1.8 > @@ -726,16 +726,16 @@ > * if the implementation supports null values.) > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws ClassCastException if the key or value is of an > inappropriate > * type for this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws NullPointerException if the specified key or value is > null, > * and this map does not permit null keys or values > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws IllegalArgumentException if some property of the > specified key > * or value prevents it from being stored in this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @since 1.8 > */ > default V putIfAbsent(K key, V value) { > @@ -772,13 +772,13 @@ > * @return {@code true} if the value was removed > * @throws UnsupportedOperationException if the {@code remove} > operation > * is not supported by this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws ClassCastException if the key or value is of an > inappropriate > * type for this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws NullPointerException if the specified key or value is > null, > * and this map does not permit null keys or values > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @since 1.8 > */ > default boolean remove(Object key, Object value) { > @@ -821,14 +821,14 @@ > * @return {@code true} if the value was replaced > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws ClassCastException if the class of a specified key or > value > * prevents it from being stored in this map > * @throws NullPointerException if a specified key or newValue is > null, > * and this map does not permit null keys or values > * @throws NullPointerException if oldValue is null and this map > does not > * permit null values > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws IllegalArgumentException if some property of a > specified key > * or value prevents it from being stored in this map > * @since 1.8 > @@ -871,10 +871,10 @@ > * if the implementation supports null values.) > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws ClassCastException if the class of the specified key or > value > * prevents it from being stored in this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws NullPointerException if the specified key or value is > null, > * and this map does not permit null keys or values > * @throws IllegalArgumentException if some property of the > specified key > @@ -942,10 +942,10 @@ > * is null > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws ClassCastException if the class of the specified key or > value > * prevents it from being stored in this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @since 1.8 > */ > default V computeIfAbsent(K key, > @@ -1003,10 +1003,10 @@ > * remappingFunction is null > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws ClassCastException if the class of the specified key or > value > * prevents it from being stored in this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @since 1.8 > */ > default V computeIfPresent(K key, > @@ -1079,10 +1079,10 @@ > * remappingFunction is null > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws ClassCastException if the class of the specified key or > value > * prevents it from being stored in this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @since 1.8 > */ > default V compute(K key, > @@ -1157,10 +1157,10 @@ > * value is associated with the key > * @throws UnsupportedOperationException if the {@code put} operation > * is not supported by this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws ClassCastException if the class of the specified key or > value > * prevents it from being stored in this map > - * ( href="Collection.html#optional-restrictions">optional) > + * ( href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) > > * @throws NullPointerException if the specified key is null and > this map > * does not support null keys or the value or > remappingFunction is > * null > > -Chris. From Ulf.Zibis at CoSoCo.de Thu Apr 10 10:03:52 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 10 Apr 2014 12:03:52 +0200 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> Message-ID: <53466C88.10801@CoSoCo.de> Hi Chris, Am 10.04.2014 11:04, schrieb Chris Hegarty: > Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache. And it's even better to use the same String instance for the lookup which was used to cache the charset. -Ulf From chris.hegarty at oracle.com Thu Apr 10 10:21:54 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Apr 2014 11:21:54 +0100 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <53466C88.10801@CoSoCo.de> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> Message-ID: <300C2A27-3E1E-4373-ADB9-B4D29ABC72A9@oracle.com> On 10 Apr 2014, at 11:03, Ulf Zibis wrote: > Hi Chris, > > Am 10.04.2014 11:04, schrieb Chris Hegarty: >> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. > > In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache. > And it's even better to use the same String instance for the lookup which was used to cache the charset. Interesting? thanks for let me know. Presumably, there is an assumption is StandardCharsets is not initialized elsewhere, by another dependency. -Chris. > > -Ulf > From Ulf.Zibis at CoSoCo.de Thu Apr 10 10:27:29 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 10 Apr 2014 12:27:29 +0200 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <53466C88.10801@CoSoCo.de> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> Message-ID: <53467211.8070405@CoSoCo.de> Correction ... Am 10.04.2014 12:03, schrieb Ulf Zibis: > Hi Chris, > > Am 10.04.2014 11:04, schrieb Chris Hegarty: >> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to >> avoid the cost of String to CharSet lookup. > > In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets > object is higher than the lookup of an existing object in the cache. > And it's even better to use the same String instance for the lookup which was used to cache the > charset. It's not about the cached charset, but about the cached charsets de/encoder, compare: StringCoding.decode(String charsetName, byte[] ba, int off, int len) StringCoding.decode(Charset cs, byte[] ba, int off, int len) -Ulf From chris.hegarty at oracle.com Thu Apr 10 10:27:50 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Apr 2014 11:27:50 +0100 Subject: RFR [9] 8039527: Broken links in ConcurrentMap javadoc In-Reply-To: <53466C63.3080507@oracle.com> References: <53455427.8020201@oracle.com> <53466C63.3080507@oracle.com> Message-ID: <3A115073-8DA9-433B-B361-840195C9AC83@oracle.com> On 10 Apr 2014, at 11:03, David Holmes wrote: > Looks good to me too Chris. Thanks for looking at this David. Unfortunately I pushed before receiving this mail, so you are not listed as a reviewer on the changeset, > But I can't help wonder if there is a design flaw in javadoc here, as this means you should never use relative links in any doc element that might be inherited. Which almost reduces to never use relative links. :( Right. This could be considered an issue with javadoc. It is difficult to say if relative hrefs should be resolved against the subtypes package hierarchy. At the very least a bug against the javadoc tool should be filed so that we can get final clarification on expected behaviour. I will do this. -Chris. > > David > > On 10/04/2014 12:07 AM, Chris Hegarty wrote: >> java.util.concurrent.ConcurrentMap contains several broken links to >> Collection.html#optional-restrictions. See >> >> http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentMap.html >> >> >> The issue is caused by the use of '{@inheritDoc}' in many '@throws' >> definitions. ConcurrentMap's superType Map, is in the java.util package. >> Map has documentation references to Collection.html, which is in the >> same package as Map, java.util, but since ConcurrentMap is not in >> java.util it needs different relative links, or better still links >> relative to the docRoot. >> >> Trivial diffs inline: >> >> diff --git a/src/share/classes/java/util/Map.java >> b/src/share/classes/java/util/Map.java >> --- a/src/share/classes/java/util/Map.java >> +++ b/src/share/classes/java/util/Map.java >> @@ -157,10 +157,10 @@ >> * key >> * @throws ClassCastException if the key is of an inappropriate >> type for >> * this map >> - * (optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws NullPointerException if the specified key is null and >> this map >> * does not permit null keys >> - * (optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> */ >> boolean containsKey(Object key); >> >> @@ -177,10 +177,10 @@ >> * specified value >> * @throws ClassCastException if the value is of an inappropriate >> type for >> * this map >> - * (optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws NullPointerException if the specified value is null and >> this >> * map does not permit null values >> - * (optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> */ >> boolean containsValue(Object value); >> >> @@ -204,10 +204,10 @@ >> * {@code null} if this map contains no mapping for the key >> * @throws ClassCastException if the key is of an inappropriate >> type for >> * this map >> - * (optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws NullPointerException if the specified key is null and >> this map >> * does not permit null keys >> - * (optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> */ >> V get(Object key); >> >> @@ -264,10 +264,10 @@ >> * is not supported by this map >> * @throws ClassCastException if the key is of an inappropriate >> type for >> * this map >> - * (optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws NullPointerException if the specified key is null and this >> * map does not permit null keys >> - * (optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> */ >> V remove(Object key); >> >> @@ -577,10 +577,10 @@ >> * {@code defaultValue} if this map contains no mapping for the key >> * @throws ClassCastException if the key is of an inappropriate >> type for >> * this map >> - * (optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws NullPointerException if the specified key is null and >> this map >> * does not permit null keys >> - * (optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @since 1.8 >> */ >> default V getOrDefault(Object key, V defaultValue) { >> @@ -659,13 +659,13 @@ >> * values >> * @throws ClassCastException if a replacement value is of an >> inappropriate >> * type for this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws NullPointerException if function or a replacement value >> is null, >> * and this map does not permit null keys or values >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws IllegalArgumentException if some property of a >> replacement value >> * prevents it from being stored in this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws ConcurrentModificationException if an entry is found to be >> * removed during iteration >> * @since 1.8 >> @@ -726,16 +726,16 @@ >> * if the implementation supports null values.) >> * @throws UnsupportedOperationException if the {@code put} operation >> * is not supported by this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws ClassCastException if the key or value is of an >> inappropriate >> * type for this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws NullPointerException if the specified key or value is >> null, >> * and this map does not permit null keys or values >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws IllegalArgumentException if some property of the >> specified key >> * or value prevents it from being stored in this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @since 1.8 >> */ >> default V putIfAbsent(K key, V value) { >> @@ -772,13 +772,13 @@ >> * @return {@code true} if the value was removed >> * @throws UnsupportedOperationException if the {@code remove} >> operation >> * is not supported by this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws ClassCastException if the key or value is of an >> inappropriate >> * type for this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws NullPointerException if the specified key or value is >> null, >> * and this map does not permit null keys or values >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @since 1.8 >> */ >> default boolean remove(Object key, Object value) { >> @@ -821,14 +821,14 @@ >> * @return {@code true} if the value was replaced >> * @throws UnsupportedOperationException if the {@code put} operation >> * is not supported by this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws ClassCastException if the class of a specified key or >> value >> * prevents it from being stored in this map >> * @throws NullPointerException if a specified key or newValue is >> null, >> * and this map does not permit null keys or values >> * @throws NullPointerException if oldValue is null and this map >> does not >> * permit null values >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws IllegalArgumentException if some property of a >> specified key >> * or value prevents it from being stored in this map >> * @since 1.8 >> @@ -871,10 +871,10 @@ >> * if the implementation supports null values.) >> * @throws UnsupportedOperationException if the {@code put} operation >> * is not supported by this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws ClassCastException if the class of the specified key or >> value >> * prevents it from being stored in this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws NullPointerException if the specified key or value is >> null, >> * and this map does not permit null keys or values >> * @throws IllegalArgumentException if some property of the >> specified key >> @@ -942,10 +942,10 @@ >> * is null >> * @throws UnsupportedOperationException if the {@code put} operation >> * is not supported by this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws ClassCastException if the class of the specified key or >> value >> * prevents it from being stored in this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @since 1.8 >> */ >> default V computeIfAbsent(K key, >> @@ -1003,10 +1003,10 @@ >> * remappingFunction is null >> * @throws UnsupportedOperationException if the {@code put} operation >> * is not supported by this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws ClassCastException if the class of the specified key or >> value >> * prevents it from being stored in this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @since 1.8 >> */ >> default V computeIfPresent(K key, >> @@ -1079,10 +1079,10 @@ >> * remappingFunction is null >> * @throws UnsupportedOperationException if the {@code put} operation >> * is not supported by this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws ClassCastException if the class of the specified key or >> value >> * prevents it from being stored in this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @since 1.8 >> */ >> default V compute(K key, >> @@ -1157,10 +1157,10 @@ >> * value is associated with the key >> * @throws UnsupportedOperationException if the {@code put} operation >> * is not supported by this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws ClassCastException if the class of the specified key or >> value >> * prevents it from being stored in this map >> - * (> href="Collection.html#optional-restrictions">optional) >> + * (> href="{@docRoot}/java/util/Collection.html#optional-restrictions">optional) >> >> * @throws NullPointerException if the specified key is null and >> this map >> * does not support null keys or the value or >> remappingFunction is >> * null >> >> -Chris. From sean.coffey at oracle.com Thu Apr 10 10:35:42 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Thu, 10 Apr 2014 11:35:42 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <5345B899.2020407@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> <53445BF9.6010902@oracle.com> <534585B7.40409@oracle.com> <5345931F.6010502@oracle.com> <53459B36.5090602@oracle.com> <5345B899.2020407@oracle.com> Message-ID: <534673FE.7050304@oracle.com> This should make the code more robust Alan. http://cr.openjdk.java.net/~coffeys/webrev.8038491.v3/webrev/ regards, Sean. On 09/04/2014 22:16, Alan Bateman wrote: > On 09/04/2014 20:10, Se?n Coffey wrote: >> >> I played around with adding some skip testing Alan but didn't see it >> increase the rate of failure on an unpatched binary. Since >> ZipFileInputStream.read(..) is the trouble method and now has better >> synchronized access to reading and updating rem, I believe we're >> good. skip(long) can trigger a close() but close() can't free up the >> resources without the ZipFile.this lock. As mentioned, having >> multiples threads reading from the one zip stream would make no sense >> anyhow. >> >> Let me know if I need to make changes. I don't think we want to add >> extra sync costs to the class. > If you are only going to synchronize read then you will need to take a > copy of rem and pos, otherwise you have to assume that the check and > limiting of len isn't reliable, same thing for pos which could be way > out of range due to concurrent usages of skip. > > -Alan. From pavel.rappo at oracle.com Thu Apr 10 10:49:39 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 10 Apr 2014 11:49:39 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <534673FE.7050304@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> <53445BF9.6010902@oracle.com> <534585B7.40409@oracle.com> <5345931F.6010502@oracle.com> <53459B36.5090602@oracle.com> <5345B899.2020407@oracle.com> <534673FE.7050304@oracle.com> Message-ID: Given the amount of mutual exclusion and synchronization already involved, I wonder if it's worth making it thread-safe after all. And (idialy) forget about races there forever. -Pavel On 10 Apr 2014, at 11:35, Se?n Coffey wrote: > This should make the code more robust Alan. > > http://cr.openjdk.java.net/~coffeys/webrev.8038491.v3/webrev/ > > regards, > Sean. > > On 09/04/2014 22:16, Alan Bateman wrote: >> On 09/04/2014 20:10, Se?n Coffey wrote: >>> >>> I played around with adding some skip testing Alan but didn't see it increase the rate of failure on an unpatched binary. Since ZipFileInputStream.read(..) is the trouble method and now has better synchronized access to reading and updating rem, I believe we're good. skip(long) can trigger a close() but close() can't free up the resources without the ZipFile.this lock. As mentioned, having multiples threads reading from the one zip stream would make no sense anyhow. >>> >>> Let me know if I need to make changes. I don't think we want to add extra sync costs to the class. >> If you are only going to synchronize read then you will need to take a copy of rem and pos, otherwise you have to assume that the check and limiting of len isn't reliable, same thing for pos which could be way out of range due to concurrent usages of skip. >> >> -Alan. > From lance.andersen at oracle.com Thu Apr 10 10:51:43 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Thu, 10 Apr 2014 06:51:43 -0400 Subject: JDK 9 RFR of JDK-8039864: Fix fallthrough lint warnings in other libs In-Reply-To: <534625EB.5030005@oracle.com> References: <534625EB.5030005@oracle.com> Message-ID: +1 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 Apr 10, 2014, at 1:02 AM, Joe Darcy wrote: > Hello, > > I've started looking at cleaning up the fallthrough lint warnings in the jdk repo. Please review the affected files in the "other libs" area: > > JDK-8039864: Fix fallthrough lint warnings in other libs > http://cr.openjdk.java.net/~darcy/8039864.0/ > > Thanks, > > -Joe > > --- old/src/share/classes/sun/tools/java/Environment.java 2014-04-09 21:57:38.000000000 -0700 > +++ new/src/share/classes/sun/tools/java/Environment.java 2014-04-09 21:57:38.000000000 -0700 > @@ -648,6 +648,7 @@ > * Return true if an implicit cast from this type to > * the given type is allowed. > */ > + @SuppressWarnings("fallthrough") > public boolean implicitCast(Type from, Type to) throws ClassNotFound { > if (from == to) > return true; > --- old/src/share/classes/sun/tools/java/Scanner.java 2014-04-09 21:57:39.000000000 -0700 > +++ new/src/share/classes/sun/tools/java/Scanner.java 2014-04-09 21:57:39.000000000 -0700 > @@ -511,6 +511,7 @@ > * Scan a number. The first digit of the number should be the current > * character. We may be scanning hex, decimal, or octal at this point > */ > + @SuppressWarnings("fallthrough") > private void scanNumber() throws IOException { > boolean seenNonOctal = false; > boolean overflow = false; > @@ -532,6 +533,7 @@ > // We can't yet throw an error if reading an octal. We might > // discover we're really reading a real. > seenNonOctal = true; > + // Fall through > case '0': case '1': case '2': case '3': > case '4': case '5': case '6': case '7': > seenDigit = true; > @@ -668,6 +670,7 @@ > * Scan a float. Should be called with the current character is either > * the 'e', 'E' or '.' > */ > + @SuppressWarnings("fallthrough") > private void scanReal() throws IOException { > boolean seenExponent = false; > boolean isSingleFloat = false; > @@ -984,6 +987,7 @@ > return xscan(); > } > > + @SuppressWarnings("fallthrough") > protected long xscan() throws IOException { > final ScannerInputReader in = this.in; > long retPos = pos; > @@ -1006,6 +1010,7 @@ > token = COMMENT; > return retPos; > } > + // Fall through > case ' ': > case '\t': > case '\f': > --- old/src/share/classes/sun/tools/javac/Main.java 2014-04-09 21:57:40.000000000 -0700 > +++ new/src/share/classes/sun/tools/javac/Main.java 2014-04-09 21:57:39.000000000 -0700 > @@ -192,6 +192,7 @@ > /** > * Run the compiler > */ > + @SuppressWarnings("fallthrough") > public synchronized boolean compile(String argv[]) { > String sourcePathArg = null; > String classPathArg = null; > --- old/src/share/classes/sun/tools/jinfo/JInfo.java 2014-04-09 21:57:40.000000000 -0700 > +++ new/src/share/classes/sun/tools/jinfo/JInfo.java 2014-04-09 21:57:40.000000000 -0700 > @@ -41,6 +41,7 @@ > */ > public class JInfo { > > + @SuppressWarnings("fallthrough") > public static void main(String[] args) throws Exception { > if (args.length == 0) { > usage(1); // no arguments > @@ -118,6 +119,7 @@ > case "-help": > case "-h": > usage(0); > + // Fall through > default: > if (args.length == 1) { > // no flags specified, we do -sysprops and -flags > --- old/src/share/classes/sun/tools/tree/AssignOpExpression.java 2014-04-09 21:57:41.000000000 -0700 > +++ new/src/share/classes/sun/tools/tree/AssignOpExpression.java 2014-04-09 21:57:40.000000000 -0700 > @@ -53,7 +53,7 @@ > * Select the type > * > */ > - > + @SuppressWarnings("fallthrough") > final void selectType(Environment env, Context ctx, int tm) { > Type rtype = null; // special conversion type for RHS > switch(op) { > --- old/src/share/classes/sun/tools/tree/NewInstanceExpression.java 2014-04-09 21:57:41.000000000 -0700 > +++ new/src/share/classes/sun/tools/tree/NewInstanceExpression.java 2014-04-09 21:57:41.000000000 -0700 > @@ -487,6 +487,7 @@ > public void codeValue(Environment env, Context ctx, Assembler asm) { > codeCommon(env, ctx, asm, true); > } > + @SuppressWarnings("fallthrough") > private void codeCommon(Environment env, Context ctx, Assembler asm, > boolean forValue) { > asm.add(where, opc_new, field.getClassDeclaration()); > From miroslav.kos at oracle.com Thu Apr 10 10:56:55 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Thu, 10 Apr 2014 12:56:55 +0200 Subject: RFR: 8039899: Missing licence headers in test for JDK-8033113 Message-ID: <534678F7.5010204@oracle.com> Hi, please review the following change - this is just missing license headers fix - 8039899: Missing licence headers in test for JDK-8033113 JBS: https://bugs.openjdk.java.net/browse/JDK-8039899 WEBREV: http://cr.openjdk.java.net/~mkos/8039899/jdk.01/ Chris, may I ask you to push it to jdk9u-dev? Thanks Miran From sean.coffey at oracle.com Thu Apr 10 11:46:13 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Thu, 10 Apr 2014 12:46:13 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> <53445BF9.6010902@oracle.com> <534585B7.40409@oracle.com> <5345931F.6010502@oracle.com> <53459B36.5090602@oracle.com> <5345B899.2020407@oracle.com> <534673FE.7050304@oracle.com> Message-ID: <53468485.6040406@oracle.com> On 10/04/2014 11:49, Pavel Rappo wrote: > Given the amount of mutual exclusion and synchronization already involved, I wonder if it's worth making it thread-safe after all. And (idialy) forget about races there forever. It's a fair point Pavel. All java.util.zip classes would need to be looked at to claim that zip package would be thread-safe. It still only makes sense to have only one thread operating on such streams and if the application does code to that expectation maybe the synchronization overhead is not too costly. Maybe an enhancement request could be opened to look into it. I'd like to backport the below change to 8u, 7u and keep that separate. regards, Sean. > > -Pavel > > On 10 Apr 2014, at 11:35, Se?n Coffey wrote: > >> This should make the code more robust Alan. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8038491.v3/webrev/ >> >> regards, >> Sean. >> >> On 09/04/2014 22:16, Alan Bateman wrote: >>> On 09/04/2014 20:10, Se?n Coffey wrote: >>>> I played around with adding some skip testing Alan but didn't see it increase the rate of failure on an unpatched binary. Since ZipFileInputStream.read(..) is the trouble method and now has better synchronized access to reading and updating rem, I believe we're good. skip(long) can trigger a close() but close() can't free up the resources without the ZipFile.this lock. As mentioned, having multiples threads reading from the one zip stream would make no sense anyhow. >>>> >>>> Let me know if I need to make changes. I don't think we want to add extra sync costs to the class. >>> If you are only going to synchronize read then you will need to take a copy of rem and pos, otherwise you have to assume that the check and limiting of len isn't reliable, same thing for pos which could be way out of range due to concurrent usages of skip. >>> >>> -Alan. From chris.hegarty at oracle.com Thu Apr 10 12:27:42 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Apr 2014 13:27:42 +0100 Subject: RFR: 8039899: Missing licence headers in test for JDK-8033113 In-Reply-To: <534678F7.5010204@oracle.com> References: <534678F7.5010204@oracle.com> Message-ID: On 10 Apr 2014, at 11:56, Miroslav Kos wrote: > Hi, > please review the following change - this is just missing license headers fix - > > 8039899: Missing licence headers in test for JDK-8033113 > JBS: https://bugs.openjdk.java.net/browse/JDK-8039899 > WEBREV: http://cr.openjdk.java.net/~mkos/8039899/jdk.01/ Approved. Looks good to me. > Chris, may I ask you to push it to jdk9u-dev? Yes, I will push this for you. -Chris. > > Thanks > Miran From Alan.Bateman at oracle.com Thu Apr 10 13:04:19 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Apr 2014 14:04:19 +0100 Subject: RFR : 8038491: Improve synchronization in ZipFile.read() In-Reply-To: <534673FE.7050304@oracle.com> References: <534413E7.3030505@oracle.com> <53441CEA.30008@oracle.com> <534431FF.6060609@oracle.com> <53443882.4010304@oracle.com> <53445BF9.6010902@oracle.com> <534585B7.40409@oracle.com> <5345931F.6010502@oracle.com> <53459B36.5090602@oracle.com> <5345B899.2020407@oracle.com> <534673FE.7050304@oracle.com> Message-ID: <534696D3.8000209@oracle.com> On 10/04/2014 11:35, Se?n Coffey wrote: > This should make the code more robust Alan. > > http://cr.openjdk.java.net/~coffeys/webrev.8038491.v3/webrev/ This looks much better and means that the checks prior to the read do what they were intended to do. There are still works with this code as it was just never intended to be used in this way. I agree with Pavel's comment that it wouldn't take much effort to fix it completely. You're interesting might be 7u, in which case splitting into two issues is okay. -Alan. From alexandre.iline at oracle.com Thu Apr 10 13:20:16 2014 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 10 Apr 2014 17:20:16 +0400 Subject: RFR: 8039438: Some tests depend on internal API sun.misc.IOUtils In-Reply-To: <53459488.4000606@oracle.com> References: <53456E94.1020409@oracle.com> <53459488.4000606@oracle.com> Message-ID: <53469A90.3020202@oracle.com> On 4/9/14, 10:42 PM, Alan Bateman wrote: > On 09/04/2014 17:00, Alexandre (Shura) Iline wrote: >> Hi. >> >> I'd like to ask for review of this fix: >> http://cr.openjdk.java.net/~shurailine/8039438/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8039438 > Looks okay to me. > > For the class description then maybe something like "Defines useful I/O > methods" might be a bit better than "Holds useful io shortcuts" but it's > a minor point. I guess I would probably make it final and/or a private > constructor to make it obvious that it just defines static methods. > > A minor comment on LambdaClassLoaderSerialization.java is that would be > good to indeed the tags so that they are consistent with other tests > (pre-dates your change but more noticable now). I assume you meant "indent" above. http://cr.openjdk.java.net/~shurailine/8039438/webrev.01/ Shura > > -Alan From brian.burkhalter at oracle.com Thu Apr 10 14:57:04 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Apr 2014 07:57:04 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <53467211.8070405@CoSoCo.de> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <53467211.8070405@CoSoCo.de> Message-ID: On Apr 10, 2014, at 3:27 AM, Ulf Zibis wrote: > Correction ... > > Am 10.04.2014 12:03, schrieb Ulf Zibis: >> Hi Chris, >> >> Am 10.04.2014 11:04, schrieb Chris Hegarty: >>> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. >> >> In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache. >> And it's even better to use the same String instance for the lookup which was used to cache the charset. > > It's not about the cached charset, but about the cached charsets de/encoder, compare: > StringCoding.decode(String charsetName, byte[] ba, int off, int len) > StringCoding.decode(Charset cs, byte[] ba, int off, int len) So from all this I infer that the change is OK as-is. Correct? Thanks, Brian From chris.hegarty at oracle.com Thu Apr 10 14:59:28 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Apr 2014 15:59:28 +0100 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <53467211.8070405@CoSoCo.de> Message-ID: <307D8599-606E-4B1C-B9C9-EB5DEB980BAE@oracle.com> On 10 Apr 2014, at 15:57, Brian Burkhalter wrote: > > On Apr 10, 2014, at 3:27 AM, Ulf Zibis wrote: > >> Correction ... >> >> Am 10.04.2014 12:03, schrieb Ulf Zibis: >>> Hi Chris, >>> >>> Am 10.04.2014 11:04, schrieb Chris Hegarty: >>>> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. >>> >>> In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache. >>> And it's even better to use the same String instance for the lookup which was used to cache the charset. >> >> It's not about the cached charset, but about the cached charsets de/encoder, compare: >> StringCoding.decode(String charsetName, byte[] ba, int off, int len) >> StringCoding.decode(Charset cs, byte[] ba, int off, int len) > > So from all this I infer that the change is OK as-is. > > Correct? From my point of view, YES. -Chris. > > Thanks, > > Brian From xueming.shen at oracle.com Thu Apr 10 15:20:38 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 10 Apr 2014 08:20:38 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <53467211.8070405@CoSoCo.de> Message-ID: <5346B6C6.2000908@oracle.com> Looks fine. Personally I would prefer the "canonicalized/real" name "ISO-8859-1" though. -Sherman On 4/10/14 7:57 AM, Brian Burkhalter wrote: > On Apr 10, 2014, at 3:27 AM, Ulf Zibis wrote: > >> Correction ... >> >> Am 10.04.2014 12:03, schrieb Ulf Zibis: >>> Hi Chris, >>> >>> Am 10.04.2014 11:04, schrieb Chris Hegarty: >>>> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. >>> In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache. >>> And it's even better to use the same String instance for the lookup which was used to cache the charset. >> It's not about the cached charset, but about the cached charsets de/encoder, compare: >> StringCoding.decode(String charsetName, byte[] ba, int off, int len) >> StringCoding.decode(Charset cs, byte[] ba, int off, int len) > So from all this I infer that the change is OK as-is. > > Correct? > > Thanks, > > Brian From mike.duigou at oracle.com Thu Apr 10 17:40:56 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 10 Apr 2014 10:40:56 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <300C2A27-3E1E-4373-ADB9-B4D29ABC72A9@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <300C2A27-3E1E-4373-ADB9-B4D29ABC72A9@oracle.com> Message-ID: On Apr 10 2014, at 03:21 , Chris Hegarty wrote: > On 10 Apr 2014, at 11:03, Ulf Zibis wrote: > >> Hi Chris, >> >> Am 10.04.2014 11:04, schrieb Chris Hegarty: >>> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. >> >> In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache. >> And it's even better to use the same String instance for the lookup which was used to cache the charset. > > Interesting? thanks for let me know. Presumably, there is an assumption is StandardCharsets is not initialized elsewhere, by another dependency. Generally it's safe to assume that StandardCharsets will already be initialized. If it isn't initialized we should consider it an amortized cost. Mike From mike.duigou at oracle.com Thu Apr 10 17:54:58 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 10 Apr 2014 10:54:58 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> Message-ID: Shouldn't we be using the platform default character set rather than iso8859-1? This change will change the charset used for all platforms not using iso885901 as their default. It is certainly odd that sun.misc.CharacterEncoder(byte) and sun.misc.CharacterDecoder(String) are not symmetrical but this seems like a serious historical wart we might need to preserve. Mike On Apr 9 2014, at 18:19 , Brian Burkhalter wrote: > Hello, > > Issue: https://bugs.openjdk.java.net/browse/JDK-8039474 > Patch: http://cr.openjdk.java.net/~bpb/8039474/webrev.00/ > > The change is to specify the charset for the String where none had been before. The extant test sun/misc/Encode/GetBytes.java appears to suffice for this. > > Thanks, > > Brian From brian.burkhalter at oracle.com Thu Apr 10 17:59:31 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Apr 2014 10:59:31 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> Message-ID: <63ACE430-1ADB-4514-816E-0536C10A3D15@oracle.com> How can one keep it symmetrical without forcing a particular encoding? Brian On Apr 10, 2014, at 10:54 AM, Mike Duigou wrote: > Shouldn't we be using the platform default character set rather than iso8859-1? > > This change will change the charset used for all platforms not using iso885901 as their default. > > It is certainly odd that sun.misc.CharacterEncoder(byte) and sun.misc.CharacterDecoder(String) are not symmetrical but this seems like a serious historical wart we might need to preserve. From mike.duigou at oracle.com Thu Apr 10 18:05:02 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 10 Apr 2014 11:05:02 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <63ACE430-1ADB-4514-816E-0536C10A3D15@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <63ACE430-1ADB-4514-816E-0536C10A3D15@oracle.com> Message-ID: It won't be symmetrical unless the default charset is ISO8859-1. We can't change sun.misc.CharacterEncoder(byte) to use the default charset because it has the longstanding behaviour of encoding to ISO8859-1 and I would argue we can't change sun.misc.CharacterDecoder(String) from using the default charset because that behaviour is also longstanding. Strange, wrongheaded and nonsensical behaviour, but longstanding. "Isn't all this sun.misc stuff going go away soon anyway?" <-- wishful thinking Mike On Apr 10 2014, at 10:59 , Brian Burkhalter wrote: > How can one keep it symmetrical without forcing a particular encoding? > > Brian > > On Apr 10, 2014, at 10:54 AM, Mike Duigou wrote: > >> Shouldn't we be using the platform default character set rather than iso8859-1? >> >> This change will change the charset used for all platforms not using iso885901 as their default. >> >> It is certainly odd that sun.misc.CharacterEncoder(byte) and sun.misc.CharacterDecoder(String) are not symmetrical but this seems like a serious historical wart we might need to preserve. > From xueming.shen at oracle.com Thu Apr 10 18:08:50 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 10 Apr 2014 11:08:50 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> Message-ID: <5346DE32.2090309@oracle.com> This fix is to "un-do" a previous changeset (8036848), in which it replaces the use of deprecated String.getBytes(int,int,byte[],int) method with String.getBytes() (which uses the default platform default charset), therefor causes a behavioral change. This one is to undo that change to go back to the "platform neutral" behavior. String.getBytes(int,int,byte[],int) and String.getBytes(iso-8859-1) are functionally equivalent when encoding (from charset's decoding/encoding perspective/term, it's "decoding" from base64's term) base64 alphabets. -Sherman On 04/10/2014 10:54 AM, Mike Duigou wrote: > Shouldn't we be using the platform default character set rather than iso8859-1? > > This change will change the charset used for all platforms not using iso885901 as their default. > > It is certainly odd that sun.misc.CharacterEncoder(byte) and sun.misc.CharacterDecoder(String) are not symmetrical but this seems like a serious historical wart we might need to preserve. > > Mike > > On Apr 9 2014, at 18:19 , Brian Burkhalter wrote: > >> Hello, >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8039474 >> Patch: http://cr.openjdk.java.net/~bpb/8039474/webrev.00/ >> >> The change is to specify the charset for the String where none had been before. The extant test sun/misc/Encode/GetBytes.java appears to suffice for this. >> >> Thanks, >> >> Brian From brian.burkhalter at oracle.com Thu Apr 10 18:05:44 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Apr 2014 11:05:44 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <63ACE430-1ADB-4514-816E-0536C10A3D15@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <63ACE430-1ADB-4514-816E-0536C10A3D15@oracle.com> Message-ID: <47A59E61-9777-465C-97C5-423CF98C6733@oracle.com> That is to say either explicitly or implicitly, i.e., using the default on both ends? On Apr 10, 2014, at 10:59 AM, Brian Burkhalter wrote: > How can one keep it symmetrical without forcing a particular encoding? > > Brian > > On Apr 10, 2014, at 10:54 AM, Mike Duigou wrote: > >> Shouldn't we be using the platform default character set rather than iso8859-1? >> >> This change will change the charset used for all platforms not using iso885901 as their default. >> >> It is certainly odd that sun.misc.CharacterEncoder(byte) and sun.misc.CharacterDecoder(String) are not symmetrical but this seems like a serious historical wart we might need to preserve. From brian.burkhalter at oracle.com Thu Apr 10 18:08:21 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Apr 2014 11:08:21 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <63ACE430-1ADB-4514-816E-0536C10A3D15@oracle.com> Message-ID: <10A9F5CF-84B0-452B-9AD1-FE0D95DD87A0@oracle.com> => Resolved: Won?t Fix. On Apr 10, 2014, at 11:05 AM, Mike Duigou wrote: > Strange, wrongheaded and nonsensical behaviour, but longstanding. From chris.hegarty at oracle.com Thu Apr 10 18:08:37 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Apr 2014 19:08:37 +0100 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <300C2A27-3E1E-4373-ADB9-B4D29ABC72A9@oracle.com> Message-ID: <97B2F738-286C-46C5-A0DF-5221491314C5@oracle.com> > On 10 Apr 2014, at 18:40, Mike Duigou wrote: > > >> On Apr 10 2014, at 03:21 , Chris Hegarty wrote: >> >>> On 10 Apr 2014, at 11:03, Ulf Zibis wrote: >>> >>> Hi Chris, >>> >>> Am 10.04.2014 11:04, schrieb Chris Hegarty: >>>> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. >>> >>> In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache. >>> And it's even better to use the same String instance for the lookup which was used to cache the charset. >> >> Interesting? thanks for let me know. Presumably, there is an assumption is StandardCharsets is not initialized elsewhere, by another dependency. > > Generally it's safe to assume that StandardCharsets will already be initialized. If it isn't initialized we should consider it an amortized cost. I'm which case why would the string version be more performant than the version that already takes the Charset? Doesn't the string version need to do a lookup? -Chris. > Mike From xueming.shen at oracle.com Thu Apr 10 18:23:09 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 10 Apr 2014 11:23:09 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <97B2F738-286C-46C5-A0DF-5221491314C5@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <300C2A27-3E1E-4373-ADB9-B4D29ABC72A9@oracle.com> <97B2F738-286C-46C5-A0DF-5221491314C5@oracle.com> Message-ID: <5346E18D.3000703@oracle.com> On 04/10/2014 11:08 AM, Chris Hegarty wrote: >> On 10 Apr 2014, at 18:40, Mike Duigou wrote: >> >> >>> On Apr 10 2014, at 03:21 , Chris Hegarty wrote: >>> >>>> On 10 Apr 2014, at 11:03, Ulf Zibis wrote: >>>> >>>> Hi Chris, >>>> >>>> Am 10.04.2014 11:04, schrieb Chris Hegarty: >>>>> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. >>>> In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache. >>>> And it's even better to use the same String instance for the lookup which was used to cache the charset. >>> Interesting? thanks for let me know. Presumably, there is an assumption is StandardCharsets is not initialized elsewhere, by another dependency. >> Generally it's safe to assume that StandardCharsets will already be initialized. If it isn't initialized we should consider it an amortized cost. > I'm which case why would the string version be more performant than the version that already takes the Charset? Doesn't the string version need to do a lookup? > String version has the cache mechanism of charset -> CharsetDe/Encoder, so if cache hits, you don't need to have String->Charset lookup. We don't cache the "external" charset though for de/encode(Charset ...), so we always need to create a "new" CharsetDe/Encoder everytime the de/encode() method gets invoked. -Sherman From stevenschlansker at gmail.com Thu Apr 10 18:21:24 2014 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Thu, 10 Apr 2014 11:21:24 -0700 Subject: UUID.compareTo broken? In-Reply-To: <6E659508-7CC6-4906-AABB-59D511B4D728@oracle.com> References: <9473DBFE-49BF-4AC9-B290-9F7D56B09A24@oracle.com> <20A90CCF-FE95-4CAE-8596-BA717D71C133@oracle.com> <99E17723-83AB-43FC-BA63-E1700C8C8889@oracle.com> <59FFB1A3-1B99-4018-A7C4-AD8ED3A95C4A@oracle.com> <6E659508-7CC6-4906-AABB-59D511B4D728@oracle.com> Message-ID: <523D8111-F650-4F8C-B2B1-7C4DC6E24922@gmail.com> On Apr 9, 2014, at 2:21 AM, Paul Sandoz wrote: > On Apr 8, 2014, at 9:15 PM, Mike Duigou wrote: > > That seems a terribly broken usage of UUID for 128 bit numbers or a pair of signed 64 bit numbers :-) > > Part of me thinks we should not be supporting such broken usage. Might be worth getting some usage data from grepcode or maven central. > I?m guilty of doing this at a point in the past. We used it to intermix multiple sources of data - a few that used ?long? IDs and a few that used ?real? UUIDs. We took prefixes that had flags never generated by UUID libraries (the ?reserved for compatibility with Microsoft? ones IIRC) and slapped those with a long to make pseudo-UUIDs. That way everything was a UUID and we were guaranteed to never see collisions within our dataset. We never expected them to give sensible meanings to the various getters e.g. timestamp() but we did expect the UUID class to work generally. We never relied on any particular ordering. > >>>> We could provide static methods to return appropriate comparators for version 1 and version 2 UUIDs--I've actually written them before for other projects. >>>> >>> >>> It would be nice to just have one compareTo that does the right thing based of the UUID types being compared. >> >> If it were up to me only the time and DCE UUIDs would be comparable, there's no ordering relationship for other versions. > > I think it is fine for random UUIDs to be comparable with each other. > > >> The comparators I've considered adding would only allow comparisons within the same version. > > Yes, although for a general comparator the primary sort key could be the version value. +1 to a ?sort first by version then version-specific ordering? ? it gives you the best of both worlds IMO. I think the natural ordering for UUIDs must be able to create an ordering over all possible UUIDs, no matter the version or even if it is valid or not. If you read UUIDs from an external source you have no way to understand what version they are or aren?t. Imagine a process that loads data from a database or text file into a TreeMap - it would be awful if a change in the UUID generation scheme on the far side caused the Comparator you used to no longer function. From brian.burkhalter at oracle.com Thu Apr 10 18:32:23 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Apr 2014 11:32:23 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <5346E18D.3000703@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <300C2A27-3E1E-4373-ADB9-B4D29ABC72A9@oracle.com> <97B2F738-286C-46C5-A0DF-5221491314C5@oracle.com> <5346E18D.3000703@oracle.com> Message-ID: <11558F90-87F6-4D71-A2BE-6BFC9AD1594A@oracle.com> Here?s an updated version with the encoder also modified for symmetry. Brian On Apr 10, 2014, at 11:23 AM, Xueming Shen wrote: > String version has the cache mechanism of charset -> CharsetDe/Encoder, so if > cache hits, you don't need to have String->Charset lookup. > > We don't cache the "external" charset though for de/encode(Charset ...), so we > always need to create a "new" CharsetDe/Encoder everytime the de/encode() > method gets invoked. From brian.burkhalter at oracle.com Thu Apr 10 18:34:47 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Apr 2014 11:34:47 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <11558F90-87F6-4D71-A2BE-6BFC9AD1594A@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <300C2A27-3E1E-4373-ADB9-B4D29ABC72A9@oracle.com> <97B2F738-286C-46C5-A0DF-5221491314C5@oracle.com> <5346E18D.3000703@oracle.com> <11558F90-87F6-4D71-A2BE-6BFC9AD1594A@oracle.com> Message-ID: Would have been nice had I included the link: http://cr.openjdk.java.net/~bpb/8039474/webrev.01/ Brian On Apr 10, 2014, at 11:32 AM, Brian Burkhalter wrote: > Here?s an updated version with the encoder also modified for symmetry. From mike.duigou at oracle.com Thu Apr 10 18:38:53 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 10 Apr 2014 11:38:53 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <97B2F738-286C-46C5-A0DF-5221491314C5@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <300C2A27-3E1E-4373-ADB9-B4D29ABC72A9@oracle.com> <97B2F738-286C-46C5-A0DF-5221491314C5@oracle.com> Message-ID: <5E48E92D-0167-480C-89A7-28A15BC361D0@oracle.com> On Apr 10 2014, at 11:08 , Chris Hegarty wrote: > >> On 10 Apr 2014, at 18:40, Mike Duigou wrote: >> >> >>> On Apr 10 2014, at 03:21 , Chris Hegarty wrote: >>> >>>> On 10 Apr 2014, at 11:03, Ulf Zibis wrote: >>>> >>>> Hi Chris, >>>> >>>> Am 10.04.2014 11:04, schrieb Chris Hegarty: >>>>> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. >>>> >>>> In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache. >>>> And it's even better to use the same String instance for the lookup which was used to cache the charset. >>> >>> Interesting? thanks for let me know. Presumably, there is an assumption is StandardCharsets is not initialized elsewhere, by another dependency. >> >> Generally it's safe to assume that StandardCharsets will already be initialized. If it isn't initialized we should consider it an amortized cost. > > I'm which case why would the string version be more performant than the version that already takes the Charset? Doesn't the string version need to do a lookup? There is a cache in StringCoder that is only used in the byte[] getBytes(String charsetName) but not in the byte[] getBytes(Charset charset) case. The rationale in StringCodding::decode(Charset cs, byte[] ba, int off, int len) may need to be revisited as it is certainly surprising that the string constant charset name usage is faster than the CharSet constant. Mike From xueming.shen at oracle.com Thu Apr 10 18:50:19 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 10 Apr 2014 11:50:19 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <5E48E92D-0167-480C-89A7-28A15BC361D0@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <300C2A27-3E1E-4373-ADB9-B4D29ABC72A9@oracle.com> <97B2F738-286C-46C5-A0DF-5221491314C5@oracle.com> <5E48E92D-0167-480C-89A7-28A15BC361D0@oracle.com> Message-ID: <5346E7EB.1090708@oracle.com> On 04/10/2014 11:38 AM, Mike Duigou wrote: > On Apr 10 2014, at 11:08 , Chris Hegarty wrote: > >>> On 10 Apr 2014, at 18:40, Mike Duigou wrote: >>> >>> >>>> On Apr 10 2014, at 03:21 , Chris Hegarty wrote: >>>> >>>>> On 10 Apr 2014, at 11:03, Ulf Zibis wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> Am 10.04.2014 11:04, schrieb Chris Hegarty: >>>>>> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. >>>>> In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache. >>>>> And it's even better to use the same String instance for the lookup which was used to cache the charset. >>>> Interesting? thanks for let me know. Presumably, there is an assumption is StandardCharsets is not initialized elsewhere, by another dependency. >>> Generally it's safe to assume that StandardCharsets will already be initialized. If it isn't initialized we should consider it an amortized cost. >> I'm which case why would the string version be more performant than the version that already takes the Charset? Doesn't the string version need to do a lookup? > There is a cache in StringCoder that is only used in the byte[] getBytes(String charsetName) but not in the byte[] getBytes(Charset charset) case. The rationale in StringCodding::decode(Charset cs, byte[] ba, int off, int len) may need to be revisited as it is certainly surprising that the string constant charset name usage is faster than the CharSet constant. It's a surprising :-) In theory you can't cache the de/encoder of a charset from external world, as the same charset might return a different de/encoder next time. So it is decided to not cache the de/encoder for a coming charset back then. It might be reasonable to cache those from the StandardCharsets though. -Sherman > Mike From chris.hegarty at oracle.com Thu Apr 10 19:03:16 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Apr 2014 20:03:16 +0100 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <5346E7EB.1090708@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <300C2A27-3E1E-4373-ADB9-B4D29ABC72A9@oracle.com> <97B2F738-286C-46C5-A0DF-5221491314C5@oracle.com> <5E48E92D-0167-480C-89A7-28A15BC361D0@oracle.com> <5346E7EB.1090708@oracle.com> Message-ID: <807F5B4F-F3D9-4F19-B423-D24D20B5E3C6@oracle.com> On 10 Apr 2014, at 19:50, Xueming Shen wrote: > On 04/10/2014 11:38 AM, Mike Duigou wrote: >> On Apr 10 2014, at 11:08 , Chris Hegarty wrote: >> >>>> On 10 Apr 2014, at 18:40, Mike Duigou wrote: >>>> >>>> >>>>> On Apr 10 2014, at 03:21 , Chris Hegarty wrote: >>>>> >>>>>> On 10 Apr 2014, at 11:03, Ulf Zibis wrote: >>>>>> >>>>>> Hi Chris, >>>>>> >>>>>> Am 10.04.2014 11:04, schrieb Chris Hegarty: >>>>>>> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. >>>>>> In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache. >>>>>> And it's even better to use the same String instance for the lookup which was used to cache the charset. >>>>> Interesting? thanks for let me know. Presumably, there is an assumption is StandardCharsets is not initialized elsewhere, by another dependency. >>>> Generally it's safe to assume that StandardCharsets will already be initialized. If it isn't initialized we should consider it an amortized cost. >>> I'm which case why would the string version be more performant than the version that already takes the Charset? Doesn't the string version need to do a lookup? >> There is a cache in StringCoder that is only used in the byte[] getBytes(String charsetName) but not in the byte[] getBytes(Charset charset) case. The rationale in StringCodding::decode(Charset cs, byte[] ba, int off, int len) may need to be revisited as it is certainly surprising that the string constant charset name usage is faster than the CharSet constant. > > It's a surprising :-) In theory you can't cache the de/encoder of a charset from > external world, as the same charset might return a different de/encoder next > time. So it is decided to not cache the de/encoder for a coming charset back > then. It might be reasonable to cache those from the StandardCharsets though. I would say that it is more than reasonable. ;-) And it is surprising to me too that this usage is not as fast as a constant string. -Chris. > > -Sherman > > > > >> Mike > From mandy.chung at oracle.com Thu Apr 10 19:07:31 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Apr 2014 12:07:31 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <63ACE430-1ADB-4514-816E-0536C10A3D15@oracle.com> Message-ID: <5346EBF3.1010404@oracle.com> On 4/10/14 11:05 AM, Mike Duigou wrote: > "Isn't all this sun.misc stuff going go away soon anyway?" <-- wishful thinking We use them in our implementation and can't go away but at least access will be denied with module boundary enforcement. Mandy From xueming.shen at oracle.com Thu Apr 10 19:17:22 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 10 Apr 2014 12:17:22 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <807F5B4F-F3D9-4F19-B423-D24D20B5E3C6@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <300C2A27-3E1E-4373-ADB9-B4D29ABC72A9@oracle.com> <97B2F738-286C-46C5-A0DF-5221491314C5@oracle.com> <5E48E92D-0167-480C-89A7-28A15BC361D0@oracle.com> <5346E7EB.1090708@oracle.com> <807F5B4F-F3D9-4F19-B423-D24D20B5E3C6@oracle.com> Message-ID: <5346EE42.10006@oracle.com> On 04/10/2014 12:03 PM, Chris Hegarty wrote: > On 10 Apr 2014, at 19:50, Xueming Shen wrote: > >> On 04/10/2014 11:38 AM, Mike Duigou wrote: >>> On Apr 10 2014, at 11:08 , Chris Hegarty wrote: >>> >>>>> On 10 Apr 2014, at 18:40, Mike Duigou wrote: >>>>> >>>>> >>>>>> On Apr 10 2014, at 03:21 , Chris Hegarty wrote: >>>>>> >>>>>>> On 10 Apr 2014, at 11:03, Ulf Zibis wrote: >>>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> Am 10.04.2014 11:04, schrieb Chris Hegarty: >>>>>>>> Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. >>>>>>> In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets object is higher than the lookup of an existing object in the cache. >>>>>>> And it's even better to use the same String instance for the lookup which was used to cache the charset. >>>>>> Interesting? thanks for let me know. Presumably, there is an assumption is StandardCharsets is not initialized elsewhere, by another dependency. >>>>> Generally it's safe to assume that StandardCharsets will already be initialized. If it isn't initialized we should consider it an amortized cost. >>>> I'm which case why would the string version be more performant than the version that already takes the Charset? Doesn't the string version need to do a lookup? >>> There is a cache in StringCoder that is only used in the byte[] getBytes(String charsetName) but not in the byte[] getBytes(Charset charset) case. The rationale in StringCodding::decode(Charset cs, byte[] ba, int off, int len) may need to be revisited as it is certainly surprising that the string constant charset name usage is faster than the CharSet constant. >> It's a surprising :-) In theory you can't cache the de/encoder of a charset from >> external world, as the same charset might return a different de/encoder next >> time. So it is decided to not cache the de/encoder for a coming charset back >> then. It might be reasonable to cache those from the StandardCharsets though. > I would say that it is more than reasonable. ;-) And it is surprising to me too that this usage is not as fast as a constant string. > Charset.equals() does explicitly mention "same canonical name" as below /** * Tells whether or not this object is equal to another. * *

Two charsets are equal if, and only if, they have the same canonical * names. A charset is never equal to any other type of object.

* * @return true if, and only if, this charset is equal to the * given object */ But it is very reasonable :-) to assume someone might pass in a home-made charset implementation with the same canonical name as the one in our/jdk charset repository. Then we have another debate on which one should be used in this case. -Sherman From mandy.chung at oracle.com Thu Apr 10 19:24:26 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Apr 2014 12:24:26 -0700 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <300C2A27-3E1E-4373-ADB9-B4D29ABC72A9@oracle.com> <97B2F738-286C-46C5-A0DF-5221491314C5@oracle.com> <5346E18D.3000703@oracle.com> <11558F90-87F6-4D71-A2BE-6BFC9AD1594A@oracle.com> Message-ID: <5346EFEA.7090001@oracle.com> On 4/10/14 11:34 AM, Brian Burkhalter wrote: > Would have been nice had I included the link: > > http://cr.openjdk.java.net/~bpb/8039474/webrev.01/ Brian - thanks for getting this fixed. Looks good to me. I reviewed the fix for JDK-8036848 and missed the subtle compatibility issue (thanks to Sherman for catching it). I think it's good to adjust this fix as it was intended to fix the deprecation warning that should not cause any behavioral change, as Sherman explains. thanks Mandy From Ulf.Zibis at CoSoCo.de Thu Apr 10 19:26:20 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 10 Apr 2014 21:26:20 +0200 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <5346B6C6.2000908@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <53467211.8070405@CoSoCo.de> <5346B6C6.2000908@oracle.com> Message-ID: <5346F05C.6010604@CoSoCo.de> Am 10.04.2014 17:20, schrieb Xueming Shen: > Looks fine. Personally I would prefer the "canonicalized/real" name "ISO-8859-1" though. Yep, using the canonical name guarantees best performance for the charset lookup. BTW, where are these links gone: Bug 100092 -- Speed-up FastCharsetProvider Bug 100095 -- Avoid 2-step lookup in sun.nio.cs charset providers Bug 100098 -- Make sun.nio.cs.* charset objects light-weight -Ulf From tim.bell at oracle.com Thu Apr 10 19:53:53 2014 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 10 Apr 2014 19:53:53 +0000 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <5346F05C.6010604@CoSoCo.de> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <53467211.8070405@CoSoCo.de> <5346B6C6.2000908@oracle.com> <5346F05C.6010604@CoSoCo.de> Message-ID: <5346F6D1.2050203@oracle.com> On 04/10/14 19:26, Ulf Zibis wrote: > BTW, where are these links gone: This part of the question I can handle. The six digit Bug numbers came from the legacy OpenJDK bugzilla instance. Before it was shut down, those bug reports were transferred to JBS. In the process, they were assigned new JDK-nnnnnnn bug numbers, so you will be able to view them on the new system: > Bug 100092 -- Speed-up FastCharsetProvider > New URL: https://bugs.openjdk.java.net/browse/JDK-6790402 > Bug 100095 -- Avoid 2-step lookup in sun.nio.cs charset providers > New URL: https://bugs.openjdk.java.net/browse/JDK-6850361 > Bug 100098 -- Make sun.nio.cs.* charset objects light-weight > New URL: https://bugs.openjdk.java.net/browse/JDK-6862158 In general, if you saved an old Bugzilla ID (six digits, for example 100092), you should be able to find it in JBS by visiting this URL: https://bugs.openjdk.java.net/issues/?jql= And doing a simple search for the string "id=100092" Hope this helps- Tim Bell From brian.burkhalter at oracle.com Thu Apr 10 20:45:02 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Apr 2014 13:45:02 -0700 Subject: PING! Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> <53307892.4020805@gmail.com> Message-ID: <1E0F511F-4A17-4A88-9D63-83A2154FDC6D@oracle.com> Second day back from vacation so I guess it?s time to beat this horse again ? As there was no response to the message included below I am simply re-posting it. Thanks, Brian On Mar 25, 2014, at 7:19 AM, Brian Burkhalter wrote: > On Mar 25, 2014, at 1:58 AM, Paul Sandoz wrote: > >> This is another example of a stable variable. >> >> I would like to re-iterate my scepticism that such changes are necessary in this case (i am not sure if it is possible to create a benchmark that could better exacerbate the concurrent overlap of calls to layoutChars). But, i do agree the discussion has been useful and interesting. > > I am happy either to leave the toString() code as it is or to change it to the variant with toStringSlow(). There is however other cleanup in the patch to consider. So it would be good to get consensus on the two points: > > 1) Change toString() to variant using toStringSlow() or leave it as-is. > 2) Change non-toString() code as indicated in the patch or leave it as-is. > > If ?as-is? is the answer in both cases, then it?s simply a matter of resolving the enhancement as ?not an issue.? > > Thanks, > > Brian From Ulf.Zibis at CoSoCo.de Thu Apr 10 21:27:55 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 10 Apr 2014 23:27:55 +0200 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <5346F6D1.2050203@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <53467211.8070405@CoSoCo.de> <5346B6C6.2000908@oracle.com> <5346F05C.6010604@CoSoCo.de> <5346F6D1.2050203@oracle.com> Message-ID: <53470CDB.1040306@CoSoCo.de> Am 10.04.2014 21:53, schrieb Tim Bell: > On 04/10/14 19:26, Ulf Zibis wrote: >> BTW, where are these links gone: > > This part of the question I can handle. > > The six digit Bug numbers came from the legacy OpenJDK bugzilla instance. > > Before it was shut down, those bug reports were transferred to JBS. In the process, they were > assigned new JDK-nnnnnnn bug numbers, so you will be able to view them on the new system: > > In general, if you saved an old Bugzilla ID (six digits, for example 100092), you should be able > to find it in JBS by visiting this URL: > > https://bugs.openjdk.java.net/issues/?jql= > > And doing a simple search for the string "id=100092" > > > Hope this helps- Much thanks Tim. But where are the original attachments e.g. webrevs, patches ? -Ulf From brian.burkhalter at oracle.com Thu Apr 10 23:24:10 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Apr 2014 16:24:10 -0700 Subject: JDK 9 RFR of 8035427: Math.random() JavaDoc: missing maximum returned value Message-ID: Hello, This is a minor amplification of information already contained in the javadoc. Issue: https://bugs.openjdk.java.net/browse/JDK-8035427 Patch: http://cr.openjdk.java.net/~bpb/8035427/webrev.00/ This is a doc-only change. If acceptable, a CCC request would I expect need to be submitted and approved. Thanks, Brian From david.x.li at oracle.com Thu Apr 10 23:36:50 2014 From: david.x.li at oracle.com (David Li) Date: Thu, 10 Apr 2014 16:36:50 -0700 Subject: RFR (JAXP): 8037259: Xerces Update: XPointer update Message-ID: <53472B12.2070809@oracle.com> Hi, This is an update from Xerces XPointer. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8037259. Webrevs: http://cr.openjdk.java.net/~dli/8037259/webrev/ Existing tests: JAXP SQE and unit tests passed. No new tests were added because most of the changes are minor and do not add any new functionality. Changes in ElementSchemePointer.java are already covered in JAXP unit test xinclude/Bug6794483Test.java. Thanks, David From peter.levart at gmail.com Fri Apr 11 06:54:45 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 11 Apr 2014 08:54:45 +0200 Subject: UUID.compareTo broken? In-Reply-To: <523D8111-F650-4F8C-B2B1-7C4DC6E24922@gmail.com> References: <9473DBFE-49BF-4AC9-B290-9F7D56B09A24@oracle.com> <20A90CCF-FE95-4CAE-8596-BA717D71C133@oracle.com> <99E17723-83AB-43FC-BA63-E1700C8C8889@oracle.com> <59FFB1A3-1B99-4018-A7C4-AD8ED3A95C4A@oracle.com> <6E659508-7CC6-4906-AABB-59D511B4D728@oracle.com> <523D8111-F650-4F8C-B2B1-7C4DC6E24922@gmail.com> Message-ID: <534791B5.3000105@gmail.com> On 04/10/2014 08:21 PM, Steven Schlansker wrote: > On Apr 9, 2014, at 2:21 AM, Paul Sandoz wrote: > >> On Apr 8, 2014, at 9:15 PM, Mike Duigou wrote: >> >> That seems a terribly broken usage of UUID for 128 bit numbers or a pair of signed 64 bit numbers :-) >> >> Part of me thinks we should not be supporting such broken usage. Might be worth getting some usage data from grepcode or maven central. >> > I?m guilty of doing this at a point in the past. We used it to intermix multiple sources of data - a few that used ?long? IDs and a few that used ?real? UUIDs. We took prefixes that had flags never generated by UUID libraries (the ?reserved for compatibility with Microsoft? ones IIRC) and slapped those with a long to make pseudo-UUIDs. That way everything was a UUID and we were guaranteed to never see collisions within our dataset. > > We never expected them to give sensible meanings to the various getters e.g. timestamp() but we did expect the UUID class to work generally. > We never relied on any particular ordering. > >>>>> We could provide static methods to return appropriate comparators for version 1 and version 2 UUIDs--I've actually written them before for other projects. >>>>> >>>> It would be nice to just have one compareTo that does the right thing based of the UUID types being compared. >>> If it were up to me only the time and DCE UUIDs would be comparable, there's no ordering relationship for other versions. >> I think it is fine for random UUIDs to be comparable with each other. >> >> >>> The comparators I've considered adding would only allow comparisons within the same version. >> Yes, although for a general comparator the primary sort key could be the version value. > +1 to a ?sort first by version then version-specific ordering? ? it gives you the best of both worlds IMO. > > I think the natural ordering for UUIDs must be able to create an ordering over all possible UUIDs, no matter the version or even if it is valid or not. If you read UUIDs from an external source you have no way to understand what version they are or aren?t. Imagine a process that loads data from a database or text file into a TreeMap - it would be awful if a change in the UUID generation scheme on the far side caused the Comparator you used to no longer function. > Hi, Code that relies on UUIDs to have a "natural" order, say "chronological", is relying on being given the particular type of UUIDs that have the time built-in. When given mixed-type or non-time-based UUIDs, such code will break. The purpose of UUID schemes is generating globally unique identifiers, not interpreting them. Various types exist just because it's practical to generate UUIDs differently in different contexts. Programs should not try to extract business information from UUIDs (except probably for hunting down virus authors: http://en.wikipedia.org/wiki/Melissa_%28computer_virus%29). So I think a good general-purpose compareTo() method should try to discourage such usage for example by reversing the bits of the UUID value before comparing. This would also make algorithms that order UUIDs for facilitating quick access (B-Tree, Red-Black-Tree, ...) happier. Try the following benchmark (with options: -wi 5 -i 5 -t 1 -f 1): public class TreeMapInsertionBench { private static final int N = 100000; @GenerateMicroBenchmark() @BenchmarkMode(Mode.AverageTime) public static void testTreeMapSequentialInsert(BlackHole bh) { Map map = new TreeMap<>(); for (int i = 0; i < N; i++) { map.put(new Integer(i), Boolean.TRUE); } bh.consume(map); } @GenerateMicroBenchmark() @BenchmarkMode(Mode.AverageTime) public static void testTreeMapReversedBitsInsert(BlackHole bh) { Map map = new TreeMap<>(); for (int i = 0; i < N; i++) { map.put(new Integer(Integer.reverse(i)), Boolean.TRUE); } bh.consume(map); } } ...and the results will be: Benchmark Mode Samples Mean Mean error Units o.s.TreeMapInsertionBench.testTreeMapReversedBitsInsert avgt 5 8.208 0.100 ms/op o.s.TreeMapInsertionBench.testTreeMapSequentialInsert avgt 5 10.498 1.164 ms/op That's just an opinion. Regards, Peter From paul.sandoz at oracle.com Fri Apr 11 07:30:03 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 Apr 2014 09:30:03 +0200 Subject: JDK 9 RFR of 8035427: Math.random() JavaDoc: missing maximum returned value In-Reply-To: References: Message-ID: On Apr 11, 2014, at 1:24 AM, Brian Burkhalter wrote: > Hello, > > This is a minor amplification of information already contained in the javadoc. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8035427 > Patch: http://cr.openjdk.java.net/~bpb/8035427/webrev.00/ > > This is a doc-only change. If acceptable, a CCC request would I expect need to be submitted and approved. > Does such a non-normative change require a CCC? I think the changes could be placed under an @apiNote tag. It's a shame that java.util.Random is explicitly referenced, as there is no wiggle room to improve the PRNG characteristics Paul. From ivan.gerasimov at oracle.com Fri Apr 11 08:01:38 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 11 Apr 2014 12:01:38 +0400 Subject: RFR: [8039396] NPE when writing a class descriptor object to a custom ObjectOutputStream Message-ID: <5347A162.3080909@oracle.com> Hello everybody! ObjectStreamClass#forClass() function is allowed to return null, if the local VM does not have the corresponding local class. Because of that, NPE can be encountered during serialization through a subclass of ObjectOutputStream. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8039396 WEBREV: http://cr.openjdk.java.net/~igerasim/8039396/0/webrev/ Sincerely yours, Ivan From paul.sandoz at oracle.com Fri Apr 11 10:35:13 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 Apr 2014 12:35:13 +0200 Subject: UUID.compareTo broken? In-Reply-To: <534791B5.3000105@gmail.com> References: <9473DBFE-49BF-4AC9-B290-9F7D56B09A24@oracle.com> <20A90CCF-FE95-4CAE-8596-BA717D71C133@oracle.com> <99E17723-83AB-43FC-BA63-E1700C8C8889@oracle.com> <59FFB1A3-1B99-4018-A7C4-AD8ED3A95C4A@oracle.com> <6E659508-7CC6-4906-AABB-59D511B4D728@oracle.com> <523D8111-F650-4F8C-B2B1-7C4DC6E24922@gmail.com> <534791B5.3000105@gmail.com> Message-ID: <75990B2E-9DF1-486D-B57C-F00EBCED62F0@oracle.com> On Apr 11, 2014, at 8:54 AM, Peter Levart wrote: > > Hi, > > Code that relies on UUIDs to have a "natural" order, say "chronological", is relying on being given the particular type of UUIDs that have the time built-in. When given mixed-type or non-time-based UUIDs, such code will break. The purpose of UUID schemes is generating globally unique identifiers, not interpreting them. Various types exist just because it's practical to generate UUIDs differently in different contexts. Good point, the bias is towards producers, but still i can imagine time-based UUIDs are quite useful for consumers and i think implicitly such users would reasonably expect them to be ordered in some manner based on the time. > Programs should not try to extract business information from UUIDs (except probably for hunting down virus authors: http://en.wikipedia.org/wiki/Melissa_%28computer_virus%29). So I think a good general-purpose compareTo() method should try to discourage such usage for example by reversing the bits of the UUID value before comparing. This would also make algorithms that order UUIDs for facilitating quick access (B-Tree, Red-Black-Tree, ...) happier. > Interesting, i suppose if those N values are randomly shuffled then added it may get close to reversed bit result, i should probably try it :-) Paul. From peter.levart at gmail.com Fri Apr 11 10:47:52 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 11 Apr 2014 12:47:52 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: <53454916.5010104@oracle.com> References: <532C7A30.6060904@oracle.com> <532E2113.6040903@gmail.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.co! m> <53454916.5010104@oracle.com> Message-ID: <5347C858.6030003@gmail.com> On 04/09/2014 03:20 PM, roger riggs wrote: > Hi Peter, > > On a related topic, the request to be able to destroy a Process and > all of its children > might also want to used the group pid to be able to identify all of > the children. Hi Roger, This would require each child spawned by Process API to be assigned it's own process group. The grandchildren would inherit this process group. You could then send KILL/TERM signal to a process group in order to destroy the child and all it's descendants (that did not change the process group in the meanwhile). But we can only group processes for one purpose, since a process can only belong to one group at a time. To send signals to a (sub-)tree of processes, the child-parent relationship is more natural to follow, I think, since no waiting/blocking is involved in sending the signals, so enumerating and iterating is appropriate. Waiting on children is another purpose where process group(s) could be employed and I think they would be better spent this way. I think I now have a picture of how this could work. See my reply to Martin. Regards, Peter > > Roger > > > On 4/9/2014 2:08 AM, Peter Levart wrote: >> Hi Martin, >> >> As you might have seen in my later reply to Roger, there's still hope >> on that front: setpgid() + wait(-pgid, ...) might be the answer. I'm >> exploring in that direction. Shells are doing it, so why can't JDK? >> >> It's a little trickier for Process API, since I imagine that shells >> form a group of processes from a pipeline which is known in-advance >> while Process API will have to add processes to the live group >> dynamically. So some races will have to be resolved, but I think it's >> doable. >> >> Stay tuned. >> >> Regards, Peter >> >> On 04/08/2014 07:48 PM, Martin Buchholz wrote: >>> Peter, thank you very much for your deep analysis. >>> >>> TIL and am horrified: signals on Unix are not queued, not even if >>> you specify SA_SIGINFO. Providing siginfo turns signals into proper >>> "messages" each with unique content, and it is unacceptable to >>> simply drop some (Especially when proper queueing seems required for >>> so-called real-time signals), but at least the Linux kernel does so >>> very deliberately. 45 years later, we are still fighting with >>> unreliable Unix signals... >>> >>> We can't call waitpid(WAIT_ANY, ) because we can only wait for >>> processes owned by the j.l.Process subsystem. We can't override >>> libc functions like waitpid because the JVM may be a "guest" in some >>> other process. >>> >>> I don't know of any public examples, but it is reasonable to add a >>> JVM to a previously pure native code application, similarly to the >>> way tcl or lua is often used to provide a higher-level safer >>> programming api to native code, and some programs at Google use this >>> strategy. >>> >>> What problem are we actually trying to solve? The army of reaper >>> threads is ugly, but the inefficiency is greatly mitigated by the >>> use of small explicit stack sizes. Redoing the process code is >>> always risky, as we have already seen in this thread. >>> >>> Maintaining a single child helper process which spawns all the >>> (grand)child processes seems reasonable, although it would create a >>> permanent intermediate entry in the process table (pstree?) which >>> might confuse some sysadmin scripts. Is it worth it? >>> >> > From volker.simonis at gmail.com Fri Apr 11 13:46:08 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Apr 2014 15:46:08 +0200 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Jonathan, thank you for fixing all the remaining issues. From my point of view this change looks good now. @Masayoshi: can I please get a final approval from you for pushing the change? I also want to downport this to 8u-dev but I don't think that's a big deal as this only touches AX code. Thank you and best regards, Volker On Thu, Apr 10, 2014 at 11:44 AM, Jonathan Lu wrote: > Hi Volker, > > Thanks a lot for your comments, I've made another patch, > > http://cr.openjdk.java.net/~luchsh/JDK-8Masayoshi034220.v4/ > > > On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis wrote: > >> Hi Jonathan, >> >> sorry, but I found a few more issues: >> >> - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise >> somebody could easily crash the VM by specifying a TZ with more than >> 100 characters. >> > > Right, I've fix it by using strncpy, and also updated another usage of > strcmp(). > > > >> >> - you can delete the lines 871-872 because the variables are actually >> not used and you can also remove the handling for "timezone == 0" >> because that is actually done in getGMTOffsetID() anyway. >> > > Nice catch, have deleted those in latest patch. > > >> >> - could you please avoid the usage of strtok. It is not intended for >> usage in a multithreaded environment (see for example "man strtok" on >> AIX). strtok_r is probably overkill, but you could use for example >> strchr. >> > > I've changed it to strtok_r in this patch, > although strtok was only used once here, it may still impact other > threads. > > >> did you check the build on Windows? >> > > Yes, both patches got built on Windows. > > >> >> Thank you and best regards, >> Volker >> >> >> On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu >> wrote: >> > Hi Volker, Masayoshi, >> > >> > I made another patch which fixed the problems mentioned in last mail, >> > >> > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ >> > >> > Could you pls help to take a look? >> > >> > Many thanks >> > Jonathan >> > >> > >> > >> > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu > > >> > wrote: >> >> >> >> Hi Volker, >> >> >> >> >> >> On 2014?04?02? 23:07, Volker Simonis wrote: >> >> >> >> Hi Jonathan, >> >> >> >> thanks for updating the change. Please find my comments inline: >> >> >> >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu > > >> >> wrote: >> >> >> >> Hi Volker, Masayoshi, >> >> >> >> Thanks a lot for your review, here's the updated patch, could you pls >> take >> >> a >> >> look? >> >> >> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ >> >> >> >> >> >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis < >> volker.simonis at gmail.com> >> >> wrote: >> >> >> >> Hi Jonathan, >> >> >> >> thanks for doing this change. Please find some comments below: >> >> >> >> 1. please update the copyright year to 2014 in every file you touch >> >> >> >> Updated in new patch. >> >> >> >> 2. in CopyFiles.gmk you can simplify the change by joining the windows >> >> and aix cases because on Windows OPENJDK_TARGET_OS is the same like >> >> OPENJDK_TARGET_OS_API_DIR. So you can write: >> >> >> >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) >> >> >> >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib >> >> >> >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings >> >> $(call install-file) >> >> >> >> COPY_FILES += $(LIBDIR)/tzmappings >> >> >> >> endif >> >> >> >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is >> >> 'solaris' >> >> as I observed on my AIX box, >> >> solaris/lib is not the directory where tzmappings was stored for AIX. >> >> So I'm keeping this change, please fix me if I was wrong about the >> config. >> >> >> >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the >> >> construction of TZMAPPINGS_SRC as shown in the code snippet above. >> >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX >> >> and that should be just enough here. >> >> >> >> >> >> That's right, let me try that and also build/test on Windows platform. >> >> >> >> >> >> 3. regarding the changes proposed by Masayoshi: I agree that we should >> >> put the AIX timezone mapping code in its own function, but I don't >> >> think that getPlatformTimeZoneID() would be the right place. As far as >> >> I understand, getPlatformTimeZoneID() is used to get a platform time >> >> zone id if the environment variable "TZ" is not set. I don't know a >> >> way how this could be done on AIX (@Jonathan: maybe you know?). If >> >> there would be a way to get the time zone from some system files or >> >> so, then we should put this code into the AIX version of >> >> getPlatformTimeZoneID(). >> >> >> >> I guess we may try to use /etc/envrionment file, which is basic setting >> >> for >> >> all processes, >> >> see >> >> >> >> >> http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm >> >> The implementation of getPlatformTimeZoneID() has been updated. >> >> >> >> That's good! >> >> >> >> But the current AIX code contributed by Jonathan, actually uses the >> >> time zone id from the "TZ" environment variable and just maps it to a >> >> Java compatible time zone id. So I'd suggest to refactor this code >> >> into a function like for example "static const char* >> >> mapPlatformToJavaTimzone(const char* tz)" and call that from >> >> findJavaTZ_md(). I think that would make the code easier to >> >> understand. >> >> >> >> Agree, and have split the code into a separate static method to do the >> >> mapping work. >> >> >> >> Good. But there's still one error in findJavaTZ_md(): >> >> >> >> 706 #ifdef _AIX >> >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); >> >> 708 #endif >> >> >> >> This should read: >> >> >> >> 706 #ifdef _AIX >> >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz); >> >> 708 #endif >> >> >> >> because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came >> >> from getPlatformTimeZoneID(). >> >> >> >> >> >> Right, but with the second approach, there may be a minor memory leak >> >> here, >> >> as javatz was not freed before being overwritten on AIX. will post >> another >> >> patch on this soon. >> >> >> >> >> >> With the above fixed I'll push this one we get one more review from a >> >> reviewer (I'm currently not an official reviewer). >> >> >> >> Regards, >> >> Volker >> >> >> >> >> >> @Masayoshi: what do you think, would you agree with such a solution. >> >> >> >> 4. I agree with Masayoshi that you should use the existing >> >> getGMTOffsetID() >> >> >> >> Updated in new patch to eliminate duplication. >> >> >> >> 5. Please notice that your change breaks all Unix builds except AIX >> >> because of: >> >> >> >> 759 } >> >> 760 tzerr: >> >> 761 if (javatz == NULL) { >> >> 762 time_t offset; >> >> ... >> >> 782 } >> >> 783 #endif >> >> >> >> I think that should read: >> >> >> >> 759 >> >> 760 tzerr: >> >> 761 if (javatz == NULL) { >> >> 762 time_t offset; >> >> ... >> >> 782 } >> >> 783 #endif >> >> 784 } >> >> >> >> Refactoring the code in an extra function will make that error more >> >> evident anyway. >> >> >> >> But please always build at least on one different platform (i.e. >> >> Linux) to prevent such errors in the future. >> >> >> >> My fault, sorry for the failure, should take no chance after any manual >> >> alteration. >> >> >> >> Regards, >> >> Volker >> >> >> >> >> >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu >> >> wrote: >> >> >> >> Hi Jonathan, >> >> >> >> The AIX specific code looks OK to me. But I'd suggest the code be moved >> >> to >> >> getPlatformTimeZoneID() for AIX, which just returns NULL currently. >> Also >> >> there's a function for producing a fallback ID in "GMT?hh:mm", >> >> getGMTOffsetID() which can be called in tzerr. >> >> >> >> Thanks, >> >> Masayoshi >> >> >> >> >> >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: >> >> >> >> Hi ppc-aix-port-dev, core-libs-dev, >> >> >> >> Here's a patch for JDK-8034220, >> >> >> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ >> >> >> >> It is trying to add the a more complete timezone mapping mechanism for >> >> AIX >> >> platform. >> >> the changes are primarily based on IBM's commercial JDK code, which >> >> includes: >> >> >> >> - A new timezone mapping file added under directory jdk/src/aix/lib/ >> >> - Code to parse above config file, changed file is >> >> src/solaris/native/java/util/TimeZone_md.c >> >> - And also makefile change in make/CopyFiles.gmk to copy the config >> >> file >> >> >> >> Could you pls help to review and give comments ? >> >> >> >> Cheers >> >> - Jonathan >> >> >> >> Many thanks >> >> Jonathan >> >> >> >> Regards >> >> Jonathan >> > >> > >> > > Regards > Jonathan > From roger.riggs at oracle.com Fri Apr 11 14:45:36 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 11 Apr 2014 10:45:36 -0400 Subject: ProcessReaper: single thread reaper In-Reply-To: <5347C858.6030003@gmail.com> References: <532C7A30.6060904@oracle.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.co! m> <53454916.5010104@oracle.! com> <5347C858.6030003@gmai! l.com> Message-ID: <53480010.9030201@oracle.com> Hi Peter, Understood, but didn't want ignore another requested feature. Iterating over children is workable but I'm not clear whether if an intermediate child dies/is killed that its children are reparented up the tree. If for one reason or another a grandchild is reparented to pid 1 then it would not be discovered by iteration. No Zombies please. Thanks, Roger On 4/11/2014 6:47 AM, Peter Levart wrote: > On 04/09/2014 03:20 PM, roger riggs wrote: >> Hi Peter, >> >> On a related topic, the request to be able to destroy a Process and >> all of its children >> might also want to used the group pid to be able to identify all of >> the children. > > Hi Roger, > > This would require each child spawned by Process API to be assigned > it's own process group. The grandchildren would inherit this process > group. You could then send KILL/TERM signal to a process group in > order to destroy the child and all it's descendants (that did not > change the process group in the meanwhile). > > But we can only group processes for one purpose, since a process can > only belong to one group at a time. To send signals to a (sub-)tree of > processes, the child-parent relationship is more natural to follow, I > think, since no waiting/blocking is involved in sending the signals, > so enumerating and iterating is appropriate. > > Waiting on children is another purpose where process group(s) could be > employed and I think they would be better spent this way. > > I think I now have a picture of how this could work. See my reply to > Martin. > > Regards, Peter > >> >> Roger >> >> >> On 4/9/2014 2:08 AM, Peter Levart wrote: >>> Hi Martin, >>> >>> As you might have seen in my later reply to Roger, there's still >>> hope on that front: setpgid() + wait(-pgid, ...) might be the >>> answer. I'm exploring in that direction. Shells are doing it, so why >>> can't JDK? >>> >>> It's a little trickier for Process API, since I imagine that shells >>> form a group of processes from a pipeline which is known in-advance >>> while Process API will have to add processes to the live group >>> dynamically. So some races will have to be resolved, but I think >>> it's doable. >>> >>> Stay tuned. >>> >>> Regards, Peter >>> >>> On 04/08/2014 07:48 PM, Martin Buchholz wrote: >>>> Peter, thank you very much for your deep analysis. >>>> >>>> TIL and am horrified: signals on Unix are not queued, not even if >>>> you specify SA_SIGINFO. Providing siginfo turns signals into >>>> proper "messages" each with unique content, and it is unacceptable >>>> to simply drop some (Especially when proper queueing seems required >>>> for so-called real-time signals), but at least the Linux kernel >>>> does so very deliberately. 45 years later, we are still fighting >>>> with unreliable Unix signals... >>>> >>>> We can't call waitpid(WAIT_ANY, ) because we can only wait for >>>> processes owned by the j.l.Process subsystem. We can't override >>>> libc functions like waitpid because the JVM may be a "guest" in >>>> some other process. >>>> >>>> I don't know of any public examples, but it is reasonable to add a >>>> JVM to a previously pure native code application, similarly to the >>>> way tcl or lua is often used to provide a higher-level safer >>>> programming api to native code, and some programs at Google use >>>> this strategy. >>>> >>>> What problem are we actually trying to solve? The army of reaper >>>> threads is ugly, but the inefficiency is greatly mitigated by the >>>> use of small explicit stack sizes. Redoing the process code is >>>> always risky, as we have already seen in this thread. >>>> >>>> Maintaining a single child helper process which spawns all the >>>> (grand)child processes seems reasonable, although it would create a >>>> permanent intermediate entry in the process table (pstree?) which >>>> might confuse some sysadmin scripts. Is it worth it? >>>> >>> >> > From peter.levart at gmail.com Fri Apr 11 14:52:03 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 11 Apr 2014 16:52:03 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> Message-ID: <53480193.7050803@gmail.com> On 04/09/2014 07:02 PM, Martin Buchholz wrote: > > > > On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart > wrote: > > Hi Martin, > > As you might have seen in my later reply to Roger, there's still > hope on that front: setpgid() + wait(-pgid, ...) might be the > answer. I'm exploring in that direction. Shells are doing it, so > why can't JDK? > > It's a little trickier for Process API, since I imagine that > shells form a group of processes from a pipeline which is known > in-advance while Process API will have to add processes to the > live group dynamically. So some races will have to be resolved, > but I think it's doable. > > > This is a clever idea, and it's arguably better to design subprocesses > so they live in separate process groups (emacs does that), but: > Every time you create a process group, you change the effect of a user > signal like Ctrl-C, since it's sent to only one group. > Maybe propagate signals to the subprocess group? It's starting to get > complicated... > Hi Martin, Yes, shells send Ctrl-C (SIGINT) and other signals initiated by terminal to a (foreground) process group. A process group is formed from a pipeline of interconnected processes. Each pipeline is considered to be a separate "job", hence shells call this feature "job-control". Child processes by default inherit process group from it's parent, so children born with Process API (and their children) inherit the process group from the JVM process. Considering the intentions of shell job-controll, is propagating SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by Process API desirable? If so, then yes, handling those signals in JVM and propagating them to current process group that contains all children spawned by Process API and their descendants would have to be performed by JVM. That problem would certainly have to be addressed. But let's first see what I found out about sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), etc... waitpid(-pgid, ...) alone seems to not be enough for our task. Mainly because a process can re-assign it's group and join some other group. I don't know if this is a situation that occurs in real world, but imagine if we have one live child process in a process group pgid1 and no unwaited exited children. If we issue: waitpid(-pgid1, &status, 0); Then this call blocks, because at the time it was given, there were >0 child processes in the pgid1 group and none of them has exited yet. Now if this one child process changes it's process group with: setpgid(0, pgid2); Then the waitpid call in the parent does not return (maybe this is a bug in Linux?) although there are no more live child processes in the pgid1 group any more. Even when this child exits, the call to waitpid does not return, since this child is not in the group we are waiting for when it exits. If all our children "escape" the group in such way, the tread doing waiting will never unblock. To solve this, we can employ signal handlers. In a signal handler for SIGCHLD signal we can invoke: waitpid(-pgid1, &status, WNOHANG); // non-blocking call ...in loop until it either returns (0) which means that there're no more unwaited exited children in the group at the momen or (-1) with errno == ECHILD, which means that there're no more children in the queried group any more - the group does not exist any more. Since signal handler is invoked whith SIGCHLD being masked and there is one bit of pending signal state in the kernel, no child exit can be "skipped" this way. Unless the child "escapes" by changing it's group. I don't know of a plausible reason for a program to change it's process group. If a program executing as JVM child wants to become a background daemon it usually behaves as follows: - fork()s a grand-child and then exit()s (so we get notified via signal and waitpid(-pgid, ...) successfully for it's exitstatus) - the grand-child then changes it's session and group (becomes session and group leader), closes file descriptors, etc. The responsibility for waiting on the grand-child daemon is transferred to the init process (pid=1) since the grand-child becomes an orphan (has no parent). Ignoring this still unsolved problem of possible ill-behaved child program that changes it's process group, I started constructing a proof-of-concept prototype. What I will do in the prototype is start throwing IllegalStateException from the methods of the Process API that pertain to such children. I think this is reasonable. Stay tuned, Peter From brian.burkhalter at oracle.com Fri Apr 11 14:56:44 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 11 Apr 2014 07:56:44 -0700 Subject: JDK 9 RFR of 8035427: Math.random() JavaDoc: missing maximum returned value In-Reply-To: References: Message-ID: On Apr 11, 2014, at 12:30 AM, Paul Sandoz wrote: > Does such a non-normative change require a CCC? I think the changes could be placed under an @apiNote tag. Personally I would think not but was prepared to submit one. > It's a shame that java.util.Random is explicitly referenced, as there is no wiggle room to improve the PRNG characteristics I noticed that too and agree. Thanks, Brian From paul.sandoz at oracle.com Fri Apr 11 15:09:52 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 Apr 2014 17:09:52 +0200 Subject: JDK 9 RFR of 8035427: Math.random() JavaDoc: missing maximum returned value In-Reply-To: References: Message-ID: On Apr 11, 2014, at 4:56 PM, Brian Burkhalter wrote: > > On Apr 11, 2014, at 12:30 AM, Paul Sandoz wrote: > >> Does such a non-normative change require a CCC? I think the changes could be placed under an @apiNote tag. > > Personally I would think not but was prepared to submit one. > Me neither. Stick an @apiNote on it and i think it's good to go :-) @apiNote As the largest... Paul. From peter.levart at gmail.com Fri Apr 11 15:16:33 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 11 Apr 2014 17:16:33 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: <53480010.9030201@oracle.com> References: <532C7A30.6060904@oracle.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.co! m> <53454916.5010104@oracle.! com> <5347C858.6030003@gmai! l.com> <53480010.9030201@oracle.com> Message-ID: <53480751.6000304@gmail.com> On 04/11/2014 04:45 PM, roger riggs wrote: > Hi Peter, > > Understood, but didn't want ignore another requested feature. > Iterating over children is workable but I'm not clear whether if an > intermediate child > dies/is killed that its children are reparented up the tree. If a parent dies, all it's immediate children are reparented to pid 1 (init process). init process is responsible for waiting on their exits. That's why there're no zombies left behind such children when they exit - the init process collects them. > If for one reason or another a grandchild is reparented to pid 1 then > it would not > be discovered by iteration. That's right. If a JVM child dies, the tree view of processes, which is rooted in the JVM process, looses an entire branch. This usually happens for processes that wish to become background daemons. They fork() a child and exit(). Their child becomes a daemon. You won't be able to ever see this daemon PID in the tree if you're not quick enough. The daemons also change their session and group, so tracking them by group id is not possible either. > No Zombies please. No Cranberries ;-) Regards, Peter > > Thanks, Roger > > > On 4/11/2014 6:47 AM, Peter Levart wrote: >> On 04/09/2014 03:20 PM, roger riggs wrote: >>> Hi Peter, >>> >>> On a related topic, the request to be able to destroy a Process and >>> all of its children >>> might also want to used the group pid to be able to identify all of >>> the children. >> >> Hi Roger, >> >> This would require each child spawned by Process API to be assigned >> it's own process group. The grandchildren would inherit this process >> group. You could then send KILL/TERM signal to a process group in >> order to destroy the child and all it's descendants (that did not >> change the process group in the meanwhile). >> >> But we can only group processes for one purpose, since a process can >> only belong to one group at a time. To send signals to a (sub-)tree >> of processes, the child-parent relationship is more natural to >> follow, I think, since no waiting/blocking is involved in sending the >> signals, so enumerating and iterating is appropriate. >> >> Waiting on children is another purpose where process group(s) could >> be employed and I think they would be better spent this way. >> >> I think I now have a picture of how this could work. See my reply to >> Martin. >> >> Regards, Peter >> >>> >>> Roger >>> >>> >>> On 4/9/2014 2:08 AM, Peter Levart wrote: >>>> Hi Martin, >>>> >>>> As you might have seen in my later reply to Roger, there's still >>>> hope on that front: setpgid() + wait(-pgid, ...) might be the >>>> answer. I'm exploring in that direction. Shells are doing it, so >>>> why can't JDK? >>>> >>>> It's a little trickier for Process API, since I imagine that shells >>>> form a group of processes from a pipeline which is known in-advance >>>> while Process API will have to add processes to the live group >>>> dynamically. So some races will have to be resolved, but I think >>>> it's doable. >>>> >>>> Stay tuned. >>>> >>>> Regards, Peter >>>> >>>> On 04/08/2014 07:48 PM, Martin Buchholz wrote: >>>>> Peter, thank you very much for your deep analysis. >>>>> >>>>> TIL and am horrified: signals on Unix are not queued, not even if >>>>> you specify SA_SIGINFO. Providing siginfo turns signals into >>>>> proper "messages" each with unique content, and it is unacceptable >>>>> to simply drop some (Especially when proper queueing seems >>>>> required for so-called real-time signals), but at least the Linux >>>>> kernel does so very deliberately. 45 years later, we are still >>>>> fighting with unreliable Unix signals... >>>>> >>>>> We can't call waitpid(WAIT_ANY, ) because we can only wait for >>>>> processes owned by the j.l.Process subsystem. We can't override >>>>> libc functions like waitpid because the JVM may be a "guest" in >>>>> some other process. >>>>> >>>>> I don't know of any public examples, but it is reasonable to add a >>>>> JVM to a previously pure native code application, similarly to the >>>>> way tcl or lua is often used to provide a higher-level safer >>>>> programming api to native code, and some programs at Google use >>>>> this strategy. >>>>> >>>>> What problem are we actually trying to solve? The army of reaper >>>>> threads is ugly, but the inefficiency is greatly mitigated by the >>>>> use of small explicit stack sizes. Redoing the process code is >>>>> always risky, as we have already seen in this thread. >>>>> >>>>> Maintaining a single child helper process which spawns all the >>>>> (grand)child processes seems reasonable, although it would create >>>>> a permanent intermediate entry in the process table (pstree?) >>>>> which might confuse some sysadmin scripts. Is it worth it? >>>>> >>>> >>> >> > From roger.riggs at oracle.com Fri Apr 11 16:49:49 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 11 Apr 2014 12:49:49 -0400 Subject: ProcessReaper: single thread reaper In-Reply-To: <53480193.7050803@gmail.com> References: <532C7A30.6060904@oracle.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> Message-ID: <53481D2D.10702@oracle.com> Hi Peter, We do know the PIDs of the processes that we care about but are unwilling to pay the cost of waiting for them individually. For the escapees, Process could resort to an individual thread invoking waitpid(n). Thanks, Roger On 4/11/2014 10:52 AM, Peter Levart wrote: > On 04/09/2014 07:02 PM, Martin Buchholz wrote: >> >> >> >> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart > > wrote: >> >> Hi Martin, >> >> As you might have seen in my later reply to Roger, there's still >> hope on that front: setpgid() + wait(-pgid, ...) might be the >> answer. I'm exploring in that direction. Shells are doing it, so >> why can't JDK? >> >> It's a little trickier for Process API, since I imagine that >> shells form a group of processes from a pipeline which is known >> in-advance while Process API will have to add processes to the >> live group dynamically. So some races will have to be resolved, >> but I think it's doable. >> >> >> This is a clever idea, and it's arguably better to design >> subprocesses so they live in separate process groups (emacs does >> that), but: >> Every time you create a process group, you change the effect of a >> user signal like Ctrl-C, since it's sent to only one group. >> Maybe propagate signals to the subprocess group? It's starting to >> get complicated... >> > > Hi Martin, > > Yes, shells send Ctrl-C (SIGINT) and other signals initiated by > terminal to a (foreground) process group. A process group is formed > from a pipeline of interconnected processes. Each pipeline is > considered to be a separate "job", hence shells call this feature > "job-control". Child processes by default inherit process group from > it's parent, so children born with Process API (and their children) > inherit the process group from the JVM process. Considering the > intentions of shell job-controll, is propagating > SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by Process > API desirable? If so, then yes, handling those signals in JVM and > propagating them to current process group that contains all children > spawned by Process API and their descendants would have to be > performed by JVM. That problem would certainly have to be addressed. > But let's first see what I found out about sigaction(SIGCHLD, ...), > setpgid(pid, pgid), waitpid(-pgid, ...), etc... > > waitpid(-pgid, ...) alone seems to not be enough for our task. Mainly > because a process can re-assign it's group and join some other group. > I don't know if this is a situation that occurs in real world, but > imagine if we have one live child process in a process group pgid1 and > no unwaited exited children. If we issue: > > waitpid(-pgid1, &status, 0); > > Then this call blocks, because at the time it was given, there were >0 > child processes in the pgid1 group and none of them has exited yet. > Now if this one child process changes it's process group with: > > setpgid(0, pgid2); > > Then the waitpid call in the parent does not return (maybe this is a > bug in Linux?) although there are no more live child processes in the > pgid1 group any more. Even when this child exits, the call to waitpid > does not return, since this child is not in the group we are waiting > for when it exits. If all our children "escape" the group in such way, > the tread doing waiting will never unblock. To solve this, we can > employ signal handlers. In a signal handler for SIGCHLD signal we can > invoke: > > waitpid(-pgid1, &status, WNOHANG); // non-blocking call > > ...in loop until it either returns (0) which means that there're no > more unwaited exited children in the group at the momen or (-1) with > errno == ECHILD, which means that there're no more children in the > queried group any more - the group does not exist any more. Since > signal handler is invoked whith SIGCHLD being masked and there is one > bit of pending signal state in the kernel, no child exit can be > "skipped" this way. Unless the child "escapes" by changing it's group. > I don't know of a plausible reason for a program to change it's > process group. If a program executing as JVM child wants to become a > background daemon it usually behaves as follows: > > - fork()s a grand-child and then exit()s (so we get notified via > signal and waitpid(-pgid, ...) successfully for it's exitstatus) > - the grand-child then changes it's session and group (becomes session > and group leader), closes file descriptors, etc. The responsibility > for waiting on the grand-child daemon is transferred to the init > process (pid=1) since the grand-child becomes an orphan (has no parent). > > Ignoring this still unsolved problem of possible ill-behaved child > program that changes it's process group, I started constructing a > proof-of-concept prototype. What I will do in the prototype is start > throwing IllegalStateException from the methods of the Process API > that pertain to such children. I think this is reasonable. > > Stay tuned, > > Peter > > From mike.duigou at oracle.com Fri Apr 11 19:22:32 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 11 Apr 2014 12:22:32 -0700 Subject: RFR: 8035284: (xs) Remove redundant null initialization Message-ID: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> Hello all; This is a simple cleanup changeset that removes redundant initialization of fields to null from a number of collection classes. These field initializations may seem cheap but they do have a cost: - For volatile fields there is a measurable cost on some benchmarks for these extra initializations. - Larger byte code in methods. - For transient fields the initialization is misleading since it does not occur on deserialization. https://bugs.openjdk.java.net/browse/JDK-8035284 http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ Redundant null initializations in other components/packages will be handled in separate issues. Mike From lance.andersen at oracle.com Fri Apr 11 19:23:53 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Fri, 11 Apr 2014 15:23:53 -0400 Subject: RFR (JAXP): 8037259: Xerces Update: XPointer update In-Reply-To: <53472B12.2070809@oracle.com> References: <53472B12.2070809@oracle.com> Message-ID: Overall it looks ok. I think you will get some unchecked warnings from com/sun/org/apache/xerces/internal/xpointer/XPointerHandler.java Any reason not to address this for your HashMap and ArrayList? 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 Apr 10, 2014, at 7:36 PM, David Li wrote: > Hi, > > This is an update from Xerces XPointer. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8037259. > > Webrevs: http://cr.openjdk.java.net/~dli/8037259/webrev/ > > Existing tests: JAXP SQE and unit tests passed. No new tests were added because most of the changes are minor and do not add any new functionality. Changes in ElementSchemePointer.java are already covered in JAXP unit test xinclude/Bug6794483Test.java. > > Thanks, > David From lance.andersen at oracle.com Fri Apr 11 19:25:48 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Fri, 11 Apr 2014 15:25:48 -0400 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> Message-ID: <89B6E24C-7FEE-4415-A23B-430C03137ECF@oracle.com> Looks fine mike 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 Apr 11, 2014, at 3:22 PM, Mike Duigou wrote: > Hello all; > > This is a simple cleanup changeset that removes redundant initialization of fields to null from a number of collection classes. These field initializations may seem cheap but they do have a cost: > > - For volatile fields there is a measurable cost on some benchmarks for these extra initializations. > > - Larger byte code in methods. > > - For transient fields the initialization is misleading since it does not occur on deserialization. > > https://bugs.openjdk.java.net/browse/JDK-8035284 > http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ > > Redundant null initializations in other components/packages will be handled in separate issues. > > Mike From aleksey.shipilev at oracle.com Fri Apr 11 19:30:58 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 11 Apr 2014 23:30:58 +0400 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> Message-ID: <534842F2.6090805@oracle.com> On 04/11/2014 11:22 PM, Mike Duigou wrote: > https://bugs.openjdk.java.net/browse/JDK-8035284 > http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ This! Thumbs up. > Redundant null initializations in other components/packages will be handled in separate issues. I also remember seeing cases where the field initializers basically dubbed the constructor (I think it was in JAXB/P). Not sure if you can find these automatically. -Aleksey. From martinrb at google.com Fri Apr 11 19:57:13 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Apr 2014 12:57:13 -0700 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> Message-ID: It's surprising that javac does not eliminate the redundant initializations to null. Initializing to null has documentation value (suggesting that the constructor will not assign a value; null is a "valid" value). How about fixing javac instead? On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou wrote: > Hello all; > > This is a simple cleanup changeset that removes redundant initialization > of fields to null from a number of collection classes. These field > initializations may seem cheap but they do have a cost: > > - For volatile fields there is a measurable cost on some benchmarks for > these extra initializations. > > - Larger byte code in methods. > > - For transient fields the initialization is misleading since it does not > occur on deserialization. > > https://bugs.openjdk.java.net/browse/JDK-8035284 > http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ > > Redundant null initializations in other components/packages will be > handled in separate issues. > > Mike From mike.duigou at oracle.com Fri Apr 11 20:04:15 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 11 Apr 2014 13:04:15 -0700 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> Message-ID: <7376D6A7-0475-4BEB-A427-EB71BA4F7DF3@oracle.com> Apparently javac did at elide the "extraneous" null initialization at one point and it was deemed to have been contrary to point #4 of the procedure in JLS 12.5 (http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.5-220-D) Mike On Apr 11 2014, at 12:57 , Martin Buchholz wrote: > It's surprising that javac does not eliminate the redundant initializations to null. Initializing to null has documentation value (suggesting that the constructor will not assign a value; null is a "valid" value). How about fixing javac instead? > > > On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou wrote: > Hello all; > > This is a simple cleanup changeset that removes redundant initialization of fields to null from a number of collection classes. These field initializations may seem cheap but they do have a cost: > > - For volatile fields there is a measurable cost on some benchmarks for these extra initializations. > > - Larger byte code in methods. > > - For transient fields the initialization is misleading since it does not occur on deserialization. > > https://bugs.openjdk.java.net/browse/JDK-8035284 > http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ > > Redundant null initializations in other components/packages will be handled in separate issues. > > Mike > From chris.hegarty at oracle.com Fri Apr 11 20:07:39 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Apr 2014 21:07:39 +0100 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> Message-ID: <3726C41D-31F3-4D2F-B746-4A976611C2AD@oracle.com> This look good to me. I'm really happy to see these do away. I'll help clean up other areas too. -Chris > On 11 Apr 2014, at 20:22, Mike Duigou wrote: > > Hello all; > > This is a simple cleanup changeset that removes redundant initialization of fields to null from a number of collection classes. These field initializations may seem cheap but they do have a cost: > > - For volatile fields there is a measurable cost on some benchmarks for these extra initializations. > > - Larger byte code in methods. > > - For transient fields the initialization is misleading since it does not occur on deserialization. > > https://bugs.openjdk.java.net/browse/JDK-8035284 > http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ > > Redundant null initializations in other components/packages will be handled in separate issues. > > Mike From chris.hegarty at oracle.com Fri Apr 11 20:09:31 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Apr 2014 21:09:31 +0100 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: <7376D6A7-0475-4BEB-A427-EB71BA4F7DF3@oracle.com> References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> <7376D6A7-0475-4BEB-A427-EB71BA4F7DF3@oracle.com> Message-ID: <416789C9-F133-4198-BE77-DD5ABC67DE9D@oracle.com> > On 11 Apr 2014, at 21:04, Mike Duigou wrote: > > Apparently javac did at elide the "extraneous" null initialization at one point and it was deemed to have been contrary to point #4 of the procedure in JLS 12.5 (http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.5-220-D) I remember talking to Maurizio about this a few years ago. I think he mentioned something similar. -Chris. > > Mike > > >> On Apr 11 2014, at 12:57 , Martin Buchholz wrote: >> >> It's surprising that javac does not eliminate the redundant initializations to null. Initializing to null has documentation value (suggesting that the constructor will not assign a value; null is a "valid" value). How about fixing javac instead? >> >> >> On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou wrote: >> Hello all; >> >> This is a simple cleanup changeset that removes redundant initialization of fields to null from a number of collection classes. These field initializations may seem cheap but they do have a cost: >> >> - For volatile fields there is a measurable cost on some benchmarks for these extra initializations. >> >> - Larger byte code in methods. >> >> - For transient fields the initialization is misleading since it does not occur on deserialization. >> >> https://bugs.openjdk.java.net/browse/JDK-8035284 >> http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ >> >> Redundant null initializations in other components/packages will be handled in separate issues. >> >> Mike > From mike.duigou at oracle.com Fri Apr 11 20:11:19 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 11 Apr 2014 13:11:19 -0700 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: <416789C9-F133-4198-BE77-DD5ABC67DE9D@oracle.com> References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> <7376D6A7-0475-4BEB-A427-EB71BA4F7DF3@oracle.com> <416789C9-F133-4198-BE77-DD5ABC67DE9D@oracle.com> Message-ID: <194BB8B0-5020-4704-9D59-C20832C25603@oracle.com> I and others have tried to track down the compiler issue in which this change was made. If anyone can point us in the right direction it would be nice to reference that issue. Mike On Apr 11 2014, at 13:09 , Chris Hegarty wrote: > >> On 11 Apr 2014, at 21:04, Mike Duigou wrote: >> >> Apparently javac did at elide the "extraneous" null initialization at one point and it was deemed to have been contrary to point #4 of the procedure in JLS 12.5 (http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.5-220-D) > > I remember talking to Maurizio about this a few years ago. I think he mentioned something similar. > > -Chris. > >> >> Mike >> >> >>> On Apr 11 2014, at 12:57 , Martin Buchholz wrote: >>> >>> It's surprising that javac does not eliminate the redundant initializations to null. Initializing to null has documentation value (suggesting that the constructor will not assign a value; null is a "valid" value). How about fixing javac instead? >>> >>> >>> On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou wrote: >>> Hello all; >>> >>> This is a simple cleanup changeset that removes redundant initialization of fields to null from a number of collection classes. These field initializations may seem cheap but they do have a cost: >>> >>> - For volatile fields there is a measurable cost on some benchmarks for these extra initializations. >>> >>> - Larger byte code in methods. >>> >>> - For transient fields the initialization is misleading since it does not occur on deserialization. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8035284 >>> http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ >>> >>> Redundant null initializations in other components/packages will be handled in separate issues. >>> >>> Mike >> From brian.burkhalter at oracle.com Fri Apr 11 20:31:26 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 11 Apr 2014 13:31:26 -0700 Subject: JDK 9 RFR of 8035427: Math.random() JavaDoc: missing maximum returned value In-Reply-To: References: Message-ID: On Apr 11, 2014, at 8:09 AM, Paul Sandoz wrote: > > On Apr 11, 2014, at 4:56 PM, Brian Burkhalter wrote: > >> >> On Apr 11, 2014, at 12:30 AM, Paul Sandoz wrote: >> >>> Does such a non-normative change require a CCC? I think the changes could be placed under an @apiNote tag. >> >> Personally I would think not but was prepared to submit one. >> > > Me neither. Stick an @apiNote on it and i think it's good to go :-) > > @apiNote > As the largest? Pushed with suggested annotation; webrev updated in place: http://cr.openjdk.java.net/~bpb/8035427/webrev.00/ Thanks, Brian From martinrb at google.com Fri Apr 11 20:38:43 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Apr 2014 13:38:43 -0700 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: <194BB8B0-5020-4704-9D59-C20832C25603@oracle.com> References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> <7376D6A7-0475-4BEB-A427-EB71BA4F7DF3@oracle.com> <416789C9-F133-4198-BE77-DD5ABC67DE9D@oracle.com> <194BB8B0-5020-4704-9D59-C20832C25603@oracle.com> Message-ID: I see now that the semantics of private Foo foo = null; and private Foo foo; are different, because in the first case foo may have been set to non-null by other code textually "left" to the initialization to null. Conceptually a variable explicitly initialized to null is initialized twice - first the initialization to null promised by the JVM, and then the explicit initialization to null. The compiler may be able to elide the assignment, but only by doing an analysis of all possible executions. And for volatile fields, it is reasonable (if you squint) to expect that a true volatile store is performed even if the VM can prove that "this" does not escape the constructor. Change approved! Still, it makes me sad. We will also cleanse jsr166 sources of these redundant initializations. On Fri, Apr 11, 2014 at 1:11 PM, Mike Duigou wrote: > I and others have tried to track down the compiler issue in which this > change was made. If anyone can point us in the right direction it would be > nice to reference that issue. > > Mike > > On Apr 11 2014, at 13:09 , Chris Hegarty wrote: > > > > >> On 11 Apr 2014, at 21:04, Mike Duigou wrote: > >> > >> Apparently javac did at elide the "extraneous" null initialization at > one point and it was deemed to have been contrary to point #4 of the > procedure in JLS 12.5 ( > http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.5-220-D > ) > > > > I remember talking to Maurizio about this a few years ago. I think he > mentioned something similar. > > > > -Chris. > > > >> > >> Mike > >> > >> > >>> On Apr 11 2014, at 12:57 , Martin Buchholz > wrote: > >>> > >>> It's surprising that javac does not eliminate the redundant > initializations to null. Initializing to null has documentation value > (suggesting that the constructor will not assign a value; null is a "valid" > value). How about fixing javac instead? > >>> > >>> > >>> On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou > wrote: > >>> Hello all; > >>> > >>> This is a simple cleanup changeset that removes redundant > initialization of fields to null from a number of collection classes. These > field initializations may seem cheap but they do have a cost: > >>> > >>> - For volatile fields there is a measurable cost on some benchmarks > for these extra initializations. > >>> > >>> - Larger byte code in methods. > >>> > >>> - For transient fields the initialization is misleading since it does > not occur on deserialization. > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8035284 > >>> http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ > >>> > >>> Redundant null initializations in other components/packages will be > handled in separate issues. > >>> > >>> Mike > >> > > From xueming.shen at oracle.com Fri Apr 11 22:42:59 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 11 Apr 2014 15:42:59 -0700 Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider Message-ID: <53486FF3.6020203@oracle.com> Hi, Please help review this changeset to upgrade the zip filesystem provider implementation from demo to a supported provider. Back in JDK7 we created a demo file system provider for zip/jar files. It is shipped in two forms, one as a binary under lib/ext that works "out of the box" to support zip/jar file access as a nio filesystem, the second is source form with a BSD license. We are now proposing to drop it as a demo and instead just "release" it as a filesystem provider that shipped with the JDK. issue: https://bugs.openjdk.java.net/browse/JDK-8038500 webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev Thanks! -Sherman From david.x.li at oracle.com Fri Apr 11 23:09:26 2014 From: david.x.li at oracle.com (David Li) Date: Fri, 11 Apr 2014 16:09:26 -0700 Subject: RFR (JAXP): 8037259: Xerces Update: XPointer update In-Reply-To: References: <53472B12.2070809@oracle.com> Message-ID: <53487626.3000009@oracle.com> Hi Lance, Good catch. I have uploaded a fixed review. I had forgotten about this since Xerces is at JDK 1.4, while we had agreed to move to JDK 1.7. It's good to get these lint warnings fixed now since we are planning to do a large scale fix later on. I also made a similar fix in ElementSchemePointer.java. If you see anything else, then let me know. http://cr.openjdk.java.net/~dli/8037259/webrev/ Thanks, David On 4/11/2014 12:23 PM, Lance @ Oracle wrote: > Overall it looks ok. > > I think you will get some unchecked warnings from > com/sun/org/apache/xerces/internal/xpointer/XPointerHandler.java > > Any reason not to address this for your HashMap and ArrayList? > > 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 Apr 10, 2014, at 7:36 PM, David Li > wrote: > >> Hi, >> >> This is an update from Xerces XPointer. For details, please refer >> to: https://bugs.openjdk.java.net/browse/JDK-8037259. >> >> Webrevs: http://cr.openjdk.java.net/~dli/8037259/webrev/ >> >> >> Existing tests: JAXP SQE and unit tests passed. No new tests were >> added because most of the changes are minor and do not add any new >> functionality. Changes in ElementSchemePointer.java are already >> covered in JAXP unit test xinclude/Bug6794483Test.java. >> >> Thanks, >> David From lance.andersen at oracle.com Fri Apr 11 23:21:09 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 11 Apr 2014 19:21:09 -0400 Subject: RFR (JAXP): 8037259: Xerces Update: XPointer update In-Reply-To: <53487626.3000009@oracle.com> References: <53472B12.2070809@oracle.com> <53487626.3000009@oracle.com> Message-ID: <5BDFA0A8-5A53-4C05-A66D-C77C3B068C49@oracle.com> Hi David, Looks better. You should be able to clean this up further by using the diamond operator. Once you do this, you are good to go. Best Lance On Apr 11, 2014, at 7:09 PM, David Li wrote: > Hi Lance, > > Good catch. I have uploaded a fixed review. I had forgotten about this since Xerces is at JDK 1.4, while we had agreed to move to JDK 1.7. It's good to get these lint warnings fixed now since we are planning to do a large scale fix later on. I also made a similar fix in ElementSchemePointer.java. If you see anything else, then let me know. > > http://cr.openjdk.java.net/~dli/8037259/webrev/ > > Thanks, > David > > On 4/11/2014 12:23 PM, Lance @ Oracle wrote: >> Overall it looks ok. >> >> I think you will get some unchecked warnings from >> com/sun/org/apache/xerces/internal/xpointer/XPointerHandler.java >> >> Any reason not to address this for your HashMap and ArrayList? >> >> 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 Apr 10, 2014, at 7:36 PM, David Li wrote: >> >>> Hi, >>> >>> This is an update from Xerces XPointer. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8037259. >>> >>> Webrevs: http://cr.openjdk.java.net/~dli/8037259/webrev/ >>> >>> Existing tests: JAXP SQE and unit tests passed. No new tests were added because most of the changes are minor and do not add any new functionality. Changes in ElementSchemePointer.java are already covered in JAXP unit test xinclude/Bug6794483Test.java. >>> >>> Thanks, >>> David > 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 mandy.chung at oracle.com Fri Apr 11 23:29:22 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Apr 2014 16:29:22 -0700 Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider In-Reply-To: <53486FF3.6020203@oracle.com> References: <53486FF3.6020203@oracle.com> Message-ID: <53487AD2.5060203@oracle.com> On 4/11/2014 3:42 PM, Xueming Shen wrote: > > webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev It's good to see the source of the zip provider moved to the jdk repo. You have made some public classes to package-private which is good. I wonder whether a few remaining public classes can be made package-private (e.g. ZipFileAttributes, ZipInfo etc). Is JarFileSystemProvider used anywhere? ZipFileSystemProvider is the only provider listed in the service configuration. Do you mean to make Demo.java as a regression test? basic.sh - I wonder if you can get rid of this shell test. Do Basic, PathOps, ZipFSTester have any relationship? I was thinking if they can be made as individual java test and constructor the input path of zipfs.jar. With zipfs.jar part of the jdk build, it will be found under ${java.home}/lib/ext/zipfs.jar. When we move to modules, this jar file won't exist. It might be better for the tests to create a JAR file (one to share by all zipfs tests) to get ready for modules. Mandy From martinrb at google.com Fri Apr 11 23:37:14 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Apr 2014 16:37:14 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: <53480193.7050803@gmail.com> References: <532C7A30.6060904@oracle.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> Message-ID: Let's step back again and try to check our goals... We could try to optimize the one-reaper-thread-per-subprocess thing. But that is risky, and the cost of what we're doing today is not that high. We could try to implement the feature of killing off an entire subprocess tree. But historically, any kind of behavior change like that has been vetoed. I have tried and failed to make less incompatible changes. We would have to add a new API. The reality is that Java does not give you real access to the underlying OS, and unless there's a seriously heterodox attempt to provide OS-specific extensions, people will have to continue to either write native code or delegate to an OS-savvy subprocess like a perl script. On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart wrote: > On 04/09/2014 07:02 PM, Martin Buchholz wrote: > > > > > On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart wrote: > >> Hi Martin, >> >> As you might have seen in my later reply to Roger, there's still hope on >> that front: setpgid() + wait(-pgid, ...) might be the answer. I'm exploring >> in that direction. Shells are doing it, so why can't JDK? >> >> It's a little trickier for Process API, since I imagine that shells form >> a group of processes from a pipeline which is known in-advance while >> Process API will have to add processes to the live group dynamically. So >> some races will have to be resolved, but I think it's doable. >> > > This is a clever idea, and it's arguably better to design subprocesses > so they live in separate process groups (emacs does that), but: > Every time you create a process group, you change the effect of a user > signal like Ctrl-C, since it's sent to only one group. > Maybe propagate signals to the subprocess group? It's starting to get > complicated... > > > Hi Martin, > > Yes, shells send Ctrl-C (SIGINT) and other signals initiated by terminal > to a (foreground) process group. A process group is formed from a pipeline > of interconnected processes. Each pipeline is considered to be a separate > "job", hence shells call this feature "job-control". Child processes by > default inherit process group from it's parent, so children born with > Process API (and their children) inherit the process group from the JVM > process. Considering the intentions of shell job-controll, is propagating > SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by Process API > desirable? If so, then yes, handling those signals in JVM and propagating > them to current process group that contains all children spawned by Process > API and their descendants would have to be performed by JVM. That problem > would certainly have to be addressed. But let's first see what I found out > about sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), > etc... > > waitpid(-pgid, ...) alone seems to not be enough for our task. Mainly > because a process can re-assign it's group and join some other group. I > don't know if this is a situation that occurs in real world, but imagine if > we have one live child process in a process group pgid1 and no unwaited > exited children. If we issue: > > waitpid(-pgid1, &status, 0); > > Then this call blocks, because at the time it was given, there were >0 > child processes in the pgid1 group and none of them has exited yet. Now if > this one child process changes it's process group with: > > setpgid(0, pgid2); > > Then the waitpid call in the parent does not return (maybe this is a bug > in Linux?) although there are no more live child processes in the pgid1 > group any more. Even when this child exits, the call to waitpid does not > return, since this child is not in the group we are waiting for when it > exits. If all our children "escape" the group in such way, the tread doing > waiting will never unblock. To solve this, we can employ signal handlers. > In a signal handler for SIGCHLD signal we can invoke: > > waitpid(-pgid1, &status, WNOHANG); // non-blocking call > > ...in loop until it either returns (0) which means that there're no more > unwaited exited children in the group at the momen or (-1) with errno == > ECHILD, which means that there're no more children in the queried group any > more - the group does not exist any more. Since signal handler is invoked > whith SIGCHLD being masked and there is one bit of pending signal state in > the kernel, no child exit can be "skipped" this way. Unless the child > "escapes" by changing it's group. I don't know of a plausible reason for a > program to change it's process group. If a program executing as JVM child > wants to become a background daemon it usually behaves as follows: > > - fork()s a grand-child and then exit()s (so we get notified via signal > and waitpid(-pgid, ...) successfully for it's exitstatus) > - the grand-child then changes it's session and group (becomes session and > group leader), closes file descriptors, etc. The responsibility for waiting > on the grand-child daemon is transferred to the init process (pid=1) since > the grand-child becomes an orphan (has no parent). > > Ignoring this still unsolved problem of possible ill-behaved child program > that changes it's process group, I started constructing a proof-of-concept > prototype. What I will do in the prototype is start throwing > IllegalStateException from the methods of the Process API that pertain to > such children. I think this is reasonable. > > Stay tuned, > > Peter > > > From david.x.li at oracle.com Fri Apr 11 23:48:19 2014 From: david.x.li at oracle.com (David Li) Date: Fri, 11 Apr 2014 16:48:19 -0700 Subject: RFR (JAXP): 8037259: Xerces Update: XPointer update In-Reply-To: <5BDFA0A8-5A53-4C05-A66D-C77C3B068C49@oracle.com> References: <53472B12.2070809@oracle.com> <53487626.3000009@oracle.com> <5BDFA0A8-5A53-4C05-A66D-C77C3B068C49@oracle.com> Message-ID: <53487F43.2020102@oracle.com> Got it, updated. Same place: http://cr.openjdk.java.net/~dli/8037259/webrev/ Thanks, David On 4/11/2014 4:21 PM, Lance Andersen wrote: > Hi David, > > Looks better. You should be able to clean this up further by using > the diamond operator. Once you do this, you are good to go. > > Best > Lance > On Apr 11, 2014, at 7:09 PM, David Li > wrote: > >> Hi Lance, >> >> Good catch. I have uploaded a fixed review. I had forgotten about >> this since Xerces is at JDK 1.4, while we had agreed to move to JDK >> 1.7. It's good to get these lint warnings fixed now since we are >> planning to do a large scale fix later on. I also made a similar fix >> in ElementSchemePointer.java. If you see anything else, then let me >> know. >> >> http://cr.openjdk.java.net/~dli/8037259/webrev/ >> >> Thanks, >> David >> >> On 4/11/2014 12:23 PM, Lance @ Oracle wrote: >>> Overall it looks ok. >>> >>> I think you will get some unchecked warnings from >>> com/sun/org/apache/xerces/internal/xpointer/XPointerHandler.java >>> >>> Any reason not to address this for your HashMap and ArrayList? >>> >>> 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 Apr 10, 2014, at 7:36 PM, David Li >> > wrote: >>> >>>> Hi, >>>> >>>> This is an update from Xerces XPointer. For details, please refer >>>> to: https://bugs.openjdk.java.net/browse/JDK-8037259. >>>> >>>> Webrevs: http://cr.openjdk.java.net/~dli/8037259/webrev/ >>>> >>>> >>>> Existing tests: JAXP SQE and unit tests passed. No new tests were >>>> added because most of the changes are minor and do not add any new >>>> functionality. Changes in ElementSchemePointer.java are already >>>> covered in JAXP unit test xinclude/Bug6794483Test.java. >>>> >>>> Thanks, >>>> David >> > > > > 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 lance.andersen at oracle.com Sat Apr 12 00:11:18 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Fri, 11 Apr 2014 20:11:18 -0400 Subject: RFR (JAXP): 8037259: Xerces Update: XPointer update In-Reply-To: <53487F43.2020102@oracle.com> References: <53472B12.2070809@oracle.com> <53487626.3000009@oracle.com> <5BDFA0A8-5A53-4C05-A66D-C77C3B068C49@oracle.com> <53487F43.2020102@oracle.com> Message-ID: <9C2BAC48-83FA-4A8C-BA5A-5AA416AEE1A4@oracle.com> +1 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 Apr 11, 2014, at 7:48 PM, David Li wrote: > Got it, updated. Same place: > http://cr.openjdk.java.net/~dli/8037259/webrev/ > > Thanks, > David > > On 4/11/2014 4:21 PM, Lance Andersen wrote: >> Hi David, >> >> Looks better. You should be able to clean this up further by using the diamond operator. Once you do this, you are good to go. >> >> Best >> Lance >> On Apr 11, 2014, at 7:09 PM, David Li wrote: >> >>> Hi Lance, >>> >>> Good catch. I have uploaded a fixed review. I had forgotten about this since Xerces is at JDK 1.4, while we had agreed to move to JDK 1.7. It's good to get these lint warnings fixed now since we are planning to do a large scale fix later on. I also made a similar fix in ElementSchemePointer.java. If you see anything else, then let me know. >>> >>> http://cr.openjdk.java.net/~dli/8037259/webrev/ >>> >>> Thanks, >>> David >>> >>> On 4/11/2014 12:23 PM, Lance @ Oracle wrote: >>>> Overall it looks ok. >>>> >>>> I think you will get some unchecked warnings from >>>> com/sun/org/apache/xerces/internal/xpointer/XPointerHandler.java >>>> >>>> Any reason not to address this for your HashMap and ArrayList? >>>> >>>> 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 Apr 10, 2014, at 7:36 PM, David Li wrote: >>>> >>>>> Hi, >>>>> >>>>> This is an update from Xerces XPointer. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8037259. >>>>> >>>>> Webrevs: http://cr.openjdk.java.net/~dli/8037259/webrev/ >>>>> >>>>> Existing tests: JAXP SQE and unit tests passed. No new tests were added because most of the changes are minor and do not add any new functionality. Changes in ElementSchemePointer.java are already covered in JAXP unit test xinclude/Bug6794483Test.java. >>>>> >>>>> Thanks, >>>>> David >> >> >> >> >> 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 Alan.Bateman at oracle.com Sat Apr 12 07:20:06 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 12 Apr 2014 08:20:06 +0100 Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider In-Reply-To: <53486FF3.6020203@oracle.com> References: <53486FF3.6020203@oracle.com> Message-ID: <5348E926.604@oracle.com> On 11/04/2014 23:42, Xueming Shen wrote: > Hi, > > Please help review this changeset to upgrade the zip filesystem > provider implementation from > demo to a supported provider. > > Back in JDK7 we created a demo file system provider for zip/jar files. > It is shipped in two forms, > one as a binary under lib/ext that works "out of the box" to support > zip/jar file access as a nio > filesystem, the second is source form with a BSD license. > > We are now proposing to drop it as a demo and instead just "release" > it as a filesystem provider > that shipped with the JDK. > > issue: https://bugs.openjdk.java.net/browse/JDK-8038500 > webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev This looks good. Mandy makes a good point about that only com.sun.nio.zipfs.ZipFileSystemProvider needs to be public. That might avoid having to put com.sun.nio.zipfs on the restricted package list too. On basic.sh then this was originally needed in order to ensure that zipfs.jar was on the class path. Since it in the ext directory then it is not needed so Mandy's point about just moving the @test to the individual tests is good. -Alan. From Alan.Bateman at oracle.com Sat Apr 12 09:53:07 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 12 Apr 2014 10:53:07 +0100 Subject: RFR: JDK-8039751: UTF-8 decoder fails to handle some edge cases correctly In-Reply-To: <5345C0F9.8020601@oracle.com> References: <5345C0F9.8020601@oracle.com> Message-ID: <53490D03.7000802@oracle.com> On 09/04/2014 22:51, Xueming Shen wrote: > Hi, > > Please help review the fix for JDK-8039751. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8039751 > webrev: http://cr.openjdk.java.net/~sherman/8039751/webrev/ > > > This is the corner case (in 4 bytes sequence) we missed when fixing > 7096080 [1]. > The UTF_8 decoder correctly returns the malformed length for some > malformed > 4-byte illegal byte sequence (via Decoder.malformedN(...)), but it > fails to do so if > there is no enough (< 4 bytes) bytes in input buffer (via > isMalfromed4_2(...)) This looks okay to me although I think it would be useful to put in an addition comment or two to make these corner cases a bit easier to understand when looking at this code. -Alan. From mandy.chung at oracle.com Sun Apr 13 02:48:42 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 12 Apr 2014 19:48:42 -0700 Subject: Any native library calling JNI_FindClass from JNI_OnUnload? Message-ID: <5349FB0A.6020204@oracle.com> Does anyone know of a native library whose JNI_OnUnload calls JNI_FindClass? I'm wondering how much existing code out there depends on the existing behavior that is unsupported. During the investigation of JDK-4240589, I found that the implementation JNI_FindClass has a special handling that calls ClassLoader.NativeLibrary.getFromClass method to determine if JNI_FindClass is being called by JNI_OnLoad and JNI_OnUnload directly or indirectly. This special handling makes sense for JNI_OnLoad, i.e. when the native library is loaded, that may call JNI_FindClass. I don't think this should apply to JNI_OnUnload. When a native library is being unloaded, it means that the ClassLoader has become unreachable and GC'ed. When JNI_OnUnloader, there is no guarantee that the class loader still exists for doing any class loading. The JNI spec of JNI_OnUnload [1] also makes it clear: The VM calls JNI_OnUnload when the class loader containing the native library is garbage collected. This function can be used to perform cleanup operations. Because this function is called in an unknown context (such as from a finalizer), the programmer should be conservative on using Java VM services, and refrain from arbitrary Java call-backs. A little more background about this: The current ClassLoader uses finalizer to clean up and unload the native library, if any. I'm considering to replace the finalizer with phantom reference which is generally a good change and discover this VM/JNI/libs dependency. Any data would be appreciated. Mandy [1] http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#JNI_OnUnload From masayoshi.okutsu at oracle.com Mon Apr 14 06:03:17 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 14 Apr 2014 15:03:17 +0900 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: <534B7A25.7070800@oracle.com> Looks good to me. Thanks, Masayoshi On 4/11/2014 10:46 PM, Volker Simonis wrote: > Hi Jonathan, > > thank you for fixing all the remaining issues. From my point of view > this change looks good now. > > @Masayoshi: can I please get a final approval from you for pushing the > change? I also want to downport this to 8u-dev but I don't think > that's a big deal as this only touches AX code. > > Thank you and best regards, > Volker > > On Thu, Apr 10, 2014 at 11:44 AM, Jonathan Lu > > wrote: > > Hi Volker, > > Thanks a lot for your comments, I've made another patch, > > http://cr.openjdk.java.net/~luchsh/JDK-8Masayoshi034220.v4/ > > > > On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis > > wrote: > > Hi Jonathan, > > sorry, but I found a few more issues: > > - please use strncpy instead of strcpy in TimeZone_md.c:798 > otherwise > somebody could easily crash the VM by specifying a TZ with > more than > 100 characters. > > > Right, I've fix it by using strncpy, and also updated another > usage of strcmp(). > > > - you can delete the lines 871-872 because the variables are > actually > not used and you can also remove the handling for "timezone == 0" > because that is actually done in getGMTOffsetID() anyway. > > > Nice catch, have deleted those in latest patch. > > > - could you please avoid the usage of strtok. It is not > intended for > usage in a multithreaded environment (see for example "man > strtok" on > AIX). strtok_r is probably overkill, but you could use for example > strchr. > > > I've changed it to strtok_r in this patch, > although strtok was only used once here, it may still impact > other threads. > > > did you check the build on Windows? > > > Yes, both patches got built on Windows. > > > Thank you and best regards, > Volker > > > On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu > > > wrote: > > Hi Volker, Masayoshi, > > > > I made another patch which fixed the problems mentioned in > last mail, > > > > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ > > > > > Could you pls help to take a look? > > > > Many thanks > > Jonathan > > > > > > > > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu > > > > wrote: > >> > >> Hi Volker, > >> > >> > >> On 2014?04?02? 23:07, Volker Simonis wrote: > >> > >> Hi Jonathan, > >> > >> thanks for updating the change. Please find my comments inline: > >> > >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu > > > >> wrote: > >> > >> Hi Volker, Masayoshi, > >> > >> Thanks a lot for your review, here's the updated patch, > could you pls take > >> a > >> look? > >> > >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ > > >> > >> > >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis > > > >> wrote: > >> > >> Hi Jonathan, > >> > >> thanks for doing this change. Please find some comments below: > >> > >> 1. please update the copyright year to 2014 in every file > you touch > >> > >> Updated in new patch. > >> > >> 2. in CopyFiles.gmk you can simplify the change by joining > the windows > >> and aix cases because on Windows OPENJDK_TARGET_OS is the > same like > >> OPENJDK_TARGET_OS_API_DIR. So you can write: > >> > >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) > >> > >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib > >> > >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings > >> $(call install-file) > >> > >> COPY_FILES += $(LIBDIR)/tzmappings > >> > >> endif > >> > >> I've tried that approach before, but > OPENJDK_TARGET_OS_API_DIR is > >> 'solaris' > >> as I observed on my AIX box, > >> solaris/lib is not the directory where tzmappings was > stored for AIX. > >> So I'm keeping this change, please fix me if I was wrong > about the config. > >> > >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the > >> construction of TZMAPPINGS_SRC as shown in the code > snippet above. > >> OPENJDK_TARGET_OS is "windows" on Windows platforms and > "aix" on AIX > >> and that should be just enough here. > >> > >> > >> That's right, let me try that and also build/test on > Windows platform. > >> > >> > >> 3. regarding the changes proposed by Masayoshi: I agree > that we should > >> put the AIX timezone mapping code in its own function, but > I don't > >> think that getPlatformTimeZoneID() would be the right > place. As far as > >> I understand, getPlatformTimeZoneID() is used to get a > platform time > >> zone id if the environment variable "TZ" is not set. I > don't know a > >> way how this could be done on AIX (@Jonathan: maybe you > know?). If > >> there would be a way to get the time zone from some system > files or > >> so, then we should put this code into the AIX version of > >> getPlatformTimeZoneID(). > >> > >> I guess we may try to use /etc/envrionment file, which is > basic setting > >> for > >> all processes, > >> see > >> > >> > http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm > >> The implementation of getPlatformTimeZoneID() has been > updated. > >> > >> That's good! > >> > >> But the current AIX code contributed by Jonathan, actually > uses the > >> time zone id from the "TZ" environment variable and just > maps it to a > >> Java compatible time zone id. So I'd suggest to refactor > this code > >> into a function like for example "static const char* > >> mapPlatformToJavaTimzone(const char* tz)" and call that from > >> findJavaTZ_md(). I think that would make the code easier to > >> understand. > >> > >> Agree, and have split the code into a separate static > method to do the > >> mapping work. > >> > >> Good. But there's still one error in findJavaTZ_md(): > >> > >> 706 #ifdef _AIX > >> 707 javatz = > mapPlatformToJavaTimezone(java_home_dir, tz); > >> 708 #endif > >> > >> This should read: > >> > >> 706 #ifdef _AIX > >> 707 javatz = > mapPlatformToJavaTimezone(java_home_dir, javatz); > >> 708 #endif > >> > >> because in line 703 you free 'tz' via its alias 'freetz' if > 'tz' came > >> from getPlatformTimeZoneID(). > >> > >> > >> Right, but with the second approach, there may be a minor > memory leak > >> here, > >> as javatz was not freed before being overwritten on AIX. > will post another > >> patch on this soon. > >> > >> > >> With the above fixed I'll push this one we get one more > review from a > >> reviewer (I'm currently not an official reviewer). > >> > >> Regards, > >> Volker > >> > >> > >> @Masayoshi: what do you think, would you agree with such a > solution. > >> > >> 4. I agree with Masayoshi that you should use the existing > >> getGMTOffsetID() > >> > >> Updated in new patch to eliminate duplication. > >> > >> 5. Please notice that your change breaks all Unix builds > except AIX > >> because of: > >> > >> 759 } > >> 760 tzerr: > >> 761 if (javatz == NULL) { > >> 762 time_t offset; > >> ... > >> 782 } > >> 783 #endif > >> > >> I think that should read: > >> > >> 759 > >> 760 tzerr: > >> 761 if (javatz == NULL) { > >> 762 time_t offset; > >> ... > >> 782 } > >> 783 #endif > >> 784 } > >> > >> Refactoring the code in an extra function will make that > error more > >> evident anyway. > >> > >> But please always build at least on one different platform > (i.e. > >> Linux) to prevent such errors in the future. > >> > >> My fault, sorry for the failure, should take no chance > after any manual > >> alteration. > >> > >> Regards, > >> Volker > >> > >> > >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu > >> > wrote: > >> > >> Hi Jonathan, > >> > >> The AIX specific code looks OK to me. But I'd suggest the > code be moved > >> to > >> getPlatformTimeZoneID() for AIX, which just returns NULL > currently. Also > >> there's a function for producing a fallback ID in "GMT?hh:mm", > >> getGMTOffsetID() which can be called in tzerr. > >> > >> Thanks, > >> Masayoshi > >> > >> > >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: > >> > >> Hi ppc-aix-port-dev, core-libs-dev, > >> > >> Here's a patch for JDK-8034220, > >> > >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ > > >> > >> It is trying to add the a more complete timezone mapping > mechanism for > >> AIX > >> platform. > >> the changes are primarily based on IBM's commercial JDK > code, which > >> includes: > >> > >> - A new timezone mapping file added under directory > jdk/src/aix/lib/ > >> - Code to parse above config file, changed file is > >> src/solaris/native/java/util/TimeZone_md.c > >> - And also makefile change in make/CopyFiles.gmk to copy > the config > >> file > >> > >> Could you pls help to review and give comments ? > >> > >> Cheers > >> - Jonathan > >> > >> Many thanks > >> Jonathan > >> > >> Regards > >> Jonathan > > > > > > > Regards > Jonathan > > From peter.levart at gmail.com Mon Apr 14 08:35:30 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Apr 2014 10:35:30 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: <53481D2D.10702@oracle.com> References: <532C7A30.6060904@oracle.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <53481D2D.10702@oracle.com> Message-ID: <534B9DD2.30709@gmail.com> On 04/11/2014 06:49 PM, roger riggs wrote: > Hi Peter, > > We do know the PIDs of the processes that we care about but are unwilling > to pay the cost of waiting for them individually. > For the escapees, Process could resort to an individual thread > invoking waitpid(n). > > Thanks, Roger Yes, it could. But the problem is that we don't find-out about the escapees immediately. Only after waitpid(-pgid, ...) starts returning <0 with errno==ECHILD, we can assume that all children we didn't get a report on, have escaped. But that might not happen for a long time if we have at least one long-lived child in the process group... We could ignore this problem and pretend that such things never happen in practice, but I don't feel good about it and neither does Martin, I think. For a moment I thought there was another way to wait for selected children: waitid(): _SVID_SOURCE || _XOPEN_SOURCE >= 500 || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED || /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L ...contains one additional option: WNOWAIT Leave the child in a waitable state; a later wait call can be used to again retrieve the child status information. This function is available on Linux and Solaris, but not on Mac OS-X and I don't know about AIX. :-( ... So I guess we are out of luck and one thread per child is about to stay. The overhead is 32K per reaper thread which amounts to 32MB for 1K children, which doesn't seem much for a system which wants to spawn 1K concurrent children and cached thread pool takes care of thread re-use when a program spawns some children, waits for them and does that repeatedly... Regards, Peter > > > On 4/11/2014 10:52 AM, Peter Levart wrote: >> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>> >>> >>> >>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>> > wrote: >>> >>> Hi Martin, >>> >>> As you might have seen in my later reply to Roger, there's still >>> hope on that front: setpgid() + wait(-pgid, ...) might be the >>> answer. I'm exploring in that direction. Shells are doing it, so >>> why can't JDK? >>> >>> It's a little trickier for Process API, since I imagine that >>> shells form a group of processes from a pipeline which is known >>> in-advance while Process API will have to add processes to the >>> live group dynamically. So some races will have to be resolved, >>> but I think it's doable. >>> >>> >>> This is a clever idea, and it's arguably better to design >>> subprocesses so they live in separate process groups (emacs does >>> that), but: >>> Every time you create a process group, you change the effect of a >>> user signal like Ctrl-C, since it's sent to only one group. >>> Maybe propagate signals to the subprocess group? It's starting to >>> get complicated... >>> >> >> Hi Martin, >> >> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >> terminal to a (foreground) process group. A process group is formed >> from a pipeline of interconnected processes. Each pipeline is >> considered to be a separate "job", hence shells call this feature >> "job-control". Child processes by default inherit process group from >> it's parent, so children born with Process API (and their children) >> inherit the process group from the JVM process. Considering the >> intentions of shell job-controll, is propagating >> SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by Process >> API desirable? If so, then yes, handling those signals in JVM and >> propagating them to current process group that contains all children >> spawned by Process API and their descendants would have to be >> performed by JVM. That problem would certainly have to be addressed. >> But let's first see what I found out about sigaction(SIGCHLD, ...), >> setpgid(pid, pgid), waitpid(-pgid, ...), etc... >> >> waitpid(-pgid, ...) alone seems to not be enough for our task. Mainly >> because a process can re-assign it's group and join some other group. >> I don't know if this is a situation that occurs in real world, but >> imagine if we have one live child process in a process group pgid1 >> and no unwaited exited children. If we issue: >> >> waitpid(-pgid1, &status, 0); >> >> Then this call blocks, because at the time it was given, there were >> >0 child processes in the pgid1 group and none of them has exited >> yet. Now if this one child process changes it's process group with: >> >> setpgid(0, pgid2); >> >> Then the waitpid call in the parent does not return (maybe this is a >> bug in Linux?) although there are no more live child processes in the >> pgid1 group any more. Even when this child exits, the call to waitpid >> does not return, since this child is not in the group we are waiting >> for when it exits. If all our children "escape" the group in such >> way, the tread doing waiting will never unblock. To solve this, we >> can employ signal handlers. In a signal handler for SIGCHLD signal we >> can invoke: >> >> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >> >> ...in loop until it either returns (0) which means that there're no >> more unwaited exited children in the group at the momen or (-1) with >> errno == ECHILD, which means that there're no more children in the >> queried group any more - the group does not exist any more. Since >> signal handler is invoked whith SIGCHLD being masked and there is one >> bit of pending signal state in the kernel, no child exit can be >> "skipped" this way. Unless the child "escapes" by changing it's >> group. I don't know of a plausible reason for a program to change >> it's process group. If a program executing as JVM child wants to >> become a background daemon it usually behaves as follows: >> >> - fork()s a grand-child and then exit()s (so we get notified via >> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >> - the grand-child then changes it's session and group (becomes >> session and group leader), closes file descriptors, etc. The >> responsibility for waiting on the grand-child daemon is transferred >> to the init process (pid=1) since the grand-child becomes an orphan >> (has no parent). >> >> Ignoring this still unsolved problem of possible ill-behaved child >> program that changes it's process group, I started constructing a >> proof-of-concept prototype. What I will do in the prototype is start >> throwing IllegalStateException from the methods of the Process API >> that pertain to such children. I think this is reasonable. >> >> Stay tuned, >> >> Peter >> >> > From peter.levart at gmail.com Mon Apr 14 09:02:28 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Apr 2014 11:02:28 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> Message-ID: <534BA424.9040006@gmail.com> Hi Martin, Roger, Just a thought. Would it be feasible to have two (ore more) built-in strategies, selectable by system property? A backwards compatible tread per child, using waitpid(pid, ...), a single reaper thread using waitpid(-1, ...), maybe also single threaded strategy accessible only on Linux/Solaris using waitid(-1, ..., WNOWAIT)... All packed nicely in a package-private interface (ProcessReaper) with multiple implementations? Regards, Peter On 04/12/2014 01:37 AM, Martin Buchholz wrote: > Let's step back again and try to check our goals... > > We could try to optimize the one-reaper-thread-per-subprocess thing. > But that is risky, and the cost of what we're doing today is not that > high. > > We could try to implement the feature of killing off an entire > subprocess tree. But historically, any kind of behavior change like > that has been vetoed. I have tried and failed to make less > incompatible changes. We would have to add a new API. > > The reality is that Java does not give you real access to the > underlying OS, and unless there's a seriously heterodox attempt to > provide OS-specific extensions, people will have to continue to either > write native code or delegate to an OS-savvy subprocess like a perl > script. > > > On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart > wrote: > > On 04/09/2014 07:02 PM, Martin Buchholz wrote: >> >> >> >> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >> > wrote: >> >> Hi Martin, >> >> As you might have seen in my later reply to Roger, there's >> still hope on that front: setpgid() + wait(-pgid, ...) might >> be the answer. I'm exploring in that direction. Shells are >> doing it, so why can't JDK? >> >> It's a little trickier for Process API, since I imagine that >> shells form a group of processes from a pipeline which is >> known in-advance while Process API will have to add processes >> to the live group dynamically. So some races will have to be >> resolved, but I think it's doable. >> >> >> This is a clever idea, and it's arguably better to design >> subprocesses so they live in separate process groups (emacs does >> that), but: >> Every time you create a process group, you change the effect of a >> user signal like Ctrl-C, since it's sent to only one group. >> Maybe propagate signals to the subprocess group? It's starting >> to get complicated... >> > > Hi Martin, > > Yes, shells send Ctrl-C (SIGINT) and other signals initiated by > terminal to a (foreground) process group. A process group is > formed from a pipeline of interconnected processes. Each pipeline > is considered to be a separate "job", hence shells call this > feature "job-control". Child processes by default inherit process > group from it's parent, so children born with Process API (and > their children) inherit the process group from the JVM process. > Considering the intentions of shell job-controll, is propagating > SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by > Process API desirable? If so, then yes, handling those signals in > JVM and propagating them to current process group that contains > all children spawned by Process API and their descendants would > have to be performed by JVM. That problem would certainly have to > be addressed. But let's first see what I found out about > sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), > etc... > > waitpid(-pgid, ...) alone seems to not be enough for our task. > Mainly because a process can re-assign it's group and join some > other group. I don't know if this is a situation that occurs in > real world, but imagine if we have one live child process in a > process group pgid1 and no unwaited exited children. If we issue: > > waitpid(-pgid1, &status, 0); > > Then this call blocks, because at the time it was given, there > were >0 child processes in the pgid1 group and none of them has > exited yet. Now if this one child process changes it's process > group with: > > setpgid(0, pgid2); > > Then the waitpid call in the parent does not return (maybe this is > a bug in Linux?) although there are no more live child processes > in the pgid1 group any more. Even when this child exits, the call > to waitpid does not return, since this child is not in the group > we are waiting for when it exits. If all our children "escape" the > group in such way, the tread doing waiting will never unblock. To > solve this, we can employ signal handlers. In a signal handler for > SIGCHLD signal we can invoke: > > waitpid(-pgid1, &status, WNOHANG); // non-blocking call > > ...in loop until it either returns (0) which means that there're > no more unwaited exited children in the group at the momen or (-1) > with errno == ECHILD, which means that there're no more children > in the queried group any more - the group does not exist any more. > Since signal handler is invoked whith SIGCHLD being masked and > there is one bit of pending signal state in the kernel, no child > exit can be "skipped" this way. Unless the child "escapes" by > changing it's group. I don't know of a plausible reason for a > program to change it's process group. If a program executing as > JVM child wants to become a background daemon it usually behaves > as follows: > > - fork()s a grand-child and then exit()s (so we get notified via > signal and waitpid(-pgid, ...) successfully for it's exitstatus) > - the grand-child then changes it's session and group (becomes > session and group leader), closes file descriptors, etc. The > responsibility for waiting on the grand-child daemon is > transferred to the init process (pid=1) since the grand-child > becomes an orphan (has no parent). > > Ignoring this still unsolved problem of possible ill-behaved child > program that changes it's process group, I started constructing a > proof-of-concept prototype. What I will do in the prototype is > start throwing IllegalStateException from the methods of the > Process API that pertain to such children. I think this is reasonable. > > Stay tuned, > > Peter > > > From alexandre.iline at oracle.com Mon Apr 14 09:48:43 2014 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 14 Apr 2014 13:48:43 +0400 Subject: RFR: 8039816: Some tests depend on internal API sun.security.action.GetPropertyAction Message-ID: <534BAEFB.5070800@oracle.com> Hi. I'd like to ask for review of this fix: http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8039816 Thank you. Shura From weijun.wang at oracle.com Mon Apr 14 09:56:38 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 14 Apr 2014 17:56:38 +0800 Subject: RFR: 8039816: Some tests depend on internal API sun.security.action.GetPropertyAction In-Reply-To: <534BAEFB.5070800@oracle.com> References: <534BAEFB.5070800@oracle.com> Message-ID: <14A3BBF1-BECC-49FB-8477-9438703976DC@oracle.com> Change looks fine. Thanks Max On Apr 14, 2014, at 17:48, Alexandre (Shura) Iline wrote: > Hi. > > I'd like to ask for review of this fix: > http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8039816 > > Thank you. > > Shura From chris.hegarty at oracle.com Mon Apr 14 10:00:33 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Apr 2014 11:00:33 +0100 Subject: RFR: 8039816: Some tests depend on internal API sun.security.action.GetPropertyAction In-Reply-To: <534BAEFB.5070800@oracle.com> References: <534BAEFB.5070800@oracle.com> Message-ID: <534BB1C1.8050001@oracle.com> Looks good to me Shura. I can sponsor this for you ( if needed ). -Chris. On 14/04/14 10:48, Alexandre (Shura) Iline wrote: > Hi. > > I'd like to ask for review of this fix: > http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8039816 > > Thank you. > > Shura From alexandre.iline at oracle.com Mon Apr 14 10:24:37 2014 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 14 Apr 2014 14:24:37 +0400 Subject: RFR: 8039816: Some tests depend on internal API sun.security.action.GetPropertyAction In-Reply-To: <534BB1C1.8050001@oracle.com> References: <534BAEFB.5070800@oracle.com> <534BB1C1.8050001@oracle.com> Message-ID: <534BB765.8050702@oracle.com> On 4/14/14, 2:00 PM, Chris Hegarty wrote: > Looks good to me Shura. I can sponsor this for you ( if needed ). Thank you. Shura. > > -Chris. > > On 14/04/14 10:48, Alexandre (Shura) Iline wrote: >> Hi. >> >> I'd like to ask for review of this fix: >> http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8039816 >> >> Thank you. >> >> Shura From Alan.Bateman at oracle.com Mon Apr 14 10:29:50 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Apr 2014 11:29:50 +0100 Subject: RFR: 8039816: Some tests depend on internal API sun.security.action.GetPropertyAction In-Reply-To: <534BAEFB.5070800@oracle.com> References: <534BAEFB.5070800@oracle.com> Message-ID: <534BB89E.3020103@oracle.com> On 14/04/2014 10:48, Alexandre (Shura) Iline wrote: > Hi. > > I'd like to ask for review of this fix: > http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8039816 > This looks okay to me too. -Alan From ivan.gerasimov at oracle.com Mon Apr 14 11:36:12 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Apr 2014 15:36:12 +0400 Subject: RFR [8009637]: Some error messages are missing a space Message-ID: <534BC82C.4020800@oracle.com> Hello! It was reported that the error message in an exception is missing a space. Grep found a couple of other places with the same misformatting. Can I please have a review of the trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8009637 WEBREV: http://cr.openjdk.java.net/~igerasim/8009637/0/webrev/ Sincerely yours, Ivan From Alan.Bateman at oracle.com Mon Apr 14 11:55:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Apr 2014 12:55:40 +0100 Subject: RFR [8009637]: Some error messages are missing a space In-Reply-To: <534BC82C.4020800@oracle.com> References: <534BC82C.4020800@oracle.com> Message-ID: <534BCCBC.4050106@oracle.com> On 14/04/2014 12:36, Ivan Gerasimov wrote: > Hello! > > It was reported that the error message in an exception is missing a > space. > Grep found a couple of other places with the same misformatting. > > Can I please have a review of the trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8009637 > WEBREV: http://cr.openjdk.java.net/~igerasim/8009637/0/webrev/ Good to get these fixed, the change looks okay to me. -Alan. From ivan.gerasimov at oracle.com Mon Apr 14 12:12:45 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Apr 2014 16:12:45 +0400 Subject: RFR [8009637]: Some error messages are missing a space In-Reply-To: <534BCCBC.4050106@oracle.com> References: <534BC82C.4020800@oracle.com> <534BCCBC.4050106@oracle.com> Message-ID: <534BD0BD.5060709@oracle.com> Thanks! On 14.04.2014 15:55, Alan Bateman wrote: > On 14/04/2014 12:36, Ivan Gerasimov wrote: >> Hello! >> >> It was reported that the error message in an exception is missing a >> space. >> Grep found a couple of other places with the same misformatting. >> >> Can I please have a review of the trivial fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8009637 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8009637/0/webrev/ > Good to get these fixed, the change looks okay to me. > > -Alan. > > From daniel.fuchs at oracle.com Mon Apr 14 12:31:37 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 14 Apr 2014 14:31:37 +0200 Subject: RFR [8009637]: Some error messages are missing a space In-Reply-To: <534BC82C.4020800@oracle.com> References: <534BC82C.4020800@oracle.com> Message-ID: <534BD529.8060306@oracle.com> Looks good Ivan! best, -- daniel On 4/14/14 1:36 PM, Ivan Gerasimov wrote: > Hello! > > It was reported that the error message in an exception is missing a space. > Grep found a couple of other places with the same misformatting. > > Can I please have a review of the trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8009637 > WEBREV: http://cr.openjdk.java.net/~igerasim/8009637/0/webrev/ > > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Mon Apr 14 13:21:58 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Apr 2014 17:21:58 +0400 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again Message-ID: <534BE0F6.6070409@oracle.com> Hello! The test EarlyTimeout.java failed again, now with message "elapsed time 981 is less than timeout 1000." The root cause seems to be non-accurate time measurement in Windows: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx Because of this we can achieve this result: long start1 = System.currentTimeMillis(); long start2 = System.nanoTime(); ~~~~~~~~ long elapsed2 = (System.nanoTime() - start2) / 1000000; long elapsed1 = System.currentTimeMillis() - start1; assert elapsed2 < elapsed1; // can fail There might be two ways to address the issue: - add a tolerance > 15 ms, or - use System.nanoTime() for the measurement. I did both. Would you please help review the test fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038982 WEBREV: http://cr.openjdk.java.net/~igerasim/8038982/0/webrev/ Sincerely yours, Ivan From roger.riggs at oracle.com Mon Apr 14 13:49:58 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 14 Apr 2014 09:49:58 -0400 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> Message-ID: <534BE786.5010405@oracle.com> Hi Martin, A new API is needed, overloading the current Process API is not a good option. Even within Process a new method will be needed to destroy the subprocess and all of its children maintain backward compatibility. Are there specific OS features that need to be exposed to applications? Is the destroy-process-and-all-children abstraction too coarse. Roger On 4/11/2014 7:37 PM, Martin Buchholz wrote: > Let's step back again and try to check our goals... > > We could try to optimize the one-reaper-thread-per-subprocess thing. > But that is risky, and the cost of what we're doing today is not that > high. > > We could try to implement the feature of killing off an entire > subprocess tree. But historically, any kind of behavior change like > that has been vetoed. I have tried and failed to make less > incompatible changes. We would have to add a new API. > > The reality is that Java does not give you real access to the > underlying OS, and unless there's a seriously heterodox attempt to > provide OS-specific extensions, people will have to continue to either > write native code or delegate to an OS-savvy subprocess like a perl > script. > > > On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart > wrote: > > On 04/09/2014 07:02 PM, Martin Buchholz wrote: >> >> >> >> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >> > wrote: >> >> Hi Martin, >> >> As you might have seen in my later reply to Roger, there's >> still hope on that front: setpgid() + wait(-pgid, ...) might >> be the answer. I'm exploring in that direction. Shells are >> doing it, so why can't JDK? >> >> It's a little trickier for Process API, since I imagine that >> shells form a group of processes from a pipeline which is >> known in-advance while Process API will have to add processes >> to the live group dynamically. So some races will have to be >> resolved, but I think it's doable. >> >> >> This is a clever idea, and it's arguably better to design >> subprocesses so they live in separate process groups (emacs does >> that), but: >> Every time you create a process group, you change the effect of a >> user signal like Ctrl-C, since it's sent to only one group. >> Maybe propagate signals to the subprocess group? It's starting >> to get complicated... >> > > Hi Martin, > > Yes, shells send Ctrl-C (SIGINT) and other signals initiated by > terminal to a (foreground) process group. A process group is > formed from a pipeline of interconnected processes. Each pipeline > is considered to be a separate "job", hence shells call this > feature "job-control". Child processes by default inherit process > group from it's parent, so children born with Process API (and > their children) inherit the process group from the JVM process. > Considering the intentions of shell job-controll, is propagating > SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by > Process API desirable? If so, then yes, handling those signals in > JVM and propagating them to current process group that contains > all children spawned by Process API and their descendants would > have to be performed by JVM. That problem would certainly have to > be addressed. But let's first see what I found out about > sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), > etc... > > waitpid(-pgid, ...) alone seems to not be enough for our task. > Mainly because a process can re-assign it's group and join some > other group. I don't know if this is a situation that occurs in > real world, but imagine if we have one live child process in a > process group pgid1 and no unwaited exited children. If we issue: > > waitpid(-pgid1, &status, 0); > > Then this call blocks, because at the time it was given, there > were >0 child processes in the pgid1 group and none of them has > exited yet. Now if this one child process changes it's process > group with: > > setpgid(0, pgid2); > > Then the waitpid call in the parent does not return (maybe this is > a bug in Linux?) although there are no more live child processes > in the pgid1 group any more. Even when this child exits, the call > to waitpid does not return, since this child is not in the group > we are waiting for when it exits. If all our children "escape" the > group in such way, the tread doing waiting will never unblock. To > solve this, we can employ signal handlers. In a signal handler for > SIGCHLD signal we can invoke: > > waitpid(-pgid1, &status, WNOHANG); // non-blocking call > > ...in loop until it either returns (0) which means that there're > no more unwaited exited children in the group at the momen or (-1) > with errno == ECHILD, which means that there're no more children > in the queried group any more - the group does not exist any more. > Since signal handler is invoked whith SIGCHLD being masked and > there is one bit of pending signal state in the kernel, no child > exit can be "skipped" this way. Unless the child "escapes" by > changing it's group. I don't know of a plausible reason for a > program to change it's process group. If a program executing as > JVM child wants to become a background daemon it usually behaves > as follows: > > - fork()s a grand-child and then exit()s (so we get notified via > signal and waitpid(-pgid, ...) successfully for it's exitstatus) > - the grand-child then changes it's session and group (becomes > session and group leader), closes file descriptors, etc. The > responsibility for waiting on the grand-child daemon is > transferred to the init process (pid=1) since the grand-child > becomes an orphan (has no parent). > > Ignoring this still unsolved problem of possible ill-behaved child > program that changes it's process group, I started constructing a > proof-of-concept prototype. What I will do in the prototype is > start throwing IllegalStateException from the methods of the > Process API that pertain to such children. I think this is reasonable. > > Stay tuned, > > Peter > > > From roger.riggs at oracle.com Mon Apr 14 13:50:53 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 14 Apr 2014 09:50:53 -0400 Subject: ProcessReaper: single thread reaper In-Reply-To: <534BA424.9040006@gmail.com> References: <532C7A30.6060904@oracle.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BA424.9040006@gmail.com> Message-ID: <534BE7BD.4000604@oracle.com> Hi Peter, The new API to handle process trees and processes not spawned by the Java process also will need a way to wait for exit status and destroy children so I'm not sure the issue goes away. It too will need to co-exist with non-JDK libraries that spawn and handle their own children. A selectable implementation may a way to accommodate the needed backward compatibility. Roger On 4/14/2014 5:02 AM, Peter Levart wrote: > Hi Martin, Roger, > > Just a thought. Would it be feasible to have two (ore more) built-in > strategies, selectable by system property? A backwards compatible > tread per child, using waitpid(pid, ...), a single reaper thread using > waitpid(-1, ...), maybe also single threaded strategy accessible only > on Linux/Solaris using waitid(-1, ..., WNOWAIT)... All packed nicely > in a package-private interface (ProcessReaper) with multiple > implementations? > > Regards, Peter > > On 04/12/2014 01:37 AM, Martin Buchholz wrote: >> Let's step back again and try to check our goals... >> >> We could try to optimize the one-reaper-thread-per-subprocess thing. >> But that is risky, and the cost of what we're doing today is not >> that high. >> >> We could try to implement the feature of killing off an entire >> subprocess tree. But historically, any kind of behavior change like >> that has been vetoed. I have tried and failed to make less >> incompatible changes. We would have to add a new API. >> >> The reality is that Java does not give you real access to the >> underlying OS, and unless there's a seriously heterodox attempt to >> provide OS-specific extensions, people will have to continue to >> either write native code or delegate to an OS-savvy subprocess like a >> perl script. >> >> >> On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart > > wrote: >> >> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>> >>> >>> >>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>> > wrote: >>> >>> Hi Martin, >>> >>> As you might have seen in my later reply to Roger, there's >>> still hope on that front: setpgid() + wait(-pgid, ...) might >>> be the answer. I'm exploring in that direction. Shells are >>> doing it, so why can't JDK? >>> >>> It's a little trickier for Process API, since I imagine that >>> shells form a group of processes from a pipeline which is >>> known in-advance while Process API will have to add >>> processes to the live group dynamically. So some races will >>> have to be resolved, but I think it's doable. >>> >>> >>> This is a clever idea, and it's arguably better to design >>> subprocesses so they live in separate process groups (emacs does >>> that), but: >>> Every time you create a process group, you change the effect of >>> a user signal like Ctrl-C, since it's sent to only one group. >>> Maybe propagate signals to the subprocess group? It's starting >>> to get complicated... >>> >> >> Hi Martin, >> >> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >> terminal to a (foreground) process group. A process group is >> formed from a pipeline of interconnected processes. Each pipeline >> is considered to be a separate "job", hence shells call this >> feature "job-control". Child processes by default inherit process >> group from it's parent, so children born with Process API (and >> their children) inherit the process group from the JVM process. >> Considering the intentions of shell job-controll, is propagating >> SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by >> Process API desirable? If so, then yes, handling those signals in >> JVM and propagating them to current process group that contains >> all children spawned by Process API and their descendants would >> have to be performed by JVM. That problem would certainly have to >> be addressed. But let's first see what I found out about >> sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), >> etc... >> >> waitpid(-pgid, ...) alone seems to not be enough for our task. >> Mainly because a process can re-assign it's group and join some >> other group. I don't know if this is a situation that occurs in >> real world, but imagine if we have one live child process in a >> process group pgid1 and no unwaited exited children. If we issue: >> >> waitpid(-pgid1, &status, 0); >> >> Then this call blocks, because at the time it was given, there >> were >0 child processes in the pgid1 group and none of them has >> exited yet. Now if this one child process changes it's process >> group with: >> >> setpgid(0, pgid2); >> >> Then the waitpid call in the parent does not return (maybe this >> is a bug in Linux?) although there are no more live child >> processes in the pgid1 group any more. Even when this child >> exits, the call to waitpid does not return, since this child is >> not in the group we are waiting for when it exits. If all our >> children "escape" the group in such way, the tread doing waiting >> will never unblock. To solve this, we can employ signal handlers. >> In a signal handler for SIGCHLD signal we can invoke: >> >> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >> >> ...in loop until it either returns (0) which means that there're >> no more unwaited exited children in the group at the momen or >> (-1) with errno == ECHILD, which means that there're no more >> children in the queried group any more - the group does not exist >> any more. Since signal handler is invoked whith SIGCHLD being >> masked and there is one bit of pending signal state in the >> kernel, no child exit can be "skipped" this way. Unless the child >> "escapes" by changing it's group. I don't know of a plausible >> reason for a program to change it's process group. If a program >> executing as JVM child wants to become a background daemon it >> usually behaves as follows: >> >> - fork()s a grand-child and then exit()s (so we get notified via >> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >> - the grand-child then changes it's session and group (becomes >> session and group leader), closes file descriptors, etc. The >> responsibility for waiting on the grand-child daemon is >> transferred to the init process (pid=1) since the grand-child >> becomes an orphan (has no parent). >> >> Ignoring this still unsolved problem of possible ill-behaved >> child program that changes it's process group, I started >> constructing a proof-of-concept prototype. What I will do in the >> prototype is start throwing IllegalStateException from the >> methods of the Process API that pertain to such children. I think >> this is reasonable. >> >> Stay tuned, >> >> Peter >> >> >> > From david.lloyd at redhat.com Mon Apr 14 14:31:06 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Apr 2014 09:31:06 -0500 Subject: ProcessReaper: single thread reaper In-Reply-To: <534BE786.5010405@oracle.com> References: <532C7A30.6060904@oracle.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BE786.5010405@oracle.co! m> Message-ID: <534BF12A.6060508@redhat.com> Where does the requirement to manage grandchild processes actually come from? I'd hate to see the ability to "nicely" terminate immediate child processes lost just because it was difficult to implement some grander scheme. On 04/14/2014 08:49 AM, roger riggs wrote: > Hi Martin, > > A new API is needed, overloading the current Process API is not a good > option. > Even within Process a new method will be needed to destroy the > subprocess and all > of its children maintain backward compatibility. > > Are there specific OS features that need to be exposed to applications? > Is the destroy-process-and-all-children abstraction too coarse. > > Roger > > > > > > On 4/11/2014 7:37 PM, Martin Buchholz wrote: >> Let's step back again and try to check our goals... >> >> We could try to optimize the one-reaper-thread-per-subprocess thing. >> But that is risky, and the cost of what we're doing today is not that >> high. >> >> We could try to implement the feature of killing off an entire >> subprocess tree. But historically, any kind of behavior change like >> that has been vetoed. I have tried and failed to make less >> incompatible changes. We would have to add a new API. >> >> The reality is that Java does not give you real access to the >> underlying OS, and unless there's a seriously heterodox attempt to >> provide OS-specific extensions, people will have to continue to either >> write native code or delegate to an OS-savvy subprocess like a perl >> script. >> >> >> On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart > > wrote: >> >> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>> >>> >>> >>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>> > wrote: >>> >>> Hi Martin, >>> >>> As you might have seen in my later reply to Roger, there's >>> still hope on that front: setpgid() + wait(-pgid, ...) might >>> be the answer. I'm exploring in that direction. Shells are >>> doing it, so why can't JDK? >>> >>> It's a little trickier for Process API, since I imagine that >>> shells form a group of processes from a pipeline which is >>> known in-advance while Process API will have to add processes >>> to the live group dynamically. So some races will have to be >>> resolved, but I think it's doable. >>> >>> >>> This is a clever idea, and it's arguably better to design >>> subprocesses so they live in separate process groups (emacs does >>> that), but: >>> Every time you create a process group, you change the effect of a >>> user signal like Ctrl-C, since it's sent to only one group. >>> Maybe propagate signals to the subprocess group? It's starting >>> to get complicated... >>> >> >> Hi Martin, >> >> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >> terminal to a (foreground) process group. A process group is >> formed from a pipeline of interconnected processes. Each pipeline >> is considered to be a separate "job", hence shells call this >> feature "job-control". Child processes by default inherit process >> group from it's parent, so children born with Process API (and >> their children) inherit the process group from the JVM process. >> Considering the intentions of shell job-controll, is propagating >> SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by >> Process API desirable? If so, then yes, handling those signals in >> JVM and propagating them to current process group that contains >> all children spawned by Process API and their descendants would >> have to be performed by JVM. That problem would certainly have to >> be addressed. But let's first see what I found out about >> sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), >> etc... >> >> waitpid(-pgid, ...) alone seems to not be enough for our task. >> Mainly because a process can re-assign it's group and join some >> other group. I don't know if this is a situation that occurs in >> real world, but imagine if we have one live child process in a >> process group pgid1 and no unwaited exited children. If we issue: >> >> waitpid(-pgid1, &status, 0); >> >> Then this call blocks, because at the time it was given, there >> were >0 child processes in the pgid1 group and none of them has >> exited yet. Now if this one child process changes it's process >> group with: >> >> setpgid(0, pgid2); >> >> Then the waitpid call in the parent does not return (maybe this is >> a bug in Linux?) although there are no more live child processes >> in the pgid1 group any more. Even when this child exits, the call >> to waitpid does not return, since this child is not in the group >> we are waiting for when it exits. If all our children "escape" the >> group in such way, the tread doing waiting will never unblock. To >> solve this, we can employ signal handlers. In a signal handler for >> SIGCHLD signal we can invoke: >> >> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >> >> ...in loop until it either returns (0) which means that there're >> no more unwaited exited children in the group at the momen or (-1) >> with errno == ECHILD, which means that there're no more children >> in the queried group any more - the group does not exist any more. >> Since signal handler is invoked whith SIGCHLD being masked and >> there is one bit of pending signal state in the kernel, no child >> exit can be "skipped" this way. Unless the child "escapes" by >> changing it's group. I don't know of a plausible reason for a >> program to change it's process group. If a program executing as >> JVM child wants to become a background daemon it usually behaves >> as follows: >> >> - fork()s a grand-child and then exit()s (so we get notified via >> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >> - the grand-child then changes it's session and group (becomes >> session and group leader), closes file descriptors, etc. The >> responsibility for waiting on the grand-child daemon is >> transferred to the init process (pid=1) since the grand-child >> becomes an orphan (has no parent). >> >> Ignoring this still unsolved problem of possible ill-behaved child >> program that changes it's process group, I started constructing a >> proof-of-concept prototype. What I will do in the prototype is >> start throwing IllegalStateException from the methods of the >> Process API that pertain to such children. I think this is >> reasonable. >> >> Stay tuned, >> >> Peter >> >> >> > -- - DML From roger.riggs at oracle.com Mon Apr 14 14:37:10 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 14 Apr 2014 10:37:10 -0400 Subject: ProcessReaper: single thread reaper In-Reply-To: <534BF12A.6060508@redhat.com> References: <532C7A30.6060904@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BE786.5010405@oracle.co! m> <534BF12A.6060508@redhat.! com> Message-ID: <534BF296.6060002@oracle.com> Hi, Jtreg, for example, needs a reliable way to cleanup after tests. We've had a variety of problems with stray processes left over because there is no visibility nor reliable way to identify and kill them. Roger On 4/14/2014 10:31 AM, David M. Lloyd wrote: > Where does the requirement to manage grandchild processes actually > come from? I'd hate to see the ability to "nicely" terminate > immediate child processes lost just because it was difficult to > implement some grander scheme. > > On 04/14/2014 08:49 AM, roger riggs wrote: >> Hi Martin, >> >> A new API is needed, overloading the current Process API is not a good >> option. >> Even within Process a new method will be needed to destroy the >> subprocess and all >> of its children maintain backward compatibility. >> >> Are there specific OS features that need to be exposed to applications? >> Is the destroy-process-and-all-children abstraction too coarse. >> >> Roger >> >> >> >> >> >> On 4/11/2014 7:37 PM, Martin Buchholz wrote: >>> Let's step back again and try to check our goals... >>> >>> We could try to optimize the one-reaper-thread-per-subprocess thing. >>> But that is risky, and the cost of what we're doing today is not that >>> high. >>> >>> We could try to implement the feature of killing off an entire >>> subprocess tree. But historically, any kind of behavior change like >>> that has been vetoed. I have tried and failed to make less >>> incompatible changes. We would have to add a new API. >>> >>> The reality is that Java does not give you real access to the >>> underlying OS, and unless there's a seriously heterodox attempt to >>> provide OS-specific extensions, people will have to continue to either >>> write native code or delegate to an OS-savvy subprocess like a perl >>> script. >>> >>> >>> On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart >> > wrote: >>> >>> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>>> >>>> >>>> >>>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>>> > wrote: >>>> >>>> Hi Martin, >>>> >>>> As you might have seen in my later reply to Roger, there's >>>> still hope on that front: setpgid() + wait(-pgid, ...) might >>>> be the answer. I'm exploring in that direction. Shells are >>>> doing it, so why can't JDK? >>>> >>>> It's a little trickier for Process API, since I imagine that >>>> shells form a group of processes from a pipeline which is >>>> known in-advance while Process API will have to add processes >>>> to the live group dynamically. So some races will have to be >>>> resolved, but I think it's doable. >>>> >>>> >>>> This is a clever idea, and it's arguably better to design >>>> subprocesses so they live in separate process groups (emacs does >>>> that), but: >>>> Every time you create a process group, you change the effect of a >>>> user signal like Ctrl-C, since it's sent to only one group. >>>> Maybe propagate signals to the subprocess group? It's starting >>>> to get complicated... >>>> >>> >>> Hi Martin, >>> >>> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >>> terminal to a (foreground) process group. A process group is >>> formed from a pipeline of interconnected processes. Each pipeline >>> is considered to be a separate "job", hence shells call this >>> feature "job-control". Child processes by default inherit process >>> group from it's parent, so children born with Process API (and >>> their children) inherit the process group from the JVM process. >>> Considering the intentions of shell job-controll, is propagating >>> SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by >>> Process API desirable? If so, then yes, handling those signals in >>> JVM and propagating them to current process group that contains >>> all children spawned by Process API and their descendants would >>> have to be performed by JVM. That problem would certainly have to >>> be addressed. But let's first see what I found out about >>> sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), >>> etc... >>> >>> waitpid(-pgid, ...) alone seems to not be enough for our task. >>> Mainly because a process can re-assign it's group and join some >>> other group. I don't know if this is a situation that occurs in >>> real world, but imagine if we have one live child process in a >>> process group pgid1 and no unwaited exited children. If we issue: >>> >>> waitpid(-pgid1, &status, 0); >>> >>> Then this call blocks, because at the time it was given, there >>> were >0 child processes in the pgid1 group and none of them has >>> exited yet. Now if this one child process changes it's process >>> group with: >>> >>> setpgid(0, pgid2); >>> >>> Then the waitpid call in the parent does not return (maybe this is >>> a bug in Linux?) although there are no more live child processes >>> in the pgid1 group any more. Even when this child exits, the call >>> to waitpid does not return, since this child is not in the group >>> we are waiting for when it exits. If all our children "escape" the >>> group in such way, the tread doing waiting will never unblock. To >>> solve this, we can employ signal handlers. In a signal handler for >>> SIGCHLD signal we can invoke: >>> >>> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >>> >>> ...in loop until it either returns (0) which means that there're >>> no more unwaited exited children in the group at the momen or (-1) >>> with errno == ECHILD, which means that there're no more children >>> in the queried group any more - the group does not exist any more. >>> Since signal handler is invoked whith SIGCHLD being masked and >>> there is one bit of pending signal state in the kernel, no child >>> exit can be "skipped" this way. Unless the child "escapes" by >>> changing it's group. I don't know of a plausible reason for a >>> program to change it's process group. If a program executing as >>> JVM child wants to become a background daemon it usually behaves >>> as follows: >>> >>> - fork()s a grand-child and then exit()s (so we get notified via >>> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >>> - the grand-child then changes it's session and group (becomes >>> session and group leader), closes file descriptors, etc. The >>> responsibility for waiting on the grand-child daemon is >>> transferred to the init process (pid=1) since the grand-child >>> becomes an orphan (has no parent). >>> >>> Ignoring this still unsolved problem of possible ill-behaved child >>> program that changes it's process group, I started constructing a >>> proof-of-concept prototype. What I will do in the prototype is >>> start throwing IllegalStateException from the methods of the >>> Process API that pertain to such children. I think this is >>> reasonable. >>> >>> Stay tuned, >>> >>> Peter >>> >>> >>> >> > > From chris.hegarty at oracle.com Mon Apr 14 15:35:12 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Apr 2014 16:35:12 +0100 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <534BE0F6.6070409@oracle.com> References: <534BE0F6.6070409@oracle.com> Message-ID: <534C0030.6090902@oracle.com> Are you by any chance running on a VM? We have seen issues like this before, see https://bugs.openjdk.java.net/browse/JDK-7148829 ( as of yet still unresolved) -Chris. On 14/04/14 14:21, Ivan Gerasimov wrote: > Hello! > > The test EarlyTimeout.java failed again, now with message "elapsed time > 981 is less than timeout 1000." > > The root cause seems to be non-accurate time measurement in Windows: > http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx > > > Because of this we can achieve this result: > long start1 = System.currentTimeMillis(); > long start2 = System.nanoTime(); > ~~~~~~~~ > long elapsed2 = (System.nanoTime() - start2) / 1000000; > long elapsed1 = System.currentTimeMillis() - start1; > > assert elapsed2 < elapsed1; // can fail > > > There might be two ways to address the issue: > - add a tolerance > 15 ms, or > - use System.nanoTime() for the measurement. > > I did both. > > Would you please help review the test fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038982 > WEBREV: http://cr.openjdk.java.net/~igerasim/8038982/0/webrev/ > > Sincerely yours, > Ivan From peter.levart at gmail.com Mon Apr 14 15:54:47 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Apr 2014 17:54:47 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: <534BE7BD.4000604@oracle.com> References: <532C7A30.6060904@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BA424.9040006@gmail.com> <534BE7BD.4000604@oracle.com> Message-ID: <534C04C7.5070906@gmail.com> On 04/14/2014 03:50 PM, roger riggs wrote: > Hi Peter, > > The new API to handle process trees and processes not spawned by the > Java process > also will need a way to wait for exit status and destroy children so > I'm not sure the > issue goes away. It too will need to co-exist with non-JDK libraries > that spawn and handle > their own children. Hi Roger, At some point one has to decide who's responsibility it is to wait on a child process. If a process is spawned by some native library, one can expect that it's this library's responsibility to reap that child. Otherwise you're providing just one half of the story and allowing conflicts. Spawning a child and waiting on it's exit (or exiting yourself and leaving the orphan to be handled by init) are two intrinsically inter-connected actions on UNIX. It's also not possible to wait on a grand-child. Only immediate children are the clean-up responsibility of a parent (regardless of which API was used to spawn them). In that light I question the need to gracefully destroy anyone besides a direct child. It might be convenient to be able to forcibly destroy the whole sub-tree rooted at a particular direct child, but gracefull destruction should be initiated by sending a TERM signal just to the immediate child. It's this child's responsibility to do any clean-up needed, including stopping it's children. So I think we need the following capabilities in new API: - enumerate direct children (regardless of which API was used to spawn them) - trigger graceful destruction of any direct child - non-blocking query for liveness of any direct child - trigger forcible termination of any direct child and all descendants in one call - (optionally: obtain a Process object of any live direct child that was spawned by Process API) That's my view on the API that provides access to children/ancestors of JVM and has built-in constraints that prevent users to stray from recommended practices. The other possibility would be an API that provides access to any process on the system. Such API could enumerate all processes on the system and gracefully/forcibly terminate any process that OS allows (an API-equivalent for UNIX commands "ps" and "kill"). That would be a low-level API. > > A selectable implementation may a way to accommodate the needed > backward compatibility. So what do you think of the following internal reaper API (which could be used for implementation of existing Process API and to support new API obtaining Process objects for children): interface ProcessReaper { // return a suitable implementation of ProcessReaper (selectable by system property) static ProcessReaper getInstance() { .... } // register "our" process that we have just spawned and are responsible to wait for. // return CompletableFuture that will be completed with the exitstatus // when the process terminates CompletableFuture processStarted(Process process); // return the Process object for "our" live process or null if the given pid // does not represent a live process that we have spawned. ProcessgetProcess(int pid); } This assumes that Process class will get new public (or at least package-private) method: int getProcessId(); Regards, Peter > > Roger > > On 4/14/2014 5:02 AM, Peter Levart wrote: >> Hi Martin, Roger, >> >> Just a thought. Would it be feasible to have two (ore more) built-in >> strategies, selectable by system property? A backwards compatible >> tread per child, using waitpid(pid, ...), a single reaper thread >> using waitpid(-1, ...), maybe also single threaded strategy >> accessible only on Linux/Solaris using waitid(-1, ..., WNOWAIT)... >> All packed nicely in a package-private interface (ProcessReaper) with >> multiple implementations? >> >> Regards, Peter >> >> On 04/12/2014 01:37 AM, Martin Buchholz wrote: >>> Let's step back again and try to check our goals... >>> >>> We could try to optimize the one-reaper-thread-per-subprocess thing. >>> But that is risky, and the cost of what we're doing today is not >>> that high. >>> >>> We could try to implement the feature of killing off an entire >>> subprocess tree. But historically, any kind of behavior change like >>> that has been vetoed. I have tried and failed to make less >>> incompatible changes. We would have to add a new API. >>> >>> The reality is that Java does not give you real access to the >>> underlying OS, and unless there's a seriously heterodox attempt to >>> provide OS-specific extensions, people will have to continue to >>> either write native code or delegate to an OS-savvy subprocess like >>> a perl script. >>> >>> >>> On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart >>> > wrote: >>> >>> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>>> >>>> >>>> >>>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>>> > wrote: >>>> >>>> Hi Martin, >>>> >>>> As you might have seen in my later reply to Roger, there's >>>> still hope on that front: setpgid() + wait(-pgid, ...) >>>> might be the answer. I'm exploring in that direction. >>>> Shells are doing it, so why can't JDK? >>>> >>>> It's a little trickier for Process API, since I imagine >>>> that shells form a group of processes from a pipeline which >>>> is known in-advance while Process API will have to add >>>> processes to the live group dynamically. So some races will >>>> have to be resolved, but I think it's doable. >>>> >>>> >>>> This is a clever idea, and it's arguably better to design >>>> subprocesses so they live in separate process groups (emacs >>>> does that), but: >>>> Every time you create a process group, you change the effect of >>>> a user signal like Ctrl-C, since it's sent to only one group. >>>> Maybe propagate signals to the subprocess group? It's starting >>>> to get complicated... >>>> >>> >>> Hi Martin, >>> >>> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >>> terminal to a (foreground) process group. A process group is >>> formed from a pipeline of interconnected processes. Each >>> pipeline is considered to be a separate "job", hence shells call >>> this feature "job-control". Child processes by default inherit >>> process group from it's parent, so children born with Process >>> API (and their children) inherit the process group from the JVM >>> process. Considering the intentions of shell job-controll, is >>> propagating SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children >>> spawned by Process API desirable? If so, then yes, handling >>> those signals in JVM and propagating them to current process >>> group that contains all children spawned by Process API and >>> their descendants would have to be performed by JVM. That >>> problem would certainly have to be addressed. But let's first >>> see what I found out about sigaction(SIGCHLD, ...), setpgid(pid, >>> pgid), waitpid(-pgid, ...), etc... >>> >>> waitpid(-pgid, ...) alone seems to not be enough for our task. >>> Mainly because a process can re-assign it's group and join some >>> other group. I don't know if this is a situation that occurs in >>> real world, but imagine if we have one live child process in a >>> process group pgid1 and no unwaited exited children. If we issue: >>> >>> waitpid(-pgid1, &status, 0); >>> >>> Then this call blocks, because at the time it was given, there >>> were >0 child processes in the pgid1 group and none of them has >>> exited yet. Now if this one child process changes it's process >>> group with: >>> >>> setpgid(0, pgid2); >>> >>> Then the waitpid call in the parent does not return (maybe this >>> is a bug in Linux?) although there are no more live child >>> processes in the pgid1 group any more. Even when this child >>> exits, the call to waitpid does not return, since this child is >>> not in the group we are waiting for when it exits. If all our >>> children "escape" the group in such way, the tread doing waiting >>> will never unblock. To solve this, we can employ signal >>> handlers. In a signal handler for SIGCHLD signal we can invoke: >>> >>> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >>> >>> ...in loop until it either returns (0) which means that there're >>> no more unwaited exited children in the group at the momen or >>> (-1) with errno == ECHILD, which means that there're no more >>> children in the queried group any more - the group does not >>> exist any more. Since signal handler is invoked whith SIGCHLD >>> being masked and there is one bit of pending signal state in the >>> kernel, no child exit can be "skipped" this way. Unless the >>> child "escapes" by changing it's group. I don't know of a >>> plausible reason for a program to change it's process group. If >>> a program executing as JVM child wants to become a background >>> daemon it usually behaves as follows: >>> >>> - fork()s a grand-child and then exit()s (so we get notified via >>> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >>> - the grand-child then changes it's session and group (becomes >>> session and group leader), closes file descriptors, etc. The >>> responsibility for waiting on the grand-child daemon is >>> transferred to the init process (pid=1) since the grand-child >>> becomes an orphan (has no parent). >>> >>> Ignoring this still unsolved problem of possible ill-behaved >>> child program that changes it's process group, I started >>> constructing a proof-of-concept prototype. What I will do in the >>> prototype is start throwing IllegalStateException from the >>> methods of the Process API that pertain to such children. I >>> think this is reasonable. >>> >>> Stay tuned, >>> >>> Peter >>> >>> >>> >> > From mandy.chung at oracle.com Mon Apr 14 16:03:51 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Apr 2014 09:03:51 -0700 Subject: RFR: 8039816: Some tests depend on internal API sun.security.action.GetPropertyAction In-Reply-To: <534BAEFB.5070800@oracle.com> References: <534BAEFB.5070800@oracle.com> Message-ID: <534C06E7.6060907@oracle.com> On 4/14/2014 2:48 AM, Alexandre (Shura) Iline wrote: > Hi. > > I'd like to ask for review of this fix: > http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8039816 This change looks fine. Thanks for these test cleanup. Mandy From mandy.chung at oracle.com Mon Apr 14 16:18:26 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Apr 2014 09:18:26 -0700 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <534BE0F6.6070409@oracle.com> References: <534BE0F6.6070409@oracle.com> Message-ID: <534C0A52.7040707@oracle.com> On 4/14/2014 6:21 AM, Ivan Gerasimov wrote: > Hello! > > The test EarlyTimeout.java failed again, now with message "elapsed > time 981 is less than timeout 1000." > > The root cause seems to be non-accurate time measurement in Windows: > http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx > > > There might be two ways to address the issue: > - add a tolerance > 15 ms, or > - use System.nanoTime() for the measurement. > > I did both. > > Would you please help review the test fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038982 > WEBREV: http://cr.openjdk.java.net/~igerasim/8038982/0/webrev/ > Thanks for putting time in getting this test more reliable. Have you thought about keep zero tolerance (or much smaller value) when the test is running on *nix platforms? Mandy From peter.levart at gmail.com Mon Apr 14 16:37:27 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Apr 2014 18:37:27 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: <534BF296.6060002@oracle.com> References: <532C7A30.6060904@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BE786.5010405@oracle.co! m> <534BF12A.6060508@redhat.! com> <534BF296.6060002@oracle.com> Message-ID: <534C0EC7.1040209@gmail.com> On 04/14/2014 04:37 PM, roger riggs wrote: > Hi, > > Jtreg, for example, needs a reliable way to cleanup after tests. > We've had a variety of problems with stray processes left over because > there is no visibility nor reliable way to identify and kill them. > > Roger Hi Roger, If you want to reliably get rid of all ancestors then there's only one way on UNIX: for (Proc c : enumerateDirectChildrenOfJVM()) { getRidOfTreeRootedAt(c); } getRidOfTreeRootedAt(Proc p) { // if we're not alive any more, then we can't have children - they are // orphans and we can't identify them any more (their parent is "init") if (p.isAlive()) { // save list of direct children 1st, since they will be re-parented when // their parent is gone, preventing enumerating them later... List children = p.enumerateDirectChildren(); // try gracefull... p.terminateGrecefully(); // wait a while if (p.isAlive()) p.terminateForcefully(); // now iterate children for (C : children) { getRidOfTreeRootedAt(C); } } } - must 1st terminate the parent (hopefully with grace and it will take care of children) because if you kill a child 1st, a persistent parent might re-spawn it. - must enumerate the children before terminating the parent, because they are re-parented when the parent dies and you can't find them any more. So my list of requirements for the new API that I submitted in previous message: On 04/14/2014 05:54 PM, Peter Levart wrote: > - enumerate direct children (regardless of which API was used to spawn > them) of JVM > - trigger graceful destruction of any direct child > - non-blocking query for liveness of any direct child > - trigger forcible termination of any direct child and all descendants > in one call > - (optionally: obtain a Process object of any live direct child that > was spawned by Process API) ...must be augmented: - enumerate direct children (regardless of which API was used to spawn them) of JVM - enumerate direct children of any child enumerated by the API - trigger graceful destruction of any ancestor enumerated by the API - non-blocking query for liveness of any ancestor enumerated by the API - trigger forcible termination of any ancestor enumerated by the API - (optionally: obtain a Process object of any live direct JVM child that was spawned by Process API) Regards, Peter > > > On 4/14/2014 10:31 AM, David M. Lloyd wrote: >> Where does the requirement to manage grandchild processes actually >> come from? I'd hate to see the ability to "nicely" terminate >> immediate child processes lost just because it was difficult to >> implement some grander scheme. >> >> On 04/14/2014 08:49 AM, roger riggs wrote: >>> Hi Martin, >>> >>> A new API is needed, overloading the current Process API is not a good >>> option. >>> Even within Process a new method will be needed to destroy the >>> subprocess and all >>> of its children maintain backward compatibility. >>> >>> Are there specific OS features that need to be exposed to applications? >>> Is the destroy-process-and-all-children abstraction too coarse. >>> >>> Roger >>> >>> >>> >>> >>> >>> On 4/11/2014 7:37 PM, Martin Buchholz wrote: >>>> Let's step back again and try to check our goals... >>>> >>>> We could try to optimize the one-reaper-thread-per-subprocess thing. >>>> But that is risky, and the cost of what we're doing today is not that >>>> high. >>>> >>>> We could try to implement the feature of killing off an entire >>>> subprocess tree. But historically, any kind of behavior change like >>>> that has been vetoed. I have tried and failed to make less >>>> incompatible changes. We would have to add a new API. >>>> >>>> The reality is that Java does not give you real access to the >>>> underlying OS, and unless there's a seriously heterodox attempt to >>>> provide OS-specific extensions, people will have to continue to either >>>> write native code or delegate to an OS-savvy subprocess like a perl >>>> script. >>>> >>>> >>>> On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart >>> > wrote: >>>> >>>> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>>>> >>>>> >>>>> >>>>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>>>> > wrote: >>>>> >>>>> Hi Martin, >>>>> >>>>> As you might have seen in my later reply to Roger, there's >>>>> still hope on that front: setpgid() + wait(-pgid, ...) might >>>>> be the answer. I'm exploring in that direction. Shells are >>>>> doing it, so why can't JDK? >>>>> >>>>> It's a little trickier for Process API, since I imagine that >>>>> shells form a group of processes from a pipeline which is >>>>> known in-advance while Process API will have to add processes >>>>> to the live group dynamically. So some races will have to be >>>>> resolved, but I think it's doable. >>>>> >>>>> >>>>> This is a clever idea, and it's arguably better to design >>>>> subprocesses so they live in separate process groups (emacs does >>>>> that), but: >>>>> Every time you create a process group, you change the effect of a >>>>> user signal like Ctrl-C, since it's sent to only one group. >>>>> Maybe propagate signals to the subprocess group? It's starting >>>>> to get complicated... >>>>> >>>> >>>> Hi Martin, >>>> >>>> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >>>> terminal to a (foreground) process group. A process group is >>>> formed from a pipeline of interconnected processes. Each pipeline >>>> is considered to be a separate "job", hence shells call this >>>> feature "job-control". Child processes by default inherit process >>>> group from it's parent, so children born with Process API (and >>>> their children) inherit the process group from the JVM process. >>>> Considering the intentions of shell job-controll, is propagating >>>> SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by >>>> Process API desirable? If so, then yes, handling those signals in >>>> JVM and propagating them to current process group that contains >>>> all children spawned by Process API and their descendants would >>>> have to be performed by JVM. That problem would certainly have to >>>> be addressed. But let's first see what I found out about >>>> sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), >>>> etc... >>>> >>>> waitpid(-pgid, ...) alone seems to not be enough for our task. >>>> Mainly because a process can re-assign it's group and join some >>>> other group. I don't know if this is a situation that occurs in >>>> real world, but imagine if we have one live child process in a >>>> process group pgid1 and no unwaited exited children. If we issue: >>>> >>>> waitpid(-pgid1, &status, 0); >>>> >>>> Then this call blocks, because at the time it was given, there >>>> were >0 child processes in the pgid1 group and none of them has >>>> exited yet. Now if this one child process changes it's process >>>> group with: >>>> >>>> setpgid(0, pgid2); >>>> >>>> Then the waitpid call in the parent does not return (maybe this is >>>> a bug in Linux?) although there are no more live child processes >>>> in the pgid1 group any more. Even when this child exits, the call >>>> to waitpid does not return, since this child is not in the group >>>> we are waiting for when it exits. If all our children "escape" the >>>> group in such way, the tread doing waiting will never unblock. To >>>> solve this, we can employ signal handlers. In a signal handler for >>>> SIGCHLD signal we can invoke: >>>> >>>> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >>>> >>>> ...in loop until it either returns (0) which means that there're >>>> no more unwaited exited children in the group at the momen or (-1) >>>> with errno == ECHILD, which means that there're no more children >>>> in the queried group any more - the group does not exist any more. >>>> Since signal handler is invoked whith SIGCHLD being masked and >>>> there is one bit of pending signal state in the kernel, no child >>>> exit can be "skipped" this way. Unless the child "escapes" by >>>> changing it's group. I don't know of a plausible reason for a >>>> program to change it's process group. If a program executing as >>>> JVM child wants to become a background daemon it usually behaves >>>> as follows: >>>> >>>> - fork()s a grand-child and then exit()s (so we get notified via >>>> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >>>> - the grand-child then changes it's session and group (becomes >>>> session and group leader), closes file descriptors, etc. The >>>> responsibility for waiting on the grand-child daemon is >>>> transferred to the init process (pid=1) since the grand-child >>>> becomes an orphan (has no parent). >>>> >>>> Ignoring this still unsolved problem of possible ill-behaved child >>>> program that changes it's process group, I started constructing a >>>> proof-of-concept prototype. What I will do in the prototype is >>>> start throwing IllegalStateException from the methods of the >>>> Process API that pertain to such children. I think this is >>>> reasonable. >>>> >>>> Stay tuned, >>>> >>>> Peter >>>> >>>> >>>> >>> >> >> > From david.lloyd at redhat.com Mon Apr 14 17:00:52 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Apr 2014 12:00:52 -0500 Subject: ProcessReaper: single thread reaper In-Reply-To: <534C04C7.5070906@gmail.com> References: <532C7A30.6060904@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BA424.9040006@gmail.com> <534BE7BD.4000604@oracle.com> <534C04C7.5070906@gmail.com> Message-ID: <534C1444.3010100@redhat.com> On 04/14/2014 10:54 AM, Peter Levart wrote: > On 04/14/2014 03:50 PM, roger riggs wrote: >> Hi Peter, >> >> The new API to handle process trees and processes not spawned by the >> Java process >> also will need a way to wait for exit status and destroy children so >> I'm not sure the >> issue goes away. It too will need to co-exist with non-JDK libraries >> that spawn and handle >> their own children. > > Hi Roger, > > At some point one has to decide who's responsibility it is to wait on a > child process. If a process is spawned by some native library, one can > expect that it's this library's responsibility to reap that child. > Otherwise you're providing just one half of the story and allowing > conflicts. Spawning a child and waiting on it's exit (or exiting > yourself and leaving the orphan to be handled by init) are two > intrinsically inter-connected actions on UNIX. It's also not possible to > wait on a grand-child. > > Only immediate children are the clean-up responsibility of a parent > (regardless of which API was used to spawn them). In that light I > question the need to gracefully destroy anyone besides a direct child. > It might be convenient to be able to forcibly destroy the whole sub-tree > rooted at a particular direct child, but gracefull destruction should be > initiated by sending a TERM signal just to the immediate child. It's > this child's responsibility to do any clean-up needed, including > stopping it's children. This is exactly what I was getting at. > So I think we need the following capabilities in new API: > > - enumerate direct children (regardless of which API was used to spawn > them) > - trigger graceful destruction of any direct child > - non-blocking query for liveness of any direct child > - trigger forcible termination of any direct child and all descendants > in one call > - (optionally: obtain a Process object of any live direct child that was > spawned by Process API) While the Process API does not provide a satisfactory abstraction of a direct child process not started by that API, it is not hard to imagine that a superclass of Process containing a subset of operations, all of which are relevant to any direct child process, could fulfill the need with a minimum of API dissonance (i.e. everything excluding the stream-related methods, including any new graceful termination API methods). > That's my view on the API that provides access to children/ancestors of > JVM and has built-in constraints that prevent users to stray from > recommended practices. > > The other possibility would be an API that provides access to any > process on the system. Such API could enumerate all processes on the > system and gracefully/forcibly terminate any process that OS allows (an > API-equivalent for UNIX commands "ps" and "kill"). That would be a > low-level API. This could be accomplished using a superclass of the aforementioned superclass which contains only the destroy/terminateNicely/isAlive methods, but not the exitValue/waitFor kinds of methods. -- - DML From david.lloyd at redhat.com Mon Apr 14 17:02:30 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Apr 2014 12:02:30 -0500 Subject: ProcessReaper: single thread reaper In-Reply-To: <534C0EC7.1040209@gmail.com> References: <532C7A30.6060904@oracle.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BE786.5010405@oracle.co! m> <534BF12A.6060508@redhat.! com> <534BF296.6060002@oracle.com> <534C0EC7.1040209@gmai! l.com> Message-ID: <534C14A6.7030805@redhat.com> On 04/14/2014 11:37 AM, Peter Levart wrote: > On 04/14/2014 04:37 PM, roger riggs wrote: >> Hi, >> >> Jtreg, for example, needs a reliable way to cleanup after tests. >> We've had a variety of problems with stray processes left over because >> there is no visibility nor reliable way to identify and kill them. >> >> Roger > > Hi Roger, > > If you want to reliably get rid of all ancestors then there's only one > way on UNIX: > > > for (Proc c : enumerateDirectChildrenOfJVM()) { > getRidOfTreeRootedAt(c); > } > > getRidOfTreeRootedAt(Proc p) { > // if we're not alive any more, then we can't have children - they are > // orphans and we can't identify them any more (their parent is > "init") > if (p.isAlive()) { > // save list of direct children 1st, since they will be > re-parented when > // their parent is gone, preventing enumerating them later... > List children = p.enumerateDirectChildren(); > // try gracefull... > p.terminateGrecefully(); > // wait a while > if (p.isAlive()) p.terminateForcefully(); > // now iterate children > for (C : children) { > getRidOfTreeRootedAt(C); > } > } > } I don't think this is a good idea. If a grandchild process exits, and the parent waits() on it, then by the time we get around to iterating grandchild processes, the OS may have assigned a new process the old PID. Zombies are pretty much the only reliable way to ensure that the process is the one we think it is, and we can only reliably do that for immediate children AFAICT. > > > - must 1st terminate the parent (hopefully with grace and it will take > care of children) because if you kill a child 1st, a persistent parent > might re-spawn it. > - must enumerate the children before terminating the parent, because > they are re-parented when the parent dies and you can't find them any more. > > > So my list of requirements for the new API that I submitted in previous > message: > > On 04/14/2014 05:54 PM, Peter Levart wrote: >> - enumerate direct children (regardless of which API was used to spawn >> them) of JVM >> - trigger graceful destruction of any direct child >> - non-blocking query for liveness of any direct child >> - trigger forcible termination of any direct child and all descendants >> in one call >> - (optionally: obtain a Process object of any live direct child that >> was spawned by Process API) > > ...must be augmented: > > - enumerate direct children (regardless of which API was used to spawn > them) of JVM > - enumerate direct children of any child enumerated by the API > - trigger graceful destruction of any ancestor enumerated by the API > - non-blocking query for liveness of any ancestor enumerated by the API > - trigger forcible termination of any ancestor enumerated by the API > - (optionally: obtain a Process object of any live direct JVM child that > was spawned by Process API) > > > Regards, Peter > > >> >> >> On 4/14/2014 10:31 AM, David M. Lloyd wrote: >>> Where does the requirement to manage grandchild processes actually >>> come from? I'd hate to see the ability to "nicely" terminate >>> immediate child processes lost just because it was difficult to >>> implement some grander scheme. >>> >>> On 04/14/2014 08:49 AM, roger riggs wrote: >>>> Hi Martin, >>>> >>>> A new API is needed, overloading the current Process API is not a good >>>> option. >>>> Even within Process a new method will be needed to destroy the >>>> subprocess and all >>>> of its children maintain backward compatibility. >>>> >>>> Are there specific OS features that need to be exposed to applications? >>>> Is the destroy-process-and-all-children abstraction too coarse. >>>> >>>> Roger >>>> >>>> >>>> >>>> >>>> >>>> On 4/11/2014 7:37 PM, Martin Buchholz wrote: >>>>> Let's step back again and try to check our goals... >>>>> >>>>> We could try to optimize the one-reaper-thread-per-subprocess thing. >>>>> But that is risky, and the cost of what we're doing today is not that >>>>> high. >>>>> >>>>> We could try to implement the feature of killing off an entire >>>>> subprocess tree. But historically, any kind of behavior change like >>>>> that has been vetoed. I have tried and failed to make less >>>>> incompatible changes. We would have to add a new API. >>>>> >>>>> The reality is that Java does not give you real access to the >>>>> underlying OS, and unless there's a seriously heterodox attempt to >>>>> provide OS-specific extensions, people will have to continue to either >>>>> write native code or delegate to an OS-savvy subprocess like a perl >>>>> script. >>>>> >>>>> >>>>> On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart >>>> > wrote: >>>>> >>>>> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>>>>> > wrote: >>>>>> >>>>>> Hi Martin, >>>>>> >>>>>> As you might have seen in my later reply to Roger, there's >>>>>> still hope on that front: setpgid() + wait(-pgid, ...) might >>>>>> be the answer. I'm exploring in that direction. Shells are >>>>>> doing it, so why can't JDK? >>>>>> >>>>>> It's a little trickier for Process API, since I imagine that >>>>>> shells form a group of processes from a pipeline which is >>>>>> known in-advance while Process API will have to add processes >>>>>> to the live group dynamically. So some races will have to be >>>>>> resolved, but I think it's doable. >>>>>> >>>>>> >>>>>> This is a clever idea, and it's arguably better to design >>>>>> subprocesses so they live in separate process groups (emacs does >>>>>> that), but: >>>>>> Every time you create a process group, you change the effect of a >>>>>> user signal like Ctrl-C, since it's sent to only one group. >>>>>> Maybe propagate signals to the subprocess group? It's starting >>>>>> to get complicated... >>>>>> >>>>> >>>>> Hi Martin, >>>>> >>>>> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >>>>> terminal to a (foreground) process group. A process group is >>>>> formed from a pipeline of interconnected processes. Each pipeline >>>>> is considered to be a separate "job", hence shells call this >>>>> feature "job-control". Child processes by default inherit process >>>>> group from it's parent, so children born with Process API (and >>>>> their children) inherit the process group from the JVM process. >>>>> Considering the intentions of shell job-controll, is propagating >>>>> SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by >>>>> Process API desirable? If so, then yes, handling those signals in >>>>> JVM and propagating them to current process group that contains >>>>> all children spawned by Process API and their descendants would >>>>> have to be performed by JVM. That problem would certainly have to >>>>> be addressed. But let's first see what I found out about >>>>> sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), >>>>> etc... >>>>> >>>>> waitpid(-pgid, ...) alone seems to not be enough for our task. >>>>> Mainly because a process can re-assign it's group and join some >>>>> other group. I don't know if this is a situation that occurs in >>>>> real world, but imagine if we have one live child process in a >>>>> process group pgid1 and no unwaited exited children. If we issue: >>>>> >>>>> waitpid(-pgid1, &status, 0); >>>>> >>>>> Then this call blocks, because at the time it was given, there >>>>> were >0 child processes in the pgid1 group and none of them has >>>>> exited yet. Now if this one child process changes it's process >>>>> group with: >>>>> >>>>> setpgid(0, pgid2); >>>>> >>>>> Then the waitpid call in the parent does not return (maybe this is >>>>> a bug in Linux?) although there are no more live child processes >>>>> in the pgid1 group any more. Even when this child exits, the call >>>>> to waitpid does not return, since this child is not in the group >>>>> we are waiting for when it exits. If all our children "escape" the >>>>> group in such way, the tread doing waiting will never unblock. To >>>>> solve this, we can employ signal handlers. In a signal handler for >>>>> SIGCHLD signal we can invoke: >>>>> >>>>> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >>>>> >>>>> ...in loop until it either returns (0) which means that there're >>>>> no more unwaited exited children in the group at the momen or (-1) >>>>> with errno == ECHILD, which means that there're no more children >>>>> in the queried group any more - the group does not exist any more. >>>>> Since signal handler is invoked whith SIGCHLD being masked and >>>>> there is one bit of pending signal state in the kernel, no child >>>>> exit can be "skipped" this way. Unless the child "escapes" by >>>>> changing it's group. I don't know of a plausible reason for a >>>>> program to change it's process group. If a program executing as >>>>> JVM child wants to become a background daemon it usually behaves >>>>> as follows: >>>>> >>>>> - fork()s a grand-child and then exit()s (so we get notified via >>>>> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >>>>> - the grand-child then changes it's session and group (becomes >>>>> session and group leader), closes file descriptors, etc. The >>>>> responsibility for waiting on the grand-child daemon is >>>>> transferred to the init process (pid=1) since the grand-child >>>>> becomes an orphan (has no parent). >>>>> >>>>> Ignoring this still unsolved problem of possible ill-behaved child >>>>> program that changes it's process group, I started constructing a >>>>> proof-of-concept prototype. What I will do in the prototype is >>>>> start throwing IllegalStateException from the methods of the >>>>> Process API that pertain to such children. I think this is >>>>> reasonable. >>>>> >>>>> Stay tuned, >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>>> >>> >>> >> > -- - DML From brent.christian at oracle.com Mon Apr 14 17:22:41 2014 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 14 Apr 2014 10:22:41 -0700 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <534BE0F6.6070409@oracle.com> References: <534BE0F6.6070409@oracle.com> Message-ID: <534C1961.1010204@oracle.com> Hi, Ivan This sounds like an issue we saw in FX a while ago with imprecise timers on Windows. If it is, you might check out: https://bugs.openjdk.java.net/browse/JDK-6435126 It describes a workaround to enable higher-precision timing on Windows (using a long-sleeping daemon thread). That might be a third alternative solution... -Brent On 4/14/14 6:21 AM, Ivan Gerasimov wrote: > Hello! > > The test EarlyTimeout.java failed again, now with message "elapsed time > 981 is less than timeout 1000." > > The root cause seems to be non-accurate time measurement in Windows: > http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx > > > Because of this we can achieve this result: > long start1 = System.currentTimeMillis(); > long start2 = System.nanoTime(); > ~~~~~~~~ > long elapsed2 = (System.nanoTime() - start2) / 1000000; > long elapsed1 = System.currentTimeMillis() - start1; > > assert elapsed2 < elapsed1; // can fail > > > There might be two ways to address the issue: > - add a tolerance > 15 ms, or > - use System.nanoTime() for the measurement. > > I did both. > > Would you please help review the test fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038982 > WEBREV: http://cr.openjdk.java.net/~igerasim/8038982/0/webrev/ > > Sincerely yours, > Ivan From roger.riggs at oracle.com Mon Apr 14 17:31:16 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 14 Apr 2014 13:31:16 -0400 Subject: ProcessReaper: single thread reaper In-Reply-To: <534C0EC7.1040209@gmail.com> References: <532C7A30.6060904@oracle.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BE786.5010405@oracle.co! m> <534BF12A.6060508@redhat.! com> <534BF296.6060002@oracle.com> <534C0EC7.1040209@gmai! l.com> Message-ID: <534C1B64.1030902@oracle.com> Hi Peter, We already have Process.destroy vs Process.destroyForcibly though the implementations are identical. I agree that for a general purpose API, using a nice polite approach with the children is needed. But I'm troubled, by the 'wait-a-while' technique. That probably should be left to the caller of the API. But in the cleanup case, such as jtreg, the niceties do not need to be provided; just clean the swamp. I've seen one technique that suspends all of the sub processes in the first pass then send them all sigkill and go back and continue them again. Roger On 4/14/2014 12:37 PM, Peter Levart wrote: > On 04/14/2014 04:37 PM, roger riggs wrote: >> Hi, >> >> Jtreg, for example, needs a reliable way to cleanup after tests. >> We've had a variety of problems with stray processes left over because >> there is no visibility nor reliable way to identify and kill them. >> >> Roger > > Hi Roger, > > If you want to reliably get rid of all ancestors then there's only one > way on UNIX: > > > for (Proc c : enumerateDirectChildrenOfJVM()) { > getRidOfTreeRootedAt(c); > } > > getRidOfTreeRootedAt(Proc p) { > // if we're not alive any more, then we can't have children - they > are > // orphans and we can't identify them any more (their parent is > "init") > if (p.isAlive()) { > // save list of direct children 1st, since they will be > re-parented when > // their parent is gone, preventing enumerating them later... > List children = p.enumerateDirectChildren(); > // try gracefull... > p.terminateGracefully(); > // wait a while > if (p.isAlive()) p.terminateForcefully(); > // now iterate children > for (C : children) { > getRidOfTreeRootedAt(C); > } > } > } > > > - must 1st terminate the parent (hopefully with grace and it will take > care of children) because if you kill a child 1st, a persistent parent > might re-spawn it. > - must enumerate the children before terminating the parent, because > they are re-parented when the parent dies and you can't find them any > more. > > > So my list of requirements for the new API that I submitted in > previous message: > > On 04/14/2014 05:54 PM, Peter Levart wrote: >> - enumerate direct children (regardless of which API was used to >> spawn them) of JVM >> - trigger graceful destruction of any direct child >> - non-blocking query for liveness of any direct child >> - trigger forcible termination of any direct child and all >> descendants in one call >> - (optionally: obtain a Process object of any live direct child that >> was spawned by Process API) > > ...must be augmented: > > - enumerate direct children (regardless of which API was used to spawn > them) of JVM > - enumerate direct children of any child enumerated by the API > - trigger graceful destruction of any ancestor enumerated by the API > - non-blocking query for liveness of any ancestor enumerated by the API > - trigger forcible termination of any ancestor enumerated by the API > - (optionally: obtain a Process object of any live direct JVM child > that was spawned by Process API) > > > Regards, Peter > > >> >> >> On 4/14/2014 10:31 AM, David M. Lloyd wrote: >>> Where does the requirement to manage grandchild processes actually >>> come from? I'd hate to see the ability to "nicely" terminate >>> immediate child processes lost just because it was difficult to >>> implement some grander scheme. >>> >>> On 04/14/2014 08:49 AM, roger riggs wrote: >>>> Hi Martin, >>>> >>>> A new API is needed, overloading the current Process API is not a good >>>> option. >>>> Even within Process a new method will be needed to destroy the >>>> subprocess and all >>>> of its children maintain backward compatibility. >>>> >>>> Are there specific OS features that need to be exposed to >>>> applications? >>>> Is the destroy-process-and-all-children abstraction too coarse. >>>> >>>> Roger >>>> >>>> >>>> >>>> >>>> >>>> On 4/11/2014 7:37 PM, Martin Buchholz wrote: >>>>> Let's step back again and try to check our goals... >>>>> >>>>> We could try to optimize the one-reaper-thread-per-subprocess thing. >>>>> But that is risky, and the cost of what we're doing today is not >>>>> that >>>>> high. >>>>> >>>>> We could try to implement the feature of killing off an entire >>>>> subprocess tree. But historically, any kind of behavior change like >>>>> that has been vetoed. I have tried and failed to make less >>>>> incompatible changes. We would have to add a new API. >>>>> >>>>> The reality is that Java does not give you real access to the >>>>> underlying OS, and unless there's a seriously heterodox attempt to >>>>> provide OS-specific extensions, people will have to continue to >>>>> either >>>>> write native code or delegate to an OS-savvy subprocess like a perl >>>>> script. >>>>> >>>>> >>>>> On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart >>>> > wrote: >>>>> >>>>> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>>>>> > wrote: >>>>>> >>>>>> Hi Martin, >>>>>> >>>>>> As you might have seen in my later reply to Roger, there's >>>>>> still hope on that front: setpgid() + wait(-pgid, ...) might >>>>>> be the answer. I'm exploring in that direction. Shells are >>>>>> doing it, so why can't JDK? >>>>>> >>>>>> It's a little trickier for Process API, since I imagine that >>>>>> shells form a group of processes from a pipeline which is >>>>>> known in-advance while Process API will have to add >>>>>> processes >>>>>> to the live group dynamically. So some races will have to be >>>>>> resolved, but I think it's doable. >>>>>> >>>>>> >>>>>> This is a clever idea, and it's arguably better to design >>>>>> subprocesses so they live in separate process groups (emacs does >>>>>> that), but: >>>>>> Every time you create a process group, you change the effect >>>>>> of a >>>>>> user signal like Ctrl-C, since it's sent to only one group. >>>>>> Maybe propagate signals to the subprocess group? It's starting >>>>>> to get complicated... >>>>>> >>>>> >>>>> Hi Martin, >>>>> >>>>> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >>>>> terminal to a (foreground) process group. A process group is >>>>> formed from a pipeline of interconnected processes. Each pipeline >>>>> is considered to be a separate "job", hence shells call this >>>>> feature "job-control". Child processes by default inherit process >>>>> group from it's parent, so children born with Process API (and >>>>> their children) inherit the process group from the JVM process. >>>>> Considering the intentions of shell job-controll, is propagating >>>>> SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by >>>>> Process API desirable? If so, then yes, handling those signals in >>>>> JVM and propagating them to current process group that contains >>>>> all children spawned by Process API and their descendants would >>>>> have to be performed by JVM. That problem would certainly have to >>>>> be addressed. But let's first see what I found out about >>>>> sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), >>>>> etc... >>>>> >>>>> waitpid(-pgid, ...) alone seems to not be enough for our task. >>>>> Mainly because a process can re-assign it's group and join some >>>>> other group. I don't know if this is a situation that occurs in >>>>> real world, but imagine if we have one live child process in a >>>>> process group pgid1 and no unwaited exited children. If we issue: >>>>> >>>>> waitpid(-pgid1, &status, 0); >>>>> >>>>> Then this call blocks, because at the time it was given, there >>>>> were >0 child processes in the pgid1 group and none of them has >>>>> exited yet. Now if this one child process changes it's process >>>>> group with: >>>>> >>>>> setpgid(0, pgid2); >>>>> >>>>> Then the waitpid call in the parent does not return (maybe >>>>> this is >>>>> a bug in Linux?) although there are no more live child processes >>>>> in the pgid1 group any more. Even when this child exits, the call >>>>> to waitpid does not return, since this child is not in the group >>>>> we are waiting for when it exits. If all our children "escape" >>>>> the >>>>> group in such way, the tread doing waiting will never unblock. To >>>>> solve this, we can employ signal handlers. In a signal handler >>>>> for >>>>> SIGCHLD signal we can invoke: >>>>> >>>>> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >>>>> >>>>> ...in loop until it either returns (0) which means that there're >>>>> no more unwaited exited children in the group at the momen or >>>>> (-1) >>>>> with errno == ECHILD, which means that there're no more children >>>>> in the queried group any more - the group does not exist any >>>>> more. >>>>> Since signal handler is invoked whith SIGCHLD being masked and >>>>> there is one bit of pending signal state in the kernel, no child >>>>> exit can be "skipped" this way. Unless the child "escapes" by >>>>> changing it's group. I don't know of a plausible reason for a >>>>> program to change it's process group. If a program executing as >>>>> JVM child wants to become a background daemon it usually behaves >>>>> as follows: >>>>> >>>>> - fork()s a grand-child and then exit()s (so we get notified via >>>>> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >>>>> - the grand-child then changes it's session and group (becomes >>>>> session and group leader), closes file descriptors, etc. The >>>>> responsibility for waiting on the grand-child daemon is >>>>> transferred to the init process (pid=1) since the grand-child >>>>> becomes an orphan (has no parent). >>>>> >>>>> Ignoring this still unsolved problem of possible ill-behaved >>>>> child >>>>> program that changes it's process group, I started constructing a >>>>> proof-of-concept prototype. What I will do in the prototype is >>>>> start throwing IllegalStateException from the methods of the >>>>> Process API that pertain to such children. I think this is >>>>> reasonable. >>>>> >>>>> Stay tuned, >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>>> >>> >>> >> > From xueming.shen at oracle.com Mon Apr 14 17:52:37 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 14 Apr 2014 10:52:37 -0700 Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider In-Reply-To: <53487AD2.5060203@oracle.com> References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com> Message-ID: <534C2065.6010705@oracle.com> Thanks Mandy and Alan for the review. webrev has been updated accordingly to (1) Removed the basic.sh. The tests are now using test.jdk to access the zipfs.jar directly (2) Updated most of the class to package package, only ZipFileSystemProvider (the spi interface) and ZipInfo are public. The ZipInfo is a handy utility sometime I find it useful to simply do java com.sun.nio.zipfs.Info xyz.zip to display all cen and loc tables in details. I may take sometime to find a better home for it later. (3) I have not migrated the test target zipfs.jar to an "independent" test source (created during test) yet, will definitely later in a separate thread when we move to modules. (4) Yes, I mean to keep Demo there as an interactive regression test. http://cr.openjdk.java.net/~sherman/8038500/webrev/ -Sherman On 4/11/14 4:29 PM, Mandy Chung wrote: > On 4/11/2014 3:42 PM, Xueming Shen wrote: >> >> webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev > > It's good to see the source of the zip provider moved to the jdk > repo. You have made some public classes to package-private which is > good. I wonder whether a few remaining public classes can be made > package-private (e.g. ZipFileAttributes, ZipInfo etc). Is > JarFileSystemProvider used anywhere? ZipFileSystemProvider is the > only provider listed in the service configuration. > > Do you mean to make Demo.java as a regression test? > > basic.sh - I wonder if you can get rid of this shell test. Do Basic, > PathOps, ZipFSTester have any relationship? I was thinking if they > can be made as individual java test and constructor the input path of > zipfs.jar. With zipfs.jar part of the jdk build, it will be found > under ${java.home}/lib/ext/zipfs.jar. When we move to modules, this > jar file won't exist. It might be better for the tests to create a > JAR file (one to share by all zipfs tests) to get ready for modules. > > Mandy From ivan.gerasimov at oracle.com Mon Apr 14 18:17:41 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Apr 2014 22:17:41 +0400 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <534C0030.6090902@oracle.com> References: <534BE0F6.6070409@oracle.com> <534C0030.6090902@oracle.com> Message-ID: <534C2645.6090906@oracle.com> Thanks Chris! It's very similar, though still different. ReferenceQueue.remove(timeout) makes sure the timeout has fully elapsed, using System.nanoTime(). Thus the test failure only indicates that nested time intervals measured with nanoTime() and currentTimeMillis() can be inconsistent: The inner interval turns out to be bigger than the outer. But the inner interval is guaranteed to be not less than the timeout specified. Sincerely yours, Ivan On 14.04.2014 19:35, Chris Hegarty wrote: > Are you by any chance running on a VM? We have seen issues like this > before, see > https://bugs.openjdk.java.net/browse/JDK-7148829 > ( as of yet still unresolved) > > -Chris. > > On 14/04/14 14:21, Ivan Gerasimov wrote: >> Hello! >> >> The test EarlyTimeout.java failed again, now with message "elapsed time >> 981 is less than timeout 1000." >> >> The root cause seems to be non-accurate time measurement in Windows: >> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx >> >> >> >> Because of this we can achieve this result: >> long start1 = System.currentTimeMillis(); >> long start2 = System.nanoTime(); >> ~~~~~~~~ >> long elapsed2 = (System.nanoTime() - start2) / 1000000; >> long elapsed1 = System.currentTimeMillis() - start1; >> >> assert elapsed2 < elapsed1; // can fail >> >> >> There might be two ways to address the issue: >> - add a tolerance > 15 ms, or >> - use System.nanoTime() for the measurement. >> >> I did both. >> >> Would you please help review the test fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038982 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8038982/0/webrev/ >> >> Sincerely yours, >> Ivan > > From ivan.gerasimov at oracle.com Mon Apr 14 18:26:29 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Apr 2014 22:26:29 +0400 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <534C0A52.7040707@oracle.com> References: <534BE0F6.6070409@oracle.com> <534C0A52.7040707@oracle.com> Message-ID: <534C2855.6020908@oracle.com> On 14.04.2014 20:18, Mandy Chung wrote: > > On 4/14/2014 6:21 AM, Ivan Gerasimov wrote: >> Hello! >> >> The test EarlyTimeout.java failed again, now with message "elapsed >> time 981 is less than timeout 1000." >> >> The root cause seems to be non-accurate time measurement in Windows: >> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx >> >> >> There might be two ways to address the issue: >> - add a tolerance > 15 ms, or >> - use System.nanoTime() for the measurement. >> >> I did both. >> >> Would you please help review the test fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038982 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8038982/0/webrev/ >> > > Thanks for putting time in getting this test more reliable. Have you > thought about keep zero tolerance (or much smaller value) when the > test is running on *nix platforms? > Actually, zero tolerance should be sufficient now even for Windows platform. Measuring the time with nanoTime() should make the inner and outer time intervals consistent. I've added the tolerance just to play safer. I can remove it. Sincerely yours, Ivan > Mandy > > From ivan.gerasimov at oracle.com Mon Apr 14 18:31:14 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Apr 2014 22:31:14 +0400 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <534C1961.1010204@oracle.com> References: <534BE0F6.6070409@oracle.com> <534C1961.1010204@oracle.com> Message-ID: <534C2972.6030808@oracle.com> Thank you Brent for the pointer! I think that using nanoTime() is simpler in this situation. We don't really have to use currentTimeMillis(), so no need to make it more reliable. Sincerely yours, Ivan On 14.04.2014 21:22, Brent Christian wrote: > Hi, Ivan > > This sounds like an issue we saw in FX a while ago with imprecise > timers on Windows. If it is, you might check out: > > https://bugs.openjdk.java.net/browse/JDK-6435126 > > It describes a workaround to enable higher-precision timing on Windows > (using a long-sleeping daemon thread). That might be a third > alternative solution... > > -Brent > > On 4/14/14 6:21 AM, Ivan Gerasimov wrote: >> Hello! >> >> The test EarlyTimeout.java failed again, now with message "elapsed time >> 981 is less than timeout 1000." >> >> The root cause seems to be non-accurate time measurement in Windows: >> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx >> >> >> >> Because of this we can achieve this result: >> long start1 = System.currentTimeMillis(); >> long start2 = System.nanoTime(); >> ~~~~~~~~ >> long elapsed2 = (System.nanoTime() - start2) / 1000000; >> long elapsed1 = System.currentTimeMillis() - start1; >> >> assert elapsed2 < elapsed1; // can fail >> >> >> There might be two ways to address the issue: >> - add a tolerance > 15 ms, or >> - use System.nanoTime() for the measurement. >> >> I did both. >> >> Would you please help review the test fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038982 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8038982/0/webrev/ >> >> Sincerely yours, >> Ivan > > From Alan.Bateman at oracle.com Mon Apr 14 18:56:46 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Apr 2014 19:56:46 +0100 Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider In-Reply-To: <534C2065.6010705@oracle.com> References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com> <534C2065.6010705@oracle.com> Message-ID: <534C2F6E.5090609@oracle.com> On 14/04/2014 18:52, Xueming Shen wrote: > Thanks Mandy and Alan for the review. > > webrev has been updated accordingly to > > (1) Removed the basic.sh. The tests are now using test.jdk to access > the zipfs.jar directly > (2) Updated most of the class to package package, only > ZipFileSystemProvider (the spi interface) > and ZipInfo are public. > The ZipInfo is a handy utility sometime I find it useful to > simply do java com.sun.nio.zipfs.Info xyz.zip > to display all cen and loc tables in details. I may take sometime > to find a better home for it later. > (3) I have not migrated the test target zipfs.jar to an "independent" > test source (created during test) yet, > will definitely later in a separate thread when we move to modules. > (4) Yes, I mean to keep Demo there as an interactive regression test. > > http://cr.openjdk.java.net/~sherman/8038500/webrev/ > > -Sherman Iris asked me off-list about the name space which makes me wonder if we should use the opportunity to move this to jdk.. As it's a service provider then nothing should be accessing these classes directly. The only thing that comes to mind is ZipFileAttributeView/ZipFileAttributes where the API provides a type-safe means to access attributes. In the webrev then these are being changed to package-private so I think would break anyone that might be using them anyway. The removal of basic.sh and the test tags added the tests looks okay. -Alan. From xueming.shen at oracle.com Mon Apr 14 19:15:16 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 14 Apr 2014 12:15:16 -0700 Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider In-Reply-To: <534C2F6E.5090609@oracle.com> References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com> <534C2065.6010705@oracle.com> <534C2F6E.5090609@oracle.com> Message-ID: <534C33C4.7030400@oracle.com> On 4/14/14 11:56 AM, Alan Bateman wrote: > On 14/04/2014 18:52, Xueming Shen wrote: >> Thanks Mandy and Alan for the review. >> >> webrev has been updated accordingly to >> >> (1) Removed the basic.sh. The tests are now using test.jdk to access >> the zipfs.jar directly >> (2) Updated most of the class to package package, only >> ZipFileSystemProvider (the spi interface) >> and ZipInfo are public. >> The ZipInfo is a handy utility sometime I find it useful to >> simply do java com.sun.nio.zipfs.Info xyz.zip >> to display all cen and loc tables in details. I may take >> sometime to find a better home for it later. >> (3) I have not migrated the test target zipfs.jar to an "independent" >> test source (created during test) yet, >> will definitely later in a separate thread when we move to modules. >> (4) Yes, I mean to keep Demo there as an interactive regression test. >> >> http://cr.openjdk.java.net/~sherman/8038500/webrev/ >> >> -Sherman > Iris asked me off-list about the name space which makes me wonder if > we should use the opportunity to move this to jdk.. As it's > a service provider then nothing should be accessing these classes > directly. The only thing that comes to mind is > ZipFileAttributeView/ZipFileAttributes where the API provides a > type-safe means to access attributes. In the webrev then these are > being changed to package-private so I think would break anyone that > might be using them anyway. > go with jdk.nio.zipfs? I'm fine with that if this is the new directory to go. though it appears we have 1000+ classes at com.sun... -sherman From peter.levart at gmail.com Mon Apr 14 20:57:16 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Apr 2014 22:57:16 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: <534C14A6.7030805@redhat.com> References: <532C7A30.6060904@oracle.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BE786.5010405@oracle.co! m> <534BF12A.6060508@redhat.! com> <534BF296.6060002@oracle.com> <534C0EC7.1040209@gmai! l.com> <534C14A6.7030805@redhat.com> Message-ID: <534C4BAC.7050802@gmail.com> On 04/14/2014 07:02 PM, David M. Lloyd wrote: > On 04/14/2014 11:37 AM, Peter Levart wrote: >> On 04/14/2014 04:37 PM, roger riggs wrote: >>> Hi, >>> >>> Jtreg, for example, needs a reliable way to cleanup after tests. >>> We've had a variety of problems with stray processes left over because >>> there is no visibility nor reliable way to identify and kill them. >>> >>> Roger >> >> Hi Roger, >> >> If you want to reliably get rid of all ancestors then there's only one >> way on UNIX: >> >> >> for (Proc c : enumerateDirectChildrenOfJVM()) { >> getRidOfTreeRootedAt(c); >> } >> >> getRidOfTreeRootedAt(Proc p) { >> // if we're not alive any more, then we can't have children - >> they are >> // orphans and we can't identify them any more (their parent is >> "init") >> if (p.isAlive()) { >> // save list of direct children 1st, since they will be >> re-parented when >> // their parent is gone, preventing enumerating them later... >> List children = p.enumerateDirectChildren(); >> // try gracefull... >> p.terminateGrecefully(); >> // wait a while >> if (p.isAlive()) p.terminateForcefully(); >> // now iterate children >> for (C : children) { >> getRidOfTreeRootedAt(C); >> } >> } >> } > > I don't think this is a good idea. If a grandchild process exits, and > the parent waits() on it, then by the time we get around to iterating > grandchild processes, the OS may have assigned a new process the old > PID. Zombies are pretty much the only reliable way to ensure that the > process is the one we think it is, and we can only reliably do that > for immediate children AFAICT. There's already such a race in current implementation of Process.terminate(). It admittedly only concerns a small window between process exiting and the reaper thread managing to signal this state to the other threads wishing to terminate it at the same time, so it could happen that a KILL/TERM signal is sent to an already deceased PID which was re-used, but it doesn't happen in practice since PIDs are not re-used very soon typically. But I agree, waiting between listing children and sending them signals increases the chance of hitting a reused PID. Regards, Peter > >> >> >> - must 1st terminate the parent (hopefully with grace and it will take >> care of children) because if you kill a child 1st, a persistent parent >> might re-spawn it. >> - must enumerate the children before terminating the parent, because >> they are re-parented when the parent dies and you can't find them any >> more. >> >> >> So my list of requirements for the new API that I submitted in previous >> message: >> >> On 04/14/2014 05:54 PM, Peter Levart wrote: >>> - enumerate direct children (regardless of which API was used to spawn >>> them) of JVM >>> - trigger graceful destruction of any direct child >>> - non-blocking query for liveness of any direct child >>> - trigger forcible termination of any direct child and all descendants >>> in one call >>> - (optionally: obtain a Process object of any live direct child that >>> was spawned by Process API) >> >> ...must be augmented: >> >> - enumerate direct children (regardless of which API was used to spawn >> them) of JVM >> - enumerate direct children of any child enumerated by the API >> - trigger graceful destruction of any ancestor enumerated by the API >> - non-blocking query for liveness of any ancestor enumerated by the API >> - trigger forcible termination of any ancestor enumerated by the API >> - (optionally: obtain a Process object of any live direct JVM child that >> was spawned by Process API) >> >> >> Regards, Peter >> >> >>> >>> >>> On 4/14/2014 10:31 AM, David M. Lloyd wrote: >>>> Where does the requirement to manage grandchild processes actually >>>> come from? I'd hate to see the ability to "nicely" terminate >>>> immediate child processes lost just because it was difficult to >>>> implement some grander scheme. >>>> >>>> On 04/14/2014 08:49 AM, roger riggs wrote: >>>>> Hi Martin, >>>>> >>>>> A new API is needed, overloading the current Process API is not a >>>>> good >>>>> option. >>>>> Even within Process a new method will be needed to destroy the >>>>> subprocess and all >>>>> of its children maintain backward compatibility. >>>>> >>>>> Are there specific OS features that need to be exposed to >>>>> applications? >>>>> Is the destroy-process-and-all-children abstraction too coarse. >>>>> >>>>> Roger >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 4/11/2014 7:37 PM, Martin Buchholz wrote: >>>>>> Let's step back again and try to check our goals... >>>>>> >>>>>> We could try to optimize the one-reaper-thread-per-subprocess thing. >>>>>> But that is risky, and the cost of what we're doing today is not >>>>>> that >>>>>> high. >>>>>> >>>>>> We could try to implement the feature of killing off an entire >>>>>> subprocess tree. But historically, any kind of behavior change like >>>>>> that has been vetoed. I have tried and failed to make less >>>>>> incompatible changes. We would have to add a new API. >>>>>> >>>>>> The reality is that Java does not give you real access to the >>>>>> underlying OS, and unless there's a seriously heterodox attempt to >>>>>> provide OS-specific extensions, people will have to continue to >>>>>> either >>>>>> write native code or delegate to an OS-savvy subprocess like a perl >>>>>> script. >>>>>> >>>>>> >>>>>> On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart >>>>>> >>>>> > wrote: >>>>>> >>>>>> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>>>>>> > wrote: >>>>>>> >>>>>>> Hi Martin, >>>>>>> >>>>>>> As you might have seen in my later reply to Roger, there's >>>>>>> still hope on that front: setpgid() + wait(-pgid, ...) >>>>>>> might >>>>>>> be the answer. I'm exploring in that direction. Shells are >>>>>>> doing it, so why can't JDK? >>>>>>> >>>>>>> It's a little trickier for Process API, since I imagine >>>>>>> that >>>>>>> shells form a group of processes from a pipeline which is >>>>>>> known in-advance while Process API will have to add >>>>>>> processes >>>>>>> to the live group dynamically. So some races will have >>>>>>> to be >>>>>>> resolved, but I think it's doable. >>>>>>> >>>>>>> >>>>>>> This is a clever idea, and it's arguably better to design >>>>>>> subprocesses so they live in separate process groups (emacs >>>>>>> does >>>>>>> that), but: >>>>>>> Every time you create a process group, you change the effect >>>>>>> of a >>>>>>> user signal like Ctrl-C, since it's sent to only one group. >>>>>>> Maybe propagate signals to the subprocess group? It's starting >>>>>>> to get complicated... >>>>>>> >>>>>> >>>>>> Hi Martin, >>>>>> >>>>>> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >>>>>> terminal to a (foreground) process group. A process group is >>>>>> formed from a pipeline of interconnected processes. Each >>>>>> pipeline >>>>>> is considered to be a separate "job", hence shells call this >>>>>> feature "job-control". Child processes by default inherit >>>>>> process >>>>>> group from it's parent, so children born with Process API (and >>>>>> their children) inherit the process group from the JVM process. >>>>>> Considering the intentions of shell job-controll, is propagating >>>>>> SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by >>>>>> Process API desirable? If so, then yes, handling those >>>>>> signals in >>>>>> JVM and propagating them to current process group that contains >>>>>> all children spawned by Process API and their descendants would >>>>>> have to be performed by JVM. That problem would certainly >>>>>> have to >>>>>> be addressed. But let's first see what I found out about >>>>>> sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, >>>>>> ...), >>>>>> etc... >>>>>> >>>>>> waitpid(-pgid, ...) alone seems to not be enough for our task. >>>>>> Mainly because a process can re-assign it's group and join some >>>>>> other group. I don't know if this is a situation that occurs in >>>>>> real world, but imagine if we have one live child process in a >>>>>> process group pgid1 and no unwaited exited children. If we >>>>>> issue: >>>>>> >>>>>> waitpid(-pgid1, &status, 0); >>>>>> >>>>>> Then this call blocks, because at the time it was given, there >>>>>> were >0 child processes in the pgid1 group and none of them has >>>>>> exited yet. Now if this one child process changes it's process >>>>>> group with: >>>>>> >>>>>> setpgid(0, pgid2); >>>>>> >>>>>> Then the waitpid call in the parent does not return (maybe >>>>>> this is >>>>>> a bug in Linux?) although there are no more live child processes >>>>>> in the pgid1 group any more. Even when this child exits, the >>>>>> call >>>>>> to waitpid does not return, since this child is not in the group >>>>>> we are waiting for when it exits. If all our children >>>>>> "escape" the >>>>>> group in such way, the tread doing waiting will never >>>>>> unblock. To >>>>>> solve this, we can employ signal handlers. In a signal >>>>>> handler for >>>>>> SIGCHLD signal we can invoke: >>>>>> >>>>>> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >>>>>> >>>>>> ...in loop until it either returns (0) which means that there're >>>>>> no more unwaited exited children in the group at the momen or >>>>>> (-1) >>>>>> with errno == ECHILD, which means that there're no more children >>>>>> in the queried group any more - the group does not exist any >>>>>> more. >>>>>> Since signal handler is invoked whith SIGCHLD being masked and >>>>>> there is one bit of pending signal state in the kernel, no child >>>>>> exit can be "skipped" this way. Unless the child "escapes" by >>>>>> changing it's group. I don't know of a plausible reason for a >>>>>> program to change it's process group. If a program executing as >>>>>> JVM child wants to become a background daemon it usually behaves >>>>>> as follows: >>>>>> >>>>>> - fork()s a grand-child and then exit()s (so we get notified via >>>>>> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >>>>>> - the grand-child then changes it's session and group (becomes >>>>>> session and group leader), closes file descriptors, etc. The >>>>>> responsibility for waiting on the grand-child daemon is >>>>>> transferred to the init process (pid=1) since the grand-child >>>>>> becomes an orphan (has no parent). >>>>>> >>>>>> Ignoring this still unsolved problem of possible ill-behaved >>>>>> child >>>>>> program that changes it's process group, I started >>>>>> constructing a >>>>>> proof-of-concept prototype. What I will do in the prototype is >>>>>> start throwing IllegalStateException from the methods of the >>>>>> Process API that pertain to such children. I think this is >>>>>> reasonable. >>>>>> >>>>>> Stay tuned, >>>>>> >>>>>> Peter >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > > From david.lloyd at redhat.com Mon Apr 14 22:04:45 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Apr 2014 17:04:45 -0500 Subject: ProcessReaper: single thread reaper In-Reply-To: <534C4BAC.7050802@gmail.com> References: <532C7A30.6060904@oracle.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BE786.5010405@oracle.co! m> <534BF12A.6060508@redhat.! com> <534BF296.6060002@oracle.com> <534C0EC7.1040209@gmai! l.com> <534C14A6.7030805@redhat.com> <534C4BAC.7050802@gmail.com> Message-ID: <534C5B7D.1050900@redhat.com> On 04/14/2014 03:57 PM, Peter Levart wrote: > > On 04/14/2014 07:02 PM, David M. Lloyd wrote: >> On 04/14/2014 11:37 AM, Peter Levart wrote: >>> On 04/14/2014 04:37 PM, roger riggs wrote: >>>> Hi, >>>> >>>> Jtreg, for example, needs a reliable way to cleanup after tests. >>>> We've had a variety of problems with stray processes left over because >>>> there is no visibility nor reliable way to identify and kill them. >>>> >>>> Roger >>> >>> Hi Roger, >>> >>> If you want to reliably get rid of all ancestors then there's only one >>> way on UNIX: >>> >>> >>> for (Proc c : enumerateDirectChildrenOfJVM()) { >>> getRidOfTreeRootedAt(c); >>> } >>> >>> getRidOfTreeRootedAt(Proc p) { >>> // if we're not alive any more, then we can't have children - >>> they are >>> // orphans and we can't identify them any more (their parent is >>> "init") >>> if (p.isAlive()) { >>> // save list of direct children 1st, since they will be >>> re-parented when >>> // their parent is gone, preventing enumerating them later... >>> List children = p.enumerateDirectChildren(); >>> // try gracefull... >>> p.terminateGrecefully(); >>> // wait a while >>> if (p.isAlive()) p.terminateForcefully(); >>> // now iterate children >>> for (C : children) { >>> getRidOfTreeRootedAt(C); >>> } >>> } >>> } >> >> I don't think this is a good idea. If a grandchild process exits, and >> the parent waits() on it, then by the time we get around to iterating >> grandchild processes, the OS may have assigned a new process the old >> PID. Zombies are pretty much the only reliable way to ensure that the >> process is the one we think it is, and we can only reliably do that >> for immediate children AFAICT. > > There's already such a race in current implementation of > Process.terminate(). It admittedly only concerns a small window between > process exiting and the reaper thread managing to signal this state to > the other threads wishing to terminate it at the same time, so it could > happen that a KILL/TERM signal is sent to an already deceased PID which > was re-used, but it doesn't happen in practice since PIDs are not > re-used very soon typically. It seems like it would be trivial enough to introduce a synchronization between the reaper thread and whatever API signals child processes. > But I agree, waiting between listing children and sending them signals > increases the chance of hitting a reused PID. > > Regards, Peter > >> >>> >>> >>> - must 1st terminate the parent (hopefully with grace and it will take >>> care of children) because if you kill a child 1st, a persistent parent >>> might re-spawn it. >>> - must enumerate the children before terminating the parent, because >>> they are re-parented when the parent dies and you can't find them any >>> more. >>> >>> >>> So my list of requirements for the new API that I submitted in previous >>> message: >>> >>> On 04/14/2014 05:54 PM, Peter Levart wrote: >>>> - enumerate direct children (regardless of which API was used to spawn >>>> them) of JVM >>>> - trigger graceful destruction of any direct child >>>> - non-blocking query for liveness of any direct child >>>> - trigger forcible termination of any direct child and all descendants >>>> in one call >>>> - (optionally: obtain a Process object of any live direct child that >>>> was spawned by Process API) >>> >>> ...must be augmented: >>> >>> - enumerate direct children (regardless of which API was used to spawn >>> them) of JVM >>> - enumerate direct children of any child enumerated by the API >>> - trigger graceful destruction of any ancestor enumerated by the API >>> - non-blocking query for liveness of any ancestor enumerated by the API >>> - trigger forcible termination of any ancestor enumerated by the API >>> - (optionally: obtain a Process object of any live direct JVM child that >>> was spawned by Process API) >>> >>> >>> Regards, Peter >>> >>> >>>> >>>> >>>> On 4/14/2014 10:31 AM, David M. Lloyd wrote: >>>>> Where does the requirement to manage grandchild processes actually >>>>> come from? I'd hate to see the ability to "nicely" terminate >>>>> immediate child processes lost just because it was difficult to >>>>> implement some grander scheme. >>>>> >>>>> On 04/14/2014 08:49 AM, roger riggs wrote: >>>>>> Hi Martin, >>>>>> >>>>>> A new API is needed, overloading the current Process API is not a >>>>>> good >>>>>> option. >>>>>> Even within Process a new method will be needed to destroy the >>>>>> subprocess and all >>>>>> of its children maintain backward compatibility. >>>>>> >>>>>> Are there specific OS features that need to be exposed to >>>>>> applications? >>>>>> Is the destroy-process-and-all-children abstraction too coarse. >>>>>> >>>>>> Roger >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 4/11/2014 7:37 PM, Martin Buchholz wrote: >>>>>>> Let's step back again and try to check our goals... >>>>>>> >>>>>>> We could try to optimize the one-reaper-thread-per-subprocess thing. >>>>>>> But that is risky, and the cost of what we're doing today is not >>>>>>> that >>>>>>> high. >>>>>>> >>>>>>> We could try to implement the feature of killing off an entire >>>>>>> subprocess tree. But historically, any kind of behavior change like >>>>>>> that has been vetoed. I have tried and failed to make less >>>>>>> incompatible changes. We would have to add a new API. >>>>>>> >>>>>>> The reality is that Java does not give you real access to the >>>>>>> underlying OS, and unless there's a seriously heterodox attempt to >>>>>>> provide OS-specific extensions, people will have to continue to >>>>>>> either >>>>>>> write native code or delegate to an OS-savvy subprocess like a perl >>>>>>> script. >>>>>>> >>>>>>> >>>>>>> On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> As you might have seen in my later reply to Roger, there's >>>>>>>> still hope on that front: setpgid() + wait(-pgid, ...) >>>>>>>> might >>>>>>>> be the answer. I'm exploring in that direction. Shells are >>>>>>>> doing it, so why can't JDK? >>>>>>>> >>>>>>>> It's a little trickier for Process API, since I imagine >>>>>>>> that >>>>>>>> shells form a group of processes from a pipeline which is >>>>>>>> known in-advance while Process API will have to add >>>>>>>> processes >>>>>>>> to the live group dynamically. So some races will have >>>>>>>> to be >>>>>>>> resolved, but I think it's doable. >>>>>>>> >>>>>>>> >>>>>>>> This is a clever idea, and it's arguably better to design >>>>>>>> subprocesses so they live in separate process groups (emacs >>>>>>>> does >>>>>>>> that), but: >>>>>>>> Every time you create a process group, you change the effect >>>>>>>> of a >>>>>>>> user signal like Ctrl-C, since it's sent to only one group. >>>>>>>> Maybe propagate signals to the subprocess group? It's starting >>>>>>>> to get complicated... >>>>>>>> >>>>>>> >>>>>>> Hi Martin, >>>>>>> >>>>>>> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >>>>>>> terminal to a (foreground) process group. A process group is >>>>>>> formed from a pipeline of interconnected processes. Each >>>>>>> pipeline >>>>>>> is considered to be a separate "job", hence shells call this >>>>>>> feature "job-control". Child processes by default inherit >>>>>>> process >>>>>>> group from it's parent, so children born with Process API (and >>>>>>> their children) inherit the process group from the JVM process. >>>>>>> Considering the intentions of shell job-controll, is propagating >>>>>>> SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by >>>>>>> Process API desirable? If so, then yes, handling those >>>>>>> signals in >>>>>>> JVM and propagating them to current process group that contains >>>>>>> all children spawned by Process API and their descendants would >>>>>>> have to be performed by JVM. That problem would certainly >>>>>>> have to >>>>>>> be addressed. But let's first see what I found out about >>>>>>> sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, >>>>>>> ...), >>>>>>> etc... >>>>>>> >>>>>>> waitpid(-pgid, ...) alone seems to not be enough for our task. >>>>>>> Mainly because a process can re-assign it's group and join some >>>>>>> other group. I don't know if this is a situation that occurs in >>>>>>> real world, but imagine if we have one live child process in a >>>>>>> process group pgid1 and no unwaited exited children. If we >>>>>>> issue: >>>>>>> >>>>>>> waitpid(-pgid1, &status, 0); >>>>>>> >>>>>>> Then this call blocks, because at the time it was given, there >>>>>>> were >0 child processes in the pgid1 group and none of them has >>>>>>> exited yet. Now if this one child process changes it's process >>>>>>> group with: >>>>>>> >>>>>>> setpgid(0, pgid2); >>>>>>> >>>>>>> Then the waitpid call in the parent does not return (maybe >>>>>>> this is >>>>>>> a bug in Linux?) although there are no more live child processes >>>>>>> in the pgid1 group any more. Even when this child exits, the >>>>>>> call >>>>>>> to waitpid does not return, since this child is not in the group >>>>>>> we are waiting for when it exits. If all our children >>>>>>> "escape" the >>>>>>> group in such way, the tread doing waiting will never >>>>>>> unblock. To >>>>>>> solve this, we can employ signal handlers. In a signal >>>>>>> handler for >>>>>>> SIGCHLD signal we can invoke: >>>>>>> >>>>>>> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >>>>>>> >>>>>>> ...in loop until it either returns (0) which means that there're >>>>>>> no more unwaited exited children in the group at the momen or >>>>>>> (-1) >>>>>>> with errno == ECHILD, which means that there're no more children >>>>>>> in the queried group any more - the group does not exist any >>>>>>> more. >>>>>>> Since signal handler is invoked whith SIGCHLD being masked and >>>>>>> there is one bit of pending signal state in the kernel, no child >>>>>>> exit can be "skipped" this way. Unless the child "escapes" by >>>>>>> changing it's group. I don't know of a plausible reason for a >>>>>>> program to change it's process group. If a program executing as >>>>>>> JVM child wants to become a background daemon it usually behaves >>>>>>> as follows: >>>>>>> >>>>>>> - fork()s a grand-child and then exit()s (so we get notified via >>>>>>> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >>>>>>> - the grand-child then changes it's session and group (becomes >>>>>>> session and group leader), closes file descriptors, etc. The >>>>>>> responsibility for waiting on the grand-child daemon is >>>>>>> transferred to the init process (pid=1) since the grand-child >>>>>>> becomes an orphan (has no parent). >>>>>>> >>>>>>> Ignoring this still unsolved problem of possible ill-behaved >>>>>>> child >>>>>>> program that changes it's process group, I started >>>>>>> constructing a >>>>>>> proof-of-concept prototype. What I will do in the prototype is >>>>>>> start throwing IllegalStateException from the methods of the >>>>>>> Process API that pertain to such children. I think this is >>>>>>> reasonable. >>>>>>> >>>>>>> Stay tuned, >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> > -- - DML From mike.duigou at oracle.com Mon Apr 14 22:54:54 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 14 Apr 2014 15:54:54 -0700 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: References: <533255B1.7020400@oracle.com> <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> Message-ID: <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> Hello all; Sorry for the delay in following up on this issue. I have collected responses to the various comments and will provide responses here. - Regarding the performance impact of the changes and of RTM. Valdimir Kozlov provided the following results from a run on a Haswell CPU system: > threads=4 Interval=10000 CPUs=4 MapSize=2048 Population=1024 P10G80R10 > > > Without RTM locking, without Hashtable changes: > > 2080 iterations/msec > > Without RTM locking, with Hashtable changes (-Xbootclasspath/p:Hashtable124.jar): > > 2140 iterations/msec > > With RTM locking (-XX:+UseRTMLocking), without Hashtable changes: > > 23500 iterations/ms > > With RTM locking, with Hashtable changes: > > 33100 iterations/ms > > > Numbers are average from 3 runs. They v[a]ry about 6-8%. The benchmark is a slightly adapted version of the Hashtable benchmark used in Dave Dice's ASPLOS 2009 "Rock" paper [1] - Regarding hotspot or javac doing the desired code movements. Neither compiler will currently move assignments past conditional logic and it isn't likely this will change in the near future. While it would be foolish to restructure all of our code for "compiler behaviour of the week" it does seem prudent to do so very selectively when we know that the behaviour is not going to soon change and the benefits are significant. - Regarding potential loss of fast-fail behaviour. Vector is unaffected because reads and co-mod checks are always done under synchronization. Enumerations from Hashtable elements() and keys() methods offer no fast-fail behaviour though they may see different behaviour as a result of this change. The Hashtable entrySet().iterator(), keySet().iterator() and values().iterator() will have the existing behaviour when the illegal modification occurs on the same thread as iteration. When the modification occurs on a different thread then it is possible that different behaviour may be observed. Since the Hashtable Iterator modCount check occurs without synchronization the ordering of visible writes is unspecified until the lock on Hashtable is released. In the meantime neither, either or both writes may be visible. In RTM, updates to modCount would not be visible to unsynchronized readers regardless of placement within the synchronized block. We may just have to accept this limitation of Hashtable Iterators--they should really be holding the lock during next() if the fast-fail is to be reliable. Should we proceed forward despite these understood limitations? My vote is a very soft "Yes". Mike [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.143.8940&rep=rep1&type=pdf On Apr 4 2014, at 02:07 , Paul Sandoz wrote: > On Apr 4, 2014, at 1:42 AM, Mike Duigou wrote: >>> >>> I could live with that change in behaviour, but this change completely breaks the fail-fast semantics of the iterators in some cases! If you don't update modCount until after the change is complete, the iterator may access the updated state and not throw CME!. >> >> For Vector I don't see this. The Iterator accesses to the data structures is always done with the Vector.this lock held. The re-ordering would only be observable to another thread if it is reading the Vector fields without holding the lock. I am not sure we should worry about that case. >> > > Agreed, i don't see how that can happen. > > >> For Hashtable Iterator there is no synchronization on the owning Hashtable except during the remove() method. It is unclear why the Hashtable iterators were not written in the same way as Vector. > > Dunno. > > >> It seems like there would be massive disruption to adding synchronization to Hashtable's itertors. Are the Hashtable iterators actually fast-fail? > > They are fail fast only from within the same thread when the control is inverted via iterator (like that for non-synchronized HashMap etc), otherwise it is necessary to explicitly synchronize on the iterator, much like that for Collections.synchronized* methods, see the implementation: > > public Set keySet() { > if (keySet == null) > keySet = Collections.synchronizedSet(new KeySet(), this); > return keySet; > } > > The documentation for keySet etc. states: > > * reflected in the set, and vice-versa. If the map is modified > * while an iteration over the set is in progress (except through > * the iterator's own remove operation), the results of > * the iteration are undefined. The set supports element removal, > > > The documentation on the enumeration methods does not say anything. > > We should probably update the documentation to additionally say something like that on Collections.synchronized* methods. > > >> Without synchronization this is not guaranteed since the writes may not be visible and Hashtable iterator failure behaviour is already likely to vary between platforms/architectures. With RTM it's presumed that the writes will NOT be visible until the transaction completes. This implies that the failure mode from Hashtable iterators is likely to change just by turning RTM locking on whether we make this code change or not. :-( >> > >>> I think this change is misguided. >> >> I think we are fine for Vector, but Hashtable gives me concerns even in it's current state. >> > > I don't think the current situation is made any worse by your changes. > > The are some subtle changes with regards parameter checking and throwing exceptions, but that does not seems to be very important behaviour to preserve. > > Paul. From martinrb at google.com Tue Apr 15 01:25:05 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 14 Apr 2014 18:25:05 -0700 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> References: <533255B1.7020400@oracle.com> <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> Message-ID: I'll retreat to being neutral on the overall idea. In general, it *is* a best software engineering practice to do all the reading and computing before doing all the writing at the end. You'll break anyone who does the crazy thing of intentionally calling add(null, Integer.MAX_VALUE) just for the side effect of incrementing modCount. How would _you_ increment modCount without doing any modding?! You could make a real improvement (more concurrency) for addAll, by moving the call to toArray out of the synchronized block. public synchronized boolean addAll(Collection c) { - modCount++; Object[] a = c.toArray(); It's hardly worth it for e.g. clear, where you are doing nothing but writes in the loop as well. public synchronized void clear() { Entry tab[] = table; - modCount++; for (int index = tab.length; --index >= 0; ) tab[index] = null; + modCount++; count = 0; } On Mon, Apr 14, 2014 at 3:54 PM, Mike Duigou wrote: > Hello all; > > Sorry for the delay in following up on this issue. I have collected > responses to the various comments and will provide responses here. > > - Regarding the performance impact of the changes and of RTM. Valdimir > Kozlov provided the following results from a run on a Haswell CPU system: > > > threads=4 Interval=10000 CPUs=4 MapSize=2048 Population=1024 P10G80R10 > > > > > > Without RTM locking, without Hashtable changes: > > > > 2080 iterations/msec > > > > Without RTM locking, with Hashtable changes > (-Xbootclasspath/p:Hashtable124.jar): > > > > 2140 iterations/msec > > > > With RTM locking (-XX:+UseRTMLocking), without Hashtable changes: > > > > 23500 iterations/ms > > > > With RTM locking, with Hashtable changes: > > > > 33100 iterations/ms > > > > > > Numbers are average from 3 runs. They v[a]ry about 6-8%. > > The benchmark is a slightly adapted version of the Hashtable benchmark > used in Dave Dice's ASPLOS 2009 "Rock" paper [1] > > - Regarding hotspot or javac doing the desired code movements. Neither > compiler will currently move assignments past conditional logic and it > isn't likely this will change in the near future. While it would be foolish > to restructure all of our code for "compiler behaviour of the week" it does > seem prudent to do so very selectively when we know that the behaviour is > not going to soon change and the benefits are significant. > > - Regarding potential loss of fast-fail behaviour. Vector is unaffected > because reads and co-mod checks are always done under synchronization. > Enumerations from Hashtable elements() and keys() methods offer no > fast-fail behaviour though they may see different behaviour as a result of > this change. The Hashtable entrySet().iterator(), keySet().iterator() and > values().iterator() will have the existing behaviour when the illegal > modification occurs on the same thread as iteration. When the modification > occurs on a different thread then it is possible that different behaviour > may be observed. Since the Hashtable Iterator modCount check occurs without > synchronization the ordering of visible writes is unspecified until the > lock on Hashtable is released. In the meantime neither, either or both > writes may be visible. In RTM, updates to modCount would not be visible to > unsynchronized readers regardless of placement within the synchronized > block. We may just have to accept this limitation of Hashtable > Iterators--they should really be holding the lock during next() if the > fast-fail is to be reliable. > > Should we proceed forward despite these understood limitations? My vote is > a very soft "Yes". > > Mike > > > [1] > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.143.8940&rep=rep1&type=pdf > > > On Apr 4 2014, at 02:07 , Paul Sandoz wrote: > > > On Apr 4, 2014, at 1:42 AM, Mike Duigou wrote: > >>> > >>> I could live with that change in behaviour, but this change completely > breaks the fail-fast semantics of the iterators in some cases! If you don't > update modCount until after the change is complete, the iterator may access > the updated state and not throw CME!. > >> > >> For Vector I don't see this. The Iterator accesses to the data > structures is always done with the Vector.this lock held. The re-ordering > would only be observable to another thread if it is reading the Vector > fields without holding the lock. I am not sure we should worry about that > case. > >> > > > > Agreed, i don't see how that can happen. > > > > > >> For Hashtable Iterator there is no synchronization on the owning > Hashtable except during the remove() method. It is unclear why the > Hashtable iterators were not written in the same way as Vector. > > > > Dunno. > > > > > >> It seems like there would be massive disruption to adding > synchronization to Hashtable's itertors. Are the Hashtable iterators > actually fast-fail? > > > > They are fail fast only from within the same thread when the control is > inverted via iterator (like that for non-synchronized HashMap etc), > otherwise it is necessary to explicitly synchronize on the iterator, much > like that for Collections.synchronized* methods, see the implementation: > > > > public Set keySet() { > > if (keySet == null) > > keySet = Collections.synchronizedSet(new KeySet(), this); > > return keySet; > > } > > > > The documentation for keySet etc. states: > > > > * reflected in the set, and vice-versa. If the map is modified > > * while an iteration over the set is in progress (except through > > * the iterator's own remove operation), the results of > > * the iteration are undefined. The set supports element removal, > > > > > > The documentation on the enumeration methods does not say anything. > > > > We should probably update the documentation to additionally say > something like that on Collections.synchronized* methods. > > > > > >> Without synchronization this is not guaranteed since the writes may not > be visible and Hashtable iterator failure behaviour is already likely to > vary between platforms/architectures. With RTM it's presumed that the > writes will NOT be visible until the transaction completes. This implies > that the failure mode from Hashtable iterators is likely to change just by > turning RTM locking on whether we make this code change or not. :-( > >> > > > >>> I think this change is misguided. > >> > >> I think we are fine for Vector, but Hashtable gives me concerns even in > it's current state. > >> > > > > I don't think the current situation is made any worse by your changes. > > > > The are some subtle changes with regards parameter checking and throwing > exceptions, but that does not seems to be very important behaviour to > preserve. > > > > Paul. > > From mandy.chung at oracle.com Tue Apr 15 02:23:07 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Apr 2014 19:23:07 -0700 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <534C2855.6020908@oracle.com> References: <534BE0F6.6070409@oracle.com> <534C0A52.7040707@oracle.com> <534C2855.6020908@oracle.com> Message-ID: <534C980B.2000408@oracle.com> On 4/14/2014 11:26 AM, Ivan Gerasimov wrote: > Actually, zero tolerance should be sufficient now even for Windows > platform. > Measuring the time with nanoTime() should make the inner and outer > time intervals consistent. > > I've added the tolerance just to play safer. > I can remove it. That'd be even better! thanks Mandy From xueming.shen at oracle.com Tue Apr 15 03:48:44 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 14 Apr 2014 20:48:44 -0700 Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider In-Reply-To: <534C33C4.7030400@oracle.com> References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com> <534C2065.6010705@oracle.com> <534C2F6E.5090609@oracle.com> <534C33C4.7030400@oracle.com> Message-ID: <534CAC1C.8000405@oracle.com> Hi, webrev has been updated to use the name space jdk.nio.zipfs. http://cr.openjdk.java.net/~sherman/8038500/webrev/ -Sherman On 4/14/14 12:15 PM, Xueming Shen wrote: > On 4/14/14 11:56 AM, Alan Bateman wrote: >> On 14/04/2014 18:52, Xueming Shen wrote: >>> Thanks Mandy and Alan for the review. >>> >>> webrev has been updated accordingly to >>> >>> (1) Removed the basic.sh. The tests are now using test.jdk to access >>> the zipfs.jar directly >>> (2) Updated most of the class to package package, only >>> ZipFileSystemProvider (the spi interface) >>> and ZipInfo are public. >>> The ZipInfo is a handy utility sometime I find it useful to >>> simply do java com.sun.nio.zipfs.Info xyz.zip >>> to display all cen and loc tables in details. I may take >>> sometime to find a better home for it later. >>> (3) I have not migrated the test target zipfs.jar to an >>> "independent" test source (created during test) yet, >>> will definitely later in a separate thread when we move to >>> modules. >>> (4) Yes, I mean to keep Demo there as an interactive regression test. >>> >>> http://cr.openjdk.java.net/~sherman/8038500/webrev/ >>> >>> -Sherman >> Iris asked me off-list about the name space which makes me wonder if >> we should use the opportunity to move this to jdk.. As >> it's a service provider then nothing should be accessing these >> classes directly. The only thing that comes to mind is >> ZipFileAttributeView/ZipFileAttributes where the API provides a >> type-safe means to access attributes. In the webrev then these are >> being changed to package-private so I think would break anyone that >> might be using them anyway. >> > > go with jdk.nio.zipfs? I'm fine with that if this is the new directory > to go. though it appears we have 1000+ classes at com.sun... > > -sherman From peter.levart at gmail.com Tue Apr 15 05:50:06 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 15 Apr 2014 07:50:06 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: <534C5B7D.1050900@redhat.com> References: <532C7A30.6060904@oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BE786.5010405@oracle.co! m> <534BF12A.6060508@redhat.! com> <534BF296.6060002@oracle.com> <534C0EC7.1040209@gmai! l.com> <534C14A6.7030805@redhat.com> <534C4BAC.7050802@gmail.com> <534C5B7D.1050900@redhat.com> Message-ID: <534CC88E.4080607@gmail.com> On 04/15/2014 12:04 AM, David M. Lloyd wrote: >> There's already such a race in current implementation of >> Process.terminate(). It admittedly only concerns a small window between >> process exiting and the reaper thread managing to signal this state to >> the other threads wishing to terminate it at the same time, so it could >> happen that a KILL/TERM signal is sent to an already deceased PID which >> was re-used, but it doesn't happen in practice since PIDs are not >> re-used very soon typically. > > It seems like it would be trivial enough to introduce a > synchronization between the reaper thread and whatever API signals > child processes. Not really. Reaper thread(s) wait in system call (waitpid()), so holding a mutex while waiting would prevent other threads from killing the process. After the call returns, the PID is already released and could theoretically be re-used. But in practice this is really not a problem. Regards, Peter From ivan.gerasimov at oracle.com Tue Apr 15 06:10:06 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 15 Apr 2014 10:10:06 +0400 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <534C980B.2000408@oracle.com> References: <534BE0F6.6070409@oracle.com> <534C0A52.7040707@oracle.com> <534C2855.6020908@oracle.com> <534C980B.2000408@oracle.com> Message-ID: <534CCD3E.2080500@oracle.com> On 15.04.2014 6:23, Mandy Chung wrote: > On 4/14/2014 11:26 AM, Ivan Gerasimov wrote: >> Actually, zero tolerance should be sufficient now even for Windows >> platform. >> Measuring the time with nanoTime() should make the inner and outer >> time intervals consistent. >> >> I've added the tolerance just to play safer. >> I can remove it. > > That'd be even better! > Alright, I removed the tolerance back. So now the only change is how the time interval is measured: http://cr.openjdk.java.net/~igerasim/8038982/1/webrev/ Sincerely yours, Ivan > thanks > Mandy > > From david.holmes at oracle.com Tue Apr 15 06:48:01 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Apr 2014 16:48:01 +1000 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <534CCD3E.2080500@oracle.com> References: <534BE0F6.6070409@oracle.com> <534C0A52.7040707@oracle.com> <534C2855.6020908@oracle.com> <534C980B.2000408@oracle.com> <534CCD3E.2080500@oracle.com> Message-ID: <534CD621.6060901@oracle.com> On 15/04/2014 4:10 PM, Ivan Gerasimov wrote: > > On 15.04.2014 6:23, Mandy Chung wrote: >> On 4/14/2014 11:26 AM, Ivan Gerasimov wrote: >>> Actually, zero tolerance should be sufficient now even for Windows >>> platform. >>> Measuring the time with nanoTime() should make the inner and outer >>> time intervals consistent. >>> >>> I've added the tolerance just to play safer. >>> I can remove it. >> >> That'd be even better! >> > Alright, I removed the tolerance back. > So now the only change is how the time interval is measured: > > http://cr.openjdk.java.net/~igerasim/8038982/1/webrev/ This is the right change to make. I'm a little surprised we are seeing these timing problems though. That said the resolution of timed blocking calls and the resolution of currentTimeMillis() can be quite different on any platform, not just windows. In general nanoTime should always be used to measure elapsed time. Thanks, David > Sincerely yours, > Ivan > >> thanks >> Mandy >> >> > From daniel.fuchs at oracle.com Tue Apr 15 06:54:14 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 15 Apr 2014 08:54:14 +0200 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <534CD621.6060901@oracle.com> References: <534BE0F6.6070409@oracle.com> <534C0A52.7040707@oracle.com> <534C2855.6020908@oracle.com> <534C980B.2000408@oracle.com> <534CCD3E.2080500@oracle.com> <534CD621.6060901@oracle.com> Message-ID: <534CD796.4060309@oracle.com> Hi guys, Should 'actual' and 'reference' be declared as volatile? I see that they are accessed from main() after joining the threads. Or does joining the threads guarantees that 'main' will see the right values? best regards, -- daniel On 4/15/14 8:48 AM, David Holmes wrote: > On 15/04/2014 4:10 PM, Ivan Gerasimov wrote: >> >> On 15.04.2014 6:23, Mandy Chung wrote: >>> On 4/14/2014 11:26 AM, Ivan Gerasimov wrote: >>>> Actually, zero tolerance should be sufficient now even for Windows >>>> platform. >>>> Measuring the time with nanoTime() should make the inner and outer >>>> time intervals consistent. >>>> >>>> I've added the tolerance just to play safer. >>>> I can remove it. >>> >>> That'd be even better! >>> >> Alright, I removed the tolerance back. >> So now the only change is how the time interval is measured: >> >> http://cr.openjdk.java.net/~igerasim/8038982/1/webrev/ > > This is the right change to make. > > I'm a little surprised we are seeing these timing problems though. > That said the resolution of timed blocking calls and the resolution of > currentTimeMillis() can be quite different on any platform, not just > windows. In general nanoTime should always be used to measure elapsed > time. > > Thanks, > David > >> Sincerely yours, >> Ivan >> >>> thanks >>> Mandy >>> >>> >> From david.holmes at oracle.com Tue Apr 15 07:22:18 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Apr 2014 17:22:18 +1000 Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider In-Reply-To: <534CAC1C.8000405@oracle.com> References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com> <534C2065.6010705@oracle.com> <534C2F6E.5090609@oracle.com> <534C33C4.7030400@oracle.com> <534CAC1C.8000405@oracle.com> Message-ID: <534CDE2A.2030407@oracle.com> Hi Sherman, Can you confirm that the intent is that this remains only available in a full JRE and not in any Compact Profile? Thanks, David On 15/04/2014 1:48 PM, Xueming Shen wrote: > Hi, > > webrev has been updated to use the name space jdk.nio.zipfs. > > http://cr.openjdk.java.net/~sherman/8038500/webrev/ > > -Sherman > > On 4/14/14 12:15 PM, Xueming Shen wrote: >> On 4/14/14 11:56 AM, Alan Bateman wrote: >>> On 14/04/2014 18:52, Xueming Shen wrote: >>>> Thanks Mandy and Alan for the review. >>>> >>>> webrev has been updated accordingly to >>>> >>>> (1) Removed the basic.sh. The tests are now using test.jdk to access >>>> the zipfs.jar directly >>>> (2) Updated most of the class to package package, only >>>> ZipFileSystemProvider (the spi interface) >>>> and ZipInfo are public. >>>> The ZipInfo is a handy utility sometime I find it useful to >>>> simply do java com.sun.nio.zipfs.Info xyz.zip >>>> to display all cen and loc tables in details. I may take >>>> sometime to find a better home for it later. >>>> (3) I have not migrated the test target zipfs.jar to an >>>> "independent" test source (created during test) yet, >>>> will definitely later in a separate thread when we move to >>>> modules. >>>> (4) Yes, I mean to keep Demo there as an interactive regression test. >>>> >>>> http://cr.openjdk.java.net/~sherman/8038500/webrev/ >>>> >>>> -Sherman >>> Iris asked me off-list about the name space which makes me wonder if >>> we should use the opportunity to move this to jdk.. As >>> it's a service provider then nothing should be accessing these >>> classes directly. The only thing that comes to mind is >>> ZipFileAttributeView/ZipFileAttributes where the API provides a >>> type-safe means to access attributes. In the webrev then these are >>> being changed to package-private so I think would break anyone that >>> might be using them anyway. >>> >> >> go with jdk.nio.zipfs? I'm fine with that if this is the new directory >> to go. though it appears we have 1000+ classes at com.sun... >> >> -sherman > From paul.sandoz at oracle.com Tue Apr 15 07:23:58 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 15 Apr 2014 09:23:58 +0200 Subject: PING! Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <1E0F511F-4A17-4A88-9D63-83A2154FDC6D@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> <53307892.4020805@gmail.com> <1E0F511F-4A17-4A88-9D63-83A2154FDC6D@oracle.com> Message-ID: <2C8313DE-B562-407E-9BBC-880E3F782568@oracle.com> Hi Brian, My inclination is "if it ain't broke... " and AFAICT nothing indicates toString it is particular broken [*], so perhaps just focus on the cleanup aspects and revisit the other when the JMM is updated (and maybe enhanced volatiles is ready)? Paul. [*] although i still question the use of thread locals, but that is a separate issue that requires more investigation and i don't know if if can be improved. On Apr 10, 2014, at 10:45 PM, Brian Burkhalter wrote: > Second day back from vacation so I guess it?s time to beat this horse again ? > > As there was no response to the message included below I am simply re-posting it. > > Thanks, > > Brian > > On Mar 25, 2014, at 7:19 AM, Brian Burkhalter wrote: > >> On Mar 25, 2014, at 1:58 AM, Paul Sandoz wrote: >> >>> This is another example of a stable variable. >>> >>> I would like to re-iterate my scepticism that such changes are necessary in this case (i am not sure if it is possible to create a benchmark that could better exacerbate the concurrent overlap of calls to layoutChars). But, i do agree the discussion has been useful and interesting. >> >> I am happy either to leave the toString() code as it is or to change it to the variant with toStringSlow(). There is however other cleanup in the patch to consider. So it would be good to get consensus on the two points: >> >> 1) Change toString() to variant using toStringSlow() or leave it as-is. >> 2) Change non-toString() code as indicated in the patch or leave it as-is. >> >> If ?as-is? is the answer in both cases, then it?s simply a matter of resolving the enhancement as ?not an issue.? >> >> Thanks, >> >> Brian > From david.holmes at oracle.com Tue Apr 15 07:25:30 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Apr 2014 17:25:30 +1000 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <534CD796.4060309@oracle.com> References: <534BE0F6.6070409@oracle.com> <534C0A52.7040707@oracle.com> <534C2855.6020908@oracle.com> <534C980B.2000408@oracle.com> <534CCD3E.2080500@oracle.com> <534CD621.6060901@oracle.com> <534CD796.4060309@oracle.com> Message-ID: <534CDEEA.8020805@oracle.com> On 15/04/2014 4:54 PM, Daniel Fuchs wrote: > Hi guys, > > Should 'actual' and 'reference' be declared as volatile? > > I see that they are accessed from main() after joining the threads. > Or does joining the threads guarantees that 'main' will see the right > values? Yes. If you join() a Thread you are guaranteed to see all writes performed by that Thread before it terminated. (Similarly a newly started Thread sees all writes performed by the Thread that called start() on it.) David > best regards, > > -- daniel > > On 4/15/14 8:48 AM, David Holmes wrote: >> On 15/04/2014 4:10 PM, Ivan Gerasimov wrote: >>> >>> On 15.04.2014 6:23, Mandy Chung wrote: >>>> On 4/14/2014 11:26 AM, Ivan Gerasimov wrote: >>>>> Actually, zero tolerance should be sufficient now even for Windows >>>>> platform. >>>>> Measuring the time with nanoTime() should make the inner and outer >>>>> time intervals consistent. >>>>> >>>>> I've added the tolerance just to play safer. >>>>> I can remove it. >>>> >>>> That'd be even better! >>>> >>> Alright, I removed the tolerance back. >>> So now the only change is how the time interval is measured: >>> >>> http://cr.openjdk.java.net/~igerasim/8038982/1/webrev/ >> >> This is the right change to make. >> >> I'm a little surprised we are seeing these timing problems though. >> That said the resolution of timed blocking calls and the resolution of >> currentTimeMillis() can be quite different on any platform, not just >> windows. In general nanoTime should always be used to measure elapsed >> time. >> >> Thanks, >> David >> >>> Sincerely yours, >>> Ivan >>> >>>> thanks >>>> Mandy >>>> >>>> >>> > From paul.sandoz at oracle.com Tue Apr 15 07:46:34 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 15 Apr 2014 09:46:34 +0200 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> References: <533255B1.7020400@oracle.com> <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> Message-ID: On Apr 15, 2014, at 12:54 AM, Mike Duigou wrote: > Should we proceed forward despite these understood limitations? My vote is a very soft "Yes". > I think we can proceed, things are not made any worse for the cases we care about, and i think we can slightly improve things as Martin suggests, plus we can update the documentation on enumerators and iterators. Paul. From luchsh at linux.vnet.ibm.com Tue Apr 15 07:48:35 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 15 Apr 2014 15:48:35 +0800 Subject: Improve timezone mapping for AIX platform In-Reply-To: <534B7A25.7070800@oracle.com> References: <53329D98.6040002@oracle.com> <534B7A25.7070800@oracle.com> Message-ID: Hi Masayoshi, Volker, Thanks a lot for reviewing ! Is it OK for me to push the change into JDK9 directly ? or need another reviewer's approval ? Many thanks Jonathan On Mon, Apr 14, 2014 at 2:03 PM, Masayoshi Okutsu < masayoshi.okutsu at oracle.com> wrote: > Looks good to me. > > Thanks, > Masayoshi > > > On 4/11/2014 10:46 PM, Volker Simonis wrote: > > Hi Jonathan, > > thank you for fixing all the remaining issues. From my point of view this > change looks good now. > > @Masayoshi: can I please get a final approval from you for pushing the > change? I also want to downport this to 8u-dev but I don't think that's a > big deal as this only touches AX code. > > Thank you and best regards, > Volker > > On Thu, Apr 10, 2014 at 11:44 AM, Jonathan Lu wrote: > >> Hi Volker, >> >> Thanks a lot for your comments, I've made another patch, >> >> http://cr.openjdk.java.net/~luchsh/JDK-8Masayoshi034220.v4/ >> >> >> On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis wrote: >> >>> Hi Jonathan, >>> >>> sorry, but I found a few more issues: >>> >>> - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise >>> somebody could easily crash the VM by specifying a TZ with more than >>> 100 characters. >>> >> >> Right, I've fix it by using strncpy, and also updated another usage of >> strcmp(). >> >> >> >>> >>> - you can delete the lines 871-872 because the variables are actually >>> not used and you can also remove the handling for "timezone == 0" >>> because that is actually done in getGMTOffsetID() anyway. >>> >> >> Nice catch, have deleted those in latest patch. >> >> >>> >>> - could you please avoid the usage of strtok. It is not intended for >>> usage in a multithreaded environment (see for example "man strtok" on >>> AIX). strtok_r is probably overkill, but you could use for example >>> strchr. >>> >> >> I've changed it to strtok_r in this patch, >> although strtok was only used once here, it may still impact other >> threads. >> >> >>> did you check the build on Windows? >>> >> >> Yes, both patches got built on Windows. >> >> >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu >>> wrote: >>> > Hi Volker, Masayoshi, >>> > >>> > I made another patch which fixed the problems mentioned in last mail, >>> > >>> > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ >>> > >>> > Could you pls help to take a look? >>> > >>> > Many thanks >>> > Jonathan >>> > >>> > >>> > >>> > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu < >>> luchsh at linux.vnet.ibm.com> >>> > wrote: >>> >> >>> >> Hi Volker, >>> >> >>> >> >>> >> On 2014?04?02? 23:07, Volker Simonis wrote: >>> >> >>> >> Hi Jonathan, >>> >> >>> >> thanks for updating the change. Please find my comments inline: >>> >> >>> >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu < >>> luchsh at linux.vnet.ibm.com> >>> >> wrote: >>> >> >>> >> Hi Volker, Masayoshi, >>> >> >>> >> Thanks a lot for your review, here's the updated patch, could you pls >>> take >>> >> a >>> >> look? >>> >> >>> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ >>> >> >>> >> >>> >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis < >>> volker.simonis at gmail.com> >>> >> wrote: >>> >> >>> >> Hi Jonathan, >>> >> >>> >> thanks for doing this change. Please find some comments below: >>> >> >>> >> 1. please update the copyright year to 2014 in every file you touch >>> >> >>> >> Updated in new patch. >>> >> >>> >> 2. in CopyFiles.gmk you can simplify the change by joining the windows >>> >> and aix cases because on Windows OPENJDK_TARGET_OS is the same like >>> >> OPENJDK_TARGET_OS_API_DIR. So you can write: >>> >> >>> >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) >>> >> >>> >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib >>> >> >>> >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings >>> >> $(call install-file) >>> >> >>> >> COPY_FILES += $(LIBDIR)/tzmappings >>> >> >>> >> endif >>> >> >>> >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is >>> >> 'solaris' >>> >> as I observed on my AIX box, >>> >> solaris/lib is not the directory where tzmappings was stored for AIX. >>> >> So I'm keeping this change, please fix me if I was wrong about the >>> config. >>> >> >>> >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the >>> >> construction of TZMAPPINGS_SRC as shown in the code snippet above. >>> >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX >>> >> and that should be just enough here. >>> >> >>> >> >>> >> That's right, let me try that and also build/test on Windows >>> platform. >>> >> >>> >> >>> >> 3. regarding the changes proposed by Masayoshi: I agree that we should >>> >> put the AIX timezone mapping code in its own function, but I don't >>> >> think that getPlatformTimeZoneID() would be the right place. As far as >>> >> I understand, getPlatformTimeZoneID() is used to get a platform time >>> >> zone id if the environment variable "TZ" is not set. I don't know a >>> >> way how this could be done on AIX (@Jonathan: maybe you know?). If >>> >> there would be a way to get the time zone from some system files or >>> >> so, then we should put this code into the AIX version of >>> >> getPlatformTimeZoneID(). >>> >> >>> >> I guess we may try to use /etc/envrionment file, which is basic >>> setting >>> >> for >>> >> all processes, >>> >> see >>> >> >>> >> >>> http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm >>> >> The implementation of getPlatformTimeZoneID() has been updated. >>> >> >>> >> That's good! >>> >> >>> >> But the current AIX code contributed by Jonathan, actually uses the >>> >> time zone id from the "TZ" environment variable and just maps it to a >>> >> Java compatible time zone id. So I'd suggest to refactor this code >>> >> into a function like for example "static const char* >>> >> mapPlatformToJavaTimzone(const char* tz)" and call that from >>> >> findJavaTZ_md(). I think that would make the code easier to >>> >> understand. >>> >> >>> >> Agree, and have split the code into a separate static method to do the >>> >> mapping work. >>> >> >>> >> Good. But there's still one error in findJavaTZ_md(): >>> >> >>> >> 706 #ifdef _AIX >>> >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); >>> >> 708 #endif >>> >> >>> >> This should read: >>> >> >>> >> 706 #ifdef _AIX >>> >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, >>> javatz); >>> >> 708 #endif >>> >> >>> >> because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came >>> >> from getPlatformTimeZoneID(). >>> >> >>> >> >>> >> Right, but with the second approach, there may be a minor memory leak >>> >> here, >>> >> as javatz was not freed before being overwritten on AIX. will post >>> another >>> >> patch on this soon. >>> >> >>> >> >>> >> With the above fixed I'll push this one we get one more review from a >>> >> reviewer (I'm currently not an official reviewer). >>> >> >>> >> Regards, >>> >> Volker >>> >> >>> >> >>> >> @Masayoshi: what do you think, would you agree with such a solution. >>> >> >>> >> 4. I agree with Masayoshi that you should use the existing >>> >> getGMTOffsetID() >>> >> >>> >> Updated in new patch to eliminate duplication. >>> >> >>> >> 5. Please notice that your change breaks all Unix builds except AIX >>> >> because of: >>> >> >>> >> 759 } >>> >> 760 tzerr: >>> >> 761 if (javatz == NULL) { >>> >> 762 time_t offset; >>> >> ... >>> >> 782 } >>> >> 783 #endif >>> >> >>> >> I think that should read: >>> >> >>> >> 759 >>> >> 760 tzerr: >>> >> 761 if (javatz == NULL) { >>> >> 762 time_t offset; >>> >> ... >>> >> 782 } >>> >> 783 #endif >>> >> 784 } >>> >> >>> >> Refactoring the code in an extra function will make that error more >>> >> evident anyway. >>> >> >>> >> But please always build at least on one different platform (i.e. >>> >> Linux) to prevent such errors in the future. >>> >> >>> >> My fault, sorry for the failure, should take no chance after any >>> manual >>> >> alteration. >>> >> >>> >> Regards, >>> >> Volker >>> >> >>> >> >>> >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu >>> >> wrote: >>> >> >>> >> Hi Jonathan, >>> >> >>> >> The AIX specific code looks OK to me. But I'd suggest the code be >>> moved >>> >> to >>> >> getPlatformTimeZoneID() for AIX, which just returns NULL currently. >>> Also >>> >> there's a function for producing a fallback ID in "GMT?hh:mm", >>> >> getGMTOffsetID() which can be called in tzerr. >>> >> >>> >> Thanks, >>> >> Masayoshi >>> >> >>> >> >>> >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: >>> >> >>> >> Hi ppc-aix-port-dev, core-libs-dev, >>> >> >>> >> Here's a patch for JDK-8034220, >>> >> >>> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ >>> >> >>> >> It is trying to add the a more complete timezone mapping mechanism for >>> >> AIX >>> >> platform. >>> >> the changes are primarily based on IBM's commercial JDK code, which >>> >> includes: >>> >> >>> >> - A new timezone mapping file added under directory jdk/src/aix/lib/ >>> >> - Code to parse above config file, changed file is >>> >> src/solaris/native/java/util/TimeZone_md.c >>> >> - And also makefile change in make/CopyFiles.gmk to copy the config >>> >> file >>> >> >>> >> Could you pls help to review and give comments ? >>> >> >>> >> Cheers >>> >> - Jonathan >>> >> >>> >> Many thanks >>> >> Jonathan >>> >> >>> >> Regards >>> >> Jonathan >>> > >>> > >>> >> >> Regards >> Jonathan >> > > > From erik.joelsson at oracle.com Tue Apr 15 07:48:37 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 15 Apr 2014 09:48:37 +0200 Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider In-Reply-To: <534C2065.6010705@oracle.com> References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com> <534C2065.6010705@oracle.com> Message-ID: <534CE455.1090809@oracle.com> Hello Sherman, The build changes look good to me. /Erik On 2014-04-14 19:52, Xueming Shen wrote: > Thanks Mandy and Alan for the review. > > webrev has been updated accordingly to > > (1) Removed the basic.sh. The tests are now using test.jdk to access > the zipfs.jar directly > (2) Updated most of the class to package package, only > ZipFileSystemProvider (the spi interface) > and ZipInfo are public. > The ZipInfo is a handy utility sometime I find it useful to > simply do java com.sun.nio.zipfs.Info xyz.zip > to display all cen and loc tables in details. I may take sometime > to find a better home for it later. > (3) I have not migrated the test target zipfs.jar to an "independent" > test source (created during test) yet, > will definitely later in a separate thread when we move to modules. > (4) Yes, I mean to keep Demo there as an interactive regression test. > > http://cr.openjdk.java.net/~sherman/8038500/webrev/ > > -Sherman > > On 4/11/14 4:29 PM, Mandy Chung wrote: >> On 4/11/2014 3:42 PM, Xueming Shen wrote: >>> >>> webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev >> >> It's good to see the source of the zip provider moved to the jdk >> repo. You have made some public classes to package-private which is >> good. I wonder whether a few remaining public classes can be made >> package-private (e.g. ZipFileAttributes, ZipInfo etc). Is >> JarFileSystemProvider used anywhere? ZipFileSystemProvider is the >> only provider listed in the service configuration. >> >> Do you mean to make Demo.java as a regression test? >> >> basic.sh - I wonder if you can get rid of this shell test. Do Basic, >> PathOps, ZipFSTester have any relationship? I was thinking if they >> can be made as individual java test and constructor the input path of >> zipfs.jar. With zipfs.jar part of the jdk build, it will be found >> under ${java.home}/lib/ext/zipfs.jar. When we move to modules, this >> jar file won't exist. It might be better for the tests to create a >> JAR file (one to share by all zipfs tests) to get ready for modules. >> >> Mandy > From richard.warburton at gmail.com Tue Apr 15 08:05:50 2014 From: richard.warburton at gmail.com (Richard Warburton) Date: Tue, 15 Apr 2014 09:05:50 +0100 Subject: Covariant overrides on the Buffer Hierachy Message-ID: Hi, I'd like to have a discussion about tidying up a few core library method signatures in a way that (I think) is backwards compatible. I've been using ByteBuffer quite a lot recently which is designed to be a fluent API. Unfortunately its quite inconvenient to use because there's a hierarchy of classes at play (MappedByteBuffer, ByteBuffer and Buffer) and methods which are inherited from parent classes aren't overridden with covariant return types. For example the following code doesn't compile because clear is defined on Buffer and putInt is defined on ByteBuffer. ByteBuffer buffer = ByteBuffer.allocate(256); ByteBuffer other = buffer.duplicate() .clear() .putInt(0, 4); If clear was overridden in ByteBuffer with ByteBuffer as its return type then this would compile. Now I can appreciate that these classes were introduced in Java 1.4, which was before covariant overriding was possible, but I was wondering what the situation was with fixing it. To my mind, and by all means correct me if I've overlooked something, changing these methods to return their own type rather than the parent type should be backwards compatible at the source and binary levels. The only issue that I'm aware of that is related to this kind of change is the requirement to recompile all the classes in the hierarchy when making a change [0]. If you don't do this its possible for an infinite recursion and eventual stackoverflow to occur. Now as far as I can tell the entire hierarchy of Buffer classes are all either package scoped classes, or they are public classes with package scoped constructors. So I'm not aware of a way to sub class them without the code being part of the JDK. This would mean that the subclasses all need to be recompiled, satisfying the safety criteria. I'd be most appreciative of any feedback on this issue. regards, Richard Warburton http://insightfullogic.com @RichardWarburto [0] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/009119.html (thanks to Stuart Marks for pointing this one out to me) From Alan.Bateman at oracle.com Tue Apr 15 08:46:13 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Apr 2014 09:46:13 +0100 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: References: Message-ID: <534CF1D5.70605@oracle.com> On 15/04/2014 09:05, Richard Warburton wrote: > : > > The only issue that I'm aware of that is related to this kind of change is > the requirement to recompile all the classes in the hierarchy when making a > change [0]. If you don't do this its possible for an infinite recursion and > eventual stackoverflow to occur. Now as far as I can tell the > entire hierarchy of Buffer classes are all either package scoped classes, > or they are public classes with package scoped constructors. So I'm not > aware of a way to sub class them without the code being part of the JDK. > This would mean that the subclasses all need to be recompiled, satisfying > the safety criteria. > This is a long standing bug to look at this issue [1]. CharBuffer.subSequence was one case that was retrofitted in 7. As you note, buffers are not designed to be extended outside of the java.nio package so this should make a number of options possible. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-4774077 From volker.simonis at gmail.com Tue Apr 15 08:50:34 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 15 Apr 2014 10:50:34 +0200 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> <534B7A25.7070800@oracle.com> Message-ID: You can push it to jdk9-dev directly. No other reviewer is required. Regards, Volker On Tue, Apr 15, 2014 at 9:48 AM, Jonathan Lu wrote: > Hi Masayoshi, Volker, > > Thanks a lot for reviewing ! > Is it OK for me to push the change into JDK9 directly ? or need another > reviewer's approval ? > > Many thanks > Jonathan > > > > On Mon, Apr 14, 2014 at 2:03 PM, Masayoshi Okutsu > wrote: >> >> Looks good to me. >> >> Thanks, >> Masayoshi >> >> >> On 4/11/2014 10:46 PM, Volker Simonis wrote: >> >> Hi Jonathan, >> >> thank you for fixing all the remaining issues. From my point of view this >> change looks good now. >> >> @Masayoshi: can I please get a final approval from you for pushing the >> change? I also want to downport this to 8u-dev but I don't think that's a >> big deal as this only touches AX code. >> >> Thank you and best regards, >> Volker >> >> On Thu, Apr 10, 2014 at 11:44 AM, Jonathan Lu >> wrote: >>> >>> Hi Volker, >>> >>> Thanks a lot for your comments, I've made another patch, >>> >>> http://cr.openjdk.java.net/~luchsh/JDK-8Masayoshi034220.v4/ >>> >>> >>> On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis >>> wrote: >>>> >>>> Hi Jonathan, >>>> >>>> sorry, but I found a few more issues: >>>> >>>> - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise >>>> somebody could easily crash the VM by specifying a TZ with more than >>>> 100 characters. >>> >>> >>> Right, I've fix it by using strncpy, and also updated another usage of >>> strcmp(). >>> >>> >>>> >>>> >>>> - you can delete the lines 871-872 because the variables are actually >>>> not used and you can also remove the handling for "timezone == 0" >>>> because that is actually done in getGMTOffsetID() anyway. >>> >>> >>> Nice catch, have deleted those in latest patch. >>> >>>> >>>> >>>> - could you please avoid the usage of strtok. It is not intended for >>>> usage in a multithreaded environment (see for example "man strtok" on >>>> AIX). strtok_r is probably overkill, but you could use for example >>>> strchr. >>> >>> >>> I've changed it to strtok_r in this patch, >>> although strtok was only used once here, it may still impact other >>> threads. >>> >>>> >>>> did you check the build on Windows? >>> >>> >>> Yes, both patches got built on Windows. >>> >>>> >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> >>>> On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu >>>> wrote: >>>> > Hi Volker, Masayoshi, >>>> > >>>> > I made another patch which fixed the problems mentioned in last mail, >>>> > >>>> > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ >>>> > >>>> > Could you pls help to take a look? >>>> > >>>> > Many thanks >>>> > Jonathan >>>> > >>>> > >>>> > >>>> > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu >>>> > >>>> > wrote: >>>> >> >>>> >> Hi Volker, >>>> >> >>>> >> >>>> >> On 2014?04?02? 23:07, Volker Simonis wrote: >>>> >> >>>> >> Hi Jonathan, >>>> >> >>>> >> thanks for updating the change. Please find my comments inline: >>>> >> >>>> >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu >>>> >> >>>> >> wrote: >>>> >> >>>> >> Hi Volker, Masayoshi, >>>> >> >>>> >> Thanks a lot for your review, here's the updated patch, could you pls >>>> >> take >>>> >> a >>>> >> look? >>>> >> >>>> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ >>>> >> >>>> >> >>>> >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis >>>> >> >>>> >> wrote: >>>> >> >>>> >> Hi Jonathan, >>>> >> >>>> >> thanks for doing this change. Please find some comments below: >>>> >> >>>> >> 1. please update the copyright year to 2014 in every file you touch >>>> >> >>>> >> Updated in new patch. >>>> >> >>>> >> 2. in CopyFiles.gmk you can simplify the change by joining the >>>> >> windows >>>> >> and aix cases because on Windows OPENJDK_TARGET_OS is the same like >>>> >> OPENJDK_TARGET_OS_API_DIR. So you can write: >>>> >> >>>> >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) >>>> >> >>>> >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib >>>> >> >>>> >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings >>>> >> $(call install-file) >>>> >> >>>> >> COPY_FILES += $(LIBDIR)/tzmappings >>>> >> >>>> >> endif >>>> >> >>>> >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is >>>> >> 'solaris' >>>> >> as I observed on my AIX box, >>>> >> solaris/lib is not the directory where tzmappings was stored for AIX. >>>> >> So I'm keeping this change, please fix me if I was wrong about the >>>> >> config. >>>> >> >>>> >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the >>>> >> construction of TZMAPPINGS_SRC as shown in the code snippet above. >>>> >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX >>>> >> and that should be just enough here. >>>> >> >>>> >> >>>> >> That's right, let me try that and also build/test on Windows >>>> >> platform. >>>> >> >>>> >> >>>> >> 3. regarding the changes proposed by Masayoshi: I agree that we >>>> >> should >>>> >> put the AIX timezone mapping code in its own function, but I don't >>>> >> think that getPlatformTimeZoneID() would be the right place. As far >>>> >> as >>>> >> I understand, getPlatformTimeZoneID() is used to get a platform time >>>> >> zone id if the environment variable "TZ" is not set. I don't know a >>>> >> way how this could be done on AIX (@Jonathan: maybe you know?). If >>>> >> there would be a way to get the time zone from some system files or >>>> >> so, then we should put this code into the AIX version of >>>> >> getPlatformTimeZoneID(). >>>> >> >>>> >> I guess we may try to use /etc/envrionment file, which is basic >>>> >> setting >>>> >> for >>>> >> all processes, >>>> >> see >>>> >> >>>> >> >>>> >> http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm >>>> >> The implementation of getPlatformTimeZoneID() has been updated. >>>> >> >>>> >> That's good! >>>> >> >>>> >> But the current AIX code contributed by Jonathan, actually uses the >>>> >> time zone id from the "TZ" environment variable and just maps it to a >>>> >> Java compatible time zone id. So I'd suggest to refactor this code >>>> >> into a function like for example "static const char* >>>> >> mapPlatformToJavaTimzone(const char* tz)" and call that from >>>> >> findJavaTZ_md(). I think that would make the code easier to >>>> >> understand. >>>> >> >>>> >> Agree, and have split the code into a separate static method to do >>>> >> the >>>> >> mapping work. >>>> >> >>>> >> Good. But there's still one error in findJavaTZ_md(): >>>> >> >>>> >> 706 #ifdef _AIX >>>> >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); >>>> >> 708 #endif >>>> >> >>>> >> This should read: >>>> >> >>>> >> 706 #ifdef _AIX >>>> >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, >>>> >> javatz); >>>> >> 708 #endif >>>> >> >>>> >> because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came >>>> >> from getPlatformTimeZoneID(). >>>> >> >>>> >> >>>> >> Right, but with the second approach, there may be a minor memory leak >>>> >> here, >>>> >> as javatz was not freed before being overwritten on AIX. will post >>>> >> another >>>> >> patch on this soon. >>>> >> >>>> >> >>>> >> With the above fixed I'll push this one we get one more review from a >>>> >> reviewer (I'm currently not an official reviewer). >>>> >> >>>> >> Regards, >>>> >> Volker >>>> >> >>>> >> >>>> >> @Masayoshi: what do you think, would you agree with such a solution. >>>> >> >>>> >> 4. I agree with Masayoshi that you should use the existing >>>> >> getGMTOffsetID() >>>> >> >>>> >> Updated in new patch to eliminate duplication. >>>> >> >>>> >> 5. Please notice that your change breaks all Unix builds except AIX >>>> >> because of: >>>> >> >>>> >> 759 } >>>> >> 760 tzerr: >>>> >> 761 if (javatz == NULL) { >>>> >> 762 time_t offset; >>>> >> ... >>>> >> 782 } >>>> >> 783 #endif >>>> >> >>>> >> I think that should read: >>>> >> >>>> >> 759 >>>> >> 760 tzerr: >>>> >> 761 if (javatz == NULL) { >>>> >> 762 time_t offset; >>>> >> ... >>>> >> 782 } >>>> >> 783 #endif >>>> >> 784 } >>>> >> >>>> >> Refactoring the code in an extra function will make that error more >>>> >> evident anyway. >>>> >> >>>> >> But please always build at least on one different platform (i.e. >>>> >> Linux) to prevent such errors in the future. >>>> >> >>>> >> My fault, sorry for the failure, should take no chance after any >>>> >> manual >>>> >> alteration. >>>> >> >>>> >> Regards, >>>> >> Volker >>>> >> >>>> >> >>>> >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu >>>> >> wrote: >>>> >> >>>> >> Hi Jonathan, >>>> >> >>>> >> The AIX specific code looks OK to me. But I'd suggest the code be >>>> >> moved >>>> >> to >>>> >> getPlatformTimeZoneID() for AIX, which just returns NULL currently. >>>> >> Also >>>> >> there's a function for producing a fallback ID in "GMT?hh:mm", >>>> >> getGMTOffsetID() which can be called in tzerr. >>>> >> >>>> >> Thanks, >>>> >> Masayoshi >>>> >> >>>> >> >>>> >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: >>>> >> >>>> >> Hi ppc-aix-port-dev, core-libs-dev, >>>> >> >>>> >> Here's a patch for JDK-8034220, >>>> >> >>>> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ >>>> >> >>>> >> It is trying to add the a more complete timezone mapping mechanism >>>> >> for >>>> >> AIX >>>> >> platform. >>>> >> the changes are primarily based on IBM's commercial JDK code, which >>>> >> includes: >>>> >> >>>> >> - A new timezone mapping file added under directory jdk/src/aix/lib/ >>>> >> - Code to parse above config file, changed file is >>>> >> src/solaris/native/java/util/TimeZone_md.c >>>> >> - And also makefile change in make/CopyFiles.gmk to copy the config >>>> >> file >>>> >> >>>> >> Could you pls help to review and give comments ? >>>> >> >>>> >> Cheers >>>> >> - Jonathan >>>> >> >>>> >> Many thanks >>>> >> Jonathan >>>> >> >>>> >> Regards >>>> >> Jonathan >>>> > >>>> > >>> >>> >>> Regards >>> Jonathan >> >> >> > From Alan.Bateman at oracle.com Tue Apr 15 08:56:21 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Apr 2014 09:56:21 +0100 Subject: RFR: [8039396] NPE when writing a class descriptor object to a custom ObjectOutputStream In-Reply-To: <5347A162.3080909@oracle.com> References: <5347A162.3080909@oracle.com> Message-ID: <534CF435.7070101@oracle.com> On 11/04/2014 09:01, Ivan Gerasimov wrote: > Hello everybody! > > ObjectStreamClass#forClass() function is allowed to return null, if > the local VM does not have the corresponding local class. > Because of that, NPE can be encountered during serialization through a > subclass of ObjectOutputStream. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8039396 > WEBREV: http://cr.openjdk.java.net/~igerasim/8039396/0/webrev/ The fix looks okay to me, a bit of a corner case but okay. The test looks useful. A minor suggestion is to shorten the lines a bit to make future side-by-side reviews easier. -Alan. From Alan.Bateman at oracle.com Tue Apr 15 09:00:30 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Apr 2014 10:00:30 +0100 Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider In-Reply-To: <534CAC1C.8000405@oracle.com> References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com> <534C2065.6010705@oracle.com> <534C2F6E.5090609@oracle.com> <534C33C4.7030400@oracle.com> <534CAC1C.8000405@oracle.com> Message-ID: <534CF52E.5040403@oracle.com> On 15/04/2014 04:48, Xueming Shen wrote: > Hi, > > webrev has been updated to use the name space jdk.nio.zipfs. > > http://cr.openjdk.java.net/~sherman/8038500/webrev/ > Thanks, I think this makes sense. For further down the road then consideration could be given to make ZipFileAttributes/ZipFileAttributeView public and supported so as to provide type safe access to zip specific attributes. JarFileSystemProvider will also need discussion at some point to decide whether it should be added to the service configuration file so that JAR URLs are supported. -Alan. ** From ivan.gerasimov at oracle.com Tue Apr 15 12:49:03 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 15 Apr 2014 16:49:03 +0400 Subject: RFR: [8039396] NPE when writing a class descriptor object to a custom ObjectOutputStream In-Reply-To: <534CF435.7070101@oracle.com> References: <5347A162.3080909@oracle.com> <534CF435.7070101@oracle.com> Message-ID: <534D2ABF.6030901@oracle.com> Thank you Alan! I'll reformat the test before pushing to make it fit into the half of the screen. Sincerely yours, Ivan On 15.04.2014 12:56, Alan Bateman wrote: > On 11/04/2014 09:01, Ivan Gerasimov wrote: >> Hello everybody! >> >> ObjectStreamClass#forClass() function is allowed to return null, if >> the local VM does not have the corresponding local class. >> Because of that, NPE can be encountered during serialization through >> a subclass of ObjectOutputStream. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8039396 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8039396/0/webrev/ > The fix looks okay to me, a bit of a corner case but okay. > > The test looks useful. A minor suggestion is to shorten the lines a > bit to make future side-by-side reviews easier. > > -Alan. > > From alexander.v.stepanov at oracle.com Tue Apr 15 13:11:31 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Tue, 15 Apr 2014 17:11:31 +0400 Subject: [9] Review Request for 8030709: Tidy warnings cleanup for java.lang package In-Reply-To: <53465545.4060307@oracle.com> References: <53465511.5090606@oracle.com> <53465545.4060307@oracle.com> Message-ID: <534D3003.9070102@oracle.com> Sorry, the webrev was updated to include one other minor change in javax/script/ScriptEngineFactory.java to avoid creation of separate review request: http://cr.openjdk.java.net/~yan/8030709/webrev.01/ Regards, Alexander On 10.04.2014 12:24, alexander stepanov wrote: > > BigInteger.java from java.lang was also touched. > sorry, from java.math > > On 10.04.2014 12:23, alexander stepanov wrote: >> Hello, >> >> Could you please review the fix for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8030709 >> >> Webrev corresponding: >> http://cr.openjdk.java.net/~yan/8030709/webrev.00/ >> >> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >> affected. >> >> BigInteger.java from java.lang was also touched. >> >> Thanks. >> >> Regards, >> Alexander > From Lance.Andersen at oracle.com Tue Apr 15 13:24:19 2014 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Tue, 15 Apr 2014 09:24:19 -0400 Subject: [9] Review Request for 8030709: Tidy warnings cleanup for java.lang package In-Reply-To: <534D3003.9070102@oracle.com> References: <53465511.5090606@oracle.com> <53465545.4060307@oracle.com> <534D3003.9070102@oracle.com> Message-ID: looks ok On Apr 15, 2014, at 9:11 AM, alexander stepanov wrote: > Sorry, the webrev was updated to include one other minor change in javax/script/ScriptEngineFactory.java to avoid creation of separate review request: > http://cr.openjdk.java.net/~yan/8030709/webrev.01/ > > Regards, > Alexander > > On 10.04.2014 12:24, alexander stepanov wrote: >> > BigInteger.java from java.lang was also touched. >> sorry, from java.math >> >> On 10.04.2014 12:23, alexander stepanov wrote: >>> Hello, >>> >>> Could you please review the fix for the following bug: >>> https://bugs.openjdk.java.net/browse/JDK-8030709 >>> >>> Webrev corresponding: >>> http://cr.openjdk.java.net/~yan/8030709/webrev.00/ >>> >>> Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. >>> >>> BigInteger.java from java.lang was also touched. >>> >>> Thanks. >>> >>> Regards, >>> Alexander >> > 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 Tue Apr 15 14:20:28 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Tue, 15 Apr 2014 18:20:28 +0400 Subject: [9] Review Request for 8030709: Tidy warnings cleanup for java.lang package In-Reply-To: References: <53465511.5090606@oracle.com> <53465545.4060307@oracle.com> <534D3003.9070102@oracle.com> Message-ID: <534D402C.3050307@oracle.com> thanks! On 15.04.2014 17:24, Lance Andersen wrote: > looks ok > On Apr 15, 2014, at 9:11 AM, alexander stepanov > > wrote: > >> Sorry, the webrev was updated to include one other minor change in >> javax/script/ScriptEngineFactory.java to avoid creation of separate >> review request: >> http://cr.openjdk.java.net/~yan/8030709/webrev.01/ >> >> >> Regards, >> Alexander >> >> On 10.04.2014 12:24, alexander stepanov wrote: >>> > BigInteger.java from java.lang was also touched. >>> sorry, from java.math >>> >>> On 10.04.2014 12:23, alexander stepanov wrote: >>>> Hello, >>>> >>>> Could you please review the fix for the following bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8030709 >>>> >>>> Webrev corresponding: >>>> http://cr.openjdk.java.net/~yan/8030709/webrev.00/ >>>> >>>> Just a minor cleanup of javadoc to avoid tidy warnings; no other >>>> code affected. >>>> >>>> BigInteger.java from java.lang was also touched. >>>> >>>> Thanks. >>>> >>>> Regards, >>>> Alexander >>> >> > > > > 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 brian.burkhalter at oracle.com Tue Apr 15 16:24:34 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 15 Apr 2014 09:24:34 -0700 Subject: PING! Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <2C8313DE-B562-407E-9BBC-880E3F782568@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> <53307892.4020805@gmail.com> <1E0F511F-4A17-4A88-9D63-83A2154FDC6D@oracle.com> <2C8313DE-B562-407E-9BBC-880E3F782568@oracle.com> Message-ID: <60E7A3E0-8621-4BE3-B3DF-B42A2673BC5D@oracle.com> Hi Paul, On Apr 15, 2014, at 12:23 AM, Paul Sandoz wrote: > Hi Brian, > > My inclination is "if it ain't broke... " and AFAICT nothing indicates toString it is particular broken [*], so perhaps just focus on the cleanup aspects and revisit the other when the JMM is updated (and maybe enhanced volatiles is ready)? > > Paul. Fine by me. I?ll update the webrev. The other aspects could come under this issue already on file: https://bugs.openjdk.java.net/browse/JDK-8033491. Thanks, Brian > [*] although i still question the use of thread locals, but that is a separate issue that requires more investigation and i don't know if if can be improved. From xueming.shen at oracle.com Tue Apr 15 16:43:05 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 15 Apr 2014 09:43:05 -0700 Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider In-Reply-To: <534CDE2A.2030407@oracle.com> References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com> <534C2065.6010705@oracle.com> <534C2F6E.5090609@oracle.com> <534C33C4.7030400@oracle.com> <534CAC1C.8000405@oracle.com> <534CDE2A.2030407@oracle.com> Message-ID: <534D6199.2030706@oracle.com> Hi David, yes, it's the intent to make it only available in full jre, for now. Thanks! -Sherman On 4/15/14 12:22 AM, David Holmes wrote: > Hi Sherman, > > Can you confirm that the intent is that this remains only available in > a full JRE and not in any Compact Profile? > > Thanks, > David > > On 15/04/2014 1:48 PM, Xueming Shen wrote: >> Hi, >> >> webrev has been updated to use the name space jdk.nio.zipfs. >> >> http://cr.openjdk.java.net/~sherman/8038500/webrev/ >> >> -Sherman >> >> On 4/14/14 12:15 PM, Xueming Shen wrote: >>> On 4/14/14 11:56 AM, Alan Bateman wrote: >>>> On 14/04/2014 18:52, Xueming Shen wrote: >>>>> Thanks Mandy and Alan for the review. >>>>> >>>>> webrev has been updated accordingly to >>>>> >>>>> (1) Removed the basic.sh. The tests are now using test.jdk to access >>>>> the zipfs.jar directly >>>>> (2) Updated most of the class to package package, only >>>>> ZipFileSystemProvider (the spi interface) >>>>> and ZipInfo are public. >>>>> The ZipInfo is a handy utility sometime I find it useful to >>>>> simply do java com.sun.nio.zipfs.Info xyz.zip >>>>> to display all cen and loc tables in details. I may take >>>>> sometime to find a better home for it later. >>>>> (3) I have not migrated the test target zipfs.jar to an >>>>> "independent" test source (created during test) yet, >>>>> will definitely later in a separate thread when we move to >>>>> modules. >>>>> (4) Yes, I mean to keep Demo there as an interactive regression test. >>>>> >>>>> http://cr.openjdk.java.net/~sherman/8038500/webrev/ >>>>> >>>>> -Sherman >>>> Iris asked me off-list about the name space which makes me wonder if >>>> we should use the opportunity to move this to jdk.. As >>>> it's a service provider then nothing should be accessing these >>>> classes directly. The only thing that comes to mind is >>>> ZipFileAttributeView/ZipFileAttributes where the API provides a >>>> type-safe means to access attributes. In the webrev then these are >>>> being changed to package-private so I think would break anyone that >>>> might be using them anyway. >>>> >>> >>> go with jdk.nio.zipfs? I'm fine with that if this is the new directory >>> to go. though it appears we have 1000+ classes at com.sun... >>> >>> -sherman >> From Ulf.Zibis at CoSoCo.de Tue Apr 15 16:47:13 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 15 Apr 2014 18:47:13 +0200 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <5346F6D1.2050203@oracle.com> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <53467211.8070405@CoSoCo.de> <5346B6C6.2000908@oracle.com> <5346F05C.6010604@CoSoCo.de> <5346F6D1.2050203@oracle.com> Message-ID: <534D6291.9090604@CoSoCo.de> Am 10.04.2014 21:53, schrieb Tim Bell: > On 04/10/14 19:26, Ulf Zibis wrote: >> BTW, where are these links gone: > > This part of the question I can handle. > > The six digit Bug numbers came from the legacy OpenJDK bugzilla instance. > > Before it was shut down, those bug reports were transferred to JBS. In the process, they were > assigned new JDK-nnnnnnn bug numbers, so you will be able to view them on the new system: > > In general, if you saved an old Bugzilla ID (six digits, for example 100092), you should be able > to find it in JBS by visiting this URL: > > https://bugs.openjdk.java.net/issues/?jql= > > And doing a simple search for the string "id=100092" > > > Hope this helps- Much thanks Tim. But where are the original attachments e.g. webrevs, patches ? Are they lost forever ? -Ulf From mandy.chung at oracle.com Tue Apr 15 16:55:33 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Apr 2014 09:55:33 -0700 Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider In-Reply-To: <534CAC1C.8000405@oracle.com> References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com> <534C2065.6010705@oracle.com> <534C2F6E.5090609@oracle.com> <534C33C4.7030400@oracle.com> <534CAC1C.8000405@oracle.com> Message-ID: <534D6485.7030202@oracle.com> On 4/14/14 8:48 PM, Xueming Shen wrote: > Hi, > > webrev has been updated to use the name space jdk.nio.zipfs. > > http://cr.openjdk.java.net/~sherman/8038500/webrev/ This patch looks fine. JarFileSystemProvider is currently not used and it's fine to include it as it will need discussion to decide if this should be added in the service configuration file as Alan suggests. thanks Mandy From Ulf.Zibis at CoSoCo.de Tue Apr 15 16:56:49 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 15 Apr 2014 18:56:49 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: References: Message-ID: <534D64D1.2060508@CoSoCo.de> Hi, Am 15.04.2014 10:05, schrieb Richard Warburton: > Hi, > > I'd like to have a discussion about tidying up a few core library method > signatures in a way that (I think) is backwards compatible. > > I've been using ByteBuffer quite a lot recently which is designed to be a > fluent API. Unfortunately its quite inconvenient to use because there's a > hierarchy of classes at play (MappedByteBuffer, ByteBuffer and Buffer) and > methods which are inherited from parent classes aren't overridden with > covariant return types. For example the following code doesn't compile > because clear is defined on Buffer and putInt is defined on ByteBuffer. > > ByteBuffer buffer = ByteBuffer.allocate(256); > > ByteBuffer other = buffer.duplicate() > .clear() > .putInt(0, 4); > > If clear was overridden in ByteBuffer with ByteBuffer as its return type > then this would compile. See also: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-April/001512.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-April/001365.html http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html https://bugs.openjdk.java.net/browse/JDK-6472931 https://bugs.openjdk.java.net/browse/JDK-6373386 https://bugs.openjdk.java.net/browse/JDK-6479372 https://bugs.openjdk.java.net/browse/JDK-4774077 https://bugs.openjdk.java.net/browse/JDK-6451131 https://bugs.openjdk.java.net/browse/JDK-5082736 -Ulf From ivan.gerasimov at oracle.com Tue Apr 15 17:13:28 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 15 Apr 2014 21:13:28 +0400 Subject: String.indexOf optimization In-Reply-To: References: Message-ID: <534D68B8.3040002@oracle.com> Hi everyone! On 04.04.2014 21:13, Martin Buchholz wrote: > Summary: > > Many people (myself included) have looked at this problem. It's unlikely > that String.indexOf will change. It's hard to beat the naive > implementation in the typical case. But we can try to speed up this naive implementation a little bit. We can separate the special case: When the substring's length == 1. This special case can be done fast, and in the general case we can now assume substring's length is at least 2. Here's the webrev with the implementation of this idea: http://cr.openjdk.java.net/~igerasim/indexof/0/webrev/ I've done some benchmarking with JMH and found no performance degradation on my machine. Of course, more testcases should be created and they should be tried on different machines to be treated as reliable. Benchmark Mode Thr Cnt Sec Mean Mean error Units o.b.IndexOfBench.benchIndexOf_1_A avgt 1 20 5 704.739 9.104 nsec/op o.b.IndexOfBench.benchIndexOf_1_B avgt 1 20 5 *573.879* 9.820 nsec/op o.b.IndexOfBench.benchIndexOf_2_A avgt 1 20 5 668.455 9.882 nsec/op o.b.IndexOfBench.benchIndexOf_2_B avgt 1 20 5 *476.062* 6.063 nsec/op o.b.IndexOfBench.benchIndexOf_3_A avgt 1 20 5 155.227 1.796 nsec/op o.b.IndexOfBench.benchIndexOf_3_B avgt 1 20 5 *152.850 * 1.512 nsec/op o.b.IndexOfBench.benchIndexOf_4_A avgt 1 20 5 656.183 5.904 nsec/op o.b.IndexOfBench.benchIndexOf_4_B avgt 1 20 5 *515.178* 9.107 nsec/op o.b.IndexOfBench.benchIndexOf_5_A avgt 1 20 5 140.609 7.305 nsec/op o.b.IndexOfBench.benchIndexOf_5_B avgt 1 20 5 *129.603* 1.654 nsec/op o.b.IndexOfBench.benchIndexOf_6_A avgt 1 20 5 127.713 1.497 nsec/op o.b.IndexOfBench.benchIndexOf_6_B avgt 1 20 5 *122.177* 1.186 nsec/op o.b.IndexOfBench.benchIndexOf_7_A avgt 1 20 5 430.148 4.875 nsec/op o.b.IndexOfBench.benchIndexOf_7_B avgt 1 20 5 *387.338* 10.904 nsec/op o.b.IndexOfBench.benchIndexOf_8_A avgt 1 20 5 2064.563 28.885 nsec/op o.b.IndexOfBench.benchIndexOf_8_B avgt 1 20 5 *1858.669* 24.343 nsec/op Benchmarks ending with A use the current indexOf implementation, with B use the modified version. These numbers show from 1.4% up to 28% performance increase. The full listing is below. Suggestions about what else to test are welcome! Sincerely yours, Ivan --------------------- /** * Copyright (c) 2014, 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 * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. Oracle designates this * particular file as subject to the "Classpath" exception as provided * by Oracle in the LICENSE file that accompanied this code. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ package org.benches; import org.openjdk.jmh.annotations.*; import org.openjdk.jmh.logic.BlackHole; import java.util.concurrent.TimeUnit; @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @State(Scope.Benchmark) public class IndexOfBench { // ||| final static char[] source1 = "abababcabcacabcabcabcabcaccbcabcacbcabcacbcbcabcbcbacbcabcbabacbcbacbcabcabcabcabcabcabcabcacbacbacbacabcabcacbacbcabcbcbcaabdacbacabcabacbacabca".toCharArray(); final static char[] source2 = "acfacafacfacfacfacafcafcacadcacdacaccacacdacacfcafcafcfacdacadcadcadcdacfacfacdacadcacdcfacfacdacdacdcfacdacdacdacgshgshasdabdahghjgwdshacavcavsc".toCharArray(); final static char[] source3 = "tyrtytfytytuytfytuytggfghgdytyftytfdytdshfgjhdfytsfuythgsfhgjhfghtuysdfthgfsdhgystfjhgsfguysthgfgjhgdfjhgsjdghfythgsdfjhggfabduikjhfjhkjhfkjhgkjh".toCharArray(); final static char[] target1 = "abd".toCharArray(); final static char[] source4 = "ahhhahahahahhahahahahhahahahhhahahahahahahahahahahhahahahahahahahahallallalalalalalkakakakakakakakakkakmamamamabammamamamamamaakaklalalaoalalalao".toCharArray(); final static char[] source5 = "hgjkhjhjkdghkjhdfkjhgkjhdkjdhgkjdfhgkjdhfgkjdfhgkjhdfkjghkdjghkdjfhgkjhkdjhgkjdfhjkghkdjfhgkjdfhgkjdfhgkjdfhkgabhfkjghdkfjhgkjdfhgkjdfhgkjdfhgkhh".toCharArray(); final static char[] target2 = "ab".toCharArray(); final static char[] source6 = "lskgjsklfjgskldfjgklsfjdlgkjsdflkgjskldfgjsdklfgjsl;kdfgjskldfjglksdfjglksfjglksdfjgklsfdjgslkdfjglksjdflkgsjfalksjdflkfgjsdklfjglskdfjglksdfjghh".toCharArray(); final static char[] target3 = "a".toCharArray(); final static char[] source7 = "lskgajabfagskldfjgklsabclgkjsdflkabsabcdgjsdklfabclbkdfgjskabfjglksdfjabcdfjglabcfjgklsfabgslkdfjglksjdabcdsjfabcdedflabcjsdklfjglskdfabcksdfjghh".toCharArray(); final static char[] target4 = "abcde".toCharArray(); final static char[] source8 = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa".toCharArray(); final static char[] target5 = "aaaab".toCharArray(); @GenerateMicroBenchmark public void benchIndexOf_1_A(BlackHole bh) { bh.consume(indexOfA(source1, 0, source1.length, target1, 0, target1.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_1_B(BlackHole bh) { bh.consume(indexOfB(source1, 0, source1.length, target1, 0, target1.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_2_A(BlackHole bh) { bh.consume(indexOfA(source2, 0, source2.length, target1, 0, target1.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_2_B(BlackHole bh) { bh.consume(indexOfB(source2, 0, source2.length, target1, 0, target1.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_3_A(BlackHole bh) { bh.consume(indexOfA(source3, 0, source3.length, target1, 0, target1.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_3_B(BlackHole bh) { bh.consume(indexOfB(source3, 0, source3.length, target1, 0, target1.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_4_A(BlackHole bh) { bh.consume(indexOfA(source4, 0, source4.length, target2, 0, target2.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_4_B(BlackHole bh) { bh.consume(indexOfB(source4, 0, source4.length, target2, 0, target2.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_5_A(BlackHole bh) { bh.consume(indexOfA(source5, 0, source5.length, target2, 0, target2.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_5_B(BlackHole bh) { bh.consume(indexOfB(source5, 0, source5.length, target2, 0, target2.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_6_A(BlackHole bh) { bh.consume(indexOfA(source6, 0, source6.length, target3, 0, target3.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_6_B(BlackHole bh) { bh.consume(indexOfB(source6, 0, source6.length, target3, 0, target3.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_7_A(BlackHole bh) { bh.consume(indexOfA(source7, 0, source7.length, target4, 0, target4.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_7_B(BlackHole bh) { bh.consume(indexOfB(source7, 0, source7.length, target4, 0, target4.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_8_A(BlackHole bh) { bh.consume(indexOfA(source8, 0, source8.length, target5, 0, target5.length, 0)); } @GenerateMicroBenchmark public void benchIndexOf_8_B(BlackHole bh) { bh.consume(indexOfB(source8, 0, source8.length, target5, 0, target5.length, 0)); } // implementations static int indexOfA(char[] source, int sourceOffset, int sourceCount, char[] target, int targetOffset, int targetCount, int fromIndex) { if (fromIndex >= sourceCount) { return (targetCount == 0 ? sourceCount : -1); } if (fromIndex < 0) { fromIndex = 0; } if (targetCount == 0) { return fromIndex; } char first = target[targetOffset]; int max = sourceOffset + (sourceCount - targetCount); for (int i = sourceOffset + fromIndex; i <= max; i++) { /* Look for first character. */ if (source[i] != first) { while (++i <= max && source[i] != first); } /* Found first character, now look at the rest of v2 */ if (i <= max) { int j = i + 1; int end = j + targetCount - 1; for (int k = targetOffset + 1; j < end && source[j] == target[k]; j++, k++); if (j == end) { /* Found whole string. */ return i - sourceOffset; } } } return -1; } static int indexOfB(char[] source, int sourceOffset, int sourceCount, char[] target, int targetOffset, int targetCount, int fromIndex) { if (fromIndex >= sourceCount) { return (targetCount == 0 ? sourceCount : -1); } if (fromIndex < 0) { fromIndex = 0; } if (targetCount == 0) { return fromIndex; } char first = target[targetOffset]; char second = 0; if (targetCount != 1) { second = target[targetOffset + 1]; } int max = sourceOffset + (sourceCount - targetCount); for (int i = sourceOffset + fromIndex; i <= max; i++) { /* Look for first character. */ if (source[i] != first) { while (++i <= max && source[i] != first); } if (targetCount == 1) { return (i <= max) ? i - sourceOffset : -1; } /* Found first character, now look at the rest of v2 */ if (i <= max && source[i + 1] == second) { int j = i + 2; int end = i + targetCount; for (int k = targetOffset + 2; j < end && source[j] == target[k]; j++, k++); if (j == end) { /* Found whole string. */ return i - sourceOffset; } } } return -1; } } From tim.bell at oracle.com Tue Apr 15 19:10:40 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 15 Apr 2014 19:10:40 +0000 Subject: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) In-Reply-To: <534D6291.9090604@CoSoCo.de> References: <3C5D406B-0937-44C5-ACE3-F750A3CD0445@oracle.com> <71C70BB3-CDC3-4A9B-9BB6-6D49EFC73C5A@oracle.com> <53466C88.10801@CoSoCo.de> <53467211.8070405@CoSoCo.de> <5346B6C6.2000908@oracle.com> <5346F05C.6010604@CoSoCo.de> <5346F6D1.2050203@oracle.com> <534D6291.9090604@CoSoCo.de> Message-ID: <534D8430.5090209@oracle.com> On 04/15/14 16:47, Ulf Zibis wrote: > But where are the original attachments e.g. webrevs, patches ? > Are they lost forever ? No, they are there on the new JBS bug reports. For some reason they are not visible to users outside Oracle. I will see if that can be changed. Regards- Tim From brian.burkhalter at oracle.com Tue Apr 15 19:51:51 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 15 Apr 2014 12:51:51 -0700 Subject: PING! Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal In-Reply-To: <60E7A3E0-8621-4BE3-B3DF-B42A2673BC5D@oracle.com> References: <7CFE7FA1-7907-48BE-BDAC-3C389D05E96B@oracle.com> <5315EDAA.5020801@gmail.com> <531EC3BD.9050605@oracle.com> <53201EA5.9090702@gmail.com> <53307892.4020805@gmail.com> <1E0F511F-4A17-4A88-9D63-83A2154FDC6D@oracle.com> <2C8313DE-B562-407E-9BBC-880E3F782568@oracle.com> <60E7A3E0-8621-4BE3-B3DF-B42A2673BC5D@oracle.com> Message-ID: <049F8C22-290E-45BF-94F5-A1DEDBDD4497@oracle.com> On Apr 15, 2014, at 9:24 AM, Brian Burkhalter wrote: > On Apr 15, 2014, at 12:23 AM, Paul Sandoz wrote: > >> My inclination is "if it ain't broke... " and AFAICT nothing indicates toString it is particular broken [*], so perhaps just focus on the cleanup aspects and revisit the other when the JMM is updated (and maybe enhanced volatiles is ready)? I updated the patch to remove the toString() changes: http://cr.openjdk.java.net/~bpb/6375303/webrev.02/ Unless there are objections within the next 24 hours or so I will push this as-is. > Fine by me. I?ll update the webrev. The other aspects could come under this issue already on file:https://bugs.openjdk.java.net/browse/JDK-8033491. I linked this issue to 6375303 and included links to the archive discussion thread. Thanks, Brian From mike.duigou at oracle.com Tue Apr 15 22:14:03 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 15 Apr 2014 15:14:03 -0700 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: References: <533255B1.7020400@oracle.com> <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> Message-ID: <75162C95-8D8C-49D0-B911-708133D75CC7@oracle.com> On Apr 14 2014, at 18:25 , Martin Buchholz wrote: > I'll retreat to being neutral on the overall idea. > > In general, it *is* a best software engineering practice to do all the reading and computing before doing all the writing at the end. > > You'll break anyone who does the crazy thing of intentionally calling add(null, Integer.MAX_VALUE) just for the side effect of incrementing modCount. How would _you_ increment modCount without doing any modding?! Assuming you meant Vector::put(Integer.MAX_VALUE, null). You could use synchronized(vector) { vector.removeRange(vector.size(), vector.size()) } with slight higher cost. > You could make a real improvement (more concurrency) for addAll, by moving the call to toArray out of the synchronized block. > public synchronized boolean addAll(Collection c) { > - modCount++; > Object[] a = c.toArray(); Done! > > It's hardly worth it for e.g. clear, where you are doing nothing but writes in the loop as well. > public synchronized void clear() { > Entry tab[] = table; > - modCount++; > for (int index = tab.length; --index >= 0; ) > tab[index] = null; > + modCount++; > count = 0; > } For consistency with other methods I retained the movement of modCount. I have updated the webrev with what I hope is the final form: http://cr.openjdk.java.net/~mduigou/JDK-8020860/1/webrev/ Good to go? Mike PS:- I would have liked to rewritten Hashtable::putAll(Map<> t) as : { t.forEach(this::put) } but decided against this since it may change the synchronization on t which seems risky. ie. some Thread could hold a lock on t which would now deadlock where the current implementation does not. The forEach() implementation would have advantages as for some cases it would avoid the need to create Map.Entry objects in the iterator. From martinrb at google.com Tue Apr 15 22:18:19 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Apr 2014 15:18:19 -0700 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: <75162C95-8D8C-49D0-B911-708133D75CC7@oracle.com> References: <533255B1.7020400@oracle.com> <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> <75162C95-8D8C-49D0-B911-708133D75CC7@oracle.com> Message-ID: Did you mean s/code/link/ ? + * The Enumerations returned by Hashtable's {@code #keys keys} and + * {@code #elements elements} methods are not fail-fast. On Tue, Apr 15, 2014 at 3:14 PM, Mike Duigou wrote: > > On Apr 14 2014, at 18:25 , Martin Buchholz wrote: > > > I'll retreat to being neutral on the overall idea. > > > > In general, it *is* a best software engineering practice to do all the > reading and computing before doing all the writing at the end. > > > > You'll break anyone who does the crazy thing of intentionally calling > add(null, Integer.MAX_VALUE) just for the side effect of incrementing > modCount. How would _you_ increment modCount without doing any modding?! > > Assuming you meant Vector::put(Integer.MAX_VALUE, null). You could use > synchronized(vector) { vector.removeRange(vector.size(), vector.size()) } > with slight higher cost. > > > You could make a real improvement (more concurrency) for addAll, by > moving the call to toArray out of the synchronized block. > > public synchronized boolean addAll(Collection c) { > > - modCount++; > > Object[] a = c.toArray(); > > Done! > > > > > It's hardly worth it for e.g. clear, where you are doing nothing but > writes in the loop as well. > > public synchronized void clear() { > > Entry tab[] = table; > > - modCount++; > > for (int index = tab.length; --index >= 0; ) > > tab[index] = null; > > + modCount++; > > count = 0; > > } > > For consistency with other methods I retained the movement of modCount. > > I have updated the webrev with what I hope is the final form: > > http://cr.openjdk.java.net/~mduigou/JDK-8020860/1/webrev/ > > Good to go? > > Mike > > PS:- I would have liked to rewritten Hashtable::putAll(Map<> t) > > as : > > { > t.forEach(this::put) > } > > but decided against this since it may change the synchronization on t > which seems risky. ie. some Thread could hold a lock on t which would now > deadlock where the current implementation does not. The forEach() > implementation would have advantages as for some cases it would avoid the > need to create Map.Entry objects in the iterator. > > From martinrb at google.com Tue Apr 15 22:53:00 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Apr 2014 15:53:00 -0700 Subject: String.indexOf optimization In-Reply-To: <534D68B8.3040002@oracle.com> References: <534D68B8.3040002@oracle.com> Message-ID: Hi Ivan, There's already an indexOf(int, int) that allows a user to explicitly search for a char (or character). Hotspot seems to have some intrinsification of String.indexOf, which confuses me. Hotspot seems the right place to provide more optimizations for this, since there has been a fair amount of work creating high-performance low-level implementations of this idea in C. On Tue, Apr 15, 2014 at 10:13 AM, Ivan Gerasimov wrote: > Hi everyone! > > > On 04.04.2014 21:13, Martin Buchholz wrote: > > Summary: > > Many people (myself included) have looked at this problem. It's unlikely > that String.indexOf will change. It's hard to beat the naive > implementation in the typical case. > > But we can try to speed up this naive implementation a little bit. > > We can separate the special case: When the substring's length == 1. > This special case can be done fast, and in the general case we can now > assume substring's length is at least 2. > > Here's the webrev with the implementation of this idea: > http://cr.openjdk.java.net/~igerasim/indexof/0/webrev/ > > I've done some benchmarking with JMH and found no performance degradation > on my machine. > Of course, more testcases should be created and they should be tried on > different machines to be treated as reliable. > > Benchmark Mode Thr Cnt Sec Mean > Mean error Units > o.b.IndexOfBench.benchIndexOf_1_A avgt 1 20 5 > 704.739 9.104 nsec/op > o.b.IndexOfBench.benchIndexOf_1_B avgt 1 20 5 * 573.879* > 9.820 nsec/op > o.b.IndexOfBench.benchIndexOf_2_A avgt 1 20 5 > 668.455 9.882 nsec/op > o.b.IndexOfBench.benchIndexOf_2_B avgt 1 20 5 *476.062* > 6.063 nsec/op > o.b.IndexOfBench.benchIndexOf_3_A avgt 1 20 5 > 155.227 1.796 nsec/op > o.b.IndexOfBench.benchIndexOf_3_B avgt 1 20 5 * > 152.850 * 1.512 nsec/op > o.b.IndexOfBench.benchIndexOf_4_A avgt 1 20 5 > 656.183 5.904 nsec/op > o.b.IndexOfBench.benchIndexOf_4_B avgt 1 20 5 *515.178* > 9.107 nsec/op > o.b.IndexOfBench.benchIndexOf_5_A avgt 1 20 5 > 140.609 7.305 nsec/op > o.b.IndexOfBench.benchIndexOf_5_B avgt 1 20 5 *129.603* > 1.654 nsec/op > o.b.IndexOfBench.benchIndexOf_6_A avgt 1 20 5 > 127.713 1.497 nsec/op > o.b.IndexOfBench.benchIndexOf_6_B avgt 1 20 5 *122.177* > 1.186 nsec/op > o.b.IndexOfBench.benchIndexOf_7_A avgt 1 20 5 > 430.148 4.875 nsec/op > o.b.IndexOfBench.benchIndexOf_7_B avgt 1 20 5 * > 387.338* 10.904 nsec/op > o.b.IndexOfBench.benchIndexOf_8_A avgt 1 20 5 > 2064.563 28.885 nsec/op > o.b.IndexOfBench.benchIndexOf_8_B avgt 1 20 5 *1858.669* > 24.343 nsec/op > > Benchmarks ending with A use the current indexOf implementation, with B > use the modified version. > These numbers show from 1.4% up to 28% performance increase. > > The full listing is below. > > Suggestions about what else to test are welcome! > > Sincerely yours, > Ivan > > --------------------- > > /** > * Copyright (c) 2014, 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 > * under the terms of the GNU General Public License version 2 only, as > * published by the Free Software Foundation. Oracle designates this > * particular file as subject to the "Classpath" exception as provided > * by Oracle in the LICENSE file that accompanied this code. > * > * This code is distributed in the hope that it will be useful, but WITHOUT > * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > * version 2 for more details (a copy is included in the LICENSE file that > * accompanied this code). > * > * You should have received a copy of the GNU General Public License > version > * 2 along with this work; if not, write to the Free Software Foundation, > * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > * > * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > * or visit www.oracle.com if you need additional information or have any > * questions. > */ > package org.benches; > > import org.openjdk.jmh.annotations.*; > import org.openjdk.jmh.logic.BlackHole; > import java.util.concurrent.TimeUnit; > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @State(Scope.Benchmark) > public class IndexOfBench { > > > // > ||| > final static char[] source1 = > "abababcabcacabcabcabcabcaccbcabcacbcabcacbcbcabcbcbacbcabcbabacbcbacbcabcabcabcabcabcabcabcacbacbacbacabcabcacbacbcabcbcbcaabdacbacabcabacbacabca".toCharArray(); > final static char[] source2 = > "acfacafacfacfacfacafcafcacadcacdacaccacacdacacfcafcafcfacdacadcadcadcdacfacfacdacadcacdcfacfacdacdacdcfacdacdacdacgshgshasdabdahghjgwdshacavcavsc".toCharArray(); > final static char[] source3 = > "tyrtytfytytuytfytuytggfghgdytyftytfdytdshfgjhdfytsfuythgsfhgjhfghtuysdfthgfsdhgystfjhgsfguysthgfgjhgdfjhgsjdghfythgsdfjhggfabduikjhfjhkjhfkjhgkjh".toCharArray(); > final static char[] target1 = "abd".toCharArray(); > > final static char[] source4 = > "ahhhahahahahhahahahahhahahahhhahahahahahahahahahahhahahahahahahahahallallalalalalalkakakakakakakakakkakmamamamabammamamamamamaakaklalalaoalalalao".toCharArray(); > final static char[] source5 = > "hgjkhjhjkdghkjhdfkjhgkjhdkjdhgkjdfhgkjdhfgkjdfhgkjhdfkjghkdjghkdjfhgkjhkdjhgkjdfhjkghkdjfhgkjdfhgkjdfhgkjdfhkgabhfkjghdkfjhgkjdfhgkjdfhgkjdfhgkhh".toCharArray(); > final static char[] target2 = "ab".toCharArray(); > > final static char[] source6 = > "lskgjsklfjgskldfjgklsfjdlgkjsdflkgjskldfgjsdklfgjsl;kdfgjskldfjglksdfjglksfjglksdfjgklsfdjgslkdfjglksjdflkgsjfalksjdflkfgjsdklfjglskdfjglksdfjghh".toCharArray(); > final static char[] target3 = "a".toCharArray(); > > final static char[] source7 = > "lskgajabfagskldfjgklsabclgkjsdflkabsabcdgjsdklfabclbkdfgjskabfjglksdfjabcdfjglabcfjgklsfabgslkdfjglksjdabcdsjfabcdedflabcjsdklfjglskdfabcksdfjghh".toCharArray(); > final static char[] target4 = "abcde".toCharArray(); > > final static char[] source8 = > "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa".toCharArray(); > final static char[] target5 = "aaaab".toCharArray(); > > @GenerateMicroBenchmark > public void benchIndexOf_1_A(BlackHole bh) { > bh.consume(indexOfA(source1, 0, source1.length, target1, 0, > target1.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_1_B(BlackHole bh) { > bh.consume(indexOfB(source1, 0, source1.length, target1, 0, > target1.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_2_A(BlackHole bh) { > bh.consume(indexOfA(source2, 0, source2.length, target1, 0, > target1.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_2_B(BlackHole bh) { > bh.consume(indexOfB(source2, 0, source2.length, target1, 0, > target1.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_3_A(BlackHole bh) { > bh.consume(indexOfA(source3, 0, source3.length, target1, 0, > target1.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_3_B(BlackHole bh) { > bh.consume(indexOfB(source3, 0, source3.length, target1, 0, > target1.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_4_A(BlackHole bh) { > bh.consume(indexOfA(source4, 0, source4.length, target2, 0, > target2.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_4_B(BlackHole bh) { > bh.consume(indexOfB(source4, 0, source4.length, target2, 0, > target2.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_5_A(BlackHole bh) { > bh.consume(indexOfA(source5, 0, source5.length, target2, 0, > target2.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_5_B(BlackHole bh) { > bh.consume(indexOfB(source5, 0, source5.length, target2, 0, > target2.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_6_A(BlackHole bh) { > bh.consume(indexOfA(source6, 0, source6.length, target3, 0, > target3.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_6_B(BlackHole bh) { > bh.consume(indexOfB(source6, 0, source6.length, target3, 0, > target3.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_7_A(BlackHole bh) { > bh.consume(indexOfA(source7, 0, source7.length, target4, 0, > target4.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_7_B(BlackHole bh) { > bh.consume(indexOfB(source7, 0, source7.length, target4, 0, > target4.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_8_A(BlackHole bh) { > bh.consume(indexOfA(source8, 0, source8.length, target5, 0, > target5.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_8_B(BlackHole bh) { > bh.consume(indexOfB(source8, 0, source8.length, target5, 0, > target5.length, 0)); > } > > // implementations > > static int indexOfA(char[] source, int sourceOffset, int sourceCount, > char[] target, int targetOffset, int targetCount, > int fromIndex) { > if (fromIndex >= sourceCount) { > return (targetCount == 0 ? sourceCount : -1); > } > if (fromIndex < 0) { > fromIndex = 0; > } > if (targetCount == 0) { > return fromIndex; > } > > char first = target[targetOffset]; > int max = sourceOffset + (sourceCount - targetCount); > > for (int i = sourceOffset + fromIndex; i <= max; i++) { > /* Look for first character. */ > if (source[i] != first) { > while (++i <= max && source[i] != first); > } > > /* Found first character, now look at the rest of v2 */ > if (i <= max) { > int j = i + 1; > int end = j + targetCount - 1; > for (int k = targetOffset + 1; j < end && source[j] > == target[k]; j++, k++); > > if (j == end) { > /* Found whole string. */ > return i - sourceOffset; > } > } > } > return -1; > } > > static int indexOfB(char[] source, int sourceOffset, int sourceCount, > char[] target, int targetOffset, int targetCount, > int fromIndex) { > if (fromIndex >= sourceCount) { > return (targetCount == 0 ? sourceCount : -1); > } > if (fromIndex < 0) { > fromIndex = 0; > } > if (targetCount == 0) { > return fromIndex; > } > char first = target[targetOffset]; > char second = 0; > if (targetCount != 1) { > second = target[targetOffset + 1]; > } > int max = sourceOffset + (sourceCount - targetCount); > for (int i = sourceOffset + fromIndex; i <= max; i++) { > /* Look for first character. */ > if (source[i] != first) { > while (++i <= max && source[i] != first); > } > if (targetCount == 1) { > return (i <= max) ? i - sourceOffset : -1; > } > /* Found first character, now look at the rest of v2 */ > if (i <= max && source[i + 1] == second) { > int j = i + 2; > int end = i + targetCount; > for (int k = targetOffset + 2; j < end && source[j] > == target[k]; j++, k++); > > if (j == end) { > /* Found whole string. */ > return i - sourceOffset; > } > } > } > return -1; > } > } > From chris.hegarty at oracle.com Wed Apr 16 07:34:36 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 16 Apr 2014 08:34:36 +0100 Subject: A hole in the serialization spec In-Reply-To: <53022FD7.8040602@redhat.com> References: <52F4F6BB.2010207@redhat.com> <52F8E807.2090403@oracle.com> <52F8F21C.80205@redhat.com> <52FB8E5C.9020502@oracle.com> <52FB9248.6010703@redhat.com> <26199217-BAE6-47AC-AFC8-4DE90726B8C0@oracle.com> <52FD0328.3050304@redhat.com> <52FE3CB2.5060408@redhat.com> <52FE55BD.2010201@redhat.com> <5301B78B.80801@oracle.com> <5301F596.1000300@oracle.com> <53022FD7.8040602@redhat.com> Message-ID: <534E328C.5090106@oracle.com> On 17/02/14 15:50, David M. Lloyd wrote: > ... > > Honestly I'm coming to the conclusion that the spec should just be > updated to match the existing behavior. At least this way, it is > possible to establish and explain exactly what is happening and why, and > what the effect is on the wire protocol, and how to cope with changes to > the affected class hierarchies in a compatible way. Resurrecting an old thread, since I just realized I didn't reply to this. I have no objection, and would support any effort/attempt to try and resolve this issue. -Chris. From pavel.rappo at oracle.com Wed Apr 16 11:28:39 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 16 Apr 2014 12:28:39 +0100 Subject: RFR JDK-8038178: Fix corrupt license header Message-ID: Hi everyone, could you please review my change for JDK-8038178? P.S. Some may find this a little bit amusing. Thanks -Pavel diff --git a/src/share/classes/sun/misc/InnocuousThread.java b/src/share/classes/sun/misc/InnocuousThread.java --- a/src/share/classes/sun/misc/InnocuousThread.java +++ b/src/share/classes/sun/misc/InnocuousThread.java @@ -3,22 +3,22 @@ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it - * under the terms of the GNUNSAFE General Public License version 2 only, as + * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. Oracle designates this * particular file as subject to the "Classpath" exception as provided * by Oracle in the LICENSE file that accompanied this code. * - * This code is distributed in the hope that it will be useful, but WITHOUNSAFET + * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICUNSAFELAR PUNSAFERPOSE. See the GNUNSAFE General Public License + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * - * You should have received a copy of the GNUNSAFE General Public License version + * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 UNSAFESA. + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 UNSAFESA + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ From chris.hegarty at oracle.com Wed Apr 16 11:37:00 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 16 Apr 2014 12:37:00 +0100 Subject: RFR JDK-8038178: Fix corrupt license header In-Reply-To: References: Message-ID: <534E6B5C.8030605@oracle.com> This looks good to me Pavel. Thanks for fixing it. -Chris. P.S. it gave me a little chuckle ;-) On 16/04/14 12:28, Pavel Rappo wrote: > Hi everyone, > > could you please review my change for JDK-8038178? > P.S. Some may find this a little bit amusing. > > Thanks > -Pavel > > diff --git a/src/share/classes/sun/misc/InnocuousThread.java b/src/share/classes/sun/misc/InnocuousThread.java > --- a/src/share/classes/sun/misc/InnocuousThread.java > +++ b/src/share/classes/sun/misc/InnocuousThread.java > @@ -3,22 +3,22 @@ > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > - * under the terms of the GNUNSAFE General Public License version 2 only, as > + * under the terms of the GNU General Public License version 2 only, as > * published by the Free Software Foundation. Oracle designates this > * particular file as subject to the "Classpath" exception as provided > * by Oracle in the LICENSE file that accompanied this code. > * > - * This code is distributed in the hope that it will be useful, but WITHOUNSAFET > + * This code is distributed in the hope that it will be useful, but WITHOUT > * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > - * FITNESS FOR A PARTICUNSAFELAR PUNSAFERPOSE. See the GNUNSAFE General Public License > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > * version 2 for more details (a copy is included in the LICENSE file that > * accompanied this code). > * > - * You should have received a copy of the GNUNSAFE General Public License version > + * You should have received a copy of the GNU General Public License version > * 2 along with this work; if not, write to the Free Software Foundation, > - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 UNSAFESA. > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > * > - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 UNSAFESA > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > * or visit www.oracle.com if you need additional information or have any > * questions. > */ > From david.holmes at oracle.com Wed Apr 16 11:36:47 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Apr 2014 21:36:47 +1000 Subject: RFR JDK-8038178: Fix corrupt license header In-Reply-To: References: Message-ID: <534E6B4F.6090703@oracle.com> On 16/04/2014 9:28 PM, Pavel Rappo wrote: > Hi everyone, > > could you please review my change for JDK-8038178? Looks okay to me. > P.S. Some may find this a little bit amusing. Indeed :) I'm guessing original code was private static final Unsafe U; then a rename occurred s/U/UNSAFE/ :) David > Thanks > -Pavel > > diff --git a/src/share/classes/sun/misc/InnocuousThread.java b/src/share/classes/sun/misc/InnocuousThread.java > --- a/src/share/classes/sun/misc/InnocuousThread.java > +++ b/src/share/classes/sun/misc/InnocuousThread.java > @@ -3,22 +3,22 @@ > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > - * under the terms of the GNUNSAFE General Public License version 2 only, as > + * under the terms of the GNU General Public License version 2 only, as > * published by the Free Software Foundation. Oracle designates this > * particular file as subject to the "Classpath" exception as provided > * by Oracle in the LICENSE file that accompanied this code. > * > - * This code is distributed in the hope that it will be useful, but WITHOUNSAFET > + * This code is distributed in the hope that it will be useful, but WITHOUT > * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > - * FITNESS FOR A PARTICUNSAFELAR PUNSAFERPOSE. See the GNUNSAFE General Public License > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > * version 2 for more details (a copy is included in the LICENSE file that > * accompanied this code). > * > - * You should have received a copy of the GNUNSAFE General Public License version > + * You should have received a copy of the GNU General Public License version > * 2 along with this work; if not, write to the Free Software Foundation, > - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 UNSAFESA. > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > * > - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 UNSAFESA > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > * or visit www.oracle.com if you need additional information or have any > * questions. > */ > From aleksey.shipilev at oracle.com Wed Apr 16 11:43:04 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 16 Apr 2014 15:43:04 +0400 Subject: RFR JDK-8038178: Fix corrupt license header In-Reply-To: <534E6B4F.6090703@oracle.com> References: <534E6B4F.6090703@oracle.com> Message-ID: <534E6CC8.1030206@oracle.com> On 04/16/2014 03:36 PM, David Holmes wrote: > On 16/04/2014 9:28 PM, Pavel Rappo wrote: >> P.S. Some may find this a little bit amusing. > > Indeed :) I'm guessing original code was > > private static final Unsafe U; Awww... Another thing to be cautious about when using Unsafe. -Aleksey. From roger.riggs at oracle.com Wed Apr 16 13:18:14 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 16 Apr 2014 09:18:14 -0400 Subject: ProcessReaper: single thread reaper In-Reply-To: <534BA424.9040006@gmail.com> References: <532C7A30.6060904@oracle.com> <532FB6B4.7010300@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BA424.9040006@gmail.com> Message-ID: <534E8316.1040506@oracle.com> Hi, Another approach was suggested by a member of the Solaris team. If you open /proc/pid O_RDONLY for any process you wish to monitor and use poll(2), you can wait for a hangup event which indicates that the process has exited. You can then reap that process's status w/ waitpid. You'll also want to wait on a pipe; as you fork additional processes you can write their pid to the pipe and the monitoring thread can wake up, read the pipe and add that fd to the pollfds. This will work for any version of Solaris you support, and it uses a fd per process; using the pipe mechanism no locking is required. I haven't had a chance to followup but it is interesting that monitoring /proc can give an indication of Process termination and some aspects should work on Linux, not just Solaris. Roger On 4/14/2014 5:02 AM, Peter Levart wrote: > Hi Martin, Roger, > > Just a thought. Would it be feasible to have two (ore more) built-in > strategies, selectable by system property? A backwards compatible > tread per child, using waitpid(pid, ...), a single reaper thread using > waitpid(-1, ...), maybe also single threaded strategy accessible only > on Linux/Solaris using waitid(-1, ..., WNOWAIT)... All packed nicely > in a package-private interface (ProcessReaper) with multiple > implementations? > > Regards, Peter > > On 04/12/2014 01:37 AM, Martin Buchholz wrote: >> Let's step back again and try to check our goals... >> >> We could try to optimize the one-reaper-thread-per-subprocess thing. >> But that is risky, and the cost of what we're doing today is not >> that high. >> >> We could try to implement the feature of killing off an entire >> subprocess tree. But historically, any kind of behavior change like >> that has been vetoed. I have tried and failed to make less >> incompatible changes. We would have to add a new API. >> >> The reality is that Java does not give you real access to the >> underlying OS, and unless there's a seriously heterodox attempt to >> provide OS-specific extensions, people will have to continue to >> either write native code or delegate to an OS-savvy subprocess like a >> perl script. >> >> >> On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart > > wrote: >> >> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>> >>> >>> >>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>> > wrote: >>> >>> Hi Martin, >>> >>> As you might have seen in my later reply to Roger, there's >>> still hope on that front: setpgid() + wait(-pgid, ...) might >>> be the answer. I'm exploring in that direction. Shells are >>> doing it, so why can't JDK? >>> >>> It's a little trickier for Process API, since I imagine that >>> shells form a group of processes from a pipeline which is >>> known in-advance while Process API will have to add >>> processes to the live group dynamically. So some races will >>> have to be resolved, but I think it's doable. >>> >>> >>> This is a clever idea, and it's arguably better to design >>> subprocesses so they live in separate process groups (emacs does >>> that), but: >>> Every time you create a process group, you change the effect of >>> a user signal like Ctrl-C, since it's sent to only one group. >>> Maybe propagate signals to the subprocess group? It's starting >>> to get complicated... >>> >> >> Hi Martin, >> >> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >> terminal to a (foreground) process group. A process group is >> formed from a pipeline of interconnected processes. Each pipeline >> is considered to be a separate "job", hence shells call this >> feature "job-control". Child processes by default inherit process >> group from it's parent, so children born with Process API (and >> their children) inherit the process group from the JVM process. >> Considering the intentions of shell job-controll, is propagating >> SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by >> Process API desirable? If so, then yes, handling those signals in >> JVM and propagating them to current process group that contains >> all children spawned by Process API and their descendants would >> have to be performed by JVM. That problem would certainly have to >> be addressed. But let's first see what I found out about >> sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), >> etc... >> >> waitpid(-pgid, ...) alone seems to not be enough for our task. >> Mainly because a process can re-assign it's group and join some >> other group. I don't know if this is a situation that occurs in >> real world, but imagine if we have one live child process in a >> process group pgid1 and no unwaited exited children. If we issue: >> >> waitpid(-pgid1, &status, 0); >> >> Then this call blocks, because at the time it was given, there >> were >0 child processes in the pgid1 group and none of them has >> exited yet. Now if this one child process changes it's process >> group with: >> >> setpgid(0, pgid2); >> >> Then the waitpid call in the parent does not return (maybe this >> is a bug in Linux?) although there are no more live child >> processes in the pgid1 group any more. Even when this child >> exits, the call to waitpid does not return, since this child is >> not in the group we are waiting for when it exits. If all our >> children "escape" the group in such way, the tread doing waiting >> will never unblock. To solve this, we can employ signal handlers. >> In a signal handler for SIGCHLD signal we can invoke: >> >> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >> >> ...in loop until it either returns (0) which means that there're >> no more unwaited exited children in the group at the momen or >> (-1) with errno == ECHILD, which means that there're no more >> children in the queried group any more - the group does not exist >> any more. Since signal handler is invoked whith SIGCHLD being >> masked and there is one bit of pending signal state in the >> kernel, no child exit can be "skipped" this way. Unless the child >> "escapes" by changing it's group. I don't know of a plausible >> reason for a program to change it's process group. If a program >> executing as JVM child wants to become a background daemon it >> usually behaves as follows: >> >> - fork()s a grand-child and then exit()s (so we get notified via >> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >> - the grand-child then changes it's session and group (becomes >> session and group leader), closes file descriptors, etc. The >> responsibility for waiting on the grand-child daemon is >> transferred to the init process (pid=1) since the grand-child >> becomes an orphan (has no parent). >> >> Ignoring this still unsolved problem of possible ill-behaved >> child program that changes it's process group, I started >> constructing a proof-of-concept prototype. What I will do in the >> prototype is start throwing IllegalStateException from the >> methods of the Process API that pertain to such children. I think >> this is reasonable. >> >> Stay tuned, >> >> Peter >> >> >> > From martin.desruisseaux at geomatys.fr Wed Apr 16 15:19:39 2014 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Wed, 16 Apr 2014 11:19:39 -0400 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: <75162C95-8D8C-49D0-B911-708133D75CC7@oracle.com> References: <533255B1.7020400@oracle.com> <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> <75162C95-8D8C-49D0-B911-708133D75CC7@oracle.com> Message-ID: <534E9F8B.6070302@geomatys.fr> Hello all Le 15/04/14 18:14, Mike Duigou a ?crit : > I have updated the webrev with what I hope is the final form: > > http://cr.openjdk.java.net/~mduigou/JDK-8020860/1/webrev/ The first changes in the javadoc contains "{@code #keys keys}" and "{@code #elements elements}". I presume that you mean {@link} instead of {@code}? Martin From bruno.do.medeiros at gmail.com Wed Apr 16 16:23:37 2014 From: bruno.do.medeiros at gmail.com (Bruno Medeiros) Date: Wed, 16 Apr 2014 17:23:37 +0100 Subject: Thread hangs reading from process output streams, even though process has terminated. (possible JDK bug?) Message-ID: I have some code where I start an external process (ProcessBuilder.start() ,etc.) and then I spawn two worker threads to read the stdout and stderr of the external process. I directly read the streams provided by process.getInputStream() and process.getErrorStream() , I'm not wrapping them with my own streams or anything. Rather, the worker threads are calling java.io.InputStream.read(byte[]) in a loop. I've encountered a situation, where the worker threads hang despite the process having been terminated already! ( Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) , Windows 7) I'm able to caught this whilst running the Java program under the debugger. I invoked process.exitValue() under the debugger to see if the JVM has indeed realized the process has terminated. It returned 0, so it seems it knows the process has terminated. Yet the streams are still blocked, in a native method: The stdout worker thread is stuck here: Daemon Thread [ExternalProcessEclipseHelper.MainWorker] (Suspended) owns: BufferedInputStream (id=145) FileInputStream.readBytes(byte[], int, int) line: not available [native method] FileInputStream.read(byte[], int, int) line: 272 BufferedInputStream.fill() line: 235 BufferedInputStream.read1(byte[], int, int) line: 275 BufferedInputStream.read(byte[], int, int) line: 334 BufferedInputStream(FilterInputStream).read(byte[]) line: 107 ExternalProcessNotifyingHelper$1(ExternalProcessHelper$ReadAllBytesTask).doRun() line: 73 The stderr worker thread is similarly stuck : Daemon Thread [ExternalProcessEclipseHelper.StdErrWorker] (Suspended) FileInputStream.readBytes(byte[], int, int) line: not available [native method] FileInputStream.read(byte[]) line: 243 ExternalProcessNotifyingHelper$2(ExternalProcessHelper$ReadAllBytesTask).doRun() line: 73 Could this be a JVM bug? I don't see that this scenario should ever be happening, unless some other part of my code somehow did some violation and messed up the JVM state. I've added a sample of the relevant code I'm using here: https://github.com/bruno-medeiros/Scratchpad/tree/jvm-processio-issue However, I haven't yet been able to replicate this bug using the isolated code from there. At the moment, I can only replicate it when I run my full application. The sample code could be simplified further, but I haven't done it yet since I couldn't replicate the bug using that. One interesting bit, is that I can only replicate it when I run the application for the first time, per computer session. That is, apparently I need to reboot my computer for the bug to manifest again! I'd like to narrow this down, but I would appreciate some help or suggestions for that. What could affect the JVM, such that subsequent invocations apparently don't cause the bug? Some code cache issue? I also wonder if the OSGi runtime could be a factor here. -- Bruno Medeiros https://twitter.com/brunodomedeiros From iris.clark at oracle.com Wed Apr 16 17:19:09 2014 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 16 Apr 2014 10:19:09 -0700 (PDT) Subject: RFR JDK-8038178: Fix corrupt license header In-Reply-To: References: Message-ID: <99574e22-0511-4e78-be8a-0fbd731bda28@default> Hi, Pavel. Oops. Looks good to me. iris -----Original Message----- From: Pavel Rappo Sent: Wednesday, April 16, 2014 4:29 AM To: core-libs-dev Subject: RFR JDK-8038178: Fix corrupt license header Hi everyone, could you please review my change for JDK-8038178? P.S. Some may find this a little bit amusing. Thanks -Pavel diff --git a/src/share/classes/sun/misc/InnocuousThread.java b/src/share/classes/sun/misc/InnocuousThread.java --- a/src/share/classes/sun/misc/InnocuousThread.java +++ b/src/share/classes/sun/misc/InnocuousThread.java @@ -3,22 +3,22 @@ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it - * under the terms of the GNUNSAFE General Public License version 2 only, as + * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. Oracle designates this * particular file as subject to the "Classpath" exception as provided * by Oracle in the LICENSE file that accompanied this code. * - * This code is distributed in the hope that it will be useful, but WITHOUNSAFET + * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICUNSAFELAR PUNSAFERPOSE. See the GNUNSAFE General Public License + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * - * You should have received a copy of the GNUNSAFE General Public License version + * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 UNSAFESA. + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 UNSAFESA + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ From mike.duigou at oracle.com Wed Apr 16 17:30:25 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 16 Apr 2014 10:30:25 -0700 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: <534E9F8B.6070302@geomatys.fr> References: <533255B1.7020400@oracle.com> <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> <75162C95-8D8C-49D0-B911-708133D75CC7@oracle.com> <534E9F8B.6070302@geomatys.fr> Message-ID: <18370F8A-191D-4586-9162-FD94F65FB48F@oracle.com> Yes. This has been corrected. Mike On Apr 16 2014, at 08:19 , Martin Desruisseaux wrote: > Hello all > > Le 15/04/14 18:14, Mike Duigou a ?crit : >> I have updated the webrev with what I hope is the final form: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8020860/1/webrev/ > > The first changes in the javadoc contains "{@code #keys keys}" and > "{@code #elements elements}". I presume that you mean {@link} instead of > {@code}? > > Martin > From martinrb at google.com Wed Apr 16 17:47:49 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Apr 2014 10:47:49 -0700 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: <18370F8A-191D-4586-9162-FD94F65FB48F@oracle.com> References: <533255B1.7020400@oracle.com> <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> <75162C95-8D8C-49D0-B911-708133D75CC7@oracle.com> <534E9F8B.6070302@geomatys.fr> <18370F8A-191D-4586-9162-FD94F65FB48F@oracle.com> Message-ID: Here you access elementCount outside the synchronized block, which is a data race + public boolean addAll(int index, Collection c) { if (index < 0 || index > elementCount) throw new ArrayIndexOutOfBoundsException(index); On Wed, Apr 16, 2014 at 10:30 AM, Mike Duigou wrote: > Yes. This has been corrected. > > Mike > > On Apr 16 2014, at 08:19 , Martin Desruisseaux < > martin.desruisseaux at geomatys.fr> wrote: > > > Hello all > > > > Le 15/04/14 18:14, Mike Duigou a ?crit : > >> I have updated the webrev with what I hope is the final form: > >> > >> http://cr.openjdk.java.net/~mduigou/JDK-8020860/1/webrev/ > > > > The first changes in the javadoc contains "{@code #keys keys}" and > > "{@code #elements elements}". I presume that you mean {@link} instead of > > {@code}? > > > > Martin > > > > From martinrb at google.com Wed Apr 16 19:15:17 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Apr 2014 12:15:17 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: <534C4BAC.7050802@gmail.com> References: <532C7A30.6060904@oracle.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BF296.6060002@oracle.com> <534C14A6.7030805@redhat.com> <534C4BAC.7050802@gmail.com> Message-ID: On Mon, Apr 14, 2014 at 1:57 PM, Peter Levart wrote: > > There's already such a race in current implementation of > Process.terminate(). It admittedly only concerns a small window between > process exiting and the reaper thread managing to signal this state to the > other threads wishing to terminate it at the same time, so it could happen > that a KILL/TERM signal is sent to an already deceased PID which was > re-used, but it doesn't happen in practice since PIDs are not re-used very > soon typically. > > But I agree, waiting between listing children and sending them signals > increases the chance of hitting a reused PID. > We do rely on the OS not reusing a PID _immediately_. We used to have bugs in this area where Process.destroy would send a signal to a pid that may have deceased arbitrarily long ago. From lance.andersen at oracle.com Wed Apr 16 21:41:32 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 16 Apr 2014 17:41:32 -0400 Subject: RFR 8040760: Addition of new java.sql tests Message-ID: Hi, Looking for a reviewer for some new java.sql tests. The webrev can be found at http://cr.openjdk.java.net/~lancea/8040760/webrev.00/ 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 david.lloyd at redhat.com Wed Apr 16 22:34:06 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 16 Apr 2014 17:34:06 -0500 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BF296.6060002@oracle.com> <534C14A6.7030805@redhat.com> <534C4BAC.7050802@gmail.com> Message-ID: <534F055E.8070006@redhat.com> On 04/16/2014 02:15 PM, Martin Buchholz wrote: > On Mon, Apr 14, 2014 at 1:57 PM, Peter Levart > wrote: > > > There's already such a race in current implementation of > Process.terminate(). It admittedly only concerns a small window > between process exiting and the reaper thread managing to signal > this state to the other threads wishing to terminate it at the same > time, so it could happen that a KILL/TERM signal is sent to an > already deceased PID which was re-used, but it doesn't happen in > practice since PIDs are not re-used very soon typically. > > But I agree, waiting between listing children and sending them > signals increases the chance of hitting a reused PID. > > > We do rely on the OS not reusing a PID _immediately_. We used to have > bugs in this area where Process.destroy would send a signal to a pid > that may have deceased arbitrarily long ago. It seems to me that the key to avoiding this is to ensure that waitpid() is not called until we know the PID is ready to be cleaned. As long as waitpid() has not yet been called, we can be certain that the process still exists and is ours. So the real question is, how can we know a process is dead without actually calling wait() (thereby making that knowledge useless)? The aforementioned /proc trick seems like one good way to do so without, say, spawning a plethora of threads (though at one additional FD per thread, it is not free either). Unforunately /proc is not ubiquitous, and even where it does exist, it's not standardized (thus its behavior probably cannot be relied upon absolutely). A simple solution may be to use a synchronized set of child PIDs, and set a SIGCHLD handler or waiter which, when triggered, locks the set and performs a series of waitid() operations with WNOHANG, processing all the process status updates. The signalling APIs would be required to synchronize on the set to determine if the process in question is owned by the parent process. Previously unknown processes can be "adopted" into this area by acquiring the synchronization and calling "waitpid()"+WNOHANG on the PID in question, and using the result to determine whether the PID should be added to the set (or whether we just reaped it - or whether it doesn't belong to us at all). As long as the process API is restricted to managing direct children, this should work and be safe across all POSIX-ish environments. Note the potential downside that all children will be automatically reaped, which is possibly somewhat hostile to na?ve JNI libraries or embedders. Selectively enabling the /proc trick can mitigate this downside on platforms which support it however. -- - DML From david.lloyd at redhat.com Thu Apr 17 01:31:30 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 16 Apr 2014 20:31:30 -0500 Subject: A hole in the serialization spec In-Reply-To: <534E328C.5090106@oracle.com> References: <52F4F6BB.2010207@redhat.com> <52F8E807.2090403@oracle.com> <52F8F21C.80205@redhat.com> <52FB8E5C.9020502@oracle.com> <52FB9248.6010703@redhat.com> <26199217-BAE6-47AC-AFC8-4DE90726B8C0@oracle.com> <52FD0328.3050304@redhat.com> <52FE3CB2.5060408@redhat.com> <52FE55BD.2010201@redhat.com> <5301B78B.80801@oracle.com> <5301F596.1000300@oracle.com> <53022FD7.8040602@redhat.com> <534E328C.5090106@oracle.com> Message-ID: <534F2EF2.2040403@redhat.com> On 04/16/2014 02:34 AM, Chris Hegarty wrote: > > On 17/02/14 15:50, David M. Lloyd wrote: >> ... >> >> Honestly I'm coming to the conclusion that the spec should just be >> updated to match the existing behavior. At least this way, it is >> possible to establish and explain exactly what is happening and why, and >> what the effect is on the wire protocol, and how to cope with changes to >> the affected class hierarchies in a compatible way. > > Resurrecting an old thread, since I just realized I didn't reply to this. > > I have no objection, and would support any effort/attempt to try and > resolve this issue. Is the serialization spec document [1] available in some source form for which changes could be submitted directly? [1] http://docs.oracle.com/javase/7/docs/platform/serialization/spec/serialTOC.html -- - DML From brian.burkhalter at oracle.com Thu Apr 17 01:42:07 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 16 Apr 2014 18:42:07 -0700 Subject: JDK 9 RFR of 8027595: Enable BigInteger overflow tests in JTREG Message-ID: <8542A13B-8A6C-443C-87E8-B60A1FE1357A@oracle.com> Hello, Following up on http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024171.html. Issue: https://bugs.openjdk.java.net/browse/JDK-8027595#comment-13486513 Patch: http://cr.openjdk.java.net/~bpb/8027595/webrev.00/ The tests modified as shown pass JPRT. The StringConstructorOverflow test always gets an OOME without the -Xmx8g, and the DivisionOverflow test sometimes gets an OOME, but In both cases the OOME is caught and the test does not fail. I don?t think that this change is necessarily ideal, but it will enable at least some of the tests for some of the platofmrs which is better than now, i.e., nothing. The summary in the patch is not quite accurate but I can update it before pushing. Thanks, Brian From martinrb at google.com Thu Apr 17 07:07:19 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Apr 2014 00:07:19 -0700 Subject: ProcessReaper: single thread reaper In-Reply-To: <534F055E.8070006@redhat.com> References: <532C7A30.6060904@oracle.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BF296.6060002@oracle.com> <534C14A6.7030805@redhat.com> <534C4BAC.7050802@gmail.com> <534F055E.8070006@redhat.com> Message-ID: Many possible solutions eventually fail because whatever we do cannot take ownership of any global resource. Calling waitid on all child processes, even with NOWAIT and NOHANG changes global state (what if another subprocess library in the same process is trying to do the same thing?) On Wed, Apr 16, 2014 at 3:34 PM, David M. Lloyd wrote: > On 04/16/2014 02:15 PM, Martin Buchholz wrote: > >> On Mon, Apr 14, 2014 at 1:57 PM, Peter Levart > > wrote: >> >> >> There's already such a race in current implementation of >> Process.terminate(). It admittedly only concerns a small window >> between process exiting and the reaper thread managing to signal >> this state to the other threads wishing to terminate it at the same >> time, so it could happen that a KILL/TERM signal is sent to an >> already deceased PID which was re-used, but it doesn't happen in >> practice since PIDs are not re-used very soon typically. >> >> But I agree, waiting between listing children and sending them >> signals increases the chance of hitting a reused PID. >> >> >> We do rely on the OS not reusing a PID _immediately_. We used to have >> bugs in this area where Process.destroy would send a signal to a pid >> that may have deceased arbitrarily long ago. >> > > It seems to me that the key to avoiding this is to ensure that waitpid() > is not called until we know the PID is ready to be cleaned. As long as > waitpid() has not yet been called, we can be certain that the process still > exists and is ours. So the real question is, how can we know a process is > dead without actually calling wait() (thereby making that knowledge > useless)? > > The aforementioned /proc trick seems like one good way to do so without, > say, spawning a plethora of threads (though at one additional FD per > thread, it is not free either). Unforunately /proc is not ubiquitous, and > even where it does exist, it's not standardized (thus its behavior probably > cannot be relied upon absolutely). > > A simple solution may be to use a synchronized set of child PIDs, and set > a SIGCHLD handler or waiter which, when triggered, locks the set and > performs a series of waitid() operations with WNOHANG, processing all the > process status updates. The signalling APIs would be required to > synchronize on the set to determine if the process in question is owned by > the parent process. Previously unknown processes can be "adopted" into > this area by acquiring the synchronization and calling "waitpid()"+WNOHANG > on the PID in question, and using the result to determine whether the PID > should be added to the set (or whether we just reaped it - or whether it > doesn't belong to us at all). > > As long as the process API is restricted to managing direct children, this > should work and be safe across all POSIX-ish environments. Note the > potential downside that all children will be automatically reaped, which is > possibly somewhat hostile to na?ve JNI libraries or embedders. Selectively > enabling the /proc trick can mitigate this downside on platforms which > support it however. > > -- > - DML > From otaviojava at java.net Thu Apr 17 11:52:31 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Thu, 17 Apr 2014 08:52:31 -0300 Subject: getFirst and getLast on Iterable Message-ID: I would to add for news methods on Iterable, I believe it will helpful for many Java Developers. diff -r 3dd165facde7 test/java/util/Iterator/IteratorDefaults.java --- a/test/java/util/Iterator/IteratorDefaults.java Wed Apr 09 12:26:00 2014 -0700 +++ b/test/java/util/Iterator/IteratorDefaults.java Wed Apr 16 23:25:56 2014 -0300 @@ -399,6 +399,48 @@ } } + public void testgetFirst() { + + List source = Arrays.asList(1, 2, 3, 4); + int first = source.getFirst(); + assertEquals(first, 1); + + List emptySource = Collections.emptyList(); + assertNull(emptySource.getFirst()); + } + + public void testgetFirstWithDefaultElement() { + + List source = Arrays.asList(1, 2, 3, 4); + Integer defaultElement = 5; + assertEquals(source.getFirst(defaultElement), Integer.valueOf(1)); + + List emptySource = Collections.emptyList(); + assertEquals(emptySource.getFirst(defaultElement), defaultElement); + + } + + public void testgetLast() { + + List source = Arrays.asList(1, 2, 3, 4); + int last = source.getLast(); + assertEquals(last, 4); + + List emptySource = Collections.emptyList(); + assertNull(emptySource.getLast()); + } + + public void testgetLastWithDefaultElement() { + + List source = Arrays.asList(1, 2, 3, 4); + Integer defaultElement = 5; + assertEquals(source.getLast(defaultElement), Integer.valueOf(4)); + + List emptySource = Collections.emptyList(); + assertEquals(emptySource.getLast(defaultElement), defaultElement); + + } + static class IteratorWithRemove implements Iterator { public boolean removed; diff -r 3dd165facde7 src/share/classes/java/lang/Iterable.java --- a/src/share/classes/java/lang/Iterable.java Wed Apr 09 12:26:00 2014 -0700 +++ b/src/share/classes/java/lang/Iterable.java Wed Apr 16 23:16:21 2014 -0300 @@ -100,4 +100,55 @@ default Spliterator spliterator() { return Spliterators.spliteratorUnknownSize(iterator(), 0); } + + + /** + * returns the first element, if empty will return {@code null} + * @return the first element or {@code null} + * @since 1.8 + */ + default T getFirst() { + return getFirst(null); + } + + /** + * returns the first element, if empty will return the default + * @param defaultValue - the default value to return if the iterable is empty + * @return the first element or default element + * @since 1.8 + */ + default T getFirst(T defaultValue) { + for (T element : this) { + return element; + } + return defaultValue; + } + + /** + * returns the last element, if empty will return {@code null} + * @return the first element or {@code null} + * @since 1.8 + */ + default T getLast() { + + return getLast(null); + } + + /** + * returns the last element, if empty will return the default + * @param defaultValue - the default value to return if the iterable is empty + * @return the last element or default element + * @since 1.8 + */ + default T getLast(T defaultValue) { + + T last = null; + for (T element : this) { + last = element; + } + if (Objects.isNull(last)) { + return defaultValue; + } + return last; + } } -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From vitalyd at gmail.com Thu Apr 17 13:21:26 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 17 Apr 2014 09:21:26 -0400 Subject: getFirst and getLast on Iterable In-Reply-To: References: Message-ID: getLast is a bit dangerous since the sequence can be infinite. Both getFirst and getLast (ignoring infinite sequences) seem too trivial to provide in the JDK, IMHO. Sent from my phone On Apr 17, 2014 7:53 AM, "Ot?vio Gon?alves de Santana" wrote: > I would to add for news methods on Iterable, I believe it will helpful for > many Java Developers. > > > diff -r 3dd165facde7 test/java/util/Iterator/IteratorDefaults.java > > --- a/test/java/util/Iterator/IteratorDefaults.java Wed Apr 09 12:26:00 > 2014 -0700 > > +++ b/test/java/util/Iterator/IteratorDefaults.java Wed Apr 16 23:25:56 > 2014 -0300 > > @@ -399,6 +399,48 @@ > > } > > } > > > > + public void testgetFirst() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + int first = source.getFirst(); > > + assertEquals(first, 1); > > + > > + List emptySource = Collections.emptyList(); > > + assertNull(emptySource.getFirst()); > > + } > > + > > + public void testgetFirstWithDefaultElement() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + Integer defaultElement = 5; > > + assertEquals(source.getFirst(defaultElement), Integer.valueOf(1)); > > + > > + List emptySource = Collections.emptyList(); > > + assertEquals(emptySource.getFirst(defaultElement), > defaultElement); > > + > > + } > > + > > + public void testgetLast() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + int last = source.getLast(); > > + assertEquals(last, 4); > > + > > + List emptySource = Collections.emptyList(); > > + assertNull(emptySource.getLast()); > > + } > > + > > + public void testgetLastWithDefaultElement() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + Integer defaultElement = 5; > > + assertEquals(source.getLast(defaultElement), Integer.valueOf(4)); > > + > > + List emptySource = Collections.emptyList(); > > + assertEquals(emptySource.getLast(defaultElement), defaultElement); > > + > > + } > > + > > static class IteratorWithRemove implements Iterator { > > > > public boolean removed; > > > > > diff -r 3dd165facde7 src/share/classes/java/lang/Iterable.java > > --- a/src/share/classes/java/lang/Iterable.java Wed Apr 09 12:26:00 2014 > -0700 > > +++ b/src/share/classes/java/lang/Iterable.java Wed Apr 16 23:16:21 2014 > -0300 > > @@ -100,4 +100,55 @@ > > default Spliterator spliterator() { > > return Spliterators.spliteratorUnknownSize(iterator(), 0); > > } > > + > > + > > + /** > > + * returns the first element, if empty will return {@code null} > > + * @return the first element or {@code null} > > + * @since 1.8 > > + */ > > + default T getFirst() { > > + return getFirst(null); > > + } > > + > > + /** > > + * returns the first element, if empty will return the default > > + * @param defaultValue - the default value to return if the iterable > is empty > > + * @return the first element or default element > > + * @since 1.8 > > + */ > > + default T getFirst(T defaultValue) { > > + for (T element : this) { > > + return element; > > + } > > + return defaultValue; > > + } > > + > > + /** > > + * returns the last element, if empty will return {@code null} > > + * @return the first element or {@code null} > > + * @since 1.8 > > + */ > > + default T getLast() { > > + > > + return getLast(null); > > + } > > + > > + /** > > + * returns the last element, if empty will return the default > > + * @param defaultValue - the default value to return if the iterable > is empty > > + * @return the last element or default element > > + * @since 1.8 > > + */ > > + default T getLast(T defaultValue) { > > + > > + T last = null; > > + for (T element : this) { > > + last = element; > > + } > > + if (Objects.isNull(last)) { > > + return defaultValue; > > + } > > + return last; > > + } > > } > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 > From Roger.Riggs at Oracle.com Thu Apr 17 13:44:42 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 17 Apr 2014 09:44:42 -0400 Subject: RFR 8040760: Addition of new java.sql tests In-Reply-To: References: Message-ID: <534FDACA.8050105@Oracle.com> Hi Lance, - The empty method for @BeforeClass, @AfterClass, @BeforeMethod, @AfterMethod could be deleted (and related imports) - Ditto the empty public constructors - The javadoc first sentences should end with a "." (Though we rarely generate javadoc for tests). - Binary files (BatchUpdateException_JDBC42.ser) are rarely a good idea. Typically the bytes are dumped to a source byte array and embedded in the test. - Some tests (like BatchUpdateException) would be easier to read if there was method for 'equals(ex1, ex2)'. - Only BatchUpdateException has a serialization test for compatibility with previous versions. (the round trip write/read tests only test the current version). - StubDriverDA logs an error to the Logger instead of causing a test failure - is that correct? - BatchUpdateExceptionTests + 320 check indentation - DriverManagerTests + 291 "to to" -> "to" - StubConnection +44 add a space before "{" Roger On 04/16/2014 05:41 PM, Lance Andersen wrote: > Hi, > > Looking for a reviewer for some new java.sql tests. > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8040760/webrev.00/ > > 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 peter.levart at gmail.com Thu Apr 17 14:23:27 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 17 Apr 2014 16:23:27 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: <534E8316.1040506@oracle.com> References: <532C7A30.6060904@oracle.com> <53309E15.2060405@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BA424.9040006@gmail.com> <534E8316.1040506@oracle.com> Message-ID: <534FE3DF.20606@gmail.com> On 04/16/2014 03:18 PM, roger riggs wrote: > Hi, > > Another approach was suggested by a member of the Solaris team. > > If you open /proc/pid O_RDONLY for any process you wish to monitor > and use poll(2), you can wait for a hangup event which indicates that > the process has exited. You can then reap that process's status w/ > waitpid. You'll also want to wait on a pipe; as you fork additional > processes you can write their pid to the pipe and the monitoring thread > can wake up, read the pipe and add that fd to the pollfds. This will > work for any version of Solaris you support, and it uses a fd per > process; using the pipe mechanism no locking is required. > > I haven't had a chance to followup but it is interesting that > monitoring /proc > can give an indication of Process termination and some aspects should > work on Linux, not just Solaris. > > Roger Hi Roger, An interesting idea. Another way to dynamically augment the list of fds the single thread is poll()ing is to use a signal to interrupt poll(), but using a pipe might be less hassle (thinking of setting up per-thread signal masks, ...). So I think there's one more reason to create an internal API just for that purpose (waiting on child exits, reaping their exit statuses and dispatching events to Java threads) with multiple implementations selectable by system property. The API could be as simple as: interface ProcessReaper { // called from Process API after spawning new child. // returns exit status futureand registers the child // to be reaped. CompletableFuture processStarted(int pid); // optional - returns exit status future of a child process // spawned by Process API which has not been reaped yet, // null otherwise CompletableFuture getExitStatus(int pid); } Regards, Peter > > > On 4/14/2014 5:02 AM, Peter Levart wrote: >> Hi Martin, Roger, >> >> Just a thought. Would it be feasible to have two (ore more) built-in >> strategies, selectable by system property? A backwards compatible >> tread per child, using waitpid(pid, ...), a single reaper thread >> using waitpid(-1, ...), maybe also single threaded strategy >> accessible only on Linux/Solaris using waitid(-1, ..., WNOWAIT)... >> All packed nicely in a package-private interface (ProcessReaper) with >> multiple implementations? >> >> Regards, Peter >> >> On 04/12/2014 01:37 AM, Martin Buchholz wrote: >>> Let's step back again and try to check our goals... >>> >>> We could try to optimize the one-reaper-thread-per-subprocess thing. >>> But that is risky, and the cost of what we're doing today is not >>> that high. >>> >>> We could try to implement the feature of killing off an entire >>> subprocess tree. But historically, any kind of behavior change like >>> that has been vetoed. I have tried and failed to make less >>> incompatible changes. We would have to add a new API. >>> >>> The reality is that Java does not give you real access to the >>> underlying OS, and unless there's a seriously heterodox attempt to >>> provide OS-specific extensions, people will have to continue to >>> either write native code or delegate to an OS-savvy subprocess like >>> a perl script. >>> >>> >>> On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart >>> > wrote: >>> >>> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>>> >>>> >>>> >>>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>>> > wrote: >>>> >>>> Hi Martin, >>>> >>>> As you might have seen in my later reply to Roger, there's >>>> still hope on that front: setpgid() + wait(-pgid, ...) might >>>> be the answer. I'm exploring in that direction. Shells are >>>> doing it, so why can't JDK? >>>> >>>> It's a little trickier for Process API, since I imagine that >>>> shells form a group of processes from a pipeline which is >>>> known in-advance while Process API will have to add >>>> processes to the live group dynamically. So some races will >>>> have to be resolved, but I think it's doable. >>>> >>>> >>>> This is a clever idea, and it's arguably better to design >>>> subprocesses so they live in separate process groups (emacs does >>>> that), but: >>>> Every time you create a process group, you change the effect of >>>> a user signal like Ctrl-C, since it's sent to only one group. >>>> Maybe propagate signals to the subprocess group? It's starting >>>> to get complicated... >>>> >>> >>> Hi Martin, >>> >>> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >>> terminal to a (foreground) process group. A process group is >>> formed from a pipeline of interconnected processes. Each pipeline >>> is considered to be a separate "job", hence shells call this >>> feature "job-control". Child processes by default inherit process >>> group from it's parent, so children born with Process API (and >>> their children) inherit the process group from the JVM process. >>> Considering the intentions of shell job-controll, is propagating >>> SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by >>> Process API desirable? If so, then yes, handling those signals in >>> JVM and propagating them to current process group that contains >>> all children spawned by Process API and their descendants would >>> have to be performed by JVM. That problem would certainly have to >>> be addressed. But let's first see what I found out about >>> sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), >>> etc... >>> >>> waitpid(-pgid, ...) alone seems to not be enough for our task. >>> Mainly because a process can re-assign it's group and join some >>> other group. I don't know if this is a situation that occurs in >>> real world, but imagine if we have one live child process in a >>> process group pgid1 and no unwaited exited children. If we issue: >>> >>> waitpid(-pgid1, &status, 0); >>> >>> Then this call blocks, because at the time it was given, there >>> were >0 child processes in the pgid1 group and none of them has >>> exited yet. Now if this one child process changes it's process >>> group with: >>> >>> setpgid(0, pgid2); >>> >>> Then the waitpid call in the parent does not return (maybe this >>> is a bug in Linux?) although there are no more live child >>> processes in the pgid1 group any more. Even when this child >>> exits, the call to waitpid does not return, since this child is >>> not in the group we are waiting for when it exits. If all our >>> children "escape" the group in such way, the tread doing waiting >>> will never unblock. To solve this, we can employ signal handlers. >>> In a signal handler for SIGCHLD signal we can invoke: >>> >>> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >>> >>> ...in loop until it either returns (0) which means that there're >>> no more unwaited exited children in the group at the momen or >>> (-1) with errno == ECHILD, which means that there're no more >>> children in the queried group any more - the group does not exist >>> any more. Since signal handler is invoked whith SIGCHLD being >>> masked and there is one bit of pending signal state in the >>> kernel, no child exit can be "skipped" this way. Unless the child >>> "escapes" by changing it's group. I don't know of a plausible >>> reason for a program to change it's process group. If a program >>> executing as JVM child wants to become a background daemon it >>> usually behaves as follows: >>> >>> - fork()s a grand-child and then exit()s (so we get notified via >>> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >>> - the grand-child then changes it's session and group (becomes >>> session and group leader), closes file descriptors, etc. The >>> responsibility for waiting on the grand-child daemon is >>> transferred to the init process (pid=1) since the grand-child >>> becomes an orphan (has no parent). >>> >>> Ignoring this still unsolved problem of possible ill-behaved >>> child program that changes it's process group, I started >>> constructing a proof-of-concept prototype. What I will do in the >>> prototype is start throwing IllegalStateException from the >>> methods of the Process API that pertain to such children. I think >>> this is reasonable. >>> >>> Stay tuned, >>> >>> Peter >>> >>> >>> >> > From michael.x.mcmahon at oracle.com Thu Apr 17 14:27:59 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 17 Apr 2014 15:27:59 +0100 Subject: RFR 8040809: '}' left in the spec for j.u.Random.doubles(..) Message-ID: <534FE4EF.4080302@oracle.com> Trivial doc change to remove extraneous '}' characters in two places http://cr.openjdk.java.net/~michaelm/8040809/webrev.1/ Thanks, Michael From roger.riggs at oracle.com Thu Apr 17 14:30:29 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 17 Apr 2014 10:30:29 -0400 Subject: RFR 8040809: '}' left in the spec for j.u.Random.doubles(..) In-Reply-To: <534FE4EF.4080302@oracle.com> References: <534FE4EF.4080302@oracle.com> Message-ID: <534FE585.8090202@oracle.com> Hi Michael, Looks good. Roger On 4/17/2014 10:27 AM, Michael McMahon wrote: > Trivial doc change to remove extraneous '}' characters in two places > > http://cr.openjdk.java.net/~michaelm/8040809/webrev.1/ > > Thanks, > Michael From peter.levart at gmail.com Thu Apr 17 14:43:52 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 17 Apr 2014 16:43:52 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: References: <532C7A30.6060904@oracle.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BF296.6060002@oracle.com> <534C14A6.7030805@redhat.com> <534C4BAC.7050802@gmail.com> <534F055E.8070006@redhat.com> Message-ID: <534FE8A8.1060308@gmail.com> On 04/17/2014 09:07 AM, Martin Buchholz wrote: > Many possible solutions eventually fail because whatever we do cannot > take ownership of any global resource. Calling waitid on all child > processes, even with NOWAIT and NOHANG changes global state (what if > another subprocess library in the same process is trying to do the > same thing?) waitid(P_ALL, ..., NOWAIT | NOHANG) does not reap the child. It can be repeated multiple times. It can be used as a precursor to real waitid/waitpid which reaps a child, but only if it is "ours". The problem with this approach is what to do in the following scenario: the precursor waitid(P_ALL, ..., NOWAIT | NOHANG) returns a child that is not "ours" so we don't reap it. The "owner" of that child (JNI-library) does not do prompt reaping of their children. We loop, repeatedly getting the same child as a result, not seeing any other children that have exited in the meanwhile... Regards, Peter > > > On Wed, Apr 16, 2014 at 3:34 PM, David M. Lloyd > > wrote: > > On 04/16/2014 02:15 PM, Martin Buchholz wrote: > > On Mon, Apr 14, 2014 at 1:57 PM, Peter Levart > > >> wrote: > > > There's already such a race in current implementation of > Process.terminate(). It admittedly only concerns a small > window > between process exiting and the reaper thread managing to > signal > this state to the other threads wishing to terminate it at > the same > time, so it could happen that a KILL/TERM signal is sent to an > already deceased PID which was re-used, but it doesn't > happen in > practice since PIDs are not re-used very soon typically. > > But I agree, waiting between listing children and sending them > signals increases the chance of hitting a reused PID. > > > We do rely on the OS not reusing a PID _immediately_. We used > to have > bugs in this area where Process.destroy would send a signal to > a pid > that may have deceased arbitrarily long ago. > > > It seems to me that the key to avoiding this is to ensure that > waitpid() is not called until we know the PID is ready to be > cleaned. As long as waitpid() has not yet been called, we can be > certain that the process still exists and is ours. So the real > question is, how can we know a process is dead without actually > calling wait() (thereby making that knowledge useless)? > > The aforementioned /proc trick seems like one good way to do so > without, say, spawning a plethora of threads (though at one > additional FD per thread, it is not free either). Unforunately > /proc is not ubiquitous, and even where it does exist, it's not > standardized (thus its behavior probably cannot be relied upon > absolutely). > > A simple solution may be to use a synchronized set of child PIDs, > and set a SIGCHLD handler or waiter which, when triggered, locks > the set and performs a series of waitid() operations with WNOHANG, > processing all the process status updates. The signalling APIs > would be required to synchronize on the set to determine if the > process in question is owned by the parent process. Previously > unknown processes can be "adopted" into this area by acquiring the > synchronization and calling "waitpid()"+WNOHANG on the PID in > question, and using the result to determine whether the PID should > be added to the set (or whether we just reaped it - or whether it > doesn't belong to us at all). > > As long as the process API is restricted to managing direct > children, this should work and be safe across all POSIX-ish > environments. Note the potential downside that all children will > be automatically reaped, which is possibly somewhat hostile to > na?ve JNI libraries or embedders. Selectively enabling the /proc > trick can mitigate this downside on platforms which support it > however. > > -- > - DML > > From roger.riggs at oracle.com Thu Apr 17 15:00:55 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 17 Apr 2014 11:00:55 -0400 Subject: ProcessReaper: single thread reaper In-Reply-To: <534FE3DF.20606@gmail.com> References: <532C7A30.6060904@oracle.com> <53318D1C.3060104@gmail.com> <5331F979.4070308@Oracle.com> <53331313.8060804@gmail.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BA424.9040006@gmail.com> <534E8316.1040506@oracle.com> <534FE3DF.20606@gmail.com> Message-ID: <534FECA7.7070901@oracle.com> Hi Peter, Yes, factoring this into a discrete function make sense and then alternate implementations (if needed) are easy to select. I'm not sure it needs to build on the CompleteableFuture model but I don't see a reason to create something else. Roger On 4/17/2014 10:23 AM, Peter Levart wrote: > On 04/16/2014 03:18 PM, roger riggs wrote: >> Hi, >> >> Another approach was suggested by a member of the Solaris team. >> >> If you open /proc/pid O_RDONLY for any process you wish to monitor >> and use poll(2), you can wait for a hangup event which indicates that >> the process has exited. You can then reap that process's status w/ >> waitpid. You'll also want to wait on a pipe; as you fork additional >> processes you can write their pid to the pipe and the monitoring thread >> can wake up, read the pipe and add that fd to the pollfds. This will >> work for any version of Solaris you support, and it uses a fd per >> process; using the pipe mechanism no locking is required. >> >> I haven't had a chance to followup but it is interesting that >> monitoring /proc >> can give an indication of Process termination and some aspects should >> work on Linux, not just Solaris. >> >> Roger > > Hi Roger, > > An interesting idea. Another way to dynamically augment the list of > fds the single thread is poll()ing is to use a signal to interrupt > poll(), but using a pipe might be less hassle (thinking of setting up > per-thread signal masks, ...). > > So I think there's one more reason to create an internal API just for > that purpose (waiting on child exits, reaping their exit statuses and > dispatching events to Java threads) with multiple implementations > selectable by system property. The API could be as simple as: > > > interface ProcessReaper { > // called from Process API after spawning new child. > // returns exit status futureand registers the child > // to be reaped. > CompletableFuture processStarted(int pid); > > // optional - returns exit status future of a child process > // spawned by Process API which has not been reaped yet, > // null otherwise > CompletableFuture getExitStatus(int pid); > } > > > Regards, Peter > >> >> >> On 4/14/2014 5:02 AM, Peter Levart wrote: >>> Hi Martin, Roger, >>> >>> Just a thought. Would it be feasible to have two (ore more) built-in >>> strategies, selectable by system property? A backwards compatible >>> tread per child, using waitpid(pid, ...), a single reaper thread >>> using waitpid(-1, ...), maybe also single threaded strategy >>> accessible only on Linux/Solaris using waitid(-1, ..., WNOWAIT)... >>> All packed nicely in a package-private interface (ProcessReaper) >>> with multiple implementations? >>> >>> Regards, Peter >>> >>> On 04/12/2014 01:37 AM, Martin Buchholz wrote: >>>> Let's step back again and try to check our goals... >>>> >>>> We could try to optimize the one-reaper-thread-per-subprocess >>>> thing. But that is risky, and the cost of what we're doing today >>>> is not that high. >>>> >>>> We could try to implement the feature of killing off an entire >>>> subprocess tree. But historically, any kind of behavior change >>>> like that has been vetoed. I have tried and failed to make less >>>> incompatible changes. We would have to add a new API. >>>> >>>> The reality is that Java does not give you real access to the >>>> underlying OS, and unless there's a seriously heterodox attempt to >>>> provide OS-specific extensions, people will have to continue to >>>> either write native code or delegate to an OS-savvy subprocess like >>>> a perl script. >>>> >>>> >>>> On Fri, Apr 11, 2014 at 7:52 AM, Peter Levart >>>> > wrote: >>>> >>>> On 04/09/2014 07:02 PM, Martin Buchholz wrote: >>>>> >>>>> >>>>> >>>>> On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart >>>>> > wrote: >>>>> >>>>> Hi Martin, >>>>> >>>>> As you might have seen in my later reply to Roger, there's >>>>> still hope on that front: setpgid() + wait(-pgid, ...) might >>>>> be the answer. I'm exploring in that direction. Shells are >>>>> doing it, so why can't JDK? >>>>> >>>>> It's a little trickier for Process API, since I imagine that >>>>> shells form a group of processes from a pipeline which is >>>>> known in-advance while Process API will have to add >>>>> processes to the live group dynamically. So some races will >>>>> have to be resolved, but I think it's doable. >>>>> >>>>> >>>>> This is a clever idea, and it's arguably better to design >>>>> subprocesses so they live in separate process groups (emacs does >>>>> that), but: >>>>> Every time you create a process group, you change the effect of >>>>> a user signal like Ctrl-C, since it's sent to only one group. >>>>> Maybe propagate signals to the subprocess group? It's starting >>>>> to get complicated... >>>>> >>>> >>>> Hi Martin, >>>> >>>> Yes, shells send Ctrl-C (SIGINT) and other signals initiated by >>>> terminal to a (foreground) process group. A process group is >>>> formed from a pipeline of interconnected processes. Each pipeline >>>> is considered to be a separate "job", hence shells call this >>>> feature "job-control". Child processes by default inherit process >>>> group from it's parent, so children born with Process API (and >>>> their children) inherit the process group from the JVM process. >>>> Considering the intentions of shell job-controll, is propagating >>>> SIGTERM/SIGINT/SIGTSTP/SIGCONT signals to children spawned by >>>> Process API desirable? If so, then yes, handling those signals in >>>> JVM and propagating them to current process group that contains >>>> all children spawned by Process API and their descendants would >>>> have to be performed by JVM. That problem would certainly have to >>>> be addressed. But let's first see what I found out about >>>> sigaction(SIGCHLD, ...), setpgid(pid, pgid), waitpid(-pgid, ...), >>>> etc... >>>> >>>> waitpid(-pgid, ...) alone seems to not be enough for our task. >>>> Mainly because a process can re-assign it's group and join some >>>> other group. I don't know if this is a situation that occurs in >>>> real world, but imagine if we have one live child process in a >>>> process group pgid1 and no unwaited exited children. If we issue: >>>> >>>> waitpid(-pgid1, &status, 0); >>>> >>>> Then this call blocks, because at the time it was given, there >>>> were >0 child processes in the pgid1 group and none of them has >>>> exited yet. Now if this one child process changes it's process >>>> group with: >>>> >>>> setpgid(0, pgid2); >>>> >>>> Then the waitpid call in the parent does not return (maybe this >>>> is a bug in Linux?) although there are no more live child >>>> processes in the pgid1 group any more. Even when this child >>>> exits, the call to waitpid does not return, since this child is >>>> not in the group we are waiting for when it exits. If all our >>>> children "escape" the group in such way, the tread doing waiting >>>> will never unblock. To solve this, we can employ signal handlers. >>>> In a signal handler for SIGCHLD signal we can invoke: >>>> >>>> waitpid(-pgid1, &status, WNOHANG); // non-blocking call >>>> >>>> ...in loop until it either returns (0) which means that there're >>>> no more unwaited exited children in the group at the momen or >>>> (-1) with errno == ECHILD, which means that there're no more >>>> children in the queried group any more - the group does not exist >>>> any more. Since signal handler is invoked whith SIGCHLD being >>>> masked and there is one bit of pending signal state in the >>>> kernel, no child exit can be "skipped" this way. Unless the child >>>> "escapes" by changing it's group. I don't know of a plausible >>>> reason for a program to change it's process group. If a program >>>> executing as JVM child wants to become a background daemon it >>>> usually behaves as follows: >>>> >>>> - fork()s a grand-child and then exit()s (so we get notified via >>>> signal and waitpid(-pgid, ...) successfully for it's exitstatus) >>>> - the grand-child then changes it's session and group (becomes >>>> session and group leader), closes file descriptors, etc. The >>>> responsibility for waiting on the grand-child daemon is >>>> transferred to the init process (pid=1) since the grand-child >>>> becomes an orphan (has no parent). >>>> >>>> Ignoring this still unsolved problem of possible ill-behaved >>>> child program that changes it's process group, I started >>>> constructing a proof-of-concept prototype. What I will do in the >>>> prototype is start throwing IllegalStateException from the >>>> methods of the Process API that pertain to such children. I think >>>> this is reasonable. >>>> >>>> Stay tuned, >>>> >>>> Peter >>>> >>>> >>>> >>> >> > From david.lloyd at redhat.com Thu Apr 17 15:15:17 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 17 Apr 2014 10:15:17 -0500 Subject: ProcessReaper: single thread reaper In-Reply-To: <534FE8A8.1060308@gmail.com> References: <532C7A30.6060904@oracle.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BF296.6060002@oracle.com> <534C14A6.7030805@redhat.com> <534C4BAC.7050802@gmail.com> <534F055E.8070006@redhat.com> <534FE8A8.1060308@gmail.com> Message-ID: <534FF005.10007@redhat.com> On 04/17/2014 09:43 AM, Peter Levart wrote: > On 04/17/2014 09:07 AM, Martin Buchholz wrote: >> Many possible solutions eventually fail because whatever we do cannot >> take ownership of any global resource. Calling waitid on all child >> processes, even with NOWAIT and NOHANG changes global state (what if >> another subprocess library in the same process is trying to do the >> same thing?) > > waitid(P_ALL, ..., NOWAIT | NOHANG) does not reap the child. It can be > repeated multiple times. It can be used as a precursor to real > waitid/waitpid which reaps a child, but only if it is "ours". The > problem with this approach is what to do in the following scenario: the > precursor waitid(P_ALL, ..., NOWAIT | NOHANG) returns a child that is > not "ours" so we don't reap it. The "owner" of that child (JNI-library) > does not do prompt reaping of their children. We loop, repeatedly > getting the same child as a result, not seeing any other children that > have exited in the meanwhile... Maybe it would be a good idea to create a process group for JDK-managed subprocesses? Otherwise, it seems that the only other choice is to take over all child process management. > > Regards, Peter > >> >> >> On Wed, Apr 16, 2014 at 3:34 PM, David M. Lloyd >> > wrote: >> >> On 04/16/2014 02:15 PM, Martin Buchholz wrote: >> >> On Mon, Apr 14, 2014 at 1:57 PM, Peter Levart >> >> > >> wrote: >> >> >> There's already such a race in current implementation of >> Process.terminate(). It admittedly only concerns a small >> window >> between process exiting and the reaper thread managing to >> signal >> this state to the other threads wishing to terminate it at >> the same >> time, so it could happen that a KILL/TERM signal is sent to an >> already deceased PID which was re-used, but it doesn't >> happen in >> practice since PIDs are not re-used very soon typically. >> >> But I agree, waiting between listing children and sending them >> signals increases the chance of hitting a reused PID. >> >> >> We do rely on the OS not reusing a PID _immediately_. We used >> to have >> bugs in this area where Process.destroy would send a signal to >> a pid >> that may have deceased arbitrarily long ago. >> >> >> It seems to me that the key to avoiding this is to ensure that >> waitpid() is not called until we know the PID is ready to be >> cleaned. As long as waitpid() has not yet been called, we can be >> certain that the process still exists and is ours. So the real >> question is, how can we know a process is dead without actually >> calling wait() (thereby making that knowledge useless)? >> >> The aforementioned /proc trick seems like one good way to do so >> without, say, spawning a plethora of threads (though at one >> additional FD per thread, it is not free either). Unforunately >> /proc is not ubiquitous, and even where it does exist, it's not >> standardized (thus its behavior probably cannot be relied upon >> absolutely). >> >> A simple solution may be to use a synchronized set of child PIDs, >> and set a SIGCHLD handler or waiter which, when triggered, locks >> the set and performs a series of waitid() operations with WNOHANG, >> processing all the process status updates. The signalling APIs >> would be required to synchronize on the set to determine if the >> process in question is owned by the parent process. Previously >> unknown processes can be "adopted" into this area by acquiring the >> synchronization and calling "waitpid()"+WNOHANG on the PID in >> question, and using the result to determine whether the PID should >> be added to the set (or whether we just reaped it - or whether it >> doesn't belong to us at all). >> >> As long as the process API is restricted to managing direct >> children, this should work and be safe across all POSIX-ish >> environments. Note the potential downside that all children will >> be automatically reaped, which is possibly somewhat hostile to >> na?ve JNI libraries or embedders. Selectively enabling the /proc >> trick can mitigate this downside on platforms which support it >> however. >> >> -- >> - DML >> >> > -- - DML From peter.levart at gmail.com Thu Apr 17 15:33:12 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 17 Apr 2014 17:33:12 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <533F06FC.40102@oracle.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> Message-ID: <534FF438.7000601@gmail.com> Hi Martin, Since you are the author of the test/java/lang/ProcessBuilder/SecurityManagerClinit.java test, I thought I'll ask you about the purpose of the following line in the test just before setting up the Policy and SecurityManager: // A funky contrived security setup, just for bug repro purposes. java.security.Security.setProperty("package.access", "java.util"); The merge of UNIXProcess.java.* sources fails this test since it now uses lambdas in various places and it seems that MHs are involved that need access to java.util package from a class loaded by AppClassLoader. Would it defeat the purpose of the test if "java.util" package was replaced by say "sun.misc" which is normally restricted? Regards, Peter On 04/04/2014 09:24 PM, roger riggs wrote: > Hi Peter, > > I ran into one test problem when running this through its paces. > > The test: test/java/lang/ProcessBuilder/SecurityManagerClinit.java > throws a package access exception while creating a lambda > due to the wacky security manager and forbidding of access to java.util. > I hacked the test to remove the limitation on java.util. > > This looks good to me but a more experienced Reviewer should look at it. > > Thanks, Roger > > >> Right, >> >> Here it is: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.06/ > > > Stack dump from test: > java.lang.ExceptionInInitializerError > at > java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:256) > at > java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:221) > at > java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:210) > at > java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:82) > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1638) > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1602) > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1778) > at > java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1727) > at > java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:442) > at java.lang.UNIXProcess$Platform.get(UNIXProcess.java:147) > at java.lang.UNIXProcess.(UNIXProcess.java:160) > at java.lang.ProcessImpl.start(ProcessImpl.java:130) > at java.lang.ProcessBuilder.start(ProcessBuilder.java:1023) > at java.lang.Runtime.exec(Runtime.java:620) > at java.lang.Runtime.exec(Runtime.java:485) > at SecurityManagerClinit.main(SecurityManagerClinit.java:70) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:484) > at > com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) > at java.lang.Thread.run(Thread.java:744) > Caused by: java.security.AccessControlException: access denied > ("java.lang.RuntimePermission" "accessClassInPackage.java.util") > at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) > at > java.security.AccessController.checkPermission(AccessController.java:884) > at > java.lang.SecurityManager.checkPermission(SecurityManager.java:541) > at > java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1481) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305) > at java.lang.ClassLoader.loadClass(ClassLoader.java:359) > at > sun.invoke.util.BytecodeDescriptor.parseSig(BytecodeDescriptor.java:83) > at > sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:54) > at > sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:41) > at > java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:911) > at java.lang.invoke.MemberName.getMethodType(MemberName.java:144) > at > java.lang.invoke.LambdaForm.computeInitialPreparedForms(LambdaForm.java:477) > at java.lang.invoke.LambdaForm.(LambdaForm.java:1641) > From huizhe.wang at oracle.com Thu Apr 17 15:43:54 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 17 Apr 2014 08:43:54 -0700 Subject: Wrong encoding after XML identity transformation In-Reply-To: <5337235C.7070302@gmx.net> References: <5336EE48.8070008@gmx.net> <5337235C.7070302@gmx.net> Message-ID: <534FF6BA.90105@oracle.com> Hi Nico, The JDK is a few patches short of Xalan 2.7.1. At least one of the patches caused performance regression, which was the main reason they were not brought in. We plan to fix the issue and bring JDK to Xalan version 2.7.1. Could you file at https://bugs.openjdk.java.net/browse/JDK? Please select category "xml" and javax.xml.transform. Thanks, Joe On 3/29/2014 12:47 PM, Nico R. wrote: > Hello again! > > A few hours ago, I wrote: > [?] >> I?m attaching my test code, which I hope is correct and readable. > It seems that the list software stripped off the attachment with the > test program, so here it is again, inline: :-/ > > > > > // This document is encoded in UTF-8, with no BOM and with LF line endings. > > import java.io.ByteArrayInputStream; > import java.io.ByteArrayOutputStream; > import java.io.PrintStream; > > import java.util.ArrayList; > import java.util.List; > > import javax.xml.parsers.DocumentBuilder; > import javax.xml.parsers.DocumentBuilderFactory; > > import javax.xml.transform.OutputKeys; > import javax.xml.transform.Transformer; > import javax.xml.transform.TransformerFactory; > import javax.xml.transform.TransformerFactoryConfigurationError; > import javax.xml.transform.dom.DOMSource; > import javax.xml.transform.stream.StreamResult; > > import org.w3c.dom.Document; > import org.w3c.dom.Element; > import org.w3c.dom.Text; > > public class TransformerTest { > > /** convenience method, prints a byte array in human-readable ASCII > chars */ > private static void printArray(byte[] data, PrintStream out) { > if (data == null) { > out.println("(null)"); > return; > } > > if (data.length == 0) { > out.println("(empty array)"); > return; > } > > for (int i = 0; ; ) { > byte b = data[i]; > if (b >= 0x20 && b <= 0x7F) { > out.print(" '" + (char)b + "'"); > } else { > out.format("0x%02X", (int)b & 0xFF); > } > > if (++i == data.length) break; > > if ((i % 16) == 0) { > out.println(','); > } else { > out.print(", "); > } > } > out.println(); > } > > /** > * parses a {@code Document} from an {@code InputStream} (and not from a > * {@code StringReader}, in order to make sure it?s not a problem when > * parsing internal Unicode {@code String}s) > */ > private static Document makeDocument() throws Exception { > DocumentBuilder builder = > DocumentBuilderFactory.newInstance().newDocumentBuilder(); > > byte[] docBytes = { > '<', '?', 'x', 'm', 'l', ' ', > > 'v', 'e', 'r', 's', 'i', 'o', 'n', '=', > '"', '1', '.', '0', '"', ' ', > > // document is encoded in US-ASCII, but labelled as a superset > 'e', 'n', 'c', 'o', 'd', 'i', 'n', 'g', '=', > '"', 'I', 'S', 'O', '-', '8', '8', '5', '9', '-', '1', '"', > > '?', '>', > > '<', 'x', '/', '>' > }; > > return builder.parse(new ByteArrayInputStream(docBytes)); > } > > /** prepares a list of transformer factories to test */ > private static List makeTransformerFactories() { > String[] facNames = { > "org.apache.xalan.processor.TransformerFactoryImpl", > "org.apache.xalan.xsltc.trax.TransformerFactoryImpl", > > "com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl" > }; > > List transFactories = new ArrayList<>(); > > for (String facName : facNames) { > try { > TransformerFactory factory = > TransformerFactory.newInstance(facName, null); > transFactories.add(factory); > } catch (TransformerFactoryConfigurationError ex) { > System.out.println("cannot build instance of " + facName); > } > } > > //transFactories.add(TransformerFactory.newInstance()); // > default impl > > return transFactories; > } > > private static byte[] transformWith(TransformerFactory transFac, > Document doc) throws Exception { > Transformer trans = transFac.newTransformer(); > trans.setOutputProperty(OutputKeys.METHOD, "xml"); > trans.setOutputProperty(OutputKeys.ENCODING, "UTF-8"); > System.out.println("transformer factory: " + > transFac.getClass().getName()); > System.out.println("transformer: " + trans.getClass().getName()); > > ByteArrayOutputStream bout = new ByteArrayOutputStream(128); > > trans.transform(new DOMSource(doc), new StreamResult(bout)); > > byte[] data = bout.toByteArray(); > > return data; > } > > public static void main(String[] t) throws Exception { > Document doc = makeDocument(); > > System.out.println( > "encoding declared in document : " + > doc.getXmlEncoding()); > > > // now insert a text node containing a character which can be > // represented in ISO-8859-1, as well as (differently) in UTF-8, > but not > // in US-ASCII > > Element dstRoot = doc.getDocumentElement(); > Text text = doc.createTextNode("sch?n"); > dstRoot.insertBefore(text, null); > System.out.println("root element text: " + > dstRoot.getTextContent()); > > > List factories = makeTransformerFactories(); > for (TransformerFactory factory : factories) { > System.out.println(); > byte[] bytes = transformWith(factory, doc); > > System.out.println("resulting bytes:"); > printArray(bytes, System.out); > } > } > > } > > > > From brian.goetz at oracle.com Thu Apr 17 16:47:41 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 17 Apr 2014 12:47:41 -0400 Subject: getFirst and getLast on Iterable In-Reply-To: References: Message-ID: <535005AD.2020207@oracle.com> In the course of JSR-335, we considered a number of possible methods on Iterable. There are literally hundreds of methods that might "sensibly" appear on Iterable; see RichIterable from GS-Collections or IEnumerable from .NET for some examples. After considering the landscape, we decided, basically, to not do any of them. The reason is that Iterable is *so general* and *so ubiquitous* that adding new methods at this stage would carry an unreasonable risk of collision. When viewed through the lens of "what is an Iterable", the meaning of a "getFirst()" is obvious enough. (getLast(), not so much; this assumes there is a last, which is a bad assumption, given that there's no size() or isKnownFinite() method.) The problem is, in the context of some Foo that implements Iterable, methods like getFirst() or sorted() or filter() or ... might not obviously mean in the context of Foo what they obviously mean in the context of Iterable. Iterable is too general. And there are zillions of outstanding Iterable classes now, so the risk is high. So given the choice between adding a zillion new methods, and adding zero (which is basically the choice, drawing the line is very hard and will always be under pressure to move "just one more method to the left"), we chose zero. On 4/17/2014 7:52 AM, Ot?vio Gon?alves de Santana wrote: > I would to add for news methods on Iterable, I believe it will helpful for > many Java Developers. > > > diff -r 3dd165facde7 test/java/util/Iterator/IteratorDefaults.java > > --- a/test/java/util/Iterator/IteratorDefaults.java Wed Apr 09 12:26:00 > 2014 -0700 > > +++ b/test/java/util/Iterator/IteratorDefaults.java Wed Apr 16 23:25:56 > 2014 -0300 > > @@ -399,6 +399,48 @@ > > } > > } > > > > + public void testgetFirst() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + int first = source.getFirst(); > > + assertEquals(first, 1); > > + > > + List emptySource = Collections.emptyList(); > > + assertNull(emptySource.getFirst()); > > + } > > + > > + public void testgetFirstWithDefaultElement() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + Integer defaultElement = 5; > > + assertEquals(source.getFirst(defaultElement), Integer.valueOf(1)); > > + > > + List emptySource = Collections.emptyList(); > > + assertEquals(emptySource.getFirst(defaultElement), defaultElement); > > + > > + } > > + > > + public void testgetLast() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + int last = source.getLast(); > > + assertEquals(last, 4); > > + > > + List emptySource = Collections.emptyList(); > > + assertNull(emptySource.getLast()); > > + } > > + > > + public void testgetLastWithDefaultElement() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + Integer defaultElement = 5; > > + assertEquals(source.getLast(defaultElement), Integer.valueOf(4)); > > + > > + List emptySource = Collections.emptyList(); > > + assertEquals(emptySource.getLast(defaultElement), defaultElement); > > + > > + } > > + > > static class IteratorWithRemove implements Iterator { > > > > public boolean removed; > > > > > diff -r 3dd165facde7 src/share/classes/java/lang/Iterable.java > > --- a/src/share/classes/java/lang/Iterable.java Wed Apr 09 12:26:00 2014 > -0700 > > +++ b/src/share/classes/java/lang/Iterable.java Wed Apr 16 23:16:21 2014 > -0300 > > @@ -100,4 +100,55 @@ > > default Spliterator spliterator() { > > return Spliterators.spliteratorUnknownSize(iterator(), 0); > > } > > + > > + > > + /** > > + * returns the first element, if empty will return {@code null} > > + * @return the first element or {@code null} > > + * @since 1.8 > > + */ > > + default T getFirst() { > > + return getFirst(null); > > + } > > + > > + /** > > + * returns the first element, if empty will return the default > > + * @param defaultValue - the default value to return if the iterable > is empty > > + * @return the first element or default element > > + * @since 1.8 > > + */ > > + default T getFirst(T defaultValue) { > > + for (T element : this) { > > + return element; > > + } > > + return defaultValue; > > + } > > + > > + /** > > + * returns the last element, if empty will return {@code null} > > + * @return the first element or {@code null} > > + * @since 1.8 > > + */ > > + default T getLast() { > > + > > + return getLast(null); > > + } > > + > > + /** > > + * returns the last element, if empty will return the default > > + * @param defaultValue - the default value to return if the iterable > is empty > > + * @return the last element or default element > > + * @since 1.8 > > + */ > > + default T getLast(T defaultValue) { > > + > > + T last = null; > > + for (T element : this) { > > + last = element; > > + } > > + if (Objects.isNull(last)) { > > + return defaultValue; > > + } > > + return last; > > + } > > } > From martinrb at google.com Thu Apr 17 16:50:47 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Apr 2014 09:50:47 -0700 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <534FF438.7000601@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> Message-ID: This test tries to make sure we have all of the doPrivileged blocks in place. Which is hard to do. I don't recall the details. It would seem better to simply test that processes can be executed if the very specific permission to do just that was provided. Which IIRC ProcessBuilder/Basic.java already has tests for. Ohhh.... but to test clinit behavior, they have to be in a new JVM instance, so the existing tests in Basic are insufficient for that purpose. But it would be cumbersome to transplant current security tests from Basic into an environment where it's the only invocation of the process api. On Thu, Apr 17, 2014 at 8:33 AM, Peter Levart wrote: > Hi Martin, > > Since you are the author of the test/java/lang/ProcessBuilder/SecurityManagerClinit.java > test, I thought I'll ask you about the purpose of the following line in the > test just before setting up the Policy and SecurityManager: > > // A funky contrived security setup, just for bug repro purposes. > java.security.Security.setProperty("package.access", "java.util"); > > The merge of UNIXProcess.java.* sources fails this test since it now uses > lambdas in various places and it seems that MHs are involved that need > access to java.util package from a class loaded by AppClassLoader. Would it > defeat the purpose of the test if "java.util" package was replaced by say > "sun.misc" which is normally restricted? > > Regards, Peter > > > On 04/04/2014 09:24 PM, roger riggs wrote: > >> Hi Peter, >> >> I ran into one test problem when running this through its paces. >> >> The test: test/java/lang/ProcessBuilder/SecurityManagerClinit.java >> throws a package access exception while creating a lambda >> due to the wacky security manager and forbidding of access to java.util. >> I hacked the test to remove the limitation on java.util. >> >> This looks good to me but a more experienced Reviewer should look at it. >> >> Thanks, Roger >> >> >> Right, >>> >>> Here it is: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.06/ >>> >> >> >> Stack dump from test: >> java.lang.ExceptionInInitializerError >> at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm( >> DirectMethodHandle.java:256) >> at java.lang.invoke.DirectMethodHandle.preparedLambdaForm( >> DirectMethodHandle.java:221) >> at java.lang.invoke.DirectMethodHandle.preparedLambdaForm( >> DirectMethodHandle.java:210) >> at java.lang.invoke.DirectMethodHandle.make( >> DirectMethodHandle.java:82) >> at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon( >> MethodHandles.java:1638) >> at java.lang.invoke.MethodHandles$Lookup. >> getDirectMethodNoSecurityManager(MethodHandles.java:1602) >> at java.lang.invoke.MethodHandles$Lookup. >> getDirectMethodForConstant(MethodHandles.java:1778) >> at java.lang.invoke.MethodHandles$Lookup. >> linkMethodHandleConstant(MethodHandles.java:1727) >> at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant( >> MethodHandleNatives.java:442) >> at java.lang.UNIXProcess$Platform.get(UNIXProcess.java:147) >> at java.lang.UNIXProcess.(UNIXProcess.java:160) >> at java.lang.ProcessImpl.start(ProcessImpl.java:130) >> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1023) >> at java.lang.Runtime.exec(Runtime.java:620) >> at java.lang.Runtime.exec(Runtime.java:485) >> at SecurityManagerClinit.main(SecurityManagerClinit.java:70) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke( >> NativeMethodAccessorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke( >> DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:484) >> at com.sun.javatest.regtest.MainWrapper$MainThread.run( >> MainWrapper.java:94) >> at java.lang.Thread.run(Thread.java:744) >> Caused by: java.security.AccessControlException: access denied >> ("java.lang.RuntimePermission" "accessClassInPackage.java.util") >> at java.security.AccessControlContext.checkPermission( >> AccessControlContext.java:457) >> at java.security.AccessController.checkPermission( >> AccessController.java:884) >> at java.lang.SecurityManager.checkPermission( >> SecurityManager.java:541) >> at java.lang.SecurityManager.checkPackageAccess( >> SecurityManager.java:1481) >> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305) >> at java.lang.ClassLoader.loadClass(ClassLoader.java:359) >> at sun.invoke.util.BytecodeDescriptor.parseSig( >> BytecodeDescriptor.java:83) >> at sun.invoke.util.BytecodeDescriptor.parseMethod( >> BytecodeDescriptor.java:54) >> at sun.invoke.util.BytecodeDescriptor.parseMethod( >> BytecodeDescriptor.java:41) >> at java.lang.invoke.MethodType.fromMethodDescriptorString( >> MethodType.java:911) >> at java.lang.invoke.MemberName.getMethodType(MemberName.java:144) >> at java.lang.invoke.LambdaForm.computeInitialPreparedForms( >> LambdaForm.java:477) >> at java.lang.invoke.LambdaForm.(LambdaForm.java:1641) >> >> > From stuart.marks at oracle.com Thu Apr 17 17:49:33 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 17 Apr 2014 10:49:33 -0700 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <534CF1D5.70605@oracle.com> References: <534CF1D5.70605@oracle.com> Message-ID: <5350142D.8040706@oracle.com> On 4/15/14 1:46 AM, Alan Bateman wrote: > On 15/04/2014 09:05, Richard Warburton wrote: >> The only issue that I'm aware of that is related to this kind of change is >> the requirement to recompile all the classes in the hierarchy when making a >> change [0]. If you don't do this its possible for an infinite recursion and >> eventual stackoverflow to occur. Now as far as I can tell the >> entire hierarchy of Buffer classes are all either package scoped classes, >> or they are public classes with package scoped constructors. So I'm not >> aware of a way to sub class them without the code being part of the JDK. >> This would mean that the subclasses all need to be recompiled, satisfying >> the safety criteria. >> > This is a long standing bug to look at this issue [1]. CharBuffer.subSequence > was one case that was retrofitted in 7. As you note, buffers are not designed to > be extended outside of the java.nio package so this should make a number of > options possible. > > [1] https://bugs.openjdk.java.net/browse/JDK-4774077 Hi Richard, It looks to me like there are no obvious problems with changing the buffer subclasses to use covariant overrides. As Alan mentioned, one API was modified this way in 7, by Martin Buchholz. The discussion threads for this change are [2] and [3]. It looks like Martin considered additional covariant overrides, but ultimately backed off from this for a variety of incidental reasons; see [4]. There is a certain amount of work here above and beyond just changing the return types, but there don't appear to be any fundamental issues. Ulf posted several links, but these seem mostly related to language change proposals related to implicit method invocation chaining. I don't think these proposals are active at the moment, so I'd suggest that you pursue a library-only change. s'marks [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-July/000596.html [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-August/000599.html [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-August/000612.html From peter.levart at gmail.com Thu Apr 17 19:58:33 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 17 Apr 2014 21:58:33 +0200 Subject: ProcessReaper: single thread reaper In-Reply-To: <534FF005.10007@redhat.com> References: <532C7A30.6060904@oracle.com> <533315EC.3000601@Oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BF296.6060002@oracle.com> <534C14A6.7030805@redhat.com> <534C4BAC.7050802@gmail.com> <534F055E.8070006@redhat.com> <534FE8A8.1060308@gmail.com> <534FF005.10007@redhat.com> Message-ID: <53503269.9050204@gmail.com> On 04/17/2014 05:15 PM, David M. Lloyd wrote: > On 04/17/2014 09:43 AM, Peter Levart wrote: >> On 04/17/2014 09:07 AM, Martin Buchholz wrote: >>> Many possible solutions eventually fail because whatever we do cannot >>> take ownership of any global resource. Calling waitid on all child >>> processes, even with NOWAIT and NOHANG changes global state (what if >>> another subprocess library in the same process is trying to do the >>> same thing?) >> >> waitid(P_ALL, ..., NOWAIT | NOHANG) does not reap the child. It can be >> repeated multiple times. It can be used as a precursor to real >> waitid/waitpid which reaps a child, but only if it is "ours". The >> problem with this approach is what to do in the following scenario: the >> precursor waitid(P_ALL, ..., NOWAIT | NOHANG) returns a child that is >> not "ours" so we don't reap it. The "owner" of that child (JNI-library) >> does not do prompt reaping of their children. We loop, repeatedly >> getting the same child as a result, not seeing any other children that >> have exited in the meanwhile... > > Maybe it would be a good idea to create a process group for > JDK-managed subprocesses? Otherwise, it seems that the only other > choice is to take over all child process management. This was the first idea discussed in the thread. But it's not fool-proof either. Parent can set the process group of a child at it's creation (after fork() but before execv() or as the very act of posix_spawn()), but the child is free to change it's group at any time after that. Such child "escapes" the group and waiting on the group id: waitpid(-pgid, ...) ...will never reap this child even after it exits. The escaping act is never reported to the parent. This usually does not happen in practice. Daemon processes are one of two kinds of processes that I know of, that change the group id, but they are grand-children of the JVM, not children, the other kind are processes spawned by some shell or other program that groups it's children in process groups to manage them so they are JVM grand-children too, so this is not a problem in practice, I think. But it's not a full-proof scheme. Regards, Peter > >> >> Regards, Peter >> >>> >>> >>> On Wed, Apr 16, 2014 at 3:34 PM, David M. Lloyd >>> > wrote: >>> >>> On 04/16/2014 02:15 PM, Martin Buchholz wrote: >>> >>> On Mon, Apr 14, 2014 at 1:57 PM, Peter Levart >>> >>> >> >> wrote: >>> >>> >>> There's already such a race in current implementation of >>> Process.terminate(). It admittedly only concerns a small >>> window >>> between process exiting and the reaper thread managing to >>> signal >>> this state to the other threads wishing to terminate it at >>> the same >>> time, so it could happen that a KILL/TERM signal is sent >>> to an >>> already deceased PID which was re-used, but it doesn't >>> happen in >>> practice since PIDs are not re-used very soon typically. >>> >>> But I agree, waiting between listing children and >>> sending them >>> signals increases the chance of hitting a reused PID. >>> >>> >>> We do rely on the OS not reusing a PID _immediately_. We used >>> to have >>> bugs in this area where Process.destroy would send a signal to >>> a pid >>> that may have deceased arbitrarily long ago. >>> >>> >>> It seems to me that the key to avoiding this is to ensure that >>> waitpid() is not called until we know the PID is ready to be >>> cleaned. As long as waitpid() has not yet been called, we can be >>> certain that the process still exists and is ours. So the real >>> question is, how can we know a process is dead without actually >>> calling wait() (thereby making that knowledge useless)? >>> >>> The aforementioned /proc trick seems like one good way to do so >>> without, say, spawning a plethora of threads (though at one >>> additional FD per thread, it is not free either). Unforunately >>> /proc is not ubiquitous, and even where it does exist, it's not >>> standardized (thus its behavior probably cannot be relied upon >>> absolutely). >>> >>> A simple solution may be to use a synchronized set of child PIDs, >>> and set a SIGCHLD handler or waiter which, when triggered, locks >>> the set and performs a series of waitid() operations with WNOHANG, >>> processing all the process status updates. The signalling APIs >>> would be required to synchronize on the set to determine if the >>> process in question is owned by the parent process. Previously >>> unknown processes can be "adopted" into this area by acquiring the >>> synchronization and calling "waitpid()"+WNOHANG on the PID in >>> question, and using the result to determine whether the PID should >>> be added to the set (or whether we just reaped it - or whether it >>> doesn't belong to us at all). >>> >>> As long as the process API is restricted to managing direct >>> children, this should work and be safe across all POSIX-ish >>> environments. Note the potential downside that all children will >>> be automatically reaped, which is possibly somewhat hostile to >>> na?ve JNI libraries or embedders. Selectively enabling the /proc >>> trick can mitigate this downside on platforms which support it >>> however. >>> >>> -- >>> - DML >>> >>> >> > > From peter.levart at gmail.com Thu Apr 17 21:49:06 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 17 Apr 2014 23:49:06 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> Message-ID: <53504C52.3020509@gmail.com> Hi, I'm cross-posting this on the mlvm-dev mailing list, because I think it concerns internal MHs implementation. While replacing some inner classes with lambdas in java.lang.UNIXProcess class, a jtreg test started failing. This test is employing a security manager with an unusual configuration. It defines "java.util" as a package for which access should be checked against the set of permissions. The class initialization of UNIXProcess class initializes some lambdas and their initialization fails with the following stack-trace: java.lang.ExceptionInInitializerError at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:256) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:221) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:210) at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:82) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1638) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1602) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1778) at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1727) at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:442) at java.lang.UNIXProcess$Platform.get(UNIXProcess.java:147) at java.lang.UNIXProcess.(UNIXProcess.java:160) at java.lang.ProcessImpl.start(ProcessImpl.java:130) at java.lang.ProcessBuilder.start(ProcessBuilder.java:1023) at java.lang.Runtime.exec(Runtime.java:620) at java.lang.Runtime.exec(Runtime.java:485) at SecurityManagerClinit.main(SecurityManagerClinit.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:484) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:744) Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.java.util") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:541) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1481) * at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305)* at java.lang.ClassLoader.loadClass(ClassLoader.java:359) at sun.invoke.util.BytecodeDescriptor.parseSig(BytecodeDescriptor.java:83) * at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:54)* at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:41) at java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:911) at java.lang.invoke.MemberName.getMethodType(MemberName.java:144) at java.lang.invoke.LambdaForm.computeInitialPreparedForms(LambdaForm.java:477) at java.lang.invoke.LambdaForm.(LambdaForm.java:1641) I think I found the root cause of the problem. It's nothing wrong with the test (although making "java.util" as an access-checked package is a little unusual). The problem, I think, is in MH's LambdaForm implementation. Although the UNIXProcess class is a system class (loaded by bootstrap class loader), MHs created by evaluating lambda expressions in this class, trigger loading a class in "java.util" package using AppClassLoader as the initiating class loader, which involves package access checks. This should not happen, I think, if only the system classes are involved in constructing MHs. I checked the code and there's a ClassLoader parameter passed to the *BytecodeDescriptor.parseMethod *method. This ClassLoader is taken as the defining class loader of the MemberName's declaring class for which the getMethoType() is requested. All the types involved in such MemberName (return type, parameter types) should be resolvable from the MemberName's declaring class' class loader. In our case, the class loader of the declaring class of the particular MemberName is bootstrap class loader, so null is passed as the ClassLoader parameter to the *BytecodeDescriptor.parseMethod *method. This method checks for null ClassLoader and replaces it with ClassLoader.getSystemClassLoader() before calling parseSig() with it, because parseSig() uses the ClassLoader instance to invoke loadClass() method on it. The ClassLoader.getSystemClassLoader() is the application class-loader (AppClassLoader). I think the right thing to do would be to use bootstrap class loader if the ClassLoader parameter passed to *BytecodeDescriptor.parseMethod *was null. The fix would be as follows: =================================================================== --- jdk/src/share/classes/sun/invoke/util/BytecodeDescriptor.java (revision 9770:8371276d52c0) +++ jdk/src/share/classes/sun/invoke/util/BytecodeDescriptor.java (revision 9770+:8371276d52c0+) @@ -43,8 +43,6 @@ static List> parseMethod(String bytecodeSignature, int start, int end, ClassLoader loader) { - if (loader == null) - loader = ClassLoader.getSystemClassLoader(); String str = bytecodeSignature; int[] i = {start}; ArrayList> ptypes = new ArrayList>(); @@ -80,7 +78,7 @@ i[0] = endc+1; String name = str.substring(begc, endc).replace('/', '.'); try { - return loader.loadClass(name); + return Class.forName(name, false, loader); } catch (ClassNotFoundException ex) { throw new TypeNotPresentException(name, ex); } What do you think? Am I right? Regards, Peter Regards, Peter On 04/17/2014 06:50 PM, Martin Buchholz wrote: > This test tries to make sure we have all of the doPrivileged blocks in > place. Which is hard to do. I don't recall the details. It would > seem better to simply test that processes can be executed if the very > specific permission to do just that was provided. Which IIRC > ProcessBuilder/Basic.java already has tests for. Ohhh.... but to test > clinit behavior, they have to be in a new JVM instance, so the > existing tests in Basic are insufficient for that purpose. But it > would be cumbersome to transplant current security tests from Basic > into an environment where it's the only invocation of the process api. > > > On Thu, Apr 17, 2014 at 8:33 AM, Peter Levart > wrote: > > Hi Martin, > > Since you are the author of the > test/java/lang/ProcessBuilder/SecurityManagerClinit.java test, I > thought I'll ask you about the purpose of the following line in > the test just before setting up the Policy and SecurityManager: > > // A funky contrived security setup, just for bug repro > purposes. > java.security.Security.setProperty("package.access", > "java.util"); > > The merge of UNIXProcess.java.* sources fails this test since it > now uses lambdas in various places and it seems that MHs are > involved that need access to java.util package from a class loaded > by AppClassLoader. Would it defeat the purpose of the test if > "java.util" package was replaced by say "sun.misc" which is > normally restricted? > > Regards, Peter > > > On 04/04/2014 09:24 PM, roger riggs wrote: > > Hi Peter, > > I ran into one test problem when running this through its paces. > > The test: test/java/lang/ProcessBuilder/SecurityManagerClinit.java > throws a package access exception while creating a lambda > due to the wacky security manager and forbidding of access to > java.util. > I hacked the test to remove the limitation on java.util. > > This looks good to me but a more experienced Reviewer should > look at it. > > Thanks, Roger > > > Right, > > Here it is: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.06/ > > > > > Stack dump from test: > java.lang.ExceptionInInitializerError > at > java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:256) > at > java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:221) > at > java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:210) > at > java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:82) > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1638) > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1602) > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1778) > at > java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1727) > at > java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:442) > at > java.lang.UNIXProcess$Platform.get(UNIXProcess.java:147) > at java.lang.UNIXProcess.(UNIXProcess.java:160) > at java.lang.ProcessImpl.start(ProcessImpl.java:130) > at > java.lang.ProcessBuilder.start(ProcessBuilder.java:1023) > at java.lang.Runtime.exec(Runtime.java:620) > at java.lang.Runtime.exec(Runtime.java:485) > at > SecurityManagerClinit.main(SecurityManagerClinit.java:70) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:484) > at > com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) > at java.lang.Thread.run(Thread.java:744) > Caused by: java.security.AccessControlException: access denied > ("java.lang.RuntimePermission" "accessClassInPackage.java.util") > at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) > at > java.security.AccessController.checkPermission(AccessController.java:884) > at > java.lang.SecurityManager.checkPermission(SecurityManager.java:541) > at > java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1481) > at > sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305) > at java.lang.ClassLoader.loadClass(ClassLoader.java:359) > at > sun.invoke.util.BytecodeDescriptor.parseSig(BytecodeDescriptor.java:83) > at > sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:54) > at > sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:41) > at > java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:911) > at > java.lang.invoke.MemberName.getMethodType(MemberName.java:144) > at > java.lang.invoke.LambdaForm.computeInitialPreparedForms(LambdaForm.java:477) > at > java.lang.invoke.LambdaForm.(LambdaForm.java:1641) > > > From david.lloyd at redhat.com Thu Apr 17 22:19:43 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 17 Apr 2014 17:19:43 -0500 Subject: ProcessReaper: single thread reaper In-Reply-To: <53503269.9050204@gmail.com> References: <532C7A30.6060904@oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BF296.6060002@oracle.com> <534C14A6.7030805@redhat.com> <534C4BAC.7050802@gmail.com> <534F055E.8070006@redhat.com> <534FE8A8.1060308@gmail.com> <534FF005.10007@redhat.com> <53503269.9050204@gmail.com> Message-ID: <5350537F.3030408@redhat.com> On 04/17/2014 02:58 PM, Peter Levart wrote: > > On 04/17/2014 05:15 PM, David M. Lloyd wrote: >> On 04/17/2014 09:43 AM, Peter Levart wrote: >>> On 04/17/2014 09:07 AM, Martin Buchholz wrote: >>>> Many possible solutions eventually fail because whatever we do cannot >>>> take ownership of any global resource. Calling waitid on all child >>>> processes, even with NOWAIT and NOHANG changes global state (what if >>>> another subprocess library in the same process is trying to do the >>>> same thing?) >>> >>> waitid(P_ALL, ..., NOWAIT | NOHANG) does not reap the child. It can be >>> repeated multiple times. It can be used as a precursor to real >>> waitid/waitpid which reaps a child, but only if it is "ours". The >>> problem with this approach is what to do in the following scenario: the >>> precursor waitid(P_ALL, ..., NOWAIT | NOHANG) returns a child that is >>> not "ours" so we don't reap it. The "owner" of that child (JNI-library) >>> does not do prompt reaping of their children. We loop, repeatedly >>> getting the same child as a result, not seeing any other children that >>> have exited in the meanwhile... >> >> Maybe it would be a good idea to create a process group for >> JDK-managed subprocesses? Otherwise, it seems that the only other >> choice is to take over all child process management. > > This was the first idea discussed in the thread. But it's not fool-proof > either. Parent can set the process group of a child at it's creation > (after fork() but before execv() or as the very act of posix_spawn()), > but the child is free to change it's group at any time after that. Such > child "escapes" the group and waiting on the group id: > > waitpid(-pgid, ...) > > ...will never reap this child even after it exits. The escaping act is > never reported to the parent. This usually does not happen in practice. > Daemon processes are one of two kinds of processes that I know of, that > change the group id, but they are grand-children of the JVM, not > children, the other kind are processes spawned by some shell or other > program that groups it's children in process groups to manage them so > they are JVM grand-children too, so this is not a problem in practice, I > think. But it's not a full-proof scheme. Yeah definitely not. I guess I am indeed going in circles at this point. I wonder though if you'll indulge me a bit longer, and verify my collected understanding of the requirements of what is being requested here: 1) The process API must reap all child processes it produces that terminate during the lifetime of the JVM, leaving no zombies (including processes which have changed process group and/or session) 2) The process API must allow for child processes which are not managed by it (by not attempting to reap them except as allowed by #3) 3) The process API must somehow be able to "adopt" other child processes produced by means other than the Process API 4) The process reaper should keep resource consumption to a minimum (preferably no more than one thread, preferably no more than one extra FD per process) 5) The process API must provide an explicitly graceful terminate method in addition to the existing forcible and "unspecified" destroy methods 6) The process API must provide safeguards to prevent the wrong process from being signaled (i.e. would be required to synchronize process reaping with termination/signaling (PID reuse probabilities notwithstanding)) I've deliberately left off any mention of direct management of grandchild processes. I believe it was pretty well established by Peter Levart that a child is solely the responsibility of its parent. Martin Buchholz has doubts about it as well. I think Roger Riggs had some unaddressed disagreement though. For what it's worth, I agree with Peter on this point, because I think managing grand+children makes #6 difficult or impossible to satisfy. But the topic, AFAIK, remains open. Also I haven't brought up anything from JEP 102 that I haven't already seen on this thread. These requirements seem to exclude some techniques brought up on the thread previously: - waitid(P_ALL,...)/waitpid(-1,...) (which violates #2, either directly, or by simply failing in the WNOWAIT|WNOHANG + unmanaged child process case previously outlined by Peter Levart). - setpgid() to an all-child process group + waitid(P_PID,...) (which allows badly behaved processes to cause us to violate #1, and also prevents automatic propagation of e.g. SIGTERM/SIGINT) - setpgid() to a per-child process group (same problems, also no workable reaping solution was found that I saw) - SIGCHLD + siginfo (very unlikely to work consistently or correctly) - anything relying on WNOWAIT on Mac OS X and maybe others I think everyone liked the idea of pluggable implementations. I didn't see this mentioned on this thread, but it seems to me that we can have a simple 100% correct implementation on UNIX-likes by retaining a single thread per child process (today each one has a 32k stack, maybe it could be even smaller?). Much like the default polling SelectorProvider for NIO, this could act as a simple fallback implementation that will always work and be correct. On proc-enabled systems, using poll or similar on the corresponding proc files seems like a possible alternative implementation requiring one additional FD per child process and only one reaper thread, since it seems possible to meet all 6 above requirements, though lack of standardization might add risk. Using a single thread to iterate all child PIDs each time a SIGCHLD is received (with WNOHANG) would work without consuming more than one thread and zero FDs total, however it scales poorly with very large numbers of child processes, and it might be considered a violation of #2 to use SIGCHLD anyway. Maybe these ideas could be implemented as an alternative, contingent on -Xrs, or contingent on the previous handler being SIG_IGN similarly to the suggestion by Martin Buchholz. I didn't see any other workable implementation alternatives. As for API, I had suggested that "adopted" processes have a strict subset of functions compared to "managed" processes, and thus could be a supertype of Process. Martin indicated that managing grandchildren should have a different API altogether. Peter seems to lean towards exposing the OS capabilities a bit more directly, through child process ID enumeration (presumably including managed and unmanaged processes in the same bucket) and an API which operates on any child process by ID, regardless of its disposition (though I don't know of any portable API to enumerate child processes; on Linux I believe you have to use /proc). Peter also suggested that a process reaper be a primary internal API construct. Did I miss anything? -- - DML From weijun.wang at oracle.com Fri Apr 18 03:28:03 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 18 Apr 2014 11:28:03 +0800 Subject: How to mount a volume with file owners being nobody? Message-ID: <5B438ACC-51B7-44A9-8952-E5A1CD2E823A@oracle.com> I have seen such things before but cannot create one now. I would like to simulate a problematic environment on my own machines. Any suggestion is welcomed, I have Mac OS X and Windows at hand but Linux and Solaris are also OK. Thanks Max From ivan.gerasimov at oracle.com Fri Apr 18 08:32:22 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 18 Apr 2014 12:32:22 +0400 Subject: String.indexOf optimization In-Reply-To: References: <534D68B8.3040002@oracle.com> Message-ID: <5350E316.2050406@oracle.com> On 16.04.2014 2:53, Martin Buchholz wrote: > Hi Ivan, > > There's already an indexOf(int, int) that allows a user to explicitly > search for a char (or character). > Sure. What I meant was not to introduce a special function for searching a single character, but to restrict the general case loop to search for a substring of at least 2 characters. Having this condition hold, we can enter the loop only when two starting characters match, and this can save us a few nanoseconds in many cases. > Hotspot seems to have some intrinsification of String.indexOf, which > confuses me. > Does it mean that that the java implementation of indexOf is never compiled? When hotspot replaces the jdk implementation with its own one? Is it ever worth to try to optimize the java implementation? > Hotspot seems the right place to provide more optimizations for this, > since there has been a fair amount of work creating high-performance > low-level implementations of this idea in C. > The hotspot's intrinsic is already optimized for searching substrings of different length. Sincerely yours, Ivan > > On Tue, Apr 15, 2014 at 10:13 AM, Ivan Gerasimov > > wrote: > > Hi everyone! > > > On 04.04.2014 21:13, Martin Buchholz wrote: >> Summary: >> >> Many people (myself included) have looked at this problem. It's unlikely >> that String.indexOf will change. It's hard to beat the naive >> implementation in the typical case. > But we can try to speed up this naive implementation a little bit. > > We can separate the special case: When the substring's length == 1. > This special case can be done fast, and in the general case we can > now assume substring's length is at least 2. > > Here's the webrev with the implementation of this idea: > http://cr.openjdk.java.net/~igerasim/indexof/0/webrev/ > > > I've done some benchmarking with JMH and found no performance > degradation on my machine. > Of course, more testcases should be created and they should be > tried on different machines to be treated as reliable. > > Benchmark Mode Thr Cnt Sec > Mean Mean error Units > o.b.IndexOfBench.benchIndexOf_1_A avgt 1 20 5 > 704.739 9.104 nsec/op > o.b.IndexOfBench.benchIndexOf_1_B avgt 1 20 5 > *573.879*9.820 nsec/op > o.b.IndexOfBench.benchIndexOf_2_A avgt 1 20 5 > 668.455 9.882 nsec/op > o.b.IndexOfBench.benchIndexOf_2_B avgt 1 20 5 > *476.062*6.063 nsec/op > o.b.IndexOfBench.benchIndexOf_3_A avgt 1 20 5 > 155.227 1.796 nsec/op > o.b.IndexOfBench.benchIndexOf_3_B avgt 1 20 5 *152.850 > *1.512 nsec/op > o.b.IndexOfBench.benchIndexOf_4_A avgt 1 20 5 > 656.183 5.904 nsec/op > o.b.IndexOfBench.benchIndexOf_4_B avgt 1 20 5 > *515.178*9.107 nsec/op > o.b.IndexOfBench.benchIndexOf_5_A avgt 1 20 5 > 140.609 7.305 nsec/op > o.b.IndexOfBench.benchIndexOf_5_B avgt 1 20 5 > *129.603*1.654 nsec/op > o.b.IndexOfBench.benchIndexOf_6_A avgt 1 20 5 > 127.713 1.497 nsec/op > o.b.IndexOfBench.benchIndexOf_6_B avgt 1 20 5 > *122.177*1.186 nsec/op > o.b.IndexOfBench.benchIndexOf_7_A avgt 1 20 5 > 430.148 4.875 nsec/op > o.b.IndexOfBench.benchIndexOf_7_B avgt 1 20 5 > *387.338*10.904 nsec/op > o.b.IndexOfBench.benchIndexOf_8_A avgt 1 20 5 > 2064.563 28.885 nsec/op > o.b.IndexOfBench.benchIndexOf_8_B avgt 1 20 5 > *1858.669*24.343 nsec/op > > Benchmarks ending with A use the current indexOf implementation, > with B use the modified version. > These numbers show from 1.4% up to 28% performance increase. > > The full listing is below. > > Suggestions about what else to test are welcome! > > Sincerely yours, > Ivan > > --------------------- > > /** > * Copyright (c) 2014, 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 > * under the terms of the GNU General Public License version 2 > only, as > * published by the Free Software Foundation. Oracle designates this > * particular file as subject to the "Classpath" exception as provided > * by Oracle in the LICENSE file that accompanied this code. > * > * This code is distributed in the hope that it will be useful, > but WITHOUT > * ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or > * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > License > * version 2 for more details (a copy is included in the LICENSE > file that > * accompanied this code). > * > * You should have received a copy of the GNU General Public > License version > * 2 along with this work; if not, write to the Free Software > Foundation, > * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > * > * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > * or visit www.oracle.com if you need > additional information or have any > * questions. > */ > package org.benches; > > import org.openjdk.jmh.annotations.*; > import org.openjdk.jmh.logic.BlackHole; > import java.util.concurrent.TimeUnit; > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @State(Scope.Benchmark) > public class IndexOfBench { > > // ||| > final static char[] source1 = > "abababcabcacabcabcabcabcaccbcabcacbcabcacbcbcabcbcbacbcabcbabacbcbacbcabcabcabcabcabcabcabcacbacbacbacabcabcacbacbcabcbcbcaabdacbacabcabacbacabca".toCharArray(); > final static char[] source2 = > "acfacafacfacfacfacafcafcacadcacdacaccacacdacacfcafcafcfacdacadcadcadcdacfacfacdacadcacdcfacfacdacdacdcfacdacdacdacgshgshasdabdahghjgwdshacavcavsc".toCharArray(); > final static char[] source3 = > "tyrtytfytytuytfytuytggfghgdytyftytfdytdshfgjhdfytsfuythgsfhgjhfghtuysdfthgfsdhgystfjhgsfguysthgfgjhgdfjhgsjdghfythgsdfjhggfabduikjhfjhkjhfkjhgkjh".toCharArray(); > final static char[] target1 = "abd".toCharArray(); > > final static char[] source4 = > "ahhhahahahahhahahahahhahahahhhahahahahahahahahahahhahahahahahahahahallallalalalalalkakakakakakakakakkakmamamamabammamamamamamaakaklalalaoalalalao".toCharArray(); > final static char[] source5 = > "hgjkhjhjkdghkjhdfkjhgkjhdkjdhgkjdfhgkjdhfgkjdfhgkjhdfkjghkdjghkdjfhgkjhkdjhgkjdfhjkghkdjfhgkjdfhgkjdfhgkjdfhkgabhfkjghdkfjhgkjdfhgkjdfhgkjdfhgkhh".toCharArray(); > final static char[] target2 = "ab".toCharArray(); > > final static char[] source6 = > "lskgjsklfjgskldfjgklsfjdlgkjsdflkgjskldfgjsdklfgjsl;kdfgjskldfjglksdfjglksfjglksdfjgklsfdjgslkdfjglksjdflkgsjfalksjdflkfgjsdklfjglskdfjglksdfjghh".toCharArray(); > final static char[] target3 = "a".toCharArray(); > > final static char[] source7 = > "lskgajabfagskldfjgklsabclgkjsdflkabsabcdgjsdklfabclbkdfgjskabfjglksdfjabcdfjglabcfjgklsfabgslkdfjglksjdabcdsjfabcdedflabcjsdklfjglskdfabcksdfjghh".toCharArray(); > final static char[] target4 = "abcde".toCharArray(); > > final static char[] source8 = > "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa".toCharArray(); > final static char[] target5 = "aaaab".toCharArray(); > > @GenerateMicroBenchmark > public void benchIndexOf_1_A(BlackHole bh) { > bh.consume(indexOfA(source1, 0, source1.length, target1, > 0, target1.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_1_B(BlackHole bh) { > bh.consume(indexOfB(source1, 0, source1.length, target1, > 0, target1.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_2_A(BlackHole bh) { > bh.consume(indexOfA(source2, 0, source2.length, target1, > 0, target1.length, 0)); > } > > @GenerateMicroBenchmark > public void benchIndexOf_2_B(BlackHole bh) { > bh.consume(indexOfB(source2, 0, source2.length, target1, > 0, target1.length, 0)); > } > > @GenerateMicroBenchm > From ivan.gerasimov at oracle.com Fri Apr 18 11:21:26 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 18 Apr 2014 15:21:26 +0400 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <534CCD3E.2080500@oracle.com> References: <534BE0F6.6070409@oracle.com> <534C0A52.7040707@oracle.com> <534C2855.6020908@oracle.com> <534C980B.2000408@oracle.com> <534CCD3E.2080500@oracle.com> Message-ID: <53510AB6.6090509@oracle.com> Hi Mandy! May I consider this fix approved? Sincerely yours, Ivan On 15.04.2014 10:10, Ivan Gerasimov wrote: > > On 15.04.2014 6:23, Mandy Chung wrote: >> On 4/14/2014 11:26 AM, Ivan Gerasimov wrote: >>> Actually, zero tolerance should be sufficient now even for Windows >>> platform. >>> Measuring the time with nanoTime() should make the inner and outer >>> time intervals consistent. >>> >>> I've added the tolerance just to play safer. >>> I can remove it. >> >> That'd be even better! >> > Alright, I removed the tolerance back. > So now the only change is how the time interval is measured: > > http://cr.openjdk.java.net/~igerasim/8038982/1/webrev/ > > Sincerely yours, > Ivan > >> thanks >> Mandy >> >> > > > From roger.riggs at oracle.com Fri Apr 18 13:29:04 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 18 Apr 2014 09:29:04 -0400 Subject: ProcessReaper: single thread reaper In-Reply-To: <5350537F.3030408@redhat.com> References: <532C7A30.6060904@oracle.com> <53332582.50102@gmail.com> <53358A3B.4070603@gmail.com> <5336F752.1050707@oracle.com> <53419610.90905@gmail.com> <5341A600.2080408@gmail.com> <5342FB54.3070707@oracle.com> <5343A8B6.8030303@gmail.com> <5344E3C8.5080501@gmail.com> <53480193.7050803@gmail.com> <534BF296.6060002@oracle.com> <534C14A6.7030805@redhat.com> <534C4BAC.7050802@gmail.com> <534F055E.8070006@redhat.com> <534FE8A8.1060308@gmail.com> <534FF005.10007@redhat.com> <53503269.9050204@gmail.com> <5350537F.3030408@redhat.com> Message-ID: <535128A0.2040100@oracle.com> Hi David, Thanks for collecting the threads... I've been a bit occupied with another task. On 04/17/2014 02:58 PM, Peter Levart wrote: > ... I guess I am indeed going in circles at this point. I wonder > though if you'll indulge me a bit longer, and verify my collected > understanding of the requirements of what is being requested here: > > 1) The process API must reap all child processes it produces that > terminate during the lifetime of the JVM, leaving no zombies > (including processes which have changed process group and/or session) > 2) The process API must allow for child processes which are not > managed by it (by not attempting to reap them except as allowed by #3) > 3) The process API must somehow be able to "adopt" other child > processes produced by means other than the Process API > 4) The process reaper should keep resource consumption to a minimum > (preferably no more than one thread, preferably no more than one extra > FD per process) > 5) The process API must provide an explicitly graceful terminate > method in addition to the existing forcible and "unspecified" destroy > methods > 6) The process API must provide safeguards to prevent the wrong > process from being signaled (i.e. would be required to synchronize > process reaping with termination/signaling (PID reuse probabilities > notwithstanding)) > > I've deliberately left off any mention of direct management of > grandchild processes. I believe it was pretty well established by > Peter Levart that a child is solely the responsibility of its parent. > Martin Buchholz has doubts about it as well. I think Roger Riggs had > some unaddressed disagreement though. For what it's worth, I agree > with Peter on this point, because I think managing grand+children > makes #6 difficult or impossible to satisfy. But the topic, AFAIK, > remains open. Correct, in the cleanup case, we have seen zombies left around and will need to investigate the cases. If the child process does not clean up after itself, someone still does. > > Also I haven't brought up anything from JEP 102 that I haven't already > seen on this thread. > > These requirements seem to exclude some techniques brought up on the > thread previously: > > - waitid(P_ALL,...)/waitpid(-1,...) (which violates #2, either > directly, or by simply failing in the WNOWAIT|WNOHANG + unmanaged > child process case previously outlined by Peter Levart). > - setpgid() to an all-child process group + waitid(P_PID,...) (which > allows badly behaved processes to cause us to violate #1, and also > prevents automatic propagation of e.g. SIGTERM/SIGINT) > - setpgid() to a per-child process group (same problems, also no > workable reaping solution was found that I saw) > - SIGCHLD + siginfo (very unlikely to work consistently or correctly) > - anything relying on WNOWAIT on Mac OS X and maybe others > > I think everyone liked the idea of pluggable implementations. > > I didn't see this mentioned on this thread, but it seems to me that we > can have a simple 100% correct implementation on UNIX-likes by > retaining a single thread per child process (today each one has a 32k > stack, maybe it could be even smaller?). Much like the default > polling SelectorProvider for NIO, this could act as a simple fallback > implementation that will always work and be correct. Yes, seem clear for 100% backward compatibility this is needed (and probably the default at least to start) > > On proc-enabled systems, using poll or similar on the corresponding > proc files seems like a possible alternative implementation requiring > one additional FD per child process and only one reaper thread, since > it seems possible to meet all 6 above requirements, though lack of > standardization might add risk. > > Using a single thread to iterate all child PIDs each time a SIGCHLD is > received (with WNOHANG) would work without consuming more than one > thread and zero FDs total, however it scales poorly with very large > numbers of child processes, and it might be considered a violation of > #2 to use SIGCHLD anyway. Maybe these ideas could be implemented as > an alternative, contingent on -Xrs, or contingent on the previous > handler being SIG_IGN similarly to the suggestion by Martin Buchholz. > > I didn't see any other workable implementation alternatives. > > As for API, I had suggested that "adopted" processes have a strict > subset of functions compared to "managed" processes, and thus could be > a supertype of Process. Martin indicated that managing grandchildren > should have a different API altogether. Peter seems to lean towards > exposing the OS capabilities a bit more directly, through child > process ID enumeration (presumably including managed and unmanaged > processes in the same bucket) and an API which operates on any child > process by ID, regardless of its disposition (though I don't know of > any portable API to enumerate child processes; on Linux I believe you > have to use /proc). Peter also suggested that a process reaper be a > primary internal API construct. I have been working on the premise of a separate API will fewer functions. The primary function that is difficult and may need to be omitted is getting the exit status of an unmanaged subprocess. I suspect the API may be limited to knowing if the process is alive and being able to terminate it. There may need to be a configuration, primarily related to the reaper that does manage every child. I have prototyped an implementation that works across the 4/5 main OSs for iterating over processes. Thanks for the good summary. Roger > > Did I miss anything? From alexander.v.stepanov at oracle.com Fri Apr 18 14:04:46 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Fri, 18 Apr 2014 18:04:46 +0400 Subject: [9] Review request for 8029451: Tidy warnings cleanup for java.util package; minor changes in java.nio, java.sql Message-ID: <535130FE.6010305@oracle.com> Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8029451 Webrev corresponding: http://cr.openjdk.java.net/~yan/JDK-8029451/webrev.00/ Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. Thanks. Regards, Alexander From mandy.chung at oracle.com Fri Apr 18 14:38:06 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Apr 2014 07:38:06 -0700 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <53510AB6.6090509@oracle.com> References: <534BE0F6.6070409@oracle.com> <534C0A52.7040707@oracle.com> <534C2855.6020908@oracle.com> <534C980B.2000408@oracle.com> <534CCD3E.2080500@oracle.com> <53510AB6.6090509@oracle.com> Message-ID: <535138CE.6070901@oracle.com> Thumbs up Mandy On 4/18/2014 4:21 AM, Ivan Gerasimov wrote: > Hi Mandy! > > May I consider this fix approved? > > Sincerely yours, > Ivan > > On 15.04.2014 10:10, Ivan Gerasimov wrote: >> >> On 15.04.2014 6:23, Mandy Chung wrote: >>> On 4/14/2014 11:26 AM, Ivan Gerasimov wrote: >>>> Actually, zero tolerance should be sufficient now even for Windows >>>> platform. >>>> Measuring the time with nanoTime() should make the inner and outer >>>> time intervals consistent. >>>> >>>> I've added the tolerance just to play safer. >>>> I can remove it. >>> >>> That'd be even better! >>> >> Alright, I removed the tolerance back. >> So now the only change is how the time interval is measured: >> >> http://cr.openjdk.java.net/~igerasim/8038982/1/webrev/ >> >> Sincerely yours, >> Ivan >> >>> thanks >>> Mandy >>> >>> >> >> >> > From ivan.gerasimov at oracle.com Fri Apr 18 14:43:12 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 18 Apr 2014 18:43:12 +0400 Subject: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again In-Reply-To: <535138CE.6070901@oracle.com> References: <534BE0F6.6070409@oracle.com> <534C0A52.7040707@oracle.com> <534C2855.6020908@oracle.com> <534C980B.2000408@oracle.com> <534CCD3E.2080500@oracle.com> <53510AB6.6090509@oracle.com> <535138CE.6070901@oracle.com> Message-ID: <53513A00.6020101@oracle.com> On 18.04.2014 18:38, Mandy Chung wrote: > Thumbs up > Mandy > Thanks! > On 4/18/2014 4:21 AM, Ivan Gerasimov wrote: >> Hi Mandy! >> >> May I consider this fix approved? >> >> Sincerely yours, >> Ivan >> >> On 15.04.2014 10:10, Ivan Gerasimov wrote: >>> >>> On 15.04.2014 6:23, Mandy Chung wrote: >>>> On 4/14/2014 11:26 AM, Ivan Gerasimov wrote: >>>>> Actually, zero tolerance should be sufficient now even for Windows >>>>> platform. >>>>> Measuring the time with nanoTime() should make the inner and outer >>>>> time intervals consistent. >>>>> >>>>> I've added the tolerance just to play safer. >>>>> I can remove it. >>>> >>>> That'd be even better! >>>> >>> Alright, I removed the tolerance back. >>> So now the only change is how the time interval is measured: >>> >>> http://cr.openjdk.java.net/~igerasim/8038982/1/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >>>> thanks >>>> Mandy >>>> >>>> >>> >>> >>> >> > > > From martinrb at google.com Fri Apr 18 16:43:24 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Apr 2014 09:43:24 -0700 Subject: String.indexOf optimization In-Reply-To: <5350E316.2050406@oracle.com> References: <534D68B8.3040002@oracle.com> <5350E316.2050406@oracle.com> Message-ID: I remain skeptical that modifying the implementation of static package private String.indexOf is the right approach. If we can produce high-performance implementations of these, perhaps making them public in Arrays.java is the right way. 1766 if (targetCount == 1) {1767 return (i <= max) ? i - sourceOffset : -1; If you're going to special case targetCount == 1, you shouldn't have a test for it in the main loop, since you slow down the general case. Instead, you can sequester the special cases like this: if (targetCount <= 1) { if (targetCount == 0) ... else ... } // now assume targetCount >= 2 On Fri, Apr 18, 2014 at 1:32 AM, Ivan Gerasimov wrote: > > On 16.04.2014 2:53, Martin Buchholz wrote: > > Hi Ivan, > > There's already an indexOf(int, int) that allows a user to explicitly > search for a char (or character). > > Sure. > What I meant was not to introduce a special function for searching a > single character, but to restrict the general case loop to search for a > substring of at least 2 characters. > Having this condition hold, we can enter the loop only when two starting > characters match, and this can save us a few nanoseconds in many cases. > > > Hotspot seems to have some intrinsification of String.indexOf, which > confuses me. > > > Does it mean that that the java implementation of indexOf is never > compiled? > When hotspot replaces the jdk implementation with its own one? > Is it ever worth to try to optimize the java implementation? > > > Hotspot seems the right place to provide more optimizations for this, > since there has been a fair amount of work creating high-performance > low-level implementations of this idea in C. > > The hotspot's intrinsic is already optimized for searching substrings of > different length. > > Sincerely yours, > Ivan > > > > On Tue, Apr 15, 2014 at 10:13 AM, Ivan Gerasimov < > ivan.gerasimov at oracle.com> wrote: > >> Hi everyone! >> >> >> On 04.04.2014 21:13, Martin Buchholz wrote: >> >> Summary: >> >> Many people (myself included) have looked at this problem. It's unlikely >> that String.indexOf will change. It's hard to beat the naive >> implementation in the typical case. >> >> But we can try to speed up this naive implementation a little bit. >> >> We can separate the special case: When the substring's length == 1. >> This special case can be done fast, and in the general case we can now >> assume substring's length is at least 2. >> >> Here's the webrev with the implementation of this idea: >> http://cr.openjdk.java.net/~igerasim/indexof/0/webrev/ >> >> I've done some benchmarking with JMH and found no performance degradation >> on my machine. >> Of course, more testcases should be created and they should be tried on >> different machines to be treated as reliable. >> >> Benchmark Mode Thr Cnt Sec Mean >> Mean error Units >> o.b.IndexOfBench.benchIndexOf_1_A avgt 1 20 5 >> 704.739 9.104 nsec/op >> o.b.IndexOfBench.benchIndexOf_1_B avgt 1 20 5 * >> 573.879* 9.820 nsec/op >> o.b.IndexOfBench.benchIndexOf_2_A avgt 1 20 5 >> 668.455 9.882 nsec/op >> o.b.IndexOfBench.benchIndexOf_2_B avgt 1 20 5 >> *476.062* 6.063 nsec/op >> o.b.IndexOfBench.benchIndexOf_3_A avgt 1 20 5 >> 155.227 1.796 nsec/op >> o.b.IndexOfBench.benchIndexOf_3_B avgt 1 20 5 * >> 152.850 * 1.512 nsec/op >> o.b.IndexOfBench.benchIndexOf_4_A avgt 1 20 5 >> 656.183 5.904 nsec/op >> o.b.IndexOfBench.benchIndexOf_4_B avgt 1 20 5 >> *515.178* 9.107 nsec/op >> o.b.IndexOfBench.benchIndexOf_5_A avgt 1 20 5 >> 140.609 7.305 nsec/op >> o.b.IndexOfBench.benchIndexOf_5_B avgt 1 20 5 >> *129.603* 1.654 nsec/op >> o.b.IndexOfBench.benchIndexOf_6_A avgt 1 20 5 >> 127.713 1.497 nsec/op >> o.b.IndexOfBench.benchIndexOf_6_B avgt 1 20 5 >> *122.177* 1.186 nsec/op >> o.b.IndexOfBench.benchIndexOf_7_A avgt 1 20 5 >> 430.148 4.875 nsec/op >> o.b.IndexOfBench.benchIndexOf_7_B avgt 1 20 5 * >> 387.338* 10.904 nsec/op >> o.b.IndexOfBench.benchIndexOf_8_A avgt 1 20 5 >> 2064.563 28.885 nsec/op >> o.b.IndexOfBench.benchIndexOf_8_B avgt 1 20 5 >> *1858.669* 24.343 nsec/op >> >> Benchmarks ending with A use the current indexOf implementation, with B >> use the modified version. >> These numbers show from 1.4% up to 28% performance increase. >> >> The full listing is below. >> >> Suggestions about what else to test are welcome! >> >> Sincerely yours, >> Ivan >> >> --------------------- >> >> /** >> * Copyright (c) 2014, 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 >> * under the terms of the GNU General Public License version 2 only, as >> * published by the Free Software Foundation. Oracle designates this >> * particular file as subject to the "Classpath" exception as provided >> * by Oracle in the LICENSE file that accompanied this code. >> * >> * This code is distributed in the hope that it will be useful, but >> WITHOUT >> * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> * version 2 for more details (a copy is included in the LICENSE file that >> * accompanied this code). >> * >> * You should have received a copy of the GNU General Public License >> version >> * 2 along with this work; if not, write to the Free Software Foundation, >> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> * >> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA >> * or visit www.oracle.com if you need additional information or have any >> * questions. >> */ >> package org.benches; >> >> import org.openjdk.jmh.annotations.*; >> import org.openjdk.jmh.logic.BlackHole; >> import java.util.concurrent.TimeUnit; >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @State(Scope.Benchmark) >> public class IndexOfBench { >> >> >> // >> ||| >> final static char[] source1 = >> "abababcabcacabcabcabcabcaccbcabcacbcabcacbcbcabcbcbacbcabcbabacbcbacbcabcabcabcabcabcabcabcacbacbacbacabcabcacbacbcabcbcbcaabdacbacabcabacbacabca".toCharArray(); >> final static char[] source2 = >> "acfacafacfacfacfacafcafcacadcacdacaccacacdacacfcafcafcfacdacadcadcadcdacfacfacdacadcacdcfacfacdacdacdcfacdacdacdacgshgshasdabdahghjgwdshacavcavsc".toCharArray(); >> final static char[] source3 = >> "tyrtytfytytuytfytuytggfghgdytyftytfdytdshfgjhdfytsfuythgsfhgjhfghtuysdfthgfsdhgystfjhgsfguysthgfgjhgdfjhgsjdghfythgsdfjhggfabduikjhfjhkjhfkjhgkjh".toCharArray(); >> final static char[] target1 = "abd".toCharArray(); >> >> final static char[] source4 = >> "ahhhahahahahhahahahahhahahahhhahahahahahahahahahahhahahahahahahahahallallalalalalalkakakakakakakakakkakmamamamabammamamamamamaakaklalalaoalalalao".toCharArray(); >> final static char[] source5 = >> "hgjkhjhjkdghkjhdfkjhgkjhdkjdhgkjdfhgkjdhfgkjdfhgkjhdfkjghkdjghkdjfhgkjhkdjhgkjdfhjkghkdjfhgkjdfhgkjdfhgkjdfhkgabhfkjghdkfjhgkjdfhgkjdfhgkjdfhgkhh".toCharArray(); >> final static char[] target2 = "ab".toCharArray(); >> >> final static char[] source6 = >> "lskgjsklfjgskldfjgklsfjdlgkjsdflkgjskldfgjsdklfgjsl;kdfgjskldfjglksdfjglksfjglksdfjgklsfdjgslkdfjglksjdflkgsjfalksjdflkfgjsdklfjglskdfjglksdfjghh".toCharArray(); >> final static char[] target3 = "a".toCharArray(); >> >> final static char[] source7 = >> "lskgajabfagskldfjgklsabclgkjsdflkabsabcdgjsdklfabclbkdfgjskabfjglksdfjabcdfjglabcfjgklsfabgslkdfjglksjdabcdsjfabcdedflabcjsdklfjglskdfabcksdfjghh".toCharArray(); >> final static char[] target4 = "abcde".toCharArray(); >> >> final static char[] source8 = >> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa".toCharArray(); >> final static char[] target5 = "aaaab".toCharArray(); >> >> @GenerateMicroBenchmark >> public void benchIndexOf_1_A(BlackHole bh) { >> bh.consume(indexOfA(source1, 0, source1.length, target1, 0, >> target1.length, 0)); >> } >> >> @GenerateMicroBenchmark >> public void benchIndexOf_1_B(BlackHole bh) { >> bh.consume(indexOfB(source1, 0, source1.length, target1, 0, >> target1.length, 0)); >> } >> >> @GenerateMicroBenchmark >> public void benchIndexOf_2_A(BlackHole bh) { >> bh.consume(indexOfA(source2, 0, source2.length, target1, 0, >> target1.length, 0)); >> } >> >> @GenerateMicroBenchmark >> public void benchIndexOf_2_B(BlackHole bh) { >> bh.consume(indexOfB(source2, 0, source2.length, target1, 0, >> target1.length, 0)); >> } >> >> @GenerateMicroBenchm >> > > From brian.burkhalter at oracle.com Fri Apr 18 17:23:52 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 18 Apr 2014 10:23:52 -0700 Subject: JDK 9 RFR of 8027595: Enable BigInteger overflow tests in JTREG In-Reply-To: <8542A13B-8A6C-443C-87E8-B60A1FE1357A@oracle.com> References: <8542A13B-8A6C-443C-87E8-B60A1FE1357A@oracle.com> Message-ID: <3B646B32-E8F2-4F3C-A393-2ADD65A78C90@oracle.com> On Apr 16, 2014, at 6:42 PM, Brian Burkhalter wrote: > Patch: http://cr.openjdk.java.net/~bpb/8027595/webrev.00/ I modified the patch to add @ignore to StringConstructorOverflow as the test will always just catch an OOME anyway without the large -Xmx setting. http://cr.openjdk.java.net/~bpb/8027595/webrev.01/ Thanks, Brian From lois.foltan at oracle.com Fri Apr 18 17:43:47 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 18 Apr 2014 13:43:47 -0400 Subject: RFR (XS) JDK-8033584: Remove java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java from exclude list Message-ID: <53516453.9080706@oracle.com> Please review the following change to remove a test from ProblemList.txt. Webrev: http://cr.openjdk.java.net/~lfoltan/bug_jdk8033584/ Bug: Remove java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java from exclude list https://bugs.openjdk.java.net/browse/JDK-8033584 Summary: The issue causing TestPrivateInterfaceMethodReflect.java to fail was fixed by the JVM Runtime team for JDK 8, for details see JDK-8029415 . Thank you, Lois From mandy.chung at oracle.com Fri Apr 18 17:49:50 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Apr 2014 10:49:50 -0700 Subject: RFR (XS) JDK-8033584: Remove java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java from exclude list In-Reply-To: <53516453.9080706@oracle.com> References: <53516453.9080706@oracle.com> Message-ID: <535165BE.9060102@oracle.com> On 4/18/2014 10:43 AM, Lois Foltan wrote: > > Please review the following change to remove a test from ProblemList.txt. > > Webrev: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8033584/ > > Bug: Remove > java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java > from exclude list > https://bugs.openjdk.java.net/browse/JDK-8033584 > Looks good. Mandy From roger.riggs at oracle.com Fri Apr 18 18:15:23 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 18 Apr 2014 14:15:23 -0400 Subject: RFR 9: 8038490: java.time Using IsoFields.WEEK_BASED_YEAR Message-ID: <53516BBB.3090306@oracle.com> Please review this correction to java.time week_based_year: 8038490 : Using IsoFields.WEEK_BASED_YEAR with ZonedDateTime throws ClassCastException Webrev: http://cr.openjdk.java.net/~rriggs/webrev-week-based-year-8038490/ Thanks, Roger From roger.riggs at oracle.com Fri Apr 18 18:36:05 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 18 Apr 2014 14:36:05 -0400 Subject: RFR 9: 8038823: Missing @Test annotation and copyright in java.time tests Message-ID: <53517095.6000509@oracle.com> Please review for 9: 8038823 : Missing @Test annotation and copyright in java.time tests Webrev: http://cr.openjdk.java.net/~rriggs/webrev-test-annotation-8038823/ Thanks, Roger From lance.andersen at oracle.com Fri Apr 18 19:18:23 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 18 Apr 2014 15:18:23 -0400 Subject: RFR 9: 8038823: Missing @Test annotation and copyright in java.time tests In-Reply-To: <53517095.6000509@oracle.com> References: <53517095.6000509@oracle.com> Message-ID: Hi Roger, Looks Ok. I assume the copyrights that were set to 2013 are meant to be 2013 vs 2014. Best Lance On Apr 18, 2014, at 2:36 PM, roger riggs wrote: > Please review for 9: > > 8038823 : Missing @Test annotation and copyright in java.time tests > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-test-annotation-8038823/ > > Thanks, Roger > 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 roger.riggs at oracle.com Fri Apr 18 19:23:31 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 18 Apr 2014 15:23:31 -0400 Subject: RFR 9: 8038823: Missing @Test annotation and copyright in java.time tests In-Reply-To: References: <53517095.6000509@oracle.com> Message-ID: <53517BB3.8040103@oracle.com> Hi Lance, Yes, the files affected were last changed in 2013, so that seems to be the right year for the copyright. Thanks, Roger On 4/18/2014 3:18 PM, Lance Andersen wrote: > Hi Roger, > > Looks Ok. I assume the copyrights that were set to 2013 are meant to > be 2013 vs 2014. > > Best > Lance > On Apr 18, 2014, at 2:36 PM, roger riggs > wrote: > >> Please review for 9: >> >> 8038823 : Missing >> @Test annotation and copyright in java.time tests >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-test-annotation-8038823/ >> >> >> Thanks, Roger >> > > > > 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 lance.andersen at oracle.com Fri Apr 18 19:24:49 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 18 Apr 2014 15:24:49 -0400 Subject: RFR 9: 8038490: java.time Using IsoFields.WEEK_BASED_YEAR In-Reply-To: <53516BBB.3090306@oracle.com> References: <53516BBB.3090306@oracle.com> Message-ID: Hi Roger +1 Best Lance On Apr 18, 2014, at 2:15 PM, roger riggs wrote: > Please review this correction to java.time week_based_year: > > 8038490 : Using IsoFields.WEEK_BASED_YEAR with ZonedDateTime throws ClassCastException > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-week-based-year-8038490/ > > Thanks, Roger > 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 lance.andersen at oracle.com Fri Apr 18 19:47:34 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 18 Apr 2014 15:47:34 -0400 Subject: [9] Review request for 8029451: Tidy warnings cleanup for java.util package; minor changes in java.nio, java.sql In-Reply-To: <535130FE.6010305@oracle.com> References: <535130FE.6010305@oracle.com> Message-ID: <240EEB54-E77B-42E8-AFBC-910DE4CE0CC7@oracle.com> looks fine On Apr 18, 2014, at 10:04 AM, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8029451 > > Webrev corresponding: > http://cr.openjdk.java.net/~yan/JDK-8029451/webrev.00/ > > Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. > > Thanks. > > Regards, > Alexander 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 lance.andersen at oracle.com Fri Apr 18 20:12:57 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 18 Apr 2014 16:12:57 -0400 Subject: RFR 8040760: Addition of new java.sql tests In-Reply-To: <534FDACA.8050105@Oracle.com> References: <534FDACA.8050105@Oracle.com> Message-ID: Hi Roger, Thanks for the suggestions On Apr 17, 2014, at 9:44 AM, Roger Riggs wrote: > Hi Lance, > > - The empty method for @BeforeClass, @AfterClass, @BeforeMethod, @AfterMethod > could be deleted (and related imports) > - Ditto the empty public constructors Agree. They are generated automagically via netbeans and I figured seeing they cause no harm, I will leave them as is as I might end up using some of them later with additional tests > - The javadoc first sentences should end with a "." (Though we rarely generate javadoc for tests). Agree, I will look at a future date to go through all of the tests to update date these. I just tried to add some comments to give an idea as to what the tests do > - Binary files (BatchUpdateException_JDBC42.ser) are rarely a good idea. > Typically the bytes are dumped to a source byte array and embedded in the test. There is only 1 test which required a checked in Serialized file. Per your suggestion, I created a byte array instead > - Some tests (like BatchUpdateException) would be easier to read if there was method for 'equals(ex1, ex2)'. I can look at this at some point in the future to see if there might be some additional value. Each Constructor had different defaults for various parameters so not sure it is worth more time now but made note of it. Have a lot of other tests to go through and port > - Only BatchUpdateException has a serialization test for compatibility with previous versions. Correct and the reason for that is in Java SE 8, another field was added to BatchUpdateException and I wanted to make sure that we were backwards compatible. The other exceptions did not change and there was no existing test. I can add this as a todo for the future, but it was not as important at this time given I was converting my own existing unit tests > (the round trip write/read tests only test the current version). > - StubDriverDA logs an error to the Logger instead of causing a test failure - is that correct? This is harmless as the stub will new throw the Exception that DriverManager requires (nor will DriverManager), so I just left the code that Netbeans generated > > - BatchUpdateExceptionTests + 320 check indentation fixed > - DriverManagerTests + 291 "to to" -> "to" fixed > - StubConnection +44 add a space before "{" fixed Revised webrev at http://cr.openjdk.java.net/~lancea/8040760/webrev.01/ Best Lance > > Roger > > > On 04/16/2014 05:41 PM, Lance Andersen wrote: >> Hi, >> >> Looking for a reviewer for some new java.sql tests. >> >> The webrev can be found at http://cr.openjdk.java.net/~lancea/8040760/webrev.00/ >> >> 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 >> >> >> > 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 roger.riggs at oracle.com Fri Apr 18 20:27:43 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 18 Apr 2014 16:27:43 -0400 Subject: RFR 9: 8040058: IsoFields.WEEK_BASED_YEAR adjustInto incorrect Message-ID: <53518ABF.50003@oracle.com> This review is for patches provided by Steve Colebourne to address 8040058 : IsoFields.WEEK_BASED_YEAR adjustInto incorrect and the related issue with WeekFields.weekOfWeekBasedYear().range being incorrect Webrev: http://cr.openjdk.java.net/~rriggs/webrev-FixIsoFieldsWeekBasedYear-8040058/ I've reviewed it and the change looks correct. Roger From roger.riggs at oracle.com Fri Apr 18 20:36:36 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 18 Apr 2014 16:36:36 -0400 Subject: RFR 8040760: Addition of new java.sql tests In-Reply-To: References: <534FDACA.8050105@Oracle.com> Message-ID: <53518CD4.5070308@oracle.com> Hi Lance, Looks fine. Thanks, Roger On 4/18/2014 4:12 PM, Lance Andersen wrote: > Hi Roger, > > Thanks for the suggestions > On Apr 17, 2014, at 9:44 AM, Roger Riggs > wrote: > >> Hi Lance, >> >> - The empty method for @BeforeClass, @AfterClass, @BeforeMethod, >> @AfterMethod >> could be deleted (and related imports) >> - Ditto the empty public constructors > > Agree. They are generated automagically via netbeans and I figured > seeing they cause no harm, I will leave them as is as I might end up > using some of them later with additional tests fyi, There is are checkbox(es) in the Netbeans test generation dialog for which methods to generate. > >> - The javadoc first sentences should end with a "." (Though we >> rarely generate javadoc for tests). > > Agree, I will look at a future date to go through all of the tests to > update date these. I just tried to add some comments to give an idea > as to what the tests do >> - Binary files (BatchUpdateException_JDBC42.ser) are rarely a good idea. >> Typically the bytes are dumped to a source byte array and embedded >> in the test. > > There is only 1 test which required a checked in Serialized file. > Per your suggestion, I created a byte array instead Looks good. >> - Some tests (like BatchUpdateException) would be easier to read if >> there was method for 'equals(ex1, ex2)'. > > I can look at this at some point in the future to see if there might > be some additional value. Each Constructor had different defaults for > various parameters so not sure it is worth more time now but made note > of it. Have a lot of other tests to go through > and port >> - Only BatchUpdateException has a serialization test for >> compatibility with previous versions. > > Correct and the reason for that is in Java SE 8, another field was > added to BatchUpdateException and I wanted to make sure that we were > backwards compatible. > > The other exceptions did not change and there was no existing test. I > can add this as a todo for the future, but it was not as important at > this time given I was converting my own existing unit tests > >> (the round trip write/read tests only test the current version). >> - StubDriverDA logs an error to the Logger instead of causing a test >> failure - is that correct? > This is harmless as the stub will new throw the Exception that > DriverManager requires (nor will DriverManager), so I just left the > code that Netbeans generated >> >> - BatchUpdateExceptionTests + 320 check indentation > fixed >> - DriverManagerTests + 291 "to to" -> "to" > fixed >> - StubConnection +44 add a space before "{" > fixed > > Revised webrev at > http://cr.openjdk.java.net/~lancea/8040760/webrev.01/ > > > Best > Lance >> >> Roger >> >> >> On 04/16/2014 05:41 PM, Lance Andersen wrote: >>> Hi, >>> >>> Looking for a reviewer for some new java.sql tests. >>> >>> The webrev can be found at >>> http://cr.openjdk.java.net/~lancea/8040760/webrev.00/ >>> >>> >>> 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 >>> >>> >>> >> > > > > 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 lance.andersen at oracle.com Fri Apr 18 20:41:52 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 18 Apr 2014 16:41:52 -0400 Subject: RFR 9: 8040058: IsoFields.WEEK_BASED_YEAR adjustInto incorrect In-Reply-To: <53518ABF.50003@oracle.com> References: <53518ABF.50003@oracle.com> Message-ID: +1 On Apr 18, 2014, at 4:27 PM, roger riggs wrote: > This review is for patches provided by Steve Colebourne to address > > 8040058 : IsoFields.WEEK_BASED_YEAR adjustInto incorrect and the related issue with > WeekFields.weekOfWeekBasedYear().range being incorrect > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-FixIsoFieldsWeekBasedYear-8040058/ > > I've reviewed it and the change looks correct. > > Roger > 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 mike.duigou at oracle.com Fri Apr 18 20:53:06 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 18 Apr 2014 13:53:06 -0700 Subject: JDK 9 RFR of 8027595: Enable BigInteger overflow tests in JTREG In-Reply-To: <3B646B32-E8F2-4F3C-A393-2ADD65A78C90@oracle.com> References: <8542A13B-8A6C-443C-87E8-B60A1FE1357A@oracle.com> <3B646B32-E8F2-4F3C-A393-2ADD65A78C90@oracle.com> Message-ID: Seems reasonable. Though it's sad to not be able to turn the tests on when they could be run. I have heard that jtreg will be sprouting a new capability which would allow this. Mike On Apr 18 2014, at 10:23 , Brian Burkhalter wrote: > > On Apr 16, 2014, at 6:42 PM, Brian Burkhalter wrote: > >> Patch: http://cr.openjdk.java.net/~bpb/8027595/webrev.00/ > > > I modified the patch to add @ignore to StringConstructorOverflow as the test will always just catch an OOME anyway without the large -Xmx setting. > > http://cr.openjdk.java.net/~bpb/8027595/webrev.01/ > > Thanks, > > Brian From richard.warburton at gmail.com Sat Apr 19 08:09:09 2014 From: richard.warburton at gmail.com (Richard Warburton) Date: Sat, 19 Apr 2014 10:09:09 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <5350142D.8040706@oracle.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> Message-ID: Hi, The only issue that I'm aware of that is related to this kind of change is >>> the requirement to recompile all the classes in the hierarchy when >>> making a >>> change [0]. If you don't do this its possible for an infinite recursion >>> and >>> eventual stackoverflow to occur. Now as far as I can tell the >>> entire hierarchy of Buffer classes are all either package scoped classes, >>> or they are public classes with package scoped constructors. So I'm not >>> aware of a way to sub class them without the code being part of the JDK. >>> This would mean that the subclasses all need to be recompiled, satisfying >>> the safety criteria. >>> >>> This is a long standing bug to look at this issue [1]. >> CharBuffer.subSequence >> was one case that was retrofitted in 7. As you note, buffers are not >> designed to >> be extended outside of the java.nio package so this should make a number >> of >> options possible. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-4774077 >> > > Hi Richard, > > It looks to me like there are no obvious problems with changing the buffer > subclasses to use covariant overrides. As Alan mentioned, one API was > modified this way in 7, by Martin Buchholz. The discussion threads for this > change are [2] and [3]. It looks like Martin considered additional > covariant overrides, but ultimately backed off from this for a variety of > incidental reasons; see [4]. There is a certain amount of work here above > and beyond just changing the return types, but there don't appear to be any > fundamental issues. > Thanks for the feedback guys - its most appreciated and I'll take a look through the detailed linked you provided. Ulf posted several links, but these seem mostly related to language change > proposals related to implicit method invocation chaining. I don't think > these proposals are active at the moment, so I'd suggest that you pursue a > library-only change. I had no intention in my original email to broaden the scope of this change to include changing the type system itself! I was only really thinking about a library level change, though I appreciate the links Ulf, thanks. regards, Richard Warburton http://insightfullogic.com @RichardWarburto From Ulf.Zibis at CoSoCo.de Sat Apr 19 16:00:14 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 19 Apr 2014 18:00:14 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> Message-ID: <53529D8E.6020606@CoSoCo.de> Am 19.04.2014 10:09, schrieb Richard Warburton: > Thanks for the feedback guys - its most appreciated and I'll take a look > through the detailed linked you provided. > > Ulf posted several links, but these seem mostly related to language change Not all of them, but yes, mostly. >> proposals related to implicit method invocation chaining. I don't think >> these proposals are active at the moment, so I'd suggest that you pursue a >> library-only change. > > I had no intention in my original email to broaden the scope of this change > to include changing the type system itself! I was only really thinking > about a library level change, though I appreciate the links Ulf, thanks. My proposed language change would ... - include the benefit of covariant overrides - solve situations, where covariant overrides don't help - need less byte code - have less backport issues - avoid massive API reengineering - cover methods which don't return this today - offer interesting extensions e.g. "leading dot" syntax Thanks for reading my proposal. -Ulf From richard.warburton at gmail.com Sun Apr 20 18:56:52 2014 From: richard.warburton at gmail.com (Richard Warburton) Date: Sun, 20 Apr 2014 20:56:52 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <5350142D.8040706@oracle.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> Message-ID: Hi, It looks to me like there are no obvious problems with changing the buffer > subclasses to use covariant overrides. As Alan mentioned, one API was > modified this way in 7, by Martin Buchholz. The discussion threads for this > change are [2] and [3]. It looks like Martin considered additional > covariant overrides, but ultimately backed off from this for a variety of > incidental reasons; see [4]. There is a certain amount of work here above > and beyond just changing the return types, but there don't appear to be any > fundamental issues. So I've put a patch on cr at http://cr.openjdk.java.net/~rwarburton/buffer-overrides-0/. It also touches a couple of other classes which have unnecessary casts in. Aside from being a good idea, fixing the casts is also necessary due to -Werror. Let me know if I've missed anything or if there are any outstanding issues. I think the bugs that this resolves are: https://bugs.openjdk.java.net/browse/JDK-4774077 https://bugs.openjdk.java.net/browse/JDK-6451131 regards, Richard Warburton http://insightfullogic.com @RichardWarburto From Ulf.Zibis at CoSoCo.de Sun Apr 20 21:44:24 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sun, 20 Apr 2014 23:44:24 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> Message-ID: <53543FB8.7040508@CoSoCo.de> Hi again, one additional reason on top of my list from yesterday why I would prefer the language change: - Removing "final" is a performance decrease. -Ulf Am 20.04.2014 20:56, schrieb Richard Warburton: > Hi, > > It looks to me like there are no obvious problems with changing the buffer >> subclasses to use covariant overrides. As Alan mentioned, one API was >> modified this way in 7, by Martin Buchholz. The discussion threads for this >> change are [2] and [3]. It looks like Martin considered additional >> covariant overrides, but ultimately backed off from this for a variety of >> incidental reasons; see [4]. There is a certain amount of work here above >> and beyond just changing the return types, but there don't appear to be any >> fundamental issues. > > So I've put a patch on cr at > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-0/. It also touches > a couple of other classes which have unnecessary casts in. Aside from being > a good idea, fixing the casts is also necessary due to -Werror. Let me > know if I've missed anything or if there are any outstanding issues. > > I think the bugs that this resolves are: > > https://bugs.openjdk.java.net/browse/JDK-4774077 > https://bugs.openjdk.java.net/browse/JDK-6451131 > > regards, > > Richard Warburton > > http://insightfullogic.com > @RichardWarburto > From alexander.v.stepanov at oracle.com Mon Apr 21 07:43:44 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Mon, 21 Apr 2014 11:43:44 +0400 Subject: [9] Review request for 8029451: Tidy warnings cleanup for java.util package; minor changes in java.nio, java.sql In-Reply-To: <240EEB54-E77B-42E8-AFBC-910DE4CE0CC7@oracle.com> References: <535130FE.6010305@oracle.com> <240EEB54-E77B-42E8-AFBC-910DE4CE0CC7@oracle.com> Message-ID: <5354CC30.6000401@oracle.com> thanks! On 18.04.2014 23:47, Lance Andersen wrote: > looks fine > On Apr 18, 2014, at 10:04 AM, alexander stepanov > > wrote: > >> Hello, >> >> Could you please review the fix for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8029451 >> >> Webrev corresponding: >> http://cr.openjdk.java.net/~yan/JDK-8029451/webrev.00/ >> >> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >> affected. >> >> Thanks. >> >> Regards, >> Alexander > > > > 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 peter.levart at gmail.com Mon Apr 21 11:10:23 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 21 Apr 2014 13:10:23 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> Message-ID: <5354FC9F.1020409@gmail.com> On 04/20/2014 08:56 PM, Richard Warburton wrote: > Hi, > > It looks to me like there are no obvious problems with changing the buffer >> subclasses to use covariant overrides. As Alan mentioned, one API was >> modified this way in 7, by Martin Buchholz. The discussion threads for this >> change are [2] and [3]. It looks like Martin considered additional >> covariant overrides, but ultimately backed off from this for a variety of >> incidental reasons; see [4]. There is a certain amount of work here above >> and beyond just changing the return types, but there don't appear to be any >> fundamental issues. > So I've put a patch on cr at > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-0/ Hi, Since the public part of Buffer type hierarchy is (mostly) just two-level, an alternative would be to generify java.nio.Buffer: public abstract class Buffer> { @SuppressWarnings("unchecked") protected final B self() { (B) return this; } public final B position(int newPosition) { ... return self(); } ... } public abstract class LongBuffer extends Buffer implements Comparable { ... } public abstract class ShortBuffer extends Buffer implements Comparable { ... } ... The question is what to do with ByteBuffer/MappedByteBuffer then. One alternative is to fix the type variable constraint at ByteBuffer level and leave MappedByteBuffer astray: public abstract class ByteBuffer extends Buffer implements Comparable { ... } public abstract class MappedByteBuffer extends ByteBuffer { ... } ...in this case Buffer/ByteBuffer methods invoked on MappedByteBuffer would have ByteBuffer return type. This would only matter if one wanted to call MappedByteBuffer's methods at the end of the chain - there are three of them: isLoaded()/load()/force(). The other alternative is to fix the type variable constraint at MappedByteBuffer level: public abstract class ByteBuffer extends Buffer> implements Comparable> { ... } public abstract class MappedByteBuffer extends ByteBuffer { ... } ...in this case, the following: ByteBuffer bb = ...; would be a raw type and consequently Buffer methods, when invoked on bb, would have Buffer return type (the erasure), but that's not a problem - it is source compatible. To achieve the desired effect one would have to use at least: ByteBuffer bb = ...; I'm suggesting this alternative, because Buffer methods can stay final in this case. This is more JIT-friendly. And, if I'm not mistaken, client code compiled using JDK8 onto which this API change was backported, would still run with JDK8 (or JDK7 when compiled with -target 1.7) onto which the API change was not back-ported. Regards, Peter > . It also touches > a couple of other classes which have unnecessary casts in. Aside from being > a good idea, fixing the casts is also necessary due to -Werror. Let me > know if I've missed anything or if there are any outstanding issues. > > I think the bugs that this resolves are: > > https://bugs.openjdk.java.net/browse/JDK-4774077 > https://bugs.openjdk.java.net/browse/JDK-6451131 > > regards, > > Richard Warburton > > http://insightfullogic.com > @RichardWarburto From Ulf.Zibis at CoSoCo.de Mon Apr 21 12:07:36 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 21 Apr 2014 14:07:36 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <5354FC9F.1020409@gmail.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> Message-ID: <53550A08.3090005@CoSoCo.de> Hi Peter, Am 21.04.2014 13:10, schrieb Peter Levart: > Since the public part of Buffer type hierarchy is (mostly) just two-level, an alternative would be > to generify java.nio.Buffer: Hey wow, some time ago I also tried to find a compiling and working code in that sense, but I stranded. But what for an effort, just to avoid retyping of same object in java code ??? So to me, this is clearly a language matter, not to solve by tricky footprint and/or performance lasting code on APIs: People want a _smart syntax_ for consecutive method invocations on the same object, that's all! -Ulf From otaviojava at java.net Mon Apr 21 13:06:46 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Mon, 21 Apr 2014 10:06:46 -0300 Subject: Conditions with that always returns true is 'if' necessary? Message-ID: Hello everyone, one question. Conditions that always returns true, is 'if' necessary? I found one. diff -r 57c1da89ae1a src/share/classes/java/lang/invoke/BoundMethodHandle.java --- a/src/share/classes/java/lang/invoke/BoundMethodHandle.java Wed Apr 16 12:32:36 2014 -0700 +++ b/src/share/classes/java/lang/invoke/BoundMethodHandle.java Mon Apr 21 09:50:29 2014 -0300 @@ -66,8 +66,7 @@ try { switch (xtype) { case 'L': - if (true) return bindSingle(type, form, x); // Use known fast path. - return (BoundMethodHandle) SpeciesData.EMPTY.extendWithType('L').constructor[0].invokeBasic(type, form, x); + return bindSingle(type, form, x); // Use known fast path. case 'I': return (BoundMethodHandle) SpeciesData.EMPTY.extendWithType('I').constructor[0].invokeBasic(type, form, ValueConversions.widenSubword(x)); case 'J': -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From lance.andersen at oracle.com Mon Apr 21 19:54:40 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 21 Apr 2014 15:54:40 -0400 Subject: Error: ~Documents/hg-workspaces/openjdk9/dev/jdk/test/TEST.groups: group jdk_other: file not found: demo/zipfs Message-ID: I am not seeing a demo/zipfs in my workspace. I assume that TEST.groups should be updated and if so I can take care of it? 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 chris.hegarty at oracle.com Mon Apr 21 20:24:54 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 Apr 2014 21:24:54 +0100 Subject: Error: ~Documents/hg-workspaces/openjdk9/dev/jdk/test/TEST.groups: group jdk_other: file not found: demo/zipfs In-Reply-To: References: Message-ID: <53557E96.8030701@oracle.com> On 04/21/2014 08:54 PM, Lance Andersen wrote: > > I am not seeing a demo/zipfs in my workspace. I assume that TEST.groups should be updated and if so I can take care of it? Looks like the jdk_other group should be updated to include 'jdk/nio/zipfs' ( and remove demo/zipfs ), given Shermans recent push. The tests have moved to jdk/test/jdk/nio/zipfs/XXX. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0e9e2be5c381 -Chris. > > 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 lance.andersen at oracle.com Mon Apr 21 20:58:46 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 21 Apr 2014 16:58:46 -0400 Subject: RFR: 8041331 Cleanup files for jtreg and windows Message-ID: <5C24B83C-10CB-4C64-AC56-5F92C037C888@oracle.com> Need a reviewer for some additional updates of the SQLException tests I pushed on Friday so that they play nicer WRT clean up on windows with some tools. Did some minor refactoring as part of this to address some of Roger's earlier comments seeing I had to touch the tests. The webrev is at http://cr.openjdk.java.net/~lancea/8041331/webrev.00/ 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 richard.warburton at gmail.com Mon Apr 21 21:51:40 2014 From: richard.warburton at gmail.com (Richard Warburton) Date: Mon, 21 Apr 2014 23:51:40 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <5354FC9F.1020409@gmail.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> Message-ID: Hi Peter, > I'm suggesting this alternative, because Buffer methods can stay final in > this case. This is more JIT-friendly. And, if I'm not mistaken, client code > compiled using JDK8 onto which this API change was backported, would still > run with JDK8 (or JDK7 when compiled with -target 1.7) onto which the API > change was not back-ported. > Thanks for suggesting this alternative. I think there are a few downsides to this approach as well though. 1. Anyone with code referring to 'ByteBuffer' now gets rawtype generics errors. 2. Anyone with -Werror (like openjdk!) now fails to compile. 3. This is a more complex change than the one I was proposing and smaller, simpler, changes seem to be less risky. 4. Developers do genuinely get confused by generics. Not a reason not to use them ever but a good reason not to introduce them if the issue can be solved by an alternative approach. Happy to be corrected if I've misunderstood anything ;) regards, Richard Warburton http://insightfullogic.com @RichardWarburto From david.lloyd at redhat.com Mon Apr 21 22:02:26 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 21 Apr 2014 17:02:26 -0500 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> Message-ID: <53559572.2080004@redhat.com> On 04/21/2014 04:51 PM, Richard Warburton wrote: > Hi Peter, > > I'm suggesting this alternative, because Buffer methods can stay > final in this case. This is more JIT-friendly. And, if I'm not > mistaken, client code compiled using JDK8 onto which this API change > was backported, would still run with JDK8 (or JDK7 when compiled > with -target 1.7) onto which the API change was not back-ported. > > > Thanks for suggesting this alternative. I think there are a few > downsides to this approach as well though. > > 1. Anyone with code referring to 'ByteBuffer' now gets rawtype generics > errors. > 2. Anyone with -Werror (like openjdk!) now fails to compile. > 3. This is a more complex change than the one I was proposing and > smaller, simpler, changes seem to be less risky. > 4. Developers do genuinely get confused by generics. Not a reason not to > use them ever but a good reason not to introduce them if the issue can > be solved by an alternative approach. > > Happy to be corrected if I've misunderstood anything ;) Um, do we *know* that there is a performance cost to covariantly overriding these methods? There would seem to be enough information to keep them monomorphic, if the optimizer is smart enough to inline the bridge methods and the delegating override method. The overridden methods in addition can be final, meaning that in the 99% case that you're invoking directly on the desired buffer type, it should be just as optimizable for the same reason that the original methods were optimizable. The only potentially "slow" invocation path is if you call the method on a Buffer reference, and even then it seems like there's enough information to avoid slowness - and if not, then that seems like a HotSpot problem that is very solvable ("if all overrides of this method call super.xxx(), inline & eliminate them"). Is there a real, solid hypothesis that would demonstrate that any of this is not true? -- - DML From otaviojava at java.net Mon Apr 21 23:28:02 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Mon, 21 Apr 2014 20:28:02 -0300 Subject: StringBuilder instead of StringBuffer in java.util package Message-ID: diff -r 57c1da89ae1a src/share/classes/java/util/prefs/Base64.java --- a/src/share/classes/java/util/prefs/Base64.java Wed Apr 16 12:32:36 2014 -0700 +++ b/src/share/classes/java/util/prefs/Base64.java Mon Apr 21 20:20:57 2014 -0300 @@ -57,7 +57,7 @@ int numFullGroups = aLen/3; int numBytesInPartialGroup = aLen - 3*numFullGroups; int resultLen = 4*((aLen + 2)/3); - StringBuffer result = new StringBuffer(resultLen); + StringBuilder result = new StringBuilder(resultLen); char[] intToAlpha = (alternate ? intToAltBase64 : intToBase64); // Translate all full groups from byte array elements to Base64 @@ -259,3 +259,4 @@ } } } + diff -r 57c1da89ae1a src/share/classes/java/util/regex/PatternSyntaxException.java --- a/src/share/classes/java/util/regex/PatternSyntaxException.java Wed Apr 16 12:32:36 2014 -0700 +++ b/src/share/classes/java/util/regex/PatternSyntaxException.java Mon Apr 21 20:21:52 2014 -0300 @@ -105,7 +105,7 @@ * @return The full detail message */ public String getMessage() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append(desc); if (index >= 0) { sb.append(" near index "); @@ -122,3 +122,4 @@ } } + diff -r 57c1da89ae1a src/share/classes/java/util/Properties.java --- a/src/share/classes/java/util/Properties.java Wed Apr 16 12:32:36 2014 -0700 +++ b/src/share/classes/java/util/Properties.java Mon Apr 21 20:22:44 2014 -0300 @@ -602,7 +602,7 @@ if (bufLen < 0) { bufLen = Integer.MAX_VALUE; } - StringBuffer outBuffer = new StringBuffer(bufLen); + StringBuilder outBuffer = new StringBuilder(bufLen); for(int x=0; x If I copy a file to another I can try (src = open(ifile); dest = open(ofile)) { while (!src.EOF) dest.write(src.read()); } but what if there are multiple destinations? Is there something like try (src = open(ifile); manager = new CloseableManager()) { for (ofile: ofiles) { manager.register(open(ofile)); } while (!src.EOF) { buffer = src.read(); for (dest: manager) dest.write(buffer); } } Thanks Max From stuart.marks at oracle.com Tue Apr 22 01:26:44 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 21 Apr 2014 18:26:44 -0700 Subject: RFR: 8041331 Cleanup files for jtreg and windows In-Reply-To: <5C24B83C-10CB-4C64-AC56-5F92C037C888@oracle.com> References: <5C24B83C-10CB-4C64-AC56-5F92C037C888@oracle.com> Message-ID: <5355C554.2000900@oracle.com> On 4/21/14 1:58 PM, Lance Andersen wrote: > Need a reviewer for some additional updates of the SQLException tests I pushed on Friday so that they play nicer WRT clean up on windows with some tools. > > Did some minor refactoring as part of this to address some of Roger's earlier comments seeing I had to touch the tests. > > The webrev is at http://cr.openjdk.java.net/~lancea/8041331/webrev.00/ Hi Lance, Thanks for pointing me at this webrev. Extracting all the serialization/deserialization code into a helper method createSerializedException() makes good sense. Nice use of generics, too. I'd go farther and avoid creating a file in the first place. You can serialize to a ByteArrayOutputStream, extract the byte array, and deserialize from that. It's probably necessary to flush between serialization and deserialization. This avoids having to do any file cleanup at all. (The IOExceptions still have to be handled or declared, though.) You could go back and remove the fname argument from all callers, or you could leave it in as a label to use in messages if any error occurs in this routine. One tiny nitpick, at SQLNonTransientConnectionExceptionTests.java line 170, an extra semicolon was inserted. Thanks, s'marks From neil.toda at oracle.com Tue Apr 22 01:18:59 2014 From: neil.toda at oracle.com (Neil Toda) Date: Mon, 21 Apr 2014 18:18:59 -0700 Subject: review request: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily Message-ID: <5355C383.9050109@oracle.com> Webrev http://cr.openjdk.java.net/~ntoda/8035782/ for bug https://bugs.openjdk.java.net/browse/JDK-8035782 The file : ./jdk/src/share/classes/sun/launcher/LauncherHelper.java has been modified so that the inner class FXHelper is not loaded unnecessarily. FXHelper, which is needed to make initializations for any JavaFX application, was being loaded for all applications. The fix was straight forward, with the lifting of one method and several static strings into FXHelper's superclass, LauncherHelper. Kevin Rushforth supplied three tests of applications not in jar files. These needed to be explicitly tested. These tests require the JavaFX bundle in the build, and the return code 2 signifies success. Launcher tests for jtreg: ./jdk/test/tools/launcher passed on Windows 7 64 and Oracle-Linux6-64. JPRT tests were run and passed on scv3. Thanks -neil From zhong.j.yu at gmail.com Tue Apr 22 02:30:47 2014 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Mon, 21 Apr 2014 21:30:47 -0500 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <53550A08.3090005@CoSoCo.de> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53550A08.3090005@CoSoCo.de> Message-ID: On Mon, Apr 21, 2014 at 7:07 AM, Ulf Zibis wrote: > So to me, this is clearly a language matter, not to solve by tricky > footprint and/or performance lasting code on APIs: > People want a _smart syntax_ for consecutive method invocations on the same > object, that's all! Amen to that! However I'm a little concerned with the mental effort a reader needs to figure out the implicit method receiver. I'd like to see more explicitness in establishing the implicit method receiver, something like Pascal's with statement. expr "." { // expr is the implicit receiver for this block foo(); // interpreted as expr.foo() } so that we could write CharBuffer.allocate(26).{position(2);put("C");position(25);put("Z");} string.{ mySub=subString(indexOf("C"), indexOf("Q")); } new HashMap<>().{ put(n1,v1); put(n2,v2); } new Button().{ color(red); text("hello"); onClick(event->color(blue)); } Zhong Yu From peter.levart at gmail.com Tue Apr 22 07:05:21 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 22 Apr 2014 09:05:21 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53550A08.3090005@CoSoCo.de> Message-ID: <535614B1.1010400@gmail.com> On 04/22/2014 04:30 AM, Zhong Yu wrote: > On Mon, Apr 21, 2014 at 7:07 AM, Ulf Zibis wrote: >> So to me, this is clearly a language matter, not to solve by tricky >> footprint and/or performance lasting code on APIs: >> People want a _smart syntax_ for consecutive method invocations on the same >> object, that's all! > Amen to that! > > However I'm a little concerned with the mental effort a reader needs > to figure out the implicit method receiver. I'd like to see more > explicitness in establishing the implicit method receiver, something > like Pascal's with statement. > > expr "." > { > // expr is the implicit receiver for this block > foo(); // interpreted as expr.foo() > } > > so that we could write > > CharBuffer.allocate(26).{position(2);put("C");position(25);put("Z");} > > string.{ mySub=subString(indexOf("C"), indexOf("Q")); } > > new HashMap<>().{ put(n1,v1); put(n2,v2); } > > new Button().{ color(red); text("hello"); onClick(event->color(blue)); } > Some questions about this syntax: What is the type of : new HashMap<>().{ put(n1,v1); put(n2,v2); } is it an expression or a statement? It should be an expression, otherwise it's not of much use. It should be possible to do: Map map = new HashMap<>().{ put(n1,v1); put(n2,v2); }; ...but that looks very similar to an anonymous class syntax, doesn't it? It actually behaves similarly to, for example: Map map = new HashMap<>() {{ put(n1,v1); put(n2,v2); }}; I don't know if this is good or bad. It certainly spawns all kinds of questions that were on the agenda for lambda expressions, like: - what's the meaning of "this" inside the .{ ... } block? - what's the meaning of "break", "continue", "next", "return", .... (I guess it should be the same as with the ordinary lexical block: { ... }, although it's rather unusual to be able to for example "break" out of a loop inside the evaluation of an expression) Regards, Peter > Zhong Yu From peter.levart at gmail.com Tue Apr 22 07:16:18 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 22 Apr 2014 09:16:18 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> Message-ID: <53561742.9020807@gmail.com> On 04/21/2014 11:51 PM, Richard Warburton wrote: > Hi Peter, > > I'm suggesting this alternative, because Buffer methods can stay > final in this case. This is more JIT-friendly. And, if I'm not > mistaken, client code compiled using JDK8 onto which this API > change was backported, would still run with JDK8 (or JDK7 when > compiled with -target 1.7) onto which the API change was not > back-ported. > > > Thanks for suggesting this alternative. I think there are a few > downsides to this approach as well though. > > 1. Anyone with code referring to 'ByteBuffer' now gets rawtype > generics errors. > 2. Anyone with -Werror (like openjdk!) now fails to compile. Yeah, this would require all uses to replace ByteBuffer with ByteBuffer. I guess this is a show-stopper. > 3. This is a more complex change than the one I was proposing and > smaller, simpler, changes seem to be less risky. If we can prove that relaxing Buffer final methods does not represent a performance regression, then by all means, it seems less risky. Regards, Peter > 4. Developers do genuinely get confused by generics. Not a reason not > to use them ever but a good reason not to introduce them if the issue > can be solved by an alternative approach. > > Happy to be corrected if I've misunderstood anything ;) > > regards, > > Richard Warburton > > http://insightfullogic.com > @RichardWarburto From paul.sandoz at oracle.com Tue Apr 22 08:07:06 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 22 Apr 2014 10:07:06 +0200 Subject: Conditions with that always returns true is 'if' necessary? In-Reply-To: References: Message-ID: Hi Ot?vio, On Apr 21, 2014, at 3:06 PM, Ot?vio Gon?alves de Santana wrote: > Hello everyone, one question. > Conditions that always returns true, is 'if' necessary? I can imagine it is a left over from hacking in the fast path. IMHO better to remove the if and comment the line below to retain the general pattern. Could easily be tacked on to an existing change e.g. if Vladimir is not fed up updating his basic types patch :-) http://cr.openjdk.java.net/~vlivanov/8037210 Paul. > I found one. > > diff -r 57c1da89ae1a > src/share/classes/java/lang/invoke/BoundMethodHandle.java > --- a/src/share/classes/java/lang/invoke/BoundMethodHandle.java Wed Apr 16 > 12:32:36 2014 -0700 > +++ b/src/share/classes/java/lang/invoke/BoundMethodHandle.java Mon Apr 21 > 09:50:29 2014 -0300 > @@ -66,8 +66,7 @@ > try { > switch (xtype) { > case 'L': > - if (true) return bindSingle(type, form, x); // Use known > fast path. > - return (BoundMethodHandle) > SpeciesData.EMPTY.extendWithType('L').constructor[0].invokeBasic(type, > form, x); > + return bindSingle(type, form, x); // Use known fast path. > case 'I': > return (BoundMethodHandle) > SpeciesData.EMPTY.extendWithType('I').constructor[0].invokeBasic(type, > form, ValueConversions.widenSubword(x)); > case 'J': > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 From paul.sandoz at oracle.com Tue Apr 22 08:47:23 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 22 Apr 2014 10:47:23 +0200 Subject: try-with-resources on arbitrary multiple files? In-Reply-To: References: Message-ID: On Apr 22, 2014, at 3:18 AM, Wang Weijun wrote: > If I copy a file to another I can > > try (src = open(ifile); dest = open(ofile)) { > while (!src.EOF) dest.write(src.read()); > } > > but what if there are multiple destinations? Is there something like > Not that i am aware of. A fun little trick you can do is the following: File ifile = null; List dests = new ArrayList<>(); try (InputStream src = open(ifile); AutoCloseable ac = () -> closeAll(dests)) { dests.add(...); .... } static void closeAll(Collection l) throws IOException { ... } But still that does not avoid the main work of closing stuff. Paul. > try (src = open(ifile); manager = new CloseableManager()) { > for (ofile: ofiles) { > manager.register(open(ofile)); > } > while (!src.EOF) { > buffer = src.read(); > for (dest: manager) dest.write(buffer); > } > } > > Thanks > Max > From richard.warburton at gmail.com Tue Apr 22 08:55:39 2014 From: richard.warburton at gmail.com (Richard Warburton) Date: Tue, 22 Apr 2014 10:55:39 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <535614B1.1010400@gmail.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53550A08.3090005@CoSoCo.de> <535614B1.1010400@gmail.com> Message-ID: Hi, > It certainly spawns all kinds of questions that were on the agenda for > lambda expressions, like: > - what's the meaning of "this" inside the .{ ... } block? > - what's the meaning of "break", "continue", "next", "return", .... (I > guess it should be the same as with the ordinary lexical block: { ... }, > although it's rather unusual to be able to for example "break" out of a > loop inside the evaluation of an expression) > I appreciate you guys are excited about the idea of language changes, but can you please discuss them in another thread and not hijack this library discussion thread. regards, Richard Warburton http://insightfullogic.com @RichardWarburto From peter.levart at gmail.com Tue Apr 22 09:17:54 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 22 Apr 2014 11:17:54 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <53559572.2080004@redhat.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53559572.2080004@redhat.com> Message-ID: <535633C2.5090501@gmail.com> On 04/22/2014 12:02 AM, David M. Lloyd wrote: > Um, do we *know* that there is a performance cost to covariantly > overriding these methods? There would seem to be enough information > to keep them monomorphic, if the optimizer is smart enough to inline > the bridge methods and the delegating override method. The overridden > methods in addition can be final, meaning that in the 99% case that > you're invoking directly on the desired buffer type, it should be just > as optimizable for the same reason that the original methods were > optimizable. The only potentially "slow" invocation path is if you > call the method on a Buffer reference, and even then it seems like > there's enough information to avoid slowness - and if not, then that > seems like a HotSpot problem that is very solvable ("if all overrides > of this method call super.xxx(), inline & eliminate them"). It's more complicated than that. Maybe we need an expert for hotspot JIT to answer this question, but as the code is written in the Rickard's webrev, then the reasoning behind the JIT to keep the monomorphic dispatch would have to be more involving. Richard is doing the following (in ByteBuffer): @Override public ByteBuffer position(int newPosition) { super.position(newPosition); return this; } javac compiles each of the covariant overrides as two methods - one that actually "overrides" the virtual method in superclass (has the same signature) and calls the covariant-returning method with a virtual dispatch. So ByteBuffer.position(int) is compiled as: public ByteBuffer position(int newPosition) { super.position(newPosition); return this; } public Buffer position(int newPosition) { // this is an invokevirtual for position:(I)Ljava/nio/ByteBuffer; return (ByteBuffer) position( (int) newPosition); } So for a call-site invoking virtual position:(I)Ljava/nio/Buffer; to behave the same as if the Buffer.position(int) was final, JIT would have to prove a lot of things. It would have to prove that all the methods involved in currently loaded hierarchy are basically the same. Among the things it would have to prove that, for example, ByteBuffer.position(int) returns what Buffer.position(int) returns. I don't know if it would help much, but the following covariant override might give a better hint to JIT in that respect: @Override public ByteBuffer position(int newPosition) { return (ByteBuffer) super.position(newPosition); } ...or it might not, since JIT would have to prove, that the cast is actually a no-op (that it always succeeds), which could be done by proving that Buffer.position(int) always returns "this", which is the same thing it would have to prove with Richard's variant of override. > > Is there a real, solid hypothesis that would demonstrate that any of > this is not true? We have to test the performance impact of this change. Regards, Peter > > -- > - DML If you're invoking the covariant-return method in the subtype (which is in addition final), then there's no problem, since this method is calling super with invokespecial, which I think is From fvheeswijk at outlook.com Tue Apr 22 10:10:32 2014 From: fvheeswijk at outlook.com (Frank van Heeswijk) Date: Tue, 22 Apr 2014 10:10:32 +0000 Subject: Map.replaceAll when changing value types In-Reply-To: References: Message-ID: Hello, First of all, this is the first time I am sending a mail to any java mailing list, so please correct me if I did something wrong. I am a regular visitor and answered on stackoverflow ( http://stackoverflow.com/users/2057294/skiwi ) and noticed that there are quite a large amount of questions now already asking for a way to easily replace values in maps when their type fundamentally changes. I however also have a few concerns while doing this, which will be listed below. Take first as example the following code, it may not be the best example, but it should show the intention: Map map = new HashMap<>(); map.put("test", 5); Map mapped = map.entrySet().stream() .collect(Collectors.toMap(Map.Entry::getKey, entry -> String.valueOf(entry.getValue()))); The intention here was to map the integer values to their string counterparts in a single map, functionally this is equivalent to the following: Map map = new HashMap<>(); map.put("test", 5); map.replaceAll((k, v) -> v + 1); One would expect the first case to also be a one-liner, possibly somewhat like: Map mapped = map.replaceAllSpecial((k, v) -> String.valueOf(v)); Based on this I have the following concerns: 1. How would the method exactly need to look like? Should it also have the option to take a Function valueMapper as argument? 2. How could this be optimized? Surely we do not *really* want to take all map entries out of one map and insert the modified value in a new map, I was thinking that an in-place modification would be the best, but then you have the issue where the type changes. Lastly, I hope that we can agree on that for such a trivial usecase, the usage of streams is possibly too complicated and furthermore point (2) is very important. As some more reference, here are some of the stackoverflow questions that ask for it: - http://stackoverflow.com/questions/23213891/how-to-map-values-in-a-map-in-java-8 - http://stackoverflow.com/questions/22840170/in-java-8-functional-style-how-can-i-map-the-values-over-a-java-util-map Regards, Frank van Heeswijk From lance.andersen at oracle.com Tue Apr 22 11:22:45 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 22 Apr 2014 07:22:45 -0400 Subject: RFR: 8041331 Cleanup files for jtreg and windows In-Reply-To: <5355C554.2000900@oracle.com> References: <5C24B83C-10CB-4C64-AC56-5F92C037C888@oracle.com> <5355C554.2000900@oracle.com> Message-ID: <0331E0BA-0AED-4CDD-8288-0D94215BA7A7@oracle.com> Hi Stuart On Apr 21, 2014, at 9:26 PM, Stuart Marks wrote: > > > On 4/21/14 1:58 PM, Lance Andersen wrote: >> Need a reviewer for some additional updates of the SQLException tests I pushed on Friday so that they play nicer WRT clean up on windows with some tools. >> >> Did some minor refactoring as part of this to address some of Roger's earlier comments seeing I had to touch the tests. >> >> The webrev is at http://cr.openjdk.java.net/~lancea/8041331/webrev.00/ > > Hi Lance, > > Thanks for pointing me at this webrev. :-) > > Extracting all the serialization/deserialization code into a helper method createSerializedException() makes good sense. Nice use of generics, too. Thank you. > > I'd go farther and avoid creating a file in the first place. You can serialize to a ByteArrayOutputStream, extract the byte array, and deserialize from that. It's probably necessary to flush between serialization and deserialization. This avoids having to do any file cleanup at all. (The IOExceptions still have to be handled or declared, though.) Roger had suggested it earlier and thought I would leave it but obviously it was the wrong choice :-) I have switched this to use a byte array vs file IO > > You could go back and remove the fname argument from all callers, or you could leave it in as a label to use in messages if any error occurs in this routine. removed the extra argument, netbeans was my friend here ;-) > > One tiny nitpick, at SQLNonTransientConnectionExceptionTests.java line 170, an extra semicolon was inserted. Thanks for catching that, fixed The revised webrev is at http://cr.openjdk.java.net/~lancea/8041331/webrev.01/ Best Lance > > Thanks, > > s'marks > 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 Tue Apr 22 12:06:05 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 22 Apr 2014 14:06:05 +0200 Subject: StringBuilder instead of StringBuffer in java.util package In-Reply-To: References: Message-ID: Hi Ot?vio, These look like good finds. I bet there are lots more of them. IntelliJ reports 284 possible uses in src/share/classes (see the "'StringBuffer' may be 'StringBuilder'" migration aid), but i have not verified all those. Perhaps we should do this more systematically over all the Java source? -- Do you want to become an openJDK contributor? I don't see you in the OpenJDK census. If you become a contributor: http://openjdk.java.net/contribute/ then i can directly accept patches from you and commit them with you as the author Paul. On Apr 22, 2014, at 1:28 AM, Ot?vio Gon?alves de Santana wrote: > diff -r 57c1da89ae1a src/share/classes/java/util/prefs/Base64.java > --- a/src/share/classes/java/util/prefs/Base64.java Wed Apr 16 12:32:36 > 2014 -0700 > +++ b/src/share/classes/java/util/prefs/Base64.java Mon Apr 21 20:20:57 > 2014 -0300 > @@ -57,7 +57,7 @@ > int numFullGroups = aLen/3; > int numBytesInPartialGroup = aLen - 3*numFullGroups; > int resultLen = 4*((aLen + 2)/3); > - StringBuffer result = new StringBuffer(resultLen); > + StringBuilder result = new StringBuilder(resultLen); > char[] intToAlpha = (alternate ? intToAltBase64 : intToBase64); > > // Translate all full groups from byte array elements to Base64 > @@ -259,3 +259,4 @@ > } > } > } > + > > > diff -r 57c1da89ae1a > src/share/classes/java/util/regex/PatternSyntaxException.java > --- a/src/share/classes/java/util/regex/PatternSyntaxException.java Wed Apr > 16 12:32:36 2014 -0700 > +++ b/src/share/classes/java/util/regex/PatternSyntaxException.java Mon Apr > 21 20:21:52 2014 -0300 > @@ -105,7 +105,7 @@ > * @return The full detail message > */ > public String getMessage() { > - StringBuffer sb = new StringBuffer(); > + StringBuilder sb = new StringBuilder(); > sb.append(desc); > if (index >= 0) { > sb.append(" near index "); > @@ -122,3 +122,4 @@ > } > > } > + > > > diff -r 57c1da89ae1a src/share/classes/java/util/Properties.java > --- a/src/share/classes/java/util/Properties.java Wed Apr 16 12:32:36 2014 > -0700 > +++ b/src/share/classes/java/util/Properties.java Mon Apr 21 20:22:44 2014 > -0300 > @@ -602,7 +602,7 @@ > if (bufLen < 0) { > bufLen = Integer.MAX_VALUE; > } > - StringBuffer outBuffer = new StringBuffer(bufLen); > + StringBuilder outBuffer = new StringBuilder(bufLen); > > for(int x=0; x char aChar = theString.charAt(x); > @@ -1209,3 +1209,4 @@ > } > } > } > + > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 From ivan.gerasimov at oracle.com Tue Apr 22 12:13:56 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 22 Apr 2014 16:13:56 +0400 Subject: RFR [8040806]: BitSet.toString() can throw IndexOutOfBoundsException Message-ID: <53565D04.7010905@oracle.com> Hello! If a BitSet has the bit Integer.MAX_VALUE set, then calling toString() will throw an exception. The same thing happens if the bit (Integer.MAX_VALUE-1) is set. Would you please help review the fix for this issue? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040806 WEBREV: http://cr.openjdk.java.net/~igerasim/8040806/0/webrev/ Sincerely yours, Ivan From otaviojava at java.net Tue Apr 22 12:14:44 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Tue, 22 Apr 2014 09:14:44 -0300 Subject: Conditions with that always returns true is 'if' necessary? In-Reply-To: References: Message-ID: Thank for your opinion. Done this way to keep the pattern. diff -r 57c1da89ae1a src/share/classes/java/lang/invoke/BoundMethodHandle.java --- a/src/share/classes/java/lang/invoke/BoundMethodHandle.java Wed Apr 16 12:32:36 2014 -0700 +++ b/src/share/classes/java/lang/invoke/BoundMethodHandle.java Mon Apr 21 09:50:29 2014 -0300 @@ -66,8 +66,7 @@ try { switch (xtype) { case 'L': - if (true) return bindSingle(type, form, x); // Use known fast path. - return (BoundMethodHandle) SpeciesData.EMPTY.extendWithType('L').constructor[0].invokeBasic(type, form, x); + return bindSingle(type, form, x); + // Use known fast path. case 'I': return (BoundMethodHandle) SpeciesData.EMPTY.extendWithType('I').constructor[0].invokeBasic(type, form, ValueConversions.widenSubword(x)); case 'J': On Tue, Apr 22, 2014 at 5:07 AM, Paul Sandoz wrote: > Hi Ot?vio, > > On Apr 21, 2014, at 3:06 PM, Ot?vio Gon?alves de Santana < > otaviojava at java.net> wrote: > > > Hello everyone, one question. > > Conditions that always returns true, is 'if' necessary? > > I can imagine it is a left over from hacking in the fast path. IMHO better > to remove the if and comment the line below to retain the general pattern. > > Could easily be tacked on to an existing change e.g. if Vladimir is not > fed up updating his basic types patch :-) > > http://cr.openjdk.java.net/~vlivanov/8037210 > > Paul. > > > I found one. > > > > diff -r 57c1da89ae1a > > src/share/classes/java/lang/invoke/BoundMethodHandle.java > > --- a/src/share/classes/java/lang/invoke/BoundMethodHandle.java Wed Apr > 16 > > 12:32:36 2014 -0700 > > +++ b/src/share/classes/java/lang/invoke/BoundMethodHandle.java Mon Apr > 21 > > 09:50:29 2014 -0300 > > @@ -66,8 +66,7 @@ > > try { > > switch (xtype) { > > case 'L': > > - if (true) return bindSingle(type, form, x); // Use > known > > fast path. > > - return (BoundMethodHandle) > > SpeciesData.EMPTY.extendWithType('L').constructor[0].invokeBasic(type, > > form, x); > > + return bindSingle(type, form, x); // Use known fast > path. > > case 'I': > > return (BoundMethodHandle) > > SpeciesData.EMPTY.extendWithType('I').constructor[0].invokeBasic(type, > > form, ValueConversions.widenSubword(x)); > > case 'J': > > > > > > -- > > Atenciosamente. > > > > Ot?vio Gon?alves de Santana > > > > blog: http://otaviosantana.blogspot.com.br/ > > twitter: http://twitter.com/otaviojava > > site: http://www.otaviojava.com.br > > (11) 98255-3513 > > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From chris.hegarty at oracle.com Tue Apr 22 12:27:20 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Apr 2014 13:27:20 +0100 Subject: RFR: 8041331 Cleanup files for jtreg and windows In-Reply-To: <0331E0BA-0AED-4CDD-8288-0D94215BA7A7@oracle.com> References: <5C24B83C-10CB-4C64-AC56-5F92C037C888@oracle.com> <5355C554.2000900@oracle.com> <0331E0BA-0AED-4CDD-8288-0D94215BA7A7@oracle.com> Message-ID: On 22 Apr 2014, at 12:22, Lance Andersen wrote: > ?. > > The revised webrev is at http://cr.openjdk.java.net/~lancea/8041331/webrev.01/ Looks good to me Lance. -Chris. > > Best > Lance >> >> Thanks, >> >> s'marks >> > > > > 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 david.lloyd at redhat.com Tue Apr 22 12:48:15 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 22 Apr 2014 07:48:15 -0500 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <535633C2.5090501@gmail.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53559572.2080004@redhat.com> <535633C2.5090501@gmail.com> Message-ID: <5356650F.5020909@redhat.com> On 04/22/2014 04:17 AM, Peter Levart wrote: > On 04/22/2014 12:02 AM, David M. Lloyd wrote: >> Um, do we *know* that there is a performance cost to covariantly >> overriding these methods? There would seem to be enough information >> to keep them monomorphic, if the optimizer is smart enough to inline >> the bridge methods and the delegating override method. The overridden >> methods in addition can be final, meaning that in the 99% case that >> you're invoking directly on the desired buffer type, it should be just >> as optimizable for the same reason that the original methods were >> optimizable. The only potentially "slow" invocation path is if you >> call the method on a Buffer reference, and even then it seems like >> there's enough information to avoid slowness - and if not, then that >> seems like a HotSpot problem that is very solvable ("if all overrides >> of this method call super.xxx(), inline & eliminate them"). > > It's more complicated than that. Maybe we need an expert for hotspot JIT > to answer this question, but as the code is written in the Rickard's > webrev, then the reasoning behind the JIT to keep the monomorphic > dispatch would have to be more involving. Richard is doing the following > (in ByteBuffer): > > @Override > public ByteBuffer position(int newPosition) { > super.position(newPosition); > return this; > } > > javac compiles each of the covariant overrides as two methods - one that > actually "overrides" the virtual method in superclass (has the same > signature) and calls the covariant-returning method with a virtual > dispatch. So ByteBuffer.position(int) is compiled as: > > public ByteBuffer position(int newPosition) { > super.position(newPosition); > return this; > } > > public Buffer position(int newPosition) { > // this is an invokevirtual for position:(I)Ljava/nio/ByteBuffer; > return (ByteBuffer) position( (int) newPosition); > } If the methods were final, AFAICT it'd be more like this: public final ByteBuffer position(int newPosition) { // iirc super upcall is already bytecoded as invokespecial invokespecial (Buffer)Buffer.position(newPosition); return this; } public synthetic final Buffer position(int newPosition) { return effectively-invokespecial (ByteBuffer)ByteBuffer.position(newPosition); } Since there would only be one possible target for the invokevirtual, my understanding is that the JIT will convert that into an invokespecial, letting the whole works be optimized at worst and inlined at best. -- - DML From lance.andersen at oracle.com Tue Apr 22 13:05:53 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 22 Apr 2014 09:05:53 -0400 Subject: Error: ~Documents/hg-workspaces/openjdk9/dev/jdk/test/TEST.groups: group jdk_other: file not found: demo/zipfs In-Reply-To: <53557E96.8030701@oracle.com> References: <53557E96.8030701@oracle.com> Message-ID: <9760AA8D-B15A-4727-93E9-CF64F9EFD040@oracle.com> Here is the diff for this via bug 8041485 hg diff test/Test.groups diff -r 3aeb306d985c test/TEST.groups --- a/test/TEST.groups Tue Apr 22 08:57:01 2014 -0400 +++ b/test/TEST.groups Tue Apr 22 09:01:26 2014 -0400 @@ -194,7 +194,7 @@ com/sun/jndi \ com/sun/corba \ lib/testlibrary \ - demo/zipfs \ + jdk/nio/zipfs \ sample # ljanders-mac:jdk ljanders$ Best Lance On Apr 21, 2014, at 4:24 PM, Chris Hegarty wrote: > jdk/nio/zipfs 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 chris.hegarty at oracle.com Tue Apr 22 13:06:38 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Apr 2014 14:06:38 +0100 Subject: Error: ~Documents/hg-workspaces/openjdk9/dev/jdk/test/TEST.groups: group jdk_other: file not found: demo/zipfs In-Reply-To: <9760AA8D-B15A-4727-93E9-CF64F9EFD040@oracle.com> References: <53557E96.8030701@oracle.com> <9760AA8D-B15A-4727-93E9-CF64F9EFD040@oracle.com> Message-ID: Looks good to me Lance. -Chris. On 22 Apr 2014, at 14:05, Lance Andersen wrote: > > Here is the diff for this via bug 8041485 > > hg diff test/Test.groups > diff -r 3aeb306d985c test/TEST.groups > --- a/test/TEST.groups Tue Apr 22 08:57:01 2014 -0400 > +++ b/test/TEST.groups Tue Apr 22 09:01:26 2014 -0400 > @@ -194,7 +194,7 @@ > com/sun/jndi \ > com/sun/corba \ > lib/testlibrary \ > - demo/zipfs \ > + jdk/nio/zipfs \ > sample > > # > ljanders-mac:jdk ljanders$ > > Best > Lance > On Apr 21, 2014, at 4:24 PM, Chris Hegarty wrote: > >> jdk/nio/zipfs > > > > 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 Tue Apr 22 13:24:10 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 22 Apr 2014 15:24:10 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <5356650F.5020909@redhat.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53559572.2080004@redhat.com> <535633C2.5090501@gmail.com> <5356650F.5020909@redhat.com> Message-ID: <25EE2DD0-5B32-45D7-9A14-C3E9E501F5AB@oracle.com> On Apr 22, 2014, at 2:48 PM, David M. Lloyd wrote: > > If the methods were final, AFAICT it'd be more like this: > > public final ByteBuffer position(int newPosition) { > // iirc super upcall is already bytecoded as invokespecial > invokespecial (Buffer)Buffer.position(newPosition); > return this; > } > > public synthetic final Buffer position(int newPosition) { > return effectively-invokespecial (ByteBuffer)ByteBuffer.position(newPosition); > } > > Since there would only be one possible target for the invokevirtual, my understanding is that the JIT will convert that into an invokespecial, letting the whole works be optimized at worst and inlined at best. > Here is a simple example with the Java 8 byte code public class TestBridge { static class A { public A pos(int i) { return this; } } static class B extends A { public final B pos(int i) { super.pos(i); return this; } } } public final TestBridge$B pos(int); flags: ACC_PUBLIC, ACC_FINAL Code: stack=2, locals=2, args_size=2 0: aload_0 1: iload_1 2: invokespecial #2 // Method TestBridge$A.pos:(I)LTestBridge$A; 5: pop 6: aload_0 7: areturn public TestBridge$A pos(int); flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC Code: stack=2, locals=2, args_size=2 0: aload_0 1: iload_1 2: invokevirtual #3 // Method pos:(I)LTestBridge$B; 5: areturn I dunno why the synthetic bridge method is not marked as final. -- It's too hard for me to speculate what any performance impact might be. My suspicion is these methods are probably not used that often in hot loops so even if performance results are marginally worse the API improvement may trump that. Paul. From david.lloyd at redhat.com Tue Apr 22 13:29:58 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 22 Apr 2014 08:29:58 -0500 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <25EE2DD0-5B32-45D7-9A14-C3E9E501F5AB@oracle.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53559572.2080004@redhat.com> <535633C2.5090501@gmail.com> <5356650F.5020909@redhat.com> <25EE2DD0-5B32-45D7-9A14-C3E9E501F5AB@oracle.com> Message-ID: <53566ED6.3030309@redhat.com> On 04/22/2014 08:24 AM, Paul Sandoz wrote: > On Apr 22, 2014, at 2:48 PM, David M. Lloyd wrote: >> >> If the methods were final, AFAICT it'd be more like this: >> >> public final ByteBuffer position(int newPosition) { >> // iirc super upcall is already bytecoded as invokespecial >> invokespecial (Buffer)Buffer.position(newPosition); >> return this; >> } >> >> public synthetic final Buffer position(int newPosition) { >> return effectively-invokespecial (ByteBuffer)ByteBuffer.position(newPosition); >> } >> >> Since there would only be one possible target for the invokevirtual, my understanding is that the JIT will convert that into an invokespecial, letting the whole works be optimized at worst and inlined at best. >> > > Here is a simple example with the Java 8 byte code > > public class TestBridge { > static class A { > public A pos(int i) { return this; } > } > > static class B extends A { > public final B pos(int i) { super.pos(i); return this; } > } > } > > public final TestBridge$B pos(int); > flags: ACC_PUBLIC, ACC_FINAL > Code: > stack=2, locals=2, args_size=2 > 0: aload_0 > 1: iload_1 > 2: invokespecial #2 // Method TestBridge$A.pos:(I)LTestBridge$A; > 5: pop > 6: aload_0 > 7: areturn > > public TestBridge$A pos(int); > flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC > Code: > stack=2, locals=2, args_size=2 > 0: aload_0 > 1: iload_1 > 2: invokevirtual #3 // Method pos:(I)LTestBridge$B; > 5: areturn > > I dunno why the synthetic bridge method is not marked as final. Hmm that seems like a bug to me, I'll take it over to compiler-dev and see what they say... > It's too hard for me to speculate what any performance impact might be. My suspicion is these methods are probably not used that often in hot loops so even if performance results are marginally worse the API improvement may trump that. Yeah I am not sure we can say with certainty either way without testing. But if there is a performance cost, IMO it should be done anyway, and the performance cost should be fixed in javac and/or the JIT. -- - DML From paul.sandoz at oracle.com Tue Apr 22 14:29:10 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 22 Apr 2014 16:29:10 +0200 Subject: Map.replaceAll when changing value types In-Reply-To: References: Message-ID: Hi Frank, On Apr 22, 2014, at 12:10 PM, Frank van Heeswijk wrote: > > Hello, > > First of all, this is the first time I am sending a mail to any java mailing list, Welcome! > so please correct me if I did something wrong. > > I am a regular visitor and answered on stackoverflow ( http://stackoverflow.com/users/2057294/skiwi ) and noticed that there are quite a large amount of questions now already asking for a way to easily replace values in maps when their type fundamentally changes. > I however also have a few concerns while doing this, which will be listed below. > > Take first as example the following code, it may not be the best example, but it should show the intention: > > Map map = new HashMap<>(); > map.put("test", 5); > Map mapped = map.entrySet().stream() > .collect(Collectors.toMap(Map.Entry::getKey, entry -> String.valueOf(entry.getValue()))); > > The intention here was to map the integer values to their string counterparts in a single map, functionally this is equivalent to the following: > > Map map = new HashMap<>(); > map.put("test", 5); > map.replaceAll((k, v) -> v + 1); > > One would expect the first case to also be a one-liner, possibly somewhat like: > > Map mapped = map.replaceAllSpecial((k, v) -> String.valueOf(v)); > > Based on this I have the following concerns: > 1. How would the method exactly need to look like? Should it also have the option to take a Function valueMapper as argument? > 2. How could this be optimized? Surely we do not *really* want to take all map entries out of one map and insert the modified value in a new map, I was thinking that an in-place modification would be the best, but then you have the issue where the type changes. > Such in place modification is a definitely wrong, you are going to pollute your map so any previous refs to Map are going to break with a ClassCastException when values are accessed. To be safe you would need to consistently use Map in such cases. (We don't have union types so you could declare if you knew up front the types.) Unfortunately stream-based manipulating maps is more difficult than manipulating lists, as you have noted. One possible solution is to create some more map-oriented collectors, such as: public static Collector, ?, Map> toMapValue(Function valueMapper) { return Collectors.toMap(Map.Entry::getKey, e -> valueMapper.apply(e.getValue())); } Map a = new HashMap<>(); ... Map b = a.entrySet().stream().collect(toMapValue(v -> v.toString())); That at least reduces some of the boilerplate and is easier for developers to initially grok. Generally stream-based operations on maps could be improved with a BiStream so you could do: map.stream().mapValue(v -> v.toString()).collect(toMap()); We prototyped that (i have such an internal prototype hacked into the latest API) but decided we were not ready to commit to such an API in Java 8 (a number of cases where BiStream may have been useful were subsumed by Collectors.groupingBy), but it still might have value in a future release. We could add some common basic functionality to the default methods on Map e.g.: default Map transformValues(Function valueMapper) { ... } default Map swap() throws IllegalStateException; // throws for dup keys etc. but there is always a danger of adding too much, a high bar would have to set set for that IMHO, a BiStream view of a Map is more satisfying in this respect and aligns with a Stream view of a Collection. Hth, Paul. > Lastly, I hope that we can agree on that for such a trivial usecase, the usage of streams is possibly too complicated and furthermore point (2) is very important. > > As some more reference, here are some of the stackoverflow questions that ask for it: > - http://stackoverflow.com/questions/23213891/how-to-map-values-in-a-map-in-java-8 > - http://stackoverflow.com/questions/22840170/in-java-8-functional-style-how-can-i-map-the-values-over-a-java-util-map > > Regards, > > Frank van Heeswijk > From xueming.shen at oracle.com Tue Apr 22 14:44:33 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 22 Apr 2014 07:44:33 -0700 Subject: Error: ~Documents/hg-workspaces/openjdk9/dev/jdk/test/TEST.groups: group jdk_other: file not found: demo/zipfs In-Reply-To: <9760AA8D-B15A-4727-93E9-CF64F9EFD040@oracle.com> References: <53557E96.8030701@oracle.com> <9760AA8D-B15A-4727-93E9-CF64F9EFD040@oracle.com> Message-ID: <2125816F-0231-4D92-ABD1-D6045D51E2BC@oracle.com> Looks good. > On Apr 22, 2014, at 6:05 AM, Lance Andersen wrote: > > > Here is the diff for this via bug 8041485 > > hg diff test/Test.groups > diff -r 3aeb306d985c test/TEST.groups > --- a/test/TEST.groups Tue Apr 22 08:57:01 2014 -0400 > +++ b/test/TEST.groups Tue Apr 22 09:01:26 2014 -0400 > @@ -194,7 +194,7 @@ > com/sun/jndi \ > com/sun/corba \ > lib/testlibrary \ > - demo/zipfs \ > + jdk/nio/zipfs \ > sample > > # > ljanders-mac:jdk ljanders$ > > Best > Lance >> On Apr 21, 2014, at 4:24 PM, Chris Hegarty wrote: >> >> jdk/nio/zipfs > > > > 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 peter.levart at gmail.com Tue Apr 22 14:53:08 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 22 Apr 2014 16:53:08 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <5356650F.5020909@redhat.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53559572.2080004@redhat.com> <535633C2.5090501@gmail.com> <5356650F.5020909@redhat.com> Message-ID: <53568254.3010106@gmail.com> On 04/22/2014 02:48 PM, David M. Lloyd wrote: > On 04/22/2014 04:17 AM, Peter Levart wrote: >> On 04/22/2014 12:02 AM, David M. Lloyd wrote: >>> Um, do we *know* that there is a performance cost to covariantly >>> overriding these methods? There would seem to be enough information >>> to keep them monomorphic, if the optimizer is smart enough to inline >>> the bridge methods and the delegating override method. The overridden >>> methods in addition can be final, meaning that in the 99% case that >>> you're invoking directly on the desired buffer type, it should be just >>> as optimizable for the same reason that the original methods were >>> optimizable. The only potentially "slow" invocation path is if you >>> call the method on a Buffer reference, and even then it seems like >>> there's enough information to avoid slowness - and if not, then that >>> seems like a HotSpot problem that is very solvable ("if all overrides >>> of this method call super.xxx(), inline & eliminate them"). >> >> It's more complicated than that. Maybe we need an expert for hotspot JIT >> to answer this question, but as the code is written in the Rickard's >> webrev, then the reasoning behind the JIT to keep the monomorphic >> dispatch would have to be more involving. Richard is doing the following >> (in ByteBuffer): >> >> @Override >> public ByteBuffer position(int newPosition) { >> super.position(newPosition); >> return this; >> } >> >> javac compiles each of the covariant overrides as two methods - one that >> actually "overrides" the virtual method in superclass (has the same >> signature) and calls the covariant-returning method with a virtual >> dispatch. So ByteBuffer.position(int) is compiled as: >> >> public ByteBuffer position(int newPosition) { >> super.position(newPosition); >> return this; >> } >> >> public Buffer position(int newPosition) { >> // this is an invokevirtual for position:(I)Ljava/nio/ByteBuffer; >> return (ByteBuffer) position( (int) newPosition); >> } > > If the methods were final, AFAICT it'd be more like this: > > public final ByteBuffer position(int newPosition) { > // iirc super upcall is already bytecoded as invokespecial > invokespecial (Buffer)Buffer.position(newPosition); > return this; > } > > public synthetic final Buffer position(int newPosition) { > return effectively-invokespecial > (ByteBuffer)ByteBuffer.position(newPosition); > } > > Since there would only be one possible target for the invokevirtual, > my understanding is that the JIT will convert that into an > invokespecial, letting the whole works be optimized at worst and > inlined at best. > There are multiple possible targets for invokevirtual position:(I)Ljava/nio/Buffer; - all the methods that override it in all subclasses loaded. It doesn't matter if they are final or not (only if they are effectively final or not). The non-finality of a method has a performance impact only if the method *is* overridden in any of the loaded subclasses, otherwise it is effectively final and treated as such by JIT (at least that's how I understand it - any hotspot JIT expert please debunk my claims). That might also be the answer to why the synthetic method need not be marked as final if the covariant method is. The synthetic method can never be overridden in a sub-class (at least not by javac) - only the covariant method can be. But as Paul noted, the methods on Buffer are probably not used in hot loops alone, since they are just for reading/adjusting position/limit/mark. The hot loops probably also contain methods for reading/writing the buffer and those are only defined on particular sub-types of java.nio.Buffer, so it can reasonably be expected that the static (guaranteed) type of target upon which methods are called in hot loops is a particular subtype of java.nio.Buffer and JIT only has one method to choose from in this case. Regards, Peter From mandy.chung at oracle.com Tue Apr 22 14:52:57 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Apr 2014 07:52:57 -0700 Subject: Error: ~Documents/hg-workspaces/openjdk9/dev/jdk/test/TEST.groups: group jdk_other: file not found: demo/zipfs In-Reply-To: <2125816F-0231-4D92-ABD1-D6045D51E2BC@oracle.com> References: <53557E96.8030701@oracle.com> <9760AA8D-B15A-4727-93E9-CF64F9EFD040@oracle.com> <2125816F-0231-4D92-ABD1-D6045D51E2BC@oracle.com> Message-ID: <53568249.5000009@oracle.com> Sherman, Is it better to group zipfs in jdk_nio? Mandy On 4/22/2014 7:44 AM, Xueming Shen wrote: > Looks good. > >> On Apr 22, 2014, at 6:05 AM, Lance Andersen wrote: >> >> >> Here is the diff for this via bug 8041485 >> >> hg diff test/Test.groups >> diff -r 3aeb306d985c test/TEST.groups >> --- a/test/TEST.groups Tue Apr 22 08:57:01 2014 -0400 >> +++ b/test/TEST.groups Tue Apr 22 09:01:26 2014 -0400 >> @@ -194,7 +194,7 @@ >> com/sun/jndi \ >> com/sun/corba \ >> lib/testlibrary \ >> - demo/zipfs \ >> + jdk/nio/zipfs \ >> sample >> >> # >> ljanders-mac:jdk ljanders$ >> >> Best >> Lance >>> On Apr 21, 2014, at 4:24 PM, Chris Hegarty wrote: >>> >>> jdk/nio/zipfs >> >> >> 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 david.lloyd at redhat.com Tue Apr 22 15:25:16 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 22 Apr 2014 10:25:16 -0500 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <53568254.3010106@gmail.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53559572.2080004@redhat.com> <535633C2.5090501@gmail.com> <5356650F.5020909@redhat.com> <53568254.3010106@gmail.com> Message-ID: <535689DC.6060907@redhat.com> On 04/22/2014 09:53 AM, Peter Levart wrote: > On 04/22/2014 02:48 PM, David M. Lloyd wrote: >> On 04/22/2014 04:17 AM, Peter Levart wrote: >>> On 04/22/2014 12:02 AM, David M. Lloyd wrote: >>>> Um, do we *know* that there is a performance cost to covariantly >>>> overriding these methods? There would seem to be enough information >>>> to keep them monomorphic, if the optimizer is smart enough to inline >>>> the bridge methods and the delegating override method. The overridden >>>> methods in addition can be final, meaning that in the 99% case that >>>> you're invoking directly on the desired buffer type, it should be just >>>> as optimizable for the same reason that the original methods were >>>> optimizable. The only potentially "slow" invocation path is if you >>>> call the method on a Buffer reference, and even then it seems like >>>> there's enough information to avoid slowness - and if not, then that >>>> seems like a HotSpot problem that is very solvable ("if all overrides >>>> of this method call super.xxx(), inline & eliminate them"). >>> >>> It's more complicated than that. Maybe we need an expert for hotspot JIT >>> to answer this question, but as the code is written in the Rickard's >>> webrev, then the reasoning behind the JIT to keep the monomorphic >>> dispatch would have to be more involving. Richard is doing the following >>> (in ByteBuffer): >>> >>> @Override >>> public ByteBuffer position(int newPosition) { >>> super.position(newPosition); >>> return this; >>> } >>> >>> javac compiles each of the covariant overrides as two methods - one that >>> actually "overrides" the virtual method in superclass (has the same >>> signature) and calls the covariant-returning method with a virtual >>> dispatch. So ByteBuffer.position(int) is compiled as: >>> >>> public ByteBuffer position(int newPosition) { >>> super.position(newPosition); >>> return this; >>> } >>> >>> public Buffer position(int newPosition) { >>> // this is an invokevirtual for position:(I)Ljava/nio/ByteBuffer; >>> return (ByteBuffer) position( (int) newPosition); >>> } >> >> If the methods were final, AFAICT it'd be more like this: >> >> public final ByteBuffer position(int newPosition) { >> // iirc super upcall is already bytecoded as invokespecial >> invokespecial (Buffer)Buffer.position(newPosition); >> return this; >> } >> >> public synthetic final Buffer position(int newPosition) { >> return effectively-invokespecial >> (ByteBuffer)ByteBuffer.position(newPosition); >> } >> >> Since there would only be one possible target for the invokevirtual, >> my understanding is that the JIT will convert that into an >> invokespecial, letting the whole works be optimized at worst and >> inlined at best. >> > > There are multiple possible targets for invokevirtual > position:(I)Ljava/nio/Buffer; - all the methods that override it in all > subclasses loaded. It doesn't matter if they are final or not (only if > they are effectively final or not). The non-finality of a method has a > performance impact only if the method *is* overridden in any of the > loaded subclasses, otherwise it is effectively final and treated as such > by JIT (at least that's how I understand it - any hotspot JIT expert > please debunk my claims). That is only true if you are calling the method on the base class, which is normally seldom done (though it will be nearly always in legacy code, but see below). > That might also be the answer to why the synthetic method need not be > marked as final if the covariant method is. The synthetic method can > never be overridden in a sub-class (at least not by javac) - only the > covariant method can be. Doesn't sound quite right to me, but I'll defer to any experts who might wish to discuss it on compiler-dev. > But as Paul noted, the methods on Buffer are probably not used in hot > loops alone, since they are just for reading/adjusting > position/limit/mark. The hot loops probably also contain methods for > reading/writing the buffer and those are only defined on particular > sub-types of java.nio.Buffer, so it can reasonably be expected that the > static (guaranteed) type of target upon which methods are called in hot > loops is a particular subtype of java.nio.Buffer and JIT only has one > method to choose from in this case. Yeah new code will call the covariant final method directly in almost all cases for sure, having been compiled against it. The tricky case is old code - even if the JIT can figure out that it is really a subclass being invoked upon, it'd still be forced to target the non-covariant synthetic method due to the specific method reference in the bytecode. Hopefully at this point though, as you say, the lack of overriding classes will be enough to optimize the dispatch. -- - DML From iris.clark at oracle.com Tue Apr 22 17:14:28 2014 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 22 Apr 2014 10:14:28 -0700 (PDT) Subject: StringBuilder instead of StringBuffer in java.util package In-Reply-To: References: Message-ID: Hi, Paul. > Do you want to become an openJDK contributor? I don't see you in the OpenJDK census. > > If you become a contributor: > > http://openjdk.java.net/contribute/ > > then i can directly accept patches from you and commit them with you as the author I'm sure this is what you meant, but just to be clear... To directly accept Octavio's patches, he would need to be an Author for the Project as described on this page [1]. "Contributor" means we can accept his changes because he's signed an OCA [2] and his name appears on the Signatories List [3]. We acknowledge Contributors in the "Contributed-by:" field of changeset comments [4]. Thanks, Iris [1]: http://openjdk.java.net/projects/#project-author [2]: http://www.oracle.com/technetwork/oca-405177.pdf [3]: http://www.oracle.com/technetwork/community/oca-486395.html [4]: http://openjdk.java.net/guide/producingChangeset.html#changesetComment -----Original Message----- From: Paul Sandoz Sent: Tuesday, April 22, 2014 5:06 AM Cc: core-libs-dev at openjdk.java.net Subject: Re: StringBuilder instead of StringBuffer in java.util package Hi Ot?vio, These look like good finds. I bet there are lots more of them. IntelliJ reports 284 possible uses in src/share/classes (see the "'StringBuffer' may be 'StringBuilder'" migration aid), but i have not verified all those. Perhaps we should do this more systematically over all the Java source? -- Do you want to become an openJDK contributor? I don't see you in the OpenJDK census. If you become a contributor: http://openjdk.java.net/contribute/ then i can directly accept patches from you and commit them with you as the author Paul. On Apr 22, 2014, at 1:28 AM, Ot?vio Gon?alves de Santana wrote: > diff -r 57c1da89ae1a src/share/classes/java/util/prefs/Base64.java > --- a/src/share/classes/java/util/prefs/Base64.java Wed Apr 16 > 12:32:36 > 2014 -0700 > +++ b/src/share/classes/java/util/prefs/Base64.java Mon Apr 21 > +++ 20:20:57 > 2014 -0300 > @@ -57,7 +57,7 @@ > int numFullGroups = aLen/3; > int numBytesInPartialGroup = aLen - 3*numFullGroups; > int resultLen = 4*((aLen + 2)/3); > - StringBuffer result = new StringBuffer(resultLen); > + StringBuilder result = new StringBuilder(resultLen); > char[] intToAlpha = (alternate ? intToAltBase64 : > intToBase64); > > // Translate all full groups from byte array elements to > Base64 @@ -259,3 +259,4 @@ > } > } > } > + > > > diff -r 57c1da89ae1a > src/share/classes/java/util/regex/PatternSyntaxException.java > --- a/src/share/classes/java/util/regex/PatternSyntaxException.java > Wed Apr > 16 12:32:36 2014 -0700 > +++ b/src/share/classes/java/util/regex/PatternSyntaxException.java > +++ Mon Apr > 21 20:21:52 2014 -0300 > @@ -105,7 +105,7 @@ > * @return The full detail message > */ > public String getMessage() { > - StringBuffer sb = new StringBuffer(); > + StringBuilder sb = new StringBuilder(); > sb.append(desc); > if (index >= 0) { > sb.append(" near index "); @@ -122,3 +122,4 @@ > } > > } > + > > > diff -r 57c1da89ae1a src/share/classes/java/util/Properties.java > --- a/src/share/classes/java/util/Properties.java Wed Apr 16 12:32:36 > 2014 > -0700 > +++ b/src/share/classes/java/util/Properties.java Mon Apr 21 20:22:44 > +++ 2014 > -0300 > @@ -602,7 +602,7 @@ > if (bufLen < 0) { > bufLen = Integer.MAX_VALUE; > } > - StringBuffer outBuffer = new StringBuffer(bufLen); > + StringBuilder outBuffer = new StringBuilder(bufLen); > > for(int x=0; x char aChar = theString.charAt(x); @@ -1209,3 +1209,4 @@ > } > } > } > + > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 From mandy.chung at oracle.com Tue Apr 22 19:39:57 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Apr 2014 12:39:57 -0700 Subject: Review request: 8040059 Change default policy for extensions to no permission Message-ID: <5356C58D.5070805@oracle.com> This change proposes to remove granting all permissions for extensions as the default and implements the principle of least privilege.In JDK 9, we want to reduce the privileges of as many system classes as possible. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.00/ This patch has reduced the zipfs, localedata and cldrdata to grant the permissions they require. It grants AllPermission to other jar files in the lib/ext directory shipped with JDK and this change is intended to enable the component teams to identify the minimum permissions and fix any issue, if any. Libraries installed in the extensions directory depending on AllPermission granted by default are impacted. Making this change as early in JDK 9 allows us to identify any customer impacted by this change. Mandy From brian.burkhalter at oracle.com Tue Apr 22 23:48:09 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 22 Apr 2014 16:48:09 -0700 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] Message-ID: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> Hello, Issue: https://bugs.openjdk.java.net/browse/JDK-8026236 Patch: http://cr.openjdk.java.net/~bpb/8026236/webrev.00/ This test provides a rudimentary verification of isProbablePrime() by: 1 - checking that the first 100000 primes are correctly identified as probably prime 2 - checking that a random sample of positive integers does not reveal non-prime numbers which test as prime The test allows for specification of an alternate source file of prime numbers if one wants to run it by hand. The file of primes included in the patch was limited to 100000 values in the interest of keeping the file size small. I think that the range of random numbers used for the non-prime portion of the test (currently [0,100000)) needs to be reexamined, but I wanted to throw this out there for discussion as-is. I?ve extended the use of the j.u.stream API to the entire test as recommended by Paul in http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021859.html. Thanks, Brian From brian.goetz at oracle.com Tue Apr 22 12:42:56 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 22 Apr 2014 08:42:56 -0400 Subject: Map.replaceAll when changing value types In-Reply-To: References: Message-ID: Its a fair question. Certainly the stream construction you suggest will do the job; you?re looking for a more compact way to do it. Note that of course you could write your own static method that encapsulates the stream operation and you?d be done. Map.replace/replaceAll are in-place, mutative methods, and so make sense as instance methods on Map. What you want is a ?construct a new map?, which is more of a static factory. Two reasons it was not prioritized: (a) as a static method, anyone can write it, and put it anywhere, so omitting it from the JDK doesn?t really prevent anyone from doing this, and (b) as a static method, there?s no value in having specialized implementations in the various JDK Map implementations. On Apr 22, 2014, at 6:10 AM, Frank van Heeswijk wrote: > > > > > Hello, > > First of all, this is the first time I am sending a mail to any java mailing list, so please correct me if I did something wrong. > > I am a regular visitor and answered on stackoverflow ( http://stackoverflow.com/users/2057294/skiwi ) and noticed that there are quite a large amount of questions now already asking for a way to easily replace values in maps when their type fundamentally changes. > I however also have a few concerns while doing this, which will be listed below. > > Take first as example the following code, it may not be the best example, but it should show the intention: > > Map map = new HashMap<>(); > map.put("test", 5); > Map mapped = map.entrySet().stream() > .collect(Collectors.toMap(Map.Entry::getKey, entry -> String.valueOf(entry.getValue()))); > > The intention here was to map the integer values to their string counterparts in a single map, functionally this is equivalent to the following: > > Map map = new HashMap<>(); > map.put("test", 5); > map.replaceAll((k, v) -> v + 1); > > One would expect the first case to also be a one-liner, possibly somewhat like: > > Map mapped = map.replaceAllSpecial((k, v) -> String.valueOf(v)); > > Based on this I have the following concerns: > 1. How would the method exactly need to look like? Should it also have the option to take a Function valueMapper as argument? > 2. How could this be optimized? Surely we do not *really* want to take all map entries out of one map and insert the modified value in a new map, I was thinking that an in-place modification would be the best, but then you have the issue where the type changes. > > Lastly, I hope that we can agree on that for such a trivial usecase, the usage of streams is possibly too complicated and furthermore point (2) is very important. > > As some more reference, here are some of the stackoverflow questions that ask for it: > - http://stackoverflow.com/questions/23213891/how-to-map-values-in-a-map-in-java-8 > - http://stackoverflow.com/questions/22840170/in-java-8-functional-style-how-can-i-map-the-values-over-a-java-util-map > > Regards, > > Frank van Heeswijk > From peter.levart at gmail.com Wed Apr 23 09:06:38 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 23 Apr 2014 11:06:38 +0200 Subject: RFR 9: JDK-8040892 Incorrect message in Exception thrown by Collectors.toMap(Function, Function) In-Reply-To: <86699497-9287-4B18-816E-B7F0D92A08F5@oracle.com> References: <534FF859.5090006@gmail.com> <534FFB92.4050805@gmail.com> <53500426.3060506@oracle.com> <535022B5.8090608@gmail.com> <86699497-9287-4B18-816E-B7F0D92A08F5@oracle.com> Message-ID: <5357829E.2030606@gmail.com> Hi, I propose a patch for: https://bugs.openjdk.java.net/browse/JDK-8040892 Here's the webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/Collectors.duplicateKey/webrev.02/ There has already been a discussion on the lambda-dev about this bug: http://mail.openjdk.java.net/pipermail/lambda-dev/2014-April/012005.html Initially a fix has been proposed which used a private RuntimeException subclass thrown by the merger function in order to transport the values that attempted to be merged out of Map.merge() method to an outer context where they could be combined with the key to produce a friendlier "duplicate key" message. It turns out that there is an alternative approach that doesn't require exception acrobatics - using Map.putIfAbsent() instead of Map.merge(). I checked both methods in Map defaults and in HashMap implementations for possible semantic differences. Same behaviour can be achieved by requiring that the value passed to Map.putIfAbsent(key, value) is non-null and throwing NPE if it isn't. Regards, Peter On 04/22/2014 02:44 PM, Paul Sandoz wrote: > Thanks Peter. > > FWIW i would have used the same exception throwing trick :-) > > Originally throwingMerger was public, but we hesitated about it's utility and made it private, glad we did that now. > > >> Hmmm, if Brian approves using this spare Exception subclass, I suggest >> extracting the creation of the accumulator into its own method. >> > Rather than the MergedRefusedException overriding fillInStackTrace it may be better to defer to the super constructor: > > MergeRefusedException(Object u, Object v) { > super(null, null, false, false) > this.u = u; > this.v = v; > } > > as that sets up the correct conditions for the state of the fields. > > Also since this is only relevant for the to*Map functions when no merger is explicitly provided it is tempting to rejig the implementation of those to create a Collector and wrap the existing mapMerger function, thus limiting the scope of the exception to where it is used. > > I have a slight concern that for large values the exception could hold large string values, but i don't think we try very hard generally in the JDK to use a form of pretty truncated printing... > > > Peter, i believe you have committer rights? Perhaps you could submit on core-libs for review? > > Paul. > From paul.sandoz at oracle.com Wed Apr 23 10:25:27 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 23 Apr 2014 12:25:27 +0200 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> Message-ID: <713E7918-869F-4A62-87BA-667D2F1A105C@oracle.com> On Apr 23, 2014, at 1:48 AM, Brian Burkhalter wrote: > Hello, > > Issue: https://bugs.openjdk.java.net/browse/JDK-8026236 > Patch: http://cr.openjdk.java.net/~bpb/8026236/webrev.00/ > > This test provides a rudimentary verification of isProbablePrime() by: > > 1 - checking that the first 100000 primes are correctly identified as probably prime > 2 - checking that a random sample of positive integers does not reveal non-prime numbers which test as prime > Note that the Stream obtained from br.lines will not close the underlying file, since it did not create the resource. You need to place the BufferedReader in the try. > The test allows for specification of an alternate source file of prime numbers if one wants to run it by hand. The file of primes included in the patch was limited to 100000 values in the interest of keeping the file size small. > 250k seems reasonable, but i don't know if there will be objections even to that size. Ideally it would be nice to download on demand to some separate repository and cached, but we really don't have the infrastructure in place for that (it would the same repository that could be used to publish JDK builds/images to be accessed by test machines). > I think that the range of random numbers used for the non-prime portion of the test (currently [0,100000)) needs to be reexamined, but I wanted to throw this out there for discussion as-is. > Why not range from [2, upperBound) ? long falsePositives = IntStream.range(0, upperBound) .mapToObj(BigInteger::valueOf) .filter(bi -> !primes.contains(bi)) .filter(bi -> bi.isProbablePrime(certainty)) .count(); Otherwise for better random sampling i recommend using SplittableRandom. Generally i don't like adding non-determinism to tests as it makes it very tricky to track down errors. Paul. > I?ve extended the use of the j.u.stream API to the entire test as recommended by Paul in http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021859.html. > > Thanks, > > Brian From paul.sandoz at oracle.com Wed Apr 23 14:21:00 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 23 Apr 2014 16:21:00 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <53504C52.3020509@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> Message-ID: Hi Peter, IMHO such security manager usage by the test is v. fragile and we should try and find a safer alternative if possible. However, there may also be an issue with lambda form code. (About a month ago i too was looking, internally, at this kind of issue and thought there was a questionable use of the application/system class loader when initializing the LambdaForm class, but then i got distracted with other stuff and forgot about it.) Your one-liner fix seems to do the trick, but I think we need Vladimir to confirm this is OK. Paul. On Apr 17, 2014, at 11:49 PM, Peter Levart wrote: > Hi, > > I'm cross-posting this on the mlvm-dev mailing list, because I think it concerns internal MHs implementation. > > While replacing some inner classes with lambdas in java.lang.UNIXProcess class, a jtreg test started failing. This test is employing a security manager with an unusual configuration. It defines "java.util" as a package for which access should be checked against the set of permissions. The class initialization of UNIXProcess class initializes some lambdas and their initialization fails with the following stack-trace: > > > java.lang.ExceptionInInitializerError > at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:256) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:221) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:210) > at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:82) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1638) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1602) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1778) > at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1727) > at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:442) > at java.lang.UNIXProcess$Platform.get(UNIXProcess.java:147) > at java.lang.UNIXProcess.(UNIXProcess.java:160) > at java.lang.ProcessImpl.start(ProcessImpl.java:130) > at java.lang.ProcessBuilder.start(ProcessBuilder.java:1023) > at java.lang.Runtime.exec(Runtime.java:620) > at java.lang.Runtime.exec(Runtime.java:485) > at SecurityManagerClinit.main(SecurityManagerClinit.java:70) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:484) > at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) > at java.lang.Thread.run(Thread.java:744) > Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.java.util") > at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) > at java.security.AccessController.checkPermission(AccessController.java:884) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:541) > at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1481) > * at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305)* > at java.lang.ClassLoader.loadClass(ClassLoader.java:359) > at sun.invoke.util.BytecodeDescriptor.parseSig(BytecodeDescriptor.java:83) > * at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:54)* > at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:41) > at java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:911) > at java.lang.invoke.MemberName.getMethodType(MemberName.java:144) > at java.lang.invoke.LambdaForm.computeInitialPreparedForms(LambdaForm.java:477) > at java.lang.invoke.LambdaForm.(LambdaForm.java:1641) > > > I think I found the root cause of the problem. It's nothing wrong with the test (although making "java.util" as an access-checked package is a little unusual). The problem, I think, is in MH's LambdaForm implementation. Although the UNIXProcess class is a system class (loaded by bootstrap class loader), MHs created by evaluating lambda expressions in this class, trigger loading a class in "java.util" package using AppClassLoader as the initiating class loader, which involves package access checks. This should not happen, I think, if only the system classes are involved in constructing MHs. > > I checked the code and there's a ClassLoader parameter passed to the *BytecodeDescriptor.parseMethod *method. This ClassLoader is taken as the defining class loader of the MemberName's declaring class for which the getMethoType() is requested. All the types involved in such MemberName (return type, parameter types) should be resolvable from the MemberName's declaring class' class loader. In our case, the class loader of the declaring class of the particular MemberName is bootstrap class loader, so null is passed as the ClassLoader parameter to the *BytecodeDescriptor.parseMethod *method. This method checks for null ClassLoader and replaces it with ClassLoader.getSystemClassLoader() before calling parseSig() with it, because parseSig() uses the ClassLoader instance to invoke loadClass() method on it. The ClassLoader.getSystemClassLoader() is the application class-loader (AppClassLoader). > > I think the right thing to do would be to use bootstrap class loader if the ClassLoader parameter passed to *BytecodeDescriptor.parseMethod *was null. The fix would be as follows: > > > =================================================================== > --- jdk/src/share/classes/sun/invoke/util/BytecodeDescriptor.java (revision 9770:8371276d52c0) > +++ jdk/src/share/classes/sun/invoke/util/BytecodeDescriptor.java (revision 9770+:8371276d52c0+) > @@ -43,8 +43,6 @@ > > static List> parseMethod(String bytecodeSignature, > int start, int end, ClassLoader loader) { > - if (loader == null) > - loader = ClassLoader.getSystemClassLoader(); > String str = bytecodeSignature; > int[] i = {start}; > ArrayList> ptypes = new ArrayList>(); > @@ -80,7 +78,7 @@ > i[0] = endc+1; > String name = str.substring(begc, endc).replace('/', '.'); > try { > - return loader.loadClass(name); > + return Class.forName(name, false, loader); > } catch (ClassNotFoundException ex) { > throw new TypeNotPresentException(name, ex); > } > > > > What do you think? Am I right? > > > Regards, Peter From peter.levart at gmail.com Wed Apr 23 14:28:35 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 23 Apr 2014 16:28:35 +0200 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> Message-ID: <5357CE13.8060905@gmail.com> Hi Brian, There seems to be a confusion between "upperBound" and the 1st "n" primer numbers. You pass "upperBound" as the parameter "n" of the parsePrimes() method which returns 1st "n" primes from the file (it can return less primes if the file is smaller). I suggest doing the following: - make parsePrimes() take "n" as it does and return 1st "n" primes from the file, but collect them into a NavigableSet (TreeSet) like that: private static *NavigableSet* parsePrimes(File f, long n) throws IOException { GZIPInputStream gis = new GZIPInputStream(new FileInputStream(f)); BufferedReader br = new BufferedReader(new InputStreamReader(gis)); try (Stream lines = br.lines()) { return lines.limit(n).map(BigInteger::new).collect(*toCollection(TreeSet::new)*); } } This would serve two purposes: - you could obtain the largest prime number from the set easily (NavigableSet.last()) and use it as the "upperBound" for the range of integers you test. - your test for containment would be faster - O(log2(n)) instead of O(n) Regards, Peter On 04/23/2014 01:48 AM, Brian Burkhalter wrote: > Hello, > > Issue: https://bugs.openjdk.java.net/browse/JDK-8026236 > Patch: http://cr.openjdk.java.net/~bpb/8026236/webrev.00/ > > This test provides a rudimentary verification of isProbablePrime() by: > > 1 - checking that the first 100000 primes are correctly identified as probably prime > 2 - checking that a random sample of positive integers does not reveal non-prime numbers which test as prime > > The test allows for specification of an alternate source file of prime numbers if one wants to run it by hand. The file of primes included in the patch was limited to 100000 values in the interest of keeping the file size small. > > I think that the range of random numbers used for the non-prime portion of the test (currently [0,100000)) needs to be reexamined, but I wanted to throw this out there for discussion as-is. > > I?ve extended the use of the j.u.stream API to the entire test as recommended by Paul in http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021859.html. > > Thanks, > > Brian From omajid at redhat.com Wed Apr 23 14:53:44 2014 From: omajid at redhat.com (Omair Majid) Date: Wed, 23 Apr 2014 10:53:44 -0400 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <533EC7FA.9030700@gmail.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53144E4D.8080606@redhat.com> <20140303190102.GE2045@redhat.com> <533EC7FA.9030700@gmail.com> Message-ID: <20140423145343.GA24358@redhat.com> Hi, * Yasumasa Suenaga [2014-04-04 10:56]: > I've succeeded to make binaries which are contained debuginfo as following: > > http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012037.html > $ make images STRIP_POLICY=no_strip POST_STRIP_CMD="" > > I guess that we should run "make" above options to avoid this issue > in currently. Thanks. I have verified that this works. Sorry about the delay in getting it pushed; I haven't had the time due to the security update and now rawhide being broken due to a GCC 4.9 bump. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From brian.burkhalter at oracle.com Wed Apr 23 15:20:04 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 23 Apr 2014 08:20:04 -0700 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: <5357CE13.8060905@gmail.com> References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> Message-ID: <8A86C77A-2541-468B-AD9A-63C55308098C@oracle.com> Hi Peter, The limitation below is precisely what I referred to in my post in particular with respect to the upper bound of non-primes tested. Thank you for your observations: I will look into the ideas and repost a revised patch later. Regards, Brian On Apr 23, 2014, at 7:28 AM, Peter Levart wrote: > - you could obtain the largest prime number from the set easily (NavigableSet.last()) and use it as the "upperBound" for the range of integers you test. From markt at apache.org Wed Apr 9 23:43:23 2014 From: markt at apache.org (Mark Thomas) Date: Wed, 09 Apr 2014 17:43:23 -0600 Subject: RFR: JDK-8039751: UTF-8 decoder fails to handle some edge cases correctly In-Reply-To: <5345C0F9.8020601@oracle.com> References: <5345C0F9.8020601@oracle.com> Message-ID: <5345DB1B.6080708@apache.org> On 09/04/2014 15:51, Xueming Shen wrote: > Hi, > > Please help review the fix for JDK-8039751. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8039751 > webrev: http://cr.openjdk.java.net/~sherman/8039751/webrev/ > > > This is the corner case (in 4 bytes sequence) we missed when fixing > 7096080 [1]. > The UTF_8 decoder correctly returns the malformed length for some malformed > 4-byte illegal byte sequence (via Decoder.malformedN(...)), but it fails > to do so if > there is no enough (< 4 bytes) bytes in input buffer (via > isMalfromed4_2(...)) > > The proposed change fixes these corner cases. > > Hey Mark, my reading of tomcat's test case suggests "malformed 4-byte > sequence" > is the only thing left after the jdk8 fix, right? Thanks for such a quick response. I agree with your reading of the Tomcat test case. There are two slightly different edge cases here. The first is the one I explained in detail in the bug report where you know from the first two bytes that whatever the next two bytes are, the result is going to be larger than the largest valid code point. The second is where you know from the first two bytes that whatever the next two bytes are, the code point should have been encoded in fewer bytes. If I am reading your additional test cases correctly, you have both of these covered. Many thanks, Mark > > Thanks! > -Sherman > > [1] https://bugs.openjdk.java.net/browse/JDK-7096080 From otaviopolianasantana at gmail.com Thu Apr 17 04:30:31 2014 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Thu, 17 Apr 2014 01:30:31 -0300 Subject: getFirst and getLast on Iterable Message-ID: I would to add for news methods on Iterable, I believe it will helpful for many Java Developers. diff -r 3dd165facde7 test/java/util/Iterator/IteratorDefaults.java --- a/test/java/util/Iterator/IteratorDefaults.java Wed Apr 09 12:26:00 2014 -0700 +++ b/test/java/util/Iterator/IteratorDefaults.java Wed Apr 16 23:25:56 2014 -0300 @@ -399,6 +399,48 @@ } } + public void testgetFirst() { + + List source = Arrays.asList(1, 2, 3, 4); + int first = source.getFirst(); + assertEquals(first, 1); + + List emptySource = Collections.emptyList(); + assertNull(emptySource.getFirst()); + } + + public void testgetFirstWithDefaultElement() { + + List source = Arrays.asList(1, 2, 3, 4); + Integer defaultElement = 5; + assertEquals(source.getFirst(defaultElement), Integer.valueOf(1)); + + List emptySource = Collections.emptyList(); + assertEquals(emptySource.getFirst(defaultElement), defaultElement); + + } + + public void testgetLast() { + + List source = Arrays.asList(1, 2, 3, 4); + int last = source.getLast(); + assertEquals(last, 4); + + List emptySource = Collections.emptyList(); + assertNull(emptySource.getLast()); + } + + public void testgetLastWithDefaultElement() { + + List source = Arrays.asList(1, 2, 3, 4); + Integer defaultElement = 5; + assertEquals(source.getLast(defaultElement), Integer.valueOf(4)); + + List emptySource = Collections.emptyList(); + assertEquals(emptySource.getLast(defaultElement), defaultElement); + + } + static class IteratorWithRemove implements Iterator { public boolean removed; diff -r 3dd165facde7 src/share/classes/java/lang/Iterable.java --- a/src/share/classes/java/lang/Iterable.java Wed Apr 09 12:26:00 2014 -0700 +++ b/src/share/classes/java/lang/Iterable.java Wed Apr 16 23:16:21 2014 -0300 @@ -100,4 +100,55 @@ default Spliterator spliterator() { return Spliterators.spliteratorUnknownSize(iterator(), 0); } + + + /** + * returns the first element, if empty will return {@code null} + * @return the first element or {@code null} + * @since 1.8 + */ + default T getFirst() { + return getFirst(null); + } + + /** + * returns the first element, if empty will return the default + * @param defaultValue - the default value to return if the iterable is empty + * @return the first element or default element + * @since 1.8 + */ + default T getFirst(T defaultValue) { + for (T element : this) { + return element; + } + return defaultValue; + } + + /** + * returns the last element, if empty will return {@code null} + * @return the first element or {@code null} + * @since 1.8 + */ + default T getLast() { + + return getLast(null); + } + + /** + * returns the last element, if empty will return the default + * @param defaultValue - the default value to return if the iterable is empty + * @return the last element or default element + * @since 1.8 + */ + default T getLast(T defaultValue) { + + T last = null; + for (T element : this) { + last = element; + } + if (Objects.isNull(last)) { + return defaultValue; + } + return last; + } } -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From otaviopolianasantana at gmail.com Mon Apr 21 12:58:32 2014 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Mon, 21 Apr 2014 09:58:32 -0300 Subject: Conditions with that always returns true is 'if' necessary? Message-ID: Hello everyone, one question. Conditions that always returns true, is 'if' necessary? I found one. diff -r 57c1da89ae1a src/share/classes/java/lang/invoke/BoundMethodHandle.java --- a/src/share/classes/java/lang/invoke/BoundMethodHandle.java Wed Apr 16 12:32:36 2014 -0700 +++ b/src/share/classes/java/lang/invoke/BoundMethodHandle.java Mon Apr 21 09:50:29 2014 -0300 @@ -66,8 +66,7 @@ try { switch (xtype) { case 'L': - if (true) return bindSingle(type, form, x); // Use known fast path. - return (BoundMethodHandle) SpeciesData.EMPTY.extendWithType('L').constructor[0].invokeBasic(type, form, x); + return bindSingle(type, form, x); // Use known fast path. case 'I': return (BoundMethodHandle) SpeciesData.EMPTY.extendWithType('I').constructor[0].invokeBasic(type, form, ValueConversions.widenSubword(x)); case 'J': -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From otaviopolianasantana at gmail.com Mon Apr 21 23:26:29 2014 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Mon, 21 Apr 2014 20:26:29 -0300 Subject: StringBuilder instead of StringBuffer in java.util package Message-ID: diff -r 57c1da89ae1a src/share/classes/java/util/prefs/Base64.java --- a/src/share/classes/java/util/prefs/Base64.java Wed Apr 16 12:32:36 2014 -0700 +++ b/src/share/classes/java/util/prefs/Base64.java Mon Apr 21 20:20:57 2014 -0300 @@ -57,7 +57,7 @@ int numFullGroups = aLen/3; int numBytesInPartialGroup = aLen - 3*numFullGroups; int resultLen = 4*((aLen + 2)/3); - StringBuffer result = new StringBuffer(resultLen); + StringBuilder result = new StringBuilder(resultLen); char[] intToAlpha = (alternate ? intToAltBase64 : intToBase64); // Translate all full groups from byte array elements to Base64 @@ -259,3 +259,4 @@ } } } + diff -r 57c1da89ae1a src/share/classes/java/util/regex/PatternSyntaxException.java --- a/src/share/classes/java/util/regex/PatternSyntaxException.java Wed Apr 16 12:32:36 2014 -0700 +++ b/src/share/classes/java/util/regex/PatternSyntaxException.java Mon Apr 21 20:21:52 2014 -0300 @@ -105,7 +105,7 @@ * @return The full detail message */ public String getMessage() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append(desc); if (index >= 0) { sb.append(" near index "); @@ -122,3 +122,4 @@ } } + diff -r 57c1da89ae1a src/share/classes/java/util/Properties.java --- a/src/share/classes/java/util/Properties.java Wed Apr 16 12:32:36 2014 -0700 +++ b/src/share/classes/java/util/Properties.java Mon Apr 21 20:22:44 2014 -0300 @@ -602,7 +602,7 @@ if (bufLen < 0) { bufLen = Integer.MAX_VALUE; } - StringBuffer outBuffer = new StringBuffer(bufLen); + StringBuilder outBuffer = new StringBuilder(bufLen); for(int x=0; x References: Message-ID: <5F074FD7-7233-45F1-BAE5-2BD1F61ACFD6@oracle.com> Didn?t we just discuss this like a week ago? http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026506.html On Apr 17, 2014, at 12:30 AM, Ot?vio Gon?alves de Santana wrote: > I would to add for news methods on Iterable, I believe it will helpful for > many Java Developers. > > > diff -r 3dd165facde7 test/java/util/Iterator/IteratorDefaults.java > > --- a/test/java/util/Iterator/IteratorDefaults.java Wed Apr 09 12:26:00 > 2014 -0700 > > +++ b/test/java/util/Iterator/IteratorDefaults.java Wed Apr 16 23:25:56 > 2014 -0300 > > @@ -399,6 +399,48 @@ > > } > > } > > > > + public void testgetFirst() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + int first = source.getFirst(); > > + assertEquals(first, 1); > > + > > + List emptySource = Collections.emptyList(); > > + assertNull(emptySource.getFirst()); > > + } > > + > > + public void testgetFirstWithDefaultElement() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + Integer defaultElement = 5; > > + assertEquals(source.getFirst(defaultElement), Integer.valueOf(1)); > > + > > + List emptySource = Collections.emptyList(); > > + assertEquals(emptySource.getFirst(defaultElement), defaultElement); > > + > > + } > > + > > + public void testgetLast() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + int last = source.getLast(); > > + assertEquals(last, 4); > > + > > + List emptySource = Collections.emptyList(); > > + assertNull(emptySource.getLast()); > > + } > > + > > + public void testgetLastWithDefaultElement() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + Integer defaultElement = 5; > > + assertEquals(source.getLast(defaultElement), Integer.valueOf(4)); > > + > > + List emptySource = Collections.emptyList(); > > + assertEquals(emptySource.getLast(defaultElement), defaultElement); > > + > > + } > > + > > static class IteratorWithRemove implements Iterator { > > > > public boolean removed; > > > > > diff -r 3dd165facde7 src/share/classes/java/lang/Iterable.java > > --- a/src/share/classes/java/lang/Iterable.java Wed Apr 09 12:26:00 2014 > -0700 > > +++ b/src/share/classes/java/lang/Iterable.java Wed Apr 16 23:16:21 2014 > -0300 > > @@ -100,4 +100,55 @@ > > default Spliterator spliterator() { > > return Spliterators.spliteratorUnknownSize(iterator(), 0); > > } > > + > > + > > + /** > > + * returns the first element, if empty will return {@code null} > > + * @return the first element or {@code null} > > + * @since 1.8 > > + */ > > + default T getFirst() { > > + return getFirst(null); > > + } > > + > > + /** > > + * returns the first element, if empty will return the default > > + * @param defaultValue - the default value to return if the iterable > is empty > > + * @return the first element or default element > > + * @since 1.8 > > + */ > > + default T getFirst(T defaultValue) { > > + for (T element : this) { > > + return element; > > + } > > + return defaultValue; > > + } > > + > > + /** > > + * returns the last element, if empty will return {@code null} > > + * @return the first element or {@code null} > > + * @since 1.8 > > + */ > > + default T getLast() { > > + > > + return getLast(null); > > + } > > + > > + /** > > + * returns the last element, if empty will return the default > > + * @param defaultValue - the default value to return if the iterable > is empty > > + * @return the last element or default element > > + * @since 1.8 > > + */ > > + default T getLast(T defaultValue) { > > + > > + T last = null; > > + for (T element : this) { > > + last = element; > > + } > > + if (Objects.isNull(last)) { > > + return defaultValue; > > + } > > + return last; > > + } > > } > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 From otaviopolianasantana at gmail.com Wed Apr 23 18:14:11 2014 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Wed, 23 Apr 2014 15:14:11 -0300 Subject: getFirst and getLast on Iterable In-Reply-To: <5F074FD7-7233-45F1-BAE5-2BD1F61ACFD6@oracle.com> References: <5F074FD7-7233-45F1-BAE5-2BD1F61ACFD6@oracle.com> Message-ID: Yes I did a mistake, please ignore. I sent twice but it had one week as delay. Sorry On Apr 23, 2014 2:01 PM, "Brian Goetz" wrote: > Didn?t we just discuss this like a week ago? > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026506.html > > > > On Apr 17, 2014, at 12:30 AM, Ot?vio Gon?alves de Santana < > otaviopolianasantana at gmail.com> wrote: > > I would to add for news methods on Iterable, I believe it will helpful for > many Java Developers. > > > diff -r 3dd165facde7 test/java/util/Iterator/IteratorDefaults.java > > --- a/test/java/util/Iterator/IteratorDefaults.java Wed Apr 09 12:26:00 > 2014 -0700 > > +++ b/test/java/util/Iterator/IteratorDefaults.java Wed Apr 16 23:25:56 > 2014 -0300 > > @@ -399,6 +399,48 @@ > > } > > } > > > > + public void testgetFirst() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + int first = source.getFirst(); > > + assertEquals(first, 1); > > + > > + List emptySource = Collections.emptyList(); > > + assertNull(emptySource.getFirst()); > > + } > > + > > + public void testgetFirstWithDefaultElement() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + Integer defaultElement = 5; > > + assertEquals(source.getFirst(defaultElement), Integer.valueOf(1)); > > + > > + List emptySource = Collections.emptyList(); > > + assertEquals(emptySource.getFirst(defaultElement), > defaultElement); > > + > > + } > > + > > + public void testgetLast() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + int last = source.getLast(); > > + assertEquals(last, 4); > > + > > + List emptySource = Collections.emptyList(); > > + assertNull(emptySource.getLast()); > > + } > > + > > + public void testgetLastWithDefaultElement() { > > + > > + List source = Arrays.asList(1, 2, 3, 4); > > + Integer defaultElement = 5; > > + assertEquals(source.getLast(defaultElement), Integer.valueOf(4)); > > + > > + List emptySource = Collections.emptyList(); > > + assertEquals(emptySource.getLast(defaultElement), defaultElement); > > + > > + } > > + > > static class IteratorWithRemove implements Iterator { > > > > public boolean removed; > > > > > diff -r 3dd165facde7 src/share/classes/java/lang/Iterable.java > > --- a/src/share/classes/java/lang/Iterable.java Wed Apr 09 12:26:00 2014 > -0700 > > +++ b/src/share/classes/java/lang/Iterable.java Wed Apr 16 23:16:21 2014 > -0300 > > @@ -100,4 +100,55 @@ > > default Spliterator spliterator() { > > return Spliterators.spliteratorUnknownSize(iterator(), 0); > > } > > + > > + > > + /** > > + * returns the first element, if empty will return {@code null} > > + * @return the first element or {@code null} > > + * @since 1.8 > > + */ > > + default T getFirst() { > > + return getFirst(null); > > + } > > + > > + /** > > + * returns the first element, if empty will return the default > > + * @param defaultValue - the default value to return if the iterable > is empty > > + * @return the first element or default element > > + * @since 1.8 > > + */ > > + default T getFirst(T defaultValue) { > > + for (T element : this) { > > + return element; > > + } > > + return defaultValue; > > + } > > + > > + /** > > + * returns the last element, if empty will return {@code null} > > + * @return the first element or {@code null} > > + * @since 1.8 > > + */ > > + default T getLast() { > > + > > + return getLast(null); > > + } > > + > > + /** > > + * returns the last element, if empty will return the default > > + * @param defaultValue - the default value to return if the iterable > is empty > > + * @return the last element or default element > > + * @since 1.8 > > + */ > > + default T getLast(T defaultValue) { > > + > > + T last = null; > > + for (T element : this) { > > + last = element; > > + } > > + if (Objects.isNull(last)) { > > + return defaultValue; > > + } > > + return last; > > + } > > } > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 > > > From sean.mullan at oracle.com Wed Apr 23 20:10:30 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 23 Apr 2014 16:10:30 -0400 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <5356C58D.5070805@oracle.com> References: <5356C58D.5070805@oracle.com> Message-ID: <53581E36.7030004@oracle.com> Just a few comments: 1. When you write a test that uses the jtreg /policy option, the policy file overrides the system policy file. If the test depends on a standard extension, then you may get SecurityExceptions unless additional perms are granted. Thus, there are quite a few tests that define their own policy files and duplicate the grant statement for extensions from the system policy: grant codeBase "file:${{java.ext.dirs}}/*" { permission java.security.AllPermission; } These tests should be modified to only grant the necessary permissions. However, ideally I think that a better solution would be to add a jtreg /policy option that doesn't override the system policy file, but rather appends to it, for example, using "==" : @run main/othervm/policy==test.policy (this is the reverse behavior of the java.security.policy system property, so it might be a little confusing, so maybe it is better to add a new option) 2. test/lib/security/java.policy/Ext_AllPolicy.java I think you should also add a check for AllPermission. 3. jdk/nio/zipfs/ZipFileSystem.java If I understand the changes, the previous code would throw SecurityExceptions when run under a SecurityManager? It's not specifically related to this bug, is it? 4. lib/security/java.policy grant codeBase "file:${java.home}/lib/ext/zipfs.jar" { permission java.io.FilePermission "<>", "read,write,delete"; Hmm, granting that likely means you are just a hop away from getting AllPermission ... not sure what to advise here, but there are several cases like this for certain permissions (ex: RuntimePermission "createClassLoader" is another one). --Sean On 04/22/2014 03:39 PM, Mandy Chung wrote: > This change proposes to remove granting all permissions for extensions > as the default and implements the principle of least privilege.In JDK 9, > we want to reduce the privileges of as many system classes as possible. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.00/ > > This patch has reduced the zipfs, localedata and cldrdata to grant the > permissions they require. It grants AllPermission to other jar files in > the lib/ext directory shipped with JDK and this change is intended to > enable the component teams to identify the minimum permissions and fix > any issue, if any. > > Libraries installed in the extensions directory depending on > AllPermission granted by default are impacted. Making this change as > early in JDK 9 allows us to identify any customer impacted by this change. > > Mandy From mandy.chung at oracle.com Wed Apr 23 21:29:16 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 Apr 2014 14:29:16 -0700 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <53581E36.7030004@oracle.com> References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com> Message-ID: <535830AC.5070003@oracle.com> On 4/23/2014 1:10 PM, Sean Mullan wrote: > Just a few comments: > > 1. When you write a test that uses the jtreg /policy option, the > policy file overrides the system policy file. If the test depends on a > standard extension, then you may get SecurityExceptions unless > additional perms are granted. Thus, there are quite a few tests that > define their own policy files and duplicate the grant statement for > extensions from the system policy: > > grant codeBase "file:${{java.ext.dirs}}/*" { > permission java.security.AllPermission; > } > > These tests should be modified to only grant the necessary > permissions. However, ideally I think that a better solution would be > to add a jtreg /policy option that doesn't override the system policy > file, but rather appends to it, for example, using "==" : > I suspect most of the tests only want to grant the permissions for the test itself rather than overriding the system policy file. Having a new jtreg/policy option not to override the system policy file may be a better solution. This would avoid updating the test's policy file every time the system's policy is modified. On the other hand, I think the test policy may not need to grant permissions to the extensions directory if it doesn't use the classes in extensions. It's a good opportunity to clean that up. This will require some closer look at the tests. If you are okay, I'd like to separate the test's custom policy update as a follow-on work. > @run main/othervm/policy==test.policy > > (this is the reverse behavior of the java.security.policy system > property, so it might be a little confusing, so maybe it is better to > add a new option) > "==" is a confusing syntax. -Djava.security.policy==test.policy overrides the system policy file ("=" prefix) whereas jtreg uses the reverse syntax? I think it would be better to make jtreg/policy consistent with -Djava.security.policy (i.e. default is to extend the system java.security). > 2. test/lib/security/java.policy/Ext_AllPolicy.java > > I think you should also add a check for AllPermission. Will look into it. > > 3. jdk/nio/zipfs/ZipFileSystem.java > > If I understand the changes, the previous code would throw > SecurityExceptions when run under a SecurityManager? It's not > specifically related to this bug, is it? > It's a bug in the zipfs provider and I can file a new JBS issue for the zipfs change. I prefer to push them in the same changeset that reduces zipfs's privileges and added tests to run with security manager. > 4. lib/security/java.policy > > grant codeBase "file:${java.home}/lib/ext/zipfs.jar" { > permission java.io.FilePermission "<>", > "read,write,delete"; > > Hmm, granting that likely means you are just a hop away from getting > AllPermission ... not sure what to advise here, but there are several > cases like this for certain permissions (ex: RuntimePermission > "createClassLoader" is another one). I think we could grant "delete" only to the temp files that zipfs creates as implementation details. I'll let Sherman follow up and fine-tune the permission set. Thanks for the feedback. I'll send an updated webrev that will also have the change for os-specific version of java.policy. Mandy > > --Sean > > On 04/22/2014 03:39 PM, Mandy Chung wrote: >> This change proposes to remove granting all permissions for extensions >> as the default and implements the principle of least privilege.In JDK 9, >> we want to reduce the privileges of as many system classes as possible. >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.00/ >> >> This patch has reduced the zipfs, localedata and cldrdata to grant the >> permissions they require. It grants AllPermission to other jar files in >> the lib/ext directory shipped with JDK and this change is intended to >> enable the component teams to identify the minimum permissions and fix >> any issue, if any. >> >> Libraries installed in the extensions directory depending on >> AllPermission granted by default are impacted. Making this change as >> early in JDK 9 allows us to identify any customer impacted by this >> change. >> >> Mandy From bruno.do.medeiros at gmail.com Wed Apr 23 21:31:34 2014 From: bruno.do.medeiros at gmail.com (Bruno Medeiros) Date: Wed, 23 Apr 2014 22:31:34 +0100 Subject: Thread hangs reading from process output streams, even though process has terminated. (possible JDK bug?) In-Reply-To: References: Message-ID: After exploring this bug when running my full application, I have a lead on what seems to be a necessary condition/cause for it, and possibly a way to create a short reproducible case. The isolated code I posted originally is not enough. Here is what I found out. First lets call the process my Java application starts, process A, the one that terminates, and yet the stream reader threads hang upon. A necessary condition for that bug to happen, is that *another process* is started by the Java application, and similarly some worker threads are spawned to read the streams of that process. Let's call this process B. Process B doesn't not terminate because it is a server program. Here's an interesting bit: if process B is forcibly killed, the reader threads of process A become unstuck! (to be clear the processes are not related. They are not even the same program.) I should be able to reduce this to a short reproducible example, as soon as I have more time. Also, I tried JDK 8, but was not able to reproduce the issue. But given the fickle nature of this bug, it's no guarantee the bug is not present in JDK 8. So I still want to find the cause of this and see it resolved. On Wed, Apr 16, 2014 at 5:23 PM, Bruno Medeiros wrote: > I have some code where I start an external process (ProcessBuilder.start() > ,etc.) and then I spawn two worker threads to read the stdout and stderr of > the external process. I directly read the streams provided by > process.getInputStream() and process.getErrorStream() , I'm not wrapping > them with my own streams or anything. Rather, the worker threads are > calling java.io.InputStream.read(byte[]) in a loop. > > I've encountered a situation, where the worker threads hang despite the > process having been terminated already! > ( Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) , > Windows 7) > > I'm able to caught this whilst running the Java program under the > debugger. I invoked process.exitValue() under the debugger to see if the > JVM has indeed realized the process has terminated. It returned 0, so it > seems it knows the process has terminated. Yet the streams are still > blocked, in a native method: > > The stdout worker thread is stuck here: > Daemon Thread [ExternalProcessEclipseHelper.MainWorker] (Suspended) > owns: BufferedInputStream (id=145) > FileInputStream.readBytes(byte[], int, int) line: not available > [native method] > FileInputStream.read(byte[], int, int) line: 272 > BufferedInputStream.fill() line: 235 > BufferedInputStream.read1(byte[], int, int) line: 275 > BufferedInputStream.read(byte[], int, int) line: 334 > BufferedInputStream(FilterInputStream).read(byte[]) line: 107 > > ExternalProcessNotifyingHelper$1(ExternalProcessHelper$ReadAllBytesTask).doRun() > line: 73 > > The stderr worker thread is similarly stuck : > Daemon Thread [ExternalProcessEclipseHelper.StdErrWorker] (Suspended) > FileInputStream.readBytes(byte[], int, int) line: not available > [native method] > FileInputStream.read(byte[]) line: 243 > > ExternalProcessNotifyingHelper$2(ExternalProcessHelper$ReadAllBytesTask).doRun() > line: 73 > > Could this be a JVM bug? I don't see that this scenario should ever be > happening, unless some other part of my code somehow did some violation and > messed up the JVM state. > > I've added a sample of the relevant code I'm using here: > https://github.com/bruno-medeiros/Scratchpad/tree/jvm-processio-issue > However, I haven't yet been able to replicate this bug using the isolated > code from there. At the moment, I can only replicate it when I run my full > application. The sample code could be simplified further, but I haven't > done it yet since I couldn't replicate the bug using that. > > One interesting bit, is that I can only replicate it when I run the > application for the first time, per computer session. That is, apparently I > need to reboot my computer for the bug to manifest again! > > I'd like to narrow this down, but I would appreciate some help or > suggestions for that. What could affect the JVM, such that subsequent > invocations apparently don't cause the bug? Some code cache issue? I also > wonder if the OSGi runtime could be a factor here. > > -- > Bruno Medeiros > https://twitter.com/brunodomedeiros > -- Bruno Medeiros https://twitter.com/brunodomedeiros From mike.duigou at oracle.com Wed Apr 23 21:35:43 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 23 Apr 2014 14:35:43 -0700 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com> <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com> <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com> <4DC7C9B0-43F2-4FFF-A8D6-CFD1B54ED158@oracle.com> <9CBC797D-F5E2-42CD-B050-A0A706DFDBD4@oracle.com> Message-ID: <7F8B9DAF-5664-4F76-B72A-EC6C1F6DEB92@oracle.com> On Mar 13 2014, at 09:53 , Martin Buchholz wrote: > It's time to add general purpose public static final empty arrays to Arrays.java for Object, all the primitive types, and perhaps also String, instead of local copies scattered around the JDK; then have ArrayList use Arrays.EMPTY_OBJECT_ARRAY. In general I agree though Jason has me all paranoid now about people synchronizing on these shared instances. Mike > > > On Thu, Mar 13, 2014 at 8:56 AM, Jason Mehrens wrote: > Mike, > > The constructor modification looks good. The only other alternative I can think would be to use 'c.toArray(EMPTY_ELEMENTDATA)' to avoid creating an extra array. I'm guessing that version would not perform as well as your current version. > > The modification for toArray violates the List contract because the returned array must be safe (must use 'new' and must not retain reference). I think you'll have to back out that change. Contract violation aside, the only case that I can see that might unsafe for an empty array would be acquiring the monitor of EMPTY_ELEMENTDATA array. When we patched the Collections$EmptyXXX classes we avoided returning a cached empty array for this reason. > > Jason > > Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty > From: mike.duigou at oracle.com > Date: Wed, 12 Mar 2014 12:41:00 -0700 > CC: martinrb at google.com; core-libs-dev at openjdk.java.net > To: jason_mehrens at hotmail.com > > > Hi Jason,' > > Using isEmpty() was intended to save the array creation but you make a valid point regarding correctness. I have amended the webrev. This handling suggests that it would useful for implementation to cache the empty result for toArray() and I have also added this to ArrayList's toArray. > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/3/webrev/ > > Mike > > On Mar 12 2014, at 07:06 , Jason Mehrens wrote: > > Mike, > > In the constructor do you think you should skip the call to isEmpty and just check the length of toArray? Seems like since the implementation of the given collection is unknown it is probably best to perform as little interaction with it as possible. Also it would be possible for isEmpty to return false followed by toArray returning a zero length array that is different from cached copies. > > Jason > > > Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty > > From: mike.duigou at oracle.com > > Date: Tue, 11 Mar 2014 18:18:26 -0700 > > To: martinrb at google.com > > CC: core-libs-dev at openjdk.java.net > > > > > > On Mar 11 2014, at 17:42 , Martin Buchholz wrote: > > > > > I'm hoping y'all have evidence that empty ArrayLists are common in the wild. > > Yes, certainly. From the original proposal: > > > [This change] based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. > > > > > It is curious that empty lists grow immediately to 10, while ArrayList with capacity 1 grows to 2, then 3... Some people might think that a bug. > > Yes, that's unfortunate. I've made another version that uses a second sentinel for the default sized but empty case. > > > > Now I want to reduce the ensureCapacity reallocations! It seems like insane churn to replace the arrays that frequently. > > > There are more   changes that need to be reverted. > > > Else looks good. > > > - * More formally, returns the lowest index i such that > > > - * (o==null ? get(i)==null : o.equals(get(i))), > > > + * More formally, returns the lowest index {@code i} such that > > > + * {@code (o==null ? get(i)==null : o.equals(get(i)))}, > > > > Corrected. Thank you. > > > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ > > > > > > Mike > > > > > > > > > > > > > > > On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou wrote: > > > I've actually always used scp. :-) > > > > > > Since I accepted all of your changes as suggested and had no other changes I was just going to go ahead and push once testing was done. > > > > > > I've now prepared a revised webrev and can still accept feedback. > > > > > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/ > > > > > > (Note: The webrev also contains https://bugs.openjdk.java.net/browse/JDK-8037097 since I am testing/pushing the two issues together.) > > > > > > Mike > > > > > > On Mar 11 2014, at 16:42 , Martin Buchholz wrote: > > > > > >> I don't see the updated webrev. Maybe you also fell victim to "rsync to cr no longer working"? > > >> > > >> > > >> On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote: > > >> > > >> On Feb 21 2014, at 14:56 , Martin Buchholz wrote: > > >> > > >>> You should do -> code conversion separately, and do it pervasively across the entire JDK. > > >> > > >> From your lips to God's ears.... I keep suggesting this along with a restyle to official style every time we create new repos. Seems unlikely unfortunately as it makes backports harder. > > >> > > >>> This is not right. > > >>> + * {@code (o==null ? get(i)==null : o.equals(get(i)))} > > >> > > >> Corrected. > > >> > > >>> You accidentally deleted a stray space here? > > >>> > > >>> - this.elementData = EMPTY_ELEMENTDATA; > > >>> + this.elementData = EMPTY_ELEMENTDATA; > > >> > > >> Corrected. > > >> > > >>> public ArrayList(int initialCapacity) { > > >>> - super(); > > >>> if (initialCapacity < 0) > > >>> throw new IllegalArgumentException("Illegal Capacity: "+ > > >>> initialCapacity); > > >>> - this.elementData = new Object[initialCapacity]; > > >>> + this.elementData = (initialCapacity > 0) > > >>> + ? new Object[initialCapacity] > > >>> + : EMPTY_ELEMENTDATA; > > >>> } > > >>> > > >>> When optimizing for special cases, we should try very hard minimize overhead in the common case. In the above, we now have two branches in the common case. Instead, > > >>> > > >>> if (initialCapacity > 0) this.elementData = new Object[initialCapacity]; > > >>> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; > > >>> else barf > > >> > > >> Corrected. > > >> > > >> Thanks as always for the feedback. > > >> > > >> Mike > > >> > > >>> > > >>> > > >>> > > >>> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote: > > >>> Hello all; > > >>> > > >>> This changeset consists of two small performance improvements for ArrayList. Both are related to the lazy initialization introduced in JDK-8011200. > > >>> > > >>> The first change is in the ArrayList(int capacity) constructor and forces lazy initialization if the requested capacity is zero. It's been observed that in cases where zero capacity is requested that it is very likely that the list never receives any elements. For these cases we permanently avoid the allocation of an element array. > > >>> > > >>> The second change, noticed by Gustav ?kesson, involves the ArrayList(Collection c) constructor. If c is an empty collection then there is no reason to inflate the backing array for the ArrayList. > > >>> > > >>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ > > >>> > > >>> I also took the opportunity to the -> {@code } conversion for the javadoc. > > >>> > > >>> Enjoy! > > >>> > > >>> Mike > > >>> > > >> > > >> > > > > > > > > > > From mike.duigou at oracle.com Wed Apr 23 21:35:52 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 23 Apr 2014 14:35:52 -0700 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com>, , <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com>, , <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com>, , <4DC7C9B0-43F2-4FFF-A8D6-CFD1B54ED158@oracle.com> , <9CBC797D-F5E2-42CD-B050-A0A706DFDBD4@oracle.com> Message-ID: <5140680D-393D-4615-B9F4-E2D8BC8ED016@oracle.com> On Mar 13 2014, at 08:56 , Jason Mehrens wrote: > Mike, > > The constructor modification looks good. The only other alternative I can think would be to use 'c.toArray(EMPTY_ELEMENTDATA)' to avoid creating an extra array. I'm guessing that version would not perform as well as your current version. Good idea, but you're also correct that it didn't perform as well (for either Arrays.ArrayList or ArrayList itself) > > The modification for toArray violates the List contract because the returned array must be safe (must use 'new' and must not retain reference). I think you'll have to back out that change. Contract violation aside, the only case that I can see that might unsafe for an empty array would be acquiring the monitor of EMPTY_ELEMENTDATA array. When we patched the Collections$EmptyXXX classes we avoided returning a cached empty array for this reason. You are of course correct. Yet another reminder to avoid unnecessary promises when creating specifications. The Collection.toArray() javadoc could have been written to allow for a shared empty array but isn't and can't be changed to be allow for this. We did eliminate the requirement to return a "new" instance some cases for String/CharSequence/StringBuilder/StringBuffer in https://bugs.openjdk.java.net/browse/JDK-7174936 and https://bugs.openjdk.java.net/browse/JDK-8028757 that were similar to this but those changes for the most part were to sync the javadoc to the longstanding actual behaviour. Mike > > Jason > > Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty > From: mike.duigou at oracle.com > Date: Wed, 12 Mar 2014 12:41:00 -0700 > CC: martinrb at google.com; core-libs-dev at openjdk.java.net > To: jason_mehrens at hotmail.com > > Hi Jason,' > > Using isEmpty() was intended to save the array creation but you make a valid point regarding correctness. I have amended the webrev. This handling suggests that it would useful for implementation to cache the empty result for toArray() and I have also added this to ArrayList's toArray. > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/3/webrev/ > > Mike > > On Mar 12 2014, at 07:06 , Jason Mehrens wrote: > > Mike, > > In the constructor do you think you should skip the call to isEmpty and just check the length of toArray? Seems like since the implementation of the given collection is unknown it is probably best to perform as little interaction with it as possible. Also it would be possible for isEmpty to return false followed by toArray returning a zero length array that is different from cached copies. > > Jason > > > Subject: Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty > > From: mike.duigou at oracle.com > > Date: Tue, 11 Mar 2014 18:18:26 -0700 > > To: martinrb at google.com > > CC: core-libs-dev at openjdk.java.net > > > > > > On Mar 11 2014, at 17:42 , Martin Buchholz wrote: > > > > > I'm hoping y'all have evidence that empty ArrayLists are common in the wild. > > Yes, certainly. From the original proposal: > > > [This change] based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. > > > > > It is curious that empty lists grow immediately to 10, while ArrayList with capacity 1 grows to 2, then 3... Some people might think that a bug. > > Yes, that's unfortunate. I've made another version that uses a second sentinel for the default sized but empty case. > > > > Now I want to reduce the ensureCapacity reallocations! It seems like insane churn to replace the arrays that frequently. > > > There are more   changes that need to be reverted. > > > Else looks good. > > > - * More formally, returns the lowest index i such that > > > - * (o==null ? get(i)==null : o.equals(get(i))), > > > + * More formally, returns the lowest index {@code i} such that > > > + * {@code (o==null ? get(i)==null : o.equals(get(i)))}, > > > > Corrected. Thank you. > > > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ > > > > > > Mike > > > > > > > > > > > > > > > On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou wrote: > > > I've actually always used scp. :-) > > > > > > Since I accepted all of your changes as suggested and had no other changes I was just going to go ahead and push once testing was done. > > > > > > I've now prepared a revised webrev and can still accept feedback. > > > > > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/1/webrev/ > > > > > > (Note: The webrev also contains https://bugs.openjdk.java.net/browse/JDK-8037097 since I am testing/pushing the two issues together.) > > > > > > Mike > > > > > > On Mar 11 2014, at 16:42 , Martin Buchholz wrote: > > > > > >> I don't see the updated webrev. Maybe you also fell victim to "rsync to cr no longer working"? > > >> > > >> > > >> On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote: > > >> > > >> On Feb 21 2014, at 14:56 , Martin Buchholz wrote: > > >> > > >>> You should do -> code conversion separately, and do it pervasively across the entire JDK. > > >> > > >> From your lips to God's ears.... I keep suggesting this along with a restyle to official style every time we create new repos. Seems unlikely unfortunately as it makes backports harder. > > >> > > >>> This is not right. > > >>> + * {@code (o==null ? get(i)==null : o.equals(get(i)))} > > >> > > >> Corrected. > > >> > > >>> You accidentally deleted a stray space here? > > >>> > > >>> - this.elementData = EMPTY_ELEMENTDATA; > > >>> + this.elementData = EMPTY_ELEMENTDATA; > > >> > > >> Corrected. > > >> > > >>> public ArrayList(int initialCapacity) { > > >>> - super(); > > >>> if (initialCapacity < 0) > > >>> throw new IllegalArgumentException("Illegal Capacity: "+ > > >>> initialCapacity); > > >>> - this.elementData = new Object[initialCapacity]; > > >>> + this.elementData = (initialCapacity > 0) > > >>> + ? new Object[initialCapacity] > > >>> + : EMPTY_ELEMENTDATA; > > >>> } > > >>> > > >>> When optimizing for special cases, we should try very hard minimize overhead in the common case. In the above, we now have two branches in the common case. Instead, > > >>> > > >>> if (initialCapacity > 0) this.elementData = new Object[initialCapacity]; > > >>> else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; > > >>> else barf > > >> > > >> Corrected. > > >> > > >> Thanks as always for the feedback. > > >> > > >> Mike > > >> > > >>> > > >>> > > >>> > > >>> On Fri, Feb 21, 2014 at 2:41 PM, Mike Duigou wrote: > > >>> Hello all; > > >>> > > >>> This changeset consists of two small performance improvements for ArrayList. Both are related to the lazy initialization introduced in JDK-8011200. > > >>> > > >>> The first change is in the ArrayList(int capacity) constructor and forces lazy initialization if the requested capacity is zero. It's been observed that in cases where zero capacity is requested that it is very likely that the list never receives any elements. For these cases we permanently avoid the allocation of an element array. > > >>> > > >>> The second change, noticed by Gustav ?kesson, involves the ArrayList(Collection c) constructor. If c is an empty collection then there is no reason to inflate the backing array for the ArrayList. > > >>> > > >>> http://cr.openjdk.java.net/~mduigou/JDK-8035584/0/webrev/ > > >>> > > >>> I also took the opportunity to the -> {@code } conversion for the javadoc. > > >>> > > >>> Enjoy! > > >>> > > >>> Mike > > >>> > > >> > > >> > > > > > > > > > From mike.duigou at oracle.com Wed Apr 23 22:33:48 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 23 Apr 2014 15:33:48 -0700 Subject: RFR: 8035584 : (s) ArrayList(c) should avoid inflation if c is empty Message-ID: <93BA31AB-56DC-457A-9D1A-41F6AC0BA8B9@oracle.com> Hello all; Revisiting this issue again at long last I have updated the proposed changeset based upon Jason Mehren's most recent feedback. http://cr.openjdk.java.net/~mduigou/JDK-8035584/4/webrev/ This version reverts the prior changes to toArray(). Mike From martinrb at google.com Wed Apr 23 23:16:38 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 23 Apr 2014 16:16:38 -0700 Subject: Thread hangs reading from process output streams, even though process has terminated. (possible JDK bug?) In-Reply-To: References: Message-ID: Very high level: Ensuring that streams get EOF when subprocesses terminate is very tricky, and we did a bunch of work on Linux and Solaris to try to make it reliable. And even now we're not quite there - If grandchildren linger, they might keep file descriptors open. I'm not aware of similar problems on Windows, but it's not at all surprising if the same kinds of effects are seen. On Wed, Apr 23, 2014 at 2:31 PM, Bruno Medeiros wrote: > After exploring this bug when running my full application, I have a lead on > what seems to be a necessary condition/cause for it, and possibly a way to > create a short reproducible case. The isolated code I posted originally is > not enough. > > Here is what I found out. First lets call the process my Java application > starts, process A, the one that terminates, and yet the stream reader > threads hang upon. > A necessary condition for that bug to happen, is that *another process* is > started by the Java application, and similarly some worker threads are > spawned to read the streams of that process. Let's call this process B. > Process B doesn't not terminate because it is a server program. > Here's an interesting bit: if process B is forcibly killed, the reader > threads of process A become unstuck! (to be clear the processes are not > related. They are not even the same program.) > I should be able to reduce this to a short reproducible example, as soon as > I have more time. > > Also, I tried JDK 8, but was not able to reproduce the issue. But given the > fickle nature of this bug, it's no guarantee the bug is not present in JDK > 8. So I still want to find the cause of this and see it resolved. > > > > On Wed, Apr 16, 2014 at 5:23 PM, Bruno Medeiros < > bruno.do.medeiros at gmail.com > > wrote: > > > I have some code where I start an external process > (ProcessBuilder.start() > > ,etc.) and then I spawn two worker threads to read the stdout and stderr > of > > the external process. I directly read the streams provided by > > process.getInputStream() and process.getErrorStream() , I'm not wrapping > > them with my own streams or anything. Rather, the worker threads are > > calling java.io.InputStream.read(byte[]) in a loop. > > > > I've encountered a situation, where the worker threads hang despite the > > process having been terminated already! > > ( Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) , > > Windows 7) > > > > I'm able to caught this whilst running the Java program under the > > debugger. I invoked process.exitValue() under the debugger to see if the > > JVM has indeed realized the process has terminated. It returned 0, so it > > seems it knows the process has terminated. Yet the streams are still > > blocked, in a native method: > > > > The stdout worker thread is stuck here: > > Daemon Thread [ExternalProcessEclipseHelper.MainWorker] (Suspended) > > owns: BufferedInputStream (id=145) > > FileInputStream.readBytes(byte[], int, int) line: not available > > [native method] > > FileInputStream.read(byte[], int, int) line: 272 > > BufferedInputStream.fill() line: 235 > > BufferedInputStream.read1(byte[], int, int) line: 275 > > BufferedInputStream.read(byte[], int, int) line: 334 > > BufferedInputStream(FilterInputStream).read(byte[]) line: 107 > > > > > ExternalProcessNotifyingHelper$1(ExternalProcessHelper$ReadAllBytesTask).doRun() > > line: 73 > > > > The stderr worker thread is similarly stuck : > > Daemon Thread [ExternalProcessEclipseHelper.StdErrWorker] (Suspended) > > FileInputStream.readBytes(byte[], int, int) line: not available > > [native method] > > FileInputStream.read(byte[]) line: 243 > > > > > ExternalProcessNotifyingHelper$2(ExternalProcessHelper$ReadAllBytesTask).doRun() > > line: 73 > > > > Could this be a JVM bug? I don't see that this scenario should ever be > > happening, unless some other part of my code somehow did some violation > and > > messed up the JVM state. > > > > I've added a sample of the relevant code I'm using here: > > https://github.com/bruno-medeiros/Scratchpad/tree/jvm-processio-issue > > However, I haven't yet been able to replicate this bug using the isolated > > code from there. At the moment, I can only replicate it when I run my > full > > application. The sample code could be simplified further, but I haven't > > done it yet since I couldn't replicate the bug using that. > > > > One interesting bit, is that I can only replicate it when I run the > > application for the first time, per computer session. That is, > apparently I > > need to reboot my computer for the bug to manifest again! > > > > I'd like to narrow this down, but I would appreciate some help or > > suggestions for that. What could affect the JVM, such that subsequent > > invocations apparently don't cause the bug? Some code cache issue? I also > > wonder if the OSGi runtime could be a factor here. > > > > -- > > Bruno Medeiros > > https://twitter.com/brunodomedeiros > > > > > > -- > Bruno Medeiros > https://twitter.com/brunodomedeiros > From mike.duigou at oracle.com Thu Apr 24 02:24:00 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 23 Apr 2014 19:24:00 -0700 Subject: pre-RFR : 8022854: (s) System.setProperties(null) causes implementation private properties to reappear Message-ID: <0FAC9688-CABD-413E-9456-89C102982EC5@oracle.com> At long last I got back to this issue and discovered that there are some lurking issues with property reinitialization. I've created a couple of bugs for some of the shortcomings I discovered. None of these are caused by this changeset. I would like to hold off completing this issue until we decide what to do with the other issues. https://bugs.openjdk.java.net/browse/JDK-8041674 user.timezone property not initialized after System.setProperties(null) https://bugs.openjdk.java.net/browse/JDK-8041675 java.vm.info not correctly reinitialized after System.setProperties(null) https://bugs.openjdk.java.net/browse/JDK-8041676 java.compiler property is uninitialized Here's the current webrev for this issue with the expanded test: http://cr.openjdk.java.net/~mduigou/JDK-8022854/2/webrev/ Mike From zhong.j.yu at gmail.com Thu Apr 24 05:06:30 2014 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Thu, 24 Apr 2014 00:06:30 -0500 Subject: Creating Thread in AccessController.doPrivileged() Message-ID: If a thread is created inside AccessController.doPrivileged(), it seems to inherit AccessControlContext from the calling thread, is that the expected/specified behavior? I'm asking because I tried to solve this problem: A spawned Thread contains strong references to all call stack class loaders through Thread.inheritedAccessControlContext. I try to avoid that and make sure that only the immediate caller class loader is referenced; my concern is rather garbage collection than permissions. Is there anyway to achieve that? Thanks, Zhong Yu From zhong.j.yu at gmail.com Thu Apr 24 06:53:29 2014 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Thu, 24 Apr 2014 01:53:29 -0500 Subject: Creating Thread in AccessController.doPrivileged() In-Reply-To: References: Message-ID: On Thu, Apr 24, 2014 at 12:06 AM, Zhong Yu wrote: > If a thread is created inside AccessController.doPrivileged(), it > seems to inherit AccessControlContext from the calling thread, sorry, I was mistaken; there is no such inheritance, the new thread is indeed privileged. > is that > the expected/specified behavior? > > I'm asking because I tried to solve this problem: A spawned Thread > contains strong references to all call stack class loaders through > Thread.inheritedAccessControlContext. I try to avoid that and make > sure that only the immediate caller class loader is referenced; my > concern is rather garbage collection than permissions. Is there anyway > to achieve that? > > Thanks, > Zhong Yu From peter.levart at gmail.com Thu Apr 24 07:24:21 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 24 Apr 2014 09:24:21 +0200 Subject: RFR [8040806]: BitSet.toString() can throw IndexOutOfBoundsException In-Reply-To: <53565D04.7010905@oracle.com> References: <53565D04.7010905@oracle.com> Message-ID: <5358BC25.7050601@gmail.com> Hi Ivan, This fix could be called: Leaving on the edge - A tricky game of overflows :-) I think the fix is good. In the test it would be nice to include the IndexOutOfBoundsException in the failure message to ease debugging. Regards, Peter On 04/22/2014 02:13 PM, Ivan Gerasimov wrote: > Hello! > > If a BitSet has the bit Integer.MAX_VALUE set, then calling toString() > will throw an exception. > The same thing happens if the bit (Integer.MAX_VALUE-1) is set. > > Would you please help review the fix for this issue? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040806 > WEBREV: http://cr.openjdk.java.net/~igerasim/8040806/0/webrev/ > > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Thu Apr 24 09:44:24 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 24 Apr 2014 13:44:24 +0400 Subject: RFR [8040806]: BitSet.toString() can throw IndexOutOfBoundsException In-Reply-To: <5358BC25.7050601@gmail.com> References: <53565D04.7010905@oracle.com> <5358BC25.7050601@gmail.com> Message-ID: <5358DCF8.6000401@oracle.com> Thanks Peter! The test was designed to be laconic, so I tried to keep it this way. I can, of course, include the mentioning of the exception in the message. With the bug fixed it's not going to be shown anyway :) Sincerely yours, Ivan On 24.04.2014 11:24, Peter Levart wrote: > Hi Ivan, > > This fix could be called: Leaving on the edge - A tricky game of > overflows :-) > > I think the fix is good. In the test it would be nice to include the > IndexOutOfBoundsException in the failure message to ease debugging. > > Regards, Peter > > On 04/22/2014 02:13 PM, Ivan Gerasimov wrote: >> Hello! >> >> If a BitSet has the bit Integer.MAX_VALUE set, then calling >> toString() will throw an exception. >> The same thing happens if the bit (Integer.MAX_VALUE-1) is set. >> >> Would you please help review the fix for this issue? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040806 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8040806/0/webrev/ >> >> Sincerely yours, >> Ivan > > > From sean.mullan at oracle.com Thu Apr 24 18:32:58 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 24 Apr 2014 14:32:58 -0400 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <535830AC.5070003@oracle.com> References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com> <535830AC.5070003@oracle.com> Message-ID: <535958DA.2010307@oracle.com> On 04/23/2014 05:29 PM, Mandy Chung wrote: > > On 4/23/2014 1:10 PM, Sean Mullan wrote: >> Just a few comments: >> >> 1. When you write a test that uses the jtreg /policy option, the >> policy file overrides the system policy file. If the test depends on a >> standard extension, then you may get SecurityExceptions unless >> additional perms are granted. Thus, there are quite a few tests that >> define their own policy files and duplicate the grant statement for >> extensions from the system policy: >> >> grant codeBase "file:${{java.ext.dirs}}/*" { >> permission java.security.AllPermission; >> } >> >> These tests should be modified to only grant the necessary >> permissions. However, ideally I think that a better solution would be >> to add a jtreg /policy option that doesn't override the system policy >> file, but rather appends to it, for example, using "==" : >> > > I suspect most of the tests only want to grant the permissions for the > test itself rather than overriding the system policy file. Having a new > jtreg/policy option not to override the system policy file may be a > better solution. This would avoid updating the test's policy file > every time the system's policy is modified. On the other hand, I think > the test policy may not need to grant permissions to the extensions > directory if it doesn't use the classes in extensions. It's a good > opportunity to clean that up. This will require some closer look at the > tests. > > If you are okay, I'd like to separate the test's custom policy update as > a follow-on work. That's fine with me. >> @run main/othervm/policy==test.policy >> >> (this is the reverse behavior of the java.security.policy system >> property, so it might be a little confusing, so maybe it is better to >> add a new option) >> > > "==" is a confusing syntax. -Djava.security.policy==test.policy > overrides the system policy file ("=" prefix) whereas jtreg uses the > reverse syntax? I think it would be better to make jtreg/policy > consistent with -Djava.security.policy (i.e. default is to extend the > system java.security). Would be nice, but not sure if we can change it at this point. Anyway, one of us should file a jtreg RFE. >> 3. jdk/nio/zipfs/ZipFileSystem.java >> >> If I understand the changes, the previous code would throw >> SecurityExceptions when run under a SecurityManager? It's not >> specifically related to this bug, is it? >> > > It's a bug in the zipfs provider and I can file a new JBS issue for the > zipfs change. I prefer to push them in the same changeset that reduces > zipfs's privileges and added tests to run with security manager. Sure, it is fine with me to include them with this. I just wanted to make sure I understood the changes. --Sean From mandy.chung at oracle.com Thu Apr 24 23:07:30 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Apr 2014 16:07:30 -0700 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <535958DA.2010307@oracle.com> References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com> <535830AC.5070003@oracle.com> <535958DA.2010307@oracle.com> Message-ID: <53599932.4090307@oracle.com> Thanks Sean. I have updated the webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/ Erik - I'm including build-dev to review the build change for java.policy file. Thanks Mandy On 4/24/14 11:32 AM, Sean Mullan wrote: > On 04/23/2014 05:29 PM, Mandy Chung wrote: >> >> On 4/23/2014 1:10 PM, Sean Mullan wrote: >>> Just a few comments: >>> >>> 1. When you write a test that uses the jtreg /policy option, the >>> policy file overrides the system policy file. If the test depends on a >>> standard extension, then you may get SecurityExceptions unless >>> additional perms are granted. Thus, there are quite a few tests that >>> define their own policy files and duplicate the grant statement for >>> extensions from the system policy: >>> >>> grant codeBase "file:${{java.ext.dirs}}/*" { >>> permission java.security.AllPermission; >>> } >>> >>> These tests should be modified to only grant the necessary >>> permissions. However, ideally I think that a better solution would be >>> to add a jtreg /policy option that doesn't override the system policy >>> file, but rather appends to it, for example, using "==" : >>> >> >> I suspect most of the tests only want to grant the permissions for the >> test itself rather than overriding the system policy file. Having a new >> jtreg/policy option not to override the system policy file may be a >> better solution. This would avoid updating the test's policy file >> every time the system's policy is modified. On the other hand, I think >> the test policy may not need to grant permissions to the extensions >> directory if it doesn't use the classes in extensions. It's a good >> opportunity to clean that up. This will require some closer look at the >> tests. >> >> If you are okay, I'd like to separate the test's custom policy update as >> a follow-on work. > > That's fine with me. > >>> @run main/othervm/policy==test.policy >>> >>> (this is the reverse behavior of the java.security.policy system >>> property, so it might be a little confusing, so maybe it is better to >>> add a new option) >>> >> >> "==" is a confusing syntax. -Djava.security.policy==test.policy >> overrides the system policy file ("=" prefix) whereas jtreg uses the >> reverse syntax? I think it would be better to make jtreg/policy >> consistent with -Djava.security.policy (i.e. default is to extend the >> system java.security). > > Would be nice, but not sure if we can change it at this point. Anyway, > one of us should file a jtreg RFE. > >>> 3. jdk/nio/zipfs/ZipFileSystem.java >>> >>> If I understand the changes, the previous code would throw >>> SecurityExceptions when run under a SecurityManager? It's not >>> specifically related to this bug, is it? >>> >> >> It's a bug in the zipfs provider and I can file a new JBS issue for the >> zipfs change. I prefer to push them in the same changeset that reduces >> zipfs's privileges and added tests to run with security manager. > > Sure, it is fine with me to include them with this. I just wanted to > make sure I understood the changes. > > --Sean From brian.burkhalter at oracle.com Fri Apr 25 00:12:53 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 24 Apr 2014 17:12:53 -0700 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: <5357CE13.8060905@gmail.com> References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> Message-ID: Hello, I have posted an updated patch here: http://cr.openjdk.java.net/~bpb/8026236/webrev.01/ Thanks for your comments. Brian On Apr 23, 2014, at 7:28 AM, Peter Levart wrote: > Hi Brian, > > There seems to be a confusion between "upperBound" and the 1st "n" primer numbers. You pass "upperBound" as the parameter "n" of the parsePrimes() method which returns 1st "n" primes from the file (it can return less primes if the file is smaller). > > I suggest doing the following: > - make parsePrimes() take "n" as it does and return 1st "n" primes from the file, but collect them into a NavigableSet (TreeSet) like that: > > private static NavigableSet parsePrimes(File f, long n) throws IOException { > GZIPInputStream gis = new GZIPInputStream(new FileInputStream(f)); > BufferedReader br = new BufferedReader(new InputStreamReader(gis)); > try (Stream lines = br.lines()) { > return lines.limit(n).map(BigInteger::new).collect(toCollection(TreeSet::new)); > } > } > > This would serve two purposes: > - you could obtain the largest prime number from the set easily (NavigableSet.last()) and use it as the "upperBound" for the range of integers you test. > - your test for containment would be faster - O(log2(n)) instead of O(n) > > Regards, Peter > > On 04/23/2014 01:48 AM, Brian Burkhalter wrote: >> Hello, >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8026236 >> Patch: http://cr.openjdk.java.net/~bpb/8026236/webrev.00/ >> >> This test provides a rudimentary verification of isProbablePrime() by: >> >> 1 - checking that the first 100000 primes are correctly identified as probably prime >> 2 - checking that a random sample of positive integers does not reveal non-prime numbers which test as prime >> >> The test allows for specification of an alternate source file of prime numbers if one wants to run it by hand. The file of primes included in the patch was limited to 100000 values in the interest of keeping the file size small. >> >> I think that the range of random numbers used for the non-prime portion of the test (currently [0,100000)) needs to be reexamined, but I wanted to throw this out there for discussion as-is. >> >> I?ve extended the use of the j.u.stream API to the entire test as recommended by Paul in http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021859.html. >> >> Thanks, >> >> Brian > From erik.joelsson at oracle.com Fri Apr 25 07:55:45 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 Apr 2014 09:55:45 +0200 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <53599932.4090307@oracle.com> References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com> <535830AC.5070003@oracle.com> <535958DA.2010307@oracle.com> <53599932.4090307@oracle.com> Message-ID: <535A1501.20500@oracle.com> Hello Mandy, The logic looks fine. Just some style issues. I would like indentation for the conditionals to be 2 spaces as is currently the standard in the makefiles. I would also like to have POLICY_SRC_LIST to be declared empty with := instead of just =. We only use = assignment when explicitly needed. /Erik On 2014-04-25 01:07, Mandy Chung wrote: > Thanks Sean. > > I have updated the webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/ > > Erik - I'm including build-dev to review the build change for > java.policy file. > > Thanks > Mandy > > On 4/24/14 11:32 AM, Sean Mullan wrote: >> On 04/23/2014 05:29 PM, Mandy Chung wrote: >>> >>> On 4/23/2014 1:10 PM, Sean Mullan wrote: >>>> Just a few comments: >>>> >>>> 1. When you write a test that uses the jtreg /policy option, the >>>> policy file overrides the system policy file. If the test depends on a >>>> standard extension, then you may get SecurityExceptions unless >>>> additional perms are granted. Thus, there are quite a few tests that >>>> define their own policy files and duplicate the grant statement for >>>> extensions from the system policy: >>>> >>>> grant codeBase "file:${{java.ext.dirs}}/*" { >>>> permission java.security.AllPermission; >>>> } >>>> >>>> These tests should be modified to only grant the necessary >>>> permissions. However, ideally I think that a better solution would be >>>> to add a jtreg /policy option that doesn't override the system policy >>>> file, but rather appends to it, for example, using "==" : >>>> >>> >>> I suspect most of the tests only want to grant the permissions for the >>> test itself rather than overriding the system policy file. Having a new >>> jtreg/policy option not to override the system policy file may be a >>> better solution. This would avoid updating the test's policy file >>> every time the system's policy is modified. On the other hand, I >>> think >>> the test policy may not need to grant permissions to the extensions >>> directory if it doesn't use the classes in extensions. It's a good >>> opportunity to clean that up. This will require some closer look at the >>> tests. >>> >>> If you are okay, I'd like to separate the test's custom policy >>> update as >>> a follow-on work. >> >> That's fine with me. >> >>>> @run main/othervm/policy==test.policy >>>> >>>> (this is the reverse behavior of the java.security.policy system >>>> property, so it might be a little confusing, so maybe it is better to >>>> add a new option) >>>> >>> >>> "==" is a confusing syntax. -Djava.security.policy==test.policy >>> overrides the system policy file ("=" prefix) whereas jtreg uses the >>> reverse syntax? I think it would be better to make jtreg/policy >>> consistent with -Djava.security.policy (i.e. default is to extend the >>> system java.security). >> >> Would be nice, but not sure if we can change it at this point. >> Anyway, one of us should file a jtreg RFE. >> >>>> 3. jdk/nio/zipfs/ZipFileSystem.java >>>> >>>> If I understand the changes, the previous code would throw >>>> SecurityExceptions when run under a SecurityManager? It's not >>>> specifically related to this bug, is it? >>>> >>> >>> It's a bug in the zipfs provider and I can file a new JBS issue for the >>> zipfs change. I prefer to push them in the same changeset that reduces >>> zipfs's privileges and added tests to run with security manager. >> >> Sure, it is fine with me to include them with this. I just wanted to >> make sure I understood the changes. >> >> --Sean > From peter.levart at gmail.com Fri Apr 25 10:04:34 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Apr 2014 12:04:34 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> Message-ID: <535A3332.4070909@gmail.com> This is a ping for any Reviewer and also a question for Vladimir. Hello Vladimir, What do you think about the classloader issue in the resolving of classes in MemberName.getMethodType() described below? Regards, Peter On 04/23/2014 04:21 PM, Paul Sandoz wrote: > Hi Peter, > > IMHO such security manager usage by the test is v. fragile and we should try and find a safer alternative if possible. > > However, there may also be an issue with lambda form code. (About a month ago i too was looking, internally, at this kind of issue and thought there was a questionable use of the application/system class loader when initializing the LambdaForm class, but then i got distracted with other stuff and forgot about it.) > > Your one-liner fix seems to do the trick, but I think we need Vladimir to confirm this is OK. > > Paul. > > On Apr 17, 2014, at 11:49 PM, Peter Levart wrote: > >> Hi, >> >> I'm cross-posting this on the mlvm-dev mailing list, because I think it concerns internal MHs implementation. >> >> While replacing some inner classes with lambdas in java.lang.UNIXProcess class, a jtreg test started failing. This test is employing a security manager with an unusual configuration. It defines "java.util" as a package for which access should be checked against the set of permissions. The class initialization of UNIXProcess class initializes some lambdas and their initialization fails with the following stack-trace: >> >> >> java.lang.ExceptionInInitializerError >> at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:256) >> at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:221) >> at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:210) >> at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:82) >> at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1638) >> at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1602) >> at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1778) >> at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1727) >> at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:442) >> at java.lang.UNIXProcess$Platform.get(UNIXProcess.java:147) >> at java.lang.UNIXProcess.(UNIXProcess.java:160) >> at java.lang.ProcessImpl.start(ProcessImpl.java:130) >> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1023) >> at java.lang.Runtime.exec(Runtime.java:620) >> at java.lang.Runtime.exec(Runtime.java:485) >> at SecurityManagerClinit.main(SecurityManagerClinit.java:70) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:484) >> at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) >> at java.lang.Thread.run(Thread.java:744) >> Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.java.util") >> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) >> at java.security.AccessController.checkPermission(AccessController.java:884) >> at java.lang.SecurityManager.checkPermission(SecurityManager.java:541) >> at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1481) >> * at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305)* >> at java.lang.ClassLoader.loadClass(ClassLoader.java:359) >> at sun.invoke.util.BytecodeDescriptor.parseSig(BytecodeDescriptor.java:83) >> * at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:54)* >> at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:41) >> at java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:911) >> at java.lang.invoke.MemberName.getMethodType(MemberName.java:144) >> at java.lang.invoke.LambdaForm.computeInitialPreparedForms(LambdaForm.java:477) >> at java.lang.invoke.LambdaForm.(LambdaForm.java:1641) >> >> >> I think I found the root cause of the problem. It's nothing wrong with the test (although making "java.util" as an access-checked package is a little unusual). The problem, I think, is in MH's LambdaForm implementation. Although the UNIXProcess class is a system class (loaded by bootstrap class loader), MHs created by evaluating lambda expressions in this class, trigger loading a class in "java.util" package using AppClassLoader as the initiating class loader, which involves package access checks. This should not happen, I think, if only the system classes are involved in constructing MHs. >> >> I checked the code and there's a ClassLoader parameter passed to the *BytecodeDescriptor.parseMethod *method. This ClassLoader is taken as the defining class loader of the MemberName's declaring class for which the getMethoType() is requested. All the types involved in such MemberName (return type, parameter types) should be resolvable from the MemberName's declaring class' class loader. In our case, the class loader of the declaring class of the particular MemberName is bootstrap class loader, so null is passed as the ClassLoader parameter to the *BytecodeDescriptor.parseMethod *method. This method checks for null ClassLoader and replaces it with ClassLoader.getSystemClassLoader() before calling parseSig() with it, because parseSig() uses the ClassLoader instance to invoke loadClass() method on it. The ClassLoader.getSystemClassLoader() is the application class-loader (AppClassLoader). >> >> I think the right thing to do would be to use bootstrap class loader if the ClassLoader parameter passed to *BytecodeDescriptor.parseMethod *was null. The fix would be as follows: >> >> >> =================================================================== >> --- jdk/src/share/classes/sun/invoke/util/BytecodeDescriptor.java (revision 9770:8371276d52c0) >> +++ jdk/src/share/classes/sun/invoke/util/BytecodeDescriptor.java (revision 9770+:8371276d52c0+) >> @@ -43,8 +43,6 @@ >> >> static List> parseMethod(String bytecodeSignature, >> int start, int end, ClassLoader loader) { >> - if (loader == null) >> - loader = ClassLoader.getSystemClassLoader(); >> String str = bytecodeSignature; >> int[] i = {start}; >> ArrayList> ptypes = new ArrayList>(); >> @@ -80,7 +78,7 @@ >> i[0] = endc+1; >> String name = str.substring(begc, endc).replace('/', '.'); >> try { >> - return loader.loadClass(name); >> + return Class.forName(name, false, loader); >> } catch (ClassNotFoundException ex) { >> throw new TypeNotPresentException(name, ex); >> } >> >> >> >> What do you think? Am I right? >> >> >> Regards, Peter From paul.sandoz at oracle.com Fri Apr 25 10:44:23 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 25 Apr 2014 12:44:23 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <535A3332.4070909@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> Message-ID: On Apr 25, 2014, at 12:04 PM, Peter Levart wrote: > This is a ping for any Reviewer and also a question for Vladimir. > > Hello Vladimir, > > What do you think about the classloader issue in the resolving of classes in MemberName.getMethodType() described below? > I looked a bit more closely and no longer think the one-liner will is sufficient, since it will break the behaviour of MethodType.fromMethodDescriptorString: public static MethodType fromMethodDescriptorString(String descriptor, ClassLoader loader) throws IllegalArgumentException, TypeNotPresentException /** * Finds or creates an instance of a method type, given the spelling of its bytecode descriptor. * Convenience method for {@link #methodType(java.lang.Class, java.lang.Class[]) methodType}. * Any class or interface name embedded in the descriptor string * will be resolved by calling {@link ClassLoader#loadClass(java.lang.String)} * on the given loader (or if it is null, on the system class loader). The observations do suggest there may be some unexpected future surprises in store for bootclasspath code in restricted packages when a SM is enabled. (The more code we can get off the boot classpath the better off we will be.... hopefully Jigsaw FTW!) It is be better if the jtreg process test did not monkey around with the restricted package list, it's asking for a poke in the eye! IMHO we should prioritize fixing the test rather than fixing the lambda code to make that test work. Paul. From paul.sandoz at oracle.com Fri Apr 25 12:12:52 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 25 Apr 2014 14:12:52 +0200 Subject: RFR 9: JDK-8040892 Incorrect message in Exception thrown by Collectors.toMap(Function, Function) In-Reply-To: <5357829E.2030606@gmail.com> References: <534FF859.5090006@gmail.com> <534FFB92.4050805@gmail.com> <53500426.3060506@oracle.com> <535022B5.8090608@gmail.com> <86699497-9287-4B18-816E-B7F0D92A08F5@oracle.com> <5357829E.2030606@gmail.com> Message-ID: On Apr 23, 2014, at 11:06 AM, Peter Levart wrote: > Hi, > > I propose a patch for: > > https://bugs.openjdk.java.net/browse/JDK-8040892 > +1, nice use of putIfAbsent. Just double checking, did you run the stream unit tests? I think key step was to separate map merge and accumulate functions for the toMap* methods not accepting a value merge function. Now that is the case one could still use merge, but that would be less efficient than putIfAbsent since that does not require a lambda capturing the key. That fix caused me to think that we should update the value merge function accepting toMap* methods for the case when the merge function returns null, as removing an entry would be most undesirable. A simple fix would be to throw an NPE if the merge function returns null, if it is acceptable to induce a side-effect of a removal, which seems reasonable given a partial result would any be returned if a null check is performed on the result of the merge function, otherwise that merge function requires wrapping e.g. mergeFunction.andThen(Objects::requireNonNull). Paul. > Here's the webrev: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Collectors.duplicateKey/webrev.02/ > > There has already been a discussion on the lambda-dev about this bug: > > http://mail.openjdk.java.net/pipermail/lambda-dev/2014-April/012005.html > > > Initially a fix has been proposed which used a private RuntimeException subclass thrown by the merger function in order to transport the values that attempted to be merged out of Map.merge() method to an outer context where they could be combined with the key to produce a friendlier "duplicate key" message. It turns out that there is an alternative approach that doesn't require exception acrobatics - using Map.putIfAbsent() instead of Map.merge(). I checked both methods in Map defaults and in HashMap implementations for possible semantic differences. Same behaviour can be achieved by requiring that the value passed to Map.putIfAbsent(key, value) is non-null and throwing NPE if it isn't. > > > Regards, Peter From roger.riggs at oracle.com Fri Apr 25 13:32:55 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 25 Apr 2014 09:32:55 -0400 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> Message-ID: <535A6407.9040705@oracle.com> Hi, I think it is sufficient that the test enables the security manager, adding a java.util as the restricted restricted package is not necessary. Roger On 4/25/2014 6:44 AM, Paul Sandoz wrote: > On Apr 25, 2014, at 12:04 PM, Peter Levart wrote: > >> This is a ping for any Reviewer and also a question for Vladimir. >> >> Hello Vladimir, >> >> What do you think about the classloader issue in the resolving of classes in MemberName.getMethodType() described below? >> > I looked a bit more closely and no longer think the one-liner will is sufficient, since it will break the behaviour of MethodType.fromMethodDescriptorString: > > public static MethodType fromMethodDescriptorString(String descriptor, ClassLoader loader) > throws IllegalArgumentException, TypeNotPresentException > > /** > * Finds or creates an instance of a method type, given the spelling of its bytecode descriptor. > * Convenience method for {@link #methodType(java.lang.Class, java.lang.Class[]) methodType}. > * Any class or interface name embedded in the descriptor string > * will be resolved by calling {@link ClassLoader#loadClass(java.lang.String)} > * on the given loader (or if it is null, on the system class loader). > > > The observations do suggest there may be some unexpected future surprises in store for bootclasspath code in restricted packages when a SM is enabled. (The more code we can get off the boot classpath the better off we will be.... hopefully Jigsaw FTW!) > > It is be better if the jtreg process test did not monkey around with the restricted package list, it's asking for a poke in the eye! > > IMHO we should prioritize fixing the test rather than fixing the lambda code to make that test work. > > Paul. From chris.hegarty at oracle.com Fri Apr 25 13:43:28 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 25 Apr 2014 14:43:28 +0100 Subject: RFR 9: JDK-8040892 Incorrect message in Exception thrown by Collectors.toMap(Function, Function) In-Reply-To: References: <534FF859.5090006@gmail.com> <534FFB92.4050805@gmail.com> <53500426.3060506@oracle.com> <535022B5.8090608@gmail.com> <86699497-9287-4B18-816E-B7F0D92A08F5@oracle.com> <5357829E.2030606@gmail.com> Message-ID: <535A6680.70601@oracle.com> On 25/04/14 13:12, Paul Sandoz wrote: > > On Apr 23, 2014, at 11:06 AM, Peter Levart wrote: > >> Hi, >> >> I propose a patch for: >> >> https://bugs.openjdk.java.net/browse/JDK-8040892 >> > > +1, nice use of putIfAbsent. Just double checking, did you run the stream unit tests? Agreed. This looks good to me. Trivially, is this comment, in uniqKeysMapMerger, left over from a previous cut'n'paste ? 144 * {@link Map#merge(Object, Object, BiFunction) Map.merge()} -Chris. > > I think key step was to separate map merge and accumulate functions for the toMap* methods not accepting a value merge function. Now that is the case one could still use merge, but that would be less efficient than putIfAbsent since that does not require a lambda capturing the key. > > > That fix caused me to think that we should update the value merge function accepting toMap* methods for the case when the merge function returns null, as removing an entry would be most undesirable. > > A simple fix would be to throw an NPE if the merge function returns null, if it is acceptable to induce a side-effect of a removal, which seems reasonable given a partial result would any be returned if a null check is performed on the result of the merge function, otherwise that merge function requires wrapping e.g. mergeFunction.andThen(Objects::requireNonNull). > > Paul. > > >> Here's the webrev: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Collectors.duplicateKey/webrev.02/ >> >> There has already been a discussion on the lambda-dev about this bug: >> >> http://mail.openjdk.java.net/pipermail/lambda-dev/2014-April/012005.html >> >> >> Initially a fix has been proposed which used a private RuntimeException subclass thrown by the merger function in order to transport the values that attempted to be merged out of Map.merge() method to an outer context where they could be combined with the key to produce a friendlier "duplicate key" message. It turns out that there is an alternative approach that doesn't require exception acrobatics - using Map.putIfAbsent() instead of Map.merge(). I checked both methods in Map defaults and in HashMap implementations for possible semantic differences. Same behaviour can be achieved by requiring that the value passed to Map.putIfAbsent(key, value) is non-null and throwing NPE if it isn't. >> >> >> Regards, Peter From jason_mehrens at hotmail.com Fri Apr 25 14:32:08 2014 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 25 Apr 2014 09:32:08 -0500 Subject: RFR: 8035584 : (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: <93BA31AB-56DC-457A-9D1A-41F6AC0BA8B9@oracle.com> References: <93BA31AB-56DC-457A-9D1A-41F6AC0BA8B9@oracle.com> Message-ID: Looks good to me. Jason > From: mike.duigou at oracle.com > Subject: RFR: 8035584 : (s) ArrayList(c) should avoid inflation if c is empty > Date: Wed, 23 Apr 2014 15:33:48 -0700 > To: core-libs-dev at openjdk.java.net > > Hello all; > > Revisiting this issue again at long last I have updated the proposed changeset based upon Jason Mehren's most recent feedback. > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/4/webrev/ > > This version reverts the prior changes to toArray(). > > Mike From kevin.rushforth at oracle.com Fri Apr 25 15:22:53 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 25 Apr 2014 08:22:53 -0700 Subject: review request: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <5355C383.9050109@oracle.com> References: <5355C383.9050109@oracle.com> Message-ID: <535A7DCD.3050902@oracle.com> The code changes looks fine to me. Also, I ran all JavaFX unit tests with no problems (at least none relating to launching). -- Kevin Neil Toda wrote: > Webrev > > http://cr.openjdk.java.net/~ntoda/8035782/ > > for bug > > https://bugs.openjdk.java.net/browse/JDK-8035782 > > The file : ./jdk/src/share/classes/sun/launcher/LauncherHelper.java > > has been modified so that the inner class FXHelper is not loaded > unnecessarily. > FXHelper, which is needed to make initializations for any JavaFX > application, was > being loaded for all applications. > > The fix was straight forward, with the lifting of one method and > several static > strings into FXHelper's superclass, LauncherHelper. > > Kevin Rushforth supplied three tests of applications not in jar > files. These > needed to be explicitly tested. These tests require the JavaFX bundle > in the > build, and the return code 2 signifies success. > > Launcher tests for jtreg: ./jdk/test/tools/launcher passed on Windows > 7 64 and Oracle-Linux6-64. > > JPRT tests were run and passed on scv3. > > Thanks > > -neil > > > From jason_mehrens at hotmail.com Fri Apr 25 15:27:44 2014 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 25 Apr 2014 10:27:44 -0500 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty - (toArray spec) In-Reply-To: <5140680D-393D-4615-B9F4-E2D8BC8ED016@oracle.com> References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com>, , <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com>, , <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com>, , <4DC7C9B0-43F2-4FFF-A8D6-CFD1B54ED158@oracle.com>, , <9CBC797D-F5E2-42CD-B050-A0A706DFDBD4@oracle.com>, , <5140680D-393D-4615-B9F4-E2D8BC8ED016@oracle.com> Message-ID: MIke, The inner T.V. lawyer in me has been trying and find some loophole that will allow returning the same empty array from toArray. The spec states "..no references to it are maintained by this collection". The Saul Goodman loophole is that "this collection" implies object member reference. Which means that returning an empty array held by static field would be legal under that interpretation. So that leaves the final hurdle which is that the spec states "...method must allocate a new array...". I don't see a way around that unless the spec is changed. I can appreciate the reluctance to change spec as you pointed out bellow. Jason JM>The modification for toArray violates the List contract because the returned array must be safe (must use 'new' and must not retain reference). I think you'll have JM>to back out that change. Contract violation aside, the only case that I can see that might unsafe for an empty array would be acquiring the monitor of JM>EMPTY_ELEMENTDATA array. When we patched the Collections$EmptyXXX classes we avoided returning a cached empty array for this reason. MD>You are of course correct. Yet another reminder to avoid unnecessary promises when creating specifications. The Collection.toArray() javadoc could have MD>been written to allow for a shared empty array but isn't and can't be changed to be allow for this. We did eliminate the requirement to return a "new" instance MD>some cases for String/CharSequence/StringBuilder/StringBuffer in https://bugs.openjdk.java.net/browse/JDK-7174936 and MD>https://bugs.openjdk.java.net/browse/JDK-8028757 that were similar to this but those changes for the most part were to sync the javadoc to the longstanding MD>actual behaviour. From mandy.chung at oracle.com Fri Apr 25 15:42:02 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 25 Apr 2014 08:42:02 -0700 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <535A1501.20500@oracle.com> References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com> <535830AC.5070003@oracle.com> <535958DA.2010307@oracle.com> <53599932.4090307@oracle.com> <535A1501.20500@oracle.com> Message-ID: <535A824A.6090606@oracle.com> On 4/25/2014 12:55 AM, Erik Joelsson wrote: > Hello Mandy, > > The logic looks fine. Just some style issues. I would like indentation > for the conditionals to be 2 spaces as is currently the standard in > the makefiles. I would also like to have POLICY_SRC_LIST to be > declared empty with := instead of just =. We only use = assignment > when explicitly needed. Thanks for the review Erik. I'll make the change before the push. Mandy > > /Erik > > On 2014-04-25 01:07, Mandy Chung wrote: >> Thanks Sean. >> >> I have updated the webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/ >> >> Erik - I'm including build-dev to review the build change for >> java.policy file. >> >> Thanks >> Mandy >> >> On 4/24/14 11:32 AM, Sean Mullan wrote: >>> On 04/23/2014 05:29 PM, Mandy Chung wrote: >>>> >>>> On 4/23/2014 1:10 PM, Sean Mullan wrote: >>>>> Just a few comments: >>>>> >>>>> 1. When you write a test that uses the jtreg /policy option, the >>>>> policy file overrides the system policy file. If the test depends >>>>> on a >>>>> standard extension, then you may get SecurityExceptions unless >>>>> additional perms are granted. Thus, there are quite a few tests that >>>>> define their own policy files and duplicate the grant statement for >>>>> extensions from the system policy: >>>>> >>>>> grant codeBase "file:${{java.ext.dirs}}/*" { >>>>> permission java.security.AllPermission; >>>>> } >>>>> >>>>> These tests should be modified to only grant the necessary >>>>> permissions. However, ideally I think that a better solution would be >>>>> to add a jtreg /policy option that doesn't override the system policy >>>>> file, but rather appends to it, for example, using "==" : >>>>> >>>> >>>> I suspect most of the tests only want to grant the permissions for the >>>> test itself rather than overriding the system policy file. Having a >>>> new >>>> jtreg/policy option not to override the system policy file may be a >>>> better solution. This would avoid updating the test's policy file >>>> every time the system's policy is modified. On the other hand, I >>>> think >>>> the test policy may not need to grant permissions to the extensions >>>> directory if it doesn't use the classes in extensions. It's a good >>>> opportunity to clean that up. This will require some closer look at >>>> the >>>> tests. >>>> >>>> If you are okay, I'd like to separate the test's custom policy >>>> update as >>>> a follow-on work. >>> >>> That's fine with me. >>> >>>>> @run main/othervm/policy==test.policy >>>>> >>>>> (this is the reverse behavior of the java.security.policy system >>>>> property, so it might be a little confusing, so maybe it is better to >>>>> add a new option) >>>>> >>>> >>>> "==" is a confusing syntax. -Djava.security.policy==test.policy >>>> overrides the system policy file ("=" prefix) whereas jtreg uses the >>>> reverse syntax? I think it would be better to make jtreg/policy >>>> consistent with -Djava.security.policy (i.e. default is to extend the >>>> system java.security). >>> >>> Would be nice, but not sure if we can change it at this point. >>> Anyway, one of us should file a jtreg RFE. >>> >>>>> 3. jdk/nio/zipfs/ZipFileSystem.java >>>>> >>>>> If I understand the changes, the previous code would throw >>>>> SecurityExceptions when run under a SecurityManager? It's not >>>>> specifically related to this bug, is it? >>>>> >>>> >>>> It's a bug in the zipfs provider and I can file a new JBS issue for >>>> the >>>> zipfs change. I prefer to push them in the same changeset that >>>> reduces >>>> zipfs's privileges and added tests to run with security manager. >>> >>> Sure, it is fine with me to include them with this. I just wanted to >>> make sure I understood the changes. >>> >>> --Sean >> > From martinrb at google.com Fri Apr 25 16:12:45 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 25 Apr 2014 09:12:45 -0700 Subject: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty - (toArray spec) In-Reply-To: References: <0541A3EA-A2A5-4977-8054-4EDB28366216@oracle.com> <318A3363-C4F6-42D5-99CD-DB6D00766B0C@oracle.com> <8FD1E74E-B433-475E-8DF6-3CB7126698AC@oracle.com> <4DC7C9B0-43F2-4FFF-A8D6-CFD1B54ED158@oracle.com> <9CBC797D-F5E2-42CD-B050-A0A706DFDBD4@oracle.com> <5140680D-393D-4615-B9F4-E2D8BC8ED016@oracle.com> Message-ID: I think it's OK to return static empty arrays. Make the trivial spec modification. On Fri, Apr 25, 2014 at 8:27 AM, Jason Mehrens wrote: > MIke, > > The inner T.V. lawyer in me has been trying and find some loophole that > will allow returning the same empty array from toArray. The spec states > "..no references to it are maintained by this collection". The Saul > Goodman loophole is that "this collection" implies object member > reference. Which means that returning an empty array held by static field > would be legal under that interpretation. > > So that leaves the final hurdle which is that the spec states "...method > must allocate a new array...". I don't see a way around that unless the > spec is changed. I can appreciate the reluctance to change spec as you > pointed out bellow. > > Jason > > > JM>The modification for toArray violates the List contract because the > returned array must be safe (must use 'new' and must not retain > reference). I think you'll have JM>to back out that change. Contract > violation aside, the only case that I can see that might unsafe for an > empty array would be acquiring the monitor of JM>EMPTY_ELEMENTDATA array. > When we patched the Collections$EmptyXXX classes we avoided returning a > cached empty array for this reason. > > MD>You are of course correct. Yet another reminder to avoid unnecessary > promises when creating specifications. The Collection.toArray() > javadoc could have MD>been written to allow for a shared empty array but > isn't and can't be changed to be allow for this. We did eliminate the > requirement to return a "new" instance MD>some cases for > String/CharSequence/StringBuilder/StringBuffer in > https://bugs.openjdk.java.net/browse/JDK-7174936 and MD> > https://bugs.openjdk.java.net/browse/JDK-8028757 that were similar to > this but those changes for the most part were to sync the javadoc to the > longstanding MD>actual behaviour. > From peter.levart at gmail.com Fri Apr 25 16:13:57 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Apr 2014 18:13:57 +0200 Subject: RFR 9: JDK-8040892 Incorrect message in Exception thrown by Collectors.toMap(Function, Function) In-Reply-To: References: <534FF859.5090006@gmail.com> <534FFB92.4050805@gmail.com> <53500426.3060506@oracle.com> <535022B5.8090608@gmail.com> <86699497-9287-4B18-816E-B7F0D92A08F5@oracle.com> <5357829E.2030606@gmail.com> Message-ID: <535A89C5.9060209@gmail.com> Hi Paul, On 04/25/2014 02:12 PM, Paul Sandoz wrote: > On Apr 23, 2014, at 11:06 AM, Peter Levart wrote: > >> Hi, >> >> I propose a patch for: >> >> https://bugs.openjdk.java.net/browse/JDK-8040892 >> > +1, nice use of putIfAbsent. Just double checking, did you run the stream unit tests? Yes, all 60 /java/util/stream jtreg tests pass. > I think key step was to separate map merge and accumulate functions for the toMap* methods not accepting a value merge function. Now that is the case one could still use merge, but that would be less efficient than putIfAbsent since that does not require a lambda capturing the key. > > > That fix caused me to think that we should update the value merge function accepting toMap* methods for the case when the merge function returns null, as removing an entry would be most undesirable. Yes, removing doesn't make sense. It's undeterministic. For example, if the merge function always returns null, then duplicate keys result in entry being absent, triplicate keys result in entry (the last one merged) being present, quadruple keys result in entry being absent again, etc ... > A simple fix would be to throw an NPE if the merge function returns null, if it is acceptable to induce a side-effect of a removal, which seems reasonable given a partial result would any be returned if a null check is performed on the result of the merge function, otherwise that merge function requires wrapping e.g. mergeFunction.andThen(Objects::requireNonNull). I think that allowing null return from mergeFunction to remove the entry from the (maybe intermediate) map is just confusing. Throwing NPE is the most sensible thing we can do here. Regards, Peter > Paul. > > >> Here's the webrev: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Collectors.duplicateKey/webrev.02/ >> >> There has already been a discussion on the lambda-dev about this bug: >> >> http://mail.openjdk.java.net/pipermail/lambda-dev/2014-April/012005.html >> >> >> Initially a fix has been proposed which used a private RuntimeException subclass thrown by the merger function in order to transport the values that attempted to be merged out of Map.merge() method to an outer context where they could be combined with the key to produce a friendlier "duplicate key" message. It turns out that there is an alternative approach that doesn't require exception acrobatics - using Map.putIfAbsent() instead of Map.merge(). I checked both methods in Map defaults and in HashMap implementations for possible semantic differences. Same behaviour can be achieved by requiring that the value passed to Map.putIfAbsent(key, value) is non-null and throwing NPE if it isn't. >> >> >> Regards, Peter From peter.levart at gmail.com Fri Apr 25 16:15:51 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Apr 2014 18:15:51 +0200 Subject: RFR 9: JDK-8040892 Incorrect message in Exception thrown by Collectors.toMap(Function, Function) In-Reply-To: <535A6680.70601@oracle.com> References: <534FF859.5090006@gmail.com> <534FFB92.4050805@gmail.com> <53500426.3060506@oracle.com> <535022B5.8090608@gmail.com> <86699497-9287-4B18-816E-B7F0D92A08F5@oracle.com> <5357829E.2030606@gmail.com> <535A6680.70601@oracle.com> Message-ID: <535A8A37.2030104@gmail.com> On 04/25/2014 03:43 PM, Chris Hegarty wrote: > > On 25/04/14 13:12, Paul Sandoz wrote: >> >> On Apr 23, 2014, at 11:06 AM, Peter Levart >> wrote: >> >>> Hi, >>> >>> I propose a patch for: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8040892 >>> >> >> +1, nice use of putIfAbsent. Just double checking, did you run the >> stream unit tests? > > Agreed. This looks good to me. > > Trivially, is this comment, in uniqKeysMapMerger, left over from a > previous cut'n'paste ? > > 144 * {@link Map#merge(Object, Object, BiFunction) Map.merge()} > > -Chris. Hi Chris, Thanks for spotting the left over line. I'll remove it. Regards, Peter > >> >> I think key step was to separate map merge and accumulate functions >> for the toMap* methods not accepting a value merge function. Now that >> is the case one could still use merge, but that would be less >> efficient than putIfAbsent since that does not require a lambda >> capturing the key. >> >> >> That fix caused me to think that we should update the value merge >> function accepting toMap* methods for the case when the merge >> function returns null, as removing an entry would be most undesirable. >> >> A simple fix would be to throw an NPE if the merge function returns >> null, if it is acceptable to induce a side-effect of a removal, which >> seems reasonable given a partial result would any be returned if a >> null check is performed on the result of the merge function, >> otherwise that merge function requires wrapping e.g. >> mergeFunction.andThen(Objects::requireNonNull). >> >> Paul. >> >> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Collectors.duplicateKey/webrev.02/ >>> >>> >>> There has already been a discussion on the lambda-dev about this bug: >>> >>> http://mail.openjdk.java.net/pipermail/lambda-dev/2014-April/012005.html >>> >>> >>> >>> Initially a fix has been proposed which used a private >>> RuntimeException subclass thrown by the merger function in order to >>> transport the values that attempted to be merged out of Map.merge() >>> method to an outer context where they could be combined with the key >>> to produce a friendlier "duplicate key" message. It turns out that >>> there is an alternative approach that doesn't require exception >>> acrobatics - using Map.putIfAbsent() instead of Map.merge(). I >>> checked both methods in Map defaults and in HashMap implementations >>> for possible semantic differences. Same behaviour can be achieved by >>> requiring that the value passed to Map.putIfAbsent(key, value) is >>> non-null and throwing NPE if it isn't. >>> >>> >>> Regards, Peter From peter.levart at gmail.com Fri Apr 25 16:18:58 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Apr 2014 18:18:58 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <535A6407.9040705@oracle.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> Message-ID: <535A8AF2.1050908@gmail.com> On 04/25/2014 03:32 PM, roger riggs wrote: > Hi, > > I think it is sufficient that the test enables the security manager, > adding a java.util as the restricted > restricted package is not necessary. I think that too. Is it ok, to fix that as part of UNIXProcess merge fix or should there a separate issue be filed? Regards, Peter > > Roger > > On 4/25/2014 6:44 AM, Paul Sandoz wrote: >> On Apr 25, 2014, at 12:04 PM, Peter Levart >> wrote: >> >>> This is a ping for any Reviewer and also a question for Vladimir. >>> >>> Hello Vladimir, >>> >>> What do you think about the classloader issue in the resolving of >>> classes in MemberName.getMethodType() described below? >>> >> I looked a bit more closely and no longer think the one-liner will is >> sufficient, since it will break the behaviour of >> MethodType.fromMethodDescriptorString: >> >> public static MethodType fromMethodDescriptorString(String >> descriptor, ClassLoader loader) >> throws IllegalArgumentException, TypeNotPresentException >> >> /** >> * Finds or creates an instance of a method type, given the >> spelling of its bytecode descriptor. >> * Convenience method for {@link #methodType(java.lang.Class, >> java.lang.Class[]) methodType}. >> * Any class or interface name embedded in the descriptor string >> * will be resolved by calling {@link >> ClassLoader#loadClass(java.lang.String)} >> * on the given loader (or if it is null, on the system class >> loader). >> >> >> The observations do suggest there may be some unexpected future >> surprises in store for bootclasspath code in restricted packages when >> a SM is enabled. (The more code we can get off the boot classpath the >> better off we will be.... hopefully Jigsaw FTW!) >> >> It is be better if the jtreg process test did not monkey around with >> the restricted package list, it's asking for a poke in the eye! >> >> IMHO we should prioritize fixing the test rather than fixing the >> lambda code to make that test work. >> >> Paul. > From staffan.larsen at oracle.com Fri Apr 25 16:24:41 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 18:24:41 +0200 Subject: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> Message-ID: <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. Should I push an anti-delta of the patch? I can prepare a review of it in a moment. /Staffan On 25 apr 2014, at 17:16, Staffan Larsen wrote: > Thanks Keith! > > As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. > > /Staffan > > On 25 apr 2014, at 17:02, Keith McGuigan wrote: > >> Hi Staffan - >> >> It looks good to me. Why is the bug marked "closed" though? >> >> >> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: >> Still looking for a Review of this change. >> >> Thanks, >> /Staffan >> >> On 7 apr 2014, at 21:19, Staffan Larsen wrote: >> >> > And the links: >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >> > webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >> > >> > Sorry about that, >> > /Staffan >> > >> > On 7 apr 2014, at 20:08, Staffan Larsen wrote: >> > >> >> >> >> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >> >> >> >> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >> >> >> >> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >> >> >> >> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >> >> >> >> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >> >> >> >> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >> >> >> >> Thanks, >> >> /Staffan >> > >> >> >> >> >> -- >> >> Keith McGuigan >> @kamggg >> kmcguigan at twitter.com > From peter.levart at gmail.com Fri Apr 25 16:28:32 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Apr 2014 18:28:32 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> Message-ID: <535A8D30.90806@gmail.com> On 04/25/2014 12:44 PM, Paul Sandoz wrote: > On Apr 25, 2014, at 12:04 PM, Peter Levart wrote: > >> This is a ping for any Reviewer and also a question for Vladimir. >> >> Hello Vladimir, >> >> What do you think about the classloader issue in the resolving of classes in MemberName.getMethodType() described below? >> > I looked a bit more closely and no longer think the one-liner will is sufficient, since it will break the behaviour of MethodType.fromMethodDescriptorString: > > public static MethodType fromMethodDescriptorString(String descriptor, ClassLoader loader) > throws IllegalArgumentException, TypeNotPresentException > > /** > * Finds or creates an instance of a method type, given the spelling of its bytecode descriptor. > * Convenience method for {@link #methodType(java.lang.Class, java.lang.Class[]) methodType}. > * Any class or interface name embedded in the descriptor string > * will be resolved by calling {@link ClassLoader#loadClass(java.lang.String)} > * on the given loader (or if it is null, on the system class loader). Ah, yes - I missed that part. MethodType.fromMethodDescriptorString() is public API with defined specification, so we can't change that. It is sensible for public API to use null as the system class loader. But all internal usages would be more correct, I think, if null meant the bootstrap class loader. So perhaps the right fix for this is to create a package-private variant of this method (say parseMethodDescriptorString()) which would work as expected for internal usage... > > The observations do suggest there may be some unexpected future surprises in store for bootclasspath code in restricted packages when a SM is enabled. (The more code we can get off the boot classpath the better off we will be.... hopefully Jigsaw FTW!) > > It is be better if the jtreg process test did not monkey around with the restricted package list, it's asking for a poke in the eye! > > IMHO we should prioritize fixing the test rather than fixing the lambda code to make that test work. > > Paul. Agreed. Regards, Peter From staffan.larsen at oracle.com Fri Apr 25 16:36:34 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 18:36:34 +0200 Subject: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> Message-ID: <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> Here is an anti-delta for the broken push. I prepared it using ?hg backout?. webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8041948 If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). Thanks, /Staffan On 25 apr 2014, at 18:24, Staffan Larsen wrote: > It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. > > Should I push an anti-delta of the patch? I can prepare a review of it in a moment. > > /Staffan > > On 25 apr 2014, at 17:16, Staffan Larsen wrote: > >> Thanks Keith! >> >> As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. >> >> /Staffan >> >> On 25 apr 2014, at 17:02, Keith McGuigan wrote: >> >>> Hi Staffan - >>> >>> It looks good to me. Why is the bug marked "closed" though? >>> >>> >>> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: >>> Still looking for a Review of this change. >>> >>> Thanks, >>> /Staffan >>> >>> On 7 apr 2014, at 21:19, Staffan Larsen wrote: >>> >>> > And the links: >>> > >>> > bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >>> > webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >>> > >>> > Sorry about that, >>> > /Staffan >>> > >>> > On 7 apr 2014, at 20:08, Staffan Larsen wrote: >>> > >>> >> >>> >> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >>> >> >>> >> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >>> >> >>> >> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >>> >> >>> >> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >>> >> >>> >> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >>> >> >>> >> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >>> >> >>> >> Thanks, >>> >> /Staffan >>> > >>> >>> >>> >>> >>> -- >>> >>> Keith McGuigan >>> @kamggg >>> kmcguigan at twitter.com >> > From martinrb at google.com Fri Apr 25 16:39:09 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 25 Apr 2014 09:39:09 -0700 Subject: RFR: 8035584 : (s) ArrayList(c) should avoid inflation if c is empty In-Reply-To: <93BA31AB-56DC-457A-9D1A-41F6AC0BA8B9@oracle.com> References: <93BA31AB-56DC-457A-9D1A-41F6AC0BA8B9@oracle.com> Message-ID: While I'm not entirely happy with the added empty array machinery, I approve this change. On Wed, Apr 23, 2014 at 3:33 PM, Mike Duigou wrote: > Hello all; > > Revisiting this issue again at long last I have updated the proposed > changeset based upon Jason Mehren's most recent feedback. > > http://cr.openjdk.java.net/~mduigou/JDK-8035584/4/webrev/ > > This version reverts the prior changes to toArray(). > > Mike From joe.darcy at oracle.com Fri Apr 25 16:43:13 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 25 Apr 2014 09:43:13 -0700 Subject: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> Message-ID: <535A90A1.2050609@oracle.com> Approved! -Joe On 04/25/2014 09:36 AM, Staffan Larsen wrote: > Here is an anti-delta for the broken push. I prepared it using ?hg backout?. > > webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8041948 > > If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). > > Thanks, > /Staffan > > > On 25 apr 2014, at 18:24, Staffan Larsen wrote: > >> It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. >> >> Should I push an anti-delta of the patch? I can prepare a review of it in a moment. >> >> /Staffan >> >> On 25 apr 2014, at 17:16, Staffan Larsen wrote: >> >>> Thanks Keith! >>> >>> As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. >>> >>> /Staffan >>> >>> On 25 apr 2014, at 17:02, Keith McGuigan wrote: >>> >>>> Hi Staffan - >>>> >>>> It looks good to me. Why is the bug marked "closed" though? >>>> >>>> >>>> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: >>>> Still looking for a Review of this change. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 7 apr 2014, at 21:19, Staffan Larsen wrote: >>>> >>>>> And the links: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >>>>> webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >>>>> >>>>> Sorry about that, >>>>> /Staffan >>>>> >>>>> On 7 apr 2014, at 20:08, Staffan Larsen wrote: >>>>> >>>>>> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >>>>>> >>>>>> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >>>>>> >>>>>> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >>>>>> >>>>>> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >>>>>> >>>>>> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >>>>>> >>>>>> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>> >>>> >>>> >>>> -- >>>> >>>> Keith McGuigan >>>> @kamggg >>>> kmcguigan at twitter.com From Alan.Bateman at oracle.com Fri Apr 25 16:44:10 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Apr 2014 17:44:10 +0100 Subject: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> Message-ID: <535A90DA.6060903@oracle.com> On 25/04/2014 17:36, Staffan Larsen wrote: > Here is an anti-delta for the broken push. I prepared it using ?hg > backout?. > > webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8041948 > > If I can get this reviewed quickly I can push the fix soon (and I will > spend the weekend in shame). > I just ran into the build issue a few minutes ago. From a quick scan of the patch then it looks to be anti-delta so I think it's good. -Alan From staffan.larsen at oracle.com Fri Apr 25 16:46:39 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 18:46:39 +0200 Subject: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <535A90A1.2050609@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> <535A90A1.2050609@oracle.com> Message-ID: <084B0307-0050-4C9B-B3D4-6D9BAA5899AC@oracle.com> Thanks Joe - fix has been pushed. (I will now retreat to a dark place and grumble over the impossibility of pushing coordinated changes). /Staffan On 25 apr 2014, at 18:43, Joe Darcy wrote: > Approved! > > -Joe > > On 04/25/2014 09:36 AM, Staffan Larsen wrote: >> Here is an anti-delta for the broken push. I prepared it using ?hg backout?. >> >> webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8041948 >> >> If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). >> >> Thanks, >> /Staffan >> >> >> On 25 apr 2014, at 18:24, Staffan Larsen wrote: >> >>> It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. >>> >>> Should I push an anti-delta of the patch? I can prepare a review of it in a moment. >>> >>> /Staffan >>> >>> On 25 apr 2014, at 17:16, Staffan Larsen wrote: >>> >>>> Thanks Keith! >>>> >>>> As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. >>>> >>>> /Staffan >>>> >>>> On 25 apr 2014, at 17:02, Keith McGuigan wrote: >>>> >>>>> Hi Staffan - >>>>> >>>>> It looks good to me. Why is the bug marked "closed" though? >>>>> >>>>> >>>>> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: >>>>> Still looking for a Review of this change. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 7 apr 2014, at 21:19, Staffan Larsen wrote: >>>>> >>>>>> And the links: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >>>>>> webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >>>>>> >>>>>> Sorry about that, >>>>>> /Staffan >>>>>> >>>>>> On 7 apr 2014, at 20:08, Staffan Larsen wrote: >>>>>> >>>>>>> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >>>>>>> >>>>>>> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >>>>>>> >>>>>>> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >>>>>>> >>>>>>> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >>>>>>> >>>>>>> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >>>>>>> >>>>>>> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Keith McGuigan >>>>> @kamggg >>>>> kmcguigan at twitter.com > From roger.riggs at oracle.com Fri Apr 25 16:47:41 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 25 Apr 2014 12:47:41 -0400 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <535A8AF2.1050908@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> Message-ID: <535A91AD.4040405@oracle.com> Hi Peter, Including the test update with the updated changeset is fine. (I think Alan had some comments on the refactoring and has not yet had a chance to comment). Thanks, Roger On 4/25/2014 12:18 PM, Peter Levart wrote: > > On 04/25/2014 03:32 PM, roger riggs wrote: >> Hi, >> >> I think it is sufficient that the test enables the security manager, >> adding a java.util as the restricted >> restricted package is not necessary. > > I think that too. Is it ok, to fix that as part of UNIXProcess merge > fix or should there a separate issue be filed? > > Regards, Peter > >> >> Roger >> >> On 4/25/2014 6:44 AM, Paul Sandoz wrote: >>> On Apr 25, 2014, at 12:04 PM, Peter Levart >>> wrote: >>> >>>> This is a ping for any Reviewer and also a question for Vladimir. >>>> >>>> Hello Vladimir, >>>> >>>> What do you think about the classloader issue in the resolving of >>>> classes in MemberName.getMethodType() described below? >>>> >>> I looked a bit more closely and no longer think the one-liner will >>> is sufficient, since it will break the behaviour of >>> MethodType.fromMethodDescriptorString: >>> >>> public static MethodType fromMethodDescriptorString(String >>> descriptor, ClassLoader loader) >>> throws IllegalArgumentException, TypeNotPresentException >>> >>> /** >>> * Finds or creates an instance of a method type, given the >>> spelling of its bytecode descriptor. >>> * Convenience method for {@link #methodType(java.lang.Class, >>> java.lang.Class[]) methodType}. >>> * Any class or interface name embedded in the descriptor string >>> * will be resolved by calling {@link >>> ClassLoader#loadClass(java.lang.String)} >>> * on the given loader (or if it is null, on the system class >>> loader). >>> >>> >>> The observations do suggest there may be some unexpected future >>> surprises in store for bootclasspath code in restricted packages >>> when a SM is enabled. (The more code we can get off the boot >>> classpath the better off we will be.... hopefully Jigsaw FTW!) >>> >>> It is be better if the jtreg process test did not monkey around with >>> the restricted package list, it's asking for a poke in the eye! >>> >>> IMHO we should prioritize fixing the test rather than fixing the >>> lambda code to make that test work. >>> >>> Paul. >> > From alejandro.murillo at oracle.com Fri Apr 25 17:04:48 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 25 Apr 2014 11:04:48 -0600 Subject: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <084B0307-0050-4C9B-B3D4-6D9BAA5899AC@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> <535A90A1.2050609@oracle.com> <084B0307-0050-4C9B-B3D4-6D9BAA5899AC@oracle.com> Message-ID: <535A95B0.3020007@oracle.com> what's wrong with pushing them to jdk9/hs-rt? We did this a couple of weeks ago with Erik (Gahlin) changes, it might disrupt nightly, as we still do not have the JPRT changes in place, but that was the agreement we have for jdk9: tightly coupled changes should be pushed through the hotspot repos. had that been pushed this week there, it would be in jdk9/dev next Tuesday Alejandro On 4/25/2014 10:46 AM, Staffan Larsen wrote: > Thanks Joe - fix has been pushed. > > (I will now retreat to a dark place and grumble over the impossibility of pushing coordinated changes). > > /Staffan > > On 25 apr 2014, at 18:43, Joe Darcy wrote: > >> Approved! >> >> -Joe >> >> On 04/25/2014 09:36 AM, Staffan Larsen wrote: >>> Here is an anti-delta for the broken push. I prepared it using ?hg backout?. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8041948 >>> >>> If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). >>> >>> Thanks, >>> /Staffan >>> >>> >>> On 25 apr 2014, at 18:24, Staffan Larsen wrote: >>> >>>> It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. >>>> >>>> Should I push an anti-delta of the patch? I can prepare a review of it in a moment. >>>> >>>> /Staffan >>>> >>>> On 25 apr 2014, at 17:16, Staffan Larsen wrote: >>>> >>>>> Thanks Keith! >>>>> >>>>> As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. >>>>> >>>>> /Staffan >>>>> >>>>> On 25 apr 2014, at 17:02, Keith McGuigan wrote: >>>>> >>>>>> Hi Staffan - >>>>>> >>>>>> It looks good to me. Why is the bug marked "closed" though? >>>>>> >>>>>> >>>>>> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: >>>>>> Still looking for a Review of this change. >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> On 7 apr 2014, at 21:19, Staffan Larsen wrote: >>>>>> >>>>>>> And the links: >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >>>>>>> webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >>>>>>> >>>>>>> Sorry about that, >>>>>>> /Staffan >>>>>>> >>>>>>> On 7 apr 2014, at 20:08, Staffan Larsen wrote: >>>>>>> >>>>>>>> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >>>>>>>> >>>>>>>> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >>>>>>>> >>>>>>>> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >>>>>>>> >>>>>>>> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >>>>>>>> >>>>>>>> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >>>>>>>> >>>>>>>> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Keith McGuigan >>>>>> @kamggg >>>>>> kmcguigan at twitter.com -- Alejandro From staffan.larsen at oracle.com Fri Apr 25 17:15:13 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 19:15:13 +0200 Subject: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <535A95B0.3020007@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> <535A90A1.2050609@oracle.com> <084B0307-0050-4C9B-B3D4-6D9BAA5899AC@oracle.com> <535A95B0.3020007@oracle.com> Message-ID: <837FBCA9-1047-4689-952C-CA28B3AADAEF@oracle.com> In this case I think it would have worked ok since the dependency was from jdk -> hotspot. If the dependency was the other way (or both ways), then such a push would break nightly testing in hotspot since that testing picks up the latest promoted JDK (instead of the JDK that is in the same forest). This is broken, IMO, and there is work in progress on fixing it. /Staffan On 25 apr 2014, at 19:04, Alejandro E Murillo wrote: > > what's wrong with pushing them to jdk9/hs-rt? > We did this a couple of weeks ago with Erik (Gahlin) changes, > it might disrupt nightly, as we still do not have the JPRT changes in place, > but that was the agreement we have for jdk9: > tightly coupled changes should be pushed through the hotspot repos. > had that been pushed this week there, it would be in jdk9/dev next Tuesday > > > Alejandro > > On 4/25/2014 10:46 AM, Staffan Larsen wrote: >> Thanks Joe - fix has been pushed. >> >> (I will now retreat to a dark place and grumble over the impossibility of pushing coordinated changes). >> >> /Staffan >> >> On 25 apr 2014, at 18:43, Joe Darcy wrote: >> >>> Approved! >>> >>> -Joe >>> >>> On 04/25/2014 09:36 AM, Staffan Larsen wrote: >>>> Here is an anti-delta for the broken push. I prepared it using ?hg backout?. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041948 >>>> >>>> If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> On 25 apr 2014, at 18:24, Staffan Larsen wrote: >>>> >>>>> It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. >>>>> >>>>> Should I push an anti-delta of the patch? I can prepare a review of it in a moment. >>>>> >>>>> /Staffan >>>>> >>>>> On 25 apr 2014, at 17:16, Staffan Larsen wrote: >>>>> >>>>>> Thanks Keith! >>>>>> >>>>>> As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. >>>>>> >>>>>> /Staffan >>>>>> >>>>>> On 25 apr 2014, at 17:02, Keith McGuigan wrote: >>>>>> >>>>>>> Hi Staffan - >>>>>>> >>>>>>> It looks good to me. Why is the bug marked "closed" though? >>>>>>> >>>>>>> >>>>>>> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: >>>>>>> Still looking for a Review of this change. >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 7 apr 2014, at 21:19, Staffan Larsen wrote: >>>>>>> >>>>>>>> And the links: >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >>>>>>>> >>>>>>>> Sorry about that, >>>>>>>> /Staffan >>>>>>>> >>>>>>>> On 7 apr 2014, at 20:08, Staffan Larsen wrote: >>>>>>>> >>>>>>>>> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >>>>>>>>> >>>>>>>>> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >>>>>>>>> >>>>>>>>> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >>>>>>>>> >>>>>>>>> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >>>>>>>>> >>>>>>>>> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >>>>>>>>> >>>>>>>>> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Keith McGuigan >>>>>>> @kamggg >>>>>>> kmcguigan at twitter.com > > -- > Alejandro > From peter.levart at gmail.com Fri Apr 25 17:31:52 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Apr 2014 19:31:52 +0200 Subject: RFR 9: JDK-8040892 Incorrect message in Exception thrown by Collectors.toMap(Function, Function) In-Reply-To: <535A89C5.9060209@gmail.com> References: <534FF859.5090006@gmail.com> <534FFB92.4050805@gmail.com> <53500426.3060506@oracle.com> <535022B5.8090608@gmail.com> <86699497-9287-4B18-816E-B7F0D92A08F5@oracle.com> <5357829E.2030606@gmail.com> <535A89C5.9060209@gmail.com> Message-ID: <535A9C08.9010906@gmail.com> On 04/25/2014 06:13 PM, Peter Levart wrote: > Hi Paul, > > On 04/25/2014 02:12 PM, Paul Sandoz wrote: >> On Apr 23, 2014, at 11:06 AM, Peter Levart wrote: >> >>> Hi, >>> >>> I propose a patch for: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8040892 >>> >> +1, nice use of putIfAbsent. Just double checking, did you run the stream unit tests? > > Yes, all 60 /java/util/stream jtreg tests pass. > >> I think key step was to separate map merge and accumulate functions for the toMap* methods not accepting a value merge function. Now that is the case one could still use merge, but that would be less efficient than putIfAbsent since that does not require a lambda capturing the key. >> >> >> That fix caused me to think that we should update the value merge function accepting toMap* methods for the case when the merge function returns null, as removing an entry would be most undesirable. > > Yes, removing doesn't make sense. It's undeterministic. For example, > if the merge function always returns null, then duplicate keys result > in entry being absent, triplicate keys result in entry (the last one > merged) being present, quadruple keys result in entry being absent > again, etc ... Hi Paul, To make any sense of null return from the mergeFunction, which could mean that an entry with that key is absent from resulting map, such Collector would have to keep some more state - the collecting map (which is also returned at the end) and the set of removed keys. For example: public static > Collector toMap(Function keyMapper, Function valueMapper, BinaryOperator mergeFunction, Supplier mapSupplier) { class State { final M map = mapSupplier.get(); final Set removedKeys = new HashSet<>(); M map() { return map; } } BiConsumer accumulator = (state, element) -> { K k = keyMapper.apply(element); if (!state.removedKeys.contains(k)) { U u = state.map.merge(k, valueMapper.apply(element), mergeFunction); if (u == null) state.removedKeys.add(k); } }; BinaryOperator merger = (state1, state2) -> { state1.map.keySet().removeAll(state2.removedKeys); state2.map.keySet().removeAll(state1.removedKeys); state1.removedKeys.addAll(state2.removedKeys); for (Map.Entry e : state2.map.entrySet()) { U u = state1.map.merge(e.getKey(), e.getValue(), mergeFunction); if (u == null) state1.removedKeys.add(e.getKey()); } return state1; }; return new CollectorImpl<>(State::new, accumulator, merger, State::map, CH_ID); } ...but the concurrent variant would be tricky to implement. Regards, Peter > >> A simple fix would be to throw an NPE if the merge function returns null, if it is acceptable to induce a side-effect of a removal, which seems reasonable given a partial result would any be returned if a null check is performed on the result of the merge function, otherwise that merge function requires wrapping e.g. mergeFunction.andThen(Objects::requireNonNull). > > I think that allowing null return from mergeFunction to remove the > entry from the (maybe intermediate) map is just confusing. Throwing > NPE is the most sensible thing we can do here. > > Regards, Peter > >> Paul. >> >> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Collectors.duplicateKey/webrev.02/ >>> >>> There has already been a discussion on the lambda-dev about this bug: >>> >>> http://mail.openjdk.java.net/pipermail/lambda-dev/2014-April/012005.html >>> >>> >>> Initially a fix has been proposed which used a private RuntimeException subclass thrown by the merger function in order to transport the values that attempted to be merged out of Map.merge() method to an outer context where they could be combined with the key to produce a friendlier "duplicate key" message. It turns out that there is an alternative approach that doesn't require exception acrobatics - using Map.putIfAbsent() instead of Map.merge(). I checked both methods in Map defaults and in HashMap implementations for possible semantic differences. Same behaviour can be achieved by requiring that the value passed to Map.putIfAbsent(key, value) is non-null and throwing NPE if it isn't. >>> >>> >>> Regards, Peter > From brian.burkhalter at oracle.com Fri Apr 25 21:26:09 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 25 Apr 2014 14:26:09 -0700 Subject: JDK 9 RFR of 8041683: java/math/BigInteger/BitLengthOverflow.java failing with OOME Message-ID: <056C7BFB-8428-4E52-BDEC-7E3266554B6B@oracle.com> Hello, Issue: https://bugs.openjdk.java.net/browse/JDK-8041683 Patch: http://cr.openjdk.java.net/~bpb/8041683/webrev.00/ It?s not really a solution but the patch changes BitLengthOverflow and DoubleValueOverflow to catch the OOME and print a warning to STDERR instead of failing outright. These OOMEs do not occur in JPRT runs with default parameters, so at least this patch would allow the tests to run successfully when there is enough memory but not to cause the test run to fail when there is not enough memory. This is more test coverage than never running the tests. Thanks, Brian From neil.toda at oracle.com Sat Apr 26 01:55:02 2014 From: neil.toda at oracle.com (Neil Toda) Date: Fri, 25 Apr 2014 18:55:02 -0700 Subject: review request: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <535A7DCD.3050902@oracle.com> References: <5355C383.9050109@oracle.com> <535A7DCD.3050902@oracle.com> Message-ID: <535B11F6.3090403@oracle.com> Thanks Kevin. -neil On 4/25/2014 8:22 AM, Kevin Rushforth wrote: > The code changes looks fine to me. Also, I ran all JavaFX unit tests > with no problems (at least none relating to launching). > > -- Kevin > > > Neil Toda wrote: >> Webrev >> >> http://cr.openjdk.java.net/~ntoda/8035782/ >> >> for bug >> >> https://bugs.openjdk.java.net/browse/JDK-8035782 >> >> The file : ./jdk/src/share/classes/sun/launcher/LauncherHelper.java >> >> has been modified so that the inner class FXHelper is not loaded >> unnecessarily. >> FXHelper, which is needed to make initializations for any JavaFX >> application, was >> being loaded for all applications. >> >> The fix was straight forward, with the lifting of one method and >> several static >> strings into FXHelper's superclass, LauncherHelper. >> >> Kevin Rushforth supplied three tests of applications not in jar >> files. These >> needed to be explicitly tested. These tests require the JavaFX >> bundle in the >> build, and the return code 2 signifies success. >> >> Launcher tests for jtreg: ./jdk/test/tools/launcher passed on Windows >> 7 64 and Oracle-Linux6-64. >> >> JPRT tests were run and passed on scv3. >> >> Thanks >> >> -neil >> >> >> > > From n-roeser at gmx.net Sat Apr 26 09:22:03 2014 From: n-roeser at gmx.net (Nico R.) Date: Sat, 26 Apr 2014 11:22:03 +0200 Subject: Wrong encoding after XML identity transformation In-Reply-To: <534FF6BA.90105@oracle.com> References: <5336EE48.8070008@gmx.net> <5337235C.7070302@gmx.net> <534FF6BA.90105@oracle.com> Message-ID: <535B7ABB.7070909@gmx.net> Hello, Joe! On 2014-04-17T17:43, huizhe wang wrote: > The JDK is a few patches short of Xalan 2.7.1. At least one of the > patches caused performance regression, which was the main reason they > were not brought in. We plan to fix the issue and bring JDK to Xalan > version 2.7.1. Ahh, that?s good to hear. > > Could you file at https://bugs.openjdk.java.net/browse/JDK? Please > select category "xml" and javax.xml.transform. Sorry, I can?t, as I don?t have an account and write access there. Someone else should please file a bug report. Thanks! -- Nico From peter.levart at gmail.com Sat Apr 26 09:30:26 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 26 Apr 2014 11:30:26 +0200 Subject: RFR 9: JDK-8040892 Incorrect message in Exception thrown by Collectors.toMap(Function, Function) In-Reply-To: <535A6680.70601@oracle.com> References: <534FF859.5090006@gmail.com> <534FFB92.4050805@gmail.com> <53500426.3060506@oracle.com> <535022B5.8090608@gmail.com> <86699497-9287-4B18-816E-B7F0D92A08F5@oracle.com> <5357829E.2030606@gmail.com> <535A6680.70601@oracle.com> Message-ID: <535B7CB2.1050604@gmail.com> Chris, Paul, Thanks again for reviews. I have just committed the change to jdk9-dev with the excess comment line spotted by Chris removed. Regards, Peter On 04/25/2014 03:43 PM, Chris Hegarty wrote: > > On 25/04/14 13:12, Paul Sandoz wrote: >> >> On Apr 23, 2014, at 11:06 AM, Peter Levart >> wrote: >> >>> Hi, >>> >>> I propose a patch for: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8040892 >>> >> >> +1, nice use of putIfAbsent. Just double checking, did you run the >> stream unit tests? > > Agreed. This looks good to me. > > Trivially, is this comment, in uniqKeysMapMerger, left over from a > previous cut'n'paste ? > > 144 * {@link Map#merge(Object, Object, BiFunction) Map.merge()} > > -Chris. > >> >> I think key step was to separate map merge and accumulate functions >> for the toMap* methods not accepting a value merge function. Now that >> is the case one could still use merge, but that would be less >> efficient than putIfAbsent since that does not require a lambda >> capturing the key. >> >> >> That fix caused me to think that we should update the value merge >> function accepting toMap* methods for the case when the merge >> function returns null, as removing an entry would be most undesirable. >> >> A simple fix would be to throw an NPE if the merge function returns >> null, if it is acceptable to induce a side-effect of a removal, which >> seems reasonable given a partial result would any be returned if a >> null check is performed on the result of the merge function, >> otherwise that merge function requires wrapping e.g. >> mergeFunction.andThen(Objects::requireNonNull). >> >> Paul. >> >> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Collectors.duplicateKey/webrev.02/ >>> >>> >>> There has already been a discussion on the lambda-dev about this bug: >>> >>> http://mail.openjdk.java.net/pipermail/lambda-dev/2014-April/012005.html >>> >>> >>> >>> Initially a fix has been proposed which used a private >>> RuntimeException subclass thrown by the merger function in order to >>> transport the values that attempted to be merged out of Map.merge() >>> method to an outer context where they could be combined with the key >>> to produce a friendlier "duplicate key" message. It turns out that >>> there is an alternative approach that doesn't require exception >>> acrobatics - using Map.putIfAbsent() instead of Map.merge(). I >>> checked both methods in Map defaults and in HashMap implementations >>> for possible semantic differences. Same behaviour can be achieved by >>> requiring that the value passed to Map.putIfAbsent(key, value) is >>> non-null and throwing NPE if it isn't. >>> >>> >>> Regards, Peter From peter.levart at gmail.com Sat Apr 26 09:30:26 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 26 Apr 2014 11:30:26 +0200 Subject: RFR 9: JDK-8040892 Incorrect message in Exception thrown by Collectors.toMap(Function, Function) In-Reply-To: <535A6680.70601@oracle.com> References: <534FF859.5090006@gmail.com> <534FFB92.4050805@gmail.com> <53500426.3060506@oracle.com> <535022B5.8090608@gmail.com> <86699497-9287-4B18-816E-B7F0D92A08F5@oracle.com> <5357829E.2030606@gmail.com> <535A6680.70601@oracle.com> Message-ID: <535B7CB2.1050604@gmail.com> Chris, Paul, Thanks again for reviews. I have just committed the change to jdk9-dev with the excess comment line spotted by Chris removed. Regards, Peter On 04/25/2014 03:43 PM, Chris Hegarty wrote: > > On 25/04/14 13:12, Paul Sandoz wrote: >> >> On Apr 23, 2014, at 11:06 AM, Peter Levart >> wrote: >> >>> Hi, >>> >>> I propose a patch for: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8040892 >>> >> >> +1, nice use of putIfAbsent. Just double checking, did you run the >> stream unit tests? > > Agreed. This looks good to me. > > Trivially, is this comment, in uniqKeysMapMerger, left over from a > previous cut'n'paste ? > > 144 * {@link Map#merge(Object, Object, BiFunction) Map.merge()} > > -Chris. > >> >> I think key step was to separate map merge and accumulate functions >> for the toMap* methods not accepting a value merge function. Now that >> is the case one could still use merge, but that would be less >> efficient than putIfAbsent since that does not require a lambda >> capturing the key. >> >> >> That fix caused me to think that we should update the value merge >> function accepting toMap* methods for the case when the merge >> function returns null, as removing an entry would be most undesirable. >> >> A simple fix would be to throw an NPE if the merge function returns >> null, if it is acceptable to induce a side-effect of a removal, which >> seems reasonable given a partial result would any be returned if a >> null check is performed on the result of the merge function, >> otherwise that merge function requires wrapping e.g. >> mergeFunction.andThen(Objects::requireNonNull). >> >> Paul. >> >> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Collectors.duplicateKey/webrev.02/ >>> >>> >>> There has already been a discussion on the lambda-dev about this bug: >>> >>> http://mail.openjdk.java.net/pipermail/lambda-dev/2014-April/012005.html >>> >>> >>> >>> Initially a fix has been proposed which used a private >>> RuntimeException subclass thrown by the merger function in order to >>> transport the values that attempted to be merged out of Map.merge() >>> method to an outer context where they could be combined with the key >>> to produce a friendlier "duplicate key" message. It turns out that >>> there is an alternative approach that doesn't require exception >>> acrobatics - using Map.putIfAbsent() instead of Map.merge(). I >>> checked both methods in Map defaults and in HashMap implementations >>> for possible semantic differences. Same behaviour can be achieved by >>> requiring that the value passed to Map.putIfAbsent(key, value) is >>> non-null and throwing NPE if it isn't. >>> >>> >>> Regards, Peter From otaviojava at java.net Sat Apr 26 10:56:01 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Sat, 26 Apr 2014 07:56:01 -0300 Subject: inefficient indexof when String has one length Message-ID: When a String has length just one, could be replaced by equivalent character literals, gaining some performance enhancement. I found 107 changes. diff -r e323c74edabd src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java --- a/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Sat Apr 26 07:31:04 2014 -0300 @@ -547,7 +547,7 @@ i = strLowerCase.indexOf("", i); if (i > 0) { i += "".length(); - int i2 = str.indexOf("<", i); + int i2 = str.indexOf('<', i); return str.substring(i, i2); } } diff -r e323c74edabd src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java --- a/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Sat Apr 26 07:31:04 2014 -0300 @@ -512,7 +512,7 @@ } static String qualifiedStringValue(String s1, String s234) { // Qualification by dot must decompose uniquely. Second string might already be qualified. - assert(s1.indexOf(".") < 0); + assert(s1.indexOf('.') < 0); return s1+"."+s234; } diff -r e323c74edabd src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java --- a/src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java Sat Apr 26 07:31:04 2014 -0300 @@ -102,7 +102,7 @@ } location = url.substring(addrStart, addrEnd); - int keyStart = location.indexOf("/"); + int keyStart = location.indexOf('/'); if (keyStart >= 0) { // Has key string if (keyStart == (location.length() -1)) { diff -r e323c74edabd src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java --- a/src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java Sat Apr 26 07:31:04 2014 -0300 @@ -336,7 +336,7 @@ String url = "rmi://"; // Enclose IPv6 literal address in '[' and ']' - url = (host.indexOf(":") > -1) ? url + "[" + host + "]" : + url = (host.indexOf(':') > -1) ? url + "[" + host + "]" : url + host; if (port > 0) { url += ":" + Integer.toString(port); diff -r e323c74edabd src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java --- a/src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Sat Apr 26 07:31:04 2014 -0300 @@ -149,7 +149,7 @@ * foo:rest/of/name foo: */ protected String getURLPrefix(String url) throws NamingException { - int start = url.indexOf(":"); + int start = url.indexOf(':'); if (start < 0) { throw new OperationNotSupportedException("Invalid URL: " + url); @@ -160,7 +160,7 @@ start += 2; // skip double slash // find last slash - int posn = url.indexOf("/", start); + int posn = url.indexOf('/', start); if (posn >= 0) { start = posn; } else { diff -r e323c74edabd src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java --- a/src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -303,7 +303,7 @@ offset = pname.length() - 1; - while ((last = pname.lastIndexOf(".", offset)) != -1) { + while ((last = pname.lastIndexOf('.', offset)) != -1) { pname = pname.substring(0, last+1) + "*"; x = permissions.get(pname); @@ -318,7 +318,7 @@ pname = p.getName(); offset = pname.length() - 1; - while ((last = pname.lastIndexOf("=", offset)) != -1) { + while ((last = pname.lastIndexOf('=', offset)) != -1) { pname = pname.substring(0, last+1) + "*"; x = permissions.get(pname); diff -r e323c74edabd src/share/classes/com/sun/rowset/CachedRowSetImpl.java --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Sat Apr 26 07:31:04 2014 -0300 @@ -6831,7 +6831,7 @@ // table name else isolate table name. indexFrom = command.toLowerCase().indexOf("from"); - indexComma = command.indexOf(",", indexFrom); + indexComma = command.indexOf(',', indexFrom); if(indexComma == -1) { // implies only one table diff -r e323c74edabd src/share/classes/com/sun/rowset/JoinRowSetImpl.java --- a/src/share/classes/com/sun/rowset/JoinRowSetImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/JoinRowSetImpl.java Sat Apr 26 07:31:04 2014 -0300 @@ -910,7 +910,7 @@ // now remove the last "," strWhereClause = strWhereClause.substring - (0, strWhereClause.lastIndexOf(",")); + (0, strWhereClause.lastIndexOf(',')); // Add from clause strWhereClause = strWhereClause.concat(" from "); @@ -920,7 +920,7 @@ //Remove the last "," strWhereClause = strWhereClause.substring - (0, strWhereClause.lastIndexOf(",")); + (0, strWhereClause.lastIndexOf(',')); // Add the where clause strWhereClause = strWhereClause.concat(" where "); diff -r e323c74edabd src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java --- a/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Sat Apr 26 07:31:04 2014 -0300 @@ -240,7 +240,7 @@ // Remove the string after "@xxxx" // before writing it to the xml file. String strProviderInstance = (caller.getSyncProvider()).toString(); - String strProvider = strProviderInstance.substring(0, (caller.getSyncProvider()).toString().indexOf("@")); + String strProvider = strProviderInstance.substring(0, (caller.getSyncProvider()).toString().indexOf('@')); propString("sync-provider-name", strProvider); propString("sync-provider-vendor", "Oracle Corporation"); diff -r e323c74edabd src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java --- a/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Sat Apr 26 07:31:04 2014 -0300 @@ -1147,7 +1147,7 @@ if (nullValue) { rs.setSyncProvider(null); } else { - String str = s.substring(0,s.indexOf("@")+1); + String str = s.substring(0,s.indexOf('@')+1); rs.setSyncProvider(str); } break; diff -r e323c74edabd src/share/classes/com/sun/rowset/internal/XmlResolver.java --- a/src/share/classes/com/sun/rowset/internal/XmlResolver.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/internal/XmlResolver.java Sat Apr 26 07:31:04 2014 -0300 @@ -39,7 +39,7 @@ public class XmlResolver implements EntityResolver { public InputSource resolveEntity(String publicId, String systemId) { - String schemaName = systemId.substring(systemId.lastIndexOf("/")); + String schemaName = systemId.substring(systemId.lastIndexOf('/')); if(systemId.startsWith("http://java.sun.com/xml/ns/jdbc")) { return new InputSource(this.getClass().getResourceAsStream(schemaName)); diff -r e323c74edabd src/share/classes/com/sun/security/auth/module/JndiLoginModule.java --- a/src/share/classes/com/sun/security/auth/module/JndiLoginModule.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/security/auth/module/JndiLoginModule.java Sat Apr 26 07:31:04 2014 -0300 @@ -694,7 +694,7 @@ throw new LoginException("Error: no CallbackHandler available " + "to garner authentication information from the user"); - String protocol = userProvider.substring(0, userProvider.indexOf(":")); + String protocol = userProvider.substring(0, userProvider.indexOf(':')); Callback[] callbacks = new Callback[2]; callbacks[0] = new NameCallback(protocol + " " diff -r e323c74edabd src/share/classes/com/sun/security/auth/module/LdapLoginModule.java --- a/src/share/classes/com/sun/security/auth/module/LdapLoginModule.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/security/auth/module/LdapLoginModule.java Sat Apr 26 07:31:04 2014 -0300 @@ -400,7 +400,7 @@ // Add any JNDI properties to the environment for (String key : options.keySet()) { - if (key.indexOf(".") > -1) { + if (key.indexOf('.') > -1) { ldapEnvironment.put(key, options.get(key)); } } diff -r e323c74edabd src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java --- a/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java Sat Apr 26 07:31:04 2014 -0300 @@ -857,7 +857,7 @@ bpSpec = runtime.createClassLineBreakpoint(classId, lineNumber); } else { // Try stripping method from class.method token. - int idot = token.lastIndexOf("."); + int idot = token.lastIndexOf('.'); if ( (idot <= 0) || /* No dot or dot in first char */ (idot >= token.length() - 1) ) { /* dot in last char */ return null; diff -r e323c74edabd src/share/classes/com/sun/tools/example/debug/tty/Commands.java --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sat Apr 26 07:31:04 2014 -0300 @@ -1079,7 +1079,7 @@ } } else { // Try stripping method from class.method token. - int idot = token.lastIndexOf("."); + int idot = token.lastIndexOf('.'); if ( (idot <= 0) || /* No dot or dot in first char */ (idot >= token.length() - 1) ) { /* dot in last char */ printBreakpointCommandUsage(atForm, inForm); diff -r e323c74edabd src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java --- a/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java Sat Apr 26 07:31:04 2014 -0300 @@ -67,7 +67,7 @@ continue; } String name = clazz.getName(); - int pos = name.lastIndexOf("."); + int pos = name.lastIndexOf('.'); String pkg; if (name.startsWith("[")) { // Only in ancient heap dumps pkg = ""; diff -r e323c74edabd src/share/classes/java/lang/Class.java --- a/src/share/classes/java/lang/Class.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/lang/Class.java Sat Apr 26 07:31:04 2014 -0300 @@ -1296,7 +1296,7 @@ String simpleName = getSimpleBinaryName(); if (simpleName == null) { // top level class simpleName = getName(); - return simpleName.substring(simpleName.lastIndexOf(".")+1); // strip the package name + return simpleName.substring(simpleName.lastIndexOf('.')+1); // strip the package name } // According to JLS3 "Binary Compatibility" (13.1) the binary // name of non-package classes (not top level) is the binary diff -r e323c74edabd src/share/classes/java/lang/ClassLoader.java --- a/src/share/classes/java/lang/ClassLoader.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/lang/ClassLoader.java Sat Apr 26 07:31:04 2014 -0300 @@ -2136,7 +2136,7 @@ return result.booleanValue(); // Check for most specific package entry - int dotIndex = className.lastIndexOf("."); + int dotIndex = className.lastIndexOf('.'); if (dotIndex < 0) { // default package result = packageAssertionStatus.get(null); if (result != null) @@ -2147,7 +2147,7 @@ result = packageAssertionStatus.get(className); if (result != null) return result.booleanValue(); - dotIndex = className.lastIndexOf(".", dotIndex-1); + dotIndex = className.lastIndexOf('.', dotIndex-1); } // Return the classloader default diff -r e323c74edabd src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java --- a/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Sat Apr 26 07:31:04 2014 -0300 @@ -84,7 +84,7 @@ private InvokerBytecodeGenerator(LambdaForm lambdaForm, int localsMapSize, String className, String invokerName, MethodType invokerType) { if (invokerName.contains(".")) { - int p = invokerName.indexOf("."); + int p = invokerName.indexOf('.'); className = invokerName.substring(0, p); invokerName = invokerName.substring(p+1); } diff -r e323c74edabd src/share/classes/java/net/CookieManager.java --- a/src/share/classes/java/net/CookieManager.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/net/CookieManager.java Sat Apr 26 07:31:04 2014 -0300 @@ -294,7 +294,7 @@ // the path is the directory of the page/doc String path = uri.getPath(); if (!path.endsWith("/")) { - int i = path.lastIndexOf("/"); + int i = path.lastIndexOf('/'); if (i > 0) { path = path.substring(0, i + 1); } else { @@ -364,7 +364,7 @@ static private boolean isInPortList(String lst, int port) { - int i = lst.indexOf(","); + int i = lst.indexOf(','); int val = -1; while (i > 0) { try { @@ -375,7 +375,7 @@ } catch (NumberFormatException numberFormatException) { } lst = lst.substring(i+1); - i = lst.indexOf(","); + i = lst.indexOf(','); } if (!lst.isEmpty()) { try { diff -r e323c74edabd src/share/classes/java/net/InetAddress.java --- a/src/share/classes/java/net/InetAddress.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/net/InetAddress.java Sat Apr 26 07:31:04 2014 -0300 @@ -1138,7 +1138,7 @@ // This is supposed to be an IPv6 literal // Check if a numeric or string zone id is present int pos; - if ((pos=host.indexOf ("%")) != -1) { + if ((pos=host.indexOf ('%')) != -1) { numericZone = checkNumericZone (host); if (numericZone == -1) { /* remainder of string must be an ifname */ ifname = host.substring (pos+1); diff -r e323c74edabd src/share/classes/java/net/SocketPermission.java --- a/src/share/classes/java/net/SocketPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/net/SocketPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -777,7 +777,7 @@ // Literal IPv6 address host = getName().substring(1, getName().indexOf(']')); } else { - int i = getName().indexOf(":"); + int i = getName().indexOf(':'); if (i == -1) host = getName(); else { diff -r e323c74edabd src/share/classes/java/net/SocksSocketImpl.java --- a/src/share/classes/java/net/SocksSocketImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/net/SocksSocketImpl.java Sat Apr 26 07:31:04 2014 -0300 @@ -368,7 +368,7 @@ String host = epoint.getHostString(); // IPv6 litteral? if (epoint.getAddress() instanceof Inet6Address && - (!host.startsWith("[")) && (host.indexOf(":") >= 0)) { + (!host.startsWith("[")) && (host.indexOf(':') >= 0)) { host = "[" + host + "]"; } try { @@ -684,7 +684,7 @@ String host = saddr.getHostString(); // IPv6 litteral? if (saddr.getAddress() instanceof Inet6Address && - (!host.startsWith("[")) && (host.indexOf(":") >= 0)) { + (!host.startsWith("[")) && (host.indexOf(':') >= 0)) { host = "[" + host + "]"; } try { diff -r e323c74edabd src/share/classes/java/net/URI.java --- a/src/share/classes/java/net/URI.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/net/URI.java Sat Apr 26 07:31:04 2014 -0300 @@ -1851,9 +1851,9 @@ sb.append("//"); if (authority.startsWith("[")) { // authority should (but may not) contain an embedded IPv6 address - int end = authority.indexOf("]"); + int end = authority.indexOf(']'); String doquote = authority, dontquote = ""; - if (end != -1 && authority.indexOf(":") != -1) { + if (end != -1 && authority.indexOf(':') != -1) { // the authority contains an IPv6 address if (end == authority.length()) { dontquote = authority; @@ -1889,8 +1889,8 @@ * because we must not quote a literal IPv6 address */ if (opaquePart.startsWith("//[")) { - int end = opaquePart.indexOf("]"); - if (end != -1 && opaquePart.indexOf(":")!=-1) { + int end = opaquePart.indexOf(']'); + if (end != -1 && opaquePart.indexOf(':')!=-1) { String doquote, dontquote; if (end == opaquePart.length()) { dontquote = opaquePart; diff -r e323c74edabd src/share/classes/java/security/BasicPermission.java --- a/src/share/classes/java/security/BasicPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/security/BasicPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -430,7 +430,7 @@ offset = path.length()-1; - while ((last = path.lastIndexOf(".", offset)) != -1) { + while ((last = path.lastIndexOf('.', offset)) != -1) { path = path.substring(0, last+1) + "*"; //System.out.println("check "+path); diff -r e323c74edabd src/share/classes/java/security/Provider.java --- a/src/share/classes/java/security/Provider.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/security/Provider.java Sat Apr 26 07:31:04 2014 -0300 @@ -927,7 +927,7 @@ } private String[] getTypeAndAlgorithm(String key) { - int i = key.indexOf("."); + int i = key.indexOf('.'); if (i < 1) { if (debug != null) { debug.println("Ignoring invalid entry in provider " diff -r e323c74edabd src/share/classes/java/security/Security.java --- a/src/share/classes/java/security/Security.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/security/Security.java Sat Apr 26 07:31:04 2014 -0300 @@ -1114,7 +1114,7 @@ // implementation of an algorithm. We are only interested // in entries which lead to the implementation // classes. - if (currentKey.indexOf(" ") < 0) { + if (currentKey.indexOf(' ') < 0) { result.add(currentKey.substring( serviceName.length() + 1)); } diff -r e323c74edabd src/share/classes/java/util/PropertyPermission.java --- a/src/share/classes/java/util/PropertyPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/util/PropertyPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -547,7 +547,7 @@ offset = name.length()-1; - while ((last = name.lastIndexOf(".", offset)) != -1) { + while ((last = name.lastIndexOf('.', offset)) != -1) { name = name.substring(0, last+1) + "*"; //System.out.println("check "+name); diff -r e323c74edabd src/share/classes/java/util/jar/JarVerifier.java --- a/src/share/classes/java/util/jar/JarVerifier.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/util/jar/JarVerifier.java Sat Apr 26 07:31:04 2014 -0300 @@ -278,7 +278,7 @@ // now we are parsing a signature block file - String key = uname.substring(0, uname.lastIndexOf(".")); + String key = uname.substring(0, uname.lastIndexOf('.')); if (signerCache == null) signerCache = new ArrayList<>(); diff -r e323c74edabd src/share/classes/java/util/logging/LogManager.java --- a/src/share/classes/java/util/logging/LogManager.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/util/logging/LogManager.java Sat Apr 26 07:31:04 2014 -0300 @@ -866,7 +866,7 @@ int ix = 1; for (;;) { - int ix2 = name.indexOf(".", ix); + int ix2 = name.indexOf('.', ix); if (ix2 < 0) { break; } @@ -889,7 +889,7 @@ } LogNode node = root; while (name.length() > 0) { - int ix = name.indexOf("."); + int ix = name.indexOf('.'); String head; if (ix > 0) { head = name.substring(0, ix); diff -r e323c74edabd src/share/classes/java/util/logging/XMLFormatter.java --- a/src/share/classes/java/util/logging/XMLFormatter.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/util/logging/XMLFormatter.java Sat Apr 26 07:31:04 2014 -0300 @@ -174,7 +174,7 @@ // Check to see if the parameter was not a messagetext format // or was not null or empty if ( parameters != null && parameters.length != 0 - && record.getMessage().indexOf("{") == -1 ) { + && record.getMessage().indexOf('{') == -1 ) { for (int i = 0; i < parameters.length; i++) { sb.append(" "); try { diff -r e323c74edabd src/share/classes/javax/management/MBeanPermission.java --- a/src/share/classes/javax/management/MBeanPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/management/MBeanPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -290,7 +290,7 @@ // Parse ObjectName - int openingBracket = name.indexOf("["); + int openingBracket = name.indexOf('['); if (openingBracket == -1) { // If "[on]" missing then ObjectName("*:*") // @@ -329,7 +329,7 @@ // Parse member - int poundSign = name.indexOf("#"); + int poundSign = name.indexOf('#'); if (poundSign == -1) setMember("*"); diff -r e323c74edabd src/share/classes/javax/management/modelmbean/DescriptorSupport.java --- a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Sat Apr 26 07:31:04 2014 -0300 @@ -329,7 +329,7 @@ inFld = false; } else if (inFld && inDesc) { // want kw=value, eg, name="myname" value="myvalue" - int eq_separator = tok.indexOf("="); + int eq_separator = tok.indexOf('='); if (eq_separator > 0) { String kwPart = tok.substring(0,eq_separator); String valPart = tok.substring(eq_separator+1); @@ -458,7 +458,7 @@ if ((fields[i] == null) || (fields[i].equals(""))) { continue; } - int eq_separator = fields[i].indexOf("="); + int eq_separator = fields[i].indexOf('='); if (eq_separator < 0) { // illegal if no = or is first character if (MODELMBEAN_LOGGER.isLoggable(Level.FINEST)) { diff -r e323c74edabd src/share/classes/javax/management/modelmbean/RequiredModelMBean.java --- a/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Sat Apr 26 07:31:04 2014 -0300 @@ -934,7 +934,7 @@ String opMethodName; // Parse for class name and method - int opSplitter = opName.lastIndexOf("."); + int opSplitter = opName.lastIndexOf('.'); if (opSplitter > 0) { opClassName = opName.substring(0,opSplitter); opMethodName = opName.substring(opSplitter+1); @@ -943,7 +943,7 @@ /* Ignore anything after a left paren. We keep this for compatibility but it isn't specified. */ - opSplitter = opMethodName.indexOf("("); + opSplitter = opMethodName.indexOf('('); if (opSplitter > 0) opMethodName = opMethodName.substring(0,opSplitter); diff -r e323c74edabd src/share/classes/javax/security/auth/PrivateCredentialPermission.java --- a/src/share/classes/javax/security/auth/PrivateCredentialPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/security/auth/PrivateCredentialPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -495,7 +495,7 @@ // perform new initialization from the permission name - if (getName().indexOf(" ") == -1 && getName().indexOf("\"") == -1) { + if (getName().indexOf(' ') == -1 && getName().indexOf('\"') == -1) { // name only has a credential class specified credentialClass = getName(); diff -r e323c74edabd src/share/classes/javax/security/sasl/Sasl.java --- a/src/share/classes/javax/security/sasl/Sasl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/security/sasl/Sasl.java Sat Apr 26 07:31:04 2014 -0300 @@ -600,7 +600,7 @@ // implementation of an algorithm. We are only interested // in entries which lead to the implementation // classes. - if (currentKey.indexOf(" ") < 0) { + if (currentKey.indexOf(' ') < 0) { String className = providers[i].getProperty(currentKey); if (!classes.contains(className)) { classes.add(className); diff -r e323c74edabd src/share/classes/javax/swing/JEditorPane.java --- a/src/share/classes/javax/swing/JEditorPane.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/swing/JEditorPane.java Sat Apr 26 07:31:04 2014 -0300 @@ -964,7 +964,7 @@ // The type could have optional info is part of it, // for example some charset info. We need to strip that // of and save it. - int parm = type.indexOf(";"); + int parm = type.indexOf(';'); if (parm > -1) { // Save the paramList. String paramList = type.substring(parm); diff -r e323c74edabd src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java --- a/src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Sat Apr 26 07:31:04 2014 -0300 @@ -653,7 +653,7 @@ // strip off the prefix, if there is one. String fullKey = key.toString(); - String partialKey = fullKey.substring(fullKey.indexOf(".") + 1); + String partialKey = fullKey.substring(fullKey.indexOf('.') + 1); Object obj = null; int xstate = getExtendedState(ctx, v); diff -r e323c74edabd src/share/classes/sun/applet/AppletClassLoader.java --- a/src/share/classes/sun/applet/AppletClassLoader.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/applet/AppletClassLoader.java Sat Apr 26 07:31:04 2014 -0300 @@ -168,7 +168,7 @@ */ protected Class findClass(String name) throws ClassNotFoundException { - int index = name.indexOf(";"); + int index = name.indexOf(';'); String cookie = ""; if(index != -1) { cookie = name.substring(index, name.length()); @@ -608,7 +608,7 @@ // deal with URL rewriting String cookie = null; - int index = name.indexOf(";"); + int index = name.indexOf(';'); if(index != -1) { cookie = name.substring(index, name.length()); name = name.substring(0, index); diff -r e323c74edabd src/share/classes/sun/awt/FontConfiguration.java --- a/src/share/classes/sun/awt/FontConfiguration.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/awt/FontConfiguration.java Sat Apr 26 07:31:04 2014 -0300 @@ -272,9 +272,9 @@ if (configFile != null) { return configFile; } - int decimalPointIndex = osVersion.indexOf("."); + int decimalPointIndex = osVersion.indexOf('.'); if (decimalPointIndex != -1) { - osMajorVersion = osVersion.substring(0, osVersion.indexOf(".")); + osMajorVersion = osVersion.substring(0, osVersion.indexOf('.')); configFile = findImpl(baseName + "." + osName + "." + osMajorVersion); if (configFile != null) { return configFile; diff -r e323c74edabd src/share/classes/sun/font/Type1Font.java --- a/src/share/classes/sun/font/Type1Font.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/font/Type1Font.java Sat Apr 26 07:31:04 2014 -0300 @@ -492,7 +492,7 @@ //Conversion: Expand abbreviations in style portion (everything after '-'), // replace '-' with space and insert missing spaces - pos = name.indexOf("-"); + pos = name.indexOf('-'); if (pos >= 0) { res = expandName(name.substring(0, pos), false); res += " " + expandName(name.substring(pos+1), true); @@ -513,8 +513,8 @@ //Conversion: Truncate style portion (everything after '-') // and insert missing spaces - if (tmp.indexOf("-") > 0) { - tmp = tmp.substring(0, tmp.indexOf("-")); + if (tmp.indexOf('-') > 0) { + tmp = tmp.substring(0, tmp.indexOf('-')); } return expandName(tmp, false); diff -r e323c74edabd src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java --- a/src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java Sat Apr 26 07:31:04 2014 -0300 @@ -84,7 +84,7 @@ * {@inheritDoc} */ public String getBaseName() { - int baseIndex = name.lastIndexOf(".")+1; + int baseIndex = name.lastIndexOf('.') + 1; return name.substring(baseIndex); } diff -r e323c74edabd src/share/classes/sun/jvmstat/monitor/HostIdentifier.java --- a/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Sat Apr 26 07:31:04 2014 -0300 @@ -138,8 +138,8 @@ String frag = u.getFragment(); URI u2 = null; - int c1index = uriString.indexOf(":"); - int c2index = uriString.lastIndexOf(":"); + int c1index = uriString.indexOf(':'); + int c2index = uriString.lastIndexOf(':'); if (c2index != c1index) { /* * this is the scheme:hostname:port case. Attempt to diff -r e323c74edabd src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java Sat Apr 26 07:31:04 2014 -0300 @@ -70,8 +70,8 @@ String addrStr; if (target.startsWith("[")) { - final int index = target.indexOf("]"); - final int index2 = target.lastIndexOf(":"); + final int index = target.indexOf(']'); + final int index2 = target.lastIndexOf(':'); if(index == -1) throw new IllegalArgumentException("Host starts with [ but " + "does not end with ]"); @@ -85,8 +85,8 @@ if (addrStr.startsWith("[")) throw new IllegalArgumentException("More than one [[...]]"); } else { - final int index = target.indexOf(":"); - final int index2 = target.lastIndexOf(":"); + final int index = target.indexOf(':'); + final int index2 = target.lastIndexOf(':'); if(index == -1) throw new IllegalArgumentException("Missing port separator \":\""); addrStr = target.substring(0, index); @@ -98,7 +98,7 @@ address = InetAddress.getByName(addrStr); //THE CHECK SHOULD BE STRONGER!!! - final int index = target.lastIndexOf(":"); + final int index = target.lastIndexOf(':'); community = target.substring(index + 1, target.length()); diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sat Apr 26 07:31:04 2014 -0300 @@ -273,8 +273,8 @@ else { // Look for index of "." in the string - int sIdx = source.indexOf("."); - int tIdx = target.indexOf("."); + int sIdx = source.indexOf('.'); + int tIdx = target.indexOf('.'); if (sIdx == -1) sIdx = source.length() - 1; @@ -304,10 +304,10 @@ String versionError = mf.format(args); // Look for "-" for pre-release - int prIndex = token.indexOf("-"); + int prIndex = token.indexOf('-'); // Look for "_" for patch release - int patchIndex = token.indexOf("_"); + int patchIndex = token.indexOf('_'); if (prIndex == -1 && patchIndex == -1) { diff -r e323c74edabd src/share/classes/sun/misc/JarIndex.java --- a/src/share/classes/sun/misc/JarIndex.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/misc/JarIndex.java Sat Apr 26 07:31:04 2014 -0300 @@ -172,7 +172,7 @@ if ((jarFiles = indexMap.get(fileName)) == null) { /* try the package name again */ int pos; - if((pos = fileName.lastIndexOf("/")) != -1) { + if((pos = fileName.lastIndexOf('/')) != -1) { jarFiles = indexMap.get(fileName.substring(0, pos)); } } @@ -195,7 +195,7 @@ public void add(String fileName, String jarName) { String packageName; int pos; - if((pos = fileName.lastIndexOf("/")) != -1) { + if((pos = fileName.lastIndexOf('/')) != -1) { packageName = fileName.substring(0, pos); } else { packageName = fileName; diff -r e323c74edabd src/share/classes/sun/misc/URLClassPath.java --- a/src/share/classes/sun/misc/URLClassPath.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/misc/URLClassPath.java Sat Apr 26 07:31:04 2014 -0300 @@ -793,7 +793,7 @@ boolean validIndex(final String name) { String packageName = name; int pos; - if((pos = name.lastIndexOf("/")) != -1) { + if((pos = name.lastIndexOf('/')) != -1) { packageName = name.substring(0, pos); } @@ -803,7 +803,7 @@ while (enum_.hasMoreElements()) { entry = enum_.nextElement(); entryName = entry.getName(); - if((pos = entryName.lastIndexOf("/")) != -1) + if((pos = entryName.lastIndexOf('/')) != -1) entryName = entryName.substring(0, pos); if (entryName.equals(packageName)) { return true; @@ -900,7 +900,7 @@ */ JarIndex newIndex = newLoader.getIndex(); if(newIndex != null) { - int pos = jarName.lastIndexOf("/"); + int pos = jarName.lastIndexOf('/'); newIndex.merge(this.index, (pos == -1 ? null : jarName.substring(0, pos + 1))); } diff -r e323c74edabd src/share/classes/sun/net/ftp/impl/FtpClient.java --- a/src/share/classes/sun/net/ftp/impl/FtpClient.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/net/ftp/impl/FtpClient.java Sat Apr 26 07:31:04 2014 -0300 @@ -259,7 +259,7 @@ d = null; } if (d != null && time != null) { - int c = time.indexOf(":"); + int c = time.indexOf(':'); now.setTime(d); now.set(Calendar.HOUR, Integer.parseInt(time.substring(0, c))); now.set(Calendar.MINUTE, Integer.parseInt(time.substring(c + 1))); @@ -295,7 +295,7 @@ public FtpDirEntry parseLine(String line) { String name = null; - int i = line.lastIndexOf(";"); + int i = line.lastIndexOf(';'); if (i > 0) { name = line.substring(i + 1).trim(); line = line.substring(0, i); @@ -306,7 +306,7 @@ FtpDirEntry file = new FtpDirEntry(name); while (!line.isEmpty()) { String s; - i = line.indexOf(";"); + i = line.indexOf(';'); if (i > 0) { s = line.substring(0, i); line = line.substring(i + 1); @@ -314,7 +314,7 @@ s = line; line = ""; } - i = s.indexOf("="); + i = s.indexOf('='); if (i > 0) { String fact = s.substring(0, i); String value = s.substring(i + 1); diff -r e323c74edabd src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java --- a/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java Sat Apr 26 07:31:04 2014 -0300 @@ -325,7 +325,7 @@ while (i.hasNext()) { String parentDomain = i.next(); int start = 0; - while ((start = parentDomain.indexOf(".")) != -1 + while ((start = parentDomain.indexOf('.')) != -1 && start < parentDomain.length() -1) { try { results = resolve(ctx, host+"."+parentDomain, ids, 0); diff -r e323c74edabd src/share/classes/sun/net/util/IPAddressUtil.java --- a/src/share/classes/sun/net/util/IPAddressUtil.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/net/util/IPAddressUtil.java Sat Apr 26 07:31:04 2014 -0300 @@ -149,7 +149,7 @@ byte[] dst = new byte[INADDR16SZ]; int srcb_length = srcb.length; - int pc = src.indexOf ("%"); + int pc = src.indexOf ('%'); if (pc == srcb_length -1) { return null; } diff -r e323c74edabd src/share/classes/sun/net/www/ParseUtil.java --- a/src/share/classes/sun/net/www/ParseUtil.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/net/www/ParseUtil.java Sat Apr 26 07:31:04 2014 -0300 @@ -356,8 +356,8 @@ * because we must not quote a literal IPv6 address */ if (opaquePart.startsWith("//[")) { - int end = opaquePart.indexOf("]"); - if (end != -1 && opaquePart.indexOf(":")!=-1) { + int end = opaquePart.indexOf(']'); + if (end != -1 && opaquePart.indexOf(':')!=-1) { String doquote, dontquote; if (end == opaquePart.length()) { dontquote = opaquePart; @@ -408,8 +408,8 @@ } else if (authority != null) { sb.append("//"); if (authority.startsWith("[")) { - int end = authority.indexOf("]"); - if (end != -1 && authority.indexOf(":")!=-1) { + int end = authority.indexOf(']'); + if (end != -1 && authority.indexOf(':')!=-1) { String doquote, dontquote; if (end == authority.length()) { dontquote = authority; diff -r e323c74edabd src/share/classes/sun/reflect/misc/ReflectUtil.java --- a/src/share/classes/sun/reflect/misc/ReflectUtil.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/reflect/misc/ReflectUtil.java Sat Apr 26 07:31:04 2014 -0300 @@ -341,6 +341,6 @@ * (not to be confused with a Java Language anonymous inner class). */ public static boolean isVMAnonymousClass(Class cls) { - return cls.getName().indexOf("/") > -1; + return cls.getName().indexOf('/') > -1; } } diff -r e323c74edabd src/share/classes/sun/rmi/runtime/Log.java --- a/src/share/classes/sun/rmi/runtime/Log.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/rmi/runtime/Log.java Sat Apr 26 07:31:04 2014 -0300 @@ -434,7 +434,7 @@ * Mimic old log messages that only contain unqualified names. */ private static String unqualifiedName(String name) { - int lastDot = name.lastIndexOf("."); + int lastDot = name.lastIndexOf('.'); if (lastDot >= 0) { name = name.substring(lastDot + 1); } diff -r e323c74edabd src/share/classes/sun/rmi/transport/proxy/CGIHandler.java --- a/src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Sat Apr 26 07:31:04 2014 -0300 @@ -141,7 +141,7 @@ { try { String command, param; - int delim = QueryString.indexOf("="); + int delim = QueryString.indexOf('='); if (delim == -1) { command = QueryString; param = ""; diff -r e323c74edabd src/share/classes/sun/security/jgss/wrapper/Krb5Util.java --- a/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Sat Apr 26 07:31:04 2014 -0300 @@ -39,7 +39,7 @@ static String getTGSName(GSSNameElement name) throws GSSException { String krbPrinc = name.getKrbName(); - int atIndex = krbPrinc.indexOf("@"); + int atIndex = krbPrinc.indexOf('@'); String realm = krbPrinc.substring(atIndex + 1); StringBuffer buf = new StringBuffer("krbtgt/"); buf.append(realm).append('@').append(realm); diff -r e323c74edabd src/share/classes/sun/security/provider/PolicyFile.java --- a/src/share/classes/sun/security/provider/PolicyFile.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/provider/PolicyFile.java Sat Apr 26 07:31:04 2014 -0300 @@ -1856,7 +1856,7 @@ int colonIndex; String prefix = value; String suffix; - if ((colonIndex = value.indexOf(":")) != -1) { + if ((colonIndex = value.indexOf(':')) != -1) { prefix = value.substring(0, colonIndex); } diff -r e323c74edabd src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java --- a/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java Sat Apr 26 07:31:04 2014 -0300 @@ -338,7 +338,7 @@ } String sigType; if (keyType.contains("_")) { - int k = keyType.indexOf("_"); + int k = keyType.indexOf('_'); sigType = keyType.substring(k + 1); keyType = keyType.substring(0, k); } else { diff -r e323c74edabd src/share/classes/sun/security/ssl/X509KeyManagerImpl.java --- a/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java Sat Apr 26 07:31:04 2014 -0300 @@ -302,7 +302,7 @@ final String sigKeyAlgorithm; KeyType(String algorithm) { - int k = algorithm.indexOf("_"); + int k = algorithm.indexOf('_'); if (k == -1) { keyAlgorithm = algorithm; sigKeyAlgorithm = null; diff -r e323c74edabd src/share/classes/sun/security/util/HostnameChecker.java --- a/src/share/classes/sun/security/util/HostnameChecker.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/util/HostnameChecker.java Sat Apr 26 07:31:04 2014 -0300 @@ -300,8 +300,8 @@ template = template.toLowerCase(Locale.ENGLISH); // Retreive leftmost component - int templateIdx = template.indexOf("."); - int nameIdx = name.indexOf("."); + int templateIdx = template.indexOf('.'); + int nameIdx = name.indexOf('.'); if (templateIdx == -1) templateIdx = template.length(); @@ -326,7 +326,7 @@ */ private static boolean matchWildCards(String name, String template) { - int wildcardIdx = template.indexOf("*"); + int wildcardIdx = template.indexOf('*'); if (wildcardIdx == -1) return name.equals(template); @@ -349,7 +349,7 @@ // update the match scope name = name.substring(beforeStartIdx + beforeWildcard.length()); - wildcardIdx = afterWildcard.indexOf("*"); + wildcardIdx = afterWildcard.indexOf('*'); } return name.endsWith(afterWildcard); } diff -r e323c74edabd src/share/classes/sun/security/util/SignatureFileVerifier.java --- a/src/share/classes/sun/security/util/SignatureFileVerifier.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/util/SignatureFileVerifier.java Sat Apr 26 07:31:04 2014 -0300 @@ -98,7 +98,7 @@ } finally { Providers.stopJarVerification(obj); } - this.name = name.substring(0, name.lastIndexOf(".")) + this.name = name.substring(0, name.lastIndexOf('.')) .toUpperCase(Locale.ENGLISH); this.md = md; this.signerCache = signerCache; diff -r e323c74edabd src/share/classes/sun/security/x509/CRLExtensions.java --- a/src/share/classes/sun/security/x509/CRLExtensions.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/x509/CRLExtensions.java Sat Apr 26 07:31:04 2014 -0300 @@ -185,7 +185,7 @@ String name; String id = attr.getPrefix(); if (id.equalsIgnoreCase(X509CertImpl.NAME)) { // fully qualified - int index = alias.lastIndexOf("."); + int index = alias.lastIndexOf('.'); name = alias.substring(index + 1); } else name = alias; diff -r e323c74edabd src/share/classes/sun/tools/jconsole/ConnectDialog.java --- a/src/share/classes/sun/tools/jconsole/ConnectDialog.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/ConnectDialog.java Sat Apr 26 07:31:04 2014 -0300 @@ -325,7 +325,7 @@ } else { String host = remoteTF.getText().trim(); String port = "0"; - int index = host.lastIndexOf(":"); + int index = host.lastIndexOf(':'); if (index >= 0) { port = host.substring(index + 1); host = host.substring(0, index); diff -r e323c74edabd src/share/classes/sun/tools/jconsole/inspector/Utils.java --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat Apr 26 07:31:04 2014 -0300 @@ -210,7 +210,7 @@ public static String getArrayClassName(String name) { String className = null; if (name.startsWith("[")) { - int index = name.lastIndexOf("["); + int index = name.lastIndexOf('['); className = name.substring(index, name.length()); if (className.startsWith("[L")) { className = className.substring(2, className.length() - 1); @@ -241,7 +241,7 @@ if (className == null) { return name; } - int index = name.lastIndexOf("["); + int index = name.lastIndexOf('['); StringBuilder brackets = new StringBuilder(className); for (int i = 0; i <= index; i++) { brackets.append("[]"); diff -r e323c74edabd src/share/classes/sun/tools/jconsole/inspector/XOperations.java --- a/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Sat Apr 26 07:31:04 2014 -0300 @@ -112,7 +112,7 @@ if (methodLabel.getText().length() > 20) { methodLabel.setText(methodLabel.getText(). substring(methodLabel.getText(). - lastIndexOf(".") + 1, + lastIndexOf('.') + 1, methodLabel.getText().length())); } diff -r e323c74edabd src/share/classes/sun/tools/jconsole/inspector/XTree.java --- a/src/share/classes/sun/tools/jconsole/inspector/XTree.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/XTree.java Sat Apr 26 07:31:04 2014 -0300 @@ -475,7 +475,7 @@ private static Map extractKeyValuePairs( String props, ObjectName mbean) { Map map = new LinkedHashMap(); - int eq = props.indexOf("="); + int eq = props.indexOf('='); while (eq != -1) { String key = props.substring(0, eq); String value = mbean.getKeyProperty(key); @@ -484,7 +484,7 @@ if (props.startsWith(",")) { props = props.substring(1); } - eq = props.indexOf("="); + eq = props.indexOf('='); } return map; } @@ -821,7 +821,7 @@ } private void buildKeyValue() { - int index = tokenValue.indexOf("="); + int index = tokenValue.indexOf('='); if (index < 0) { key = tokenValue; value = tokenValue; -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 -------------- next part -------------- diff -r e323c74edabd src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java --- a/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Sat Apr 26 07:31:04 2014 -0300 @@ -547,7 +547,7 @@ i = strLowerCase.indexOf("", i); if (i > 0) { i += "".length(); - int i2 = str.indexOf("<", i); + int i2 = str.indexOf('<', i); return str.substring(i, i2); } } diff -r e323c74edabd src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java --- a/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Sat Apr 26 07:31:04 2014 -0300 @@ -512,7 +512,7 @@ } static String qualifiedStringValue(String s1, String s234) { // Qualification by dot must decompose uniquely. Second string might already be qualified. - assert(s1.indexOf(".") < 0); + assert(s1.indexOf('.') < 0); return s1+"."+s234; } diff -r e323c74edabd src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java --- a/src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java Sat Apr 26 07:31:04 2014 -0300 @@ -102,7 +102,7 @@ } location = url.substring(addrStart, addrEnd); - int keyStart = location.indexOf("/"); + int keyStart = location.indexOf('/'); if (keyStart >= 0) { // Has key string if (keyStart == (location.length() -1)) { diff -r e323c74edabd src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java --- a/src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java Sat Apr 26 07:31:04 2014 -0300 @@ -336,7 +336,7 @@ String url = "rmi://"; // Enclose IPv6 literal address in '[' and ']' - url = (host.indexOf(":") > -1) ? url + "[" + host + "]" : + url = (host.indexOf(':') > -1) ? url + "[" + host + "]" : url + host; if (port > 0) { url += ":" + Integer.toString(port); diff -r e323c74edabd src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java --- a/src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Sat Apr 26 07:31:04 2014 -0300 @@ -149,7 +149,7 @@ * foo:rest/of/name foo: */ protected String getURLPrefix(String url) throws NamingException { - int start = url.indexOf(":"); + int start = url.indexOf(':'); if (start < 0) { throw new OperationNotSupportedException("Invalid URL: " + url); @@ -160,7 +160,7 @@ start += 2; // skip double slash // find last slash - int posn = url.indexOf("/", start); + int posn = url.indexOf('/', start); if (posn >= 0) { start = posn; } else { diff -r e323c74edabd src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java --- a/src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -303,7 +303,7 @@ offset = pname.length() - 1; - while ((last = pname.lastIndexOf(".", offset)) != -1) { + while ((last = pname.lastIndexOf('.', offset)) != -1) { pname = pname.substring(0, last+1) + "*"; x = permissions.get(pname); @@ -318,7 +318,7 @@ pname = p.getName(); offset = pname.length() - 1; - while ((last = pname.lastIndexOf("=", offset)) != -1) { + while ((last = pname.lastIndexOf('=', offset)) != -1) { pname = pname.substring(0, last+1) + "*"; x = permissions.get(pname); diff -r e323c74edabd src/share/classes/com/sun/rowset/CachedRowSetImpl.java --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Sat Apr 26 07:31:04 2014 -0300 @@ -6831,7 +6831,7 @@ // table name else isolate table name. indexFrom = command.toLowerCase().indexOf("from"); - indexComma = command.indexOf(",", indexFrom); + indexComma = command.indexOf(',', indexFrom); if(indexComma == -1) { // implies only one table diff -r e323c74edabd src/share/classes/com/sun/rowset/JoinRowSetImpl.java --- a/src/share/classes/com/sun/rowset/JoinRowSetImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/JoinRowSetImpl.java Sat Apr 26 07:31:04 2014 -0300 @@ -910,7 +910,7 @@ // now remove the last "," strWhereClause = strWhereClause.substring - (0, strWhereClause.lastIndexOf(",")); + (0, strWhereClause.lastIndexOf(',')); // Add from clause strWhereClause = strWhereClause.concat(" from "); @@ -920,7 +920,7 @@ //Remove the last "," strWhereClause = strWhereClause.substring - (0, strWhereClause.lastIndexOf(",")); + (0, strWhereClause.lastIndexOf(',')); // Add the where clause strWhereClause = strWhereClause.concat(" where "); diff -r e323c74edabd src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java --- a/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Sat Apr 26 07:31:04 2014 -0300 @@ -240,7 +240,7 @@ // Remove the string after "@xxxx" // before writing it to the xml file. String strProviderInstance = (caller.getSyncProvider()).toString(); - String strProvider = strProviderInstance.substring(0, (caller.getSyncProvider()).toString().indexOf("@")); + String strProvider = strProviderInstance.substring(0, (caller.getSyncProvider()).toString().indexOf('@')); propString("sync-provider-name", strProvider); propString("sync-provider-vendor", "Oracle Corporation"); diff -r e323c74edabd src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java --- a/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Sat Apr 26 07:31:04 2014 -0300 @@ -1147,7 +1147,7 @@ if (nullValue) { rs.setSyncProvider(null); } else { - String str = s.substring(0,s.indexOf("@")+1); + String str = s.substring(0,s.indexOf('@')+1); rs.setSyncProvider(str); } break; diff -r e323c74edabd src/share/classes/com/sun/rowset/internal/XmlResolver.java --- a/src/share/classes/com/sun/rowset/internal/XmlResolver.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/internal/XmlResolver.java Sat Apr 26 07:31:04 2014 -0300 @@ -39,7 +39,7 @@ public class XmlResolver implements EntityResolver { public InputSource resolveEntity(String publicId, String systemId) { - String schemaName = systemId.substring(systemId.lastIndexOf("/")); + String schemaName = systemId.substring(systemId.lastIndexOf('/')); if(systemId.startsWith("http://java.sun.com/xml/ns/jdbc")) { return new InputSource(this.getClass().getResourceAsStream(schemaName)); diff -r e323c74edabd src/share/classes/com/sun/security/auth/module/JndiLoginModule.java --- a/src/share/classes/com/sun/security/auth/module/JndiLoginModule.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/security/auth/module/JndiLoginModule.java Sat Apr 26 07:31:04 2014 -0300 @@ -694,7 +694,7 @@ throw new LoginException("Error: no CallbackHandler available " + "to garner authentication information from the user"); - String protocol = userProvider.substring(0, userProvider.indexOf(":")); + String protocol = userProvider.substring(0, userProvider.indexOf(':')); Callback[] callbacks = new Callback[2]; callbacks[0] = new NameCallback(protocol + " " diff -r e323c74edabd src/share/classes/com/sun/security/auth/module/LdapLoginModule.java --- a/src/share/classes/com/sun/security/auth/module/LdapLoginModule.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/security/auth/module/LdapLoginModule.java Sat Apr 26 07:31:04 2014 -0300 @@ -400,7 +400,7 @@ // Add any JNDI properties to the environment for (String key : options.keySet()) { - if (key.indexOf(".") > -1) { + if (key.indexOf('.') > -1) { ldapEnvironment.put(key, options.get(key)); } } diff -r e323c74edabd src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java --- a/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java Sat Apr 26 07:31:04 2014 -0300 @@ -857,7 +857,7 @@ bpSpec = runtime.createClassLineBreakpoint(classId, lineNumber); } else { // Try stripping method from class.method token. - int idot = token.lastIndexOf("."); + int idot = token.lastIndexOf('.'); if ( (idot <= 0) || /* No dot or dot in first char */ (idot >= token.length() - 1) ) { /* dot in last char */ return null; diff -r e323c74edabd src/share/classes/com/sun/tools/example/debug/tty/Commands.java --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sat Apr 26 07:31:04 2014 -0300 @@ -1079,7 +1079,7 @@ } } else { // Try stripping method from class.method token. - int idot = token.lastIndexOf("."); + int idot = token.lastIndexOf('.'); if ( (idot <= 0) || /* No dot or dot in first char */ (idot >= token.length() - 1) ) { /* dot in last char */ printBreakpointCommandUsage(atForm, inForm); diff -r e323c74edabd src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java --- a/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java Sat Apr 26 07:31:04 2014 -0300 @@ -67,7 +67,7 @@ continue; } String name = clazz.getName(); - int pos = name.lastIndexOf("."); + int pos = name.lastIndexOf('.'); String pkg; if (name.startsWith("[")) { // Only in ancient heap dumps pkg = ""; diff -r e323c74edabd src/share/classes/java/lang/Class.java --- a/src/share/classes/java/lang/Class.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/lang/Class.java Sat Apr 26 07:31:04 2014 -0300 @@ -1296,7 +1296,7 @@ String simpleName = getSimpleBinaryName(); if (simpleName == null) { // top level class simpleName = getName(); - return simpleName.substring(simpleName.lastIndexOf(".")+1); // strip the package name + return simpleName.substring(simpleName.lastIndexOf('.')+1); // strip the package name } // According to JLS3 "Binary Compatibility" (13.1) the binary // name of non-package classes (not top level) is the binary diff -r e323c74edabd src/share/classes/java/lang/ClassLoader.java --- a/src/share/classes/java/lang/ClassLoader.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/lang/ClassLoader.java Sat Apr 26 07:31:04 2014 -0300 @@ -2136,7 +2136,7 @@ return result.booleanValue(); // Check for most specific package entry - int dotIndex = className.lastIndexOf("."); + int dotIndex = className.lastIndexOf('.'); if (dotIndex < 0) { // default package result = packageAssertionStatus.get(null); if (result != null) @@ -2147,7 +2147,7 @@ result = packageAssertionStatus.get(className); if (result != null) return result.booleanValue(); - dotIndex = className.lastIndexOf(".", dotIndex-1); + dotIndex = className.lastIndexOf('.', dotIndex-1); } // Return the classloader default diff -r e323c74edabd src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java --- a/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Sat Apr 26 07:31:04 2014 -0300 @@ -84,7 +84,7 @@ private InvokerBytecodeGenerator(LambdaForm lambdaForm, int localsMapSize, String className, String invokerName, MethodType invokerType) { if (invokerName.contains(".")) { - int p = invokerName.indexOf("."); + int p = invokerName.indexOf('.'); className = invokerName.substring(0, p); invokerName = invokerName.substring(p+1); } diff -r e323c74edabd src/share/classes/java/net/CookieManager.java --- a/src/share/classes/java/net/CookieManager.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/net/CookieManager.java Sat Apr 26 07:31:04 2014 -0300 @@ -294,7 +294,7 @@ // the path is the directory of the page/doc String path = uri.getPath(); if (!path.endsWith("/")) { - int i = path.lastIndexOf("/"); + int i = path.lastIndexOf('/'); if (i > 0) { path = path.substring(0, i + 1); } else { @@ -364,7 +364,7 @@ static private boolean isInPortList(String lst, int port) { - int i = lst.indexOf(","); + int i = lst.indexOf(','); int val = -1; while (i > 0) { try { @@ -375,7 +375,7 @@ } catch (NumberFormatException numberFormatException) { } lst = lst.substring(i+1); - i = lst.indexOf(","); + i = lst.indexOf(','); } if (!lst.isEmpty()) { try { diff -r e323c74edabd src/share/classes/java/net/InetAddress.java --- a/src/share/classes/java/net/InetAddress.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/net/InetAddress.java Sat Apr 26 07:31:04 2014 -0300 @@ -1138,7 +1138,7 @@ // This is supposed to be an IPv6 literal // Check if a numeric or string zone id is present int pos; - if ((pos=host.indexOf ("%")) != -1) { + if ((pos=host.indexOf ('%')) != -1) { numericZone = checkNumericZone (host); if (numericZone == -1) { /* remainder of string must be an ifname */ ifname = host.substring (pos+1); diff -r e323c74edabd src/share/classes/java/net/SocketPermission.java --- a/src/share/classes/java/net/SocketPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/net/SocketPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -777,7 +777,7 @@ // Literal IPv6 address host = getName().substring(1, getName().indexOf(']')); } else { - int i = getName().indexOf(":"); + int i = getName().indexOf(':'); if (i == -1) host = getName(); else { diff -r e323c74edabd src/share/classes/java/net/SocksSocketImpl.java --- a/src/share/classes/java/net/SocksSocketImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/net/SocksSocketImpl.java Sat Apr 26 07:31:04 2014 -0300 @@ -368,7 +368,7 @@ String host = epoint.getHostString(); // IPv6 litteral? if (epoint.getAddress() instanceof Inet6Address && - (!host.startsWith("[")) && (host.indexOf(":") >= 0)) { + (!host.startsWith("[")) && (host.indexOf(':') >= 0)) { host = "[" + host + "]"; } try { @@ -684,7 +684,7 @@ String host = saddr.getHostString(); // IPv6 litteral? if (saddr.getAddress() instanceof Inet6Address && - (!host.startsWith("[")) && (host.indexOf(":") >= 0)) { + (!host.startsWith("[")) && (host.indexOf(':') >= 0)) { host = "[" + host + "]"; } try { diff -r e323c74edabd src/share/classes/java/net/URI.java --- a/src/share/classes/java/net/URI.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/net/URI.java Sat Apr 26 07:31:04 2014 -0300 @@ -1851,9 +1851,9 @@ sb.append("//"); if (authority.startsWith("[")) { // authority should (but may not) contain an embedded IPv6 address - int end = authority.indexOf("]"); + int end = authority.indexOf(']'); String doquote = authority, dontquote = ""; - if (end != -1 && authority.indexOf(":") != -1) { + if (end != -1 && authority.indexOf(':') != -1) { // the authority contains an IPv6 address if (end == authority.length()) { dontquote = authority; @@ -1889,8 +1889,8 @@ * because we must not quote a literal IPv6 address */ if (opaquePart.startsWith("//[")) { - int end = opaquePart.indexOf("]"); - if (end != -1 && opaquePart.indexOf(":")!=-1) { + int end = opaquePart.indexOf(']'); + if (end != -1 && opaquePart.indexOf(':')!=-1) { String doquote, dontquote; if (end == opaquePart.length()) { dontquote = opaquePart; diff -r e323c74edabd src/share/classes/java/security/BasicPermission.java --- a/src/share/classes/java/security/BasicPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/security/BasicPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -430,7 +430,7 @@ offset = path.length()-1; - while ((last = path.lastIndexOf(".", offset)) != -1) { + while ((last = path.lastIndexOf('.', offset)) != -1) { path = path.substring(0, last+1) + "*"; //System.out.println("check "+path); diff -r e323c74edabd src/share/classes/java/security/Provider.java --- a/src/share/classes/java/security/Provider.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/security/Provider.java Sat Apr 26 07:31:04 2014 -0300 @@ -927,7 +927,7 @@ } private String[] getTypeAndAlgorithm(String key) { - int i = key.indexOf("."); + int i = key.indexOf('.'); if (i < 1) { if (debug != null) { debug.println("Ignoring invalid entry in provider " diff -r e323c74edabd src/share/classes/java/security/Security.java --- a/src/share/classes/java/security/Security.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/security/Security.java Sat Apr 26 07:31:04 2014 -0300 @@ -1114,7 +1114,7 @@ // implementation of an algorithm. We are only interested // in entries which lead to the implementation // classes. - if (currentKey.indexOf(" ") < 0) { + if (currentKey.indexOf(' ') < 0) { result.add(currentKey.substring( serviceName.length() + 1)); } diff -r e323c74edabd src/share/classes/java/util/PropertyPermission.java --- a/src/share/classes/java/util/PropertyPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/util/PropertyPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -547,7 +547,7 @@ offset = name.length()-1; - while ((last = name.lastIndexOf(".", offset)) != -1) { + while ((last = name.lastIndexOf('.', offset)) != -1) { name = name.substring(0, last+1) + "*"; //System.out.println("check "+name); diff -r e323c74edabd src/share/classes/java/util/jar/JarVerifier.java --- a/src/share/classes/java/util/jar/JarVerifier.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/util/jar/JarVerifier.java Sat Apr 26 07:31:04 2014 -0300 @@ -278,7 +278,7 @@ // now we are parsing a signature block file - String key = uname.substring(0, uname.lastIndexOf(".")); + String key = uname.substring(0, uname.lastIndexOf('.')); if (signerCache == null) signerCache = new ArrayList<>(); diff -r e323c74edabd src/share/classes/java/util/logging/LogManager.java --- a/src/share/classes/java/util/logging/LogManager.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/util/logging/LogManager.java Sat Apr 26 07:31:04 2014 -0300 @@ -866,7 +866,7 @@ int ix = 1; for (;;) { - int ix2 = name.indexOf(".", ix); + int ix2 = name.indexOf('.', ix); if (ix2 < 0) { break; } @@ -889,7 +889,7 @@ } LogNode node = root; while (name.length() > 0) { - int ix = name.indexOf("."); + int ix = name.indexOf('.'); String head; if (ix > 0) { head = name.substring(0, ix); diff -r e323c74edabd src/share/classes/java/util/logging/XMLFormatter.java --- a/src/share/classes/java/util/logging/XMLFormatter.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/util/logging/XMLFormatter.java Sat Apr 26 07:31:04 2014 -0300 @@ -174,7 +174,7 @@ // Check to see if the parameter was not a messagetext format // or was not null or empty if ( parameters != null && parameters.length != 0 - && record.getMessage().indexOf("{") == -1 ) { + && record.getMessage().indexOf('{') == -1 ) { for (int i = 0; i < parameters.length; i++) { sb.append(" "); try { diff -r e323c74edabd src/share/classes/javax/management/MBeanPermission.java --- a/src/share/classes/javax/management/MBeanPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/management/MBeanPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -290,7 +290,7 @@ // Parse ObjectName - int openingBracket = name.indexOf("["); + int openingBracket = name.indexOf('['); if (openingBracket == -1) { // If "[on]" missing then ObjectName("*:*") // @@ -329,7 +329,7 @@ // Parse member - int poundSign = name.indexOf("#"); + int poundSign = name.indexOf('#'); if (poundSign == -1) setMember("*"); diff -r e323c74edabd src/share/classes/javax/management/modelmbean/DescriptorSupport.java --- a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Sat Apr 26 07:31:04 2014 -0300 @@ -329,7 +329,7 @@ inFld = false; } else if (inFld && inDesc) { // want kw=value, eg, name="myname" value="myvalue" - int eq_separator = tok.indexOf("="); + int eq_separator = tok.indexOf('='); if (eq_separator > 0) { String kwPart = tok.substring(0,eq_separator); String valPart = tok.substring(eq_separator+1); @@ -458,7 +458,7 @@ if ((fields[i] == null) || (fields[i].equals(""))) { continue; } - int eq_separator = fields[i].indexOf("="); + int eq_separator = fields[i].indexOf('='); if (eq_separator < 0) { // illegal if no = or is first character if (MODELMBEAN_LOGGER.isLoggable(Level.FINEST)) { diff -r e323c74edabd src/share/classes/javax/management/modelmbean/RequiredModelMBean.java --- a/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Sat Apr 26 07:31:04 2014 -0300 @@ -934,7 +934,7 @@ String opMethodName; // Parse for class name and method - int opSplitter = opName.lastIndexOf("."); + int opSplitter = opName.lastIndexOf('.'); if (opSplitter > 0) { opClassName = opName.substring(0,opSplitter); opMethodName = opName.substring(opSplitter+1); @@ -943,7 +943,7 @@ /* Ignore anything after a left paren. We keep this for compatibility but it isn't specified. */ - opSplitter = opMethodName.indexOf("("); + opSplitter = opMethodName.indexOf('('); if (opSplitter > 0) opMethodName = opMethodName.substring(0,opSplitter); diff -r e323c74edabd src/share/classes/javax/security/auth/PrivateCredentialPermission.java --- a/src/share/classes/javax/security/auth/PrivateCredentialPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/security/auth/PrivateCredentialPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -495,7 +495,7 @@ // perform new initialization from the permission name - if (getName().indexOf(" ") == -1 && getName().indexOf("\"") == -1) { + if (getName().indexOf(' ') == -1 && getName().indexOf('\"') == -1) { // name only has a credential class specified credentialClass = getName(); diff -r e323c74edabd src/share/classes/javax/security/sasl/Sasl.java --- a/src/share/classes/javax/security/sasl/Sasl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/security/sasl/Sasl.java Sat Apr 26 07:31:04 2014 -0300 @@ -600,7 +600,7 @@ // implementation of an algorithm. We are only interested // in entries which lead to the implementation // classes. - if (currentKey.indexOf(" ") < 0) { + if (currentKey.indexOf(' ') < 0) { String className = providers[i].getProperty(currentKey); if (!classes.contains(className)) { classes.add(className); diff -r e323c74edabd src/share/classes/javax/swing/JEditorPane.java --- a/src/share/classes/javax/swing/JEditorPane.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/swing/JEditorPane.java Sat Apr 26 07:31:04 2014 -0300 @@ -964,7 +964,7 @@ // The type could have optional info is part of it, // for example some charset info. We need to strip that // of and save it. - int parm = type.indexOf(";"); + int parm = type.indexOf(';'); if (parm > -1) { // Save the paramList. String paramList = type.substring(parm); diff -r e323c74edabd src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java --- a/src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Sat Apr 26 07:31:04 2014 -0300 @@ -653,7 +653,7 @@ // strip off the prefix, if there is one. String fullKey = key.toString(); - String partialKey = fullKey.substring(fullKey.indexOf(".") + 1); + String partialKey = fullKey.substring(fullKey.indexOf('.') + 1); Object obj = null; int xstate = getExtendedState(ctx, v); diff -r e323c74edabd src/share/classes/sun/applet/AppletClassLoader.java --- a/src/share/classes/sun/applet/AppletClassLoader.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/applet/AppletClassLoader.java Sat Apr 26 07:31:04 2014 -0300 @@ -168,7 +168,7 @@ */ protected Class findClass(String name) throws ClassNotFoundException { - int index = name.indexOf(";"); + int index = name.indexOf(';'); String cookie = ""; if(index != -1) { cookie = name.substring(index, name.length()); @@ -608,7 +608,7 @@ // deal with URL rewriting String cookie = null; - int index = name.indexOf(";"); + int index = name.indexOf(';'); if(index != -1) { cookie = name.substring(index, name.length()); name = name.substring(0, index); diff -r e323c74edabd src/share/classes/sun/awt/FontConfiguration.java --- a/src/share/classes/sun/awt/FontConfiguration.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/awt/FontConfiguration.java Sat Apr 26 07:31:04 2014 -0300 @@ -272,9 +272,9 @@ if (configFile != null) { return configFile; } - int decimalPointIndex = osVersion.indexOf("."); + int decimalPointIndex = osVersion.indexOf('.'); if (decimalPointIndex != -1) { - osMajorVersion = osVersion.substring(0, osVersion.indexOf(".")); + osMajorVersion = osVersion.substring(0, osVersion.indexOf('.')); configFile = findImpl(baseName + "." + osName + "." + osMajorVersion); if (configFile != null) { return configFile; diff -r e323c74edabd src/share/classes/sun/font/Type1Font.java --- a/src/share/classes/sun/font/Type1Font.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/font/Type1Font.java Sat Apr 26 07:31:04 2014 -0300 @@ -492,7 +492,7 @@ //Conversion: Expand abbreviations in style portion (everything after '-'), // replace '-' with space and insert missing spaces - pos = name.indexOf("-"); + pos = name.indexOf('-'); if (pos >= 0) { res = expandName(name.substring(0, pos), false); res += " " + expandName(name.substring(pos+1), true); @@ -513,8 +513,8 @@ //Conversion: Truncate style portion (everything after '-') // and insert missing spaces - if (tmp.indexOf("-") > 0) { - tmp = tmp.substring(0, tmp.indexOf("-")); + if (tmp.indexOf('-') > 0) { + tmp = tmp.substring(0, tmp.indexOf('-')); } return expandName(tmp, false); diff -r e323c74edabd src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java --- a/src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java Sat Apr 26 07:31:04 2014 -0300 @@ -84,7 +84,7 @@ * {@inheritDoc} */ public String getBaseName() { - int baseIndex = name.lastIndexOf(".")+1; + int baseIndex = name.lastIndexOf('.') + 1; return name.substring(baseIndex); } diff -r e323c74edabd src/share/classes/sun/jvmstat/monitor/HostIdentifier.java --- a/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Sat Apr 26 07:31:04 2014 -0300 @@ -138,8 +138,8 @@ String frag = u.getFragment(); URI u2 = null; - int c1index = uriString.indexOf(":"); - int c2index = uriString.lastIndexOf(":"); + int c1index = uriString.indexOf(':'); + int c2index = uriString.lastIndexOf(':'); if (c2index != c1index) { /* * this is the scheme:hostname:port case. Attempt to diff -r e323c74edabd src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java Sat Apr 26 07:31:04 2014 -0300 @@ -70,8 +70,8 @@ String addrStr; if (target.startsWith("[")) { - final int index = target.indexOf("]"); - final int index2 = target.lastIndexOf(":"); + final int index = target.indexOf(']'); + final int index2 = target.lastIndexOf(':'); if(index == -1) throw new IllegalArgumentException("Host starts with [ but " + "does not end with ]"); @@ -85,8 +85,8 @@ if (addrStr.startsWith("[")) throw new IllegalArgumentException("More than one [[...]]"); } else { - final int index = target.indexOf(":"); - final int index2 = target.lastIndexOf(":"); + final int index = target.indexOf(':'); + final int index2 = target.lastIndexOf(':'); if(index == -1) throw new IllegalArgumentException("Missing port separator \":\""); addrStr = target.substring(0, index); @@ -98,7 +98,7 @@ address = InetAddress.getByName(addrStr); //THE CHECK SHOULD BE STRONGER!!! - final int index = target.lastIndexOf(":"); + final int index = target.lastIndexOf(':'); community = target.substring(index + 1, target.length()); diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sat Apr 26 07:31:04 2014 -0300 @@ -273,8 +273,8 @@ else { // Look for index of "." in the string - int sIdx = source.indexOf("."); - int tIdx = target.indexOf("."); + int sIdx = source.indexOf('.'); + int tIdx = target.indexOf('.'); if (sIdx == -1) sIdx = source.length() - 1; @@ -304,10 +304,10 @@ String versionError = mf.format(args); // Look for "-" for pre-release - int prIndex = token.indexOf("-"); + int prIndex = token.indexOf('-'); // Look for "_" for patch release - int patchIndex = token.indexOf("_"); + int patchIndex = token.indexOf('_'); if (prIndex == -1 && patchIndex == -1) { diff -r e323c74edabd src/share/classes/sun/misc/JarIndex.java --- a/src/share/classes/sun/misc/JarIndex.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/misc/JarIndex.java Sat Apr 26 07:31:04 2014 -0300 @@ -172,7 +172,7 @@ if ((jarFiles = indexMap.get(fileName)) == null) { /* try the package name again */ int pos; - if((pos = fileName.lastIndexOf("/")) != -1) { + if((pos = fileName.lastIndexOf('/')) != -1) { jarFiles = indexMap.get(fileName.substring(0, pos)); } } @@ -195,7 +195,7 @@ public void add(String fileName, String jarName) { String packageName; int pos; - if((pos = fileName.lastIndexOf("/")) != -1) { + if((pos = fileName.lastIndexOf('/')) != -1) { packageName = fileName.substring(0, pos); } else { packageName = fileName; diff -r e323c74edabd src/share/classes/sun/misc/URLClassPath.java --- a/src/share/classes/sun/misc/URLClassPath.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/misc/URLClassPath.java Sat Apr 26 07:31:04 2014 -0300 @@ -793,7 +793,7 @@ boolean validIndex(final String name) { String packageName = name; int pos; - if((pos = name.lastIndexOf("/")) != -1) { + if((pos = name.lastIndexOf('/')) != -1) { packageName = name.substring(0, pos); } @@ -803,7 +803,7 @@ while (enum_.hasMoreElements()) { entry = enum_.nextElement(); entryName = entry.getName(); - if((pos = entryName.lastIndexOf("/")) != -1) + if((pos = entryName.lastIndexOf('/')) != -1) entryName = entryName.substring(0, pos); if (entryName.equals(packageName)) { return true; @@ -900,7 +900,7 @@ */ JarIndex newIndex = newLoader.getIndex(); if(newIndex != null) { - int pos = jarName.lastIndexOf("/"); + int pos = jarName.lastIndexOf('/'); newIndex.merge(this.index, (pos == -1 ? null : jarName.substring(0, pos + 1))); } diff -r e323c74edabd src/share/classes/sun/net/ftp/impl/FtpClient.java --- a/src/share/classes/sun/net/ftp/impl/FtpClient.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/net/ftp/impl/FtpClient.java Sat Apr 26 07:31:04 2014 -0300 @@ -259,7 +259,7 @@ d = null; } if (d != null && time != null) { - int c = time.indexOf(":"); + int c = time.indexOf(':'); now.setTime(d); now.set(Calendar.HOUR, Integer.parseInt(time.substring(0, c))); now.set(Calendar.MINUTE, Integer.parseInt(time.substring(c + 1))); @@ -295,7 +295,7 @@ public FtpDirEntry parseLine(String line) { String name = null; - int i = line.lastIndexOf(";"); + int i = line.lastIndexOf(';'); if (i > 0) { name = line.substring(i + 1).trim(); line = line.substring(0, i); @@ -306,7 +306,7 @@ FtpDirEntry file = new FtpDirEntry(name); while (!line.isEmpty()) { String s; - i = line.indexOf(";"); + i = line.indexOf(';'); if (i > 0) { s = line.substring(0, i); line = line.substring(i + 1); @@ -314,7 +314,7 @@ s = line; line = ""; } - i = s.indexOf("="); + i = s.indexOf('='); if (i > 0) { String fact = s.substring(0, i); String value = s.substring(i + 1); diff -r e323c74edabd src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java --- a/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java Sat Apr 26 07:31:04 2014 -0300 @@ -325,7 +325,7 @@ while (i.hasNext()) { String parentDomain = i.next(); int start = 0; - while ((start = parentDomain.indexOf(".")) != -1 + while ((start = parentDomain.indexOf('.')) != -1 && start < parentDomain.length() -1) { try { results = resolve(ctx, host+"."+parentDomain, ids, 0); diff -r e323c74edabd src/share/classes/sun/net/util/IPAddressUtil.java --- a/src/share/classes/sun/net/util/IPAddressUtil.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/net/util/IPAddressUtil.java Sat Apr 26 07:31:04 2014 -0300 @@ -149,7 +149,7 @@ byte[] dst = new byte[INADDR16SZ]; int srcb_length = srcb.length; - int pc = src.indexOf ("%"); + int pc = src.indexOf ('%'); if (pc == srcb_length -1) { return null; } diff -r e323c74edabd src/share/classes/sun/net/www/ParseUtil.java --- a/src/share/classes/sun/net/www/ParseUtil.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/net/www/ParseUtil.java Sat Apr 26 07:31:04 2014 -0300 @@ -356,8 +356,8 @@ * because we must not quote a literal IPv6 address */ if (opaquePart.startsWith("//[")) { - int end = opaquePart.indexOf("]"); - if (end != -1 && opaquePart.indexOf(":")!=-1) { + int end = opaquePart.indexOf(']'); + if (end != -1 && opaquePart.indexOf(':')!=-1) { String doquote, dontquote; if (end == opaquePart.length()) { dontquote = opaquePart; @@ -408,8 +408,8 @@ } else if (authority != null) { sb.append("//"); if (authority.startsWith("[")) { - int end = authority.indexOf("]"); - if (end != -1 && authority.indexOf(":")!=-1) { + int end = authority.indexOf(']'); + if (end != -1 && authority.indexOf(':')!=-1) { String doquote, dontquote; if (end == authority.length()) { dontquote = authority; diff -r e323c74edabd src/share/classes/sun/reflect/misc/ReflectUtil.java --- a/src/share/classes/sun/reflect/misc/ReflectUtil.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/reflect/misc/ReflectUtil.java Sat Apr 26 07:31:04 2014 -0300 @@ -341,6 +341,6 @@ * (not to be confused with a Java Language anonymous inner class). */ public static boolean isVMAnonymousClass(Class cls) { - return cls.getName().indexOf("/") > -1; + return cls.getName().indexOf('/') > -1; } } diff -r e323c74edabd src/share/classes/sun/rmi/runtime/Log.java --- a/src/share/classes/sun/rmi/runtime/Log.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/rmi/runtime/Log.java Sat Apr 26 07:31:04 2014 -0300 @@ -434,7 +434,7 @@ * Mimic old log messages that only contain unqualified names. */ private static String unqualifiedName(String name) { - int lastDot = name.lastIndexOf("."); + int lastDot = name.lastIndexOf('.'); if (lastDot >= 0) { name = name.substring(lastDot + 1); } diff -r e323c74edabd src/share/classes/sun/rmi/transport/proxy/CGIHandler.java --- a/src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Sat Apr 26 07:31:04 2014 -0300 @@ -141,7 +141,7 @@ { try { String command, param; - int delim = QueryString.indexOf("="); + int delim = QueryString.indexOf('='); if (delim == -1) { command = QueryString; param = ""; diff -r e323c74edabd src/share/classes/sun/security/jgss/wrapper/Krb5Util.java --- a/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Sat Apr 26 07:31:04 2014 -0300 @@ -39,7 +39,7 @@ static String getTGSName(GSSNameElement name) throws GSSException { String krbPrinc = name.getKrbName(); - int atIndex = krbPrinc.indexOf("@"); + int atIndex = krbPrinc.indexOf('@'); String realm = krbPrinc.substring(atIndex + 1); StringBuffer buf = new StringBuffer("krbtgt/"); buf.append(realm).append('@').append(realm); diff -r e323c74edabd src/share/classes/sun/security/provider/PolicyFile.java --- a/src/share/classes/sun/security/provider/PolicyFile.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/provider/PolicyFile.java Sat Apr 26 07:31:04 2014 -0300 @@ -1856,7 +1856,7 @@ int colonIndex; String prefix = value; String suffix; - if ((colonIndex = value.indexOf(":")) != -1) { + if ((colonIndex = value.indexOf(':')) != -1) { prefix = value.substring(0, colonIndex); } diff -r e323c74edabd src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java --- a/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java Sat Apr 26 07:31:04 2014 -0300 @@ -338,7 +338,7 @@ } String sigType; if (keyType.contains("_")) { - int k = keyType.indexOf("_"); + int k = keyType.indexOf('_'); sigType = keyType.substring(k + 1); keyType = keyType.substring(0, k); } else { diff -r e323c74edabd src/share/classes/sun/security/ssl/X509KeyManagerImpl.java --- a/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java Sat Apr 26 07:31:04 2014 -0300 @@ -302,7 +302,7 @@ final String sigKeyAlgorithm; KeyType(String algorithm) { - int k = algorithm.indexOf("_"); + int k = algorithm.indexOf('_'); if (k == -1) { keyAlgorithm = algorithm; sigKeyAlgorithm = null; diff -r e323c74edabd src/share/classes/sun/security/util/HostnameChecker.java --- a/src/share/classes/sun/security/util/HostnameChecker.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/util/HostnameChecker.java Sat Apr 26 07:31:04 2014 -0300 @@ -300,8 +300,8 @@ template = template.toLowerCase(Locale.ENGLISH); // Retreive leftmost component - int templateIdx = template.indexOf("."); - int nameIdx = name.indexOf("."); + int templateIdx = template.indexOf('.'); + int nameIdx = name.indexOf('.'); if (templateIdx == -1) templateIdx = template.length(); @@ -326,7 +326,7 @@ */ private static boolean matchWildCards(String name, String template) { - int wildcardIdx = template.indexOf("*"); + int wildcardIdx = template.indexOf('*'); if (wildcardIdx == -1) return name.equals(template); @@ -349,7 +349,7 @@ // update the match scope name = name.substring(beforeStartIdx + beforeWildcard.length()); - wildcardIdx = afterWildcard.indexOf("*"); + wildcardIdx = afterWildcard.indexOf('*'); } return name.endsWith(afterWildcard); } diff -r e323c74edabd src/share/classes/sun/security/util/SignatureFileVerifier.java --- a/src/share/classes/sun/security/util/SignatureFileVerifier.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/util/SignatureFileVerifier.java Sat Apr 26 07:31:04 2014 -0300 @@ -98,7 +98,7 @@ } finally { Providers.stopJarVerification(obj); } - this.name = name.substring(0, name.lastIndexOf(".")) + this.name = name.substring(0, name.lastIndexOf('.')) .toUpperCase(Locale.ENGLISH); this.md = md; this.signerCache = signerCache; diff -r e323c74edabd src/share/classes/sun/security/x509/CRLExtensions.java --- a/src/share/classes/sun/security/x509/CRLExtensions.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/x509/CRLExtensions.java Sat Apr 26 07:31:04 2014 -0300 @@ -185,7 +185,7 @@ String name; String id = attr.getPrefix(); if (id.equalsIgnoreCase(X509CertImpl.NAME)) { // fully qualified - int index = alias.lastIndexOf("."); + int index = alias.lastIndexOf('.'); name = alias.substring(index + 1); } else name = alias; diff -r e323c74edabd src/share/classes/sun/tools/jconsole/ConnectDialog.java --- a/src/share/classes/sun/tools/jconsole/ConnectDialog.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/ConnectDialog.java Sat Apr 26 07:31:04 2014 -0300 @@ -325,7 +325,7 @@ } else { String host = remoteTF.getText().trim(); String port = "0"; - int index = host.lastIndexOf(":"); + int index = host.lastIndexOf(':'); if (index >= 0) { port = host.substring(index + 1); host = host.substring(0, index); diff -r e323c74edabd src/share/classes/sun/tools/jconsole/inspector/Utils.java --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat Apr 26 07:31:04 2014 -0300 @@ -210,7 +210,7 @@ public static String getArrayClassName(String name) { String className = null; if (name.startsWith("[")) { - int index = name.lastIndexOf("["); + int index = name.lastIndexOf('['); className = name.substring(index, name.length()); if (className.startsWith("[L")) { className = className.substring(2, className.length() - 1); @@ -241,7 +241,7 @@ if (className == null) { return name; } - int index = name.lastIndexOf("["); + int index = name.lastIndexOf('['); StringBuilder brackets = new StringBuilder(className); for (int i = 0; i <= index; i++) { brackets.append("[]"); diff -r e323c74edabd src/share/classes/sun/tools/jconsole/inspector/XOperations.java --- a/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Sat Apr 26 07:31:04 2014 -0300 @@ -112,7 +112,7 @@ if (methodLabel.getText().length() > 20) { methodLabel.setText(methodLabel.getText(). substring(methodLabel.getText(). - lastIndexOf(".") + 1, + lastIndexOf('.') + 1, methodLabel.getText().length())); } diff -r e323c74edabd src/share/classes/sun/tools/jconsole/inspector/XTree.java --- a/src/share/classes/sun/tools/jconsole/inspector/XTree.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/XTree.java Sat Apr 26 07:31:04 2014 -0300 @@ -475,7 +475,7 @@ private static Map extractKeyValuePairs( String props, ObjectName mbean) { Map map = new LinkedHashMap(); - int eq = props.indexOf("="); + int eq = props.indexOf('='); while (eq != -1) { String key = props.substring(0, eq); String value = mbean.getKeyProperty(key); @@ -484,7 +484,7 @@ if (props.startsWith(",")) { props = props.substring(1); } - eq = props.indexOf("="); + eq = props.indexOf('='); } return map; } @@ -821,7 +821,7 @@ } private void buildKeyValue() { - int index = tokenValue.indexOf("="); + int index = tokenValue.indexOf('='); if (index < 0) { key = tokenValue; value = tokenValue; From claes.redestad at oracle.com Sat Apr 26 17:13:30 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 26 Apr 2014 19:13:30 +0200 Subject: inefficient indexof when String has one length In-Reply-To: References: Message-ID: <535BE93A.90604@oracle.com> Hi Ot?vio, while I personally like using chars instead of Strings where applicable, I would assume these constant replacements are all cases where the JIT will be quick to inline and eliminate the overhead. So the benefit, if any, would be in interpreted code. Testing these assumptions with a simple but representative JMH[1] microbenchmark[2]: Benchmark Mode Samples Mean Mean error Units o.s.MyBenchmark.indexOfChar thrpt 20 32290.764 359.347 ops/ms o.s.MyBenchmark.indexOfString thrpt 20 32353.865 398.929 ops/ms o.s.MyBenchmark.lastIndexOfChar thrpt 20 32444.428 462.630 ops/ms o.s.MyBenchmark.lastIndexOfString thrpt 20 32001.738 388.791 ops/ms So no real difference, as suspected. Running with -Xint: Benchmark Mode Samples Mean Mean error Units o.s.MyBenchmark.indexOfChar thrpt 20 3170.130 108.933 ops/ms o.s.MyBenchmark.indexOfString thrpt 20 3119.518 44.703 ops/ms o.s.MyBenchmark.lastIndexOfChar thrpt 20 3281.374 25.589 ops/ms o.s.MyBenchmark.lastIndexOfString thrpt 20 3154.710 45.224 ops/ms Not much - if anything - here either. I think more evidence that this would have some actual benefit is warranted. /Claes [1] http://openjdk.java.net/projects/code-tools/jmh/ [2] package org.sample; import org.openjdk.jmh.annotations.*; import java.util.Random; @State(Scope.Thread) public class MyBenchmark { /* * Generate a lot of randomly generated strings of various sizes */ static int NUM = 100000; static int MAX_SIZE = 1000; static String[] STRINGS = new String[NUM]; static { Random r = new Random(); for (int i = 0; i < NUM; i++) { StringBuilder sb = new StringBuilder(r.nextInt(MAX_SIZE) + 1); for (int j = 0; j < sb.capacity(); j++) { sb.append((char)(r.nextInt(70) + '0')); } STRINGS[i] = sb.toString(); } } private int i = 0; @GenerateMicroBenchmark public int indexOfString() { if (i >= NUM) { i = 0; } return STRINGS[i++].indexOf("6"); } @GenerateMicroBenchmark public int lastIndexOfString() { if (i >= NUM) { i = 0; } return STRINGS[i++].indexOf("6"); } @GenerateMicroBenchmark public int indexOfChar() { if (i >= NUM) { i = 0; } return STRINGS[i++].indexOf('6'); } @GenerateMicroBenchmark public int lastIndexOfChar() { if (i >= NUM) { i = 0; } return STRINGS[i++].indexOf('6'); } } On 2014-04-26 12:56, Ot?vio Gon?alves de Santana wrote: > When a String has length just one, could be replaced by equivalent > character literals, gaining some performance enhancement. > > I found 107 changes. > > > diff -r e323c74edabd > src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java > --- a/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Wed Apr > 23 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Sat Apr > 26 07:31:04 2014 -0300 > @@ -547,7 +547,7 @@ > i = strLowerCase.indexOf("", i); > if (i > 0) { > i += "".length(); > - int i2 = str.indexOf("<", i); > + int i2 = str.indexOf('<', i); > return str.substring(i, i2); > } > } > diff -r e323c74edabd > src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java > --- a/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -512,7 +512,7 @@ > } > static String qualifiedStringValue(String s1, String s234) { > // Qualification by dot must decompose uniquely. Second string > might already be qualified. > - assert(s1.indexOf(".") < 0); > + assert(s1.indexOf('.') < 0); > return s1+"."+s234; > } > > diff -r e323c74edabd > src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java > --- a/src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -102,7 +102,7 @@ > } > location = url.substring(addrStart, addrEnd); > > - int keyStart = location.indexOf("/"); > + int keyStart = location.indexOf('/'); > if (keyStart >= 0) { > // Has key string > if (keyStart == (location.length() -1)) { > diff -r e323c74edabd > src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java > --- a/src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -336,7 +336,7 @@ > String url = "rmi://"; > > // Enclose IPv6 literal address in '[' and ']' > - url = (host.indexOf(":") > -1) ? url + "[" + host + "]" : > + url = (host.indexOf(':') > -1) ? url + "[" + host + "]" : > url + host; > if (port > 0) { > url += ":" + Integer.toString(port); > diff -r e323c74edabd > src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java > --- a/src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -149,7 +149,7 @@ > * foo:rest/of/name foo: > */ > protected String getURLPrefix(String url) throws NamingException { > - int start = url.indexOf(":"); > + int start = url.indexOf(':'); > > if (start < 0) { > throw new OperationNotSupportedException("Invalid URL: " + > url); > @@ -160,7 +160,7 @@ > start += 2; // skip double slash > > // find last slash > - int posn = url.indexOf("/", start); > + int posn = url.indexOf('/', start); > if (posn >= 0) { > start = posn; > } else { > diff -r e323c74edabd > src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java > --- a/src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java Wed Apr > 23 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java Sat Apr > 26 07:31:04 2014 -0300 > @@ -303,7 +303,7 @@ > > offset = pname.length() - 1; > > - while ((last = pname.lastIndexOf(".", offset)) != -1) { > + while ((last = pname.lastIndexOf('.', offset)) != -1) { > > pname = pname.substring(0, last+1) + "*"; > x = permissions.get(pname); > @@ -318,7 +318,7 @@ > pname = p.getName(); > offset = pname.length() - 1; > > - while ((last = pname.lastIndexOf("=", offset)) != -1) { > + while ((last = pname.lastIndexOf('=', offset)) != -1) { > > pname = pname.substring(0, last+1) + "*"; > x = permissions.get(pname); > diff -r e323c74edabd src/share/classes/com/sun/rowset/CachedRowSetImpl.java > --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -6831,7 +6831,7 @@ > // table name else isolate table name. > > indexFrom = command.toLowerCase().indexOf("from"); > - indexComma = command.indexOf(",", indexFrom); > + indexComma = command.indexOf(',', indexFrom); > > if(indexComma == -1) { > // implies only one table > diff -r e323c74edabd src/share/classes/com/sun/rowset/JoinRowSetImpl.java > --- a/src/share/classes/com/sun/rowset/JoinRowSetImpl.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/rowset/JoinRowSetImpl.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -910,7 +910,7 @@ > > // now remove the last "," > strWhereClause = strWhereClause.substring > - (0, strWhereClause.lastIndexOf(",")); > + (0, strWhereClause.lastIndexOf(',')); > > // Add from clause > strWhereClause = strWhereClause.concat(" from "); > @@ -920,7 +920,7 @@ > > //Remove the last "," > strWhereClause = strWhereClause.substring > - (0, strWhereClause.lastIndexOf(",")); > + (0, strWhereClause.lastIndexOf(',')); > > // Add the where clause > strWhereClause = strWhereClause.concat(" where "); > diff -r e323c74edabd > src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java > --- a/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -240,7 +240,7 @@ > // Remove the string after "@xxxx" > // before writing it to the xml file. > String strProviderInstance = > (caller.getSyncProvider()).toString(); > - String strProvider = strProviderInstance.substring(0, > (caller.getSyncProvider()).toString().indexOf("@")); > + String strProvider = strProviderInstance.substring(0, > (caller.getSyncProvider()).toString().indexOf('@')); > > propString("sync-provider-name", strProvider); > propString("sync-provider-vendor", "Oracle Corporation"); > diff -r e323c74edabd > src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java > --- a/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java > Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java > Sat > Apr 26 07:31:04 2014 -0300 > @@ -1147,7 +1147,7 @@ > if (nullValue) { > rs.setSyncProvider(null); > } else { > - String str = s.substring(0,s.indexOf("@")+1); > + String str = s.substring(0,s.indexOf('@')+1); > rs.setSyncProvider(str); > } > break; > diff -r e323c74edabd > src/share/classes/com/sun/rowset/internal/XmlResolver.java > --- a/src/share/classes/com/sun/rowset/internal/XmlResolver.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/rowset/internal/XmlResolver.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -39,7 +39,7 @@ > public class XmlResolver implements EntityResolver { > > public InputSource resolveEntity(String publicId, String systemId) > { > - String schemaName = > systemId.substring(systemId.lastIndexOf("/")); > + String schemaName = > systemId.substring(systemId.lastIndexOf('/')); > > if(systemId.startsWith("http://java.sun.com/xml/ns/jdbc")) { > return new > InputSource(this.getClass().getResourceAsStream(schemaName)); > diff -r e323c74edabd > src/share/classes/com/sun/security/auth/module/JndiLoginModule.java > --- a/src/share/classes/com/sun/security/auth/module/JndiLoginModule.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/security/auth/module/JndiLoginModule.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -694,7 +694,7 @@ > throw new LoginException("Error: no CallbackHandler available > " + > "to garner authentication information from the user"); > > - String protocol = userProvider.substring(0, > userProvider.indexOf(":")); > + String protocol = userProvider.substring(0, > userProvider.indexOf(':')); > > Callback[] callbacks = new Callback[2]; > callbacks[0] = new NameCallback(protocol + " " > diff -r e323c74edabd > src/share/classes/com/sun/security/auth/module/LdapLoginModule.java > --- a/src/share/classes/com/sun/security/auth/module/LdapLoginModule.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/security/auth/module/LdapLoginModule.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -400,7 +400,7 @@ > > // Add any JNDI properties to the environment > for (String key : options.keySet()) { > - if (key.indexOf(".") > -1) { > + if (key.indexOf('.') > -1) { > ldapEnvironment.put(key, options.get(key)); > } > } > diff -r e323c74edabd > src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java > --- > a/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java Wed > Apr 23 11:35:40 2014 -0700 > +++ > b/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -857,7 +857,7 @@ > bpSpec = runtime.createClassLineBreakpoint(classId, > lineNumber); > } else { > // Try stripping method from class.method token. > - int idot = token.lastIndexOf("."); > + int idot = token.lastIndexOf('.'); > if ( (idot <= 0) || /* No dot or dot in first char > */ > (idot >= token.length() - 1) ) { /* dot in last char > */ > return null; > diff -r e323c74edabd > src/share/classes/com/sun/tools/example/debug/tty/Commands.java > --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -1079,7 +1079,7 @@ > } > } else { > // Try stripping method from class.method token. > - int idot = token.lastIndexOf("."); > + int idot = token.lastIndexOf('.'); > if ( (idot <= 0) || /* No dot or dot > in first char */ > (idot >= token.length() - 1) ) { /* dot in last char > */ > printBreakpointCommandUsage(atForm, inForm); > diff -r e323c74edabd > src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java > --- > a/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java Wed > Apr 23 11:35:40 2014 -0700 > +++ > b/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -67,7 +67,7 @@ > continue; > } > String name = clazz.getName(); > - int pos = name.lastIndexOf("."); > + int pos = name.lastIndexOf('.'); > String pkg; > if (name.startsWith("[")) { // Only in ancient heap > dumps > pkg = ""; > diff -r e323c74edabd src/share/classes/java/lang/Class.java > --- a/src/share/classes/java/lang/Class.java Wed Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/java/lang/Class.java Sat Apr 26 07:31:04 2014 -0300 > @@ -1296,7 +1296,7 @@ > String simpleName = getSimpleBinaryName(); > if (simpleName == null) { // top level class > simpleName = getName(); > - return simpleName.substring(simpleName.lastIndexOf(".")+1); // > strip the package name > + return simpleName.substring(simpleName.lastIndexOf('.')+1); // > strip the package name > } > // According to JLS3 "Binary Compatibility" (13.1) the binary > // name of non-package classes (not top level) is the binary > diff -r e323c74edabd src/share/classes/java/lang/ClassLoader.java > --- a/src/share/classes/java/lang/ClassLoader.java Wed Apr 23 11:35:40 2014 > -0700 > +++ b/src/share/classes/java/lang/ClassLoader.java Sat Apr 26 07:31:04 2014 > -0300 > @@ -2136,7 +2136,7 @@ > return result.booleanValue(); > > // Check for most specific package entry > - int dotIndex = className.lastIndexOf("."); > + int dotIndex = className.lastIndexOf('.'); > if (dotIndex < 0) { // default package > result = packageAssertionStatus.get(null); > if (result != null) > @@ -2147,7 +2147,7 @@ > result = packageAssertionStatus.get(className); > if (result != null) > return result.booleanValue(); > - dotIndex = className.lastIndexOf(".", dotIndex-1); > + dotIndex = className.lastIndexOf('.', dotIndex-1); > } > > // Return the classloader default > diff -r e323c74edabd > src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java > --- a/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -84,7 +84,7 @@ > private InvokerBytecodeGenerator(LambdaForm lambdaForm, int > localsMapSize, > String className, String invokerName, > MethodType invokerType) { > if (invokerName.contains(".")) { > - int p = invokerName.indexOf("."); > + int p = invokerName.indexOf('.'); > className = invokerName.substring(0, p); > invokerName = invokerName.substring(p+1); > } > diff -r e323c74edabd src/share/classes/java/net/CookieManager.java > --- a/src/share/classes/java/net/CookieManager.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/java/net/CookieManager.java Sat Apr 26 07:31:04 > 2014 -0300 > @@ -294,7 +294,7 @@ > // the path is the directory of the page/doc > String path = uri.getPath(); > if (!path.endsWith("/")) { > - int i = path.lastIndexOf("/"); > + int i = path.lastIndexOf('/'); > if (i > 0) { > path = path.substring(0, i + 1); > } else { > @@ -364,7 +364,7 @@ > > > static private boolean isInPortList(String lst, int port) { > - int i = lst.indexOf(","); > + int i = lst.indexOf(','); > int val = -1; > while (i > 0) { > try { > @@ -375,7 +375,7 @@ > } catch (NumberFormatException numberFormatException) { > } > lst = lst.substring(i+1); > - i = lst.indexOf(","); > + i = lst.indexOf(','); > } > if (!lst.isEmpty()) { > try { > diff -r e323c74edabd src/share/classes/java/net/InetAddress.java > --- a/src/share/classes/java/net/InetAddress.java Wed Apr 23 11:35:40 2014 > -0700 > +++ b/src/share/classes/java/net/InetAddress.java Sat Apr 26 07:31:04 2014 > -0300 > @@ -1138,7 +1138,7 @@ > // This is supposed to be an IPv6 literal > // Check if a numeric or string zone id is present > int pos; > - if ((pos=host.indexOf ("%")) != -1) { > + if ((pos=host.indexOf ('%')) != -1) { > numericZone = checkNumericZone (host); > if (numericZone == -1) { /* remainder of string must > be an ifname */ > ifname = host.substring (pos+1); > diff -r e323c74edabd src/share/classes/java/net/SocketPermission.java > --- a/src/share/classes/java/net/SocketPermission.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/java/net/SocketPermission.java Sat Apr 26 07:31:04 > 2014 -0300 > @@ -777,7 +777,7 @@ > // Literal IPv6 address > host = getName().substring(1, getName().indexOf(']')); > } else { > - int i = getName().indexOf(":"); > + int i = getName().indexOf(':'); > if (i == -1) > host = getName(); > else { > diff -r e323c74edabd src/share/classes/java/net/SocksSocketImpl.java > --- a/src/share/classes/java/net/SocksSocketImpl.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/java/net/SocksSocketImpl.java Sat Apr 26 07:31:04 > 2014 -0300 > @@ -368,7 +368,7 @@ > String host = epoint.getHostString(); > // IPv6 litteral? > if (epoint.getAddress() instanceof Inet6Address && > - (!host.startsWith("[")) && (host.indexOf(":") >= 0)) { > + (!host.startsWith("[")) && (host.indexOf(':') >= 0)) { > host = "[" + host + "]"; > } > try { > @@ -684,7 +684,7 @@ > String host = saddr.getHostString(); > // IPv6 litteral? > if (saddr.getAddress() instanceof Inet6Address && > - (!host.startsWith("[")) && (host.indexOf(":") >= 0)) { > + (!host.startsWith("[")) && (host.indexOf(':') >= 0)) { > host = "[" + host + "]"; > } > try { > diff -r e323c74edabd src/share/classes/java/net/URI.java > --- a/src/share/classes/java/net/URI.java Wed Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/java/net/URI.java Sat Apr 26 07:31:04 2014 -0300 > @@ -1851,9 +1851,9 @@ > sb.append("//"); > if (authority.startsWith("[")) { > // authority should (but may not) contain an embedded IPv6 > address > - int end = authority.indexOf("]"); > + int end = authority.indexOf(']'); > String doquote = authority, dontquote = ""; > - if (end != -1 && authority.indexOf(":") != -1) { > + if (end != -1 && authority.indexOf(':') != -1) { > // the authority contains an IPv6 address > if (end == authority.length()) { > dontquote = authority; > @@ -1889,8 +1889,8 @@ > * because we must not quote a literal IPv6 address > */ > if (opaquePart.startsWith("//[")) { > - int end = opaquePart.indexOf("]"); > - if (end != -1 && opaquePart.indexOf(":")!=-1) { > + int end = opaquePart.indexOf(']'); > + if (end != -1 && opaquePart.indexOf(':')!=-1) { > String doquote, dontquote; > if (end == opaquePart.length()) { > dontquote = opaquePart; > diff -r e323c74edabd src/share/classes/java/security/BasicPermission.java > --- a/src/share/classes/java/security/BasicPermission.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/java/security/BasicPermission.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -430,7 +430,7 @@ > > offset = path.length()-1; > > - while ((last = path.lastIndexOf(".", offset)) != -1) { > + while ((last = path.lastIndexOf('.', offset)) != -1) { > > path = path.substring(0, last+1) + "*"; > //System.out.println("check "+path); > diff -r e323c74edabd src/share/classes/java/security/Provider.java > --- a/src/share/classes/java/security/Provider.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/java/security/Provider.java Sat Apr 26 07:31:04 > 2014 -0300 > @@ -927,7 +927,7 @@ > } > > private String[] getTypeAndAlgorithm(String key) { > - int i = key.indexOf("."); > + int i = key.indexOf('.'); > if (i < 1) { > if (debug != null) { > debug.println("Ignoring invalid entry in provider " > diff -r e323c74edabd src/share/classes/java/security/Security.java > --- a/src/share/classes/java/security/Security.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/java/security/Security.java Sat Apr 26 07:31:04 > 2014 -0300 > @@ -1114,7 +1114,7 @@ > // implementation of an algorithm. We are only > interested > // in entries which lead to the implementation > // classes. > - if (currentKey.indexOf(" ") < 0) { > + if (currentKey.indexOf(' ') < 0) { > result.add(currentKey.substring( > serviceName.length() + 1)); > } > diff -r e323c74edabd src/share/classes/java/util/PropertyPermission.java > --- a/src/share/classes/java/util/PropertyPermission.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/java/util/PropertyPermission.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -547,7 +547,7 @@ > > offset = name.length()-1; > > - while ((last = name.lastIndexOf(".", offset)) != -1) { > + while ((last = name.lastIndexOf('.', offset)) != -1) { > > name = name.substring(0, last+1) + "*"; > //System.out.println("check "+name); > diff -r e323c74edabd src/share/classes/java/util/jar/JarVerifier.java > --- a/src/share/classes/java/util/jar/JarVerifier.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/java/util/jar/JarVerifier.java Sat Apr 26 07:31:04 > 2014 -0300 > @@ -278,7 +278,7 @@ > > // now we are parsing a signature block file > > - String key = uname.substring(0, uname.lastIndexOf(".")); > + String key = uname.substring(0, uname.lastIndexOf('.')); > > if (signerCache == null) > signerCache = new ArrayList<>(); > diff -r e323c74edabd src/share/classes/java/util/logging/LogManager.java > --- a/src/share/classes/java/util/logging/LogManager.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/java/util/logging/LogManager.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -866,7 +866,7 @@ > > int ix = 1; > for (;;) { > - int ix2 = name.indexOf(".", ix); > + int ix2 = name.indexOf('.', ix); > if (ix2 < 0) { > break; > } > @@ -889,7 +889,7 @@ > } > LogNode node = root; > while (name.length() > 0) { > - int ix = name.indexOf("."); > + int ix = name.indexOf('.'); > String head; > if (ix > 0) { > head = name.substring(0, ix); > diff -r e323c74edabd src/share/classes/java/util/logging/XMLFormatter.java > --- a/src/share/classes/java/util/logging/XMLFormatter.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/java/util/logging/XMLFormatter.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -174,7 +174,7 @@ > // Check to see if the parameter was not a messagetext format > // or was not null or empty > if ( parameters != null && parameters.length != 0 > - && record.getMessage().indexOf("{") == -1 ) { > + && record.getMessage().indexOf('{') == -1 ) { > for (int i = 0; i < parameters.length; i++) { > sb.append(" "); > try { > diff -r e323c74edabd src/share/classes/javax/management/MBeanPermission.java > --- a/src/share/classes/javax/management/MBeanPermission.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/javax/management/MBeanPermission.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -290,7 +290,7 @@ > > // Parse ObjectName > > - int openingBracket = name.indexOf("["); > + int openingBracket = name.indexOf('['); > if (openingBracket == -1) { > // If "[on]" missing then ObjectName("*:*") > // > @@ -329,7 +329,7 @@ > > // Parse member > > - int poundSign = name.indexOf("#"); > + int poundSign = name.indexOf('#'); > > if (poundSign == -1) > setMember("*"); > diff -r e323c74edabd > src/share/classes/javax/management/modelmbean/DescriptorSupport.java > --- a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -329,7 +329,7 @@ > inFld = false; > } else if (inFld && inDesc) { > // want kw=value, eg, name="myname" value="myvalue" > - int eq_separator = tok.indexOf("="); > + int eq_separator = tok.indexOf('='); > if (eq_separator > 0) { > String kwPart = tok.substring(0,eq_separator); > String valPart = tok.substring(eq_separator+1); > @@ -458,7 +458,7 @@ > if ((fields[i] == null) || (fields[i].equals(""))) { > continue; > } > - int eq_separator = fields[i].indexOf("="); > + int eq_separator = fields[i].indexOf('='); > if (eq_separator < 0) { > // illegal if no = or is first character > if (MODELMBEAN_LOGGER.isLoggable(Level.FINEST)) { > diff -r e323c74edabd > src/share/classes/javax/management/modelmbean/RequiredModelMBean.java > --- a/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -934,7 +934,7 @@ > String opMethodName; > > // Parse for class name and method > - int opSplitter = opName.lastIndexOf("."); > + int opSplitter = opName.lastIndexOf('.'); > if (opSplitter > 0) { > opClassName = opName.substring(0,opSplitter); > opMethodName = opName.substring(opSplitter+1); > @@ -943,7 +943,7 @@ > > /* Ignore anything after a left paren. We keep this for > compatibility but it isn't specified. */ > - opSplitter = opMethodName.indexOf("("); > + opSplitter = opMethodName.indexOf('('); > if (opSplitter > 0) > opMethodName = opMethodName.substring(0,opSplitter); > > diff -r e323c74edabd > src/share/classes/javax/security/auth/PrivateCredentialPermission.java > --- a/src/share/classes/javax/security/auth/PrivateCredentialPermission.java > Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/javax/security/auth/PrivateCredentialPermission.java > Sat > Apr 26 07:31:04 2014 -0300 > @@ -495,7 +495,7 @@ > > // perform new initialization from the permission name > > - if (getName().indexOf(" ") == -1 && getName().indexOf("\"") == -1) > { > + if (getName().indexOf(' ') == -1 && getName().indexOf('\"') == -1) > { > > // name only has a credential class specified > credentialClass = getName(); > diff -r e323c74edabd src/share/classes/javax/security/sasl/Sasl.java > --- a/src/share/classes/javax/security/sasl/Sasl.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/javax/security/sasl/Sasl.java Sat Apr 26 07:31:04 > 2014 -0300 > @@ -600,7 +600,7 @@ > // implementation of an algorithm. We are only > interested > // in entries which lead to the implementation > // classes. > - if (currentKey.indexOf(" ") < 0) { > + if (currentKey.indexOf(' ') < 0) { > String className = > providers[i].getProperty(currentKey); > if (!classes.contains(className)) { > classes.add(className); > diff -r e323c74edabd src/share/classes/javax/swing/JEditorPane.java > --- a/src/share/classes/javax/swing/JEditorPane.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/javax/swing/JEditorPane.java Sat Apr 26 07:31:04 > 2014 -0300 > @@ -964,7 +964,7 @@ > // The type could have optional info is part of it, > // for example some charset info. We need to strip that > // of and save it. > - int parm = type.indexOf(";"); > + int parm = type.indexOf(';'); > if (parm > -1) { > // Save the paramList. > String paramList = type.substring(parm); > diff -r e323c74edabd > src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java > --- a/src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -653,7 +653,7 @@ > > // strip off the prefix, if there is one. > String fullKey = key.toString(); > - String partialKey = fullKey.substring(fullKey.indexOf(".") + 1); > + String partialKey = fullKey.substring(fullKey.indexOf('.') + 1); > > Object obj = null; > int xstate = getExtendedState(ctx, v); > diff -r e323c74edabd src/share/classes/sun/applet/AppletClassLoader.java > --- a/src/share/classes/sun/applet/AppletClassLoader.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/applet/AppletClassLoader.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -168,7 +168,7 @@ > */ > protected Class findClass(String name) throws ClassNotFoundException { > > - int index = name.indexOf(";"); > + int index = name.indexOf(';'); > String cookie = ""; > if(index != -1) { > cookie = name.substring(index, name.length()); > @@ -608,7 +608,7 @@ > > // deal with URL rewriting > String cookie = null; > - int index = name.indexOf(";"); > + int index = name.indexOf(';'); > if(index != -1) { > cookie = name.substring(index, name.length()); > name = name.substring(0, index); > diff -r e323c74edabd src/share/classes/sun/awt/FontConfiguration.java > --- a/src/share/classes/sun/awt/FontConfiguration.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/awt/FontConfiguration.java Sat Apr 26 07:31:04 > 2014 -0300 > @@ -272,9 +272,9 @@ > if (configFile != null) { > return configFile; > } > - int decimalPointIndex = osVersion.indexOf("."); > + int decimalPointIndex = osVersion.indexOf('.'); > if (decimalPointIndex != -1) { > - osMajorVersion = osVersion.substring(0, > osVersion.indexOf(".")); > + osMajorVersion = osVersion.substring(0, > osVersion.indexOf('.')); > configFile = findImpl(baseName + "." + osName + "." + > osMajorVersion); > if (configFile != null) { > return configFile; > diff -r e323c74edabd src/share/classes/sun/font/Type1Font.java > --- a/src/share/classes/sun/font/Type1Font.java Wed Apr 23 11:35:40 2014 > -0700 > +++ b/src/share/classes/sun/font/Type1Font.java Sat Apr 26 07:31:04 2014 > -0300 > @@ -492,7 +492,7 @@ > > //Conversion: Expand abbreviations in style portion (everything > after '-'), > // replace '-' with space and insert missing spaces > - pos = name.indexOf("-"); > + pos = name.indexOf('-'); > if (pos >= 0) { > res = expandName(name.substring(0, pos), false); > res += " " + expandName(name.substring(pos+1), true); > @@ -513,8 +513,8 @@ > //Conversion: Truncate style portion (everything after '-') > // and insert missing spaces > > - if (tmp.indexOf("-") > 0) { > - tmp = tmp.substring(0, tmp.indexOf("-")); > + if (tmp.indexOf('-') > 0) { > + tmp = tmp.substring(0, tmp.indexOf('-')); > } > > return expandName(tmp, false); > diff -r e323c74edabd > src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java > --- a/src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -84,7 +84,7 @@ > * {@inheritDoc} > */ > public String getBaseName() { > - int baseIndex = name.lastIndexOf(".")+1; > + int baseIndex = name.lastIndexOf('.') + 1; > return name.substring(baseIndex); > } > > diff -r e323c74edabd > src/share/classes/sun/jvmstat/monitor/HostIdentifier.java > --- a/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -138,8 +138,8 @@ > String frag = u.getFragment(); > URI u2 = null; > > - int c1index = uriString.indexOf(":"); > - int c2index = uriString.lastIndexOf(":"); > + int c1index = uriString.indexOf(':'); > + int c2index = uriString.lastIndexOf(':'); > if (c2index != c1index) { > /* > * this is the scheme:hostname:port case. Attempt to > diff -r e323c74edabd > src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java > --- > a/src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java > Wed > Apr 23 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java > Sat > Apr 26 07:31:04 2014 -0300 > @@ -70,8 +70,8 @@ > > String addrStr; > if (target.startsWith("[")) { > - final int index = target.indexOf("]"); > - final int index2 = target.lastIndexOf(":"); > + final int index = target.indexOf(']'); > + final int index2 = target.lastIndexOf(':'); > if(index == -1) > throw new IllegalArgumentException("Host starts with [ but > " + > "does not end with ]"); > @@ -85,8 +85,8 @@ > if (addrStr.startsWith("[")) > throw new IllegalArgumentException("More than one > [[...]]"); > } else { > - final int index = target.indexOf(":"); > - final int index2 = target.lastIndexOf(":"); > + final int index = target.indexOf(':'); > + final int index2 = target.lastIndexOf(':'); > if(index == -1) throw new > IllegalArgumentException("Missing port separator \":\""); > addrStr = target.substring(0, index); > @@ -98,7 +98,7 @@ > address = InetAddress.getByName(addrStr); > > //THE CHECK SHOULD BE STRONGER!!! > - final int index = target.lastIndexOf(":"); > + final int index = target.lastIndexOf(':'); > > community = target.substring(index + 1, target.length()); > > diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java > --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sat Apr 26 07:31:04 > 2014 -0300 > @@ -273,8 +273,8 @@ > else > { > // Look for index of "." in the string > - int sIdx = source.indexOf("."); > - int tIdx = target.indexOf("."); > + int sIdx = source.indexOf('.'); > + int tIdx = target.indexOf('.'); > > if (sIdx == -1) > sIdx = source.length() - 1; > @@ -304,10 +304,10 @@ > String versionError = mf.format(args); > > // Look for "-" for pre-release > - int prIndex = token.indexOf("-"); > + int prIndex = token.indexOf('-'); > > // Look for "_" for patch release > - int patchIndex = token.indexOf("_"); > + int patchIndex = token.indexOf('_'); > > if (prIndex == -1 && patchIndex == -1) > { > diff -r e323c74edabd src/share/classes/sun/misc/JarIndex.java > --- a/src/share/classes/sun/misc/JarIndex.java Wed Apr 23 11:35:40 2014 > -0700 > +++ b/src/share/classes/sun/misc/JarIndex.java Sat Apr 26 07:31:04 2014 > -0300 > @@ -172,7 +172,7 @@ > if ((jarFiles = indexMap.get(fileName)) == null) { > /* try the package name again */ > int pos; > - if((pos = fileName.lastIndexOf("/")) != -1) { > + if((pos = fileName.lastIndexOf('/')) != -1) { > jarFiles = indexMap.get(fileName.substring(0, pos)); > } > } > @@ -195,7 +195,7 @@ > public void add(String fileName, String jarName) { > String packageName; > int pos; > - if((pos = fileName.lastIndexOf("/")) != -1) { > + if((pos = fileName.lastIndexOf('/')) != -1) { > packageName = fileName.substring(0, pos); > } else { > packageName = fileName; > diff -r e323c74edabd src/share/classes/sun/misc/URLClassPath.java > --- a/src/share/classes/sun/misc/URLClassPath.java Wed Apr 23 11:35:40 2014 > -0700 > +++ b/src/share/classes/sun/misc/URLClassPath.java Sat Apr 26 07:31:04 2014 > -0300 > @@ -793,7 +793,7 @@ > boolean validIndex(final String name) { > String packageName = name; > int pos; > - if((pos = name.lastIndexOf("/")) != -1) { > + if((pos = name.lastIndexOf('/')) != -1) { > packageName = name.substring(0, pos); > } > > @@ -803,7 +803,7 @@ > while (enum_.hasMoreElements()) { > entry = enum_.nextElement(); > entryName = entry.getName(); > - if((pos = entryName.lastIndexOf("/")) != -1) > + if((pos = entryName.lastIndexOf('/')) != -1) > entryName = entryName.substring(0, pos); > if (entryName.equals(packageName)) { > return true; > @@ -900,7 +900,7 @@ > */ > JarIndex newIndex = newLoader.getIndex(); > if(newIndex != null) { > - int pos = jarName.lastIndexOf("/"); > + int pos = jarName.lastIndexOf('/'); > newIndex.merge(this.index, (pos == -1 ? > null : jarName.substring(0, pos + 1))); > } > diff -r e323c74edabd src/share/classes/sun/net/ftp/impl/FtpClient.java > --- a/src/share/classes/sun/net/ftp/impl/FtpClient.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/net/ftp/impl/FtpClient.java Sat Apr 26 07:31:04 > 2014 -0300 > @@ -259,7 +259,7 @@ > d = null; > } > if (d != null && time != null) { > - int c = time.indexOf(":"); > + int c = time.indexOf(':'); > now.setTime(d); > now.set(Calendar.HOUR, > Integer.parseInt(time.substring(0, c))); > now.set(Calendar.MINUTE, > Integer.parseInt(time.substring(c + 1))); > @@ -295,7 +295,7 @@ > > public FtpDirEntry parseLine(String line) { > String name = null; > - int i = line.lastIndexOf(";"); > + int i = line.lastIndexOf(';'); > if (i > 0) { > name = line.substring(i + 1).trim(); > line = line.substring(0, i); > @@ -306,7 +306,7 @@ > FtpDirEntry file = new FtpDirEntry(name); > while (!line.isEmpty()) { > String s; > - i = line.indexOf(";"); > + i = line.indexOf(';'); > if (i > 0) { > s = line.substring(0, i); > line = line.substring(i + 1); > @@ -314,7 +314,7 @@ > s = line; > line = ""; > } > - i = s.indexOf("="); > + i = s.indexOf('='); > if (i > 0) { > String fact = s.substring(0, i); > String value = s.substring(i + 1); > diff -r e323c74edabd > src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java > --- a/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -325,7 +325,7 @@ > while (i.hasNext()) { > String parentDomain = i.next(); > int start = 0; > - while ((start = parentDomain.indexOf(".")) != -1 > + while ((start = parentDomain.indexOf('.')) != -1 > && start < parentDomain.length() -1) { > try { > results = resolve(ctx, host+"."+parentDomain, ids, > 0); > diff -r e323c74edabd src/share/classes/sun/net/util/IPAddressUtil.java > --- a/src/share/classes/sun/net/util/IPAddressUtil.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/net/util/IPAddressUtil.java Sat Apr 26 07:31:04 > 2014 -0300 > @@ -149,7 +149,7 @@ > byte[] dst = new byte[INADDR16SZ]; > > int srcb_length = srcb.length; > - int pc = src.indexOf ("%"); > + int pc = src.indexOf ('%'); > if (pc == srcb_length -1) { > return null; > } > diff -r e323c74edabd src/share/classes/sun/net/www/ParseUtil.java > --- a/src/share/classes/sun/net/www/ParseUtil.java Wed Apr 23 11:35:40 2014 > -0700 > +++ b/src/share/classes/sun/net/www/ParseUtil.java Sat Apr 26 07:31:04 2014 > -0300 > @@ -356,8 +356,8 @@ > * because we must not quote a literal IPv6 address > */ > if (opaquePart.startsWith("//[")) { > - int end = opaquePart.indexOf("]"); > - if (end != -1 && opaquePart.indexOf(":")!=-1) { > + int end = opaquePart.indexOf(']'); > + if (end != -1 && opaquePart.indexOf(':')!=-1) { > String doquote, dontquote; > if (end == opaquePart.length()) { > dontquote = opaquePart; > @@ -408,8 +408,8 @@ > } else if (authority != null) { > sb.append("//"); > if (authority.startsWith("[")) { > - int end = authority.indexOf("]"); > - if (end != -1 && authority.indexOf(":")!=-1) { > + int end = authority.indexOf(']'); > + if (end != -1 && authority.indexOf(':')!=-1) { > String doquote, dontquote; > if (end == authority.length()) { > dontquote = authority; > diff -r e323c74edabd src/share/classes/sun/reflect/misc/ReflectUtil.java > --- a/src/share/classes/sun/reflect/misc/ReflectUtil.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/reflect/misc/ReflectUtil.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -341,6 +341,6 @@ > * (not to be confused with a Java Language anonymous inner class). > */ > public static boolean isVMAnonymousClass(Class cls) { > - return cls.getName().indexOf("/") > -1; > + return cls.getName().indexOf('/') > -1; > } > } > diff -r e323c74edabd src/share/classes/sun/rmi/runtime/Log.java > --- a/src/share/classes/sun/rmi/runtime/Log.java Wed Apr 23 11:35:40 2014 > -0700 > +++ b/src/share/classes/sun/rmi/runtime/Log.java Sat Apr 26 07:31:04 2014 > -0300 > @@ -434,7 +434,7 @@ > * Mimic old log messages that only contain unqualified names. > */ > private static String unqualifiedName(String name) { > - int lastDot = name.lastIndexOf("."); > + int lastDot = name.lastIndexOf('.'); > if (lastDot >= 0) { > name = name.substring(lastDot + 1); > } > diff -r e323c74edabd > src/share/classes/sun/rmi/transport/proxy/CGIHandler.java > --- a/src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -141,7 +141,7 @@ > { > try { > String command, param; > - int delim = QueryString.indexOf("="); > + int delim = QueryString.indexOf('='); > if (delim == -1) { > command = QueryString; > param = ""; > diff -r e323c74edabd > src/share/classes/sun/security/jgss/wrapper/Krb5Util.java > --- a/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -39,7 +39,7 @@ > static String getTGSName(GSSNameElement name) > throws GSSException { > String krbPrinc = name.getKrbName(); > - int atIndex = krbPrinc.indexOf("@"); > + int atIndex = krbPrinc.indexOf('@'); > String realm = krbPrinc.substring(atIndex + 1); > StringBuffer buf = new StringBuffer("krbtgt/"); > buf.append(realm).append('@').append(realm); > diff -r e323c74edabd src/share/classes/sun/security/provider/PolicyFile.java > --- a/src/share/classes/sun/security/provider/PolicyFile.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/security/provider/PolicyFile.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -1856,7 +1856,7 @@ > int colonIndex; > String prefix = value; > String suffix; > - if ((colonIndex = value.indexOf(":")) != -1) { > + if ((colonIndex = value.indexOf(':')) != -1) { > prefix = value.substring(0, colonIndex); > } > > diff -r e323c74edabd > src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java > --- a/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java Wed Apr > 23 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java Sat Apr > 26 07:31:04 2014 -0300 > @@ -338,7 +338,7 @@ > } > String sigType; > if (keyType.contains("_")) { > - int k = keyType.indexOf("_"); > + int k = keyType.indexOf('_'); > sigType = keyType.substring(k + 1); > keyType = keyType.substring(0, k); > } else { > diff -r e323c74edabd > src/share/classes/sun/security/ssl/X509KeyManagerImpl.java > --- a/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -302,7 +302,7 @@ > final String sigKeyAlgorithm; > > KeyType(String algorithm) { > - int k = algorithm.indexOf("_"); > + int k = algorithm.indexOf('_'); > if (k == -1) { > keyAlgorithm = algorithm; > sigKeyAlgorithm = null; > diff -r e323c74edabd > src/share/classes/sun/security/util/HostnameChecker.java > --- a/src/share/classes/sun/security/util/HostnameChecker.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/security/util/HostnameChecker.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -300,8 +300,8 @@ > template = template.toLowerCase(Locale.ENGLISH); > > // Retreive leftmost component > - int templateIdx = template.indexOf("."); > - int nameIdx = name.indexOf("."); > + int templateIdx = template.indexOf('.'); > + int nameIdx = name.indexOf('.'); > > if (templateIdx == -1) > templateIdx = template.length(); > @@ -326,7 +326,7 @@ > */ > private static boolean matchWildCards(String name, String template) { > > - int wildcardIdx = template.indexOf("*"); > + int wildcardIdx = template.indexOf('*'); > if (wildcardIdx == -1) > return name.equals(template); > > @@ -349,7 +349,7 @@ > > // update the match scope > name = name.substring(beforeStartIdx + > beforeWildcard.length()); > - wildcardIdx = afterWildcard.indexOf("*"); > + wildcardIdx = afterWildcard.indexOf('*'); > } > return name.endsWith(afterWildcard); > } > diff -r e323c74edabd > src/share/classes/sun/security/util/SignatureFileVerifier.java > --- a/src/share/classes/sun/security/util/SignatureFileVerifier.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/security/util/SignatureFileVerifier.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -98,7 +98,7 @@ > } finally { > Providers.stopJarVerification(obj); > } > - this.name = name.substring(0, name.lastIndexOf(".")) > + this.name = name.substring(0, name.lastIndexOf('.')) > > .toUpperCase(Locale.ENGLISH); > this.md = md; > this.signerCache = signerCache; > diff -r e323c74edabd src/share/classes/sun/security/x509/CRLExtensions.java > --- a/src/share/classes/sun/security/x509/CRLExtensions.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/security/x509/CRLExtensions.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -185,7 +185,7 @@ > String name; > String id = attr.getPrefix(); > if (id.equalsIgnoreCase(X509CertImpl.NAME)) { // fully qualified > - int index = alias.lastIndexOf("."); > + int index = alias.lastIndexOf('.'); > name = alias.substring(index + 1); > } else > name = alias; > diff -r e323c74edabd src/share/classes/sun/tools/jconsole/ConnectDialog.java > --- a/src/share/classes/sun/tools/jconsole/ConnectDialog.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/tools/jconsole/ConnectDialog.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -325,7 +325,7 @@ > } else { > String host = remoteTF.getText().trim(); > String port = "0"; > - int index = host.lastIndexOf(":"); > + int index = host.lastIndexOf(':'); > if (index >= 0) { > port = host.substring(index + 1); > host = host.substring(0, index); > diff -r e323c74edabd > src/share/classes/sun/tools/jconsole/inspector/Utils.java > --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -210,7 +210,7 @@ > public static String getArrayClassName(String name) { > String className = null; > if (name.startsWith("[")) { > - int index = name.lastIndexOf("["); > + int index = name.lastIndexOf('['); > className = name.substring(index, name.length()); > if (className.startsWith("[L")) { > className = className.substring(2, className.length() - 1); > @@ -241,7 +241,7 @@ > if (className == null) { > return name; > } > - int index = name.lastIndexOf("["); > + int index = name.lastIndexOf('['); > StringBuilder brackets = new StringBuilder(className); > for (int i = 0; i <= index; i++) { > brackets.append("[]"); > diff -r e323c74edabd > src/share/classes/sun/tools/jconsole/inspector/XOperations.java > --- a/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Sat > Apr 26 07:31:04 2014 -0300 > @@ -112,7 +112,7 @@ > if (methodLabel.getText().length() > 20) { > methodLabel.setText(methodLabel.getText(). > substring(methodLabel.getText(). > - lastIndexOf(".") + 1, > + lastIndexOf('.') + 1, > methodLabel.getText().length())); > } > > diff -r e323c74edabd > src/share/classes/sun/tools/jconsole/inspector/XTree.java > --- a/src/share/classes/sun/tools/jconsole/inspector/XTree.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/tools/jconsole/inspector/XTree.java Sat Apr 26 > 07:31:04 2014 -0300 > @@ -475,7 +475,7 @@ > private static Map extractKeyValuePairs( > String props, ObjectName mbean) { > Map map = new LinkedHashMap(); > - int eq = props.indexOf("="); > + int eq = props.indexOf('='); > while (eq != -1) { > String key = props.substring(0, eq); > String value = mbean.getKeyProperty(key); > @@ -484,7 +484,7 @@ > if (props.startsWith(",")) { > props = props.substring(1); > } > - eq = props.indexOf("="); > + eq = props.indexOf('='); > } > return map; > } > @@ -821,7 +821,7 @@ > } > > private void buildKeyValue() { > - int index = tokenValue.indexOf("="); > + int index = tokenValue.indexOf('='); > if (index < 0) { > key = tokenValue; > value = tokenValue; > From david.holmes at oracle.com Sun Apr 27 12:04:58 2014 From: david.holmes at oracle.com (David Holmes) Date: Sun, 27 Apr 2014 22:04:58 +1000 Subject: inefficient indexof when String has one length In-Reply-To: <535BE93A.90604@oracle.com> References: <535BE93A.90604@oracle.com> Message-ID: <535CF26A.8090507@oracle.com> There is also a slight reduction in memory pressure due to not creating a bunch of one character string literals. David On 27/04/2014 3:13 AM, Claes Redestad wrote: > Hi Ot?vio, > > while I personally like using chars instead of Strings where > applicable, I would assume these constant replacements are all cases > where the JIT will be quick to inline and eliminate the overhead. So the > benefit, if any, would be in interpreted code. Testing these assumptions > with a simple but representative JMH[1] microbenchmark[2]: > > Benchmark Mode Samples Mean Mean > error Units > o.s.MyBenchmark.indexOfChar thrpt 20 32290.764 359.347 > ops/ms > o.s.MyBenchmark.indexOfString thrpt 20 32353.865 398.929 > ops/ms > o.s.MyBenchmark.lastIndexOfChar thrpt 20 32444.428 462.630 > ops/ms > o.s.MyBenchmark.lastIndexOfString thrpt 20 32001.738 388.791 > ops/ms > > So no real difference, as suspected. Running with -Xint: > > Benchmark Mode Samples Mean Mean > error Units > o.s.MyBenchmark.indexOfChar thrpt 20 3170.130 108.933 > ops/ms > o.s.MyBenchmark.indexOfString thrpt 20 3119.518 44.703 > ops/ms > o.s.MyBenchmark.lastIndexOfChar thrpt 20 3281.374 25.589 > ops/ms > o.s.MyBenchmark.lastIndexOfString thrpt 20 3154.710 45.224 > ops/ms > > Not much - if anything - here either. I think more evidence that this > would have some actual benefit is warranted. > > /Claes > > [1] http://openjdk.java.net/projects/code-tools/jmh/ > [2] package org.sample; > > import org.openjdk.jmh.annotations.*; > > import java.util.Random; > > @State(Scope.Thread) > public class MyBenchmark { > > /* > * Generate a lot of randomly generated strings of various sizes > */ > static int NUM = 100000; > static int MAX_SIZE = 1000; > static String[] STRINGS = new String[NUM]; > > static { > Random r = new Random(); > for (int i = 0; i < NUM; i++) { > StringBuilder sb = new StringBuilder(r.nextInt(MAX_SIZE) + 1); > for (int j = 0; j < sb.capacity(); j++) { > sb.append((char)(r.nextInt(70) + '0')); > } > STRINGS[i] = sb.toString(); > } > } > > private int i = 0; > > @GenerateMicroBenchmark > public int indexOfString() { > if (i >= NUM) { i = 0; } > return STRINGS[i++].indexOf("6"); > } > > @GenerateMicroBenchmark > public int lastIndexOfString() { > if (i >= NUM) { i = 0; } > return STRINGS[i++].indexOf("6"); > } > > @GenerateMicroBenchmark > public int indexOfChar() { > if (i >= NUM) { i = 0; } > return STRINGS[i++].indexOf('6'); > } > > @GenerateMicroBenchmark > public int lastIndexOfChar() { > if (i >= NUM) { i = 0; } > return STRINGS[i++].indexOf('6'); > } > } > > On 2014-04-26 12:56, Ot?vio Gon?alves de Santana wrote: >> When a String has length just one, could be replaced by equivalent >> character literals, gaining some performance enhancement. >> >> I found 107 changes. >> >> >> diff -r e323c74edabd >> src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java >> --- a/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Wed Apr >> 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Sat Apr >> 26 07:31:04 2014 -0300 >> @@ -547,7 +547,7 @@ >> i = >> strLowerCase.indexOf("", i); >> if (i > 0) { >> i += "".length(); >> - int i2 = str.indexOf("<", i); >> + int i2 = str.indexOf('<', i); >> return str.substring(i, i2); >> } >> } >> diff -r e323c74edabd >> src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java >> --- a/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Wed >> Apr 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -512,7 +512,7 @@ >> } >> static String qualifiedStringValue(String s1, String s234) { >> // Qualification by dot must decompose uniquely. Second string >> might already be qualified. >> - assert(s1.indexOf(".") < 0); >> + assert(s1.indexOf('.') < 0); >> return s1+"."+s234; >> } >> >> diff -r e323c74edabd >> src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java >> --- a/src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java Sat >> Apr 26 >> 07:31:04 2014 -0300 >> @@ -102,7 +102,7 @@ >> } >> location = url.substring(addrStart, addrEnd); >> >> - int keyStart = location.indexOf("/"); >> + int keyStart = location.indexOf('/'); >> if (keyStart >= 0) { >> // Has key string >> if (keyStart == (location.length() -1)) { >> diff -r e323c74edabd >> src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java >> --- a/src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java >> Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -336,7 +336,7 @@ >> String url = "rmi://"; >> >> // Enclose IPv6 literal address in '[' and ']' >> - url = (host.indexOf(":") > -1) ? url + "[" + host + "]" : >> + url = (host.indexOf(':') > -1) ? url + "[" + host + "]" : >> url + host; >> if (port > 0) { >> url += ":" + Integer.toString(port); >> diff -r e323c74edabd >> src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java >> --- >> a/src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -149,7 +149,7 @@ >> * foo:rest/of/name foo: >> */ >> protected String getURLPrefix(String url) throws NamingException { >> - int start = url.indexOf(":"); >> + int start = url.indexOf(':'); >> >> if (start < 0) { >> throw new OperationNotSupportedException("Invalid URL: " + >> url); >> @@ -160,7 +160,7 @@ >> start += 2; // skip double slash >> >> // find last slash >> - int posn = url.indexOf("/", start); >> + int posn = url.indexOf('/', start); >> if (posn >= 0) { >> start = posn; >> } else { >> diff -r e323c74edabd >> src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java >> --- a/src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java Wed >> Apr >> 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java Sat >> Apr >> 26 07:31:04 2014 -0300 >> @@ -303,7 +303,7 @@ >> >> offset = pname.length() - 1; >> >> - while ((last = pname.lastIndexOf(".", offset)) != -1) { >> + while ((last = pname.lastIndexOf('.', offset)) != -1) { >> >> pname = pname.substring(0, last+1) + "*"; >> x = permissions.get(pname); >> @@ -318,7 +318,7 @@ >> pname = p.getName(); >> offset = pname.length() - 1; >> >> - while ((last = pname.lastIndexOf("=", offset)) != -1) { >> + while ((last = pname.lastIndexOf('=', offset)) != -1) { >> >> pname = pname.substring(0, last+1) + "*"; >> x = permissions.get(pname); >> diff -r e323c74edabd >> src/share/classes/com/sun/rowset/CachedRowSetImpl.java >> --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -6831,7 +6831,7 @@ >> // table name else isolate table name. >> >> indexFrom = command.toLowerCase().indexOf("from"); >> - indexComma = command.indexOf(",", indexFrom); >> + indexComma = command.indexOf(',', indexFrom); >> >> if(indexComma == -1) { >> // implies only one table >> diff -r e323c74edabd src/share/classes/com/sun/rowset/JoinRowSetImpl.java >> --- a/src/share/classes/com/sun/rowset/JoinRowSetImpl.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/com/sun/rowset/JoinRowSetImpl.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -910,7 +910,7 @@ >> >> // now remove the last "," >> strWhereClause = strWhereClause.substring >> - (0, strWhereClause.lastIndexOf(",")); >> + (0, strWhereClause.lastIndexOf(',')); >> >> // Add from clause >> strWhereClause = strWhereClause.concat(" from "); >> @@ -920,7 +920,7 @@ >> >> //Remove the last "," >> strWhereClause = strWhereClause.substring >> - (0, strWhereClause.lastIndexOf(",")); >> + (0, strWhereClause.lastIndexOf(',')); >> >> // Add the where clause >> strWhereClause = strWhereClause.concat(" where "); >> diff -r e323c74edabd >> src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java >> --- >> a/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -240,7 +240,7 @@ >> // Remove the string after "@xxxx" >> // before writing it to the xml file. >> String strProviderInstance = >> (caller.getSyncProvider()).toString(); >> - String strProvider = strProviderInstance.substring(0, >> (caller.getSyncProvider()).toString().indexOf("@")); >> + String strProvider = strProviderInstance.substring(0, >> (caller.getSyncProvider()).toString().indexOf('@')); >> >> propString("sync-provider-name", strProvider); >> propString("sync-provider-vendor", "Oracle Corporation"); >> diff -r e323c74edabd >> src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java >> --- >> a/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java >> Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -1147,7 +1147,7 @@ >> if (nullValue) { >> rs.setSyncProvider(null); >> } else { >> - String str = s.substring(0,s.indexOf("@")+1); >> + String str = s.substring(0,s.indexOf('@')+1); >> rs.setSyncProvider(str); >> } >> break; >> diff -r e323c74edabd >> src/share/classes/com/sun/rowset/internal/XmlResolver.java >> --- a/src/share/classes/com/sun/rowset/internal/XmlResolver.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/com/sun/rowset/internal/XmlResolver.java Sat >> Apr 26 >> 07:31:04 2014 -0300 >> @@ -39,7 +39,7 @@ >> public class XmlResolver implements EntityResolver { >> >> public InputSource resolveEntity(String publicId, String >> systemId) >> { >> - String schemaName = >> systemId.substring(systemId.lastIndexOf("/")); >> + String schemaName = >> systemId.substring(systemId.lastIndexOf('/')); >> >> if(systemId.startsWith("http://java.sun.com/xml/ns/jdbc")) { >> return new >> InputSource(this.getClass().getResourceAsStream(schemaName)); >> diff -r e323c74edabd >> src/share/classes/com/sun/security/auth/module/JndiLoginModule.java >> --- >> a/src/share/classes/com/sun/security/auth/module/JndiLoginModule.java Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/com/sun/security/auth/module/JndiLoginModule.java Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -694,7 +694,7 @@ >> throw new LoginException("Error: no CallbackHandler >> available >> " + >> "to garner authentication information from the user"); >> >> - String protocol = userProvider.substring(0, >> userProvider.indexOf(":")); >> + String protocol = userProvider.substring(0, >> userProvider.indexOf(':')); >> >> Callback[] callbacks = new Callback[2]; >> callbacks[0] = new NameCallback(protocol + " " >> diff -r e323c74edabd >> src/share/classes/com/sun/security/auth/module/LdapLoginModule.java >> --- >> a/src/share/classes/com/sun/security/auth/module/LdapLoginModule.java Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/com/sun/security/auth/module/LdapLoginModule.java Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -400,7 +400,7 @@ >> >> // Add any JNDI properties to the environment >> for (String key : options.keySet()) { >> - if (key.indexOf(".") > -1) { >> + if (key.indexOf('.') > -1) { >> ldapEnvironment.put(key, options.get(key)); >> } >> } >> diff -r e323c74edabd >> src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java >> --- >> a/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java >> Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -857,7 +857,7 @@ >> bpSpec = runtime.createClassLineBreakpoint(classId, >> lineNumber); >> } else { >> // Try stripping method from class.method token. >> - int idot = token.lastIndexOf("."); >> + int idot = token.lastIndexOf('.'); >> if ( (idot <= 0) || /* No dot or dot in first >> char >> */ >> (idot >= token.length() - 1) ) { /* dot in last >> char >> */ >> return null; >> diff -r e323c74edabd >> src/share/classes/com/sun/tools/example/debug/tty/Commands.java >> --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed >> Apr 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -1079,7 +1079,7 @@ >> } >> } else { >> // Try stripping method from class.method token. >> - int idot = token.lastIndexOf("."); >> + int idot = token.lastIndexOf('.'); >> if ( (idot <= 0) || /* No dot or >> dot >> in first char */ >> (idot >= token.length() - 1) ) { /* dot in last >> char >> */ >> printBreakpointCommandUsage(atForm, inForm); >> diff -r e323c74edabd >> src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java >> --- >> a/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java >> Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -67,7 +67,7 @@ >> continue; >> } >> String name = clazz.getName(); >> - int pos = name.lastIndexOf("."); >> + int pos = name.lastIndexOf('.'); >> String pkg; >> if (name.startsWith("[")) { // Only in ancient heap >> dumps >> pkg = ""; >> diff -r e323c74edabd src/share/classes/java/lang/Class.java >> --- a/src/share/classes/java/lang/Class.java Wed Apr 23 11:35:40 2014 >> -0700 >> +++ b/src/share/classes/java/lang/Class.java Sat Apr 26 07:31:04 2014 >> -0300 >> @@ -1296,7 +1296,7 @@ >> String simpleName = getSimpleBinaryName(); >> if (simpleName == null) { // top level class >> simpleName = getName(); >> - return >> simpleName.substring(simpleName.lastIndexOf(".")+1); // >> strip the package name >> + return >> simpleName.substring(simpleName.lastIndexOf('.')+1); // >> strip the package name >> } >> // According to JLS3 "Binary Compatibility" (13.1) the binary >> // name of non-package classes (not top level) is the binary >> diff -r e323c74edabd src/share/classes/java/lang/ClassLoader.java >> --- a/src/share/classes/java/lang/ClassLoader.java Wed Apr 23 11:35:40 >> 2014 >> -0700 >> +++ b/src/share/classes/java/lang/ClassLoader.java Sat Apr 26 07:31:04 >> 2014 >> -0300 >> @@ -2136,7 +2136,7 @@ >> return result.booleanValue(); >> >> // Check for most specific package entry >> - int dotIndex = className.lastIndexOf("."); >> + int dotIndex = className.lastIndexOf('.'); >> if (dotIndex < 0) { // default package >> result = packageAssertionStatus.get(null); >> if (result != null) >> @@ -2147,7 +2147,7 @@ >> result = packageAssertionStatus.get(className); >> if (result != null) >> return result.booleanValue(); >> - dotIndex = className.lastIndexOf(".", dotIndex-1); >> + dotIndex = className.lastIndexOf('.', dotIndex-1); >> } >> >> // Return the classloader default >> diff -r e323c74edabd >> src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >> --- a/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >> Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -84,7 +84,7 @@ >> private InvokerBytecodeGenerator(LambdaForm lambdaForm, int >> localsMapSize, >> String className, String >> invokerName, >> MethodType invokerType) { >> if (invokerName.contains(".")) { >> - int p = invokerName.indexOf("."); >> + int p = invokerName.indexOf('.'); >> className = invokerName.substring(0, p); >> invokerName = invokerName.substring(p+1); >> } >> diff -r e323c74edabd src/share/classes/java/net/CookieManager.java >> --- a/src/share/classes/java/net/CookieManager.java Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/java/net/CookieManager.java Sat Apr 26 07:31:04 >> 2014 -0300 >> @@ -294,7 +294,7 @@ >> // the path is the directory of the >> page/doc >> String path = uri.getPath(); >> if (!path.endsWith("/")) { >> - int i = path.lastIndexOf("/"); >> + int i = path.lastIndexOf('/'); >> if (i > 0) { >> path = path.substring(0, i + 1); >> } else { >> @@ -364,7 +364,7 @@ >> >> >> static private boolean isInPortList(String lst, int port) { >> - int i = lst.indexOf(","); >> + int i = lst.indexOf(','); >> int val = -1; >> while (i > 0) { >> try { >> @@ -375,7 +375,7 @@ >> } catch (NumberFormatException numberFormatException) { >> } >> lst = lst.substring(i+1); >> - i = lst.indexOf(","); >> + i = lst.indexOf(','); >> } >> if (!lst.isEmpty()) { >> try { >> diff -r e323c74edabd src/share/classes/java/net/InetAddress.java >> --- a/src/share/classes/java/net/InetAddress.java Wed Apr 23 11:35:40 >> 2014 >> -0700 >> +++ b/src/share/classes/java/net/InetAddress.java Sat Apr 26 07:31:04 >> 2014 >> -0300 >> @@ -1138,7 +1138,7 @@ >> // This is supposed to be an IPv6 literal >> // Check if a numeric or string zone id is present >> int pos; >> - if ((pos=host.indexOf ("%")) != -1) { >> + if ((pos=host.indexOf ('%')) != -1) { >> numericZone = checkNumericZone (host); >> if (numericZone == -1) { /* remainder of string >> must >> be an ifname */ >> ifname = host.substring (pos+1); >> diff -r e323c74edabd src/share/classes/java/net/SocketPermission.java >> --- a/src/share/classes/java/net/SocketPermission.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/java/net/SocketPermission.java Sat Apr 26 >> 07:31:04 >> 2014 -0300 >> @@ -777,7 +777,7 @@ >> // Literal IPv6 address >> host = getName().substring(1, getName().indexOf(']')); >> } else { >> - int i = getName().indexOf(":"); >> + int i = getName().indexOf(':'); >> if (i == -1) >> host = getName(); >> else { >> diff -r e323c74edabd src/share/classes/java/net/SocksSocketImpl.java >> --- a/src/share/classes/java/net/SocksSocketImpl.java Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/java/net/SocksSocketImpl.java Sat Apr 26 07:31:04 >> 2014 -0300 >> @@ -368,7 +368,7 @@ >> String host = epoint.getHostString(); >> // IPv6 litteral? >> if (epoint.getAddress() instanceof Inet6Address && >> - (!host.startsWith("[")) && (host.indexOf(":") >= 0)) { >> + (!host.startsWith("[")) && (host.indexOf(':') >= 0)) { >> host = "[" + host + "]"; >> } >> try { >> @@ -684,7 +684,7 @@ >> String host = saddr.getHostString(); >> // IPv6 litteral? >> if (saddr.getAddress() instanceof Inet6Address && >> - (!host.startsWith("[")) && (host.indexOf(":") >= 0)) { >> + (!host.startsWith("[")) && (host.indexOf(':') >= 0)) { >> host = "[" + host + "]"; >> } >> try { >> diff -r e323c74edabd src/share/classes/java/net/URI.java >> --- a/src/share/classes/java/net/URI.java Wed Apr 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/java/net/URI.java Sat Apr 26 07:31:04 2014 -0300 >> @@ -1851,9 +1851,9 @@ >> sb.append("//"); >> if (authority.startsWith("[")) { >> // authority should (but may not) contain an >> embedded IPv6 >> address >> - int end = authority.indexOf("]"); >> + int end = authority.indexOf(']'); >> String doquote = authority, dontquote = ""; >> - if (end != -1 && authority.indexOf(":") != -1) { >> + if (end != -1 && authority.indexOf(':') != -1) { >> // the authority contains an IPv6 address >> if (end == authority.length()) { >> dontquote = authority; >> @@ -1889,8 +1889,8 @@ >> * because we must not quote a literal IPv6 address >> */ >> if (opaquePart.startsWith("//[")) { >> - int end = opaquePart.indexOf("]"); >> - if (end != -1 && opaquePart.indexOf(":")!=-1) { >> + int end = opaquePart.indexOf(']'); >> + if (end != -1 && opaquePart.indexOf(':')!=-1) { >> String doquote, dontquote; >> if (end == opaquePart.length()) { >> dontquote = opaquePart; >> diff -r e323c74edabd src/share/classes/java/security/BasicPermission.java >> --- a/src/share/classes/java/security/BasicPermission.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/java/security/BasicPermission.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -430,7 +430,7 @@ >> >> offset = path.length()-1; >> >> - while ((last = path.lastIndexOf(".", offset)) != -1) { >> + while ((last = path.lastIndexOf('.', offset)) != -1) { >> >> path = path.substring(0, last+1) + "*"; >> //System.out.println("check "+path); >> diff -r e323c74edabd src/share/classes/java/security/Provider.java >> --- a/src/share/classes/java/security/Provider.java Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/java/security/Provider.java Sat Apr 26 07:31:04 >> 2014 -0300 >> @@ -927,7 +927,7 @@ >> } >> >> private String[] getTypeAndAlgorithm(String key) { >> - int i = key.indexOf("."); >> + int i = key.indexOf('.'); >> if (i < 1) { >> if (debug != null) { >> debug.println("Ignoring invalid entry in provider " >> diff -r e323c74edabd src/share/classes/java/security/Security.java >> --- a/src/share/classes/java/security/Security.java Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/java/security/Security.java Sat Apr 26 07:31:04 >> 2014 -0300 >> @@ -1114,7 +1114,7 @@ >> // implementation of an algorithm. We are only >> interested >> // in entries which lead to the implementation >> // classes. >> - if (currentKey.indexOf(" ") < 0) { >> + if (currentKey.indexOf(' ') < 0) { >> result.add(currentKey.substring( >> serviceName.length() >> + 1)); >> } >> diff -r e323c74edabd src/share/classes/java/util/PropertyPermission.java >> --- a/src/share/classes/java/util/PropertyPermission.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/java/util/PropertyPermission.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -547,7 +547,7 @@ >> >> offset = name.length()-1; >> >> - while ((last = name.lastIndexOf(".", offset)) != -1) { >> + while ((last = name.lastIndexOf('.', offset)) != -1) { >> >> name = name.substring(0, last+1) + "*"; >> //System.out.println("check "+name); >> diff -r e323c74edabd src/share/classes/java/util/jar/JarVerifier.java >> --- a/src/share/classes/java/util/jar/JarVerifier.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/java/util/jar/JarVerifier.java Sat Apr 26 >> 07:31:04 >> 2014 -0300 >> @@ -278,7 +278,7 @@ >> >> // now we are parsing a signature block file >> >> - String key = uname.substring(0, uname.lastIndexOf(".")); >> + String key = uname.substring(0, uname.lastIndexOf('.')); >> >> if (signerCache == null) >> signerCache = new ArrayList<>(); >> diff -r e323c74edabd src/share/classes/java/util/logging/LogManager.java >> --- a/src/share/classes/java/util/logging/LogManager.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/java/util/logging/LogManager.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -866,7 +866,7 @@ >> >> int ix = 1; >> for (;;) { >> - int ix2 = name.indexOf(".", ix); >> + int ix2 = name.indexOf('.', ix); >> if (ix2 < 0) { >> break; >> } >> @@ -889,7 +889,7 @@ >> } >> LogNode node = root; >> while (name.length() > 0) { >> - int ix = name.indexOf("."); >> + int ix = name.indexOf('.'); >> String head; >> if (ix > 0) { >> head = name.substring(0, ix); >> diff -r e323c74edabd >> src/share/classes/java/util/logging/XMLFormatter.java >> --- a/src/share/classes/java/util/logging/XMLFormatter.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/java/util/logging/XMLFormatter.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -174,7 +174,7 @@ >> // Check to see if the parameter was not a messagetext format >> // or was not null or empty >> if ( parameters != null && parameters.length != 0 >> - && record.getMessage().indexOf("{") == -1 ) { >> + && record.getMessage().indexOf('{') == -1 ) { >> for (int i = 0; i < parameters.length; i++) { >> sb.append(" "); >> try { >> diff -r e323c74edabd >> src/share/classes/javax/management/MBeanPermission.java >> --- a/src/share/classes/javax/management/MBeanPermission.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/javax/management/MBeanPermission.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -290,7 +290,7 @@ >> >> // Parse ObjectName >> >> - int openingBracket = name.indexOf("["); >> + int openingBracket = name.indexOf('['); >> if (openingBracket == -1) { >> // If "[on]" missing then ObjectName("*:*") >> // >> @@ -329,7 +329,7 @@ >> >> // Parse member >> >> - int poundSign = name.indexOf("#"); >> + int poundSign = name.indexOf('#'); >> >> if (poundSign == -1) >> setMember("*"); >> diff -r e323c74edabd >> src/share/classes/javax/management/modelmbean/DescriptorSupport.java >> --- >> a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java >> Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -329,7 +329,7 @@ >> inFld = false; >> } else if (inFld && inDesc) { >> // want kw=value, eg, name="myname" value="myvalue" >> - int eq_separator = tok.indexOf("="); >> + int eq_separator = tok.indexOf('='); >> if (eq_separator > 0) { >> String kwPart = tok.substring(0,eq_separator); >> String valPart = tok.substring(eq_separator+1); >> @@ -458,7 +458,7 @@ >> if ((fields[i] == null) || (fields[i].equals(""))) { >> continue; >> } >> - int eq_separator = fields[i].indexOf("="); >> + int eq_separator = fields[i].indexOf('='); >> if (eq_separator < 0) { >> // illegal if no = or is first character >> if (MODELMBEAN_LOGGER.isLoggable(Level.FINEST)) { >> diff -r e323c74edabd >> src/share/classes/javax/management/modelmbean/RequiredModelMBean.java >> --- >> a/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Wed >> >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Sat >> >> Apr 26 07:31:04 2014 -0300 >> @@ -934,7 +934,7 @@ >> String opMethodName; >> >> // Parse for class name and method >> - int opSplitter = opName.lastIndexOf("."); >> + int opSplitter = opName.lastIndexOf('.'); >> if (opSplitter > 0) { >> opClassName = opName.substring(0,opSplitter); >> opMethodName = opName.substring(opSplitter+1); >> @@ -943,7 +943,7 @@ >> >> /* Ignore anything after a left paren. We keep this for >> compatibility but it isn't specified. */ >> - opSplitter = opMethodName.indexOf("("); >> + opSplitter = opMethodName.indexOf('('); >> if (opSplitter > 0) >> opMethodName = opMethodName.substring(0,opSplitter); >> >> diff -r e323c74edabd >> src/share/classes/javax/security/auth/PrivateCredentialPermission.java >> --- >> a/src/share/classes/javax/security/auth/PrivateCredentialPermission.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/javax/security/auth/PrivateCredentialPermission.java >> Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -495,7 +495,7 @@ >> >> // perform new initialization from the permission name >> >> - if (getName().indexOf(" ") == -1 && getName().indexOf("\"") >> == -1) >> { >> + if (getName().indexOf(' ') == -1 && getName().indexOf('\"') >> == -1) >> { >> >> // name only has a credential class specified >> credentialClass = getName(); >> diff -r e323c74edabd src/share/classes/javax/security/sasl/Sasl.java >> --- a/src/share/classes/javax/security/sasl/Sasl.java Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/javax/security/sasl/Sasl.java Sat Apr 26 07:31:04 >> 2014 -0300 >> @@ -600,7 +600,7 @@ >> // implementation of an algorithm. We are only >> interested >> // in entries which lead to the implementation >> // classes. >> - if (currentKey.indexOf(" ") < 0) { >> + if (currentKey.indexOf(' ') < 0) { >> String className = >> providers[i].getProperty(currentKey); >> if (!classes.contains(className)) { >> classes.add(className); >> diff -r e323c74edabd src/share/classes/javax/swing/JEditorPane.java >> --- a/src/share/classes/javax/swing/JEditorPane.java Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/javax/swing/JEditorPane.java Sat Apr 26 07:31:04 >> 2014 -0300 >> @@ -964,7 +964,7 @@ >> // The type could have optional info is part of it, >> // for example some charset info. We need to strip that >> // of and save it. >> - int parm = type.indexOf(";"); >> + int parm = type.indexOf(';'); >> if (parm > -1) { >> // Save the paramList. >> String paramList = type.substring(parm); >> diff -r e323c74edabd >> src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java >> --- a/src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Sat >> Apr 26 >> 07:31:04 2014 -0300 >> @@ -653,7 +653,7 @@ >> >> // strip off the prefix, if there is one. >> String fullKey = key.toString(); >> - String partialKey = fullKey.substring(fullKey.indexOf(".") + 1); >> + String partialKey = fullKey.substring(fullKey.indexOf('.') + 1); >> >> Object obj = null; >> int xstate = getExtendedState(ctx, v); >> diff -r e323c74edabd src/share/classes/sun/applet/AppletClassLoader.java >> --- a/src/share/classes/sun/applet/AppletClassLoader.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/applet/AppletClassLoader.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -168,7 +168,7 @@ >> */ >> protected Class findClass(String name) throws >> ClassNotFoundException { >> >> - int index = name.indexOf(";"); >> + int index = name.indexOf(';'); >> String cookie = ""; >> if(index != -1) { >> cookie = name.substring(index, name.length()); >> @@ -608,7 +608,7 @@ >> >> // deal with URL rewriting >> String cookie = null; >> - int index = name.indexOf(";"); >> + int index = name.indexOf(';'); >> if(index != -1) { >> cookie = name.substring(index, name.length()); >> name = name.substring(0, index); >> diff -r e323c74edabd src/share/classes/sun/awt/FontConfiguration.java >> --- a/src/share/classes/sun/awt/FontConfiguration.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/awt/FontConfiguration.java Sat Apr 26 >> 07:31:04 >> 2014 -0300 >> @@ -272,9 +272,9 @@ >> if (configFile != null) { >> return configFile; >> } >> - int decimalPointIndex = osVersion.indexOf("."); >> + int decimalPointIndex = osVersion.indexOf('.'); >> if (decimalPointIndex != -1) { >> - osMajorVersion = osVersion.substring(0, >> osVersion.indexOf(".")); >> + osMajorVersion = osVersion.substring(0, >> osVersion.indexOf('.')); >> configFile = findImpl(baseName + "." + osName + "." + >> osMajorVersion); >> if (configFile != null) { >> return configFile; >> diff -r e323c74edabd src/share/classes/sun/font/Type1Font.java >> --- a/src/share/classes/sun/font/Type1Font.java Wed Apr 23 11:35:40 2014 >> -0700 >> +++ b/src/share/classes/sun/font/Type1Font.java Sat Apr 26 07:31:04 2014 >> -0300 >> @@ -492,7 +492,7 @@ >> >> //Conversion: Expand abbreviations in style portion (everything >> after '-'), >> // replace '-' with space and insert missing spaces >> - pos = name.indexOf("-"); >> + pos = name.indexOf('-'); >> if (pos >= 0) { >> res = expandName(name.substring(0, pos), false); >> res += " " + expandName(name.substring(pos+1), true); >> @@ -513,8 +513,8 @@ >> //Conversion: Truncate style portion (everything after '-') >> // and insert missing spaces >> >> - if (tmp.indexOf("-") > 0) { >> - tmp = tmp.substring(0, tmp.indexOf("-")); >> + if (tmp.indexOf('-') > 0) { >> + tmp = tmp.substring(0, tmp.indexOf('-')); >> } >> >> return expandName(tmp, false); >> diff -r e323c74edabd >> src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java >> --- a/src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java Sat >> Apr 26 >> 07:31:04 2014 -0300 >> @@ -84,7 +84,7 @@ >> * {@inheritDoc} >> */ >> public String getBaseName() { >> - int baseIndex = name.lastIndexOf(".")+1; >> + int baseIndex = name.lastIndexOf('.') + 1; >> return name.substring(baseIndex); >> } >> >> diff -r e323c74edabd >> src/share/classes/sun/jvmstat/monitor/HostIdentifier.java >> --- a/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Sat >> Apr 26 >> 07:31:04 2014 -0300 >> @@ -138,8 +138,8 @@ >> String frag = u.getFragment(); >> URI u2 = null; >> >> - int c1index = uriString.indexOf(":"); >> - int c2index = uriString.lastIndexOf(":"); >> + int c1index = uriString.indexOf(':'); >> + int c2index = uriString.lastIndexOf(':'); >> if (c2index != c1index) { >> /* >> * this is the scheme:hostname:port case. >> Attempt to >> diff -r e323c74edabd >> src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java >> >> --- >> a/src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java >> >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java >> >> Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -70,8 +70,8 @@ >> >> String addrStr; >> if (target.startsWith("[")) { >> - final int index = target.indexOf("]"); >> - final int index2 = target.lastIndexOf(":"); >> + final int index = target.indexOf(']'); >> + final int index2 = target.lastIndexOf(':'); >> if(index == -1) >> throw new IllegalArgumentException("Host starts with >> [ but >> " + >> "does not end >> with ]"); >> @@ -85,8 +85,8 @@ >> if (addrStr.startsWith("[")) >> throw new IllegalArgumentException("More than one >> [[...]]"); >> } else { >> - final int index = target.indexOf(":"); >> - final int index2 = target.lastIndexOf(":"); >> + final int index = target.indexOf(':'); >> + final int index2 = target.lastIndexOf(':'); >> if(index == -1) throw new >> IllegalArgumentException("Missing port separator >> \":\""); >> addrStr = target.substring(0, index); >> @@ -98,7 +98,7 @@ >> address = InetAddress.getByName(addrStr); >> >> //THE CHECK SHOULD BE STRONGER!!! >> - final int index = target.lastIndexOf(":"); >> + final int index = target.lastIndexOf(':'); >> >> community = target.substring(index + 1, target.length()); >> >> diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java >> --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sat Apr 26 07:31:04 >> 2014 -0300 >> @@ -273,8 +273,8 @@ >> else >> { >> // Look for index of "." in the string >> - int sIdx = source.indexOf("."); >> - int tIdx = target.indexOf("."); >> + int sIdx = source.indexOf('.'); >> + int tIdx = target.indexOf('.'); >> >> if (sIdx == -1) >> sIdx = source.length() - 1; >> @@ -304,10 +304,10 @@ >> String versionError = mf.format(args); >> >> // Look for "-" for pre-release >> - int prIndex = token.indexOf("-"); >> + int prIndex = token.indexOf('-'); >> >> // Look for "_" for patch release >> - int patchIndex = token.indexOf("_"); >> + int patchIndex = token.indexOf('_'); >> >> if (prIndex == -1 && patchIndex == -1) >> { >> diff -r e323c74edabd src/share/classes/sun/misc/JarIndex.java >> --- a/src/share/classes/sun/misc/JarIndex.java Wed Apr 23 11:35:40 2014 >> -0700 >> +++ b/src/share/classes/sun/misc/JarIndex.java Sat Apr 26 07:31:04 2014 >> -0300 >> @@ -172,7 +172,7 @@ >> if ((jarFiles = indexMap.get(fileName)) == null) { >> /* try the package name again */ >> int pos; >> - if((pos = fileName.lastIndexOf("/")) != -1) { >> + if((pos = fileName.lastIndexOf('/')) != -1) { >> jarFiles = indexMap.get(fileName.substring(0, pos)); >> } >> } >> @@ -195,7 +195,7 @@ >> public void add(String fileName, String jarName) { >> String packageName; >> int pos; >> - if((pos = fileName.lastIndexOf("/")) != -1) { >> + if((pos = fileName.lastIndexOf('/')) != -1) { >> packageName = fileName.substring(0, pos); >> } else { >> packageName = fileName; >> diff -r e323c74edabd src/share/classes/sun/misc/URLClassPath.java >> --- a/src/share/classes/sun/misc/URLClassPath.java Wed Apr 23 11:35:40 >> 2014 >> -0700 >> +++ b/src/share/classes/sun/misc/URLClassPath.java Sat Apr 26 07:31:04 >> 2014 >> -0300 >> @@ -793,7 +793,7 @@ >> boolean validIndex(final String name) { >> String packageName = name; >> int pos; >> - if((pos = name.lastIndexOf("/")) != -1) { >> + if((pos = name.lastIndexOf('/')) != -1) { >> packageName = name.substring(0, pos); >> } >> >> @@ -803,7 +803,7 @@ >> while (enum_.hasMoreElements()) { >> entry = enum_.nextElement(); >> entryName = entry.getName(); >> - if((pos = entryName.lastIndexOf("/")) != -1) >> + if((pos = entryName.lastIndexOf('/')) != -1) >> entryName = entryName.substring(0, pos); >> if (entryName.equals(packageName)) { >> return true; >> @@ -900,7 +900,7 @@ >> */ >> JarIndex newIndex = newLoader.getIndex(); >> if(newIndex != null) { >> - int pos = jarName.lastIndexOf("/"); >> + int pos = jarName.lastIndexOf('/'); >> newIndex.merge(this.index, (pos == -1 ? >> null : jarName.substring(0, pos >> + 1))); >> } >> diff -r e323c74edabd src/share/classes/sun/net/ftp/impl/FtpClient.java >> --- a/src/share/classes/sun/net/ftp/impl/FtpClient.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/net/ftp/impl/FtpClient.java Sat Apr 26 >> 07:31:04 >> 2014 -0300 >> @@ -259,7 +259,7 @@ >> d = null; >> } >> if (d != null && time != null) { >> - int c = time.indexOf(":"); >> + int c = time.indexOf(':'); >> now.setTime(d); >> now.set(Calendar.HOUR, >> Integer.parseInt(time.substring(0, c))); >> now.set(Calendar.MINUTE, >> Integer.parseInt(time.substring(c + 1))); >> @@ -295,7 +295,7 @@ >> >> public FtpDirEntry parseLine(String line) { >> String name = null; >> - int i = line.lastIndexOf(";"); >> + int i = line.lastIndexOf(';'); >> if (i > 0) { >> name = line.substring(i + 1).trim(); >> line = line.substring(0, i); >> @@ -306,7 +306,7 @@ >> FtpDirEntry file = new FtpDirEntry(name); >> while (!line.isEmpty()) { >> String s; >> - i = line.indexOf(";"); >> + i = line.indexOf(';'); >> if (i > 0) { >> s = line.substring(0, i); >> line = line.substring(i + 1); >> @@ -314,7 +314,7 @@ >> s = line; >> line = ""; >> } >> - i = s.indexOf("="); >> + i = s.indexOf('='); >> if (i > 0) { >> String fact = s.substring(0, i); >> String value = s.substring(i + 1); >> diff -r e323c74edabd >> src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java >> --- >> a/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -325,7 +325,7 @@ >> while (i.hasNext()) { >> String parentDomain = i.next(); >> int start = 0; >> - while ((start = parentDomain.indexOf(".")) != -1 >> + while ((start = parentDomain.indexOf('.')) != -1 >> && start < parentDomain.length() -1) { >> try { >> results = resolve(ctx, >> host+"."+parentDomain, ids, >> 0); >> diff -r e323c74edabd src/share/classes/sun/net/util/IPAddressUtil.java >> --- a/src/share/classes/sun/net/util/IPAddressUtil.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/net/util/IPAddressUtil.java Sat Apr 26 >> 07:31:04 >> 2014 -0300 >> @@ -149,7 +149,7 @@ >> byte[] dst = new byte[INADDR16SZ]; >> >> int srcb_length = srcb.length; >> - int pc = src.indexOf ("%"); >> + int pc = src.indexOf ('%'); >> if (pc == srcb_length -1) { >> return null; >> } >> diff -r e323c74edabd src/share/classes/sun/net/www/ParseUtil.java >> --- a/src/share/classes/sun/net/www/ParseUtil.java Wed Apr 23 11:35:40 >> 2014 >> -0700 >> +++ b/src/share/classes/sun/net/www/ParseUtil.java Sat Apr 26 07:31:04 >> 2014 >> -0300 >> @@ -356,8 +356,8 @@ >> * because we must not quote a literal IPv6 address >> */ >> if (opaquePart.startsWith("//[")) { >> - int end = opaquePart.indexOf("]"); >> - if (end != -1 && opaquePart.indexOf(":")!=-1) { >> + int end = opaquePart.indexOf(']'); >> + if (end != -1 && opaquePart.indexOf(':')!=-1) { >> String doquote, dontquote; >> if (end == opaquePart.length()) { >> dontquote = opaquePart; >> @@ -408,8 +408,8 @@ >> } else if (authority != null) { >> sb.append("//"); >> if (authority.startsWith("[")) { >> - int end = authority.indexOf("]"); >> - if (end != -1 && authority.indexOf(":")!=-1) { >> + int end = authority.indexOf(']'); >> + if (end != -1 && authority.indexOf(':')!=-1) { >> String doquote, dontquote; >> if (end == authority.length()) { >> dontquote = authority; >> diff -r e323c74edabd src/share/classes/sun/reflect/misc/ReflectUtil.java >> --- a/src/share/classes/sun/reflect/misc/ReflectUtil.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/reflect/misc/ReflectUtil.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -341,6 +341,6 @@ >> * (not to be confused with a Java Language anonymous inner class). >> */ >> public static boolean isVMAnonymousClass(Class cls) { >> - return cls.getName().indexOf("/") > -1; >> + return cls.getName().indexOf('/') > -1; >> } >> } >> diff -r e323c74edabd src/share/classes/sun/rmi/runtime/Log.java >> --- a/src/share/classes/sun/rmi/runtime/Log.java Wed Apr 23 11:35:40 2014 >> -0700 >> +++ b/src/share/classes/sun/rmi/runtime/Log.java Sat Apr 26 07:31:04 2014 >> -0300 >> @@ -434,7 +434,7 @@ >> * Mimic old log messages that only contain unqualified names. >> */ >> private static String unqualifiedName(String name) { >> - int lastDot = name.lastIndexOf("."); >> + int lastDot = name.lastIndexOf('.'); >> if (lastDot >= 0) { >> name = name.substring(lastDot + 1); >> } >> diff -r e323c74edabd >> src/share/classes/sun/rmi/transport/proxy/CGIHandler.java >> --- a/src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Sat >> Apr 26 >> 07:31:04 2014 -0300 >> @@ -141,7 +141,7 @@ >> { >> try { >> String command, param; >> - int delim = QueryString.indexOf("="); >> + int delim = QueryString.indexOf('='); >> if (delim == -1) { >> command = QueryString; >> param = ""; >> diff -r e323c74edabd >> src/share/classes/sun/security/jgss/wrapper/Krb5Util.java >> --- a/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Sat >> Apr 26 >> 07:31:04 2014 -0300 >> @@ -39,7 +39,7 @@ >> static String getTGSName(GSSNameElement name) >> throws GSSException { >> String krbPrinc = name.getKrbName(); >> - int atIndex = krbPrinc.indexOf("@"); >> + int atIndex = krbPrinc.indexOf('@'); >> String realm = krbPrinc.substring(atIndex + 1); >> StringBuffer buf = new StringBuffer("krbtgt/"); >> buf.append(realm).append('@').append(realm); >> diff -r e323c74edabd >> src/share/classes/sun/security/provider/PolicyFile.java >> --- a/src/share/classes/sun/security/provider/PolicyFile.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/security/provider/PolicyFile.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -1856,7 +1856,7 @@ >> int colonIndex; >> String prefix = value; >> String suffix; >> - if ((colonIndex = value.indexOf(":")) != -1) { >> + if ((colonIndex = value.indexOf(':')) != -1) { >> prefix = value.substring(0, colonIndex); >> } >> >> diff -r e323c74edabd >> src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java >> --- a/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java >> Wed Apr >> 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java >> Sat Apr >> 26 07:31:04 2014 -0300 >> @@ -338,7 +338,7 @@ >> } >> String sigType; >> if (keyType.contains("_")) { >> - int k = keyType.indexOf("_"); >> + int k = keyType.indexOf('_'); >> sigType = keyType.substring(k + 1); >> keyType = keyType.substring(0, k); >> } else { >> diff -r e323c74edabd >> src/share/classes/sun/security/ssl/X509KeyManagerImpl.java >> --- a/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java Sat >> Apr 26 >> 07:31:04 2014 -0300 >> @@ -302,7 +302,7 @@ >> final String sigKeyAlgorithm; >> >> KeyType(String algorithm) { >> - int k = algorithm.indexOf("_"); >> + int k = algorithm.indexOf('_'); >> if (k == -1) { >> keyAlgorithm = algorithm; >> sigKeyAlgorithm = null; >> diff -r e323c74edabd >> src/share/classes/sun/security/util/HostnameChecker.java >> --- a/src/share/classes/sun/security/util/HostnameChecker.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/security/util/HostnameChecker.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -300,8 +300,8 @@ >> template = template.toLowerCase(Locale.ENGLISH); >> >> // Retreive leftmost component >> - int templateIdx = template.indexOf("."); >> - int nameIdx = name.indexOf("."); >> + int templateIdx = template.indexOf('.'); >> + int nameIdx = name.indexOf('.'); >> >> if (templateIdx == -1) >> templateIdx = template.length(); >> @@ -326,7 +326,7 @@ >> */ >> private static boolean matchWildCards(String name, String >> template) { >> >> - int wildcardIdx = template.indexOf("*"); >> + int wildcardIdx = template.indexOf('*'); >> if (wildcardIdx == -1) >> return name.equals(template); >> >> @@ -349,7 +349,7 @@ >> >> // update the match scope >> name = name.substring(beforeStartIdx + >> beforeWildcard.length()); >> - wildcardIdx = afterWildcard.indexOf("*"); >> + wildcardIdx = afterWildcard.indexOf('*'); >> } >> return name.endsWith(afterWildcard); >> } >> diff -r e323c74edabd >> src/share/classes/sun/security/util/SignatureFileVerifier.java >> --- a/src/share/classes/sun/security/util/SignatureFileVerifier.java Wed >> Apr 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/security/util/SignatureFileVerifier.java Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -98,7 +98,7 @@ >> } finally { >> Providers.stopJarVerification(obj); >> } >> - this.name = name.substring(0, name.lastIndexOf(".")) >> + this.name = name.substring(0, name.lastIndexOf('.')) >> >> .toUpperCase(Locale.ENGLISH); >> this.md = md; >> this.signerCache = signerCache; >> diff -r e323c74edabd >> src/share/classes/sun/security/x509/CRLExtensions.java >> --- a/src/share/classes/sun/security/x509/CRLExtensions.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/security/x509/CRLExtensions.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -185,7 +185,7 @@ >> String name; >> String id = attr.getPrefix(); >> if (id.equalsIgnoreCase(X509CertImpl.NAME)) { // fully >> qualified >> - int index = alias.lastIndexOf("."); >> + int index = alias.lastIndexOf('.'); >> name = alias.substring(index + 1); >> } else >> name = alias; >> diff -r e323c74edabd >> src/share/classes/sun/tools/jconsole/ConnectDialog.java >> --- a/src/share/classes/sun/tools/jconsole/ConnectDialog.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/tools/jconsole/ConnectDialog.java Sat Apr 26 >> 07:31:04 2014 -0300 >> @@ -325,7 +325,7 @@ >> } else { >> String host = remoteTF.getText().trim(); >> String port = "0"; >> - int index = host.lastIndexOf(":"); >> + int index = host.lastIndexOf(':'); >> if (index >= 0) { >> port = host.substring(index + 1); >> host = host.substring(0, index); >> diff -r e323c74edabd >> src/share/classes/sun/tools/jconsole/inspector/Utils.java >> --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat >> Apr 26 >> 07:31:04 2014 -0300 >> @@ -210,7 +210,7 @@ >> public static String getArrayClassName(String name) { >> String className = null; >> if (name.startsWith("[")) { >> - int index = name.lastIndexOf("["); >> + int index = name.lastIndexOf('['); >> className = name.substring(index, name.length()); >> if (className.startsWith("[L")) { >> className = className.substring(2, >> className.length() - 1); >> @@ -241,7 +241,7 @@ >> if (className == null) { >> return name; >> } >> - int index = name.lastIndexOf("["); >> + int index = name.lastIndexOf('['); >> StringBuilder brackets = new StringBuilder(className); >> for (int i = 0; i <= index; i++) { >> brackets.append("[]"); >> diff -r e323c74edabd >> src/share/classes/sun/tools/jconsole/inspector/XOperations.java >> --- a/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Wed >> Apr 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Sat >> Apr 26 07:31:04 2014 -0300 >> @@ -112,7 +112,7 @@ >> if (methodLabel.getText().length() > 20) { >> methodLabel.setText(methodLabel.getText(). >> substring(methodLabel.getText(). >> - lastIndexOf(".") + 1, >> + lastIndexOf('.') + 1, >> methodLabel.getText().length())); >> } >> >> diff -r e323c74edabd >> src/share/classes/sun/tools/jconsole/inspector/XTree.java >> --- a/src/share/classes/sun/tools/jconsole/inspector/XTree.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/tools/jconsole/inspector/XTree.java Sat >> Apr 26 >> 07:31:04 2014 -0300 >> @@ -475,7 +475,7 @@ >> private static Map extractKeyValuePairs( >> String props, ObjectName mbean) { >> Map map = new LinkedHashMap(); >> - int eq = props.indexOf("="); >> + int eq = props.indexOf('='); >> while (eq != -1) { >> String key = props.substring(0, eq); >> String value = mbean.getKeyProperty(key); >> @@ -484,7 +484,7 @@ >> if (props.startsWith(",")) { >> props = props.substring(1); >> } >> - eq = props.indexOf("="); >> + eq = props.indexOf('='); >> } >> return map; >> } >> @@ -821,7 +821,7 @@ >> } >> >> private void buildKeyValue() { >> - int index = tokenValue.indexOf("="); >> + int index = tokenValue.indexOf('='); >> if (index < 0) { >> key = tokenValue; >> value = tokenValue; >> > From claes.redestad at oracle.com Sun Apr 27 12:22:19 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 27 Apr 2014 14:22:19 +0200 Subject: inefficient indexof when String has one length In-Reply-To: <535CF26A.8090507@oracle.com> References: <535BE93A.90604@oracle.com> <535CF26A.8090507@oracle.com> Message-ID: <535CF67B.9050006@oracle.com> Possibly a few bytes in static class footprint, sure. Maybe this is something javac should optimize (javap on some trivial examples suggests this doesn't happen) rather than trying to root out all suboptimal cases, especially since there are bound to be a lot more code out there using similar patterns? /Claes On 2014-04-27 14:04, David Holmes wrote: > There is also a slight reduction in memory pressure due to not > creating a bunch of one character string literals. > > David > > On 27/04/2014 3:13 AM, Claes Redestad wrote: >> Hi Ot?vio, >> >> while I personally like using chars instead of Strings where >> applicable, I would assume these constant replacements are all cases >> where the JIT will be quick to inline and eliminate the overhead. So the >> benefit, if any, would be in interpreted code. Testing these assumptions >> with a simple but representative JMH[1] microbenchmark[2]: >> >> Benchmark Mode Samples Mean Mean >> error Units >> o.s.MyBenchmark.indexOfChar thrpt 20 32290.764 359.347 >> ops/ms >> o.s.MyBenchmark.indexOfString thrpt 20 32353.865 398.929 >> ops/ms >> o.s.MyBenchmark.lastIndexOfChar thrpt 20 32444.428 462.630 >> ops/ms >> o.s.MyBenchmark.lastIndexOfString thrpt 20 32001.738 388.791 >> ops/ms >> >> So no real difference, as suspected. Running with -Xint: >> >> Benchmark Mode Samples Mean Mean >> error Units >> o.s.MyBenchmark.indexOfChar thrpt 20 3170.130 108.933 >> ops/ms >> o.s.MyBenchmark.indexOfString thrpt 20 3119.518 44.703 >> ops/ms >> o.s.MyBenchmark.lastIndexOfChar thrpt 20 3281.374 25.589 >> ops/ms >> o.s.MyBenchmark.lastIndexOfString thrpt 20 3154.710 45.224 >> ops/ms >> >> Not much - if anything - here either. I think more evidence that this >> would have some actual benefit is warranted. >> >> /Claes >> >> [1] http://openjdk.java.net/projects/code-tools/jmh/ >> [2] package org.sample; >> >> import org.openjdk.jmh.annotations.*; >> >> import java.util.Random; >> >> @State(Scope.Thread) >> public class MyBenchmark { >> >> /* >> * Generate a lot of randomly generated strings of various sizes >> */ >> static int NUM = 100000; >> static int MAX_SIZE = 1000; >> static String[] STRINGS = new String[NUM]; >> >> static { >> Random r = new Random(); >> for (int i = 0; i < NUM; i++) { >> StringBuilder sb = new StringBuilder(r.nextInt(MAX_SIZE) >> + 1); >> for (int j = 0; j < sb.capacity(); j++) { >> sb.append((char)(r.nextInt(70) + '0')); >> } >> STRINGS[i] = sb.toString(); >> } >> } >> >> private int i = 0; >> >> @GenerateMicroBenchmark >> public int indexOfString() { >> if (i >= NUM) { i = 0; } >> return STRINGS[i++].indexOf("6"); >> } >> >> @GenerateMicroBenchmark >> public int lastIndexOfString() { >> if (i >= NUM) { i = 0; } >> return STRINGS[i++].indexOf("6"); >> } >> >> @GenerateMicroBenchmark >> public int indexOfChar() { >> if (i >= NUM) { i = 0; } >> return STRINGS[i++].indexOf('6'); >> } >> >> @GenerateMicroBenchmark >> public int lastIndexOfChar() { >> if (i >= NUM) { i = 0; } >> return STRINGS[i++].indexOf('6'); >> } >> } >> >> On 2014-04-26 12:56, Ot?vio Gon?alves de Santana wrote: >>> When a String has length just one, could be replaced by equivalent >>> character literals, gaining some performance enhancement. >>> >>> I found 107 changes. >>> >>> >>> diff -r e323c74edabd >>> src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java >>> --- a/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java >>> Wed Apr >>> 23 11:35:40 2014 -0700 >>> +++ b/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java >>> Sat Apr >>> 26 07:31:04 2014 -0300 >>> @@ -547,7 +547,7 @@ >>> i = >>> strLowerCase.indexOf("", i); >>> if (i > 0) { >>> i += "".length(); >>> - int i2 = str.indexOf("<", i); >>> + int i2 = str.indexOf('<', i); >>> return str.substring(i, i2); >>> } >>> } >>> diff -r e323c74edabd >>> src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java >>> --- a/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ b/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java >>> Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -512,7 +512,7 @@ >>> } >>> static String qualifiedStringValue(String s1, String s234) { >>> // Qualification by dot must decompose uniquely. Second >>> string >>> might already be qualified. >>> - assert(s1.indexOf(".") < 0); >>> + assert(s1.indexOf('.') < 0); >>> return s1+"."+s234; >>> } >>> >>> diff -r e323c74edabd >>> src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java >>> --- a/src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -102,7 +102,7 @@ >>> } >>> location = url.substring(addrStart, addrEnd); >>> >>> - int keyStart = location.indexOf("/"); >>> + int keyStart = location.indexOf('/'); >>> if (keyStart >= 0) { >>> // Has key string >>> if (keyStart == (location.length() -1)) { >>> diff -r e323c74edabd >>> src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java >>> --- a/src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ b/src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java >>> Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -336,7 +336,7 @@ >>> String url = "rmi://"; >>> >>> // Enclose IPv6 literal address in '[' and ']' >>> - url = (host.indexOf(":") > -1) ? url + "[" + host + "]" : >>> + url = (host.indexOf(':') > -1) ? url + "[" + host + "]" : >>> url + host; >>> if (port > 0) { >>> url += ":" + Integer.toString(port); >>> diff -r e323c74edabd >>> src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java >>> --- >>> a/src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -149,7 +149,7 @@ >>> * foo:rest/of/name foo: >>> */ >>> protected String getURLPrefix(String url) throws >>> NamingException { >>> - int start = url.indexOf(":"); >>> + int start = url.indexOf(':'); >>> >>> if (start < 0) { >>> throw new OperationNotSupportedException("Invalid URL: >>> " + >>> url); >>> @@ -160,7 +160,7 @@ >>> start += 2; // skip double slash >>> >>> // find last slash >>> - int posn = url.indexOf("/", start); >>> + int posn = url.indexOf('/', start); >>> if (posn >= 0) { >>> start = posn; >>> } else { >>> diff -r e323c74edabd >>> src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java >>> --- a/src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java Wed >>> Apr >>> 23 11:35:40 2014 -0700 >>> +++ b/src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java Sat >>> Apr >>> 26 07:31:04 2014 -0300 >>> @@ -303,7 +303,7 @@ >>> >>> offset = pname.length() - 1; >>> >>> - while ((last = pname.lastIndexOf(".", offset)) != -1) { >>> + while ((last = pname.lastIndexOf('.', offset)) != -1) { >>> >>> pname = pname.substring(0, last+1) + "*"; >>> x = permissions.get(pname); >>> @@ -318,7 +318,7 @@ >>> pname = p.getName(); >>> offset = pname.length() - 1; >>> >>> - while ((last = pname.lastIndexOf("=", offset)) != -1) { >>> + while ((last = pname.lastIndexOf('=', offset)) != -1) { >>> >>> pname = pname.substring(0, last+1) + "*"; >>> x = permissions.get(pname); >>> diff -r e323c74edabd >>> src/share/classes/com/sun/rowset/CachedRowSetImpl.java >>> --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Sat Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -6831,7 +6831,7 @@ >>> // table name else isolate table name. >>> >>> indexFrom = command.toLowerCase().indexOf("from"); >>> - indexComma = command.indexOf(",", indexFrom); >>> + indexComma = command.indexOf(',', indexFrom); >>> >>> if(indexComma == -1) { >>> // implies only one table >>> diff -r e323c74edabd >>> src/share/classes/com/sun/rowset/JoinRowSetImpl.java >>> --- a/src/share/classes/com/sun/rowset/JoinRowSetImpl.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/com/sun/rowset/JoinRowSetImpl.java Sat Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -910,7 +910,7 @@ >>> >>> // now remove the last "," >>> strWhereClause = strWhereClause.substring >>> - (0, strWhereClause.lastIndexOf(",")); >>> + (0, strWhereClause.lastIndexOf(',')); >>> >>> // Add from clause >>> strWhereClause = strWhereClause.concat(" from "); >>> @@ -920,7 +920,7 @@ >>> >>> //Remove the last "," >>> strWhereClause = strWhereClause.substring >>> - (0, strWhereClause.lastIndexOf(",")); >>> + (0, strWhereClause.lastIndexOf(',')); >>> >>> // Add the where clause >>> strWhereClause = strWhereClause.concat(" where "); >>> diff -r e323c74edabd >>> src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java >>> --- >>> a/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -240,7 +240,7 @@ >>> // Remove the string after "@xxxx" >>> // before writing it to the xml file. >>> String strProviderInstance = >>> (caller.getSyncProvider()).toString(); >>> - String strProvider = strProviderInstance.substring(0, >>> (caller.getSyncProvider()).toString().indexOf("@")); >>> + String strProvider = strProviderInstance.substring(0, >>> (caller.getSyncProvider()).toString().indexOf('@')); >>> >>> propString("sync-provider-name", strProvider); >>> propString("sync-provider-vendor", "Oracle Corporation"); >>> diff -r e323c74edabd >>> src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java >>> --- >>> a/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java >>> >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java >>> >>> Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -1147,7 +1147,7 @@ >>> if (nullValue) { >>> rs.setSyncProvider(null); >>> } else { >>> - String str = s.substring(0,s.indexOf("@")+1); >>> + String str = s.substring(0,s.indexOf('@')+1); >>> rs.setSyncProvider(str); >>> } >>> break; >>> diff -r e323c74edabd >>> src/share/classes/com/sun/rowset/internal/XmlResolver.java >>> --- a/src/share/classes/com/sun/rowset/internal/XmlResolver.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/com/sun/rowset/internal/XmlResolver.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> public class XmlResolver implements EntityResolver { >>> >>> public InputSource resolveEntity(String publicId, String >>> systemId) >>> { >>> - String schemaName = >>> systemId.substring(systemId.lastIndexOf("/")); >>> + String schemaName = >>> systemId.substring(systemId.lastIndexOf('/')); >>> >>> if(systemId.startsWith("http://java.sun.com/xml/ns/jdbc")) { >>> return new >>> InputSource(this.getClass().getResourceAsStream(schemaName)); >>> diff -r e323c74edabd >>> src/share/classes/com/sun/security/auth/module/JndiLoginModule.java >>> --- >>> a/src/share/classes/com/sun/security/auth/module/JndiLoginModule.java Wed >>> >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/com/sun/security/auth/module/JndiLoginModule.java Sat >>> >>> Apr 26 07:31:04 2014 -0300 >>> @@ -694,7 +694,7 @@ >>> throw new LoginException("Error: no CallbackHandler >>> available >>> " + >>> "to garner authentication information from the >>> user"); >>> >>> - String protocol = userProvider.substring(0, >>> userProvider.indexOf(":")); >>> + String protocol = userProvider.substring(0, >>> userProvider.indexOf(':')); >>> >>> Callback[] callbacks = new Callback[2]; >>> callbacks[0] = new NameCallback(protocol + " " >>> diff -r e323c74edabd >>> src/share/classes/com/sun/security/auth/module/LdapLoginModule.java >>> --- >>> a/src/share/classes/com/sun/security/auth/module/LdapLoginModule.java Wed >>> >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/com/sun/security/auth/module/LdapLoginModule.java Sat >>> >>> Apr 26 07:31:04 2014 -0300 >>> @@ -400,7 +400,7 @@ >>> >>> // Add any JNDI properties to the environment >>> for (String key : options.keySet()) { >>> - if (key.indexOf(".") > -1) { >>> + if (key.indexOf('.') > -1) { >>> ldapEnvironment.put(key, options.get(key)); >>> } >>> } >>> diff -r e323c74edabd >>> src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java >>> >>> --- >>> a/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java >>> >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java >>> >>> Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -857,7 +857,7 @@ >>> bpSpec = runtime.createClassLineBreakpoint(classId, >>> lineNumber); >>> } else { >>> // Try stripping method from class.method token. >>> - int idot = token.lastIndexOf("."); >>> + int idot = token.lastIndexOf('.'); >>> if ( (idot <= 0) || /* No dot or dot in first >>> char >>> */ >>> (idot >= token.length() - 1) ) { /* dot in last >>> char >>> */ >>> return null; >>> diff -r e323c74edabd >>> src/share/classes/com/sun/tools/example/debug/tty/Commands.java >>> --- >>> a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -1079,7 +1079,7 @@ >>> } >>> } else { >>> // Try stripping method from class.method token. >>> - int idot = token.lastIndexOf("."); >>> + int idot = token.lastIndexOf('.'); >>> if ( (idot <= 0) || /* No dot or >>> dot >>> in first char */ >>> (idot >= token.length() - 1) ) { /* dot in last >>> char >>> */ >>> printBreakpointCommandUsage(atForm, inForm); >>> diff -r e323c74edabd >>> src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java >>> >>> --- >>> a/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java >>> >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java >>> >>> Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -67,7 +67,7 @@ >>> continue; >>> } >>> String name = clazz.getName(); >>> - int pos = name.lastIndexOf("."); >>> + int pos = name.lastIndexOf('.'); >>> String pkg; >>> if (name.startsWith("[")) { // Only in ancient >>> heap >>> dumps >>> pkg = ""; >>> diff -r e323c74edabd src/share/classes/java/lang/Class.java >>> --- a/src/share/classes/java/lang/Class.java Wed Apr 23 11:35:40 2014 >>> -0700 >>> +++ b/src/share/classes/java/lang/Class.java Sat Apr 26 07:31:04 2014 >>> -0300 >>> @@ -1296,7 +1296,7 @@ >>> String simpleName = getSimpleBinaryName(); >>> if (simpleName == null) { // top level class >>> simpleName = getName(); >>> - return >>> simpleName.substring(simpleName.lastIndexOf(".")+1); // >>> strip the package name >>> + return >>> simpleName.substring(simpleName.lastIndexOf('.')+1); // >>> strip the package name >>> } >>> // According to JLS3 "Binary Compatibility" (13.1) the binary >>> // name of non-package classes (not top level) is the binary >>> diff -r e323c74edabd src/share/classes/java/lang/ClassLoader.java >>> --- a/src/share/classes/java/lang/ClassLoader.java Wed Apr 23 11:35:40 >>> 2014 >>> -0700 >>> +++ b/src/share/classes/java/lang/ClassLoader.java Sat Apr 26 07:31:04 >>> 2014 >>> -0300 >>> @@ -2136,7 +2136,7 @@ >>> return result.booleanValue(); >>> >>> // Check for most specific package entry >>> - int dotIndex = className.lastIndexOf("."); >>> + int dotIndex = className.lastIndexOf('.'); >>> if (dotIndex < 0) { // default package >>> result = packageAssertionStatus.get(null); >>> if (result != null) >>> @@ -2147,7 +2147,7 @@ >>> result = packageAssertionStatus.get(className); >>> if (result != null) >>> return result.booleanValue(); >>> - dotIndex = className.lastIndexOf(".", dotIndex-1); >>> + dotIndex = className.lastIndexOf('.', dotIndex-1); >>> } >>> >>> // Return the classloader default >>> diff -r e323c74edabd >>> src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>> --- a/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ b/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>> Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -84,7 +84,7 @@ >>> private InvokerBytecodeGenerator(LambdaForm lambdaForm, int >>> localsMapSize, >>> String className, String >>> invokerName, >>> MethodType invokerType) { >>> if (invokerName.contains(".")) { >>> - int p = invokerName.indexOf("."); >>> + int p = invokerName.indexOf('.'); >>> className = invokerName.substring(0, p); >>> invokerName = invokerName.substring(p+1); >>> } >>> diff -r e323c74edabd src/share/classes/java/net/CookieManager.java >>> --- a/src/share/classes/java/net/CookieManager.java Wed Apr 23 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/java/net/CookieManager.java Sat Apr 26 07:31:04 >>> 2014 -0300 >>> @@ -294,7 +294,7 @@ >>> // the path is the directory of the >>> page/doc >>> String path = uri.getPath(); >>> if (!path.endsWith("/")) { >>> - int i = path.lastIndexOf("/"); >>> + int i = path.lastIndexOf('/'); >>> if (i > 0) { >>> path = path.substring(0, i + 1); >>> } else { >>> @@ -364,7 +364,7 @@ >>> >>> >>> static private boolean isInPortList(String lst, int port) { >>> - int i = lst.indexOf(","); >>> + int i = lst.indexOf(','); >>> int val = -1; >>> while (i > 0) { >>> try { >>> @@ -375,7 +375,7 @@ >>> } catch (NumberFormatException numberFormatException) { >>> } >>> lst = lst.substring(i+1); >>> - i = lst.indexOf(","); >>> + i = lst.indexOf(','); >>> } >>> if (!lst.isEmpty()) { >>> try { >>> diff -r e323c74edabd src/share/classes/java/net/InetAddress.java >>> --- a/src/share/classes/java/net/InetAddress.java Wed Apr 23 11:35:40 >>> 2014 >>> -0700 >>> +++ b/src/share/classes/java/net/InetAddress.java Sat Apr 26 07:31:04 >>> 2014 >>> -0300 >>> @@ -1138,7 +1138,7 @@ >>> // This is supposed to be an IPv6 literal >>> // Check if a numeric or string zone id is present >>> int pos; >>> - if ((pos=host.indexOf ("%")) != -1) { >>> + if ((pos=host.indexOf ('%')) != -1) { >>> numericZone = checkNumericZone (host); >>> if (numericZone == -1) { /* remainder of string >>> must >>> be an ifname */ >>> ifname = host.substring (pos+1); >>> diff -r e323c74edabd src/share/classes/java/net/SocketPermission.java >>> --- a/src/share/classes/java/net/SocketPermission.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/java/net/SocketPermission.java Sat Apr 26 >>> 07:31:04 >>> 2014 -0300 >>> @@ -777,7 +777,7 @@ >>> // Literal IPv6 address >>> host = getName().substring(1, >>> getName().indexOf(']')); >>> } else { >>> - int i = getName().indexOf(":"); >>> + int i = getName().indexOf(':'); >>> if (i == -1) >>> host = getName(); >>> else { >>> diff -r e323c74edabd src/share/classes/java/net/SocksSocketImpl.java >>> --- a/src/share/classes/java/net/SocksSocketImpl.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/java/net/SocksSocketImpl.java Sat Apr 26 >>> 07:31:04 >>> 2014 -0300 >>> @@ -368,7 +368,7 @@ >>> String host = epoint.getHostString(); >>> // IPv6 litteral? >>> if (epoint.getAddress() instanceof Inet6Address && >>> - (!host.startsWith("[")) && (host.indexOf(":") >= 0)) { >>> + (!host.startsWith("[")) && (host.indexOf(':') >= 0)) { >>> host = "[" + host + "]"; >>> } >>> try { >>> @@ -684,7 +684,7 @@ >>> String host = saddr.getHostString(); >>> // IPv6 litteral? >>> if (saddr.getAddress() instanceof Inet6Address && >>> - (!host.startsWith("[")) && (host.indexOf(":") >= 0)) { >>> + (!host.startsWith("[")) && (host.indexOf(':') >= 0)) { >>> host = "[" + host + "]"; >>> } >>> try { >>> diff -r e323c74edabd src/share/classes/java/net/URI.java >>> --- a/src/share/classes/java/net/URI.java Wed Apr 23 11:35:40 2014 >>> -0700 >>> +++ b/src/share/classes/java/net/URI.java Sat Apr 26 07:31:04 2014 >>> -0300 >>> @@ -1851,9 +1851,9 @@ >>> sb.append("//"); >>> if (authority.startsWith("[")) { >>> // authority should (but may not) contain an >>> embedded IPv6 >>> address >>> - int end = authority.indexOf("]"); >>> + int end = authority.indexOf(']'); >>> String doquote = authority, dontquote = ""; >>> - if (end != -1 && authority.indexOf(":") != -1) { >>> + if (end != -1 && authority.indexOf(':') != -1) { >>> // the authority contains an IPv6 address >>> if (end == authority.length()) { >>> dontquote = authority; >>> @@ -1889,8 +1889,8 @@ >>> * because we must not quote a literal IPv6 address >>> */ >>> if (opaquePart.startsWith("//[")) { >>> - int end = opaquePart.indexOf("]"); >>> - if (end != -1 && opaquePart.indexOf(":")!=-1) { >>> + int end = opaquePart.indexOf(']'); >>> + if (end != -1 && opaquePart.indexOf(':')!=-1) { >>> String doquote, dontquote; >>> if (end == opaquePart.length()) { >>> dontquote = opaquePart; >>> diff -r e323c74edabd >>> src/share/classes/java/security/BasicPermission.java >>> --- a/src/share/classes/java/security/BasicPermission.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/java/security/BasicPermission.java Sat Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -430,7 +430,7 @@ >>> >>> offset = path.length()-1; >>> >>> - while ((last = path.lastIndexOf(".", offset)) != -1) { >>> + while ((last = path.lastIndexOf('.', offset)) != -1) { >>> >>> path = path.substring(0, last+1) + "*"; >>> //System.out.println("check "+path); >>> diff -r e323c74edabd src/share/classes/java/security/Provider.java >>> --- a/src/share/classes/java/security/Provider.java Wed Apr 23 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/java/security/Provider.java Sat Apr 26 07:31:04 >>> 2014 -0300 >>> @@ -927,7 +927,7 @@ >>> } >>> >>> private String[] getTypeAndAlgorithm(String key) { >>> - int i = key.indexOf("."); >>> + int i = key.indexOf('.'); >>> if (i < 1) { >>> if (debug != null) { >>> debug.println("Ignoring invalid entry in provider " >>> diff -r e323c74edabd src/share/classes/java/security/Security.java >>> --- a/src/share/classes/java/security/Security.java Wed Apr 23 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/java/security/Security.java Sat Apr 26 07:31:04 >>> 2014 -0300 >>> @@ -1114,7 +1114,7 @@ >>> // implementation of an algorithm. We are only >>> interested >>> // in entries which lead to the implementation >>> // classes. >>> - if (currentKey.indexOf(" ") < 0) { >>> + if (currentKey.indexOf(' ') < 0) { >>> result.add(currentKey.substring( >>> serviceName.length() >>> + 1)); >>> } >>> diff -r e323c74edabd >>> src/share/classes/java/util/PropertyPermission.java >>> --- a/src/share/classes/java/util/PropertyPermission.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/java/util/PropertyPermission.java Sat Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -547,7 +547,7 @@ >>> >>> offset = name.length()-1; >>> >>> - while ((last = name.lastIndexOf(".", offset)) != -1) { >>> + while ((last = name.lastIndexOf('.', offset)) != -1) { >>> >>> name = name.substring(0, last+1) + "*"; >>> //System.out.println("check "+name); >>> diff -r e323c74edabd src/share/classes/java/util/jar/JarVerifier.java >>> --- a/src/share/classes/java/util/jar/JarVerifier.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/java/util/jar/JarVerifier.java Sat Apr 26 >>> 07:31:04 >>> 2014 -0300 >>> @@ -278,7 +278,7 @@ >>> >>> // now we are parsing a signature block file >>> >>> - String key = uname.substring(0, >>> uname.lastIndexOf(".")); >>> + String key = uname.substring(0, >>> uname.lastIndexOf('.')); >>> >>> if (signerCache == null) >>> signerCache = new ArrayList<>(); >>> diff -r e323c74edabd >>> src/share/classes/java/util/logging/LogManager.java >>> --- a/src/share/classes/java/util/logging/LogManager.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/java/util/logging/LogManager.java Sat Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -866,7 +866,7 @@ >>> >>> int ix = 1; >>> for (;;) { >>> - int ix2 = name.indexOf(".", ix); >>> + int ix2 = name.indexOf('.', ix); >>> if (ix2 < 0) { >>> break; >>> } >>> @@ -889,7 +889,7 @@ >>> } >>> LogNode node = root; >>> while (name.length() > 0) { >>> - int ix = name.indexOf("."); >>> + int ix = name.indexOf('.'); >>> String head; >>> if (ix > 0) { >>> head = name.substring(0, ix); >>> diff -r e323c74edabd >>> src/share/classes/java/util/logging/XMLFormatter.java >>> --- a/src/share/classes/java/util/logging/XMLFormatter.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/java/util/logging/XMLFormatter.java Sat Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -174,7 +174,7 @@ >>> // Check to see if the parameter was not a messagetext >>> format >>> // or was not null or empty >>> if ( parameters != null && parameters.length != 0 >>> - && record.getMessage().indexOf("{") == -1 ) { >>> + && record.getMessage().indexOf('{') == -1 ) { >>> for (int i = 0; i < parameters.length; i++) { >>> sb.append(" "); >>> try { >>> diff -r e323c74edabd >>> src/share/classes/javax/management/MBeanPermission.java >>> --- a/src/share/classes/javax/management/MBeanPermission.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/javax/management/MBeanPermission.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -290,7 +290,7 @@ >>> >>> // Parse ObjectName >>> >>> - int openingBracket = name.indexOf("["); >>> + int openingBracket = name.indexOf('['); >>> if (openingBracket == -1) { >>> // If "[on]" missing then ObjectName("*:*") >>> // >>> @@ -329,7 +329,7 @@ >>> >>> // Parse member >>> >>> - int poundSign = name.indexOf("#"); >>> + int poundSign = name.indexOf('#'); >>> >>> if (poundSign == -1) >>> setMember("*"); >>> diff -r e323c74edabd >>> src/share/classes/javax/management/modelmbean/DescriptorSupport.java >>> --- >>> a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java >>> Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -329,7 +329,7 @@ >>> inFld = false; >>> } else if (inFld && inDesc) { >>> // want kw=value, eg, name="myname" value="myvalue" >>> - int eq_separator = tok.indexOf("="); >>> + int eq_separator = tok.indexOf('='); >>> if (eq_separator > 0) { >>> String kwPart = tok.substring(0,eq_separator); >>> String valPart = tok.substring(eq_separator+1); >>> @@ -458,7 +458,7 @@ >>> if ((fields[i] == null) || (fields[i].equals(""))) { >>> continue; >>> } >>> - int eq_separator = fields[i].indexOf("="); >>> + int eq_separator = fields[i].indexOf('='); >>> if (eq_separator < 0) { >>> // illegal if no = or is first character >>> if (MODELMBEAN_LOGGER.isLoggable(Level.FINEST)) { >>> diff -r e323c74edabd >>> src/share/classes/javax/management/modelmbean/RequiredModelMBean.java >>> --- >>> a/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java >>> Wed >>> >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/javax/management/modelmbean/RequiredModelMBean.java >>> Sat >>> >>> Apr 26 07:31:04 2014 -0300 >>> @@ -934,7 +934,7 @@ >>> String opMethodName; >>> >>> // Parse for class name and method >>> - int opSplitter = opName.lastIndexOf("."); >>> + int opSplitter = opName.lastIndexOf('.'); >>> if (opSplitter > 0) { >>> opClassName = opName.substring(0,opSplitter); >>> opMethodName = opName.substring(opSplitter+1); >>> @@ -943,7 +943,7 @@ >>> >>> /* Ignore anything after a left paren. We keep this for >>> compatibility but it isn't specified. */ >>> - opSplitter = opMethodName.indexOf("("); >>> + opSplitter = opMethodName.indexOf('('); >>> if (opSplitter > 0) >>> opMethodName = opMethodName.substring(0,opSplitter); >>> >>> diff -r e323c74edabd >>> src/share/classes/javax/security/auth/PrivateCredentialPermission.java >>> --- >>> a/src/share/classes/javax/security/auth/PrivateCredentialPermission.java >>> >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/javax/security/auth/PrivateCredentialPermission.java >>> >>> Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -495,7 +495,7 @@ >>> >>> // perform new initialization from the permission name >>> >>> - if (getName().indexOf(" ") == -1 && getName().indexOf("\"") >>> == -1) >>> { >>> + if (getName().indexOf(' ') == -1 && getName().indexOf('\"') >>> == -1) >>> { >>> >>> // name only has a credential class specified >>> credentialClass = getName(); >>> diff -r e323c74edabd src/share/classes/javax/security/sasl/Sasl.java >>> --- a/src/share/classes/javax/security/sasl/Sasl.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/javax/security/sasl/Sasl.java Sat Apr 26 >>> 07:31:04 >>> 2014 -0300 >>> @@ -600,7 +600,7 @@ >>> // implementation of an algorithm. We are only >>> interested >>> // in entries which lead to the implementation >>> // classes. >>> - if (currentKey.indexOf(" ") < 0) { >>> + if (currentKey.indexOf(' ') < 0) { >>> String className = >>> providers[i].getProperty(currentKey); >>> if (!classes.contains(className)) { >>> classes.add(className); >>> diff -r e323c74edabd src/share/classes/javax/swing/JEditorPane.java >>> --- a/src/share/classes/javax/swing/JEditorPane.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/javax/swing/JEditorPane.java Sat Apr 26 >>> 07:31:04 >>> 2014 -0300 >>> @@ -964,7 +964,7 @@ >>> // The type could have optional info is part of it, >>> // for example some charset info. We need to strip that >>> // of and save it. >>> - int parm = type.indexOf(";"); >>> + int parm = type.indexOf(';'); >>> if (parm > -1) { >>> // Save the paramList. >>> String paramList = type.substring(parm); >>> diff -r e323c74edabd >>> src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java >>> --- a/src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -653,7 +653,7 @@ >>> >>> // strip off the prefix, if there is one. >>> String fullKey = key.toString(); >>> - String partialKey = fullKey.substring(fullKey.indexOf(".") >>> + 1); >>> + String partialKey = fullKey.substring(fullKey.indexOf('.') >>> + 1); >>> >>> Object obj = null; >>> int xstate = getExtendedState(ctx, v); >>> diff -r e323c74edabd >>> src/share/classes/sun/applet/AppletClassLoader.java >>> --- a/src/share/classes/sun/applet/AppletClassLoader.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/applet/AppletClassLoader.java Sat Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -168,7 +168,7 @@ >>> */ >>> protected Class findClass(String name) throws >>> ClassNotFoundException { >>> >>> - int index = name.indexOf(";"); >>> + int index = name.indexOf(';'); >>> String cookie = ""; >>> if(index != -1) { >>> cookie = name.substring(index, name.length()); >>> @@ -608,7 +608,7 @@ >>> >>> // deal with URL rewriting >>> String cookie = null; >>> - int index = name.indexOf(";"); >>> + int index = name.indexOf(';'); >>> if(index != -1) { >>> cookie = name.substring(index, name.length()); >>> name = name.substring(0, index); >>> diff -r e323c74edabd src/share/classes/sun/awt/FontConfiguration.java >>> --- a/src/share/classes/sun/awt/FontConfiguration.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/awt/FontConfiguration.java Sat Apr 26 >>> 07:31:04 >>> 2014 -0300 >>> @@ -272,9 +272,9 @@ >>> if (configFile != null) { >>> return configFile; >>> } >>> - int decimalPointIndex = osVersion.indexOf("."); >>> + int decimalPointIndex = osVersion.indexOf('.'); >>> if (decimalPointIndex != -1) { >>> - osMajorVersion = osVersion.substring(0, >>> osVersion.indexOf(".")); >>> + osMajorVersion = osVersion.substring(0, >>> osVersion.indexOf('.')); >>> configFile = findImpl(baseName + "." + osName + "." + >>> osMajorVersion); >>> if (configFile != null) { >>> return configFile; >>> diff -r e323c74edabd src/share/classes/sun/font/Type1Font.java >>> --- a/src/share/classes/sun/font/Type1Font.java Wed Apr 23 11:35:40 >>> 2014 >>> -0700 >>> +++ b/src/share/classes/sun/font/Type1Font.java Sat Apr 26 07:31:04 >>> 2014 >>> -0300 >>> @@ -492,7 +492,7 @@ >>> >>> //Conversion: Expand abbreviations in style portion >>> (everything >>> after '-'), >>> // replace '-' with space and insert missing >>> spaces >>> - pos = name.indexOf("-"); >>> + pos = name.indexOf('-'); >>> if (pos >= 0) { >>> res = expandName(name.substring(0, pos), false); >>> res += " " + expandName(name.substring(pos+1), true); >>> @@ -513,8 +513,8 @@ >>> //Conversion: Truncate style portion (everything after '-') >>> // and insert missing spaces >>> >>> - if (tmp.indexOf("-") > 0) { >>> - tmp = tmp.substring(0, tmp.indexOf("-")); >>> + if (tmp.indexOf('-') > 0) { >>> + tmp = tmp.substring(0, tmp.indexOf('-')); >>> } >>> >>> return expandName(tmp, false); >>> diff -r e323c74edabd >>> src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java >>> --- a/src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -84,7 +84,7 @@ >>> * {@inheritDoc} >>> */ >>> public String getBaseName() { >>> - int baseIndex = name.lastIndexOf(".")+1; >>> + int baseIndex = name.lastIndexOf('.') + 1; >>> return name.substring(baseIndex); >>> } >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/jvmstat/monitor/HostIdentifier.java >>> --- a/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -138,8 +138,8 @@ >>> String frag = u.getFragment(); >>> URI u2 = null; >>> >>> - int c1index = uriString.indexOf(":"); >>> - int c2index = uriString.lastIndexOf(":"); >>> + int c1index = uriString.indexOf(':'); >>> + int c2index = uriString.lastIndexOf(':'); >>> if (c2index != c1index) { >>> /* >>> * this is the scheme:hostname:port case. >>> Attempt to >>> diff -r e323c74edabd >>> src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java >>> >>> >>> --- >>> a/src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java >>> >>> >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java >>> >>> >>> Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -70,8 +70,8 @@ >>> >>> String addrStr; >>> if (target.startsWith("[")) { >>> - final int index = target.indexOf("]"); >>> - final int index2 = target.lastIndexOf(":"); >>> + final int index = target.indexOf(']'); >>> + final int index2 = target.lastIndexOf(':'); >>> if(index == -1) >>> throw new IllegalArgumentException("Host starts with >>> [ but >>> " + >>> "does not end >>> with ]"); >>> @@ -85,8 +85,8 @@ >>> if (addrStr.startsWith("[")) >>> throw new IllegalArgumentException("More than one >>> [[...]]"); >>> } else { >>> - final int index = target.indexOf(":"); >>> - final int index2 = target.lastIndexOf(":"); >>> + final int index = target.indexOf(':'); >>> + final int index2 = target.lastIndexOf(':'); >>> if(index == -1) throw new >>> IllegalArgumentException("Missing port separator >>> \":\""); >>> addrStr = target.substring(0, index); >>> @@ -98,7 +98,7 @@ >>> address = InetAddress.getByName(addrStr); >>> >>> //THE CHECK SHOULD BE STRONGER!!! >>> - final int index = target.lastIndexOf(":"); >>> + final int index = target.lastIndexOf(':'); >>> >>> community = target.substring(index + 1, target.length()); >>> >>> diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java >>> --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sat Apr 26 07:31:04 >>> 2014 -0300 >>> @@ -273,8 +273,8 @@ >>> else >>> { >>> // Look for index of "." in the string >>> - int sIdx = source.indexOf("."); >>> - int tIdx = target.indexOf("."); >>> + int sIdx = source.indexOf('.'); >>> + int tIdx = target.indexOf('.'); >>> >>> if (sIdx == -1) >>> sIdx = source.length() - 1; >>> @@ -304,10 +304,10 @@ >>> String versionError = mf.format(args); >>> >>> // Look for "-" for pre-release >>> - int prIndex = token.indexOf("-"); >>> + int prIndex = token.indexOf('-'); >>> >>> // Look for "_" for patch release >>> - int patchIndex = token.indexOf("_"); >>> + int patchIndex = token.indexOf('_'); >>> >>> if (prIndex == -1 && patchIndex == -1) >>> { >>> diff -r e323c74edabd src/share/classes/sun/misc/JarIndex.java >>> --- a/src/share/classes/sun/misc/JarIndex.java Wed Apr 23 11:35:40 2014 >>> -0700 >>> +++ b/src/share/classes/sun/misc/JarIndex.java Sat Apr 26 07:31:04 2014 >>> -0300 >>> @@ -172,7 +172,7 @@ >>> if ((jarFiles = indexMap.get(fileName)) == null) { >>> /* try the package name again */ >>> int pos; >>> - if((pos = fileName.lastIndexOf("/")) != -1) { >>> + if((pos = fileName.lastIndexOf('/')) != -1) { >>> jarFiles = indexMap.get(fileName.substring(0, pos)); >>> } >>> } >>> @@ -195,7 +195,7 @@ >>> public void add(String fileName, String jarName) { >>> String packageName; >>> int pos; >>> - if((pos = fileName.lastIndexOf("/")) != -1) { >>> + if((pos = fileName.lastIndexOf('/')) != -1) { >>> packageName = fileName.substring(0, pos); >>> } else { >>> packageName = fileName; >>> diff -r e323c74edabd src/share/classes/sun/misc/URLClassPath.java >>> --- a/src/share/classes/sun/misc/URLClassPath.java Wed Apr 23 11:35:40 >>> 2014 >>> -0700 >>> +++ b/src/share/classes/sun/misc/URLClassPath.java Sat Apr 26 07:31:04 >>> 2014 >>> -0300 >>> @@ -793,7 +793,7 @@ >>> boolean validIndex(final String name) { >>> String packageName = name; >>> int pos; >>> - if((pos = name.lastIndexOf("/")) != -1) { >>> + if((pos = name.lastIndexOf('/')) != -1) { >>> packageName = name.substring(0, pos); >>> } >>> >>> @@ -803,7 +803,7 @@ >>> while (enum_.hasMoreElements()) { >>> entry = enum_.nextElement(); >>> entryName = entry.getName(); >>> - if((pos = entryName.lastIndexOf("/")) != -1) >>> + if((pos = entryName.lastIndexOf('/')) != -1) >>> entryName = entryName.substring(0, pos); >>> if (entryName.equals(packageName)) { >>> return true; >>> @@ -900,7 +900,7 @@ >>> */ >>> JarIndex newIndex = newLoader.getIndex(); >>> if(newIndex != null) { >>> - int pos = jarName.lastIndexOf("/"); >>> + int pos = jarName.lastIndexOf('/'); >>> newIndex.merge(this.index, (pos == >>> -1 ? >>> null : jarName.substring(0, pos >>> + 1))); >>> } >>> diff -r e323c74edabd src/share/classes/sun/net/ftp/impl/FtpClient.java >>> --- a/src/share/classes/sun/net/ftp/impl/FtpClient.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/net/ftp/impl/FtpClient.java Sat Apr 26 >>> 07:31:04 >>> 2014 -0300 >>> @@ -259,7 +259,7 @@ >>> d = null; >>> } >>> if (d != null && time != null) { >>> - int c = time.indexOf(":"); >>> + int c = time.indexOf(':'); >>> now.setTime(d); >>> now.set(Calendar.HOUR, >>> Integer.parseInt(time.substring(0, c))); >>> now.set(Calendar.MINUTE, >>> Integer.parseInt(time.substring(c + 1))); >>> @@ -295,7 +295,7 @@ >>> >>> public FtpDirEntry parseLine(String line) { >>> String name = null; >>> - int i = line.lastIndexOf(";"); >>> + int i = line.lastIndexOf(';'); >>> if (i > 0) { >>> name = line.substring(i + 1).trim(); >>> line = line.substring(0, i); >>> @@ -306,7 +306,7 @@ >>> FtpDirEntry file = new FtpDirEntry(name); >>> while (!line.isEmpty()) { >>> String s; >>> - i = line.indexOf(";"); >>> + i = line.indexOf(';'); >>> if (i > 0) { >>> s = line.substring(0, i); >>> line = line.substring(i + 1); >>> @@ -314,7 +314,7 @@ >>> s = line; >>> line = ""; >>> } >>> - i = s.indexOf("="); >>> + i = s.indexOf('='); >>> if (i > 0) { >>> String fact = s.substring(0, i); >>> String value = s.substring(i + 1); >>> diff -r e323c74edabd >>> src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java >>> --- >>> a/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -325,7 +325,7 @@ >>> while (i.hasNext()) { >>> String parentDomain = i.next(); >>> int start = 0; >>> - while ((start = parentDomain.indexOf(".")) != -1 >>> + while ((start = parentDomain.indexOf('.')) != -1 >>> && start < parentDomain.length() -1) { >>> try { >>> results = resolve(ctx, >>> host+"."+parentDomain, ids, >>> 0); >>> diff -r e323c74edabd src/share/classes/sun/net/util/IPAddressUtil.java >>> --- a/src/share/classes/sun/net/util/IPAddressUtil.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/net/util/IPAddressUtil.java Sat Apr 26 >>> 07:31:04 >>> 2014 -0300 >>> @@ -149,7 +149,7 @@ >>> byte[] dst = new byte[INADDR16SZ]; >>> >>> int srcb_length = srcb.length; >>> - int pc = src.indexOf ("%"); >>> + int pc = src.indexOf ('%'); >>> if (pc == srcb_length -1) { >>> return null; >>> } >>> diff -r e323c74edabd src/share/classes/sun/net/www/ParseUtil.java >>> --- a/src/share/classes/sun/net/www/ParseUtil.java Wed Apr 23 11:35:40 >>> 2014 >>> -0700 >>> +++ b/src/share/classes/sun/net/www/ParseUtil.java Sat Apr 26 07:31:04 >>> 2014 >>> -0300 >>> @@ -356,8 +356,8 @@ >>> * because we must not quote a literal IPv6 address >>> */ >>> if (opaquePart.startsWith("//[")) { >>> - int end = opaquePart.indexOf("]"); >>> - if (end != -1 && opaquePart.indexOf(":")!=-1) { >>> + int end = opaquePart.indexOf(']'); >>> + if (end != -1 && opaquePart.indexOf(':')!=-1) { >>> String doquote, dontquote; >>> if (end == opaquePart.length()) { >>> dontquote = opaquePart; >>> @@ -408,8 +408,8 @@ >>> } else if (authority != null) { >>> sb.append("//"); >>> if (authority.startsWith("[")) { >>> - int end = authority.indexOf("]"); >>> - if (end != -1 && authority.indexOf(":")!=-1) { >>> + int end = authority.indexOf(']'); >>> + if (end != -1 && authority.indexOf(':')!=-1) { >>> String doquote, dontquote; >>> if (end == authority.length()) { >>> dontquote = authority; >>> diff -r e323c74edabd >>> src/share/classes/sun/reflect/misc/ReflectUtil.java >>> --- a/src/share/classes/sun/reflect/misc/ReflectUtil.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/reflect/misc/ReflectUtil.java Sat Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -341,6 +341,6 @@ >>> * (not to be confused with a Java Language anonymous inner >>> class). >>> */ >>> public static boolean isVMAnonymousClass(Class cls) { >>> - return cls.getName().indexOf("/") > -1; >>> + return cls.getName().indexOf('/') > -1; >>> } >>> } >>> diff -r e323c74edabd src/share/classes/sun/rmi/runtime/Log.java >>> --- a/src/share/classes/sun/rmi/runtime/Log.java Wed Apr 23 11:35:40 >>> 2014 >>> -0700 >>> +++ b/src/share/classes/sun/rmi/runtime/Log.java Sat Apr 26 07:31:04 >>> 2014 >>> -0300 >>> @@ -434,7 +434,7 @@ >>> * Mimic old log messages that only contain unqualified >>> names. >>> */ >>> private static String unqualifiedName(String name) { >>> - int lastDot = name.lastIndexOf("."); >>> + int lastDot = name.lastIndexOf('.'); >>> if (lastDot >= 0) { >>> name = name.substring(lastDot + 1); >>> } >>> diff -r e323c74edabd >>> src/share/classes/sun/rmi/transport/proxy/CGIHandler.java >>> --- a/src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -141,7 +141,7 @@ >>> { >>> try { >>> String command, param; >>> - int delim = QueryString.indexOf("="); >>> + int delim = QueryString.indexOf('='); >>> if (delim == -1) { >>> command = QueryString; >>> param = ""; >>> diff -r e323c74edabd >>> src/share/classes/sun/security/jgss/wrapper/Krb5Util.java >>> --- a/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> static String getTGSName(GSSNameElement name) >>> throws GSSException { >>> String krbPrinc = name.getKrbName(); >>> - int atIndex = krbPrinc.indexOf("@"); >>> + int atIndex = krbPrinc.indexOf('@'); >>> String realm = krbPrinc.substring(atIndex + 1); >>> StringBuffer buf = new StringBuffer("krbtgt/"); >>> buf.append(realm).append('@').append(realm); >>> diff -r e323c74edabd >>> src/share/classes/sun/security/provider/PolicyFile.java >>> --- a/src/share/classes/sun/security/provider/PolicyFile.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/security/provider/PolicyFile.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -1856,7 +1856,7 @@ >>> int colonIndex; >>> String prefix = value; >>> String suffix; >>> - if ((colonIndex = value.indexOf(":")) != -1) { >>> + if ((colonIndex = value.indexOf(':')) != -1) { >>> prefix = value.substring(0, colonIndex); >>> } >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java >>> --- a/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java >>> Wed Apr >>> 23 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java >>> Sat Apr >>> 26 07:31:04 2014 -0300 >>> @@ -338,7 +338,7 @@ >>> } >>> String sigType; >>> if (keyType.contains("_")) { >>> - int k = keyType.indexOf("_"); >>> + int k = keyType.indexOf('_'); >>> sigType = keyType.substring(k + 1); >>> keyType = keyType.substring(0, k); >>> } else { >>> diff -r e323c74edabd >>> src/share/classes/sun/security/ssl/X509KeyManagerImpl.java >>> --- a/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -302,7 +302,7 @@ >>> final String sigKeyAlgorithm; >>> >>> KeyType(String algorithm) { >>> - int k = algorithm.indexOf("_"); >>> + int k = algorithm.indexOf('_'); >>> if (k == -1) { >>> keyAlgorithm = algorithm; >>> sigKeyAlgorithm = null; >>> diff -r e323c74edabd >>> src/share/classes/sun/security/util/HostnameChecker.java >>> --- a/src/share/classes/sun/security/util/HostnameChecker.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/security/util/HostnameChecker.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -300,8 +300,8 @@ >>> template = template.toLowerCase(Locale.ENGLISH); >>> >>> // Retreive leftmost component >>> - int templateIdx = template.indexOf("."); >>> - int nameIdx = name.indexOf("."); >>> + int templateIdx = template.indexOf('.'); >>> + int nameIdx = name.indexOf('.'); >>> >>> if (templateIdx == -1) >>> templateIdx = template.length(); >>> @@ -326,7 +326,7 @@ >>> */ >>> private static boolean matchWildCards(String name, String >>> template) { >>> >>> - int wildcardIdx = template.indexOf("*"); >>> + int wildcardIdx = template.indexOf('*'); >>> if (wildcardIdx == -1) >>> return name.equals(template); >>> >>> @@ -349,7 +349,7 @@ >>> >>> // update the match scope >>> name = name.substring(beforeStartIdx + >>> beforeWildcard.length()); >>> - wildcardIdx = afterWildcard.indexOf("*"); >>> + wildcardIdx = afterWildcard.indexOf('*'); >>> } >>> return name.endsWith(afterWildcard); >>> } >>> diff -r e323c74edabd >>> src/share/classes/sun/security/util/SignatureFileVerifier.java >>> --- a/src/share/classes/sun/security/util/SignatureFileVerifier.java >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/security/util/SignatureFileVerifier.java >>> Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -98,7 +98,7 @@ >>> } finally { >>> Providers.stopJarVerification(obj); >>> } >>> - this.name = name.substring(0, name.lastIndexOf(".")) >>> + this.name = name.substring(0, name.lastIndexOf('.')) >>> >>> .toUpperCase(Locale.ENGLISH); >>> this.md = md; >>> this.signerCache = signerCache; >>> diff -r e323c74edabd >>> src/share/classes/sun/security/x509/CRLExtensions.java >>> --- a/src/share/classes/sun/security/x509/CRLExtensions.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/security/x509/CRLExtensions.java Sat Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -185,7 +185,7 @@ >>> String name; >>> String id = attr.getPrefix(); >>> if (id.equalsIgnoreCase(X509CertImpl.NAME)) { // fully >>> qualified >>> - int index = alias.lastIndexOf("."); >>> + int index = alias.lastIndexOf('.'); >>> name = alias.substring(index + 1); >>> } else >>> name = alias; >>> diff -r e323c74edabd >>> src/share/classes/sun/tools/jconsole/ConnectDialog.java >>> --- a/src/share/classes/sun/tools/jconsole/ConnectDialog.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/tools/jconsole/ConnectDialog.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -325,7 +325,7 @@ >>> } else { >>> String host = remoteTF.getText().trim(); >>> String port = "0"; >>> - int index = host.lastIndexOf(":"); >>> + int index = host.lastIndexOf(':'); >>> if (index >= 0) { >>> port = host.substring(index + 1); >>> host = host.substring(0, index); >>> diff -r e323c74edabd >>> src/share/classes/sun/tools/jconsole/inspector/Utils.java >>> --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -210,7 +210,7 @@ >>> public static String getArrayClassName(String name) { >>> String className = null; >>> if (name.startsWith("[")) { >>> - int index = name.lastIndexOf("["); >>> + int index = name.lastIndexOf('['); >>> className = name.substring(index, name.length()); >>> if (className.startsWith("[L")) { >>> className = className.substring(2, >>> className.length() - 1); >>> @@ -241,7 +241,7 @@ >>> if (className == null) { >>> return name; >>> } >>> - int index = name.lastIndexOf("["); >>> + int index = name.lastIndexOf('['); >>> StringBuilder brackets = new StringBuilder(className); >>> for (int i = 0; i <= index; i++) { >>> brackets.append("[]"); >>> diff -r e323c74edabd >>> src/share/classes/sun/tools/jconsole/inspector/XOperations.java >>> --- >>> a/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Sat >>> Apr 26 07:31:04 2014 -0300 >>> @@ -112,7 +112,7 @@ >>> if (methodLabel.getText().length() > 20) { >>> methodLabel.setText(methodLabel.getText(). >>> substring(methodLabel.getText(). >>> - lastIndexOf(".") + 1, >>> + lastIndexOf('.') + 1, >>> methodLabel.getText().length())); >>> } >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/tools/jconsole/inspector/XTree.java >>> --- a/src/share/classes/sun/tools/jconsole/inspector/XTree.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/tools/jconsole/inspector/XTree.java Sat >>> Apr 26 >>> 07:31:04 2014 -0300 >>> @@ -475,7 +475,7 @@ >>> private static Map extractKeyValuePairs( >>> String props, ObjectName mbean) { >>> Map map = new LinkedHashMap>> String>(); >>> - int eq = props.indexOf("="); >>> + int eq = props.indexOf('='); >>> while (eq != -1) { >>> String key = props.substring(0, eq); >>> String value = mbean.getKeyProperty(key); >>> @@ -484,7 +484,7 @@ >>> if (props.startsWith(",")) { >>> props = props.substring(1); >>> } >>> - eq = props.indexOf("="); >>> + eq = props.indexOf('='); >>> } >>> return map; >>> } >>> @@ -821,7 +821,7 @@ >>> } >>> >>> private void buildKeyValue() { >>> - int index = tokenValue.indexOf("="); >>> + int index = tokenValue.indexOf('='); >>> if (index < 0) { >>> key = tokenValue; >>> value = tokenValue; >>> >> From otaviopolianasantana at gmail.com Sun Apr 27 13:15:58 2014 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Sun, 27 Apr 2014 10:15:58 -0300 Subject: Remove redundant calls of toString() Message-ID: There is an issue that was opened to remove redundant calls of toString() on String objects. [1] I went deep on all JVM sources and I found all, 32 changes. [1]https://bugs.openjdk.java.net/browse/JDK-8015470 diff -r e323c74edabd src/share/classes/com/sun/tools/example/debug/tty/Commands.java --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sat Apr 26 01:40:27 2014 -0300 @@ -1653,20 +1653,20 @@ String expr = t.nextToken(""); Value val = evaluate(expr); if (val == null) { - MessageOutput.println("expr is null", expr.toString()); + MessageOutput.println("expr is null", expr); } else if (dumpObject && (val instanceof ObjectReference) && !(val instanceof StringReference)) { ObjectReference obj = (ObjectReference)val; ReferenceType refType = obj.referenceType(); MessageOutput.println("expr is value", - new Object [] {expr.toString(), + new Object [] {expr, MessageOutput.format("grouping begin character")}); dump(obj, refType, refType); MessageOutput.println("grouping end character"); } else { String strVal = getStringValue(); if (strVal != null) { - MessageOutput.println("expr is value", new Object [] {expr.toString(), + MessageOutput.println("expr is value", new Object [] {expr, strVal}); } } diff -r e323c74edabd src/share/classes/java/lang/annotation/IncompleteAnnotationException.java --- a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java Sat Apr 26 01:40:27 2014 -0300 @@ -56,7 +56,7 @@ Class annotationType, String elementName) { super(annotationType.getName() + " missing element " + - elementName.toString()); + elementName); this.annotationType = annotationType; this.elementName = elementName; diff -r e323c74edabd src/share/classes/java/text/DateFormatSymbols.java --- a/src/share/classes/java/text/DateFormatSymbols.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/text/DateFormatSymbols.java Sat Apr 26 01:40:27 2014 -0300 @@ -593,8 +593,8 @@ * pattern characters. */ public void setLocalPatternChars(String newLocalPatternChars) { - // Call toString() to throw an NPE in case the argument is null - localPatternChars = newLocalPatternChars.toString(); + + localPatternChars = Objects.requireNonNull(newLocalPatternChars); cachedHashCode = 0; } diff -r e323c74edabd src/share/classes/javax/management/modelmbean/DescriptorSupport.java --- a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Sat Apr 26 01:40:27 2014 -0300 @@ -665,7 +665,7 @@ "getFieldNames()", "Field is null"); } } else { - responseFields[i] = currElement.getKey().toString(); + responseFields[i] = currElement.getKey(); } } @@ -929,8 +929,8 @@ if (currElement != null) { if (currElement.getValue() != null) { // validate the field valued... - if (validateField((currElement.getKey()).toString(), - (currElement.getValue()).toString())) { + if (validateField((currElement.getKey()), + (currElement.getValue()))) { continue; } else { if (MODELMBEAN_LOGGER.isLoggable(Level.FINEST)) { diff -r e323c74edabd src/share/classes/javax/swing/text/html/FormView.java --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/swing/text/html/FormView.java Sat Apr 26 01:40:27 2014 -0300 @@ -478,7 +478,7 @@ base.getPort(), base.getFile()) : new URL(base, action); if (!isPostMethod) { - String query = data.toString(); + String query = data; actionURL = new URL(actionURL + "?" + query); } } catch (MalformedURLException e) { diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/Blit.java Sat Apr 26 01:40:27 2014 -0300 @@ -50,7 +50,7 @@ public class Blit extends GraphicsPrimitive { - public static final String methodSignature = "Blit(...)".toString(); + public static final String methodSignature = "Blit(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sat Apr 26 01:40:27 2014 -0300 @@ -54,7 +54,7 @@ */ public class BlitBg extends GraphicsPrimitive { - public static final String methodSignature = "BlitBg(...)".toString(); + public static final String methodSignature = "BlitBg(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphList.java --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sat Apr 26 01:40:27 2014 -0300 @@ -39,7 +39,7 @@ */ public class DrawGlyphList extends GraphicsPrimitive { - public final static String methodSignature = "DrawGlyphList(...)".toString(); + public final static String methodSignature = "DrawGlyphList(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphListAA.java --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sat Apr 26 01:40:27 2014 -0300 @@ -39,7 +39,7 @@ */ public class DrawGlyphListAA extends GraphicsPrimitive { - public final static String methodSignature = "DrawGlyphListAA(...)".toString(); + public final static String methodSignature = "DrawGlyphListAA(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sat Apr 26 01:40:27 2014 -0300 @@ -40,7 +40,7 @@ public class DrawGlyphListLCD extends GraphicsPrimitive { public final static String - methodSignature = "DrawGlyphListLCD(...)".toString(); + methodSignature = "DrawGlyphListLCD(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sat Apr 26 01:40:27 2014 -0300 @@ -44,7 +44,7 @@ */ public class DrawLine extends GraphicsPrimitive { - public final static String methodSignature = "DrawLine(...)".toString(); + public final static String methodSignature = "DrawLine(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawParallelogram.java --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sat Apr 26 01:40:27 2014 -0300 @@ -43,7 +43,7 @@ public class DrawParallelogram extends GraphicsPrimitive { public final static String methodSignature = - "DrawParallelogram(...)".toString(); + "DrawParallelogram(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sat Apr 26 01:40:27 2014 -0300 @@ -39,7 +39,7 @@ public class DrawPath extends GraphicsPrimitive { public final static String methodSignature = - "DrawPath(...)".toString(); + "DrawPath(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPolygons.java --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sat Apr 26 01:40:27 2014 -0300 @@ -41,7 +41,7 @@ */ public class DrawPolygons extends GraphicsPrimitive { - public final static String methodSignature = "DrawPolygons(...)".toString(); + public final static String methodSignature = "DrawPolygons(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sat Apr 26 01:40:27 2014 -0300 @@ -44,7 +44,7 @@ */ public class DrawRect extends GraphicsPrimitive { - public final static String methodSignature = "DrawRect(...)".toString(); + public final static String methodSignature = "DrawRect(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillParallelogram.java --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sat Apr 26 01:40:27 2014 -0300 @@ -41,7 +41,7 @@ public class FillParallelogram extends GraphicsPrimitive { public final static String methodSignature = - "FillParallelogram(...)".toString(); + "FillParallelogram(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sat Apr 26 01:40:27 2014 -0300 @@ -39,7 +39,7 @@ public class FillPath extends GraphicsPrimitive { public final static String methodSignature = - "FillPath(...)".toString(); + "FillPath(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sat Apr 26 01:40:27 2014 -0300 @@ -44,7 +44,7 @@ */ public class FillRect extends GraphicsPrimitive { - public final static String methodSignature = "FillRect(...)".toString(); + public final static String methodSignature = "FillRect(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sat Apr 26 01:40:27 2014 -0300 @@ -45,7 +45,7 @@ */ public class FillSpans extends GraphicsPrimitive { - public final static String methodSignature = "FillSpans(...)".toString(); + public final static String methodSignature = "FillSpans(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sat Apr 26 01:40:27 2014 -0300 @@ -48,7 +48,7 @@ public class MaskBlit extends GraphicsPrimitive { - public static final String methodSignature = "MaskBlit(...)".toString(); + public static final String methodSignature = "MaskBlit(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sat Apr 26 01:40:27 2014 -0300 @@ -50,11 +50,11 @@ */ public class MaskFill extends GraphicsPrimitive { - public static final String methodSignature = "MaskFill(...)".toString(); + public static final String methodSignature = "MaskFill(...)"; public static final String fillPgramSignature = - "FillAAPgram(...)".toString(); + "FillAAPgram(...)"; public static final String drawPgramSignature = - "DrawAAPgram(...)".toString(); + "DrawAAPgram(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sat Apr 26 01:40:27 2014 -0300 @@ -45,7 +45,7 @@ public class ScaledBlit extends GraphicsPrimitive { - public static final String methodSignature = "ScaledBlit(...)".toString(); + public static final String methodSignature = "ScaledBlit(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/TransformBlit.java --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sat Apr 26 01:40:27 2014 -0300 @@ -47,7 +47,7 @@ public class TransformBlit extends GraphicsPrimitive { public static final String methodSignature = - "TransformBlit(...)".toString(); + "TransformBlit(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/TransformHelper.java --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sat Apr 26 01:40:27 2014 -0300 @@ -46,7 +46,7 @@ public class TransformHelper extends GraphicsPrimitive { public static final String methodSignature = - "TransformHelper(...)".toString(); + "TransformHelper(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sat Apr 26 01:40:27 2014 -0300 @@ -260,11 +260,11 @@ // Convert token into meaning number for comparision if (stk.hasMoreTokens()) - n = convertToken(stk.nextToken().toString()); + n = convertToken(stk.nextToken()); // Convert token into meaning number for comparision if (ttk.hasMoreTokens()) - m = convertToken(ttk.nextToken().toString()); + m = convertToken(ttk.nextToken()); if (n > m) return 1; diff -r e323c74edabd src/share/classes/sun/tools/jconsole/inspector/Utils.java --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat Apr 26 01:40:27 2014 -0300 @@ -378,7 +378,7 @@ if (userInput instanceof XObject) { result[i] = ((XObject) userInput).getObject(); } else { - result[i] = createObjectFromString(params[i].toString(), + result[i] = createObjectFromString(params[i], (String) userInput); } } -- Cheers!. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava * 55 (11) 98255-3513 From forax at univ-mlv.fr Sun Apr 27 16:09:47 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 27 Apr 2014 18:09:47 +0200 Subject: Remove redundant calls of toString() In-Reply-To: References: Message-ID: <535D2BCB.8090707@univ-mlv.fr> On 04/27/2014 03:15 PM, Ot?vio Gon?alves de Santana wrote: > There is an issue that was opened to remove redundant calls of toString() > on String objects. [1] > I went deep on all JVM sources and I found all, 32 changes. > > > [1]https://bugs.openjdk.java.net/browse/JDK-8015470 Otavio, calling toString() on a String has the side effect to implicitly check that the reference is not null. Do you have checked that for each redundant call, the String can never be null ? regards, R?mi > > > diff -r e323c74edabd > src/share/classes/com/sun/tools/example/debug/tty/Commands.java > --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sat > Apr 26 01:40:27 2014 -0300 > @@ -1653,20 +1653,20 @@ > String expr = t.nextToken(""); > Value val = evaluate(expr); > if (val == null) { > - MessageOutput.println("expr is null", expr.toString()); > + MessageOutput.println("expr is null", expr); > } else if (dumpObject && (val instanceof ObjectReference) && > !(val instanceof StringReference)) { > ObjectReference obj = (ObjectReference)val; > ReferenceType refType = obj.referenceType(); > MessageOutput.println("expr is value", > - new Object [] {expr.toString(), > + new Object [] {expr, > > MessageOutput.format("grouping begin character")}); > dump(obj, refType, refType); > MessageOutput.println("grouping end character"); > } else { > String strVal = getStringValue(); > if (strVal != null) { > - MessageOutput.println("expr is value", new Object [] > {expr.toString(), > + MessageOutput.println("expr is value", new Object [] > {expr, > > strVal}); > } > } > diff -r e323c74edabd > src/share/classes/java/lang/annotation/IncompleteAnnotationException.java > --- > a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java Wed > Apr 23 11:35:40 2014 -0700 > +++ > b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java Sat > Apr 26 01:40:27 2014 -0300 > @@ -56,7 +56,7 @@ > Class annotationType, > String elementName) { > super(annotationType.getName() + " missing element " + > - elementName.toString()); > + elementName); > > this.annotationType = annotationType; > this.elementName = elementName; > diff -r e323c74edabd src/share/classes/java/text/DateFormatSymbols.java > --- a/src/share/classes/java/text/DateFormatSymbols.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/java/text/DateFormatSymbols.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -593,8 +593,8 @@ > * pattern characters. > */ > public void setLocalPatternChars(String newLocalPatternChars) { > - // Call toString() to throw an NPE in case the argument is null > - localPatternChars = newLocalPatternChars.toString(); > + > + localPatternChars = Objects.requireNonNull(newLocalPatternChars); > cachedHashCode = 0; > } > > diff -r e323c74edabd > src/share/classes/javax/management/modelmbean/DescriptorSupport.java > --- a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Sat > Apr 26 01:40:27 2014 -0300 > @@ -665,7 +665,7 @@ > "getFieldNames()", "Field is null"); > } > } else { > - responseFields[i] = currElement.getKey().toString(); > + responseFields[i] = currElement.getKey(); > } > } > > @@ -929,8 +929,8 @@ > if (currElement != null) { > if (currElement.getValue() != null) { > // validate the field valued... > - if (validateField((currElement.getKey()).toString(), > - > (currElement.getValue()).toString())) { > + if (validateField((currElement.getKey()), > + (currElement.getValue()))) { > continue; > } else { > if (MODELMBEAN_LOGGER.isLoggable(Level.FINEST)) { > diff -r e323c74edabd src/share/classes/javax/swing/text/html/FormView.java > --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/javax/swing/text/html/FormView.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -478,7 +478,7 @@ > base.getPort(), base.getFile()) > : new URL(base, action); > if (!isPostMethod) { > - String query = data.toString(); > + String query = data; > actionURL = new URL(actionURL + "?" + query); > } > } catch (MalformedURLException e) { > diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java > --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 2014 > -0700 > +++ b/src/share/classes/sun/java2d/loops/Blit.java Sat Apr 26 01:40:27 2014 > -0300 > @@ -50,7 +50,7 @@ > > public class Blit extends GraphicsPrimitive > { > - public static final String methodSignature = "Blit(...)".toString(); > + public static final String methodSignature = "Blit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java > --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -54,7 +54,7 @@ > */ > public class BlitBg extends GraphicsPrimitive > { > - public static final String methodSignature = "BlitBg(...)".toString(); > + public static final String methodSignature = "BlitBg(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphList.java > --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -39,7 +39,7 @@ > */ > public class DrawGlyphList extends GraphicsPrimitive { > > - public final static String methodSignature = > "DrawGlyphList(...)".toString(); > + public final static String methodSignature = "DrawGlyphList(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphListAA.java > --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -39,7 +39,7 @@ > */ > public class DrawGlyphListAA extends GraphicsPrimitive { > > - public final static String methodSignature = > "DrawGlyphListAA(...)".toString(); > + public final static String methodSignature = "DrawGlyphListAA(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java > --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -40,7 +40,7 @@ > public class DrawGlyphListLCD extends GraphicsPrimitive { > > public final static String > - methodSignature = "DrawGlyphListLCD(...)".toString(); > + methodSignature = "DrawGlyphListLCD(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java > --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class DrawLine extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawLine(...)".toString(); > + public final static String methodSignature = "DrawLine(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/loops/DrawParallelogram.java > --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -43,7 +43,7 @@ > public class DrawParallelogram extends GraphicsPrimitive > { > public final static String methodSignature = > - "DrawParallelogram(...)".toString(); > + "DrawParallelogram(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java > --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -39,7 +39,7 @@ > public class DrawPath extends GraphicsPrimitive { > > public final static String methodSignature = > - "DrawPath(...)".toString(); > + "DrawPath(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPolygons.java > --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -41,7 +41,7 @@ > */ > public class DrawPolygons extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawPolygons(...)".toString(); > + public final static String methodSignature = "DrawPolygons(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java > --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class DrawRect extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawRect(...)".toString(); > + public final static String methodSignature = "DrawRect(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/loops/FillParallelogram.java > --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -41,7 +41,7 @@ > public class FillParallelogram extends GraphicsPrimitive > { > public final static String methodSignature = > - "FillParallelogram(...)".toString(); > + "FillParallelogram(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java > --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -39,7 +39,7 @@ > public class FillPath extends GraphicsPrimitive { > > public final static String methodSignature = > - "FillPath(...)".toString(); > + "FillPath(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java > --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class FillRect extends GraphicsPrimitive > { > - public final static String methodSignature = > "FillRect(...)".toString(); > + public final static String methodSignature = "FillRect(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java > --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -45,7 +45,7 @@ > */ > public class FillSpans extends GraphicsPrimitive > { > - public final static String methodSignature = > "FillSpans(...)".toString(); > + public final static String methodSignature = "FillSpans(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java > --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -48,7 +48,7 @@ > > public class MaskBlit extends GraphicsPrimitive > { > - public static final String methodSignature = > "MaskBlit(...)".toString(); > + public static final String methodSignature = "MaskBlit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java > --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -50,11 +50,11 @@ > */ > public class MaskFill extends GraphicsPrimitive > { > - public static final String methodSignature = > "MaskFill(...)".toString(); > + public static final String methodSignature = "MaskFill(...)"; > public static final String fillPgramSignature = > - "FillAAPgram(...)".toString(); > + "FillAAPgram(...)"; > public static final String drawPgramSignature = > - "DrawAAPgram(...)".toString(); > + "DrawAAPgram(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java > --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -45,7 +45,7 @@ > > public class ScaledBlit extends GraphicsPrimitive > { > - public static final String methodSignature = > "ScaledBlit(...)".toString(); > + public static final String methodSignature = "ScaledBlit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/TransformBlit.java > --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -47,7 +47,7 @@ > public class TransformBlit extends GraphicsPrimitive > { > public static final String methodSignature = > - "TransformBlit(...)".toString(); > + "TransformBlit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/TransformHelper.java > --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -46,7 +46,7 @@ > public class TransformHelper extends GraphicsPrimitive > { > public static final String methodSignature = > - "TransformHelper(...)".toString(); > + "TransformHelper(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java > --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -260,11 +260,11 @@ > > // Convert token into meaning number for comparision > if (stk.hasMoreTokens()) > - n = convertToken(stk.nextToken().toString()); > + n = convertToken(stk.nextToken()); > > // Convert token into meaning number for comparision > if (ttk.hasMoreTokens()) > - m = convertToken(ttk.nextToken().toString()); > + m = convertToken(ttk.nextToken()); > > if (n > m) > return 1; > diff -r e323c74edabd > src/share/classes/sun/tools/jconsole/inspector/Utils.java > --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -378,7 +378,7 @@ > if (userInput instanceof XObject) { > result[i] = ((XObject) userInput).getObject(); > } else { > - result[i] = createObjectFromString(params[i].toString(), > + result[i] = createObjectFromString(params[i], > (String) userInput); > } > } > > From otaviojava at java.net Sun Apr 27 16:34:47 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Sun, 27 Apr 2014 13:34:47 -0300 Subject: Remove redundant calls of toString() Message-ID: There is an issue that was opened to remove redundant calls of toString() on String objects. [1] I went deep on all JVM sources and I found all, 32 changes. [1]https://bugs.openjdk.java.net/browse/JDK-8015470 diff -r e323c74edabd src/share/classes/com/sun/tools/example/debug/tty/Commands.java --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sat Apr 26 01:40:27 2014 -0300 @@ -1653,20 +1653,20 @@ String expr = t.nextToken(""); Value val = evaluate(expr); if (val == null) { - MessageOutput.println("expr is null", expr.toString()); + MessageOutput.println("expr is null", expr); } else if (dumpObject && (val instanceof ObjectReference) && !(val instanceof StringReference)) { ObjectReference obj = (ObjectReference)val; ReferenceType refType = obj.referenceType(); MessageOutput.println("expr is value", - new Object [] {expr.toString(), + new Object [] {expr, MessageOutput.format("grouping begin character")}); dump(obj, refType, refType); MessageOutput.println("grouping end character"); } else { String strVal = getStringValue(); if (strVal != null) { - MessageOutput.println("expr is value", new Object [] {expr.toString(), + MessageOutput.println("expr is value", new Object [] {expr, strVal}); } } diff -r e323c74edabd src/share/classes/java/lang/annotation/IncompleteAnnotationException.java --- a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java Sat Apr 26 01:40:27 2014 -0300 @@ -56,7 +56,7 @@ Class annotationType, String elementName) { super(annotationType.getName() + " missing element " + - elementName.toString()); + elementName); this.annotationType = annotationType; this.elementName = elementName; diff -r e323c74edabd src/share/classes/java/text/DateFormatSymbols.java --- a/src/share/classes/java/text/DateFormatSymbols.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/text/DateFormatSymbols.java Sat Apr 26 01:40:27 2014 -0300 @@ -593,8 +593,8 @@ * pattern characters. */ public void setLocalPatternChars(String newLocalPatternChars) { - // Call toString() to throw an NPE in case the argument is null - localPatternChars = newLocalPatternChars.toString(); + + localPatternChars = Objects.requireNonNull(newLocalPatternChars); cachedHashCode = 0; } diff -r e323c74edabd src/share/classes/javax/management/modelmbean/DescriptorSupport.java --- a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Sat Apr 26 01:40:27 2014 -0300 @@ -665,7 +665,7 @@ "getFieldNames()", "Field is null"); } } else { - responseFields[i] = currElement.getKey().toString(); + responseFields[i] = currElement.getKey(); } } @@ -929,8 +929,8 @@ if (currElement != null) { if (currElement.getValue() != null) { // validate the field valued... - if (validateField((currElement.getKey()).toString(), - (currElement.getValue()).toString())) { + if (validateField((currElement.getKey()), + (currElement.getValue()))) { continue; } else { if (MODELMBEAN_LOGGER.isLoggable(Level.FINEST)) { diff -r e323c74edabd src/share/classes/javax/swing/text/html/FormView.java --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/swing/text/html/FormView.java Sat Apr 26 01:40:27 2014 -0300 @@ -478,7 +478,7 @@ base.getPort(), base.getFile()) : new URL(base, action); if (!isPostMethod) { - String query = data.toString(); + String query = data; actionURL = new URL(actionURL + "?" + query); } } catch (MalformedURLException e) { diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/Blit.java Sat Apr 26 01:40:27 2014 -0300 @@ -50,7 +50,7 @@ public class Blit extends GraphicsPrimitive { - public static final String methodSignature = "Blit(...)".toString(); + public static final String methodSignature = "Blit(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sat Apr 26 01:40:27 2014 -0300 @@ -54,7 +54,7 @@ */ public class BlitBg extends GraphicsPrimitive { - public static final String methodSignature = "BlitBg(...)".toString(); + public static final String methodSignature = "BlitBg(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphList.java --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sat Apr 26 01:40:27 2014 -0300 @@ -39,7 +39,7 @@ */ public class DrawGlyphList extends GraphicsPrimitive { - public final static String methodSignature = "DrawGlyphList(...)".toString(); + public final static String methodSignature = "DrawGlyphList(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphListAA.java --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sat Apr 26 01:40:27 2014 -0300 @@ -39,7 +39,7 @@ */ public class DrawGlyphListAA extends GraphicsPrimitive { - public final static String methodSignature = "DrawGlyphListAA(...)".toString(); + public final static String methodSignature = "DrawGlyphListAA(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sat Apr 26 01:40:27 2014 -0300 @@ -40,7 +40,7 @@ public class DrawGlyphListLCD extends GraphicsPrimitive { public final static String - methodSignature = "DrawGlyphListLCD(...)".toString(); + methodSignature = "DrawGlyphListLCD(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sat Apr 26 01:40:27 2014 -0300 @@ -44,7 +44,7 @@ */ public class DrawLine extends GraphicsPrimitive { - public final static String methodSignature = "DrawLine(...)".toString(); + public final static String methodSignature = "DrawLine(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawParallelogram.java --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sat Apr 26 01:40:27 2014 -0300 @@ -43,7 +43,7 @@ public class DrawParallelogram extends GraphicsPrimitive { public final static String methodSignature = - "DrawParallelogram(...)".toString(); + "DrawParallelogram(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sat Apr 26 01:40:27 2014 -0300 @@ -39,7 +39,7 @@ public class DrawPath extends GraphicsPrimitive { public final static String methodSignature = - "DrawPath(...)".toString(); + "DrawPath(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPolygons.java --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sat Apr 26 01:40:27 2014 -0300 @@ -41,7 +41,7 @@ */ public class DrawPolygons extends GraphicsPrimitive { - public final static String methodSignature = "DrawPolygons(...)".toString(); + public final static String methodSignature = "DrawPolygons(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sat Apr 26 01:40:27 2014 -0300 @@ -44,7 +44,7 @@ */ public class DrawRect extends GraphicsPrimitive { - public final static String methodSignature = "DrawRect(...)".toString(); + public final static String methodSignature = "DrawRect(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillParallelogram.java --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sat Apr 26 01:40:27 2014 -0300 @@ -41,7 +41,7 @@ public class FillParallelogram extends GraphicsPrimitive { public final static String methodSignature = - "FillParallelogram(...)".toString(); + "FillParallelogram(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sat Apr 26 01:40:27 2014 -0300 @@ -39,7 +39,7 @@ public class FillPath extends GraphicsPrimitive { public final static String methodSignature = - "FillPath(...)".toString(); + "FillPath(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sat Apr 26 01:40:27 2014 -0300 @@ -44,7 +44,7 @@ */ public class FillRect extends GraphicsPrimitive { - public final static String methodSignature = "FillRect(...)".toString(); + public final static String methodSignature = "FillRect(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sat Apr 26 01:40:27 2014 -0300 @@ -45,7 +45,7 @@ */ public class FillSpans extends GraphicsPrimitive { - public final static String methodSignature = "FillSpans(...)".toString(); + public final static String methodSignature = "FillSpans(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sat Apr 26 01:40:27 2014 -0300 @@ -48,7 +48,7 @@ public class MaskBlit extends GraphicsPrimitive { - public static final String methodSignature = "MaskBlit(...)".toString(); + public static final String methodSignature = "MaskBlit(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sat Apr 26 01:40:27 2014 -0300 @@ -50,11 +50,11 @@ */ public class MaskFill extends GraphicsPrimitive { - public static final String methodSignature = "MaskFill(...)".toString(); + public static final String methodSignature = "MaskFill(...)"; public static final String fillPgramSignature = - "FillAAPgram(...)".toString(); + "FillAAPgram(...)"; public static final String drawPgramSignature = - "DrawAAPgram(...)".toString(); + "DrawAAPgram(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sat Apr 26 01:40:27 2014 -0300 @@ -45,7 +45,7 @@ public class ScaledBlit extends GraphicsPrimitive { - public static final String methodSignature = "ScaledBlit(...)".toString(); + public static final String methodSignature = "ScaledBlit(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/TransformBlit.java --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sat Apr 26 01:40:27 2014 -0300 @@ -47,7 +47,7 @@ public class TransformBlit extends GraphicsPrimitive { public static final String methodSignature = - "TransformBlit(...)".toString(); + "TransformBlit(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/TransformHelper.java --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sat Apr 26 01:40:27 2014 -0300 @@ -46,7 +46,7 @@ public class TransformHelper extends GraphicsPrimitive { public static final String methodSignature = - "TransformHelper(...)".toString(); + "TransformHelper(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sat Apr 26 01:40:27 2014 -0300 @@ -260,11 +260,11 @@ // Convert token into meaning number for comparision if (stk.hasMoreTokens()) - n = convertToken(stk.nextToken().toString()); + n = convertToken(stk.nextToken()); // Convert token into meaning number for comparision if (ttk.hasMoreTokens()) - m = convertToken(ttk.nextToken().toString()); + m = convertToken(ttk.nextToken()); if (n > m) return 1; diff -r e323c74edabd src/share/classes/sun/tools/jconsole/inspector/Utils.java --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat Apr 26 01:40:27 2014 -0300 @@ -378,7 +378,7 @@ if (userInput instanceof XObject) { result[i] = ((XObject) userInput).getObject(); } else { - result[i] = createObjectFromString(params[i].toString(), + result[i] = createObjectFromString(params[i], (String) userInput); } } -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From otaviojava at java.net Sun Apr 27 17:41:13 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Sun, 27 Apr 2014 14:41:13 -0300 Subject: Remove redundant calls of toString() In-Reply-To: <535D2BCB.8090707@univ-mlv.fr> References: <535D2BCB.8090707@univ-mlv.fr> Message-ID: sorry. I tried answer and the message was twice. But Yes when has null pointer possibility I replaced to Objects.requireNonNull. I am review the code again. The code below: diff -r e323c74edabd src/share/classes/com/sun/tools/example/debug/tty/Commands.java --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sun Apr 27 14:33:45 2014 -0300 @@ -1653,20 +1653,20 @@ String expr = t.nextToken(""); Value val = evaluate(expr); if (val == null) { - MessageOutput.println("expr is null", expr.toString()); + MessageOutput.println("expr is null",Objects.requireNonNull(expr)); } else if (dumpObject && (val instanceof ObjectReference) && !(val instanceof StringReference)) { ObjectReference obj = (ObjectReference)val; ReferenceType refType = obj.referenceType(); MessageOutput.println("expr is value", - new Object [] {expr.toString(), + new Object [] {Objects.requireNonNull(expr), MessageOutput.format("grouping begin character")}); dump(obj, refType, refType); MessageOutput.println("grouping end character"); } else { String strVal = getStringValue(); if (strVal != null) { - MessageOutput.println("expr is value", new Object [] {expr.toString(), + MessageOutput.println("expr is value", new Object [] {Objects.requireNonNull(expr), strVal}); } } diff -r e323c74edabd src/share/classes/java/lang/annotation/IncompleteAnnotationException.java --- a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java Sun Apr 27 14:33:45 2014 -0300 @@ -25,6 +25,8 @@ package java.lang.annotation; +import java.util.Objects; + /** * Thrown to indicate that a program has attempted to access an element of * an annotation type that was added to the annotation type definition after @@ -56,7 +58,7 @@ Class annotationType, String elementName) { super(annotationType.getName() + " missing element " + - elementName.toString()); + Objects.requireNonNull(elementName)); this.annotationType = annotationType; this.elementName = elementName; diff -r e323c74edabd src/share/classes/java/text/DateFormatSymbols.java --- a/src/share/classes/java/text/DateFormatSymbols.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/java/text/DateFormatSymbols.java Sun Apr 27 14:33:45 2014 -0300 @@ -594,7 +594,7 @@ */ public void setLocalPatternChars(String newLocalPatternChars) { // Call toString() to throw an NPE in case the argument is null - localPatternChars = newLocalPatternChars.toString(); + localPatternChars = Objects.requireNonNull(newLocalPatternChars); cachedHashCode = 0; } diff -r e323c74edabd src/share/classes/javax/management/modelmbean/DescriptorSupport.java --- a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Sun Apr 27 14:33:45 2014 -0300 @@ -43,13 +43,7 @@ import java.lang.reflect.Constructor; import java.security.AccessController; -import java.util.HashMap; -import java.util.Iterator; -import java.util.Map; -import java.util.Set; -import java.util.SortedMap; -import java.util.StringTokenizer; -import java.util.TreeMap; +import java.util.*; import java.util.logging.Level; import javax.management.Descriptor; @@ -665,7 +659,7 @@ "getFieldNames()", "Field is null"); } } else { - responseFields[i] = currElement.getKey().toString(); + responseFields[i] = Objects.requireNonNull(currElement.getKey()); } } @@ -929,7 +923,7 @@ if (currElement != null) { if (currElement.getValue() != null) { // validate the field valued... - if (validateField((currElement.getKey()).toString(), + if (validateField((Objects.requireNonNull(currElement.getKey())), (currElement.getValue()).toString())) { continue; } else { diff -r e323c74edabd src/share/classes/javax/swing/text/html/FormView.java --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/swing/text/html/FormView.java Sun Apr 27 14:33:45 2014 -0300 @@ -478,7 +478,7 @@ base.getPort(), base.getFile()) : new URL(base, action); if (!isPostMethod) { - String query = data.toString(); + String query = Objects.requireNonNull(data); actionURL = new URL(actionURL + "?" + query); } } catch (MalformedURLException e) { diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/Blit.java Sun Apr 27 14:33:45 2014 -0300 @@ -50,7 +50,7 @@ public class Blit extends GraphicsPrimitive { - public static final String methodSignature = "Blit(...)".toString(); + public static final String methodSignature = "Blit(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sun Apr 27 14:33:45 2014 -0300 @@ -54,7 +54,7 @@ */ public class BlitBg extends GraphicsPrimitive { - public static final String methodSignature = "BlitBg(...)".toString(); + public static final String methodSignature = "BlitBg(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphList.java --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sun Apr 27 14:33:45 2014 -0300 @@ -39,7 +39,7 @@ */ public class DrawGlyphList extends GraphicsPrimitive { - public final static String methodSignature = "DrawGlyphList(...)".toString(); + public final static String methodSignature = "DrawGlyphList(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphListAA.java --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sun Apr 27 14:33:45 2014 -0300 @@ -39,7 +39,7 @@ */ public class DrawGlyphListAA extends GraphicsPrimitive { - public final static String methodSignature = "DrawGlyphListAA(...)".toString(); + public final static String methodSignature = "DrawGlyphListAA(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sun Apr 27 14:33:45 2014 -0300 @@ -40,7 +40,7 @@ public class DrawGlyphListLCD extends GraphicsPrimitive { public final static String - methodSignature = "DrawGlyphListLCD(...)".toString(); + methodSignature = "DrawGlyphListLCD(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sun Apr 27 14:33:45 2014 -0300 @@ -44,7 +44,7 @@ */ public class DrawLine extends GraphicsPrimitive { - public final static String methodSignature = "DrawLine(...)".toString(); + public final static String methodSignature = "DrawLine(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawParallelogram.java --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sun Apr 27 14:33:45 2014 -0300 @@ -43,7 +43,7 @@ public class DrawParallelogram extends GraphicsPrimitive { public final static String methodSignature = - "DrawParallelogram(...)".toString(); + "DrawParallelogram(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sun Apr 27 14:33:45 2014 -0300 @@ -39,7 +39,7 @@ public class DrawPath extends GraphicsPrimitive { public final static String methodSignature = - "DrawPath(...)".toString(); + "DrawPath(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPolygons.java --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sun Apr 27 14:33:45 2014 -0300 @@ -41,7 +41,7 @@ */ public class DrawPolygons extends GraphicsPrimitive { - public final static String methodSignature = "DrawPolygons(...)".toString(); + public final static String methodSignature = "DrawPolygons(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sun Apr 27 14:33:45 2014 -0300 @@ -44,7 +44,7 @@ */ public class DrawRect extends GraphicsPrimitive { - public final static String methodSignature = "DrawRect(...)".toString(); + public final static String methodSignature = "DrawRect(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillParallelogram.java --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sun Apr 27 14:33:45 2014 -0300 @@ -41,7 +41,7 @@ public class FillParallelogram extends GraphicsPrimitive { public final static String methodSignature = - "FillParallelogram(...)".toString(); + "FillParallelogram(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sun Apr 27 14:33:45 2014 -0300 @@ -39,7 +39,7 @@ public class FillPath extends GraphicsPrimitive { public final static String methodSignature = - "FillPath(...)".toString(); + "FillPath(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sun Apr 27 14:33:45 2014 -0300 @@ -44,7 +44,7 @@ */ public class FillRect extends GraphicsPrimitive { - public final static String methodSignature = "FillRect(...)".toString(); + public final static String methodSignature = "FillRect(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sun Apr 27 14:33:45 2014 -0300 @@ -45,7 +45,7 @@ */ public class FillSpans extends GraphicsPrimitive { - public final static String methodSignature = "FillSpans(...)".toString(); + public final static String methodSignature = "FillSpans(...)"; public final static int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sun Apr 27 14:33:45 2014 -0300 @@ -48,7 +48,7 @@ public class MaskBlit extends GraphicsPrimitive { - public static final String methodSignature = "MaskBlit(...)".toString(); + public static final String methodSignature = "MaskBlit(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sun Apr 27 14:33:45 2014 -0300 @@ -50,11 +50,11 @@ */ public class MaskFill extends GraphicsPrimitive { - public static final String methodSignature = "MaskFill(...)".toString(); + public static final String methodSignature = "MaskFill(...)"; public static final String fillPgramSignature = - "FillAAPgram(...)".toString(); + "FillAAPgram(...)"; public static final String drawPgramSignature = - "DrawAAPgram(...)".toString(); + "DrawAAPgram(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sun Apr 27 14:33:45 2014 -0300 @@ -45,7 +45,7 @@ public class ScaledBlit extends GraphicsPrimitive { - public static final String methodSignature = "ScaledBlit(...)".toString(); + public static final String methodSignature = "ScaledBlit(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/TransformBlit.java --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sun Apr 27 14:33:45 2014 -0300 @@ -47,7 +47,7 @@ public class TransformBlit extends GraphicsPrimitive { public static final String methodSignature = - "TransformBlit(...)".toString(); + "TransformBlit(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/java2d/loops/TransformHelper.java --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sun Apr 27 14:33:45 2014 -0300 @@ -46,7 +46,7 @@ public class TransformHelper extends GraphicsPrimitive { public static final String methodSignature = - "TransformHelper(...)".toString(); + "TransformHelper(...)"; public static final int primTypeID = makePrimTypeID(); diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sun Apr 27 14:33:45 2014 -0300 @@ -25,6 +25,7 @@ package sun.misc; +import java.util.Objects; import java.util.StringTokenizer; import java.util.jar.Attributes; import java.util.jar.Attributes.Name; @@ -260,11 +261,11 @@ // Convert token into meaning number for comparision if (stk.hasMoreTokens()) - n = convertToken(stk.nextToken().toString()); + n = convertToken(Objects.requireNonNull(stk.nextToken())); // Convert token into meaning number for comparision if (ttk.hasMoreTokens()) - m = convertToken(ttk.nextToken().toString()); + m = convertToken(Objects.requireNonNull(ttk.nextToken())); if (n > m) return 1; diff -r e323c74edabd src/share/classes/sun/tools/jconsole/inspector/Utils.java --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sun Apr 27 14:33:45 2014 -0300 @@ -378,7 +378,7 @@ if (userInput instanceof XObject) { result[i] = ((XObject) userInput).getObject(); } else { - result[i] = createObjectFromString(params[i].toString(), + result[i] = createObjectFromString(Objects.requireNonNull(params[i]), (String) userInput); } } On Sun, Apr 27, 2014 at 1:09 PM, Remi Forax wrote: > On 04/27/2014 03:15 PM, Ot?vio Gon?alves de Santana wrote: > >> There is an issue that was opened to remove redundant calls of toString() >> on String objects. [1] >> I went deep on all JVM sources and I found all, 32 changes. >> >> >> [1]https://bugs.openjdk.java.net/browse/JDK-8015470 >> > > Otavio, > calling toString() on a String has the side effect to implicitly check > that the reference is not null. > Do you have checked that for each redundant call, the String can never be > null ? > > regards, > R?mi > > > >> >> diff -r e323c74edabd >> src/share/classes/com/sun/tools/example/debug/tty/Commands.java >> --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed >> Apr 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sat >> Apr 26 01:40:27 2014 -0300 >> @@ -1653,20 +1653,20 @@ >> String expr = t.nextToken(""); >> Value val = evaluate(expr); >> if (val == null) { >> - MessageOutput.println("expr is null", expr.toString()); >> + MessageOutput.println("expr is null", expr); >> } else if (dumpObject && (val instanceof ObjectReference) && >> !(val instanceof StringReference)) { >> ObjectReference obj = (ObjectReference)val; >> ReferenceType refType = obj.referenceType(); >> MessageOutput.println("expr is value", >> - new Object [] {expr.toString(), >> + new Object [] {expr, >> >> MessageOutput.format("grouping begin character")}); >> dump(obj, refType, refType); >> MessageOutput.println("grouping end character"); >> } else { >> String strVal = getStringValue(); >> if (strVal != null) { >> - MessageOutput.println("expr is value", new Object [] >> {expr.toString(), >> + MessageOutput.println("expr is value", new Object [] >> {expr, >> >> strVal}); >> } >> } >> diff -r e323c74edabd >> src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> --- >> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> Sat >> Apr 26 01:40:27 2014 -0300 >> @@ -56,7 +56,7 @@ >> Class annotationType, >> String elementName) { >> super(annotationType.getName() + " missing element " + >> - elementName.toString()); >> + elementName); >> >> this.annotationType = annotationType; >> this.elementName = elementName; >> diff -r e323c74edabd src/share/classes/java/text/DateFormatSymbols.java >> --- a/src/share/classes/java/text/DateFormatSymbols.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/java/text/DateFormatSymbols.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -593,8 +593,8 @@ >> * pattern characters. >> */ >> public void setLocalPatternChars(String newLocalPatternChars) { >> - // Call toString() to throw an NPE in case the argument is null >> - localPatternChars = newLocalPatternChars.toString(); >> + >> + localPatternChars = Objects.requireNonNull( >> newLocalPatternChars); >> cachedHashCode = 0; >> } >> >> diff -r e323c74edabd >> src/share/classes/javax/management/modelmbean/DescriptorSupport.java >> --- a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java >> Sat >> Apr 26 01:40:27 2014 -0300 >> @@ -665,7 +665,7 @@ >> "getFieldNames()", "Field is null"); >> } >> } else { >> - responseFields[i] = currElement.getKey().toString(); >> + responseFields[i] = currElement.getKey(); >> } >> } >> >> @@ -929,8 +929,8 @@ >> if (currElement != null) { >> if (currElement.getValue() != null) { >> // validate the field valued... >> - if (validateField((currElement.getKey()).toString(), >> - >> (currElement.getValue()).toString())) { >> + if (validateField((currElement.getKey()), >> + (currElement.getValue()))) { >> continue; >> } else { >> if (MODELMBEAN_LOGGER.isLoggable(Level.FINEST)) >> { >> diff -r e323c74edabd src/share/classes/javax/swing/ >> text/html/FormView.java >> --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/javax/swing/text/html/FormView.java Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -478,7 +478,7 @@ >> base.getPort(), base.getFile()) >> : new URL(base, action); >> if (!isPostMethod) { >> - String query = data.toString(); >> + String query = data; >> actionURL = new URL(actionURL + "?" + query); >> } >> } catch (MalformedURLException e) { >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java >> --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 >> 2014 >> -0700 >> +++ b/src/share/classes/sun/java2d/loops/Blit.java Sat Apr 26 01:40:27 >> 2014 >> -0300 >> @@ -50,7 +50,7 @@ >> >> public class Blit extends GraphicsPrimitive >> { >> - public static final String methodSignature = "Blit(...)".toString(); >> + public static final String methodSignature = "Blit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java >> --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sat Apr 26 01:40:27 >> 2014 -0300 >> @@ -54,7 +54,7 @@ >> */ >> public class BlitBg extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "BlitBg(...)".toString(); >> + public static final String methodSignature = "BlitBg(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/ >> loops/DrawGlyphList.java >> --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -39,7 +39,7 @@ >> */ >> public class DrawGlyphList extends GraphicsPrimitive { >> >> - public final static String methodSignature = >> "DrawGlyphList(...)".toString(); >> + public final static String methodSignature = "DrawGlyphList(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/ >> loops/DrawGlyphListAA.java >> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -39,7 +39,7 @@ >> */ >> public class DrawGlyphListAA extends GraphicsPrimitive { >> >> - public final static String methodSignature = >> "DrawGlyphListAA(...)".toString(); >> + public final static String methodSignature = "DrawGlyphListAA(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java >> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -40,7 +40,7 @@ >> public class DrawGlyphListLCD extends GraphicsPrimitive { >> >> public final static String >> - methodSignature = "DrawGlyphListLCD(...)".toString(); >> + methodSignature = "DrawGlyphListLCD(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java >> --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class DrawLine extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawLine(...)".toString(); >> + public final static String methodSignature = "DrawLine(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/DrawParallelogram.java >> --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed Apr >> 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sat Apr >> 26 >> 01:40:27 2014 -0300 >> @@ -43,7 +43,7 @@ >> public class DrawParallelogram extends GraphicsPrimitive >> { >> public final static String methodSignature = >> - "DrawParallelogram(...)".toString(); >> + "DrawParallelogram(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java >> --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -39,7 +39,7 @@ >> public class DrawPath extends GraphicsPrimitive { >> >> public final static String methodSignature = >> - "DrawPath(...)".toString(); >> + "DrawPath(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPolygons.java >> --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -41,7 +41,7 @@ >> */ >> public class DrawPolygons extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawPolygons(...)".toString(); >> + public final static String methodSignature = "DrawPolygons(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java >> --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class DrawRect extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawRect(...)".toString(); >> + public final static String methodSignature = "DrawRect(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/FillParallelogram.java >> --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed Apr >> 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sat Apr >> 26 >> 01:40:27 2014 -0300 >> @@ -41,7 +41,7 @@ >> public class FillParallelogram extends GraphicsPrimitive >> { >> public final static String methodSignature = >> - "FillParallelogram(...)".toString(); >> + "FillParallelogram(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java >> --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -39,7 +39,7 @@ >> public class FillPath extends GraphicsPrimitive { >> >> public final static String methodSignature = >> - "FillPath(...)".toString(); >> + "FillPath(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java >> --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class FillRect extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "FillRect(...)".toString(); >> + public final static String methodSignature = "FillRect(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java >> --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -45,7 +45,7 @@ >> */ >> public class FillSpans extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "FillSpans(...)".toString(); >> + public final static String methodSignature = "FillSpans(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java >> --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -48,7 +48,7 @@ >> >> public class MaskBlit extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "MaskBlit(...)".toString(); >> + public static final String methodSignature = "MaskBlit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java >> --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -50,11 +50,11 @@ >> */ >> public class MaskFill extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "MaskFill(...)".toString(); >> + public static final String methodSignature = "MaskFill(...)"; >> public static final String fillPgramSignature = >> - "FillAAPgram(...)".toString(); >> + "FillAAPgram(...)"; >> public static final String drawPgramSignature = >> - "DrawAAPgram(...)".toString(); >> + "DrawAAPgram(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java >> --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -45,7 +45,7 @@ >> >> public class ScaledBlit extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "ScaledBlit(...)".toString(); >> + public static final String methodSignature = "ScaledBlit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/ >> loops/TransformBlit.java >> --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -47,7 +47,7 @@ >> public class TransformBlit extends GraphicsPrimitive >> { >> public static final String methodSignature = >> - "TransformBlit(...)".toString(); >> + "TransformBlit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/ >> loops/TransformHelper.java >> --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -46,7 +46,7 @@ >> public class TransformHelper extends GraphicsPrimitive >> { >> public static final String methodSignature = >> - "TransformHelper(...)".toString(); >> + "TransformHelper(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java >> --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sat Apr 26 01:40:27 >> 2014 -0300 >> @@ -260,11 +260,11 @@ >> >> // Convert token into meaning number for comparision >> if (stk.hasMoreTokens()) >> - n = convertToken(stk.nextToken().toString()); >> + n = convertToken(stk.nextToken()); >> >> // Convert token into meaning number for comparision >> if (ttk.hasMoreTokens()) >> - m = convertToken(ttk.nextToken().toString()); >> + m = convertToken(ttk.nextToken()); >> >> if (n > m) >> return 1; >> diff -r e323c74edabd >> src/share/classes/sun/tools/jconsole/inspector/Utils.java >> --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr >> 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat Apr >> 26 >> 01:40:27 2014 -0300 >> @@ -378,7 +378,7 @@ >> if (userInput instanceof XObject) { >> result[i] = ((XObject) userInput).getObject(); >> } else { >> - result[i] = createObjectFromString(params[i].toString(), >> + result[i] = createObjectFromString(params[i], >> (String) userInput); >> } >> } >> >> >> > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From richard.warburton at gmail.com Sun Apr 27 23:08:28 2014 From: richard.warburton at gmail.com (Richard Warburton) Date: Mon, 28 Apr 2014 00:08:28 +0100 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <535689DC.6060907@redhat.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53559572.2080004@redhat.com> <535633C2.5090501@gmail.com> <5356650F.5020909@redhat.com> <53568254.3010106@gmail.com> <535689DC.6060907@redhat.com> Message-ID: Hi, There are multiple possible targets for invokevirtual >> position:(I)Ljava/nio/Buffer; - all the methods that override it in all >> subclasses loaded. It doesn't matter if they are final or not (only if >> they are effectively final or not). The non-finality of a method has a >> performance impact only if the method *is* overridden in any of the >> loaded subclasses, otherwise it is effectively final and treated as such >> by JIT (at least that's how I understand it - any hotspot JIT expert >> please debunk my claims). >> > > That is only true if you are calling the method on the base class, which > is normally seldom done (though it will be nearly always in legacy code, > but see below). > > That might also be the answer to why the synthetic method need not be >> marked as final if the covariant method is. The synthetic method can >> never be overridden in a sub-class (at least not by javac) - only the >> covariant method can be. >> > > Doesn't sound quite right to me, but I'll defer to any experts who might > wish to discuss it on compiler-dev. > > > But as Paul noted, the methods on Buffer are probably not used in hot >> loops alone, since they are just for reading/adjusting >> position/limit/mark. The hot loops probably also contain methods for >> reading/writing the buffer and those are only defined on particular >> sub-types of java.nio.Buffer, so it can reasonably be expected that the >> static (guaranteed) type of target upon which methods are called in hot >> loops is a particular subtype of java.nio.Buffer and JIT only has one >> method to choose from in this case. >> > > Yeah new code will call the covariant final method directly in almost all > cases for sure, having been compiled against it. The tricky case is old > code - even if the JIT can figure out that it is really a subclass being > invoked upon, it'd still be forced to target the non-covariant synthetic > method due to the specific method reference in the bytecode. Hopefully at > this point though, as you say, the lack of overriding classes will be > enough to optimize the dispatch. > So interestingly the original patch didn't add final to the covariant overrides. I've updated the patch to do this. http://cr.openjdk.java.net/~rwarburton/buffer-overrides-1/ I'm not sure what would satisfy people on the performance front. Some guidance would be most appreciated here. regards, Richard Warburton http://insightfullogic.com @RichardWarburto From david.holmes at oracle.com Mon Apr 28 02:33:53 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Apr 2014 12:33:53 +1000 Subject: Remove redundant calls of toString() In-Reply-To: References: <535D2BCB.8090707@univ-mlv.fr> Message-ID: <535DBE11.2000303@oracle.com> On 28/04/2014 3:41 AM, Ot?vio Gon?alves de Santana wrote: > sorry. > I tried answer and the message was twice. > But Yes when has null pointer possibility I replaced to > Objects.requireNonNull. In my opinion that is making the code worse not better. David ----- > I am review the code again. > The code below: > > diff -r e323c74edabd > src/share/classes/com/sun/tools/example/debug/tty/Commands.java > --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sun > Apr 27 14:33:45 2014 -0300 > @@ -1653,20 +1653,20 @@ > String expr = t.nextToken(""); > Value val = evaluate(expr); > if (val == null) { > - MessageOutput.println("expr is null", expr.toString()); > + MessageOutput.println("expr is > null",Objects.requireNonNull(expr)); > } else if (dumpObject && (val instanceof ObjectReference) && > !(val instanceof StringReference)) { > ObjectReference obj = (ObjectReference)val; > ReferenceType refType = obj.referenceType(); > MessageOutput.println("expr is value", > - new Object [] {expr.toString(), > + new Object [] > {Objects.requireNonNull(expr), > > MessageOutput.format("grouping begin character")}); > dump(obj, refType, refType); > MessageOutput.println("grouping end character"); > } else { > String strVal = getStringValue(); > if (strVal != null) { > - MessageOutput.println("expr is value", new Object [] > {expr.toString(), > + MessageOutput.println("expr is value", new Object [] > {Objects.requireNonNull(expr), > > strVal}); > } > } > diff -r e323c74edabd > src/share/classes/java/lang/annotation/IncompleteAnnotationException.java > --- > a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java Wed > Apr 23 11:35:40 2014 -0700 > +++ > b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java Sun > Apr 27 14:33:45 2014 -0300 > @@ -25,6 +25,8 @@ > > package java.lang.annotation; > > +import java.util.Objects; > + > /** > * Thrown to indicate that a program has attempted to access an element of > * an annotation type that was added to the annotation type definition > after > @@ -56,7 +58,7 @@ > Class annotationType, > String elementName) { > super(annotationType.getName() + " missing element " + > - elementName.toString()); > + Objects.requireNonNull(elementName)); > > this.annotationType = annotationType; > this.elementName = elementName; > diff -r e323c74edabd src/share/classes/java/text/DateFormatSymbols.java > --- a/src/share/classes/java/text/DateFormatSymbols.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/java/text/DateFormatSymbols.java Sun Apr 27 > 14:33:45 2014 -0300 > @@ -594,7 +594,7 @@ > */ > public void setLocalPatternChars(String newLocalPatternChars) { > // Call toString() to throw an NPE in case the argument is null > - localPatternChars = newLocalPatternChars.toString(); > + localPatternChars = Objects.requireNonNull(newLocalPatternChars); > cachedHashCode = 0; > } > > diff -r e323c74edabd > src/share/classes/javax/management/modelmbean/DescriptorSupport.java > --- a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Wed > Apr 23 11:35:40 2014 -0700 > +++ b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java Sun > Apr 27 14:33:45 2014 -0300 > @@ -43,13 +43,7 @@ > import java.lang.reflect.Constructor; > > import java.security.AccessController; > -import java.util.HashMap; > -import java.util.Iterator; > -import java.util.Map; > -import java.util.Set; > -import java.util.SortedMap; > -import java.util.StringTokenizer; > -import java.util.TreeMap; > +import java.util.*; > import java.util.logging.Level; > > import javax.management.Descriptor; > @@ -665,7 +659,7 @@ > "getFieldNames()", "Field is null"); > } > } else { > - responseFields[i] = currElement.getKey().toString(); > + responseFields[i] = > Objects.requireNonNull(currElement.getKey()); > } > } > > @@ -929,7 +923,7 @@ > if (currElement != null) { > if (currElement.getValue() != null) { > // validate the field valued... > - if (validateField((currElement.getKey()).toString(), > + if > (validateField((Objects.requireNonNull(currElement.getKey())), > > (currElement.getValue()).toString())) { > continue; > } else { > diff -r e323c74edabd src/share/classes/javax/swing/text/html/FormView.java > --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/javax/swing/text/html/FormView.java Sun Apr 27 > 14:33:45 2014 -0300 > @@ -478,7 +478,7 @@ > base.getPort(), base.getFile()) > : new URL(base, action); > if (!isPostMethod) { > - String query = data.toString(); > + String query = Objects.requireNonNull(data); > actionURL = new URL(actionURL + "?" + query); > } > } catch (MalformedURLException e) { > diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java > --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 2014 > -0700 > +++ b/src/share/classes/sun/java2d/loops/Blit.java Sun Apr 27 14:33:45 2014 > -0300 > @@ -50,7 +50,7 @@ > > public class Blit extends GraphicsPrimitive > { > - public static final String methodSignature = "Blit(...)".toString(); > + public static final String methodSignature = "Blit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java > --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sun Apr 27 14:33:45 > 2014 -0300 > @@ -54,7 +54,7 @@ > */ > public class BlitBg extends GraphicsPrimitive > { > - public static final String methodSignature = "BlitBg(...)".toString(); > + public static final String methodSignature = "BlitBg(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphList.java > --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sun Apr 27 > 14:33:45 2014 -0300 > @@ -39,7 +39,7 @@ > */ > public class DrawGlyphList extends GraphicsPrimitive { > > - public final static String methodSignature = > "DrawGlyphList(...)".toString(); > + public final static String methodSignature = "DrawGlyphList(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphListAA.java > --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sun Apr 27 > 14:33:45 2014 -0300 > @@ -39,7 +39,7 @@ > */ > public class DrawGlyphListAA extends GraphicsPrimitive { > > - public final static String methodSignature = > "DrawGlyphListAA(...)".toString(); > + public final static String methodSignature = "DrawGlyphListAA(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java > --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sun Apr 27 > 14:33:45 2014 -0300 > @@ -40,7 +40,7 @@ > public class DrawGlyphListLCD extends GraphicsPrimitive { > > public final static String > - methodSignature = "DrawGlyphListLCD(...)".toString(); > + methodSignature = "DrawGlyphListLCD(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java > --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sun Apr 27 14:33:45 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class DrawLine extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawLine(...)".toString(); > + public final static String methodSignature = "DrawLine(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/loops/DrawParallelogram.java > --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sun Apr 27 > 14:33:45 2014 -0300 > @@ -43,7 +43,7 @@ > public class DrawParallelogram extends GraphicsPrimitive > { > public final static String methodSignature = > - "DrawParallelogram(...)".toString(); > + "DrawParallelogram(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java > --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sun Apr 27 14:33:45 > 2014 -0300 > @@ -39,7 +39,7 @@ > public class DrawPath extends GraphicsPrimitive { > > public final static String methodSignature = > - "DrawPath(...)".toString(); > + "DrawPath(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPolygons.java > --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sun Apr 27 > 14:33:45 2014 -0300 > @@ -41,7 +41,7 @@ > */ > public class DrawPolygons extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawPolygons(...)".toString(); > + public final static String methodSignature = "DrawPolygons(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java > --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sun Apr 27 14:33:45 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class DrawRect extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawRect(...)".toString(); > + public final static String methodSignature = "DrawRect(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/loops/FillParallelogram.java > --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sun Apr 27 > 14:33:45 2014 -0300 > @@ -41,7 +41,7 @@ > public class FillParallelogram extends GraphicsPrimitive > { > public final static String methodSignature = > - "FillParallelogram(...)".toString(); > + "FillParallelogram(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java > --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sun Apr 27 14:33:45 > 2014 -0300 > @@ -39,7 +39,7 @@ > public class FillPath extends GraphicsPrimitive { > > public final static String methodSignature = > - "FillPath(...)".toString(); > + "FillPath(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java > --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sun Apr 27 14:33:45 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class FillRect extends GraphicsPrimitive > { > - public final static String methodSignature = > "FillRect(...)".toString(); > + public final static String methodSignature = "FillRect(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java > --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sun Apr 27 14:33:45 > 2014 -0300 > @@ -45,7 +45,7 @@ > */ > public class FillSpans extends GraphicsPrimitive > { > - public final static String methodSignature = > "FillSpans(...)".toString(); > + public final static String methodSignature = "FillSpans(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java > --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sun Apr 27 14:33:45 > 2014 -0300 > @@ -48,7 +48,7 @@ > > public class MaskBlit extends GraphicsPrimitive > { > - public static final String methodSignature = > "MaskBlit(...)".toString(); > + public static final String methodSignature = "MaskBlit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java > --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sun Apr 27 14:33:45 > 2014 -0300 > @@ -50,11 +50,11 @@ > */ > public class MaskFill extends GraphicsPrimitive > { > - public static final String methodSignature = > "MaskFill(...)".toString(); > + public static final String methodSignature = "MaskFill(...)"; > public static final String fillPgramSignature = > - "FillAAPgram(...)".toString(); > + "FillAAPgram(...)"; > public static final String drawPgramSignature = > - "DrawAAPgram(...)".toString(); > + "DrawAAPgram(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java > --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sun Apr 27 > 14:33:45 2014 -0300 > @@ -45,7 +45,7 @@ > > public class ScaledBlit extends GraphicsPrimitive > { > - public static final String methodSignature = > "ScaledBlit(...)".toString(); > + public static final String methodSignature = "ScaledBlit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/TransformBlit.java > --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sun Apr 27 > 14:33:45 2014 -0300 > @@ -47,7 +47,7 @@ > public class TransformBlit extends GraphicsPrimitive > { > public static final String methodSignature = > - "TransformBlit(...)".toString(); > + "TransformBlit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/TransformHelper.java > --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sun Apr 27 > 14:33:45 2014 -0300 > @@ -46,7 +46,7 @@ > public class TransformHelper extends GraphicsPrimitive > { > public static final String methodSignature = > - "TransformHelper(...)".toString(); > + "TransformHelper(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java > --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sun Apr 27 14:33:45 > 2014 -0300 > @@ -25,6 +25,7 @@ > > package sun.misc; > > +import java.util.Objects; > import java.util.StringTokenizer; > import java.util.jar.Attributes; > import java.util.jar.Attributes.Name; > @@ -260,11 +261,11 @@ > > // Convert token into meaning number for comparision > if (stk.hasMoreTokens()) > - n = convertToken(stk.nextToken().toString()); > + n = convertToken(Objects.requireNonNull(stk.nextToken())); > > // Convert token into meaning number for comparision > if (ttk.hasMoreTokens()) > - m = convertToken(ttk.nextToken().toString()); > + m = convertToken(Objects.requireNonNull(ttk.nextToken())); > > if (n > m) > return 1; > diff -r e323c74edabd > src/share/classes/sun/tools/jconsole/inspector/Utils.java > --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sun Apr 27 > 14:33:45 2014 -0300 > @@ -378,7 +378,7 @@ > if (userInput instanceof XObject) { > result[i] = ((XObject) userInput).getObject(); > } else { > - result[i] = createObjectFromString(params[i].toString(), > + result[i] = > createObjectFromString(Objects.requireNonNull(params[i]), > (String) userInput); > } > } > > > > > On Sun, Apr 27, 2014 at 1:09 PM, Remi Forax wrote: > >> On 04/27/2014 03:15 PM, Ot?vio Gon?alves de Santana wrote: >> >>> There is an issue that was opened to remove redundant calls of toString() >>> on String objects. [1] >>> I went deep on all JVM sources and I found all, 32 changes. >>> >>> >>> [1]https://bugs.openjdk.java.net/browse/JDK-8015470 >>> >> >> Otavio, >> calling toString() on a String has the side effect to implicitly check >> that the reference is not null. >> Do you have checked that for each redundant call, the String can never be >> null ? >> >> regards, >> R?mi >> >> >> >>> >>> diff -r e323c74edabd >>> src/share/classes/com/sun/tools/example/debug/tty/Commands.java >>> --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sat >>> Apr 26 01:40:27 2014 -0300 >>> @@ -1653,20 +1653,20 @@ >>> String expr = t.nextToken(""); >>> Value val = evaluate(expr); >>> if (val == null) { >>> - MessageOutput.println("expr is null", expr.toString()); >>> + MessageOutput.println("expr is null", expr); >>> } else if (dumpObject && (val instanceof ObjectReference) && >>> !(val instanceof StringReference)) { >>> ObjectReference obj = (ObjectReference)val; >>> ReferenceType refType = obj.referenceType(); >>> MessageOutput.println("expr is value", >>> - new Object [] {expr.toString(), >>> + new Object [] {expr, >>> >>> MessageOutput.format("grouping begin character")}); >>> dump(obj, refType, refType); >>> MessageOutput.println("grouping end character"); >>> } else { >>> String strVal = getStringValue(); >>> if (strVal != null) { >>> - MessageOutput.println("expr is value", new Object [] >>> {expr.toString(), >>> + MessageOutput.println("expr is value", new Object [] >>> {expr, >>> >>> strVal}); >>> } >>> } >>> diff -r e323c74edabd >>> src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>> --- >>> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>> Sat >>> Apr 26 01:40:27 2014 -0300 >>> @@ -56,7 +56,7 @@ >>> Class annotationType, >>> String elementName) { >>> super(annotationType.getName() + " missing element " + >>> - elementName.toString()); >>> + elementName); >>> >>> this.annotationType = annotationType; >>> this.elementName = elementName; >>> diff -r e323c74edabd src/share/classes/java/text/DateFormatSymbols.java >>> --- a/src/share/classes/java/text/DateFormatSymbols.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/java/text/DateFormatSymbols.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -593,8 +593,8 @@ >>> * pattern characters. >>> */ >>> public void setLocalPatternChars(String newLocalPatternChars) { >>> - // Call toString() to throw an NPE in case the argument is null >>> - localPatternChars = newLocalPatternChars.toString(); >>> + >>> + localPatternChars = Objects.requireNonNull( >>> newLocalPatternChars); >>> cachedHashCode = 0; >>> } >>> >>> diff -r e323c74edabd >>> src/share/classes/javax/management/modelmbean/DescriptorSupport.java >>> --- a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java >>> Sat >>> Apr 26 01:40:27 2014 -0300 >>> @@ -665,7 +665,7 @@ >>> "getFieldNames()", "Field is null"); >>> } >>> } else { >>> - responseFields[i] = currElement.getKey().toString(); >>> + responseFields[i] = currElement.getKey(); >>> } >>> } >>> >>> @@ -929,8 +929,8 @@ >>> if (currElement != null) { >>> if (currElement.getValue() != null) { >>> // validate the field valued... >>> - if (validateField((currElement.getKey()).toString(), >>> - >>> (currElement.getValue()).toString())) { >>> + if (validateField((currElement.getKey()), >>> + (currElement.getValue()))) { >>> continue; >>> } else { >>> if (MODELMBEAN_LOGGER.isLoggable(Level.FINEST)) >>> { >>> diff -r e323c74edabd src/share/classes/javax/swing/ >>> text/html/FormView.java >>> --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/javax/swing/text/html/FormView.java Sat Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -478,7 +478,7 @@ >>> base.getPort(), base.getFile()) >>> : new URL(base, action); >>> if (!isPostMethod) { >>> - String query = data.toString(); >>> + String query = data; >>> actionURL = new URL(actionURL + "?" + query); >>> } >>> } catch (MalformedURLException e) { >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java >>> --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 >>> 2014 >>> -0700 >>> +++ b/src/share/classes/sun/java2d/loops/Blit.java Sat Apr 26 01:40:27 >>> 2014 >>> -0300 >>> @@ -50,7 +50,7 @@ >>> >>> public class Blit extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = "Blit(...)".toString(); >>> + public static final String methodSignature = "Blit(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java >>> --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sat Apr 26 01:40:27 >>> 2014 -0300 >>> @@ -54,7 +54,7 @@ >>> */ >>> public class BlitBg extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "BlitBg(...)".toString(); >>> + public static final String methodSignature = "BlitBg(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>> loops/DrawGlyphList.java >>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sat Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> */ >>> public class DrawGlyphList extends GraphicsPrimitive { >>> >>> - public final static String methodSignature = >>> "DrawGlyphList(...)".toString(); >>> + public final static String methodSignature = "DrawGlyphList(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>> loops/DrawGlyphListAA.java >>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sat Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> */ >>> public class DrawGlyphListAA extends GraphicsPrimitive { >>> >>> - public final static String methodSignature = >>> "DrawGlyphListAA(...)".toString(); >>> + public final static String methodSignature = "DrawGlyphListAA(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java >>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sat Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -40,7 +40,7 @@ >>> public class DrawGlyphListLCD extends GraphicsPrimitive { >>> >>> public final static String >>> - methodSignature = "DrawGlyphListLCD(...)".toString(); >>> + methodSignature = "DrawGlyphListLCD(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java >>> --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -44,7 +44,7 @@ >>> */ >>> public class DrawLine extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "DrawLine(...)".toString(); >>> + public final static String methodSignature = "DrawLine(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/DrawParallelogram.java >>> --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed Apr >>> 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sat Apr >>> 26 >>> 01:40:27 2014 -0300 >>> @@ -43,7 +43,7 @@ >>> public class DrawParallelogram extends GraphicsPrimitive >>> { >>> public final static String methodSignature = >>> - "DrawParallelogram(...)".toString(); >>> + "DrawParallelogram(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java >>> --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> public class DrawPath extends GraphicsPrimitive { >>> >>> public final static String methodSignature = >>> - "DrawPath(...)".toString(); >>> + "DrawPath(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPolygons.java >>> --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -41,7 +41,7 @@ >>> */ >>> public class DrawPolygons extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "DrawPolygons(...)".toString(); >>> + public final static String methodSignature = "DrawPolygons(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java >>> --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -44,7 +44,7 @@ >>> */ >>> public class DrawRect extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "DrawRect(...)".toString(); >>> + public final static String methodSignature = "DrawRect(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/FillParallelogram.java >>> --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed Apr >>> 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sat Apr >>> 26 >>> 01:40:27 2014 -0300 >>> @@ -41,7 +41,7 @@ >>> public class FillParallelogram extends GraphicsPrimitive >>> { >>> public final static String methodSignature = >>> - "FillParallelogram(...)".toString(); >>> + "FillParallelogram(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java >>> --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> public class FillPath extends GraphicsPrimitive { >>> >>> public final static String methodSignature = >>> - "FillPath(...)".toString(); >>> + "FillPath(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java >>> --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -44,7 +44,7 @@ >>> */ >>> public class FillRect extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "FillRect(...)".toString(); >>> + public final static String methodSignature = "FillRect(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java >>> --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -45,7 +45,7 @@ >>> */ >>> public class FillSpans extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "FillSpans(...)".toString(); >>> + public final static String methodSignature = "FillSpans(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java >>> --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -48,7 +48,7 @@ >>> >>> public class MaskBlit extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "MaskBlit(...)".toString(); >>> + public static final String methodSignature = "MaskBlit(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java >>> --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -50,11 +50,11 @@ >>> */ >>> public class MaskFill extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "MaskFill(...)".toString(); >>> + public static final String methodSignature = "MaskFill(...)"; >>> public static final String fillPgramSignature = >>> - "FillAAPgram(...)".toString(); >>> + "FillAAPgram(...)"; >>> public static final String drawPgramSignature = >>> - "DrawAAPgram(...)".toString(); >>> + "DrawAAPgram(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java >>> --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -45,7 +45,7 @@ >>> >>> public class ScaledBlit extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "ScaledBlit(...)".toString(); >>> + public static final String methodSignature = "ScaledBlit(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>> loops/TransformBlit.java >>> --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sat Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -47,7 +47,7 @@ >>> public class TransformBlit extends GraphicsPrimitive >>> { >>> public static final String methodSignature = >>> - "TransformBlit(...)".toString(); >>> + "TransformBlit(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>> loops/TransformHelper.java >>> --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sat Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -46,7 +46,7 @@ >>> public class TransformHelper extends GraphicsPrimitive >>> { >>> public static final String methodSignature = >>> - "TransformHelper(...)".toString(); >>> + "TransformHelper(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java >>> --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sat Apr 26 01:40:27 >>> 2014 -0300 >>> @@ -260,11 +260,11 @@ >>> >>> // Convert token into meaning number for comparision >>> if (stk.hasMoreTokens()) >>> - n = convertToken(stk.nextToken().toString()); >>> + n = convertToken(stk.nextToken()); >>> >>> // Convert token into meaning number for comparision >>> if (ttk.hasMoreTokens()) >>> - m = convertToken(ttk.nextToken().toString()); >>> + m = convertToken(ttk.nextToken()); >>> >>> if (n > m) >>> return 1; >>> diff -r e323c74edabd >>> src/share/classes/sun/tools/jconsole/inspector/Utils.java >>> --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr >>> 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat Apr >>> 26 >>> 01:40:27 2014 -0300 >>> @@ -378,7 +378,7 @@ >>> if (userInput instanceof XObject) { >>> result[i] = ((XObject) userInput).getObject(); >>> } else { >>> - result[i] = createObjectFromString(params[i].toString(), >>> + result[i] = createObjectFromString(params[i], >>> (String) userInput); >>> } >>> } >>> >>> >>> >> > > From otaviojava at java.net Mon Apr 28 03:05:08 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Mon, 28 Apr 2014 00:05:08 -0300 Subject: Remove redundant calls of toString() In-Reply-To: <535DBE11.2000303@oracle.com> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> Message-ID: In my opinion not, because Objects.requireNonNull is more readable than just string.toString. This way is more understandable which field is required and doesn't impact on performance. On Sun, Apr 27, 2014 at 11:33 PM, David Holmes wrote: > On 28/04/2014 3:41 AM, Ot?vio Gon?alves de Santana wrote: > >> sorry. >> I tried answer and the message was twice. >> But Yes when has null pointer possibility I replaced to >> Objects.requireNonNull. >> > > In my opinion that is making the code worse not better. > > David > ----- > > > I am review the code again. >> The code below: >> >> diff -r e323c74edabd >> src/share/classes/com/sun/tools/example/debug/tty/Commands.java >> --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed >> Apr 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sun >> Apr 27 14:33:45 2014 -0300 >> @@ -1653,20 +1653,20 @@ >> String expr = t.nextToken(""); >> Value val = evaluate(expr); >> if (val == null) { >> - MessageOutput.println("expr is null", expr.toString()); >> + MessageOutput.println("expr is >> null",Objects.requireNonNull(expr)); >> } else if (dumpObject && (val instanceof ObjectReference) && >> !(val instanceof StringReference)) { >> ObjectReference obj = (ObjectReference)val; >> ReferenceType refType = obj.referenceType(); >> MessageOutput.println("expr is value", >> - new Object [] {expr.toString(), >> + new Object [] >> {Objects.requireNonNull(expr), >> >> MessageOutput.format("grouping begin character")}); >> dump(obj, refType, refType); >> MessageOutput.println("grouping end character"); >> } else { >> String strVal = getStringValue(); >> if (strVal != null) { >> - MessageOutput.println("expr is value", new Object [] >> {expr.toString(), >> + MessageOutput.println("expr is value", new Object [] >> {Objects.requireNonNull(expr), >> >> strVal}); >> } >> } >> diff -r e323c74edabd >> src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> --- >> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> Sun >> Apr 27 14:33:45 2014 -0300 >> @@ -25,6 +25,8 @@ >> >> package java.lang.annotation; >> >> +import java.util.Objects; >> + >> /** >> * Thrown to indicate that a program has attempted to access an element >> of >> * an annotation type that was added to the annotation type definition >> after >> @@ -56,7 +58,7 @@ >> Class annotationType, >> String elementName) { >> super(annotationType.getName() + " missing element " + >> - elementName.toString()); >> + Objects.requireNonNull(elementName)); >> >> this.annotationType = annotationType; >> this.elementName = elementName; >> diff -r e323c74edabd src/share/classes/java/text/DateFormatSymbols.java >> --- a/src/share/classes/java/text/DateFormatSymbols.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/java/text/DateFormatSymbols.java Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -594,7 +594,7 @@ >> */ >> public void setLocalPatternChars(String newLocalPatternChars) { >> // Call toString() to throw an NPE in case the argument is null >> - localPatternChars = newLocalPatternChars.toString(); >> + localPatternChars = Objects.requireNonNull( >> newLocalPatternChars); >> cachedHashCode = 0; >> } >> >> diff -r e323c74edabd >> src/share/classes/javax/management/modelmbean/DescriptorSupport.java >> --- a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java >> Sun >> Apr 27 14:33:45 2014 -0300 >> @@ -43,13 +43,7 @@ >> import java.lang.reflect.Constructor; >> >> import java.security.AccessController; >> -import java.util.HashMap; >> -import java.util.Iterator; >> -import java.util.Map; >> -import java.util.Set; >> -import java.util.SortedMap; >> -import java.util.StringTokenizer; >> -import java.util.TreeMap; >> +import java.util.*; >> import java.util.logging.Level; >> >> import javax.management.Descriptor; >> @@ -665,7 +659,7 @@ >> "getFieldNames()", "Field is null"); >> } >> } else { >> - responseFields[i] = currElement.getKey().toString(); >> + responseFields[i] = >> Objects.requireNonNull(currElement.getKey()); >> } >> } >> >> @@ -929,7 +923,7 @@ >> if (currElement != null) { >> if (currElement.getValue() != null) { >> // validate the field valued... >> - if (validateField((currElement.getKey()).toString(), >> + if >> (validateField((Objects.requireNonNull(currElement.getKey())), >> >> (currElement.getValue()).toString())) { >> continue; >> } else { >> diff -r e323c74edabd src/share/classes/javax/swing/ >> text/html/FormView.java >> --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/javax/swing/text/html/FormView.java Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -478,7 +478,7 @@ >> base.getPort(), base.getFile()) >> : new URL(base, action); >> if (!isPostMethod) { >> - String query = data.toString(); >> + String query = Objects.requireNonNull(data); >> actionURL = new URL(actionURL + "?" + query); >> } >> } catch (MalformedURLException e) { >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java >> --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 >> 2014 >> -0700 >> +++ b/src/share/classes/sun/java2d/loops/Blit.java Sun Apr 27 14:33:45 >> 2014 >> -0300 >> @@ -50,7 +50,7 @@ >> >> public class Blit extends GraphicsPrimitive >> { >> - public static final String methodSignature = "Blit(...)".toString(); >> + public static final String methodSignature = "Blit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java >> --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sun Apr 27 14:33:45 >> 2014 -0300 >> @@ -54,7 +54,7 @@ >> */ >> public class BlitBg extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "BlitBg(...)".toString(); >> + public static final String methodSignature = "BlitBg(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/ >> loops/DrawGlyphList.java >> --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -39,7 +39,7 @@ >> */ >> public class DrawGlyphList extends GraphicsPrimitive { >> >> - public final static String methodSignature = >> "DrawGlyphList(...)".toString(); >> + public final static String methodSignature = "DrawGlyphList(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/ >> loops/DrawGlyphListAA.java >> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -39,7 +39,7 @@ >> */ >> public class DrawGlyphListAA extends GraphicsPrimitive { >> >> - public final static String methodSignature = >> "DrawGlyphListAA(...)".toString(); >> + public final static String methodSignature = "DrawGlyphListAA(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java >> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -40,7 +40,7 @@ >> public class DrawGlyphListLCD extends GraphicsPrimitive { >> >> public final static String >> - methodSignature = "DrawGlyphListLCD(...)".toString(); >> + methodSignature = "DrawGlyphListLCD(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java >> --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sun Apr 27 >> 14:33:45 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class DrawLine extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawLine(...)".toString(); >> + public final static String methodSignature = "DrawLine(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/DrawParallelogram.java >> --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed Apr >> 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sun Apr >> 27 >> 14:33:45 2014 -0300 >> @@ -43,7 +43,7 @@ >> public class DrawParallelogram extends GraphicsPrimitive >> { >> public final static String methodSignature = >> - "DrawParallelogram(...)".toString(); >> + "DrawParallelogram(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java >> --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sun Apr 27 >> 14:33:45 >> 2014 -0300 >> @@ -39,7 +39,7 @@ >> public class DrawPath extends GraphicsPrimitive { >> >> public final static String methodSignature = >> - "DrawPath(...)".toString(); >> + "DrawPath(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPolygons.java >> --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -41,7 +41,7 @@ >> */ >> public class DrawPolygons extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawPolygons(...)".toString(); >> + public final static String methodSignature = "DrawPolygons(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java >> --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sun Apr 27 >> 14:33:45 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class DrawRect extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawRect(...)".toString(); >> + public final static String methodSignature = "DrawRect(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/FillParallelogram.java >> --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed Apr >> 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sun Apr >> 27 >> 14:33:45 2014 -0300 >> @@ -41,7 +41,7 @@ >> public class FillParallelogram extends GraphicsPrimitive >> { >> public final static String methodSignature = >> - "FillParallelogram(...)".toString(); >> + "FillParallelogram(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java >> --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sun Apr 27 >> 14:33:45 >> 2014 -0300 >> @@ -39,7 +39,7 @@ >> public class FillPath extends GraphicsPrimitive { >> >> public final static String methodSignature = >> - "FillPath(...)".toString(); >> + "FillPath(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java >> --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sun Apr 27 >> 14:33:45 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class FillRect extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "FillRect(...)".toString(); >> + public final static String methodSignature = "FillRect(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java >> --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sun Apr 27 >> 14:33:45 >> 2014 -0300 >> @@ -45,7 +45,7 @@ >> */ >> public class FillSpans extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "FillSpans(...)".toString(); >> + public final static String methodSignature = "FillSpans(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java >> --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sun Apr 27 >> 14:33:45 >> 2014 -0300 >> @@ -48,7 +48,7 @@ >> >> public class MaskBlit extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "MaskBlit(...)".toString(); >> + public static final String methodSignature = "MaskBlit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java >> --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sun Apr 27 >> 14:33:45 >> 2014 -0300 >> @@ -50,11 +50,11 @@ >> */ >> public class MaskFill extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "MaskFill(...)".toString(); >> + public static final String methodSignature = "MaskFill(...)"; >> public static final String fillPgramSignature = >> - "FillAAPgram(...)".toString(); >> + "FillAAPgram(...)"; >> public static final String drawPgramSignature = >> - "DrawAAPgram(...)".toString(); >> + "DrawAAPgram(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java >> --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -45,7 +45,7 @@ >> >> public class ScaledBlit extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "ScaledBlit(...)".toString(); >> + public static final String methodSignature = "ScaledBlit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/ >> loops/TransformBlit.java >> --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -47,7 +47,7 @@ >> public class TransformBlit extends GraphicsPrimitive >> { >> public static final String methodSignature = >> - "TransformBlit(...)".toString(); >> + "TransformBlit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/ >> loops/TransformHelper.java >> --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -46,7 +46,7 @@ >> public class TransformHelper extends GraphicsPrimitive >> { >> public static final String methodSignature = >> - "TransformHelper(...)".toString(); >> + "TransformHelper(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java >> --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sun Apr 27 14:33:45 >> 2014 -0300 >> @@ -25,6 +25,7 @@ >> >> package sun.misc; >> >> +import java.util.Objects; >> import java.util.StringTokenizer; >> import java.util.jar.Attributes; >> import java.util.jar.Attributes.Name; >> @@ -260,11 +261,11 @@ >> >> // Convert token into meaning number for comparision >> if (stk.hasMoreTokens()) >> - n = convertToken(stk.nextToken().toString()); >> + n = convertToken(Objects.requireNonNull(stk.nextToken())); >> >> // Convert token into meaning number for comparision >> if (ttk.hasMoreTokens()) >> - m = convertToken(ttk.nextToken().toString()); >> + m = convertToken(Objects.requireNonNull(ttk.nextToken())); >> >> if (n > m) >> return 1; >> diff -r e323c74edabd >> src/share/classes/sun/tools/jconsole/inspector/Utils.java >> --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr >> 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sun Apr >> 27 >> 14:33:45 2014 -0300 >> @@ -378,7 +378,7 @@ >> if (userInput instanceof XObject) { >> result[i] = ((XObject) userInput).getObject(); >> } else { >> - result[i] = createObjectFromString(params[i].toString(), >> + result[i] = >> createObjectFromString(Objects.requireNonNull(params[i]), >> (String) userInput); >> } >> } >> >> >> >> >> On Sun, Apr 27, 2014 at 1:09 PM, Remi Forax wrote: >> >> On 04/27/2014 03:15 PM, Ot?vio Gon?alves de Santana wrote: >>> >>> There is an issue that was opened to remove redundant calls of >>>> toString() >>>> on String objects. [1] >>>> I went deep on all JVM sources and I found all, 32 changes. >>>> >>>> >>>> [1]https://bugs.openjdk.java.net/browse/JDK-8015470 >>>> >>>> >>> Otavio, >>> calling toString() on a String has the side effect to implicitly check >>> that the reference is not null. >>> Do you have checked that for each redundant call, the String can never be >>> null ? >>> >>> regards, >>> R?mi >>> >>> >>> >>> >>>> diff -r e323c74edabd >>>> src/share/classes/com/sun/tools/example/debug/tty/Commands.java >>>> --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java >>>> Wed >>>> Apr 23 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java >>>> Sat >>>> Apr 26 01:40:27 2014 -0300 >>>> @@ -1653,20 +1653,20 @@ >>>> String expr = t.nextToken(""); >>>> Value val = evaluate(expr); >>>> if (val == null) { >>>> - MessageOutput.println("expr is null", expr.toString()); >>>> + MessageOutput.println("expr is null", expr); >>>> } else if (dumpObject && (val instanceof >>>> ObjectReference) && >>>> !(val instanceof StringReference)) { >>>> ObjectReference obj = (ObjectReference)val; >>>> ReferenceType refType = obj.referenceType(); >>>> MessageOutput.println("expr is value", >>>> - new Object [] {expr.toString(), >>>> + new Object [] {expr, >>>> >>>> MessageOutput.format("grouping begin character")}); >>>> dump(obj, refType, refType); >>>> MessageOutput.println("grouping end character"); >>>> } else { >>>> String strVal = getStringValue(); >>>> if (strVal != null) { >>>> - MessageOutput.println("expr is value", new Object >>>> [] >>>> {expr.toString(), >>>> + MessageOutput.println("expr is value", new Object >>>> [] >>>> {expr, >>>> >>>> strVal}); >>>> } >>>> } >>>> diff -r e323c74edabd >>>> src/share/classes/java/lang/annotation/IncompleteAnnotationException. >>>> java >>>> --- >>>> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException. >>>> java >>>> Wed >>>> Apr 23 11:35:40 2014 -0700 >>>> +++ >>>> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException. >>>> java >>>> Sat >>>> Apr 26 01:40:27 2014 -0300 >>>> @@ -56,7 +56,7 @@ >>>> Class annotationType, >>>> String elementName) { >>>> super(annotationType.getName() + " missing element " + >>>> - elementName.toString()); >>>> + elementName); >>>> >>>> this.annotationType = annotationType; >>>> this.elementName = elementName; >>>> diff -r e323c74edabd src/share/classes/java/text/DateFormatSymbols.java >>>> --- a/src/share/classes/java/text/DateFormatSymbols.java Wed Apr 23 >>>> 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/java/text/DateFormatSymbols.java Sat Apr 26 >>>> 01:40:27 >>>> 2014 -0300 >>>> @@ -593,8 +593,8 @@ >>>> * pattern characters. >>>> */ >>>> public void setLocalPatternChars(String newLocalPatternChars) { >>>> - // Call toString() to throw an NPE in case the argument is null >>>> - localPatternChars = newLocalPatternChars.toString(); >>>> + >>>> + localPatternChars = Objects.requireNonNull( >>>> newLocalPatternChars); >>>> cachedHashCode = 0; >>>> } >>>> >>>> diff -r e323c74edabd >>>> src/share/classes/javax/management/modelmbean/DescriptorSupport.java >>>> --- a/src/share/classes/javax/management/modelmbean/ >>>> DescriptorSupport.java >>>> Wed >>>> Apr 23 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/javax/management/modelmbean/ >>>> DescriptorSupport.java >>>> Sat >>>> Apr 26 01:40:27 2014 -0300 >>>> @@ -665,7 +665,7 @@ >>>> "getFieldNames()", "Field is null"); >>>> } >>>> } else { >>>> - responseFields[i] = currElement.getKey().toString(); >>>> + responseFields[i] = currElement.getKey(); >>>> } >>>> } >>>> >>>> @@ -929,8 +929,8 @@ >>>> if (currElement != null) { >>>> if (currElement.getValue() != null) { >>>> // validate the field valued... >>>> - if (validateField((currElement. >>>> getKey()).toString(), >>>> - >>>> (currElement.getValue()).toString())) { >>>> + if (validateField((currElement.getKey()), >>>> + (currElement.getValue()))) { >>>> continue; >>>> } else { >>>> if (MODELMBEAN_LOGGER.isLoggable( >>>> Level.FINEST)) >>>> { >>>> diff -r e323c74edabd src/share/classes/javax/swing/ >>>> text/html/FormView.java >>>> --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 >>>> 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/javax/swing/text/html/FormView.java Sat Apr 26 >>>> 01:40:27 2014 -0300 >>>> @@ -478,7 +478,7 @@ >>>> base.getPort(), >>>> base.getFile()) >>>> : new URL(base, action); >>>> if (!isPostMethod) { >>>> - String query = data.toString(); >>>> + String query = data; >>>> actionURL = new URL(actionURL + "?" + query); >>>> } >>>> } catch (MalformedURLException e) { >>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java >>>> --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 >>>> 2014 >>>> -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/Blit.java Sat Apr 26 01:40:27 >>>> 2014 >>>> -0300 >>>> @@ -50,7 +50,7 @@ >>>> >>>> public class Blit extends GraphicsPrimitive >>>> { >>>> - public static final String methodSignature = >>>> "Blit(...)".toString(); >>>> + public static final String methodSignature = "Blit(...)"; >>>> >>>> public static final int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java >>>> --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 >>>> 11:35:40 >>>> 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sat Apr 26 >>>> 01:40:27 >>>> 2014 -0300 >>>> @@ -54,7 +54,7 @@ >>>> */ >>>> public class BlitBg extends GraphicsPrimitive >>>> { >>>> - public static final String methodSignature = >>>> "BlitBg(...)".toString(); >>>> + public static final String methodSignature = "BlitBg(...)"; >>>> >>>> public static final int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>>> loops/DrawGlyphList.java >>>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 >>>> 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sat Apr 26 >>>> 01:40:27 2014 -0300 >>>> @@ -39,7 +39,7 @@ >>>> */ >>>> public class DrawGlyphList extends GraphicsPrimitive { >>>> >>>> - public final static String methodSignature = >>>> "DrawGlyphList(...)".toString(); >>>> + public final static String methodSignature = "DrawGlyphList(...)"; >>>> >>>> public final static int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>>> loops/DrawGlyphListAA.java >>>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr >>>> 23 >>>> 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sat Apr >>>> 26 >>>> 01:40:27 2014 -0300 >>>> @@ -39,7 +39,7 @@ >>>> */ >>>> public class DrawGlyphListAA extends GraphicsPrimitive { >>>> >>>> - public final static String methodSignature = >>>> "DrawGlyphListAA(...)".toString(); >>>> + public final static String methodSignature = >>>> "DrawGlyphListAA(...)"; >>>> >>>> public final static int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd >>>> src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java >>>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr >>>> 23 >>>> 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sat Apr >>>> 26 >>>> 01:40:27 2014 -0300 >>>> @@ -40,7 +40,7 @@ >>>> public class DrawGlyphListLCD extends GraphicsPrimitive { >>>> >>>> public final static String >>>> - methodSignature = "DrawGlyphListLCD(...)".toString(); >>>> + methodSignature = "DrawGlyphListLCD(...)"; >>>> >>>> public final static int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java >>>> --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 >>>> 11:35:40 >>>> 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sat Apr 26 >>>> 01:40:27 >>>> 2014 -0300 >>>> @@ -44,7 +44,7 @@ >>>> */ >>>> public class DrawLine extends GraphicsPrimitive >>>> { >>>> - public final static String methodSignature = >>>> "DrawLine(...)".toString(); >>>> + public final static String methodSignature = "DrawLine(...)"; >>>> >>>> public final static int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd >>>> src/share/classes/sun/java2d/loops/DrawParallelogram.java >>>> --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed Apr >>>> 23 >>>> 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sat Apr >>>> 26 >>>> 01:40:27 2014 -0300 >>>> @@ -43,7 +43,7 @@ >>>> public class DrawParallelogram extends GraphicsPrimitive >>>> { >>>> public final static String methodSignature = >>>> - "DrawParallelogram(...)".toString(); >>>> + "DrawParallelogram(...)"; >>>> >>>> public final static int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java >>>> --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 >>>> 11:35:40 >>>> 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sat Apr 26 >>>> 01:40:27 >>>> 2014 -0300 >>>> @@ -39,7 +39,7 @@ >>>> public class DrawPath extends GraphicsPrimitive { >>>> >>>> public final static String methodSignature = >>>> - "DrawPath(...)".toString(); >>>> + "DrawPath(...)"; >>>> >>>> public final static int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>>> loops/DrawPolygons.java >>>> --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 >>>> 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sat Apr 26 >>>> 01:40:27 >>>> 2014 -0300 >>>> @@ -41,7 +41,7 @@ >>>> */ >>>> public class DrawPolygons extends GraphicsPrimitive >>>> { >>>> - public final static String methodSignature = >>>> "DrawPolygons(...)".toString(); >>>> + public final static String methodSignature = "DrawPolygons(...)"; >>>> >>>> public final static int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java >>>> --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 >>>> 11:35:40 >>>> 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sat Apr 26 >>>> 01:40:27 >>>> 2014 -0300 >>>> @@ -44,7 +44,7 @@ >>>> */ >>>> public class DrawRect extends GraphicsPrimitive >>>> { >>>> - public final static String methodSignature = >>>> "DrawRect(...)".toString(); >>>> + public final static String methodSignature = "DrawRect(...)"; >>>> >>>> public final static int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd >>>> src/share/classes/sun/java2d/loops/FillParallelogram.java >>>> --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed Apr >>>> 23 >>>> 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sat Apr >>>> 26 >>>> 01:40:27 2014 -0300 >>>> @@ -41,7 +41,7 @@ >>>> public class FillParallelogram extends GraphicsPrimitive >>>> { >>>> public final static String methodSignature = >>>> - "FillParallelogram(...)".toString(); >>>> + "FillParallelogram(...)"; >>>> >>>> public final static int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java >>>> --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 >>>> 11:35:40 >>>> 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sat Apr 26 >>>> 01:40:27 >>>> 2014 -0300 >>>> @@ -39,7 +39,7 @@ >>>> public class FillPath extends GraphicsPrimitive { >>>> >>>> public final static String methodSignature = >>>> - "FillPath(...)".toString(); >>>> + "FillPath(...)"; >>>> >>>> public final static int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java >>>> --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 >>>> 11:35:40 >>>> 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sat Apr 26 >>>> 01:40:27 >>>> 2014 -0300 >>>> @@ -44,7 +44,7 @@ >>>> */ >>>> public class FillRect extends GraphicsPrimitive >>>> { >>>> - public final static String methodSignature = >>>> "FillRect(...)".toString(); >>>> + public final static String methodSignature = "FillRect(...)"; >>>> >>>> public final static int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java >>>> --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 >>>> 11:35:40 >>>> 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sat Apr 26 >>>> 01:40:27 >>>> 2014 -0300 >>>> @@ -45,7 +45,7 @@ >>>> */ >>>> public class FillSpans extends GraphicsPrimitive >>>> { >>>> - public final static String methodSignature = >>>> "FillSpans(...)".toString(); >>>> + public final static String methodSignature = "FillSpans(...)"; >>>> >>>> public final static int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java >>>> --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 >>>> 11:35:40 >>>> 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sat Apr 26 >>>> 01:40:27 >>>> 2014 -0300 >>>> @@ -48,7 +48,7 @@ >>>> >>>> public class MaskBlit extends GraphicsPrimitive >>>> { >>>> - public static final String methodSignature = >>>> "MaskBlit(...)".toString(); >>>> + public static final String methodSignature = "MaskBlit(...)"; >>>> >>>> public static final int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java >>>> --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 >>>> 11:35:40 >>>> 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sat Apr 26 >>>> 01:40:27 >>>> 2014 -0300 >>>> @@ -50,11 +50,11 @@ >>>> */ >>>> public class MaskFill extends GraphicsPrimitive >>>> { >>>> - public static final String methodSignature = >>>> "MaskFill(...)".toString(); >>>> + public static final String methodSignature = "MaskFill(...)"; >>>> public static final String fillPgramSignature = >>>> - "FillAAPgram(...)".toString(); >>>> + "FillAAPgram(...)"; >>>> public static final String drawPgramSignature = >>>> - "DrawAAPgram(...)".toString(); >>>> + "DrawAAPgram(...)"; >>>> >>>> public static final int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java >>>> --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 >>>> 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sat Apr 26 >>>> 01:40:27 >>>> 2014 -0300 >>>> @@ -45,7 +45,7 @@ >>>> >>>> public class ScaledBlit extends GraphicsPrimitive >>>> { >>>> - public static final String methodSignature = >>>> "ScaledBlit(...)".toString(); >>>> + public static final String methodSignature = "ScaledBlit(...)"; >>>> >>>> public static final int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>>> loops/TransformBlit.java >>>> --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 >>>> 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sat Apr 26 >>>> 01:40:27 2014 -0300 >>>> @@ -47,7 +47,7 @@ >>>> public class TransformBlit extends GraphicsPrimitive >>>> { >>>> public static final String methodSignature = >>>> - "TransformBlit(...)".toString(); >>>> + "TransformBlit(...)"; >>>> >>>> public static final int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>>> loops/TransformHelper.java >>>> --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr >>>> 23 >>>> 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sat Apr >>>> 26 >>>> 01:40:27 2014 -0300 >>>> @@ -46,7 +46,7 @@ >>>> public class TransformHelper extends GraphicsPrimitive >>>> { >>>> public static final String methodSignature = >>>> - "TransformHelper(...)".toString(); >>>> + "TransformHelper(...)"; >>>> >>>> public static final int primTypeID = makePrimTypeID(); >>>> >>>> diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java >>>> --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 >>>> 2014 -0700 >>>> +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sat Apr 26 01:40:27 >>>> 2014 -0300 >>>> @@ -260,11 +260,11 @@ >>>> >>>> // Convert token into meaning number for comparision >>>> if (stk.hasMoreTokens()) >>>> - n = convertToken(stk.nextToken().toString()); >>>> + n = convertToken(stk.nextToken()); >>>> >>>> // Convert token into meaning number for comparision >>>> if (ttk.hasMoreTokens()) >>>> - m = convertToken(ttk.nextToken().toString()); >>>> + m = convertToken(ttk.nextToken()); >>>> >>>> if (n > m) >>>> return 1; >>>> diff -r e323c74edabd >>>> src/share/classes/sun/tools/jconsole/inspector/Utils.java >>>> --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr >>>> 23 >>>> 11:35:40 2014 -0700 >>>> +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat Apr >>>> 26 >>>> 01:40:27 2014 -0300 >>>> @@ -378,7 +378,7 @@ >>>> if (userInput instanceof XObject) { >>>> result[i] = ((XObject) userInput).getObject(); >>>> } else { >>>> - result[i] = createObjectFromString(params[ >>>> i].toString(), >>>> + result[i] = createObjectFromString(params[i], >>>> (String) userInput); >>>> } >>>> } >>>> >>>> >>>> >>>> >>> >> >> -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From paul.sandoz at oracle.com Mon Apr 28 07:34:06 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 28 Apr 2014 09:34:06 +0200 Subject: Remove redundant calls of toString() In-Reply-To: References: Message-ID: <79BD36D4-9743-4321-94A1-6F1C6AE6F68F@oracle.com> Hi Ot?vio, Is there anyway you can experiment with publishing a webrev to dropbox or github, preferably so that it is browsable, otherwise the zip? Unfortunately the patches are hard to review, especially in response to reviews where code is updated. I realize until you have an openjdk account you are somewhat in "no-mans" land, but i strongly suspect using one of the above mentioned services is fairly easy to use, and therefore will make it easier to accept such patches. Paul. On Apr 27, 2014, at 3:15 PM, Ot?vio Gon?alves de Santana wrote: > There is an issue that was opened to remove redundant calls of toString() > on String objects. [1] > I went deep on all JVM sources and I found all, 32 changes. From paul.sandoz at oracle.com Mon Apr 28 07:42:48 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 28 Apr 2014 09:42:48 +0200 Subject: inefficient indexof when String has one length In-Reply-To: <535CF67B.9050006@oracle.com> References: <535BE93A.90604@oracle.com> <535CF26A.8090507@oracle.com> <535CF67B.9050006@oracle.com> Message-ID: <55638F81-25EF-4B1F-9804-0991B3180FAC@oracle.com> On Apr 27, 2014, at 2:22 PM, Claes Redestad wrote: > Possibly a few bytes in static class footprint, sure. Maybe this is something javac should optimize (javap on some trivial examples suggests this doesn't happen) rather than trying to root out all suboptimal cases, especially since there are bound to be a lot more code out there using similar patterns? > While javac can and perhaps should be smarter in certain cases like this i am still supportive of this change in the JDK esp. so if it is something trivially detectable by IDEs; it's low-hanging fruit. Paul. From paul.sandoz at oracle.com Mon Apr 28 08:20:15 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 28 Apr 2014 10:20:15 +0200 Subject: RFR 9: JDK-8040892 Incorrect message in Exception thrown by Collectors.toMap(Function, Function) In-Reply-To: <535A9C08.9010906@gmail.com> References: <534FF859.5090006@gmail.com> <534FFB92.4050805@gmail.com> <53500426.3060506@oracle.com> <535022B5.8090608@gmail.com> <86699497-9287-4B18-816E-B7F0D92A08F5@oracle.com> <5357829E.2030606@gmail.com> <535A89C5.9060209@gmail.com> <535A9C08.9010906@gmail.com> Message-ID: On Apr 25, 2014, at 7:31 PM, Peter Levart wrote: > Hi Paul, > > To make any sense of null return from the mergeFunction, which could mean that an entry with that key is absent from resulting map, such Collector would have to keep some more state - the collecting map (which is also returned at the end) and the set of removed keys. For example: > > > public static > > Collector toMap(Function keyMapper, > Function valueMapper, > BinaryOperator mergeFunction, > Supplier mapSupplier) { > > class State { > final M map = mapSupplier.get(); > final Set removedKeys = new HashSet<>(); > M map() { return map; } > } > > BiConsumer accumulator = (state, element) -> { > K k = keyMapper.apply(element); > if (!state.removedKeys.contains(k)) { > U u = state.map.merge(k, valueMapper.apply(element), mergeFunction); > if (u == null) state.removedKeys.add(k); > } > }; > > BinaryOperator merger = (state1, state2) -> { > state1.map.keySet().removeAll(state2.removedKeys); > state2.map.keySet().removeAll(state1.removedKeys); > state1.removedKeys.addAll(state2.removedKeys); > for (Map.Entry e : state2.map.entrySet()) { > U u = state1.map.merge(e.getKey(), e.getValue(), mergeFunction); > if (u == null) state1.removedKeys.add(e.getKey()); > } > return state1; > }; > > return new CollectorImpl<>(State::new, accumulator, merger, State::map, CH_ID); > } > > > ...but the concurrent variant would be tricky to implement. > Yes, i suspect a finishing stage would be required to clean up the map. The simplest thing to do is throw an NPE if Map.merge returns null. It would be rather surprising for partial map value merging to have a global subtractive effect (esp. if that could occur non-determinisitically when encounter order of processing values is not important). Collectors.toMap and groupingBy are already null-hostile, Map.merge (and your update using putIfAbsent preserving the same merge behaviour) will throw an NPE on a null input value. Plus I now realize that throwing an NPE after removal has occurred is OK since that side-effect should never be observed as resulting map will not be returned to the caller. Paul. From david.holmes at oracle.com Mon Apr 28 06:57:34 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Apr 2014 16:57:34 +1000 Subject: Remove redundant calls of toString() In-Reply-To: References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> Message-ID: <535DFBDE.6030701@oracle.com> On 28/04/2014 1:05 PM, Ot?vio Gon?alves de Santana wrote: > In my opinion not, because Objects.requireNonNull is more readable than > just string.toString. This way is more understandable which field is > required and doesn't impact on performance. An invocation of requireNonNull is potentially more expensive than the implicit null check that happens with foo.toString(). David ----- > > On Sun, Apr 27, 2014 at 11:33 PM, David Holmes > wrote: > > On 28/04/2014 3:41 AM, Ot?vio Gon?alves de Santana wrote: > > sorry. > I tried answer and the message was twice. > But Yes when has null pointer possibility I replaced to > Objects.requireNonNull. > > > In my opinion that is making the code worse not better. > > David > ----- > > > I am review the code again. > The code below: > > diff -r e323c74edabd > src/share/classes/com/sun/__tools/example/debug/tty/__Commands.java > --- > a/src/share/classes/com/sun/__tools/example/debug/tty/__Commands.java > Wed > Apr 23 11:35:40 2014 -0700 > +++ > b/src/share/classes/com/sun/__tools/example/debug/tty/__Commands.java > Sun > Apr 27 14:33:45 2014 -0300 > @@ -1653,20 +1653,20 @@ > String expr = t.nextToken(""); > Value val = evaluate(expr); > if (val == null) { > - MessageOutput.println("expr is null", > expr.toString()); > + MessageOutput.println("expr is > null",Objects.requireNonNull(__expr)); > } else if (dumpObject && (val instanceof > ObjectReference) && > !(val instanceof StringReference)) { > ObjectReference obj = (ObjectReference)val; > ReferenceType refType = obj.referenceType(); > MessageOutput.println("expr is value", > - new Object [] > {expr.toString(), > + new Object [] > {Objects.requireNonNull(expr), > > MessageOutput.format("grouping begin character")}); > dump(obj, refType, refType); > MessageOutput.println("__grouping end > character"); > } else { > String strVal = getStringValue(); > if (strVal != null) { > - MessageOutput.println("expr is value", new > Object [] > {expr.toString(), > + MessageOutput.println("expr is value", new > Object [] > {Objects.requireNonNull(expr), > > strVal}); > } > } > diff -r e323c74edabd > src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > --- > a/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > Wed > Apr 23 11:35:40 2014 -0700 > +++ > b/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > Sun > Apr 27 14:33:45 2014 -0300 > @@ -25,6 +25,8 @@ > > package java.lang.annotation; > > +import java.util.Objects; > + > /** > * Thrown to indicate that a program has attempted to access > an element of > * an annotation type that was added to the annotation type > definition > after > @@ -56,7 +58,7 @@ > Class annotationType, > String elementName) { > super(annotationType.getName() + " missing element " + > - elementName.toString()); > + Objects.requireNonNull(__elementName)); > > this.annotationType = annotationType; > this.elementName = elementName; > diff -r e323c74edabd > src/share/classes/java/text/__DateFormatSymbols.java > --- a/src/share/classes/java/text/__DateFormatSymbols.java Wed > Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/java/text/__DateFormatSymbols.java Sun > Apr 27 > 14:33:45 2014 -0300 > @@ -594,7 +594,7 @@ > */ > public void setLocalPatternChars(String > newLocalPatternChars) { > // Call toString() to throw an NPE in case the > argument is null > - localPatternChars = newLocalPatternChars.toString(__); > + localPatternChars = > Objects.requireNonNull(__newLocalPatternChars); > cachedHashCode = 0; > } > > diff -r e323c74edabd > src/share/classes/javax/__management/modelmbean/__DescriptorSupport.java > --- > a/src/share/classes/javax/__management/modelmbean/__DescriptorSupport.java > Wed > Apr 23 11:35:40 2014 -0700 > +++ > b/src/share/classes/javax/__management/modelmbean/__DescriptorSupport.java > Sun > Apr 27 14:33:45 2014 -0300 > @@ -43,13 +43,7 @@ > import java.lang.reflect.Constructor; > > import java.security.__AccessController; > -import java.util.HashMap; > -import java.util.Iterator; > -import java.util.Map; > -import java.util.Set; > -import java.util.SortedMap; > -import java.util.StringTokenizer; > -import java.util.TreeMap; > +import java.util.*; > import java.util.logging.Level; > > import javax.management.Descriptor; > @@ -665,7 +659,7 @@ > "getFieldNames()", "Field is null"); > } > } else { > - responseFields[i] = > currElement.getKey().toString(__); > + responseFields[i] = > Objects.requireNonNull(__currElement.getKey()); > } > } > > @@ -929,7 +923,7 @@ > if (currElement != null) { > if (currElement.getValue() != null) { > // validate the field valued... > - if > (validateField((currElement.__getKey()).toString(), > + if > (validateField((Objects.__requireNonNull(currElement.__getKey())), > > (currElement.getValue()).__toString())) { > continue; > } else { > diff -r e323c74edabd > src/share/classes/javax/swing/__text/html/FormView.java > --- a/src/share/classes/javax/__swing/text/html/FormView.java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/javax/__swing/text/html/FormView.java > Sun Apr 27 > 14:33:45 2014 -0300 > @@ -478,7 +478,7 @@ > base.getPort(), > base.getFile()) > : new URL(base, action); > if (!isPostMethod) { > - String query = data.toString(); > + String query = Objects.requireNonNull(data); > actionURL = new URL(actionURL + "?" + query); > } > } catch (MalformedURLException e) { > diff -r e323c74edabd src/share/classes/sun/java2d/__loops/Blit.java > --- a/src/share/classes/sun/__java2d/loops/Blit.java Wed Apr 23 > 11:35:40 2014 > -0700 > +++ b/src/share/classes/sun/__java2d/loops/Blit.java Sun Apr 27 > 14:33:45 2014 > -0300 > @@ -50,7 +50,7 @@ > > public class Blit extends GraphicsPrimitive > { > - public static final String methodSignature = > "Blit(...)".toString(); > + public static final String methodSignature = "Blit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/BlitBg.java > --- a/src/share/classes/sun/__java2d/loops/BlitBg.java Wed Apr > 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/BlitBg.java Sun Apr > 27 14:33:45 > 2014 -0300 > @@ -54,7 +54,7 @@ > */ > public class BlitBg extends GraphicsPrimitive > { > - public static final String methodSignature = > "BlitBg(...)".toString(); > + public static final String methodSignature = "BlitBg(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawGlyphList.java > --- a/src/share/classes/sun/__java2d/loops/DrawGlyphList.__java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/DrawGlyphList.__java > Sun Apr 27 > 14:33:45 2014 -0300 > @@ -39,7 +39,7 @@ > */ > public class DrawGlyphList extends GraphicsPrimitive { > > - public final static String methodSignature = > "DrawGlyphList(...)".toString(__); > + public final static String methodSignature = > "DrawGlyphList(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawGlyphListAA.java > --- > a/src/share/classes/sun/__java2d/loops/DrawGlyphListAA.__java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/DrawGlyphListAA.__java > Sun Apr 27 > 14:33:45 2014 -0300 > @@ -39,7 +39,7 @@ > */ > public class DrawGlyphListAA extends GraphicsPrimitive { > > - public final static String methodSignature = > "DrawGlyphListAA(...)".__toString(); > + public final static String methodSignature = > "DrawGlyphListAA(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawGlyphListLCD.java > --- > a/src/share/classes/sun/__java2d/loops/DrawGlyphListLCD.__java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/DrawGlyphListLCD.__java > Sun Apr 27 > 14:33:45 2014 -0300 > @@ -40,7 +40,7 @@ > public class DrawGlyphListLCD extends GraphicsPrimitive { > > public final static String > - methodSignature = "DrawGlyphListLCD(...)".__toString(); > + methodSignature = "DrawGlyphListLCD(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawLine.java > --- a/src/share/classes/sun/__java2d/loops/DrawLine.java Wed Apr > 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/DrawLine.java Sun Apr > 27 14:33:45 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class DrawLine extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawLine(...)".toString(); > + public final static String methodSignature = "DrawLine(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawParallelogram.java > --- > a/src/share/classes/sun/__java2d/loops/__DrawParallelogram.java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/__DrawParallelogram.java > Sun Apr 27 > 14:33:45 2014 -0300 > @@ -43,7 +43,7 @@ > public class DrawParallelogram extends GraphicsPrimitive > { > public final static String methodSignature = > - "DrawParallelogram(...)".__toString(); > + "DrawParallelogram(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawPath.java > --- a/src/share/classes/sun/__java2d/loops/DrawPath.java Wed Apr > 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/DrawPath.java Sun Apr > 27 14:33:45 > 2014 -0300 > @@ -39,7 +39,7 @@ > public class DrawPath extends GraphicsPrimitive { > > public final static String methodSignature = > - "DrawPath(...)".toString(); > + "DrawPath(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawPolygons.java > --- a/src/share/classes/sun/__java2d/loops/DrawPolygons.java Wed > Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/DrawPolygons.java Sun > Apr 27 > 14:33:45 2014 -0300 > @@ -41,7 +41,7 @@ > */ > public class DrawPolygons extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawPolygons(...)".toString()__; > + public final static String methodSignature = > "DrawPolygons(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawRect.java > --- a/src/share/classes/sun/__java2d/loops/DrawRect.java Wed Apr > 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/DrawRect.java Sun Apr > 27 14:33:45 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class DrawRect extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawRect(...)".toString(); > + public final static String methodSignature = "DrawRect(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/FillParallelogram.java > --- > a/src/share/classes/sun/__java2d/loops/__FillParallelogram.java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/__FillParallelogram.java > Sun Apr 27 > 14:33:45 2014 -0300 > @@ -41,7 +41,7 @@ > public class FillParallelogram extends GraphicsPrimitive > { > public final static String methodSignature = > - "FillParallelogram(...)".__toString(); > + "FillParallelogram(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/FillPath.java > --- a/src/share/classes/sun/__java2d/loops/FillPath.java Wed Apr > 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/FillPath.java Sun Apr > 27 14:33:45 > 2014 -0300 > @@ -39,7 +39,7 @@ > public class FillPath extends GraphicsPrimitive { > > public final static String methodSignature = > - "FillPath(...)".toString(); > + "FillPath(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/FillRect.java > --- a/src/share/classes/sun/__java2d/loops/FillRect.java Wed Apr > 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/FillRect.java Sun Apr > 27 14:33:45 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class FillRect extends GraphicsPrimitive > { > - public final static String methodSignature = > "FillRect(...)".toString(); > + public final static String methodSignature = "FillRect(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/FillSpans.java > --- a/src/share/classes/sun/__java2d/loops/FillSpans.java Wed > Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/FillSpans.java Sun > Apr 27 14:33:45 > 2014 -0300 > @@ -45,7 +45,7 @@ > */ > public class FillSpans extends GraphicsPrimitive > { > - public final static String methodSignature = > "FillSpans(...)".toString(); > + public final static String methodSignature = "FillSpans(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/MaskBlit.java > --- a/src/share/classes/sun/__java2d/loops/MaskBlit.java Wed Apr > 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/MaskBlit.java Sun Apr > 27 14:33:45 > 2014 -0300 > @@ -48,7 +48,7 @@ > > public class MaskBlit extends GraphicsPrimitive > { > - public static final String methodSignature = > "MaskBlit(...)".toString(); > + public static final String methodSignature = "MaskBlit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/MaskFill.java > --- a/src/share/classes/sun/__java2d/loops/MaskFill.java Wed Apr > 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/MaskFill.java Sun Apr > 27 14:33:45 > 2014 -0300 > @@ -50,11 +50,11 @@ > */ > public class MaskFill extends GraphicsPrimitive > { > - public static final String methodSignature = > "MaskFill(...)".toString(); > + public static final String methodSignature = "MaskFill(...)"; > public static final String fillPgramSignature = > - "FillAAPgram(...)".toString(); > + "FillAAPgram(...)"; > public static final String drawPgramSignature = > - "DrawAAPgram(...)".toString(); > + "DrawAAPgram(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/ScaledBlit.java > --- a/src/share/classes/sun/__java2d/loops/ScaledBlit.java Wed > Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/ScaledBlit.java Sun > Apr 27 > 14:33:45 2014 -0300 > @@ -45,7 +45,7 @@ > > public class ScaledBlit extends GraphicsPrimitive > { > - public static final String methodSignature = > "ScaledBlit(...)".toString(); > + public static final String methodSignature = "ScaledBlit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/TransformBlit.java > --- a/src/share/classes/sun/__java2d/loops/TransformBlit.__java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/TransformBlit.__java > Sun Apr 27 > 14:33:45 2014 -0300 > @@ -47,7 +47,7 @@ > public class TransformBlit extends GraphicsPrimitive > { > public static final String methodSignature = > - "TransformBlit(...)".toString(__); > + "TransformBlit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/TransformHelper.java > --- > a/src/share/classes/sun/__java2d/loops/TransformHelper.__java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/TransformHelper.__java > Sun Apr 27 > 14:33:45 2014 -0300 > @@ -46,7 +46,7 @@ > public class TransformHelper extends GraphicsPrimitive > { > public static final String methodSignature = > - "TransformHelper(...)".__toString(); > + "TransformHelper(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/misc/__ExtensionInfo.java > --- a/src/share/classes/sun/misc/__ExtensionInfo.java Wed Apr 23 > 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/misc/__ExtensionInfo.java Sun Apr 27 > 14:33:45 > 2014 -0300 > @@ -25,6 +25,7 @@ > > package sun.misc; > > +import java.util.Objects; > import java.util.StringTokenizer; > import java.util.jar.Attributes; > import java.util.jar.Attributes.Name > ; > @@ -260,11 +261,11 @@ > > // Convert token into meaning number for comparision > if (stk.hasMoreTokens()) > - n = convertToken(stk.nextToken().__toString()); > + n = > convertToken(Objects.__requireNonNull(stk.nextToken()__)); > > // Convert token into meaning number for comparision > if (ttk.hasMoreTokens()) > - m = convertToken(ttk.nextToken().__toString()); > + m = > convertToken(Objects.__requireNonNull(ttk.nextToken()__)); > > if (n > m) > return 1; > diff -r e323c74edabd > src/share/classes/sun/tools/__jconsole/inspector/Utils.java > --- > a/src/share/classes/sun/tools/__jconsole/inspector/Utils.java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/tools/__jconsole/inspector/Utils.java > Sun Apr 27 > 14:33:45 2014 -0300 > @@ -378,7 +378,7 @@ > if (userInput instanceof XObject) { > result[i] = ((XObject) userInput).getObject(); > } else { > - result[i] = > createObjectFromString(params[__i].toString(), > + result[i] = > createObjectFromString(__Objects.requireNonNull(params[__i]), > (String) userInput); > } > } > > > > > On Sun, Apr 27, 2014 at 1:09 PM, Remi Forax > wrote: > > On 04/27/2014 03:15 PM, Ot?vio Gon?alves de Santana wrote: > > There is an issue that was opened to remove redundant > calls of toString() > on String objects. [1] > I went deep on all JVM sources and I found all, 32 changes. > > > [1]https://bugs.openjdk.java.__net/browse/JDK-8015470 > > > > Otavio, > calling toString() on a String has the side effect to > implicitly check > that the reference is not null. > Do you have checked that for each redundant call, the String > can never be > null ? > > regards, > R?mi > > > > > diff -r e323c74edabd > src/share/classes/com/sun/__tools/example/debug/tty/__Commands.java > --- > a/src/share/classes/com/sun/__tools/example/debug/tty/__Commands.java > Wed > Apr 23 11:35:40 2014 -0700 > +++ > b/src/share/classes/com/sun/__tools/example/debug/tty/__Commands.java > Sat > Apr 26 01:40:27 2014 -0300 > @@ -1653,20 +1653,20 @@ > String expr = t.nextToken(""); > Value val = evaluate(expr); > if (val == null) { > - MessageOutput.println("expr is null", > expr.toString()); > + MessageOutput.println("expr is null", > expr); > } else if (dumpObject && (val instanceof > ObjectReference) && > !(val instanceof > StringReference)) { > ObjectReference obj = > (ObjectReference)val; > ReferenceType refType = > obj.referenceType(); > MessageOutput.println("expr is value", > - new Object [] > {expr.toString(), > + new Object [] {expr, > > MessageOutput.format("grouping begin character")}); > dump(obj, refType, refType); > MessageOutput.println("__grouping > end character"); > } else { > String strVal = getStringValue(); > if (strVal != null) { > - MessageOutput.println("expr is > value", new Object [] > {expr.toString(), > + MessageOutput.println("expr is > value", new Object [] > {expr, > > strVal}); > } > } > diff -r e323c74edabd > src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > --- > a/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > Wed > Apr 23 11:35:40 2014 -0700 > +++ > b/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > Sat > Apr 26 01:40:27 2014 -0300 > @@ -56,7 +56,7 @@ > Class annotationType, > String elementName) { > super(annotationType.getName() + " missing > element " + > - elementName.toString()); > + elementName); > > this.annotationType = annotationType; > this.elementName = elementName; > diff -r e323c74edabd > src/share/classes/java/text/__DateFormatSymbols.java > --- > a/src/share/classes/java/text/__DateFormatSymbols.java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/java/text/__DateFormatSymbols.java > Sat Apr 26 > 01:40:27 > 2014 -0300 > @@ -593,8 +593,8 @@ > * pattern characters. > */ > public void setLocalPatternChars(String > newLocalPatternChars) { > - // Call toString() to throw an NPE in case the > argument is null > - localPatternChars = > newLocalPatternChars.toString(__); > + > + localPatternChars = Objects.requireNonNull( > newLocalPatternChars); > cachedHashCode = 0; > } > > diff -r e323c74edabd > src/share/classes/javax/__management/modelmbean/__DescriptorSupport.java > --- > a/src/share/classes/javax/__management/modelmbean/__DescriptorSupport.java > Wed > Apr 23 11:35:40 2014 -0700 > +++ > b/src/share/classes/javax/__management/modelmbean/__DescriptorSupport.java > Sat > Apr 26 01:40:27 2014 -0300 > @@ -665,7 +665,7 @@ > "getFieldNames()", > "Field is null"); > } > } else { > - responseFields[i] = > currElement.getKey().toString(__); > + responseFields[i] = currElement.getKey(); > } > } > > @@ -929,8 +929,8 @@ > if (currElement != null) { > if (currElement.getValue() != null) { > // validate the field valued... > - if > (validateField((currElement.__getKey()).toString(), > - > (currElement.getValue()).__toString())) { > + if > (validateField((currElement.__getKey()), > + > (currElement.getValue()))) { > continue; > } else { > if > (MODELMBEAN_LOGGER.isLoggable(__Level.FINEST)) > { > diff -r e323c74edabd src/share/classes/javax/swing/ > text/html/FormView.java > --- > a/src/share/classes/javax/__swing/text/html/FormView.java Wed > Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/javax/__swing/text/html/FormView.java Sat > Apr 26 > 01:40:27 2014 -0300 > @@ -478,7 +478,7 @@ > > base.getPort(), base.getFile()) > : new URL(base, action); > if (!isPostMethod) { > - String query = data.toString(); > + String query = data; > actionURL = new URL(actionURL + "?" > + query); > } > } catch (MalformedURLException e) { > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/Blit.java > --- a/src/share/classes/sun/__java2d/loops/Blit.java Wed > Apr 23 11:35:40 > 2014 > -0700 > +++ b/src/share/classes/sun/__java2d/loops/Blit.java Sat > Apr 26 01:40:27 > 2014 > -0300 > @@ -50,7 +50,7 @@ > > public class Blit extends GraphicsPrimitive > { > - public static final String methodSignature = > "Blit(...)".toString(); > + public static final String methodSignature = > "Blit(...)"; > > public static final int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/BlitBg.java > --- a/src/share/classes/sun/__java2d/loops/BlitBg.java > Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/BlitBg.java > Sat Apr 26 01:40:27 > 2014 -0300 > @@ -54,7 +54,7 @@ > */ > public class BlitBg extends GraphicsPrimitive > { > - public static final String methodSignature = > "BlitBg(...)".toString(); > + public static final String methodSignature = > "BlitBg(...)"; > > public static final int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/ > loops/DrawGlyphList.java > --- > a/src/share/classes/sun/__java2d/loops/DrawGlyphList.__java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/DrawGlyphList.__java > Sat Apr 26 > 01:40:27 2014 -0300 > @@ -39,7 +39,7 @@ > */ > public class DrawGlyphList extends GraphicsPrimitive { > > - public final static String methodSignature = > "DrawGlyphList(...)".toString(__); > + public final static String methodSignature = > "DrawGlyphList(...)"; > > public final static int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/ > loops/DrawGlyphListAA.java > --- > a/src/share/classes/sun/__java2d/loops/DrawGlyphListAA.__java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/DrawGlyphListAA.__java > Sat Apr 26 > 01:40:27 2014 -0300 > @@ -39,7 +39,7 @@ > */ > public class DrawGlyphListAA extends GraphicsPrimitive { > > - public final static String methodSignature = > "DrawGlyphListAA(...)".__toString(); > + public final static String methodSignature = > "DrawGlyphListAA(...)"; > > public final static int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawGlyphListLCD.java > --- > a/src/share/classes/sun/__java2d/loops/DrawGlyphListLCD.__java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/DrawGlyphListLCD.__java > Sat Apr 26 > 01:40:27 2014 -0300 > @@ -40,7 +40,7 @@ > public class DrawGlyphListLCD extends > GraphicsPrimitive { > > public final static String > - methodSignature = > "DrawGlyphListLCD(...)".__toString(); > + methodSignature = "DrawGlyphListLCD(...)"; > > public final static int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawLine.java > --- a/src/share/classes/sun/__java2d/loops/DrawLine.java > Wed Apr 23 > 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/DrawLine.java > Sat Apr 26 > 01:40:27 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class DrawLine extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawLine(...)".toString(); > + public final static String methodSignature = > "DrawLine(...)"; > > public final static int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawParallelogram.java > --- > a/src/share/classes/sun/__java2d/loops/__DrawParallelogram.java > Wed Apr > 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/__DrawParallelogram.java > Sat Apr > 26 > 01:40:27 2014 -0300 > @@ -43,7 +43,7 @@ > public class DrawParallelogram extends GraphicsPrimitive > { > public final static String methodSignature = > - "DrawParallelogram(...)".__toString(); > + "DrawParallelogram(...)"; > > public final static int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawPath.java > --- a/src/share/classes/sun/__java2d/loops/DrawPath.java > Wed Apr 23 > 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/DrawPath.java > Sat Apr 26 > 01:40:27 > 2014 -0300 > @@ -39,7 +39,7 @@ > public class DrawPath extends GraphicsPrimitive { > > public final static String methodSignature = > - "DrawPath(...)".toString(); > + "DrawPath(...)"; > > public final static int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawPolygons.java > --- > a/src/share/classes/sun/__java2d/loops/DrawPolygons.java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/DrawPolygons.java > Sat Apr 26 > 01:40:27 > 2014 -0300 > @@ -41,7 +41,7 @@ > */ > public class DrawPolygons extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawPolygons(...)".toString()__; > + public final static String methodSignature = > "DrawPolygons(...)"; > > public final static int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/DrawRect.java > --- a/src/share/classes/sun/__java2d/loops/DrawRect.java > Wed Apr 23 > 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/DrawRect.java > Sat Apr 26 > 01:40:27 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class DrawRect extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawRect(...)".toString(); > + public final static String methodSignature = > "DrawRect(...)"; > > public final static int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/FillParallelogram.java > --- > a/src/share/classes/sun/__java2d/loops/__FillParallelogram.java > Wed Apr > 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/__FillParallelogram.java > Sat Apr > 26 > 01:40:27 2014 -0300 > @@ -41,7 +41,7 @@ > public class FillParallelogram extends GraphicsPrimitive > { > public final static String methodSignature = > - "FillParallelogram(...)".__toString(); > + "FillParallelogram(...)"; > > public final static int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/FillPath.java > --- a/src/share/classes/sun/__java2d/loops/FillPath.java > Wed Apr 23 > 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/FillPath.java > Sat Apr 26 > 01:40:27 > 2014 -0300 > @@ -39,7 +39,7 @@ > public class FillPath extends GraphicsPrimitive { > > public final static String methodSignature = > - "FillPath(...)".toString(); > + "FillPath(...)"; > > public final static int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/FillRect.java > --- a/src/share/classes/sun/__java2d/loops/FillRect.java > Wed Apr 23 > 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/FillRect.java > Sat Apr 26 > 01:40:27 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class FillRect extends GraphicsPrimitive > { > - public final static String methodSignature = > "FillRect(...)".toString(); > + public final static String methodSignature = > "FillRect(...)"; > > public final static int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/FillSpans.java > --- > a/src/share/classes/sun/__java2d/loops/FillSpans.java > Wed Apr 23 > 11:35:40 > 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/FillSpans.java > Sat Apr 26 > 01:40:27 > 2014 -0300 > @@ -45,7 +45,7 @@ > */ > public class FillSpans extends GraphicsPrimitive > { > - public final static String methodSignature = > "FillSpans(...)".toString(); > + public final static String methodSignature = > "FillSpans(...)"; > > public final static int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/MaskBlit.java > --- a/src/share/classes/sun/__java2d/loops/MaskBlit.java > Wed Apr 23 > 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/MaskBlit.java > Sat Apr 26 > 01:40:27 > 2014 -0300 > @@ -48,7 +48,7 @@ > > public class MaskBlit extends GraphicsPrimitive > { > - public static final String methodSignature = > "MaskBlit(...)".toString(); > + public static final String methodSignature = > "MaskBlit(...)"; > > public static final int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/MaskFill.java > --- a/src/share/classes/sun/__java2d/loops/MaskFill.java > Wed Apr 23 > 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/__java2d/loops/MaskFill.java > Sat Apr 26 > 01:40:27 > 2014 -0300 > @@ -50,11 +50,11 @@ > */ > public class MaskFill extends GraphicsPrimitive > { > - public static final String methodSignature = > "MaskFill(...)".toString(); > + public static final String methodSignature = > "MaskFill(...)"; > public static final String fillPgramSignature = > - "FillAAPgram(...)".toString(); > + "FillAAPgram(...)"; > public static final String drawPgramSignature = > - "DrawAAPgram(...)".toString(); > + "DrawAAPgram(...)"; > > public static final int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/__loops/ScaledBlit.java > --- > a/src/share/classes/sun/__java2d/loops/ScaledBlit.java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/ScaledBlit.java > Sat Apr 26 > 01:40:27 > 2014 -0300 > @@ -45,7 +45,7 @@ > > public class ScaledBlit extends GraphicsPrimitive > { > - public static final String methodSignature = > "ScaledBlit(...)".toString(); > + public static final String methodSignature = > "ScaledBlit(...)"; > > public static final int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/ > loops/TransformBlit.java > --- > a/src/share/classes/sun/__java2d/loops/TransformBlit.__java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/TransformBlit.__java > Sat Apr 26 > 01:40:27 2014 -0300 > @@ -47,7 +47,7 @@ > public class TransformBlit extends GraphicsPrimitive > { > public static final String methodSignature = > - "TransformBlit(...)".toString(__); > + "TransformBlit(...)"; > > public static final int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/ > loops/TransformHelper.java > --- > a/src/share/classes/sun/__java2d/loops/TransformHelper.__java > Wed Apr 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/__java2d/loops/TransformHelper.__java > Sat Apr 26 > 01:40:27 2014 -0300 > @@ -46,7 +46,7 @@ > public class TransformHelper extends GraphicsPrimitive > { > public static final String methodSignature = > - "TransformHelper(...)".__toString(); > + "TransformHelper(...)"; > > public static final int primTypeID = > makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/misc/__ExtensionInfo.java > --- a/src/share/classes/sun/misc/__ExtensionInfo.java > Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/misc/__ExtensionInfo.java > Sat Apr 26 01:40:27 > 2014 -0300 > @@ -260,11 +260,11 @@ > > // Convert token into meaning number for > comparision > if (stk.hasMoreTokens()) > - n = convertToken(stk.nextToken().__toString()); > + n = convertToken(stk.nextToken()); > > // Convert token into meaning number for > comparision > if (ttk.hasMoreTokens()) > - m = convertToken(ttk.nextToken().__toString()); > + m = convertToken(ttk.nextToken()); > > if (n > m) > return 1; > diff -r e323c74edabd > src/share/classes/sun/tools/__jconsole/inspector/Utils.java > --- > a/src/share/classes/sun/tools/__jconsole/inspector/Utils.java > Wed Apr > 23 > 11:35:40 2014 -0700 > +++ > b/src/share/classes/sun/tools/__jconsole/inspector/Utils.java > Sat Apr > 26 > 01:40:27 2014 -0300 > @@ -378,7 +378,7 @@ > if (userInput instanceof XObject) { > result[i] = ((XObject) > userInput).getObject(); > } else { > - result[i] = > createObjectFromString(params[__i].toString(), > + result[i] = > createObjectFromString(params[__i], > (String) userInput); > } > } > > > > > > > > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 > From peter.levart at gmail.com Mon Apr 28 10:30:22 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 28 Apr 2014 12:30:22 +0200 Subject: RFR 9: JDK-8040892 Incorrect message in Exception thrown by Collectors.toMap(Function, Function) In-Reply-To: References: <534FF859.5090006@gmail.com> <534FFB92.4050805@gmail.com> <53500426.3060506@oracle.com> <535022B5.8090608@gmail.com> <86699497-9287-4B18-816E-B7F0D92A08F5@oracle.com> <5357829E.2030606@gmail.com> <535A89C5.9060209@gmail.com> <535A9C08.9010906@gmail.com> Message-ID: <535E2DBE.3050300@gmail.com> On 04/28/2014 10:20 AM, Paul Sandoz wrote: > On Apr 25, 2014, at 7:31 PM, Peter Levart wrote: >> Hi Paul, >> >> To make any sense of null return from the mergeFunction, which could mean that an entry with that key is absent from resulting map, such Collector would have to keep some more state - the collecting map (which is also returned at the end) and the set of removed keys. For example: >> >> >> public static > >> Collector toMap(Function keyMapper, >> Function valueMapper, >> BinaryOperator mergeFunction, >> Supplier mapSupplier) { >> >> class State { >> final M map = mapSupplier.get(); >> final Set removedKeys = new HashSet<>(); >> M map() { return map; } >> } >> >> BiConsumer accumulator = (state, element) -> { >> K k = keyMapper.apply(element); >> if (!state.removedKeys.contains(k)) { >> U u = state.map.merge(k, valueMapper.apply(element), mergeFunction); >> if (u == null) state.removedKeys.add(k); >> } >> }; >> >> BinaryOperator merger = (state1, state2) -> { >> state1.map.keySet().removeAll(state2.removedKeys); >> state2.map.keySet().removeAll(state1.removedKeys); >> state1.removedKeys.addAll(state2.removedKeys); >> for (Map.Entry e : state2.map.entrySet()) { >> U u = state1.map.merge(e.getKey(), e.getValue(), mergeFunction); >> if (u == null) state1.removedKeys.add(e.getKey()); >> } >> return state1; >> }; >> >> return new CollectorImpl<>(State::new, accumulator, merger, State::map, CH_ID); >> } >> >> >> ...but the concurrent variant would be tricky to implement. >> > Yes, i suspect a finishing stage would be required to clean up the map. > > The simplest thing to do is throw an NPE if Map.merge returns null. It would be rather surprising for partial map value merging to have a global subtractive effect (esp. if that could occur non-determinisitically when encounter order of processing values is not important). > > Collectors.toMap and groupingBy are already null-hostile, Map.merge (and your update using putIfAbsent preserving the same merge behaviour) will throw an NPE on a null input value. > > Plus I now realize that throwing an NPE after removal has occurred is OK since that side-effect should never be observed as resulting map will not be returned to the caller. You could use the null return from Map.merge() as a signal to throw NPE, but this is only 100% safe in to*Map() methods that don't take a mapSupplier. Collections.toConcurrentMap(...., Supplier mapSupplier) could be abused by someone knowing that the supplier is called exactly once and that the returned map is the same instance returned from the supplier. For example: ConcurrentMap map = new ConcurrentHashMap<>(); Stream s1 = Stream.of(1, 2, 3); Stream s2 = Stream.of(4, 5, 6); s1.collect(toConcurrentMap(e -> e, e -> "" + e, (v1, v2) -> v1, () -> map)); s2.collect(toConcurrentMap(e -> e, e -> "" + e, (v1, v2) -> v1, () -> map)); System.out.println(map); ...in that case a null return from mergeFunction could be observed in the result. Regards, Peter > > Paul. From paul.sandoz at oracle.com Mon Apr 28 10:54:49 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 28 Apr 2014 12:54:49 +0200 Subject: RFR 9: JDK-8040892 Incorrect message in Exception thrown by Collectors.toMap(Function, Function) In-Reply-To: <535E2DBE.3050300@gmail.com> References: <534FF859.5090006@gmail.com> <534FFB92.4050805@gmail.com> <53500426.3060506@oracle.com> <535022B5.8090608@gmail.com> <86699497-9287-4B18-816E-B7F0D92A08F5@oracle.com> <5357829E.2030606@gmail.com> <535A89C5.9060209@gmail.com> <535A9C08.9010906@gmail.com> <535E2DBE.3050300@gmail.com> Message-ID: On Apr 28, 2014, at 12:30 PM, Peter Levart wrote: > You could use the null return from Map.merge() as a signal to throw NPE, but this is only 100% safe in to*Map() methods that don't take a mapSupplier. > > Collections.toConcurrentMap(...., Supplier mapSupplier) could be abused by someone knowing that the supplier is called exactly once and that the returned map is the same instance returned from the supplier. For example: > I don't think we should concern ourselves with such abuses :-) * @param mapSupplier a function which returns a new, empty {@code Map} into * which the results will be inserted Paul. From otaviojava at java.net Mon Apr 28 11:56:34 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Mon, 28 Apr 2014 08:56:34 -0300 Subject: Remove redundant calls of toString() In-Reply-To: <535DFBDE.6030701@oracle.com> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> Message-ID: Yes you are right, but I mean it doesn't too much expensive enough to don't use the requireNonNull. IMHO. On Mon, Apr 28, 2014 at 3:57 AM, David Holmes wrote: > On 28/04/2014 1:05 PM, Ot?vio Gon?alves de Santana wrote: > >> In my opinion not, because Objects.requireNonNull is more readable than >> just string.toString. This way is more understandable which field is >> required and doesn't impact on performance. >> > > An invocation of requireNonNull is potentially more expensive than the > implicit null check that happens with foo.toString(). > > David > ----- > > >> On Sun, Apr 27, 2014 at 11:33 PM, David Holmes > > wrote: >> >> On 28/04/2014 3:41 AM, Ot?vio Gon?alves de Santana wrote: >> >> sorry. >> I tried answer and the message was twice. >> But Yes when has null pointer possibility I replaced to >> Objects.requireNonNull. >> >> >> In my opinion that is making the code worse not better. >> >> David >> ----- >> >> >> I am review the code again. >> The code below: >> >> diff -r e323c74edabd >> src/share/classes/com/sun/__tools/example/debug/tty/__ >> Commands.java >> --- >> a/src/share/classes/com/sun/__tools/example/debug/tty/__ >> Commands.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/com/sun/__tools/example/debug/tty/__ >> Commands.java >> Sun >> Apr 27 14:33:45 2014 -0300 >> @@ -1653,20 +1653,20 @@ >> String expr = t.nextToken(""); >> Value val = evaluate(expr); >> if (val == null) { >> - MessageOutput.println("expr is null", >> expr.toString()); >> + MessageOutput.println("expr is >> null",Objects.requireNonNull(__expr)); >> } else if (dumpObject && (val instanceof >> ObjectReference) && >> !(val instanceof StringReference)) { >> ObjectReference obj = (ObjectReference)val; >> ReferenceType refType = obj.referenceType(); >> MessageOutput.println("expr is value", >> - new Object [] >> {expr.toString(), >> + new Object [] >> {Objects.requireNonNull(expr), >> >> MessageOutput.format("grouping begin character")}); >> dump(obj, refType, refType); >> MessageOutput.println("__grouping end >> character"); >> } else { >> String strVal = getStringValue(); >> if (strVal != null) { >> - MessageOutput.println("expr is value", new >> Object [] >> {expr.toString(), >> + MessageOutput.println("expr is value", new >> Object [] >> {Objects.requireNonNull(expr), >> >> strVal}); >> } >> } >> diff -r e323c74edabd >> src/share/classes/java/lang/__annotation/__ >> IncompleteAnnotationException.__java >> --- >> a/src/share/classes/java/lang/__annotation/__ >> IncompleteAnnotationException.__java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/java/lang/__annotation/__ >> IncompleteAnnotationException.__java >> Sun >> Apr 27 14:33:45 2014 -0300 >> @@ -25,6 +25,8 @@ >> >> package java.lang.annotation; >> >> +import java.util.Objects; >> + >> /** >> * Thrown to indicate that a program has attempted to access >> an element of >> * an annotation type that was added to the annotation type >> definition >> after >> @@ -56,7 +58,7 @@ >> Class annotationType, >> String elementName) { >> super(annotationType.getName() + " missing element " + >> - elementName.toString()); >> + Objects.requireNonNull(__elementName)); >> >> this.annotationType = annotationType; >> this.elementName = elementName; >> diff -r e323c74edabd >> src/share/classes/java/text/__DateFormatSymbols.java >> --- a/src/share/classes/java/text/__DateFormatSymbols.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/java/text/__DateFormatSymbols.java Sun >> Apr 27 >> 14:33:45 2014 -0300 >> @@ -594,7 +594,7 @@ >> */ >> public void setLocalPatternChars(String >> newLocalPatternChars) { >> // Call toString() to throw an NPE in case the >> argument is null >> - localPatternChars = newLocalPatternChars.toString(__); >> + localPatternChars = >> Objects.requireNonNull(__newLocalPatternChars); >> cachedHashCode = 0; >> } >> >> diff -r e323c74edabd >> src/share/classes/javax/__management/modelmbean/__ >> DescriptorSupport.java >> --- >> a/src/share/classes/javax/__management/modelmbean/__ >> DescriptorSupport.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/javax/__management/modelmbean/__ >> DescriptorSupport.java >> Sun >> Apr 27 14:33:45 2014 -0300 >> @@ -43,13 +43,7 @@ >> import java.lang.reflect.Constructor; >> >> import java.security.__AccessController; >> -import java.util.HashMap; >> -import java.util.Iterator; >> -import java.util.Map; >> -import java.util.Set; >> -import java.util.SortedMap; >> -import java.util.StringTokenizer; >> -import java.util.TreeMap; >> +import java.util.*; >> import java.util.logging.Level; >> >> import javax.management.Descriptor; >> @@ -665,7 +659,7 @@ >> "getFieldNames()", "Field is >> null"); >> } >> } else { >> - responseFields[i] = >> currElement.getKey().toString(__); >> + responseFields[i] = >> Objects.requireNonNull(__currElement.getKey()); >> } >> } >> >> @@ -929,7 +923,7 @@ >> if (currElement != null) { >> if (currElement.getValue() != null) { >> // validate the field valued... >> - if >> (validateField((currElement.__getKey()).toString(), >> + if >> (validateField((Objects.__requireNonNull(currElement.__ >> getKey())), >> >> (currElement.getValue()).__toString())) { >> continue; >> } else { >> diff -r e323c74edabd >> src/share/classes/javax/swing/__text/html/FormView.java >> --- a/src/share/classes/javax/__swing/text/html/FormView.java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/javax/__swing/text/html/FormView.java >> Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -478,7 +478,7 @@ >> base.getPort(), >> base.getFile()) >> : new URL(base, action); >> if (!isPostMethod) { >> - String query = data.toString(); >> + String query = Objects.requireNonNull(data); >> actionURL = new URL(actionURL + "?" + query); >> } >> } catch (MalformedURLException e) { >> diff -r e323c74edabd src/share/classes/sun/java2d/_ >> _loops/Blit.java >> --- a/src/share/classes/sun/__java2d/loops/Blit.java Wed Apr 23 >> 11:35:40 2014 >> -0700 >> +++ b/src/share/classes/sun/__java2d/loops/Blit.java Sun Apr 27 >> 14:33:45 2014 >> -0300 >> @@ -50,7 +50,7 @@ >> >> public class Blit extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "Blit(...)".toString(); >> + public static final String methodSignature = "Blit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/BlitBg.java >> --- a/src/share/classes/sun/__java2d/loops/BlitBg.java Wed Apr >> 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/BlitBg.java Sun Apr >> 27 14:33:45 >> 2014 -0300 >> @@ -54,7 +54,7 @@ >> */ >> public class BlitBg extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "BlitBg(...)".toString(); >> + public static final String methodSignature = "BlitBg(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/DrawGlyphList.java >> --- a/src/share/classes/sun/__java2d/loops/DrawGlyphList.__java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/DrawGlyphList.__java >> Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -39,7 +39,7 @@ >> */ >> public class DrawGlyphList extends GraphicsPrimitive { >> >> - public final static String methodSignature = >> "DrawGlyphList(...)".toString(__); >> + public final static String methodSignature = >> "DrawGlyphList(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/DrawGlyphListAA.java >> --- >> a/src/share/classes/sun/__java2d/loops/DrawGlyphListAA.__java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/DrawGlyphListAA.__java >> Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -39,7 +39,7 @@ >> */ >> public class DrawGlyphListAA extends GraphicsPrimitive { >> >> - public final static String methodSignature = >> "DrawGlyphListAA(...)".__toString(); >> + public final static String methodSignature = >> "DrawGlyphListAA(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/DrawGlyphListLCD.java >> --- >> a/src/share/classes/sun/__java2d/loops/DrawGlyphListLCD.__java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/DrawGlyphListLCD.__java >> Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -40,7 +40,7 @@ >> public class DrawGlyphListLCD extends GraphicsPrimitive { >> >> public final static String >> - methodSignature = "DrawGlyphListLCD(...)".__toString(); >> + methodSignature = "DrawGlyphListLCD(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/DrawLine.java >> --- a/src/share/classes/sun/__java2d/loops/DrawLine.java Wed Apr >> 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/DrawLine.java Sun Apr >> 27 14:33:45 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class DrawLine extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawLine(...)".toString(); >> + public final static String methodSignature = "DrawLine(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/DrawParallelogram.java >> --- >> a/src/share/classes/sun/__java2d/loops/__DrawParallelogram.java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/__DrawParallelogram.java >> Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -43,7 +43,7 @@ >> public class DrawParallelogram extends GraphicsPrimitive >> { >> public final static String methodSignature = >> - "DrawParallelogram(...)".__toString(); >> + "DrawParallelogram(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/DrawPath.java >> --- a/src/share/classes/sun/__java2d/loops/DrawPath.java Wed Apr >> 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/DrawPath.java Sun Apr >> 27 14:33:45 >> 2014 -0300 >> @@ -39,7 +39,7 @@ >> public class DrawPath extends GraphicsPrimitive { >> >> public final static String methodSignature = >> - "DrawPath(...)".toString(); >> + "DrawPath(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/DrawPolygons.java >> --- a/src/share/classes/sun/__java2d/loops/DrawPolygons.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/DrawPolygons.java Sun >> Apr 27 >> 14:33:45 2014 -0300 >> @@ -41,7 +41,7 @@ >> */ >> public class DrawPolygons extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawPolygons(...)".toString()__; >> + public final static String methodSignature = >> "DrawPolygons(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/DrawRect.java >> --- a/src/share/classes/sun/__java2d/loops/DrawRect.java Wed Apr >> 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/DrawRect.java Sun Apr >> 27 14:33:45 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class DrawRect extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawRect(...)".toString(); >> + public final static String methodSignature = "DrawRect(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/FillParallelogram.java >> --- >> a/src/share/classes/sun/__java2d/loops/__FillParallelogram.java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/__FillParallelogram.java >> Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -41,7 +41,7 @@ >> public class FillParallelogram extends GraphicsPrimitive >> { >> public final static String methodSignature = >> - "FillParallelogram(...)".__toString(); >> + "FillParallelogram(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/FillPath.java >> --- a/src/share/classes/sun/__java2d/loops/FillPath.java Wed Apr >> 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/FillPath.java Sun Apr >> 27 14:33:45 >> 2014 -0300 >> @@ -39,7 +39,7 @@ >> public class FillPath extends GraphicsPrimitive { >> >> public final static String methodSignature = >> - "FillPath(...)".toString(); >> + "FillPath(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/FillRect.java >> --- a/src/share/classes/sun/__java2d/loops/FillRect.java Wed Apr >> 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/FillRect.java Sun Apr >> 27 14:33:45 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class FillRect extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "FillRect(...)".toString(); >> + public final static String methodSignature = "FillRect(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/FillSpans.java >> --- a/src/share/classes/sun/__java2d/loops/FillSpans.java Wed >> Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/FillSpans.java Sun >> Apr 27 14:33:45 >> 2014 -0300 >> @@ -45,7 +45,7 @@ >> */ >> public class FillSpans extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "FillSpans(...)".toString(); >> + public final static String methodSignature = >> "FillSpans(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/MaskBlit.java >> --- a/src/share/classes/sun/__java2d/loops/MaskBlit.java Wed Apr >> 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/MaskBlit.java Sun Apr >> 27 14:33:45 >> 2014 -0300 >> @@ -48,7 +48,7 @@ >> >> public class MaskBlit extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "MaskBlit(...)".toString(); >> + public static final String methodSignature = "MaskBlit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/MaskFill.java >> --- a/src/share/classes/sun/__java2d/loops/MaskFill.java Wed Apr >> 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/MaskFill.java Sun Apr >> 27 14:33:45 >> 2014 -0300 >> @@ -50,11 +50,11 @@ >> */ >> public class MaskFill extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "MaskFill(...)".toString(); >> + public static final String methodSignature = "MaskFill(...)"; >> public static final String fillPgramSignature = >> - "FillAAPgram(...)".toString(); >> + "FillAAPgram(...)"; >> public static final String drawPgramSignature = >> - "DrawAAPgram(...)".toString(); >> + "DrawAAPgram(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/ScaledBlit.java >> --- a/src/share/classes/sun/__java2d/loops/ScaledBlit.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/ScaledBlit.java Sun >> Apr 27 >> 14:33:45 2014 -0300 >> @@ -45,7 +45,7 @@ >> >> public class ScaledBlit extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "ScaledBlit(...)".toString(); >> + public static final String methodSignature = >> "ScaledBlit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/TransformBlit.java >> --- a/src/share/classes/sun/__java2d/loops/TransformBlit.__java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/TransformBlit.__java >> Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -47,7 +47,7 @@ >> public class TransformBlit extends GraphicsPrimitive >> { >> public static final String methodSignature = >> - "TransformBlit(...)".toString(__); >> + "TransformBlit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/TransformHelper.java >> --- >> a/src/share/classes/sun/__java2d/loops/TransformHelper.__java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/TransformHelper.__java >> Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -46,7 +46,7 @@ >> public class TransformHelper extends GraphicsPrimitive >> { >> public static final String methodSignature = >> - "TransformHelper(...)".__toString(); >> + "TransformHelper(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/misc/__ >> ExtensionInfo.java >> --- a/src/share/classes/sun/misc/__ExtensionInfo.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/misc/__ExtensionInfo.java Sun Apr 27 >> 14:33:45 >> 2014 -0300 >> @@ -25,6 +25,7 @@ >> >> package sun.misc; >> >> +import java.util.Objects; >> import java.util.StringTokenizer; >> import java.util.jar.Attributes; >> import java.util.jar.Attributes.Name >> ; >> @@ -260,11 +261,11 @@ >> >> // Convert token into meaning number for comparision >> if (stk.hasMoreTokens()) >> - n = convertToken(stk.nextToken().__toString()); >> + n = >> convertToken(Objects.__requireNonNull(stk.nextToken()__)); >> >> // Convert token into meaning number for comparision >> if (ttk.hasMoreTokens()) >> - m = convertToken(ttk.nextToken().__toString()); >> + m = >> convertToken(Objects.__requireNonNull(ttk.nextToken()__)); >> >> if (n > m) >> return 1; >> diff -r e323c74edabd >> src/share/classes/sun/tools/__jconsole/inspector/Utils.java >> --- >> a/src/share/classes/sun/tools/__jconsole/inspector/Utils.java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/tools/__jconsole/inspector/Utils.java >> Sun Apr 27 >> 14:33:45 2014 -0300 >> @@ -378,7 +378,7 @@ >> if (userInput instanceof XObject) { >> result[i] = ((XObject) userInput).getObject(); >> } else { >> - result[i] = >> createObjectFromString(params[__i].toString(), >> + result[i] = >> createObjectFromString(__Objects.requireNonNull(params[__i]), >> (String) userInput); >> } >> } >> >> >> >> >> On Sun, Apr 27, 2014 at 1:09 PM, Remi Forax > > wrote: >> >> On 04/27/2014 03:15 PM, Ot?vio Gon?alves de Santana wrote: >> >> There is an issue that was opened to remove redundant >> calls of toString() >> on String objects. [1] >> I went deep on all JVM sources and I found all, 32 >> changes. >> >> >> [1]https://bugs.openjdk.java.__net/browse/JDK-8015470 >> >> >> >> Otavio, >> calling toString() on a String has the side effect to >> implicitly check >> that the reference is not null. >> Do you have checked that for each redundant call, the String >> can never be >> null ? >> >> regards, >> R?mi >> >> >> >> >> diff -r e323c74edabd >> src/share/classes/com/sun/__tools/example/debug/tty/__ >> Commands.java >> --- >> a/src/share/classes/com/sun/__tools/example/debug/tty/__ >> Commands.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/com/sun/__tools/example/debug/tty/__ >> Commands.java >> Sat >> Apr 26 01:40:27 2014 -0300 >> @@ -1653,20 +1653,20 @@ >> String expr = t.nextToken(""); >> Value val = evaluate(expr); >> if (val == null) { >> - MessageOutput.println("expr is null", >> expr.toString()); >> + MessageOutput.println("expr is null", >> expr); >> } else if (dumpObject && (val instanceof >> ObjectReference) && >> !(val instanceof >> StringReference)) { >> ObjectReference obj = >> (ObjectReference)val; >> ReferenceType refType = >> obj.referenceType(); >> MessageOutput.println("expr is value", >> - new Object [] >> {expr.toString(), >> + new Object [] >> {expr, >> >> MessageOutput.format("grouping begin character")}); >> dump(obj, refType, refType); >> MessageOutput.println("__grouping >> end character"); >> } else { >> String strVal = getStringValue(); >> if (strVal != null) { >> - MessageOutput.println("expr is >> value", new Object [] >> {expr.toString(), >> + MessageOutput.println("expr is >> value", new Object [] >> {expr, >> >> strVal}); >> } >> } >> diff -r e323c74edabd >> src/share/classes/java/lang/__annotation/__ >> IncompleteAnnotationException.__java >> --- >> a/src/share/classes/java/lang/__annotation/__ >> IncompleteAnnotationException.__java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/java/lang/__annotation/__ >> IncompleteAnnotationException.__java >> Sat >> Apr 26 01:40:27 2014 -0300 >> @@ -56,7 +56,7 @@ >> Class >> annotationType, >> String elementName) { >> super(annotationType.getName() + " missing >> element " + >> - elementName.toString()); >> + elementName); >> >> this.annotationType = annotationType; >> this.elementName = elementName; >> diff -r e323c74edabd >> src/share/classes/java/text/__DateFormatSymbols.java >> --- >> a/src/share/classes/java/text/__DateFormatSymbols.java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/java/text/__DateFormatSymbols.java >> Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -593,8 +593,8 @@ >> * pattern characters. >> */ >> public void setLocalPatternChars(String >> newLocalPatternChars) { >> - // Call toString() to throw an NPE in case the >> argument is null >> - localPatternChars = >> newLocalPatternChars.toString(__); >> + >> + localPatternChars = Objects.requireNonNull( >> newLocalPatternChars); >> cachedHashCode = 0; >> } >> >> diff -r e323c74edabd >> src/share/classes/javax/__management/modelmbean/__ >> DescriptorSupport.java >> --- >> a/src/share/classes/javax/__management/modelmbean/__ >> DescriptorSupport.java >> Wed >> Apr 23 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/javax/__management/modelmbean/__ >> DescriptorSupport.java >> Sat >> Apr 26 01:40:27 2014 -0300 >> @@ -665,7 +665,7 @@ >> "getFieldNames()", >> "Field is null"); >> } >> } else { >> - responseFields[i] = >> currElement.getKey().toString(__); >> + responseFields[i] = currElement.getKey(); >> } >> } >> >> @@ -929,8 +929,8 @@ >> if (currElement != null) { >> if (currElement.getValue() != null) { >> // validate the field valued... >> - if >> (validateField((currElement.__getKey()).toString(), >> - >> (currElement.getValue()).__toString())) { >> + if >> (validateField((currElement.__getKey()), >> + >> (currElement.getValue()))) { >> continue; >> } else { >> if >> (MODELMBEAN_LOGGER.isLoggable(__Level.FINEST)) >> { >> diff -r e323c74edabd src/share/classes/javax/swing/ >> text/html/FormView.java >> --- >> a/src/share/classes/javax/__swing/text/html/FormView.java >> Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/javax/__swing/text/html/FormView.java >> Sat >> Apr 26 >> 01:40:27 2014 -0300 >> @@ -478,7 +478,7 @@ >> >> base.getPort(), base.getFile()) >> : new URL(base, action); >> if (!isPostMethod) { >> - String query = data.toString(); >> + String query = data; >> actionURL = new URL(actionURL + "?" >> + query); >> } >> } catch (MalformedURLException e) { >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/Blit.java >> --- a/src/share/classes/sun/__java2d/loops/Blit.java Wed >> Apr 23 11:35:40 >> 2014 >> -0700 >> +++ b/src/share/classes/sun/__java2d/loops/Blit.java Sat >> Apr 26 01:40:27 >> 2014 >> -0300 >> @@ -50,7 +50,7 @@ >> >> public class Blit extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "Blit(...)".toString(); >> + public static final String methodSignature = >> "Blit(...)"; >> >> public static final int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/BlitBg.java >> --- a/src/share/classes/sun/__java2d/loops/BlitBg.java >> Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/BlitBg.java >> Sat Apr 26 01:40:27 >> 2014 -0300 >> @@ -54,7 +54,7 @@ >> */ >> public class BlitBg extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "BlitBg(...)".toString(); >> + public static final String methodSignature = >> "BlitBg(...)"; >> >> public static final int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/ >> loops/DrawGlyphList.java >> --- >> a/src/share/classes/sun/__java2d/loops/DrawGlyphList.__ >> java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/DrawGlyphList.__ >> java >> Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -39,7 +39,7 @@ >> */ >> public class DrawGlyphList extends GraphicsPrimitive { >> >> - public final static String methodSignature = >> "DrawGlyphList(...)".toString(__); >> + public final static String methodSignature = >> "DrawGlyphList(...)"; >> >> public final static int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/ >> loops/DrawGlyphListAA.java >> --- >> a/src/share/classes/sun/__java2d/loops/DrawGlyphListAA._ >> _java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/DrawGlyphListAA._ >> _java >> Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -39,7 +39,7 @@ >> */ >> public class DrawGlyphListAA extends >> GraphicsPrimitive { >> >> - public final static String methodSignature = >> "DrawGlyphListAA(...)".__toString(); >> + public final static String methodSignature = >> "DrawGlyphListAA(...)"; >> >> public final static int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/_ >> _loops/DrawGlyphListLCD.java >> --- >> a/src/share/classes/sun/__java2d/loops/DrawGlyphListLCD. >> __java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/DrawGlyphListLCD. >> __java >> Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -40,7 +40,7 @@ >> public class DrawGlyphListLCD extends >> GraphicsPrimitive { >> >> public final static String >> - methodSignature = >> "DrawGlyphListLCD(...)".__toString(); >> + methodSignature = "DrawGlyphListLCD(...)"; >> >> public final static int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/DrawLine.java >> --- a/src/share/classes/sun/__java2d/loops/DrawLine.java >> Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/DrawLine.java >> Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class DrawLine extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawLine(...)".toString(); >> + public final static String methodSignature = >> "DrawLine(...)"; >> >> public final static int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/_ >> _loops/DrawParallelogram.java >> --- >> a/src/share/classes/sun/__java2d/loops/__ >> DrawParallelogram.java >> Wed Apr >> 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/__ >> DrawParallelogram.java >> Sat Apr >> 26 >> 01:40:27 2014 -0300 >> @@ -43,7 +43,7 @@ >> public class DrawParallelogram extends >> GraphicsPrimitive >> { >> public final static String methodSignature = >> - "DrawParallelogram(...)".__toString(); >> + "DrawParallelogram(...)"; >> >> public final static int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/DrawPath.java >> --- a/src/share/classes/sun/__java2d/loops/DrawPath.java >> Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/DrawPath.java >> Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -39,7 +39,7 @@ >> public class DrawPath extends GraphicsPrimitive { >> >> public final static String methodSignature = >> - "DrawPath(...)".toString(); >> + "DrawPath(...)"; >> >> public final static int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/DrawPolygons.java >> --- >> a/src/share/classes/sun/__java2d/loops/DrawPolygons.java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/DrawPolygons.java >> Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -41,7 +41,7 @@ >> */ >> public class DrawPolygons extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawPolygons(...)".toString()__; >> + public final static String methodSignature = >> "DrawPolygons(...)"; >> >> public final static int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/DrawRect.java >> --- a/src/share/classes/sun/__java2d/loops/DrawRect.java >> Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/DrawRect.java >> Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class DrawRect extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawRect(...)".toString(); >> + public final static String methodSignature = >> "DrawRect(...)"; >> >> public final static int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/_ >> _loops/FillParallelogram.java >> --- >> a/src/share/classes/sun/__java2d/loops/__ >> FillParallelogram.java >> Wed Apr >> 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/__ >> FillParallelogram.java >> Sat Apr >> 26 >> 01:40:27 2014 -0300 >> @@ -41,7 +41,7 @@ >> public class FillParallelogram extends >> GraphicsPrimitive >> { >> public final static String methodSignature = >> - "FillParallelogram(...)".__toString(); >> + "FillParallelogram(...)"; >> >> public final static int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/FillPath.java >> --- a/src/share/classes/sun/__java2d/loops/FillPath.java >> Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/FillPath.java >> Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -39,7 +39,7 @@ >> public class FillPath extends GraphicsPrimitive { >> >> public final static String methodSignature = >> - "FillPath(...)".toString(); >> + "FillPath(...)"; >> >> public final static int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/FillRect.java >> --- a/src/share/classes/sun/__java2d/loops/FillRect.java >> Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/FillRect.java >> Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class FillRect extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "FillRect(...)".toString(); >> + public final static String methodSignature = >> "FillRect(...)"; >> >> public final static int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/FillSpans.java >> --- >> a/src/share/classes/sun/__java2d/loops/FillSpans.java >> Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/FillSpans.java >> Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -45,7 +45,7 @@ >> */ >> public class FillSpans extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "FillSpans(...)".toString(); >> + public final static String methodSignature = >> "FillSpans(...)"; >> >> public final static int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/MaskBlit.java >> --- a/src/share/classes/sun/__java2d/loops/MaskBlit.java >> Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/MaskBlit.java >> Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -48,7 +48,7 @@ >> >> public class MaskBlit extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "MaskBlit(...)".toString(); >> + public static final String methodSignature = >> "MaskBlit(...)"; >> >> public static final int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/MaskFill.java >> --- a/src/share/classes/sun/__java2d/loops/MaskFill.java >> Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/__java2d/loops/MaskFill.java >> Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -50,11 +50,11 @@ >> */ >> public class MaskFill extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "MaskFill(...)".toString(); >> + public static final String methodSignature = >> "MaskFill(...)"; >> public static final String fillPgramSignature = >> - "FillAAPgram(...)".toString(); >> + "FillAAPgram(...)"; >> public static final String drawPgramSignature = >> - "DrawAAPgram(...)".toString(); >> + "DrawAAPgram(...)"; >> >> public static final int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/__loops/ScaledBlit.java >> --- >> a/src/share/classes/sun/__java2d/loops/ScaledBlit.java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/ScaledBlit.java >> Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -45,7 +45,7 @@ >> >> public class ScaledBlit extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "ScaledBlit(...)".toString(); >> + public static final String methodSignature = >> "ScaledBlit(...)"; >> >> public static final int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/ >> loops/TransformBlit.java >> --- >> a/src/share/classes/sun/__java2d/loops/TransformBlit.__ >> java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/TransformBlit.__ >> java >> Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -47,7 +47,7 @@ >> public class TransformBlit extends GraphicsPrimitive >> { >> public static final String methodSignature = >> - "TransformBlit(...)".toString(__); >> + "TransformBlit(...)"; >> >> public static final int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/ >> loops/TransformHelper.java >> --- >> a/src/share/classes/sun/__java2d/loops/TransformHelper._ >> _java >> Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/__java2d/loops/TransformHelper._ >> _java >> Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -46,7 +46,7 @@ >> public class TransformHelper extends GraphicsPrimitive >> { >> public static final String methodSignature = >> - "TransformHelper(...)".__toString(); >> + "TransformHelper(...)"; >> >> public static final int primTypeID = >> makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/misc/__ExtensionInfo.java >> --- a/src/share/classes/sun/misc/__ExtensionInfo.java >> Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/misc/__ExtensionInfo.java >> Sat Apr 26 01:40:27 >> 2014 -0300 >> @@ -260,11 +260,11 @@ >> >> // Convert token into meaning number for >> comparision >> if (stk.hasMoreTokens()) >> - n = convertToken(stk.nextToken()._ >> _toString()); >> + n = convertToken(stk.nextToken()); >> >> // Convert token into meaning number for >> comparision >> if (ttk.hasMoreTokens()) >> - m = convertToken(ttk.nextToken()._ >> _toString()); >> + m = convertToken(ttk.nextToken()); >> >> if (n > m) >> return 1; >> diff -r e323c74edabd >> src/share/classes/sun/tools/__ >> jconsole/inspector/Utils.java >> --- >> a/src/share/classes/sun/tools/__jconsole/inspector/Utils. >> java >> Wed Apr >> 23 >> 11:35:40 2014 -0700 >> +++ >> b/src/share/classes/sun/tools/__jconsole/inspector/Utils. >> java >> Sat Apr >> 26 >> 01:40:27 2014 -0300 >> @@ -378,7 +378,7 @@ >> if (userInput instanceof XObject) { > > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From miroslav.kos at oracle.com Mon Apr 28 12:01:08 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Mon, 28 Apr 2014 14:01:08 +0200 Subject: RFR: 8040754: Break the circular dependency between SAAJ and JAXB Message-ID: <535E4304.8050906@oracle.com> Hi, this is review request for: 8040754: Break the circular dependency between SAAJ and JAXB JBS: https://bugs.openjdk.java.net/browse/JDK-8040754 WEBREV: http://cr.openjdk.java.net/~mkos/8040754/jaxws.01/ It is basically moving classes in order to fix dependency between SAAJ, JAX-B and JAX-WS. Mandy, if it is approved, could I ask you for sponsoring the change? Thanks Miran From otaviojava at java.net Mon Apr 28 13:28:37 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Mon, 28 Apr 2014 10:28:37 -0300 Subject: Remove redundant calls of toString() In-Reply-To: <79BD36D4-9743-4321-94A1-6F1C6AE6F68F@oracle.com> References: <79BD36D4-9743-4321-94A1-6F1C6AE6F68F@oracle.com> Message-ID: Done. Link: https://dl.dropboxusercontent.com/u/16109193/open_jdk/string_to_string_uncessary.zip On Mon, Apr 28, 2014 at 4:34 AM, Paul Sandoz wrote: > Hi Ot?vio, > > Is there anyway you can experiment with publishing a webrev to dropbox or > github, preferably so that it is browsable, otherwise the zip? > > Unfortunately the patches are hard to review, especially in response to > reviews where code is updated. > > I realize until you have an openjdk account you are somewhat in "no-mans" > land, but i strongly suspect using one of the above mentioned services is > fairly easy to use, and therefore will make it easier to accept such > patches. > > Paul. > > On Apr 27, 2014, at 3:15 PM, Ot?vio Gon?alves de Santana < > otaviopolianasantana at gmail.com> wrote: > > > There is an issue that was opened to remove redundant calls of toString() > > on String objects. [1] > > I went deep on all JVM sources and I found all, 32 changes. > > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From otaviojava at java.net Mon Apr 28 13:30:00 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Mon, 28 Apr 2014 10:30:00 -0300 Subject: inefficient indexof when String has one length In-Reply-To: References: <535BE93A.90604@oracle.com> <535CF26A.8090507@oracle.com> <535CF67B.9050006@oracle.com> <55638F81-25EF-4B1F-9804-0991B3180FAC@oracle.com> Message-ID: link: https://dl.dropboxusercontent.com/u/16109193/open_jdk/index_of_with_char.zip On Mon, Apr 28, 2014 at 10:25 AM, Ot?vio Gon?alves de Santana < otaviojava at java.net> wrote: > > link: > https://dl.dropboxusercontent.com/u/16109193/open_jdk/index_of_with_char.zip > > > On Mon, Apr 28, 2014 at 4:42 AM, Paul Sandoz wrote: > >> On Apr 27, 2014, at 2:22 PM, Claes Redestad >> wrote: >> > Possibly a few bytes in static class footprint, sure. Maybe this is >> something javac should optimize (javap on some trivial examples suggests >> this doesn't happen) rather than trying to root out all suboptimal cases, >> especially since there are bound to be a lot more code out there using >> similar patterns? >> > >> >> While javac can and perhaps should be smarter in certain cases like this >> i am still supportive of this change in the JDK esp. so if it is something >> trivially detectable by IDEs; it's low-hanging fruit. >> >> Paul. >> > > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 > > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From pbenedict at apache.org Mon Apr 28 13:41:24 2014 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 28 Apr 2014 08:41:24 -0500 Subject: Remove redundant calls of toString() In-Reply-To: References: <79BD36D4-9743-4321-94A1-6F1C6AE6F68F@oracle.com> Message-ID: I have to say that the expected NPE is quite "hidden" in the current code. I am actually surprised someone was able to catch that. The use of Objects.requreNonNull() is way more clear and I prefer that approach for the sake of clarity. On Mon, Apr 28, 2014 at 8:28 AM, Ot?vio Gon?alves de Santana < otaviojava at java.net> wrote: > Done. > Link: > > https://dl.dropboxusercontent.com/u/16109193/open_jdk/string_to_string_uncessary.zip > > > On Mon, Apr 28, 2014 at 4:34 AM, Paul Sandoz > wrote: > > > Hi Ot?vio, > > > > Is there anyway you can experiment with publishing a webrev to dropbox or > > github, preferably so that it is browsable, otherwise the zip? > > > > Unfortunately the patches are hard to review, especially in response to > > reviews where code is updated. > > > > I realize until you have an openjdk account you are somewhat in "no-mans" > > land, but i strongly suspect using one of the above mentioned services is > > fairly easy to use, and therefore will make it easier to accept such > > patches. > > > > Paul. > > > > On Apr 27, 2014, at 3:15 PM, Ot?vio Gon?alves de Santana < > > otaviopolianasantana at gmail.com> wrote: > > > > > There is an issue that was opened to remove redundant calls of > toString() > > > on String objects. [1] > > > I went deep on all JVM sources and I found all, 32 changes. > > > > > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 > -- Cheers, Paul From chris.hegarty at oracle.com Mon Apr 28 14:30:12 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 28 Apr 2014 15:30:12 +0100 Subject: RFR: 8040754: Break the circular dependency between SAAJ and JAXB In-Reply-To: <535E4304.8050906@oracle.com> References: <535E4304.8050906@oracle.com> Message-ID: <535E65F4.9060806@oracle.com> Miran, This change looks good to me. Reviewed. I applied the patch to the latest jdk9/dev and all tests pass as expected. I see Mandy is sponsoring this for you. -Chris. On 28/04/14 13:01, Miroslav Kos wrote: > Hi, > > this is review request for: 8040754: Break the circular dependency > between SAAJ and JAXB > JBS: https://bugs.openjdk.java.net/browse/JDK-8040754 > WEBREV: http://cr.openjdk.java.net/~mkos/8040754/jaxws.01/ > > It is basically moving classes in order to fix dependency between SAAJ, > JAX-B and JAX-WS. > > Mandy, if it is approved, could I ask you for sponsoring the change? > > Thanks > Miran From tom.hawtin at oracle.com Mon Apr 28 15:21:04 2014 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 28 Apr 2014 16:21:04 +0100 Subject: Creating Thread in AccessController.doPrivileged() In-Reply-To: References: Message-ID: <535E71E0.7000500@oracle.com> On 24/04/2014 06:06, Zhong Yu wrote: > If a thread is created inside AccessController.doPrivileged(), it > seems to inherit AccessControlContext from the calling thread, is that > the expected/specified behavior? It should inherit the acc from when it was created. If that context was privileged by the use of doPrivileged, then it will follow the normal rules. The restricted do privileged in Java SE 8 behaves peculiarly (as specified). > I'm asking because I tried to solve this problem: A spawned Thread > contains strong references to all call stack class loaders through > Thread.inheritedAccessControlContext. I try to avoid that and make > sure that only the immediate caller class loader is referenced; my > concern is rather garbage collection than permissions. Is there anyway > to achieve that? You need to make sure you aren't doing something too privileged. If you're going to use doPrivileged in this manner, you should check that the calling context before the doPrivilieged has at least the permissions as inside. In particular, using only the immediate caller permissions is problematic. Tom From claes.redestad at oracle.com Mon Apr 28 15:43:48 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 28 Apr 2014 17:43:48 +0200 Subject: Remove redundant calls of toString() In-Reply-To: <535DFBDE.6030701@oracle.com> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> Message-ID: <535E7734.7050602@oracle.com> On 04/28/2014 08:57 AM, David Holmes wrote: > On 28/04/2014 1:05 PM, Ot?vio Gon?alves de Santana wrote: >> In my opinion not, because Objects.requireNonNull is more readable than >> just string.toString. This way is more understandable which field is >> required and doesn't impact on performance. > > An invocation of requireNonNull is potentially more expensive than the > implicit null check that happens with foo.toString(). > > David > ----- My thought was that these two would be inlined to the exact same thing, so I did a quick test to see what happens when you do foo.toString() versus Objects.requireNonNull(foo) on a set of randomly generated String[]'s with different amounts of null elements(0p: no null entries, 1p: 1% null entries etc): Benchmark Mode Samples Mean Mean error Units s.m.ThrowAwayBenchmark.nullToString0p thrpt 6 356653.044 3573.707 ops/ms s.m.ThrowAwayBenchmark.nullToString1p thrpt 6 353128.903 2764.102 ops/ms s.m.ThrowAwayBenchmark.nullToString10p thrpt 6 297956.571 9580.251 ops/ms s.m.ThrowAwayBenchmark.nullToString50p thrpt 6 158172.036 1893.096 ops/ms s.m.ThrowAwayBenchmark.nullToString100p thrpt 6 18194.614 472.091 ops/ms s.m.ThrowAwayBenchmark.requireNonNull0p thrpt 6 357855.126 2979.090 ops/ms s.m.ThrowAwayBenchmark.requireNonNull1p thrpt 6 67601.134 7004.689 ops/ms s.m.ThrowAwayBenchmark.requireNonNull10p thrpt 6 8150.595 538.970 ops/ms s.m.ThrowAwayBenchmark.requireNonNull50p thrpt 6 1604.919 220.903 ops/ms s.m.ThrowAwayBenchmark.requireNonNull100p thrpt 6 820.626 60.752 ops/ms Yikes! As long as the value is never null they're inlined nicely and neither have the upper hand performance-wise, but as soon as you get some null values, Objects.requireNonNull degenerates much faster than its foo.toString counterpart. I think this is a JIT issue - optimizing exception-paths might not be the highest priority, but Objects.requireNonNull is used pretty extensively in the JDK and my expectation would be that it shouldn't degrade performance when things actually are null now and then. /Claes From lowasser at google.com Mon Apr 28 16:24:26 2014 From: lowasser at google.com (Louis Wasserman) Date: Mon, 28 Apr 2014 09:24:26 -0700 Subject: Remove redundant calls of toString() In-Reply-To: <535E7734.7050602@oracle.com> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> <535E7734.7050602@oracle.com> Message-ID: - public final static String methodSignature = "DrawGlyphList(...)".toString(); + public final static String methodSignature = "DrawGlyphList(...)"; I conjecture that this, and other similar examples, are to avoid having the string be a compile-time constant that can be inlined into other files. Has anyone checked that there aren't any issues arising from changing this? On Mon, Apr 28, 2014 at 8:43 AM, Claes Redestad wrote: > On 04/28/2014 08:57 AM, David Holmes wrote: > >> On 28/04/2014 1:05 PM, Ot?vio Gon?alves de Santana wrote: >> >>> In my opinion not, because Objects.requireNonNull is more readable than >>> just string.toString. This way is more understandable which field is >>> required and doesn't impact on performance. >>> >> >> An invocation of requireNonNull is potentially more expensive than the >> implicit null check that happens with foo.toString(). >> >> David >> ----- >> > > My thought was that these two would be inlined to the exact same thing, so > I did a quick test to see what happens when you do foo.toString() versus > Objects.requireNonNull(foo) on a set of randomly generated String[]'s with > different amounts of null elements(0p: no null entries, 1p: 1% null entries > etc): > > Benchmark Mode Samples Mean > Mean error Units > s.m.ThrowAwayBenchmark.nullToString0p thrpt 6 356653.044 > 3573.707 ops/ms > s.m.ThrowAwayBenchmark.nullToString1p thrpt 6 353128.903 > 2764.102 ops/ms > s.m.ThrowAwayBenchmark.nullToString10p thrpt 6 297956.571 > 9580.251 ops/ms > s.m.ThrowAwayBenchmark.nullToString50p thrpt 6 158172.036 > 1893.096 ops/ms > s.m.ThrowAwayBenchmark.nullToString100p thrpt 6 18194.614 > 472.091 ops/ms > s.m.ThrowAwayBenchmark.requireNonNull0p thrpt 6 357855.126 > 2979.090 ops/ms > s.m.ThrowAwayBenchmark.requireNonNull1p thrpt 6 67601.134 > 7004.689 ops/ms > s.m.ThrowAwayBenchmark.requireNonNull10p thrpt 6 8150.595 > 538.970 ops/ms > s.m.ThrowAwayBenchmark.requireNonNull50p thrpt 6 1604.919 > 220.903 ops/ms > s.m.ThrowAwayBenchmark.requireNonNull100p thrpt 6 820.626 > 60.752 ops/ms > > Yikes! As long as the value is never null they're inlined nicely and > neither have the upper hand performance-wise, but as soon as you get some > null values, Objects.requireNonNull degenerates much faster than its > foo.toString counterpart. I think this is a JIT issue - optimizing > exception-paths might not be the highest priority, but > Objects.requireNonNull is used pretty extensively in the JDK and my > expectation would be that it shouldn't degrade performance when things > actually are null now and then. > > /Claes > -- Louis Wasserman From brian.burkhalter at oracle.com Mon Apr 28 17:53:19 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 28 Apr 2014 10:53:19 -0700 Subject: Guidance about binary / data files for JTREG tests Message-ID: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> This follows from my posting of last week http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026604.html Firstly, I was informed that there are not supposed to be binary files in the jdk9/jdk/test tree. My webrev listed in the above post includes one such file, a GZIPped text file of prime numbers. Apparently this file as-is should not be checked in to the repository. I notice however that there are already a number of binary files checked in under test. The list given below includes some of these. All the files in the list are larger than the binary file in the webrev in question. To get to the point, this raises a few questions: 1 - Binary test data files are in fact illegal to check in, correct? 2 - What is the size limit for test data files which may be checked in? 3 - Is there any plan to create some well known location outside the repository where large test data files may be hosted for access by tests? Meanwhile I suppose that I could convert my test file and use the sun.misc.UU{En,De}coder classes to handle it in the test. If the answers to the above questions are already included in some OpenJDK FAQ that I overlooked, please excuse the redundancy and noise that this message represents. Thanks, Brian test/com/sun/crypto/provider/TLS/prfdata.txt test/com/sun/net/httpserver/docs/test1/largefile.txt test/java/lang/annotation/UnitTest.java test/java/lang/instrument/BigClass.java test/java/math/BigDecimal/DivideMcTests.java test/java/util/Locale/tools/language-subtag-registry.txt test/sun/net/www/protocol/jar/foo1.jar test/sun/nio/cs/EUC_TW_OLD.java test/sun/nio/cs/OLD/EUC_CN_OLD.java test/sun/nio/cs/OLD/EUC_KR_OLD.java test/sun/nio/cs/OLD/GBK_OLD.java test/sun/nio/cs/OLD/IBM1381_OLD.java test/sun/nio/cs/OLD/IBM1383_OLD.java test/sun/nio/cs/OLD/IBM930_OLD.java test/sun/nio/cs/OLD/IBM933_OLD.java test/sun/nio/cs/OLD/IBM935_OLD.java test/sun/nio/cs/OLD/IBM937_OLD.java test/sun/nio/cs/OLD/IBM939_OLD.java test/sun/nio/cs/OLD/IBM942_OLD.java test/sun/nio/cs/OLD/IBM943_OLD.java test/sun/nio/cs/OLD/IBM948_OLD.java test/sun/nio/cs/OLD/IBM949_OLD.java test/sun/nio/cs/OLD/IBM950_OLD.java test/sun/nio/cs/OLD/IBM970_OLD.java test/sun/nio/cs/OLD/Johab_OLD.java test/sun/nio/cs/OLD/MS932DB.java test/sun/nio/cs/OLD/MS936_OLD.java test/sun/nio/cs/OLD/MS949_OLD.java test/sun/nio/cs/OLD/MS950_OLD.java test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll test/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll test/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll test/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll test/sun/security/pkcs11/nss/src/nss-3.13.1.tar.gz test/sun/security/pkcs11/tls/prfdata.txt test/sun/text/resources/LocaleData test/sun/tools/jhat/hprof.bin test/sun/tools/jhat/jmap.bin test/tools/pack200/pack200-verifier/data/golden.jar From mandy.chung at oracle.com Mon Apr 28 18:25:47 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 28 Apr 2014 11:25:47 -0700 Subject: RFR: 8040754: Break the circular dependency between SAAJ and JAXB In-Reply-To: <535E65F4.9060806@oracle.com> References: <535E4304.8050906@oracle.com> <535E65F4.9060806@oracle.com> Message-ID: <535E9D2B.6060009@oracle.com> Miran, Looks good to me. I'll sponsor this patch for you. Mandy On 4/28/14 7:30 AM, Chris Hegarty wrote: > Miran, > > This change looks good to me. Reviewed. > > I applied the patch to the latest jdk9/dev and all tests pass as > expected. > > I see Mandy is sponsoring this for you. > > -Chris. > > On 28/04/14 13:01, Miroslav Kos wrote: >> Hi, >> >> this is review request for: 8040754: Break the circular dependency >> between SAAJ and JAXB >> JBS: https://bugs.openjdk.java.net/browse/JDK-8040754 >> WEBREV: http://cr.openjdk.java.net/~mkos/8040754/jaxws.01/ >> >> It is basically moving classes in order to fix dependency between SAAJ, >> JAX-B and JAX-WS. >> >> Mandy, if it is approved, could I ask you for sponsoring the change? >> >> Thanks >> Miran From fweimer at redhat.com Mon Apr 28 18:52:11 2014 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 28 Apr 2014 20:52:11 +0200 Subject: Guidance about binary / data files for JTREG tests In-Reply-To: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> References: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> Message-ID: <535EA35B.6070009@redhat.com> On 04/28/2014 07:53 PM, Brian Burkhalter wrote: > Meanwhile I suppose that I could convert my test file and use the sun.misc.UU{En,De}coder classes to handle it in the test. Uh-oh, we have java.util.Base64 these days. But in this case, it's probably simpler to use this code snippet instead of adding 235 KiB of incompressible binary data to the source code. private static boolean[] primes(int n) { boolean[] primes = new boolean[n + 1]; Arrays.fill(primes, true); primes[0] = false; primes[1] = false; for (int p = 2; p * p < n; ) { for (int i = 2 * p; i < primes.length; i += p) primes[i] = false; do ++p; while (!primes[p]); } return primes; } (I hope it's correct, but you get the idea?) Anyway, for the first 100K primes, it runs in roughly 400 ms on my machine, including JVM startup and teardown. That should be completely negligible compared to actually testing all the numbers for primality using a any non-sieve algorithm. -- Florian Weimer / Red Hat Product Security Team From brian.burkhalter at oracle.com Mon Apr 28 19:01:17 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 28 Apr 2014 12:01:17 -0700 Subject: Guidance about binary / data files for JTREG tests In-Reply-To: <535EA35B.6070009@redhat.com> References: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> <535EA35B.6070009@redhat.com> Message-ID: <280FEF6F-BAFA-4687-9446-B1C2C80EDF93@oracle.com> On Apr 28, 2014, at 11:52 AM, Florian Weimer wrote: > On 04/28/2014 07:53 PM, Brian Burkhalter wrote: > >> Meanwhile I suppose that I could convert my test file and use the sun.misc.UU{En,De}coder classes to handle it in the test. > > Uh-oh, we have java.util.Base64 these days. D?oh. I should have known as I was working on something in the code base recently. > But in this case, it's probably simpler to use this code snippet instead of adding 235 KiB of incompressible binary data to the source code. > > [?] > > (I hope it's correct, but you get the idea?) > > Anyway, for the first 100K primes, it runs in roughly 400 ms on my machine, including JVM startup and teardown. That should be completely negligible compared to actually testing all the numbers for primality using a any non-sieve algorithm. Thanks. I should have thought of that myself. I?ll re-work the thing and re-post an updated patch. Regards, Brian From philip.race at oracle.com Mon Apr 28 21:47:51 2014 From: philip.race at oracle.com (Phil Race) Date: Mon, 28 Apr 2014 14:47:51 -0700 Subject: Remove redundant calls of toString() In-Reply-To: References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> <535E7734.7050602@oracle.com> Message-ID: <535ECC87.5030808@oracle.com> I am quite sure that you are right that these were deliberate so I am adding Jim who was the author of all of the 2d ones to explain the intent. BTW Ot?vio, changes in 2D code like this should not slip by on the core-libs list. It ought to go to 2d-dev. -phil. On 4/28/2014 9:24 AM, Louis Wasserman wrote: > - public final static String methodSignature = > "DrawGlyphList(...)".toString(); > + public final static String methodSignature = "DrawGlyphList(...)"; > > I conjecture that this, and other similar examples, are to avoid having the > string be a compile-time constant that can be inlined into other files. > Has anyone checked that there aren't any issues arising from changing this? > > > > > n 4/27/2014 6:15 AM, Ot?vio Gon?alves de Santana wrote: > There is an issue that was opened to remove redundant calls of toString() > on String objects. [1] > I went deep on all JVM sources and I found all, 32 changes. > > > [1]https://bugs.openjdk.java.net/browse/JDK-8015470 > > diff -r e323c74edabd src/share/classes/javax/swing/text/html/FormView.java > --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/javax/swing/text/html/FormView.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -478,7 +478,7 @@ > base.getPort(), base.getFile()) > : new URL(base, action); > if (!isPostMethod) { > - String query = data.toString(); > + String query = data; > actionURL = new URL(actionURL + "?" + query); > } > } catch (MalformedURLException e) { > diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java > --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 2014 > -0700 > +++ b/src/share/classes/sun/java2d/loops/Blit.java Sat Apr 26 01:40:27 2014 > -0300 > @@ -50,7 +50,7 @@ > > public class Blit extends GraphicsPrimitive > { > - public static final String methodSignature = "Blit(...)".toString(); > + public static final String methodSignature = "Blit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java > --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -54,7 +54,7 @@ > */ > public class BlitBg extends GraphicsPrimitive > { > - public static final String methodSignature = "BlitBg(...)".toString(); > + public static final String methodSignature = "BlitBg(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphList.java > --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -39,7 +39,7 @@ > */ > public class DrawGlyphList extends GraphicsPrimitive { > > - public final static String methodSignature = > "DrawGlyphList(...)".toString(); > + public final static String methodSignature = "DrawGlyphList(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawGlyphListAA.java > --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -39,7 +39,7 @@ > */ > public class DrawGlyphListAA extends GraphicsPrimitive { > > - public final static String methodSignature = > "DrawGlyphListAA(...)".toString(); > + public final static String methodSignature = "DrawGlyphListAA(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java > --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -40,7 +40,7 @@ > public class DrawGlyphListLCD extends GraphicsPrimitive { > > public final static String > - methodSignature = "DrawGlyphListLCD(...)".toString(); > + methodSignature = "DrawGlyphListLCD(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java > --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class DrawLine extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawLine(...)".toString(); > + public final static String methodSignature = "DrawLine(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/loops/DrawParallelogram.java > --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -43,7 +43,7 @@ > public class DrawParallelogram extends GraphicsPrimitive > { > public final static String methodSignature = > - "DrawParallelogram(...)".toString(); > + "DrawParallelogram(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java > --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -39,7 +39,7 @@ > public class DrawPath extends GraphicsPrimitive { > > public final static String methodSignature = > - "DrawPath(...)".toString(); > + "DrawPath(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPolygons.java > --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -41,7 +41,7 @@ > */ > public class DrawPolygons extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawPolygons(...)".toString(); > + public final static String methodSignature = "DrawPolygons(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java > --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class DrawRect extends GraphicsPrimitive > { > - public final static String methodSignature = > "DrawRect(...)".toString(); > + public final static String methodSignature = "DrawRect(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd > src/share/classes/sun/java2d/loops/FillParallelogram.java > --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -41,7 +41,7 @@ > public class FillParallelogram extends GraphicsPrimitive > { > public final static String methodSignature = > - "FillParallelogram(...)".toString(); > + "FillParallelogram(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java > --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -39,7 +39,7 @@ > public class FillPath extends GraphicsPrimitive { > > public final static String methodSignature = > - "FillPath(...)".toString(); > + "FillPath(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java > --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -44,7 +44,7 @@ > */ > public class FillRect extends GraphicsPrimitive > { > - public final static String methodSignature = > "FillRect(...)".toString(); > + public final static String methodSignature = "FillRect(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java > --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -45,7 +45,7 @@ > */ > public class FillSpans extends GraphicsPrimitive > { > - public final static String methodSignature = > "FillSpans(...)".toString(); > + public final static String methodSignature = "FillSpans(...)"; > > public final static int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java > --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -48,7 +48,7 @@ > > public class MaskBlit extends GraphicsPrimitive > { > - public static final String methodSignature = > "MaskBlit(...)".toString(); > + public static final String methodSignature = "MaskBlit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java > --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 11:35:40 > 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -50,11 +50,11 @@ > */ > public class MaskFill extends GraphicsPrimitive > { > - public static final String methodSignature = > "MaskFill(...)".toString(); > + public static final String methodSignature = "MaskFill(...)"; > public static final String fillPgramSignature = > - "FillAAPgram(...)".toString(); > + "FillAAPgram(...)"; > public static final String drawPgramSignature = > - "DrawAAPgram(...)".toString(); > + "DrawAAPgram(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java > --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sat Apr 26 01:40:27 > 2014 -0300 > @@ -45,7 +45,7 @@ > > public class ScaledBlit extends GraphicsPrimitive > { > - public static final String methodSignature = > "ScaledBlit(...)".toString(); > + public static final String methodSignature = "ScaledBlit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/TransformBlit.java > --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -47,7 +47,7 @@ > public class TransformBlit extends GraphicsPrimitive > { > public static final String methodSignature = > - "TransformBlit(...)".toString(); > + "TransformBlit(...)"; > > public static final int primTypeID = makePrimTypeID(); > > diff -r e323c74edabd src/share/classes/sun/java2d/loops/TransformHelper.java > --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr 23 > 11:35:40 2014 -0700 > +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sat Apr 26 > 01:40:27 2014 -0300 > @@ -46,7 +46,7 @@ > public class TransformHelper extends GraphicsPrimitive > { > public static final String methodSignature = > - "TransformHelper(...)".toString(); > + "TransformHelper(...)"; > > public static final int primTypeID = makePrimTypeID(); > > From brian.burkhalter at oracle.com Mon Apr 28 22:09:10 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 28 Apr 2014 15:09:10 -0700 Subject: Guidance about binary / data files for JTREG tests In-Reply-To: <535EA35B.6070009@redhat.com> References: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> <535EA35B.6070009@redhat.com> Message-ID: For grins here?s an alternative implementation of your algorithm that is slower but likely takes less memory: private static BitSet primesBS(int n) { int nbits = n + 1; BitSet bs = new BitSet(nbits); bs.set(0, 2, true); for (int p = 2; p * p < n;) { for (int i = 2 * p; i < nbits; i += p) { bs.set(i, true); } do { ++p; } while (bs.get(p)); } return bs; } Note that in this case a set bit means NOT prime. Brian On Apr 28, 2014, at 11:52 AM, Florian Weimer wrote: > private static boolean[] primes(int n) { > boolean[] primes = new boolean[n + 1]; > Arrays.fill(primes, true); > primes[0] = false; > primes[1] = false; > for (int p = 2; p * p < n; ) { > for (int i = 2 * p; i < primes.length; i += p) > primes[i] = false; > do > ++p; > while (!primes[p]); > } > return primes; > } From james.graham at oracle.com Mon Apr 28 22:43:17 2014 From: james.graham at oracle.com (Jim Graham) Date: Mon, 28 Apr 2014 15:43:17 -0700 Subject: Remove redundant calls of toString() In-Reply-To: <535ECC87.5030808@oracle.com> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> <535E7734.7050602@oracle.com> <535ECC87.5030808@oracle.com> Message-ID: <535ED985.5040007@oracle.com> We refer to these strings as constants in many places. If you have: class Foo { static final String bar = ""; } class Blah { // uses Foo.bar } Then Blah will incorporate that string by content, not by reference. I don't know why this is done this way, but Strings are special in that static final versions of them are included by value just the way that static final primitive types are. As a result, we had huge duplications of these strings all over the place. But, this only happens when you initialize it to a constant "..." string. If it is the result of a method call (or probably a calculation), then it ends up being treated like any static final object and is included by reference. Thus, appending .toString(); to the "..." constant foils the "include by value" processing in the compiler... ...jim On 4/28/14 2:47 PM, Phil Race wrote: > I am quite sure that you are right that these were deliberate so > I am adding Jim who was the author of all of the 2d ones to explain the > intent. > > BTW Ot?vio, changes in 2D code like this should not slip by on the > core-libs list. > It ought to go to 2d-dev. > > -phil. > > On 4/28/2014 9:24 AM, Louis Wasserman wrote: >> - public final static String methodSignature = >> "DrawGlyphList(...)".toString(); >> + public final static String methodSignature = "DrawGlyphList(...)"; >> >> I conjecture that this, and other similar examples, are to avoid >> having the >> string be a compile-time constant that can be inlined into other files. >> Has anyone checked that there aren't any issues arising from >> changing this? >> >> >> >> >> > > n 4/27/2014 6:15 AM, Ot?vio Gon?alves de Santana wrote: >> There is an issue that was opened to remove redundant calls of toString() >> on String objects. [1] >> I went deep on all JVM sources and I found all, 32 changes. >> >> >> [1]https://bugs.openjdk.java.net/browse/JDK-8015470 >> >> diff -r e323c74edabd >> src/share/classes/javax/swing/text/html/FormView.java >> --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/javax/swing/text/html/FormView.java Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -478,7 +478,7 @@ >> base.getPort(), base.getFile()) >> : new URL(base, action); >> if (!isPostMethod) { >> - String query = data.toString(); >> + String query = data; >> actionURL = new URL(actionURL + "?" + query); >> } >> } catch (MalformedURLException e) { >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java >> --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 >> 2014 >> -0700 >> +++ b/src/share/classes/sun/java2d/loops/Blit.java Sat Apr 26 01:40:27 >> 2014 >> -0300 >> @@ -50,7 +50,7 @@ >> >> public class Blit extends GraphicsPrimitive >> { >> - public static final String methodSignature = "Blit(...)".toString(); >> + public static final String methodSignature = "Blit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java >> --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sat Apr 26 01:40:27 >> 2014 -0300 >> @@ -54,7 +54,7 @@ >> */ >> public class BlitBg extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "BlitBg(...)".toString(); >> + public static final String methodSignature = "BlitBg(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/DrawGlyphList.java >> --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -39,7 +39,7 @@ >> */ >> public class DrawGlyphList extends GraphicsPrimitive { >> >> - public final static String methodSignature = >> "DrawGlyphList(...)".toString(); >> + public final static String methodSignature = "DrawGlyphList(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/DrawGlyphListAA.java >> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -39,7 +39,7 @@ >> */ >> public class DrawGlyphListAA extends GraphicsPrimitive { >> >> - public final static String methodSignature = >> "DrawGlyphListAA(...)".toString(); >> + public final static String methodSignature = "DrawGlyphListAA(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java >> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -40,7 +40,7 @@ >> public class DrawGlyphListLCD extends GraphicsPrimitive { >> >> public final static String >> - methodSignature = "DrawGlyphListLCD(...)".toString(); >> + methodSignature = "DrawGlyphListLCD(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java >> --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class DrawLine extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawLine(...)".toString(); >> + public final static String methodSignature = "DrawLine(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/DrawParallelogram.java >> --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sat >> Apr 26 >> 01:40:27 2014 -0300 >> @@ -43,7 +43,7 @@ >> public class DrawParallelogram extends GraphicsPrimitive >> { >> public final static String methodSignature = >> - "DrawParallelogram(...)".toString(); >> + "DrawParallelogram(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java >> --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -39,7 +39,7 @@ >> public class DrawPath extends GraphicsPrimitive { >> >> public final static String methodSignature = >> - "DrawPath(...)".toString(); >> + "DrawPath(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPolygons.java >> --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -41,7 +41,7 @@ >> */ >> public class DrawPolygons extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawPolygons(...)".toString(); >> + public final static String methodSignature = "DrawPolygons(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java >> --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class DrawRect extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "DrawRect(...)".toString(); >> + public final static String methodSignature = "DrawRect(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/FillParallelogram.java >> --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed >> Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sat >> Apr 26 >> 01:40:27 2014 -0300 >> @@ -41,7 +41,7 @@ >> public class FillParallelogram extends GraphicsPrimitive >> { >> public final static String methodSignature = >> - "FillParallelogram(...)".toString(); >> + "FillParallelogram(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java >> --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -39,7 +39,7 @@ >> public class FillPath extends GraphicsPrimitive { >> >> public final static String methodSignature = >> - "FillPath(...)".toString(); >> + "FillPath(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java >> --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -44,7 +44,7 @@ >> */ >> public class FillRect extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "FillRect(...)".toString(); >> + public final static String methodSignature = "FillRect(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java >> --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -45,7 +45,7 @@ >> */ >> public class FillSpans extends GraphicsPrimitive >> { >> - public final static String methodSignature = >> "FillSpans(...)".toString(); >> + public final static String methodSignature = "FillSpans(...)"; >> >> public final static int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java >> --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -48,7 +48,7 @@ >> >> public class MaskBlit extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "MaskBlit(...)".toString(); >> + public static final String methodSignature = "MaskBlit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java >> --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 >> 11:35:40 >> 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -50,11 +50,11 @@ >> */ >> public class MaskFill extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "MaskFill(...)".toString(); >> + public static final String methodSignature = "MaskFill(...)"; >> public static final String fillPgramSignature = >> - "FillAAPgram(...)".toString(); >> + "FillAAPgram(...)"; >> public static final String drawPgramSignature = >> - "DrawAAPgram(...)".toString(); >> + "DrawAAPgram(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java >> --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sat Apr 26 >> 01:40:27 >> 2014 -0300 >> @@ -45,7 +45,7 @@ >> >> public class ScaledBlit extends GraphicsPrimitive >> { >> - public static final String methodSignature = >> "ScaledBlit(...)".toString(); >> + public static final String methodSignature = "ScaledBlit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/TransformBlit.java >> --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -47,7 +47,7 @@ >> public class TransformBlit extends GraphicsPrimitive >> { >> public static final String methodSignature = >> - "TransformBlit(...)".toString(); >> + "TransformBlit(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> diff -r e323c74edabd >> src/share/classes/sun/java2d/loops/TransformHelper.java >> --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr 23 >> 11:35:40 2014 -0700 >> +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sat Apr 26 >> 01:40:27 2014 -0300 >> @@ -46,7 +46,7 @@ >> public class TransformHelper extends GraphicsPrimitive >> { >> public static final String methodSignature = >> - "TransformHelper(...)".toString(); >> + "TransformHelper(...)"; >> >> public static final int primTypeID = makePrimTypeID(); >> >> > From brian.burkhalter at oracle.com Mon Apr 28 23:02:18 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 28 Apr 2014 16:02:18 -0700 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> Message-ID: <7B7A4981-680D-4755-B1DA-DE954CF587C4@oracle.com> Here is an updated patch http://cr.openjdk.java.net/~bpb/8026236/webrev.02/ which has been revised to obviate the need for a file source of prime numbers. Thanks, Brian On Apr 24, 2014, at 5:12 PM, Brian Burkhalter wrote: > I have posted an updated patch here: > > http://cr.openjdk.java.net/~bpb/8026236/webrev.01/ > > Thanks for your comments. From forax at univ-mlv.fr Tue Apr 29 07:31:20 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 29 Apr 2014 09:31:20 +0200 Subject: Remove redundant calls of toString() In-Reply-To: <535E7734.7050602@oracle.com> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> <535E7734.7050602@oracle.com> Message-ID: <535F5548.9020807@univ-mlv.fr> On 04/28/2014 05:43 PM, Claes Redestad wrote: > On 04/28/2014 08:57 AM, David Holmes wrote: >> On 28/04/2014 1:05 PM, Ot?vio Gon?alves de Santana wrote: >>> In my opinion not, because Objects.requireNonNull is more readable than >>> just string.toString. This way is more understandable which field is >>> required and doesn't impact on performance. >> >> An invocation of requireNonNull is potentially more expensive than >> the implicit null check that happens with foo.toString(). >> >> David >> ----- > > My thought was that these two would be inlined to the exact same > thing, so I did a quick test to see what happens when you do > foo.toString() versus Objects.requireNonNull(foo) on a set of randomly > generated String[]'s with different amounts of null elements(0p: no > null entries, 1p: 1% null entries etc): > > Benchmark Mode Samples Mean Mean > error Units > s.m.ThrowAwayBenchmark.nullToString0p thrpt 6 356653.044 > 3573.707 ops/ms > s.m.ThrowAwayBenchmark.nullToString1p thrpt 6 353128.903 > 2764.102 ops/ms > s.m.ThrowAwayBenchmark.nullToString10p thrpt 6 297956.571 > 9580.251 ops/ms > s.m.ThrowAwayBenchmark.nullToString50p thrpt 6 158172.036 > 1893.096 ops/ms > s.m.ThrowAwayBenchmark.nullToString100p thrpt 6 18194.614 > 472.091 ops/ms > s.m.ThrowAwayBenchmark.requireNonNull0p thrpt 6 357855.126 > 2979.090 ops/ms > s.m.ThrowAwayBenchmark.requireNonNull1p thrpt 6 67601.134 > 7004.689 ops/ms > s.m.ThrowAwayBenchmark.requireNonNull10p thrpt 6 8150.595 > 538.970 ops/ms > s.m.ThrowAwayBenchmark.requireNonNull50p thrpt 6 1604.919 > 220.903 ops/ms > s.m.ThrowAwayBenchmark.requireNonNull100p thrpt 6 > 820.626 60.752 ops/ms > > Yikes! As long as the value is never null they're inlined nicely and > neither have the upper hand performance-wise, but as soon as you get > some null values, Objects.requireNonNull degenerates much faster than > its foo.toString counterpart. I think this is a JIT issue - optimizing > exception-paths might not be the highest priority, but > Objects.requireNonNull is used pretty extensively in the JDK and my > expectation would be that it shouldn't degrade performance when things > actually are null now and then. > > /Claes This is a know issue, I think it's not related to the way the JIT handle exception path but what is called 'profile pollution'. Hotspot JITs have two ways to do a null check, either do nothing (yes nothing) and let the system do a fault and come back from dead using a signal handler, this solution is named implicit null check or by doing an explicit null check, i.e a conditional jump. Implicit null check is faster but if the receiver is null, it cost you an harm, so the VM profiles receiver to remember if the receiver of each call can be null or not. The problem is that when you call foo.toString(), the profile information is associated with the instruction that does foo.toString() while if the call is Objects.requireNonNull(foo), the profile associated with the nullcheck is stored inside the method requireNonNull, so if one call to requireNonNull in the entire program throw a NPE, the profile inside requireNonNull now register that it may fail, so for the VM all calls to requireNonNull may fail. So currently you should not use requireNonNull is the value is not required to be null* So the problem is that Hotspot blindly trusts the recorded profile compared to the profile that can come from the arguments of a call. The good news is that recently some patches were included in the jdk9 tree to fix or at least mitigate that issue. cheers, R?mi * read that last sentence again, it seems very logical, no ? From forax at univ-mlv.fr Tue Apr 29 07:45:16 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 29 Apr 2014 09:45:16 +0200 Subject: Remove redundant calls of toString() In-Reply-To: <535ED985.5040007@oracle.com> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> <535E7734.7050602@oracle.com> <535ECC87.5030808@oracle.com> <535ED985.5040007@oracle.com> Message-ID: <535F588C.1070505@univ-mlv.fr> On 04/29/2014 12:43 AM, Jim Graham wrote: > We refer to these strings as constants in many places. If you have: > > class Foo { > static final String bar = ""; > } > > class Blah { > // uses Foo.bar > } > > Then Blah will incorporate that string by content, not by reference. > I don't know why this is done this way, but Strings are special in > that static final versions of them are included by value just the way > that static final primitive types are. As a result, we had huge > duplications of these strings all over the place. yes and no. You have no duplication at runtime because the VM use a common dictionary for all constant strings (it's required by the Java spec) but you have duplication of the string at bytecode level. Basically the class file is bigger because the compiler duplicate the String as you said by content but you have no duplication at runtime because the VM dedup the constant strings using a dictionary. > But, this only happens when you initialize it to a constant "..." > string. If it is the result of a method call (or probably a > calculation), then it ends up being treated like any static final > object and is included by reference. Thus, appending .toString(); to > the "..." constant foils the "include by value" processing in the > compiler... yes, "foo" is a constant for the compiler but "foo".toString() is not. so by calling toString on a big String you save .class space. Also note that this is not an issue with Android because the Android class format (DEX) use one constant pool for several classes and not one constant pool by .class. > > ...jim cheers, R?mi > > On 4/28/14 2:47 PM, Phil Race wrote: >> I am quite sure that you are right that these were deliberate so >> I am adding Jim who was the author of all of the 2d ones to explain the >> intent. >> >> BTW Ot?vio, changes in 2D code like this should not slip by on the >> core-libs list. >> It ought to go to 2d-dev. >> >> -phil. >> >> On 4/28/2014 9:24 AM, Louis Wasserman wrote: >>> - public final static String methodSignature = >>> "DrawGlyphList(...)".toString(); >>> + public final static String methodSignature = "DrawGlyphList(...)"; >>> >>> I conjecture that this, and other similar examples, are to avoid >>> having the >>> string be a compile-time constant that can be inlined into other files. >>> Has anyone checked that there aren't any issues arising from >>> changing this? >>> >>> >>> >>> >>> >> >> n 4/27/2014 6:15 AM, Ot?vio Gon?alves de Santana wrote: >>> There is an issue that was opened to remove redundant calls of >>> toString() >>> on String objects. [1] >>> I went deep on all JVM sources and I found all, 32 changes. >>> >>> >>> [1]https://bugs.openjdk.java.net/browse/JDK-8015470 >>> >>> diff -r e323c74edabd >>> src/share/classes/javax/swing/text/html/FormView.java >>> --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/javax/swing/text/html/FormView.java Sat Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -478,7 +478,7 @@ >>> base.getPort(), >>> base.getFile()) >>> : new URL(base, action); >>> if (!isPostMethod) { >>> - String query = data.toString(); >>> + String query = data; >>> actionURL = new URL(actionURL + "?" + query); >>> } >>> } catch (MalformedURLException e) { >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java >>> --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 >>> 2014 >>> -0700 >>> +++ b/src/share/classes/sun/java2d/loops/Blit.java Sat Apr 26 01:40:27 >>> 2014 >>> -0300 >>> @@ -50,7 +50,7 @@ >>> >>> public class Blit extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "Blit(...)".toString(); >>> + public static final String methodSignature = "Blit(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java >>> --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -54,7 +54,7 @@ >>> */ >>> public class BlitBg extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "BlitBg(...)".toString(); >>> + public static final String methodSignature = "BlitBg(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/DrawGlyphList.java >>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sat Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> */ >>> public class DrawGlyphList extends GraphicsPrimitive { >>> >>> - public final static String methodSignature = >>> "DrawGlyphList(...)".toString(); >>> + public final static String methodSignature = "DrawGlyphList(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/DrawGlyphListAA.java >>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sat >>> Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> */ >>> public class DrawGlyphListAA extends GraphicsPrimitive { >>> >>> - public final static String methodSignature = >>> "DrawGlyphListAA(...)".toString(); >>> + public final static String methodSignature = >>> "DrawGlyphListAA(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java >>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sat >>> Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -40,7 +40,7 @@ >>> public class DrawGlyphListLCD extends GraphicsPrimitive { >>> >>> public final static String >>> - methodSignature = "DrawGlyphListLCD(...)".toString(); >>> + methodSignature = "DrawGlyphListLCD(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java >>> --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -44,7 +44,7 @@ >>> */ >>> public class DrawLine extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "DrawLine(...)".toString(); >>> + public final static String methodSignature = "DrawLine(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/DrawParallelogram.java >>> --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sat >>> Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -43,7 +43,7 @@ >>> public class DrawParallelogram extends GraphicsPrimitive >>> { >>> public final static String methodSignature = >>> - "DrawParallelogram(...)".toString(); >>> + "DrawParallelogram(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java >>> --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> public class DrawPath extends GraphicsPrimitive { >>> >>> public final static String methodSignature = >>> - "DrawPath(...)".toString(); >>> + "DrawPath(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/DrawPolygons.java >>> --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -41,7 +41,7 @@ >>> */ >>> public class DrawPolygons extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "DrawPolygons(...)".toString(); >>> + public final static String methodSignature = "DrawPolygons(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java >>> --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -44,7 +44,7 @@ >>> */ >>> public class DrawRect extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "DrawRect(...)".toString(); >>> + public final static String methodSignature = "DrawRect(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/FillParallelogram.java >>> --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sat >>> Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -41,7 +41,7 @@ >>> public class FillParallelogram extends GraphicsPrimitive >>> { >>> public final static String methodSignature = >>> - "FillParallelogram(...)".toString(); >>> + "FillParallelogram(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java >>> --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> public class FillPath extends GraphicsPrimitive { >>> >>> public final static String methodSignature = >>> - "FillPath(...)".toString(); >>> + "FillPath(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java >>> --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -44,7 +44,7 @@ >>> */ >>> public class FillRect extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "FillRect(...)".toString(); >>> + public final static String methodSignature = "FillRect(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java >>> --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -45,7 +45,7 @@ >>> */ >>> public class FillSpans extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "FillSpans(...)".toString(); >>> + public final static String methodSignature = "FillSpans(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java >>> --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -48,7 +48,7 @@ >>> >>> public class MaskBlit extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "MaskBlit(...)".toString(); >>> + public static final String methodSignature = "MaskBlit(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java >>> --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -50,11 +50,11 @@ >>> */ >>> public class MaskFill extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "MaskFill(...)".toString(); >>> + public static final String methodSignature = "MaskFill(...)"; >>> public static final String fillPgramSignature = >>> - "FillAAPgram(...)".toString(); >>> + "FillAAPgram(...)"; >>> public static final String drawPgramSignature = >>> - "DrawAAPgram(...)".toString(); >>> + "DrawAAPgram(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java >>> --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sat Apr 26 >>> 01:40:27 >>> 2014 -0300 >>> @@ -45,7 +45,7 @@ >>> >>> public class ScaledBlit extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "ScaledBlit(...)".toString(); >>> + public static final String methodSignature = "ScaledBlit(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/TransformBlit.java >>> --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sat Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -47,7 +47,7 @@ >>> public class TransformBlit extends GraphicsPrimitive >>> { >>> public static final String methodSignature = >>> - "TransformBlit(...)".toString(); >>> + "TransformBlit(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/TransformHelper.java >>> --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed >>> Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sat >>> Apr 26 >>> 01:40:27 2014 -0300 >>> @@ -46,7 +46,7 @@ >>> public class TransformHelper extends GraphicsPrimitive >>> { >>> public static final String methodSignature = >>> - "TransformHelper(...)".toString(); >>> + "TransformHelper(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> >> From paul.sandoz at oracle.com Tue Apr 29 08:22:39 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 29 Apr 2014 10:22:39 +0200 Subject: Guidance about binary / data files for JTREG tests In-Reply-To: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> References: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> Message-ID: <9C5011C8-8353-4AA8-9010-8AFF4ECFCFF7@oracle.com> On Apr 28, 2014, at 7:53 PM, Brian Burkhalter wrote: > Firstly, I was informed that there are not supposed to be binary files in the jdk9/jdk/test tree. My webrev listed in the above post includes one such file, a GZIPped text file of prime numbers. Apparently this file as-is should not be checked in to the repository. > Why? Paul. From chris.hegarty at oracle.com Tue Apr 29 08:28:38 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 29 Apr 2014 09:28:38 +0100 Subject: Guidance about binary / data files for JTREG tests In-Reply-To: <9C5011C8-8353-4AA8-9010-8AFF4ECFCFF7@oracle.com> References: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> <9C5011C8-8353-4AA8-9010-8AFF4ECFCFF7@oracle.com> Message-ID: <8DF12069-8E79-4CFE-8195-D681EF2F9B40@oracle.com> On 29 Apr 2014, at 09:22, Paul Sandoz wrote: > On Apr 28, 2014, at 7:53 PM, Brian Burkhalter wrote: >> Firstly, I was informed that there are not supposed to be binary files in the jdk9/jdk/test tree. My webrev listed in the above post includes one such file, a GZIPped text file of prime numbers. Apparently this file as-is should not be checked in to the repository. >> > > Why? A really old bug gives some insight: https://bugs.openjdk.java.net/browse/JDK-6934214 -Chris. > > Paul. From claes.redestad at oracle.com Tue Apr 29 09:20:59 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 29 Apr 2014 11:20:59 +0200 Subject: Remove redundant calls of toString() In-Reply-To: <535F5548.9020807@univ-mlv.fr> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> <535E7734.7050602@oracle.com> <535F5548.9020807@univ-mlv.fr> Message-ID: <535F6EFB.1070701@oracle.com> On 2014-04-29 09:31, Remi Forax wrote: > On 04/28/2014 05:43 PM, Claes Redestad wrote: >> On 04/28/2014 08:57 AM, David Holmes wrote: >>> On 28/04/2014 1:05 PM, Ot?vio Gon?alves de Santana wrote: >>>> In my opinion not, because Objects.requireNonNull is more readable >>>> than >>>> just string.toString. This way is more understandable which field is >>>> required and doesn't impact on performance. >>> >>> An invocation of requireNonNull is potentially more expensive than >>> the implicit null check that happens with foo.toString(). >>> >>> David >>> ----- >> >> My thought was that these two would be inlined to the exact same >> thing, so I did a quick test to see what happens when you do >> foo.toString() versus Objects.requireNonNull(foo) on a set of >> randomly generated String[]'s with different amounts of null >> elements(0p: no null entries, 1p: 1% null entries etc): >> >> Benchmark Mode Samples Mean >> Mean error Units >> s.m.ThrowAwayBenchmark.nullToString0p thrpt 6 356653.044 >> 3573.707 ops/ms >> s.m.ThrowAwayBenchmark.nullToString1p thrpt 6 353128.903 >> 2764.102 ops/ms >> s.m.ThrowAwayBenchmark.nullToString10p thrpt 6 297956.571 >> 9580.251 ops/ms >> s.m.ThrowAwayBenchmark.nullToString50p thrpt 6 158172.036 >> 1893.096 ops/ms >> s.m.ThrowAwayBenchmark.nullToString100p thrpt 6 >> 18194.614 472.091 ops/ms >> s.m.ThrowAwayBenchmark.requireNonNull0p thrpt 6 >> 357855.126 2979.090 ops/ms >> s.m.ThrowAwayBenchmark.requireNonNull1p thrpt 6 67601.134 >> 7004.689 ops/ms >> s.m.ThrowAwayBenchmark.requireNonNull10p thrpt 6 >> 8150.595 538.970 ops/ms >> s.m.ThrowAwayBenchmark.requireNonNull50p thrpt 6 >> 1604.919 220.903 ops/ms >> s.m.ThrowAwayBenchmark.requireNonNull100p thrpt 6 >> 820.626 60.752 ops/ms >> >> Yikes! As long as the value is never null they're inlined nicely and >> neither have the upper hand performance-wise, but as soon as you get >> some null values, Objects.requireNonNull degenerates much faster than >> its foo.toString counterpart. I think this is a JIT issue - >> optimizing exception-paths might not be the highest priority, but >> Objects.requireNonNull is used pretty extensively in the JDK and my >> expectation would be that it shouldn't degrade performance when >> things actually are null now and then. >> >> /Claes > > This is a know issue, I think it's not related to the way the JIT > handle exception path but what is called 'profile pollution'. > Hotspot JITs have two ways to do a null check, either do nothing (yes > nothing) and let the system do a fault and come back from dead using a > signal handler, this solution is named implicit null check or by doing > an explicit null check, i.e a conditional jump. > Implicit null check is faster but if the receiver is null, it cost you > an harm, so the VM profiles receiver to remember if the receiver of > each call can be null or not. The problem is that when you call > foo.toString(), the profile information is associated with the > instruction that does foo.toString() while if the call is > Objects.requireNonNull(foo), the profile associated with the nullcheck > is stored inside the method requireNonNull, so if one call to > requireNonNull in the entire program throw a NPE, the profile inside > requireNonNull now register that it may fail, so for the VM all calls > to requireNonNull may fail. So currently you should not use > requireNonNull is the value is not required to be null* I guess I should have given more details. :-) I ran my micros on a number of forked VMs to ensure I don't get excessive run-to-run variations, which among other things avoids profile pollution. Also I sloppily collected very few samples and only did minimal warmup after I saw that the micros produced scores that were orders of magnitude apart and the values stabilized after less than two seconds: Flags: -f 3 -wi 4 -i 2 When I run the micros sequentially in the same VM I see some added degradation for the exceptional cases, but the 0p cases still inline to the optimal(?) 360k ops/ms, so while it seems profile pollution might play in when provoked, HotSpot seems to manage these simple micros well enough. > So the problem is that Hotspot blindly trusts the recorded profile > compared to the profile that can come from the arguments of a call. > The good news is that recently some patches were included in the jdk9 > tree to fix or at least mitigate that issue. > I've now run tests on JDK8 FCS and a recent internal build of JDK9 and see the same characteristics. How recently are we talking here? :-) > cheers, > R?mi > * read that last sentence again, it seems very logical, no ? > While your reading of the method name and suggested approach makes sense right now, the javadoc for Objects.requireNonNull states "this method is designed primarily for doing parameter validation in methods and constructors". To me, "parameter validation" suggests that we're dealing with unknowns and that there's at least some calculated risk that the input might be null, so the intent is really to encourage explicit fail-fast designs, no? I thus think it makes sense to try and ensure these methods have the same performance characteristics as when provoking an implicit null check by dereferencing an object. /Claes From aph at redhat.com Tue Apr 29 09:40:44 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Apr 2014 10:40:44 +0100 Subject: Remove redundant calls of toString() In-Reply-To: <535DFBDE.6030701@oracle.com> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> Message-ID: <535F739C.10701@redhat.com> On 04/28/2014 07:57 AM, David Holmes wrote: > On 28/04/2014 1:05 PM, Ot?vio Gon?alves de Santana wrote: >> In my opinion not, because Objects.requireNonNull is more readable than >> just string.toString. This way is more understandable which field is >> required and doesn't impact on performance. > > An invocation of requireNonNull is potentially more expensive than the > implicit null check that happens with foo.toString(). It's also potentially cheaper: a cbnz versus a fetch from memory with a few cycles pipeline delay. Andrew. From david.holmes at oracle.com Tue Apr 29 09:58:59 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Apr 2014 19:58:59 +1000 Subject: Remove redundant calls of toString() In-Reply-To: <535F739C.10701@redhat.com> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> <535F739C.10701@redhat.com> Message-ID: <535F77E3.7060907@oracle.com> On 29/04/2014 7:40 PM, Andrew Haley wrote: > On 04/28/2014 07:57 AM, David Holmes wrote: >> On 28/04/2014 1:05 PM, Ot?vio Gon?alves de Santana wrote: >>> In my opinion not, because Objects.requireNonNull is more readable than >>> just string.toString. This way is more understandable which field is >>> required and doesn't impact on performance. >> >> An invocation of requireNonNull is potentially more expensive than the >> implicit null check that happens with foo.toString(). > > It's also potentially cheaper: a cbnz versus a fetch from memory with a > few cycles pipeline delay. Can you elaborate please? AFAIK implicit null checks have no overhead when the object reference is not null. Interpreted it is slower and the bytecode footprint is larger. IIRC the guidelines for use of requireNonNull in the JDK code was for replacing explicit null checks in precondition checking, not implicit ones. Anyway I don't find these changes compelling. YMMV. David ----- > Andrew. > From aph at redhat.com Tue Apr 29 10:03:40 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Apr 2014 11:03:40 +0100 Subject: Remove redundant calls of toString() In-Reply-To: <535F77E3.7060907@oracle.com> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> <535F739C.10701@redhat.com> <535F77E3.7060907@oracle.com> Message-ID: <535F78FC.7000605@redhat.com> On 04/29/2014 10:58 AM, David Holmes wrote: > On 29/04/2014 7:40 PM, Andrew Haley wrote: >> On 04/28/2014 07:57 AM, David Holmes wrote: >>> On 28/04/2014 1:05 PM, Ot?vio Gon?alves de Santana wrote: >>>> In my opinion not, because Objects.requireNonNull is more readable than >>>> just string.toString. This way is more understandable which field is >>>> required and doesn't impact on performance. >>> >>> An invocation of requireNonNull is potentially more expensive than the >>> implicit null check that happens with foo.toString(). >> >> It's also potentially cheaper: a cbnz versus a fetch from memory with a >> few cycles pipeline delay. > > Can you elaborate please? AFAIK implicit null checks have no overhead > when the object reference is not null. I'm sorry, that remark was too simplistic. If you have to read the data at that time, I agree. And it might do some useful prefetching. But if you're just checking the object is non-null it may be cheaper to do (o != null) . I have noticed that some Java code does (o.getClass()) or something similar to get an implicit check rather than if (o != null)... > Interpreted it is slower and the bytecode footprint is larger. > > IIRC the guidelines for use of requireNonNull in the JDK code was for > replacing explicit null checks in precondition checking, not implicit ones. > > Anyway I don't find these changes compelling. I agree. Andrew. From weijun.wang at oracle.com Tue Apr 29 10:31:26 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 29 Apr 2014 18:31:26 +0800 Subject: Guidance about binary / data files for JTREG tests In-Reply-To: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> References: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> Message-ID: <9735C985-B2CC-4433-B131-53B3E8D586D2@oracle.com> On Apr 29, 2014, at 1:53, Brian Burkhalter wrote: > 1 - Binary test data files are in fact illegal to check in, correct? They should be avoided as much as you can, but it's not illegal. > Meanwhile I suppose that I could convert my test file and use the sun.misc.UU{En,De}coder classes to handle it in the test. If I understand correctly, the reason why binary data is not preferable is not because they are not printable, but not human readable. Encoding them to BASE64 or HEX does not really solve the problem. What you need to do is precisely describing how to create the file so that a reader is able to recreate it. Said that, I prefer HEX much more than binary, because it's Mercurial friendly, you can add comment, and HEX strings can be easily embedded inside a program so you can use ByteArrayInputStream instead of FileInputStream. Thanks Max From Alan.Bateman at oracle.com Tue Apr 29 12:35:16 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Apr 2014 13:35:16 +0100 Subject: Guidance about binary / data files for JTREG tests In-Reply-To: <9735C985-B2CC-4433-B131-53B3E8D586D2@oracle.com> References: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> <9735C985-B2CC-4433-B131-53B3E8D586D2@oracle.com> Message-ID: <535F9C84.8000101@oracle.com> On 29/04/2014 11:31, Wang Weijun wrote: > : > > If I understand correctly, the reason why binary data is not preferable is not because they are not printable, but not human readable. Encoding them to BASE64 or HEX does not really solve the problem. What you need to do is precisely describing how to create the file so that a reader is able to recreate it. > The other thing that came up previously is distributions that have a policy of not allowing binary files. If I'm not mistake then they are deleted by downstream patches, which in this case would lead to a test failure. -Alan. From Alan.Bateman at oracle.com Tue Apr 29 14:01:08 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Apr 2014 15:01:08 +0100 Subject: JDK 9 RFR of 8041683: java/math/BigInteger/BitLengthOverflow.java failing with OOME In-Reply-To: <056C7BFB-8428-4E52-BDEC-7E3266554B6B@oracle.com> References: <056C7BFB-8428-4E52-BDEC-7E3266554B6B@oracle.com> Message-ID: <535FB0A4.5070602@oracle.com> On 25/04/2014 22:26, Brian Burkhalter wrote: > Hello, > > Issue: https://bugs.openjdk.java.net/browse/JDK-8041683 > Patch: http://cr.openjdk.java.net/~bpb/8041683/webrev.00/ > > It?s not really a solution but the patch changes BitLengthOverflow and DoubleValueOverflow to catch the OOME and print a warning to STDERR instead of failing outright. These OOMEs do not occur in JPRT runs with default parameters, so at least this patch would allow the tests to run successfully when there is enough memory but not to cause the test run to fail when there is not enough memory. This is more test coverage than never running the tests. This looks okay although I suspect these tests will will throw OOME most of the time, as it's so common to limit the heap size (512MB is common, I think is what the make files use for example). -Alan. From kumar.x.srinivasan at oracle.com Tue Apr 29 14:17:53 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 29 Apr 2014 07:17:53 -0700 Subject: review request: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <535B11F6.3090403@oracle.com> References: <5355C383.9050109@oracle.com> <535A7DCD.3050902@oracle.com> <535B11F6.3090403@oracle.com> Message-ID: <535FB491.2010702@oracle.com> Neil, The changes looks satisfactory, except for a few style nits: 1. JAVAFX_FXHELPER_CLASS_NAME_SUF -> JAVAFX_FXHELPER_CLASS_NAME_SUFFIX // 3 more characters won't make much of a difference 2. FXHelper.setFXLaunchParameters(what,mode); // missing space after comma. A Launcher regression test is required, which ensure that the launcher does not load FXLauncher inadvertently in the future. ie. a regression test. You can do this by adding another condition in the method testExtraneousJars at: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/3e8e199e23b2/test/tools/launcher/FXLauncherTest.java#l360 just like jfxrt.jar is being tested now. Kumar On 4/25/2014 6:55 PM, Neil Toda wrote: > > Thanks Kevin. -neil > > On 4/25/2014 8:22 AM, Kevin Rushforth wrote: >> The code changes looks fine to me. Also, I ran all JavaFX unit tests >> with no problems (at least none relating to launching). >> >> -- Kevin >> >> >> Neil Toda wrote: >>> Webrev >>> >>> http://cr.openjdk.java.net/~ntoda/8035782/ >>> >>> for bug >>> >>> https://bugs.openjdk.java.net/browse/JDK-8035782 >>> >>> The file : ./jdk/src/share/classes/sun/launcher/LauncherHelper.java >>> >>> has been modified so that the inner class FXHelper is not loaded >>> unnecessarily. >>> FXHelper, which is needed to make initializations for any JavaFX >>> application, was >>> being loaded for all applications. >>> >>> The fix was straight forward, with the lifting of one method and >>> several static >>> strings into FXHelper's superclass, LauncherHelper. >>> >>> Kevin Rushforth supplied three tests of applications not in jar >>> files. These >>> needed to be explicitly tested. These tests require the JavaFX >>> bundle in the >>> build, and the return code 2 signifies success. >>> >>> Launcher tests for jtreg: ./jdk/test/tools/launcher passed on >>> Windows 7 64 and Oracle-Linux6-64. >>> >>> JPRT tests were run and passed on scv3. >>> >>> Thanks >>> >>> -neil >>> >>> >>> >> >> > From brian.burkhalter at oracle.com Tue Apr 29 14:52:31 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 29 Apr 2014 07:52:31 -0700 Subject: JDK 9 RFR of 8041683: java/math/BigInteger/BitLengthOverflow.java failing with OOME In-Reply-To: <535FB0A4.5070602@oracle.com> References: <056C7BFB-8428-4E52-BDEC-7E3266554B6B@oracle.com> <535FB0A4.5070602@oracle.com> Message-ID: <49B59784-A351-4634-AE77-1D3CB6D0D188@oracle.com> On Apr 29, 2014, at 7:01 AM, Alan Bateman wrote: > This looks okay although I suspect these tests will will throw OOME most of the time, as it's so common to limit the heap size (512MB is common, I think is what the make files use for example). Understood. Thanks, Alan From Alan.Bateman at oracle.com Tue Apr 29 14:57:34 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Apr 2014 15:57:34 +0100 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <53599932.4090307@oracle.com> References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com> <535830AC.5070003@oracle.com> <535958DA.2010307@oracle.com> <53599932.4090307@oracle.com> Message-ID: <535FBDDE.8040707@oracle.com> On 25/04/2014 00:07, Mandy Chung wrote: > Thanks Sean. > > I have updated the webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/ > > Erik - I'm including build-dev to review the build change for > java.policy file. Just catching up on this thread. The update to ZipFileSystem and the policy file look good to me. I only skimmed over the test changes and agree with the the comments that tests usually just want to configure the policy for the test and not have to repeat the grants in the system policy. A minor comment on the policy files is that there is mix of indentation styles (4 and 8 in the same file in some cases). There is also inconsistent indentation in Ext_AllPolicy.java (pre-dates your changes). -Alan From neil.toda at oracle.com Tue Apr 29 15:50:54 2014 From: neil.toda at oracle.com (Neil Toda) Date: Tue, 29 Apr 2014 08:50:54 -0700 Subject: review request: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <535FB491.2010702@oracle.com> References: <5355C383.9050109@oracle.com> <535A7DCD.3050902@oracle.com> <535B11F6.3090403@oracle.com> <535FB491.2010702@oracle.com> Message-ID: <535FCA5E.4070404@oracle.com> Thanks Kumar. Will check these. I have FXLauncherTest.java open right now as I type. I started looking at it yesterday. Good that I am looking at the right test case. Good organization. I might also have to add a non FX jar file to test.. unless I've missed that. -neil On 4/29/2014 7:17 AM, Kumar Srinivasan wrote: > Neil, > > The changes looks satisfactory, except for a few style nits: > 1. JAVAFX_FXHELPER_CLASS_NAME_SUF -> JAVAFX_FXHELPER_CLASS_NAME_SUFFIX > // 3 more characters won't make much of a difference > > 2. FXHelper.setFXLaunchParameters(what,mode); > // missing space after comma. > > > A Launcher regression test is required, which ensure that the > launcher does not load > FXLauncher inadvertently in the future. ie. a regression test. > > You can do this by adding another condition in the method > testExtraneousJars at: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/3e8e199e23b2/test/tools/launcher/FXLauncherTest.java#l360 > > just like jfxrt.jar is being tested now. > > Kumar > > On 4/25/2014 6:55 PM, Neil Toda wrote: >> >> Thanks Kevin. -neil >> >> On 4/25/2014 8:22 AM, Kevin Rushforth wrote: >>> The code changes looks fine to me. Also, I ran all JavaFX unit tests >>> with no problems (at least none relating to launching). >>> >>> -- Kevin >>> >>> >>> Neil Toda wrote: >>>> Webrev >>>> >>>> http://cr.openjdk.java.net/~ntoda/8035782/ >>>> >>>> for bug >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8035782 >>>> >>>> The file : ./jdk/src/share/classes/sun/launcher/LauncherHelper.java >>>> >>>> has been modified so that the inner class FXHelper is not loaded >>>> unnecessarily. >>>> FXHelper, which is needed to make initializations for any JavaFX >>>> application, was >>>> being loaded for all applications. >>>> >>>> The fix was straight forward, with the lifting of one method and >>>> several static >>>> strings into FXHelper's superclass, LauncherHelper. >>>> >>>> Kevin Rushforth supplied three tests of applications not in jar >>>> files. These >>>> needed to be explicitly tested. These tests require the JavaFX >>>> bundle in the >>>> build, and the return code 2 signifies success. >>>> >>>> Launcher tests for jtreg: ./jdk/test/tools/launcher passed on >>>> Windows 7 64 and Oracle-Linux6-64. >>>> >>>> JPRT tests were run and passed on scv3. >>>> >>>> Thanks >>>> >>>> -neil >>>> >>>> >>>> >>> >>> >> > From kumar.x.srinivasan at oracle.com Tue Apr 29 16:45:09 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 29 Apr 2014 09:45:09 -0700 Subject: review request: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <535FCA5E.4070404@oracle.com> References: <5355C383.9050109@oracle.com> <535A7DCD.3050902@oracle.com> <535B11F6.3090403@oracle.com> <535FB491.2010702@oracle.com> <535FCA5E.4070404@oracle.com> Message-ID: <535FD715.9030200@oracle.com> On 4/29/2014 8:50 AM, Neil Toda wrote: > > Thanks Kumar. Will check these. > > I have FXLauncherTest.java open right now as I type. I started > looking at it yesterday. Good > that I am looking at the right test case. Good organization. I might > also have to add a > non FX jar file to test.. unless I've missed that. there is already a nonFX jar being created, see: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/3e8e199e23b2/test/tools/launcher/FXLauncherTest.java#l360 lines 358-361, all you have to do is add the following, and add the JBS-id in the @bug list. if (tr.testStatus) { if (!tr.notContains("jfxrt.jar")) { System.out.println("testing for extraneous jfxrt jar"); System.out.println(tr); throw new Exception("jfxrt.jar is being loaded, it should not be!"); } + if (!tr.notContains("sun.launcher.LauncherHelper\$FXHelper")) { // this is a regex +System.out.println("testing for extraneous FXhelper"); + System.out.println(tr); + throw new Exception("jfxrt.jar is being loaded, it should not be!"); + } for (String p : APP_PARMS) { if (!tr.contains(p)) { System.err.println("ERROR: Did not find " + p + " in output!"); } } } Hope this helps. Kumar > > -neil > > > > > On 4/29/2014 7:17 AM, Kumar Srinivasan wrote: >> Neil, >> >> The changes looks satisfactory, except for a few style nits: >> 1. JAVAFX_FXHELPER_CLASS_NAME_SUF -> JAVAFX_FXHELPER_CLASS_NAME_SUFFIX >> // 3 more characters won't make much of a difference >> >> 2. FXHelper.setFXLaunchParameters(what,mode); >> // missing space after comma. >> >> >> A Launcher regression test is required, which ensure that the >> launcher does not load >> FXLauncher inadvertently in the future. ie. a regression test. >> >> You can do this by adding another condition in the method >> testExtraneousJars at: >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/3e8e199e23b2/test/tools/launcher/FXLauncherTest.java#l360 >> >> just like jfxrt.jar is being tested now. >> >> Kumar >> >> On 4/25/2014 6:55 PM, Neil Toda wrote: >>> >>> Thanks Kevin. -neil >>> >>> On 4/25/2014 8:22 AM, Kevin Rushforth wrote: >>>> The code changes looks fine to me. Also, I ran all JavaFX unit >>>> tests with no problems (at least none relating to launching). >>>> >>>> -- Kevin >>>> >>>> >>>> Neil Toda wrote: >>>>> Webrev >>>>> >>>>> http://cr.openjdk.java.net/~ntoda/8035782/ >>>>> >>>>> for bug >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8035782 >>>>> >>>>> The file : ./jdk/src/share/classes/sun/launcher/LauncherHelper.java >>>>> >>>>> has been modified so that the inner class FXHelper is not loaded >>>>> unnecessarily. >>>>> FXHelper, which is needed to make initializations for any JavaFX >>>>> application, was >>>>> being loaded for all applications. >>>>> >>>>> The fix was straight forward, with the lifting of one method and >>>>> several static >>>>> strings into FXHelper's superclass, LauncherHelper. >>>>> >>>>> Kevin Rushforth supplied three tests of applications not in jar >>>>> files. These >>>>> needed to be explicitly tested. These tests require the JavaFX >>>>> bundle in the >>>>> build, and the return code 2 signifies success. >>>>> >>>>> Launcher tests for jtreg: ./jdk/test/tools/launcher passed on >>>>> Windows 7 64 and Oracle-Linux6-64. >>>>> >>>>> JPRT tests were run and passed on scv3. >>>>> >>>>> Thanks >>>>> >>>>> -neil >>>>> >>>>> >>>>> >>>> >>>> >>> >> > From neil.toda at oracle.com Tue Apr 29 16:49:07 2014 From: neil.toda at oracle.com (Neil Toda) Date: Tue, 29 Apr 2014 09:49:07 -0700 Subject: review request: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <535FD715.9030200@oracle.com> References: <5355C383.9050109@oracle.com> <535A7DCD.3050902@oracle.com> <535B11F6.3090403@oracle.com> <535FB491.2010702@oracle.com> <535FCA5E.4070404@oracle.com> <535FD715.9030200@oracle.com> Message-ID: <535FD803.4040306@oracle.com> Great. Thanks. On 4/29/2014 9:45 AM, Kumar Srinivasan wrote: > > On 4/29/2014 8:50 AM, Neil Toda wrote: >> >> Thanks Kumar. Will check these. >> >> I have FXLauncherTest.java open right now as I type. I started >> looking at it yesterday. Good >> that I am looking at the right test case. Good organization. I >> might also have to add a >> non FX jar file to test.. unless I've missed that. > > there is already a nonFX jar being created, see: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/3e8e199e23b2/test/tools/launcher/FXLauncherTest.java#l360 > > lines 358-361, all you have to do is add the following, and add the > JBS-id in the @bug list. > > if (tr.testStatus) { > if (!tr.notContains("jfxrt.jar")) { > System.out.println("testing for extraneous jfxrt jar"); > System.out.println(tr); > throw new Exception("jfxrt.jar is being loaded, it > should not be!"); > } > + if > (!tr.notContains("sun.launcher.LauncherHelper\$FXHelper")) { // this > is a regex > +System.out.println("testing for extraneous FXhelper"); > + System.out.println(tr); > + throw new Exception("jfxrt.jar is being loaded, it > should not be!"); > + } > for (String p : APP_PARMS) { > if (!tr.contains(p)) { > System.err.println("ERROR: Did not find " > + p + " in output!"); > } > } > } > > Hope this helps. > > Kumar >> >> -neil >> >> >> >> >> On 4/29/2014 7:17 AM, Kumar Srinivasan wrote: >>> Neil, >>> >>> The changes looks satisfactory, except for a few style nits: >>> 1. JAVAFX_FXHELPER_CLASS_NAME_SUF -> JAVAFX_FXHELPER_CLASS_NAME_SUFFIX >>> // 3 more characters won't make much of a difference >>> >>> 2. FXHelper.setFXLaunchParameters(what,mode); >>> // missing space after comma. >>> >>> >>> A Launcher regression test is required, which ensure that the >>> launcher does not load >>> FXLauncher inadvertently in the future. ie. a regression test. >>> >>> You can do this by adding another condition in the method >>> testExtraneousJars at: >>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/3e8e199e23b2/test/tools/launcher/FXLauncherTest.java#l360 >>> >>> just like jfxrt.jar is being tested now. >>> >>> Kumar >>> >>> On 4/25/2014 6:55 PM, Neil Toda wrote: >>>> >>>> Thanks Kevin. -neil >>>> >>>> On 4/25/2014 8:22 AM, Kevin Rushforth wrote: >>>>> The code changes looks fine to me. Also, I ran all JavaFX unit >>>>> tests with no problems (at least none relating to launching). >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Neil Toda wrote: >>>>>> Webrev >>>>>> >>>>>> http://cr.openjdk.java.net/~ntoda/8035782/ >>>>>> >>>>>> for bug >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8035782 >>>>>> >>>>>> The file : ./jdk/src/share/classes/sun/launcher/LauncherHelper.java >>>>>> >>>>>> has been modified so that the inner class FXHelper is not loaded >>>>>> unnecessarily. >>>>>> FXHelper, which is needed to make initializations for any JavaFX >>>>>> application, was >>>>>> being loaded for all applications. >>>>>> >>>>>> The fix was straight forward, with the lifting of one method and >>>>>> several static >>>>>> strings into FXHelper's superclass, LauncherHelper. >>>>>> >>>>>> Kevin Rushforth supplied three tests of applications not in jar >>>>>> files. These >>>>>> needed to be explicitly tested. These tests require the JavaFX >>>>>> bundle in the >>>>>> build, and the return code 2 signifies success. >>>>>> >>>>>> Launcher tests for jtreg: ./jdk/test/tools/launcher passed on >>>>>> Windows 7 64 and Oracle-Linux6-64. >>>>>> >>>>>> JPRT tests were run and passed on scv3. >>>>>> >>>>>> Thanks >>>>>> >>>>>> -neil >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From brian.burkhalter at oracle.com Tue Apr 29 19:06:59 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 29 Apr 2014 12:06:59 -0700 Subject: JDK 9 RFC on 8032016: Optimizations of Math.next{After, Up}({float, double}) Message-ID: <017489FE-FF2E-4DD4-B7F6-359EA69AC602@oracle.com> Hello, Issue: https://bugs.openjdk.java.net/browse/JDK-8032016 Patch: http://cr.openjdk.java.net/~bpb/8032016/webrev.00/ The performance improvements of this change are marginal but the logic seems reasonable and the code looks cleaner so I am posting this as an RFC. Comments? Thanks, Brian From brian.burkhalter at oracle.com Tue Apr 29 19:18:03 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 29 Apr 2014 12:18:03 -0700 Subject: Guidance about binary / data files for JTREG tests In-Reply-To: <535F9C84.8000101@oracle.com> References: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> <9735C985-B2CC-4433-B131-53B3E8D586D2@oracle.com> <535F9C84.8000101@oracle.com> Message-ID: Thanks, everyone, for comments. The issue has been circumvented in this case by programmatically generating the contents of the data file in question: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026668.html Brian On Apr 29, 2014, at 5:35 AM, Alan Bateman wrote: > On 29/04/2014 11:31, Wang Weijun wrote: >> : >> >> If I understand correctly, the reason why binary data is not preferable is not because they are not printable, but not human readable. Encoding them to BASE64 or HEX does not really solve the problem. What you need to do is precisely describing how to create the file so that a reader is able to recreate it. >> > The other thing that came up previously is distributions that have a policy of not allowing binary files. If I'm not mistake then they are deleted by downstream patches, which in this case would lead to a test failure. > > -Alan. From david.holmes at oracle.com Tue Apr 29 23:37:05 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Apr 2014 09:37:05 +1000 Subject: Attachment test - please ignore Message-ID: <536037A1.6080507@oracle.com> A non-text attachment was scrubbed... Name: jdk9.patch Type: text/x-patch Size: 5419 bytes Desc: not available URL: From alexander.v.stepanov at oracle.com Wed Apr 30 08:23:46 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Wed, 30 Apr 2014 12:23:46 +0400 Subject: [9] Review request for 8029451: Tidy warnings cleanup for java.util package; minor changes in java.nio, java.sql In-Reply-To: <240EEB54-E77B-42E8-AFBC-910DE4CE0CC7@oracle.com> References: <535130FE.6010305@oracle.com> <240EEB54-E77B-42E8-AFBC-910DE4CE0CC7@oracle.com> Message-ID: <5360B312.20800@oracle.com> Sorry, could please anybody else review the changes? We need at least two positive responses to push the changes. Thanks, Alexander On 18.04.2014 23:47, Lance Andersen wrote: > looks fine > On Apr 18, 2014, at 10:04 AM, alexander stepanov > > wrote: > >> Hello, >> >> Could you please review the fix for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8029451 >> >> Webrev corresponding: >> http://cr.openjdk.java.net/~yan/JDK-8029451/webrev.00/ >> >> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >> affected. >> >> Thanks. >> >> Regards, >> Alexander > > > > 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 lance.andersen at oracle.com Wed Apr 30 10:39:52 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 30 Apr 2014 06:39:52 -0400 Subject: [9] Review request for 8029451: Tidy warnings cleanup for java.util package; minor changes in java.nio, java.sql In-Reply-To: <5360B312.20800@oracle.com> References: <535130FE.6010305@oracle.com> <240EEB54-E77B-42E8-AFBC-910DE4CE0CC7@oracle.com> <5360B312.20800@oracle.com> Message-ID: <0AE41412-1372-435B-B6B1-54CFE106E571@oracle.com> On Apr 30, 2014, at 4:23 AM, alexander stepanov wrote: > Sorry, could please anybody else review the changes? We need at least two positive responses to push the changes. Why? You only need one reviewer prior to FC: http://openjdk.java.net/guide/changePlanning.html#bug > > Thanks, > Alexander > > > On 18.04.2014 23:47, Lance Andersen wrote: >> looks fine >> On Apr 18, 2014, at 10:04 AM, alexander stepanov > wrote: >> >>> Hello, >>> >>> Could you please review the fix for the following bug: >>> https://bugs.openjdk.java.net/browse/JDK-8029451 >>> >>> Webrev corresponding: >>> http://cr.openjdk.java.net/~yan/JDK-8029451/webrev.00/ >>> >>> Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. >>> >>> Thanks. >>> >>> Regards, >>> Alexander >> >> >> >> 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 >> >> >> > 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 fweimer at redhat.com Wed Apr 30 10:54:01 2014 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 30 Apr 2014 12:54:01 +0200 Subject: Guidance about binary / data files for JTREG tests In-Reply-To: <535F9C84.8000101@oracle.com> References: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> <9735C985-B2CC-4433-B131-53B3E8D586D2@oracle.com> <535F9C84.8000101@oracle.com> Message-ID: <5360D649.5040407@redhat.com> On 04/29/2014 02:35 PM, Alan Bateman wrote: > The other thing that came up previously is distributions that have a > policy of not allowing binary files. If I'm not mistake then they are > deleted by downstream patches, which in this case would lead to a test > failure. Debian and Fedora are concerned with binary files which have closed source files. These are stripped when noticed. There is no indiscriminate deletion of binary files during the packaging process. The Debian packaging tools had a problem with shipping binary data in local changes, but that's history now. -- Florian Weimer / Red Hat Product Security Team From alexander.v.stepanov at oracle.com Wed Apr 30 11:04:28 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Wed, 30 Apr 2014 15:04:28 +0400 Subject: [9] Review request for 8029451: Tidy warnings cleanup for java.util package; minor changes in java.nio, java.sql In-Reply-To: <0AE41412-1372-435B-B6B1-54CFE106E571@oracle.com> References: <535130FE.6010305@oracle.com> <240EEB54-E77B-42E8-AFBC-910DE4CE0CC7@oracle.com> <5360B312.20800@oracle.com> <0AE41412-1372-435B-B6B1-54CFE106E571@oracle.com> Message-ID: <5360D8BC.5000205@oracle.com> Hello Lance, oh yes, thanks! Regards, Alexander On 30.04.2014 14:39, Lance Andersen wrote: > > On Apr 30, 2014, at 4:23 AM, alexander stepanov > > wrote: > >> Sorry, could please anybody else review the changes? We need at least >> two positive responses to push the changes. > > Why? You only need one reviewer prior to FC: > http://openjdk.java.net/guide/changePlanning.html#bug > > >> >> Thanks, >> Alexander >> >> >> On 18.04.2014 23:47, Lance Andersen wrote: >>> looks fine >>> On Apr 18, 2014, at 10:04 AM, alexander stepanov >>> >> >>> > wrote: >>> >>>> Hello, >>>> >>>> Could you please review the fix for the following bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8029451 >>>> >>>> Webrev corresponding: >>>> http://cr.openjdk.java.net/~yan/JDK-8029451/webrev.00/ >>>> >>>> Just a minor cleanup of javadoc to avoid tidy warnings; no other >>>> code affected. >>>> >>>> Thanks. >>>> >>>> Regards, >>>> Alexander >>> >>> >>> >>> 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 >>> >>> >>> >>> >> > > > > 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 forax at univ-mlv.fr Wed Apr 30 11:08:46 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 30 Apr 2014 13:08:46 +0200 Subject: Remove redundant calls of toString() In-Reply-To: <535F6EFB.1070701@oracle.com> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> <535E7734.7050602@oracle.com> <535F5548.9020807@univ-mlv.fr> <535F6EFB.1070701@oracle.com> Message-ID: <5360D9BE.2000002@univ-mlv.fr> On 04/29/2014 11:20 AM, Claes Redestad wrote: > > On 2014-04-29 09:31, Remi Forax wrote: >> On 04/28/2014 05:43 PM, Claes Redestad wrote: >>> On 04/28/2014 08:57 AM, David Holmes wrote: >>>> On 28/04/2014 1:05 PM, Ot?vio Gon?alves de Santana wrote: >>>>> In my opinion not, because Objects.requireNonNull is more readable >>>>> than >>>>> just string.toString. This way is more understandable which field is >>>>> required and doesn't impact on performance. >>>> >>>> An invocation of requireNonNull is potentially more expensive than >>>> the implicit null check that happens with foo.toString(). >>>> >>>> David >>>> ----- >>> >>> My thought was that these two would be inlined to the exact same >>> thing, so I did a quick test to see what happens when you do >>> foo.toString() versus Objects.requireNonNull(foo) on a set of >>> randomly generated String[]'s with different amounts of null >>> elements(0p: no null entries, 1p: 1% null entries etc): >>> >>> Benchmark Mode Samples Mean >>> Mean error Units >>> s.m.ThrowAwayBenchmark.nullToString0p thrpt 6 356653.044 >>> 3573.707 ops/ms >>> s.m.ThrowAwayBenchmark.nullToString1p thrpt 6 353128.903 >>> 2764.102 ops/ms >>> s.m.ThrowAwayBenchmark.nullToString10p thrpt 6 >>> 297956.571 9580.251 ops/ms >>> s.m.ThrowAwayBenchmark.nullToString50p thrpt 6 >>> 158172.036 1893.096 ops/ms >>> s.m.ThrowAwayBenchmark.nullToString100p thrpt 6 >>> 18194.614 472.091 ops/ms >>> s.m.ThrowAwayBenchmark.requireNonNull0p thrpt 6 >>> 357855.126 2979.090 ops/ms >>> s.m.ThrowAwayBenchmark.requireNonNull1p thrpt 6 >>> 67601.134 7004.689 ops/ms >>> s.m.ThrowAwayBenchmark.requireNonNull10p thrpt 6 >>> 8150.595 538.970 ops/ms >>> s.m.ThrowAwayBenchmark.requireNonNull50p thrpt 6 >>> 1604.919 220.903 ops/ms >>> s.m.ThrowAwayBenchmark.requireNonNull100p thrpt 6 >>> 820.626 60.752 ops/ms >>> >>> Yikes! As long as the value is never null they're inlined nicely and >>> neither have the upper hand performance-wise, but as soon as you get >>> some null values, Objects.requireNonNull degenerates much faster >>> than its foo.toString counterpart. I think this is a JIT issue - >>> optimizing exception-paths might not be the highest priority, but >>> Objects.requireNonNull is used pretty extensively in the JDK and my >>> expectation would be that it shouldn't degrade performance when >>> things actually are null now and then. >>> >>> /Claes >> >> This is a know issue, I think it's not related to the way the JIT >> handle exception path but what is called 'profile pollution'. >> Hotspot JITs have two ways to do a null check, either do nothing (yes >> nothing) and let the system do a fault and come back from dead using >> a signal handler, this solution is named implicit null check or by >> doing an explicit null check, i.e a conditional jump. >> Implicit null check is faster but if the receiver is null, it cost >> you an harm, so the VM profiles receiver to remember if the receiver >> of each call can be null or not. The problem is that when you call >> foo.toString(), the profile information is associated with the >> instruction that does foo.toString() while if the call is >> Objects.requireNonNull(foo), the profile associated with the >> nullcheck is stored inside the method requireNonNull, so if one call >> to requireNonNull in the entire program throw a NPE, the profile >> inside requireNonNull now register that it may fail, so for the VM >> all calls to requireNonNull may fail. So currently you should not use >> requireNonNull is the value is not required to be null* > I guess I should have given more details. :-) I ran my micros on a > number of forked VMs to ensure I don't get excessive run-to-run > variations, which among other things avoids profile pollution. Also I > sloppily collected very few samples and only did minimal warmup after > I saw that the micros produced scores that were orders of magnitude > apart and the values stabilized after less than two seconds: Flags: -f > 3 -wi 4 -i 2 > > When I run the micros sequentially in the same VM I see some added > degradation for the exceptional cases, but the 0p cases still inline > to the optimal(?) 360k ops/ms, so while it seems profile pollution > might play in when provoked, HotSpot seems to manage these simple > micros well enough. Ok, so you have to take a look to the generated assembly code :) https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly >> So the problem is that Hotspot blindly trusts the recorded profile >> compared to the profile that can come from the arguments of a call. >> The good news is that recently some patches were included in the jdk9 >> tree to fix or at least mitigate that issue. >> > I've now run tests on JDK8 FCS and a recent internal build of JDK9 and > see the same characteristics. How recently are we talking here? :-) I don't know, I have seen the patches but not dive into the source yet, it's on my todo list, maybe it's not even activated by default. > >> cheers, >> R?mi >> * read that last sentence again, it seems very logical, no ? >> > While your reading of the method name and suggested approach makes > sense right now, the javadoc for Objects.requireNonNull states "this > method is designed primarily for doing parameter validation in methods > and constructors". To me, "parameter validation" suggests that we're > dealing with unknowns and that there's at least some calculated risk > that the input might be null, so the intent is really to encourage > explicit fail-fast designs, no? The great Java Book is clear on that, you shall never try to recover from an exception that inherits from RuntimeException :) A runtime exception is an exception that developers throw at the head of their fellow developers to indicate that they should read the fucking manual. > I thus think it makes sense to try and ensure these methods have the > same performance characteristics as when provoking an implicit null > check by dereferencing an object. as I said, I think it's time to take a look to the generated assembly code. > > /Claes regards, R?mi From claes.redestad at oracle.com Wed Apr 30 12:17:46 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 30 Apr 2014 14:17:46 +0200 Subject: Remove redundant calls of toString() In-Reply-To: <5360D9BE.2000002@univ-mlv.fr> References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> <535DFBDE.6030701@oracle.com> <535E7734.7050602@oracle.com> <535F5548.9020807@univ-mlv.fr> <535F6EFB.1070701@oracle.com> <5360D9BE.2000002@univ-mlv.fr> Message-ID: <5360E9EA.5000200@oracle.com> On 2014-04-30 13:08, Remi Forax wrote: > On 04/29/2014 11:20 AM, Claes Redestad wrote: >> >> On 2014-04-29 09:31, Remi Forax wrote: >>> On 04/28/2014 05:43 PM, Claes Redestad wrote: >>>> On 04/28/2014 08:57 AM, David Holmes wrote: >>>>> On 28/04/2014 1:05 PM, Ot?vio Gon?alves de Santana wrote: >>>>>> In my opinion not, because Objects.requireNonNull is more >>>>>> readable than >>>>>> just string.toString. This way is more understandable which field is >>>>>> required and doesn't impact on performance. >>>>> >>>>> An invocation of requireNonNull is potentially more expensive than >>>>> the implicit null check that happens with foo.toString(). >>>>> >>>>> David >>>>> ----- >>>> >>>> My thought was that these two would be inlined to the exact same >>>> thing, so I did a quick test to see what happens when you do >>>> foo.toString() versus Objects.requireNonNull(foo) on a set of >>>> randomly generated String[]'s with different amounts of null >>>> elements(0p: no null entries, 1p: 1% null entries etc): >>>> >>>> Benchmark Mode Samples Mean >>>> Mean error Units >>>> s.m.ThrowAwayBenchmark.nullToString0p thrpt 6 356653.044 >>>> 3573.707 ops/ms >>>> s.m.ThrowAwayBenchmark.nullToString1p thrpt 6 >>>> 353128.903 2764.102 ops/ms >>>> s.m.ThrowAwayBenchmark.nullToString10p thrpt 6 >>>> 297956.571 9580.251 ops/ms >>>> s.m.ThrowAwayBenchmark.nullToString50p thrpt 6 >>>> 158172.036 1893.096 ops/ms >>>> s.m.ThrowAwayBenchmark.nullToString100p thrpt 6 >>>> 18194.614 472.091 ops/ms >>>> s.m.ThrowAwayBenchmark.requireNonNull0p thrpt 6 >>>> 357855.126 2979.090 ops/ms >>>> s.m.ThrowAwayBenchmark.requireNonNull1p thrpt 6 >>>> 67601.134 7004.689 ops/ms >>>> s.m.ThrowAwayBenchmark.requireNonNull10p thrpt 6 >>>> 8150.595 538.970 ops/ms >>>> s.m.ThrowAwayBenchmark.requireNonNull50p thrpt 6 >>>> 1604.919 220.903 ops/ms >>>> s.m.ThrowAwayBenchmark.requireNonNull100p thrpt 6 >>>> 820.626 60.752 ops/ms >>>> >>>> Yikes! As long as the value is never null they're inlined nicely >>>> and neither have the upper hand performance-wise, but as soon as >>>> you get some null values, Objects.requireNonNull degenerates much >>>> faster than its foo.toString counterpart. I think this is a JIT >>>> issue - optimizing exception-paths might not be the highest >>>> priority, but Objects.requireNonNull is used pretty extensively in >>>> the JDK and my expectation would be that it shouldn't degrade >>>> performance when things actually are null now and then. >>>> >>>> /Claes >>> >>> This is a know issue, I think it's not related to the way the JIT >>> handle exception path but what is called 'profile pollution'. >>> Hotspot JITs have two ways to do a null check, either do nothing >>> (yes nothing) and let the system do a fault and come back from dead >>> using a signal handler, this solution is named implicit null check >>> or by doing an explicit null check, i.e a conditional jump. >>> Implicit null check is faster but if the receiver is null, it cost >>> you an harm, so the VM profiles receiver to remember if the receiver >>> of each call can be null or not. The problem is that when you call >>> foo.toString(), the profile information is associated with the >>> instruction that does foo.toString() while if the call is >>> Objects.requireNonNull(foo), the profile associated with the >>> nullcheck is stored inside the method requireNonNull, so if one call >>> to requireNonNull in the entire program throw a NPE, the profile >>> inside requireNonNull now register that it may fail, so for the VM >>> all calls to requireNonNull may fail. So currently you should not >>> use requireNonNull is the value is not required to be null* >> I guess I should have given more details. :-) I ran my micros on a >> number of forked VMs to ensure I don't get excessive run-to-run >> variations, which among other things avoids profile pollution. Also I >> sloppily collected very few samples and only did minimal warmup after >> I saw that the micros produced scores that were orders of magnitude >> apart and the values stabilized after less than two seconds: Flags: >> -f 3 -wi 4 -i 2 >> >> When I run the micros sequentially in the same VM I see some added >> degradation for the exceptional cases, but the 0p cases still inline >> to the optimal(?) 360k ops/ms, so while it seems profile pollution >> might play in when provoked, HotSpot seems to manage these simple >> micros well enough. > > Ok, so you have to take a look to the generated assembly code :) > https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly I've discussed the problem with some members of the compiler team who seem to think they have a pretty good idea about what's happening and thought I should file an RFE for this: https://bugs.openjdk.java.net/browse/JDK-8042127 - I suggest we continue the discussion there and/or start a new thread on this topic. > >>> So the problem is that Hotspot blindly trusts the recorded profile >>> compared to the profile that can come from the arguments of a call. >>> The good news is that recently some patches were included in the >>> jdk9 tree to fix or at least mitigate that issue. >>> >> I've now run tests on JDK8 FCS and a recent internal build of JDK9 >> and see the same characteristics. How recently are we talking here? :-) > > I don't know, I have seen the patches but not dive into the source > yet, it's on my todo list, maybe it's not even activated by default. > >> >>> cheers, >>> R?mi >>> * read that last sentence again, it seems very logical, no ? >>> >> While your reading of the method name and suggested approach makes >> sense right now, the javadoc for Objects.requireNonNull states "this >> method is designed primarily for doing parameter validation in >> methods and constructors". To me, "parameter validation" suggests >> that we're dealing with unknowns and that there's at least some >> calculated risk that the input might be null, so the intent is really >> to encourage explicit fail-fast designs, no? > > The great Java Book is clear on that, you shall never try to recover > from an exception that inherits from RuntimeException :) > A runtime exception is an exception that developers throw at the head > of their fellow developers to indicate that they should read the > fucking manual. I completely agree with you, however, I still think this is something that might happen in production systems because of reasons, so while we can't eliminate the penalty I still think it's a reasonable request to try and achieve a similarly graceful performance degradation as when doing implicit null checks. /Claes > >> I thus think it makes sense to try and ensure these methods have the >> same performance characteristics as when provoking an implicit null >> check by dereferencing an object. > > as I said, I think it's time to take a look to the generated assembly > code. > >> >> /Claes > > regards, > R?mi > From weijun.wang at oracle.com Wed Apr 30 14:03:54 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 30 Apr 2014 22:03:54 +0800 Subject: Guidance about binary / data files for JTREG tests In-Reply-To: <5360D649.5040407@redhat.com> References: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> <9735C985-B2CC-4433-B131-53B3E8D586D2@oracle.com> <535F9C84.8000101@oracle.com> <5360D649.5040407@redhat.com> Message-ID: <6BB551FE-22B0-47FE-A2CE-6967FB1D7D02@oracle.com> Florian Just curious, how do you deal with a file like this http://hg.openjdk.java.net/jdk9/dev/jdk/file/4e7f3aac979b/test/sun/security/krb5/ktab/HighestKvno.java Is the byte array inside considered binary? Thanks Max On Apr 30, 2014, at 18:54, Florian Weimer wrote: > On 04/29/2014 02:35 PM, Alan Bateman wrote: > >> The other thing that came up previously is distributions that have a >> policy of not allowing binary files. If I'm not mistake then they are >> deleted by downstream patches, which in this case would lead to a test >> failure. > > Debian and Fedora are concerned with binary files which have closed source files. These are stripped when noticed. There is no indiscriminate deletion of binary files during the packaging process. > > The Debian packaging tools had a problem with shipping binary data in local changes, but that's history now. > > -- > Florian Weimer / Red Hat Product Security Team From fweimer at redhat.com Wed Apr 30 14:13:03 2014 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 30 Apr 2014 16:13:03 +0200 Subject: Guidance about binary / data files for JTREG tests In-Reply-To: <6BB551FE-22B0-47FE-A2CE-6967FB1D7D02@oracle.com> References: <148DA11D-7B10-4761-88AD-7E9BD503C536@oracle.com> <9735C985-B2CC-4433-B131-53B3E8D586D2@oracle.com> <535F9C84.8000101@oracle.com> <5360D649.5040407@redhat.com> <6BB551FE-22B0-47FE-A2CE-6967FB1D7D02@oracle.com> Message-ID: <536104EF.7090909@redhat.com> On 04/30/2014 04:03 PM, Wang Weijun wrote: > Florian > > Just curious, how do you deal with a file like this > > http://hg.openjdk.java.net/jdk9/dev/jdk/file/4e7f3aac979b/test/sun/security/krb5/ktab/HighestKvno.java > > Is the byte array inside considered binary? We consider content problematic for which source code apparently exists (and which is the preferred form of making modifications), but it's not part of the sources we use to build RPM packages. The comment above the byte array indicates that this situation is different in this case, and I don't think Fedora or Debian has problems with it. For more authoritative information on this particular case, you'd have to ask on the fedora-legal or debian-legal mailing lists. (I'm treating this a question about policies for content inclusion in free software distributions?this is not legal advice.) -- Florian Weimer / Red Hat Product Security Team From Alan.Bateman at oracle.com Wed Apr 30 15:17:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Apr 2014 16:17:02 +0100 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <535A91AD.4040405@oracle.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> Message-ID: <536113EE.3060100@oracle.com> On 25/04/2014 17:47, roger riggs wrote: > Hi Peter, > > Including the test update with the updated changeset is fine. > > (I think Alan had some comments on the refactoring and has not yet had > a chance to comment). > > Thanks, Roger > I reviewed previous rounds and you've addressed my points so I think I'm mostly happy with this. As some point I think we should look at Platform again as there may be an opportunity later in JDK 9 to move it out of UNIXProcess. One thing that I wasn't sure about is the additions to the @author tags as we've mostly been trying not to grow these (contentious topic, I don't have a strong opinion as I never use @author). A minor comment looking at the latest webrev.07 is that some of the lines are very long. It's not a problem now but I could image future side-by-side reviews needing a scroll bar.DeferredCloseProcessPipeInputStream is very long too. -Alan. From martinrb at google.com Wed Apr 30 16:25:06 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 30 Apr 2014 09:25:06 -0700 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <536113EE.3060100@oracle.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> <536113EE.3060100@oracle.com> Message-ID: Belated review. Peter, thank you very much for taking on this difficult unification task. This is great work! Comments: --- --- + case SOLARIS: + if (osArch.equals("x86")) { osArch = "i386"; } It's very sad that ... there's no portable way of getting the name of libarchdir. I thought os.arch system property would suffice, but apparently not on Solaris? --- To avoid repetition, I would iniitalize with a vararg list of launch mechanisms, of which the first one is always the default. + LINUX(LaunchMechanism.VFORK, EnumSet.of(LaunchMechanism.FORK, LaunchMechanism.VFORK)), LINUX(LaunchMechanism.VFORK, LaunchMechanism.FORK), --- Never use toUpperCase without a Locale, to avoid the "Turkish i problem" + lm = LaunchMechanism.valueOf(s.toUpperCase()); toUpperCase(Locale.ENGLISH) On Wed, Apr 30, 2014 at 8:17 AM, Alan Bateman wrote: > On 25/04/2014 17:47, roger riggs wrote: > >> Hi Peter, >> >> Including the test update with the updated changeset is fine. >> >> (I think Alan had some comments on the refactoring and has not yet had a >> chance to comment). >> >> Thanks, Roger >> >> I reviewed previous rounds and you've addressed my points so I think I'm > mostly happy with this. As some point I think we should look at Platform > again as there may be an opportunity later in JDK 9 to move it out of > UNIXProcess. > > One thing that I wasn't sure about is the additions to the @author tags as > we've mostly been trying not to grow these (contentious topic, I don't have > a strong opinion as I never use @author). > > A minor comment looking at the latest webrev.07 is that some of the lines > are very long. It's not a problem now but I could image future side-by-side > reviews needing a scroll bar.DeferredCloseProcessPipeInputStream is very > long too. > > -Alan. > From neil.toda at oracle.com Wed Apr 30 20:47:14 2014 From: neil.toda at oracle.com (Neil Toda) Date: Wed, 30 Apr 2014 13:47:14 -0700 Subject: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <536029F0.9000406@oracle.com> References: <536029F0.9000406@oracle.com> Message-ID: <53616152.9070600@oracle.com> Please review Launcher change and test. I've added to the Launcher test : FXLauncherTest.java The test will now check that LauncherHelper$FXHelper is not loaded for non-JavaFX class and jar files. webrev.02 contains only review suggestions from webrev.01 and the new test class. http://cr.openjdk.java.net/~ntoda/8035782/webrev.02/ for bug: https://bugs.openjdk.java.net/browse/JDK-8035782 Thanks -neil From joe.darcy at oracle.com Wed Apr 30 21:49:09 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Apr 2014 14:49:09 -0700 Subject: Remove redundant calls of toString() In-Reply-To: References: <535D2BCB.8090707@univ-mlv.fr> <535DBE11.2000303@oracle.com> Message-ID: <53616FD5.20502@oracle.com> In general, I think Objects.requireNonNull() should often be considered idiomatic Java. If the constant-folding is to be avoided, I would prefer to see "foo".toString(); have a comment like "foo".toString(); // Avoid mandatory constant propagation -Joe On 04/27/2014 08:05 PM, Ot?vio Gon?alves de Santana wrote: > In my opinion not, because Objects.requireNonNull is more readable than > just string.toString. This way is more understandable which field is > required and doesn't impact on performance. > > > On Sun, Apr 27, 2014 at 11:33 PM, David Holmes wrote: > >> On 28/04/2014 3:41 AM, Ot?vio Gon?alves de Santana wrote: >> >>> sorry. >>> I tried answer and the message was twice. >>> But Yes when has null pointer possibility I replaced to >>> Objects.requireNonNull. >>> >> In my opinion that is making the code worse not better. >> >> David >> ----- >> >> >> I am review the code again. >>> The code below: >>> >>> diff -r e323c74edabd >>> src/share/classes/com/sun/tools/example/debug/tty/Commands.java >>> --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Sun >>> Apr 27 14:33:45 2014 -0300 >>> @@ -1653,20 +1653,20 @@ >>> String expr = t.nextToken(""); >>> Value val = evaluate(expr); >>> if (val == null) { >>> - MessageOutput.println("expr is null", expr.toString()); >>> + MessageOutput.println("expr is >>> null",Objects.requireNonNull(expr)); >>> } else if (dumpObject && (val instanceof ObjectReference) && >>> !(val instanceof StringReference)) { >>> ObjectReference obj = (ObjectReference)val; >>> ReferenceType refType = obj.referenceType(); >>> MessageOutput.println("expr is value", >>> - new Object [] {expr.toString(), >>> + new Object [] >>> {Objects.requireNonNull(expr), >>> >>> MessageOutput.format("grouping begin character")}); >>> dump(obj, refType, refType); >>> MessageOutput.println("grouping end character"); >>> } else { >>> String strVal = getStringValue(); >>> if (strVal != null) { >>> - MessageOutput.println("expr is value", new Object [] >>> {expr.toString(), >>> + MessageOutput.println("expr is value", new Object [] >>> {Objects.requireNonNull(expr), >>> >>> strVal}); >>> } >>> } >>> diff -r e323c74edabd >>> src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>> --- >>> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ >>> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>> Sun >>> Apr 27 14:33:45 2014 -0300 >>> @@ -25,6 +25,8 @@ >>> >>> package java.lang.annotation; >>> >>> +import java.util.Objects; >>> + >>> /** >>> * Thrown to indicate that a program has attempted to access an element >>> of >>> * an annotation type that was added to the annotation type definition >>> after >>> @@ -56,7 +58,7 @@ >>> Class annotationType, >>> String elementName) { >>> super(annotationType.getName() + " missing element " + >>> - elementName.toString()); >>> + Objects.requireNonNull(elementName)); >>> >>> this.annotationType = annotationType; >>> this.elementName = elementName; >>> diff -r e323c74edabd src/share/classes/java/text/DateFormatSymbols.java >>> --- a/src/share/classes/java/text/DateFormatSymbols.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/java/text/DateFormatSymbols.java Sun Apr 27 >>> 14:33:45 2014 -0300 >>> @@ -594,7 +594,7 @@ >>> */ >>> public void setLocalPatternChars(String newLocalPatternChars) { >>> // Call toString() to throw an NPE in case the argument is null >>> - localPatternChars = newLocalPatternChars.toString(); >>> + localPatternChars = Objects.requireNonNull( >>> newLocalPatternChars); >>> cachedHashCode = 0; >>> } >>> >>> diff -r e323c74edabd >>> src/share/classes/javax/management/modelmbean/DescriptorSupport.java >>> --- a/src/share/classes/javax/management/modelmbean/DescriptorSupport.java >>> Wed >>> Apr 23 11:35:40 2014 -0700 >>> +++ b/src/share/classes/javax/management/modelmbean/DescriptorSupport.java >>> Sun >>> Apr 27 14:33:45 2014 -0300 >>> @@ -43,13 +43,7 @@ >>> import java.lang.reflect.Constructor; >>> >>> import java.security.AccessController; >>> -import java.util.HashMap; >>> -import java.util.Iterator; >>> -import java.util.Map; >>> -import java.util.Set; >>> -import java.util.SortedMap; >>> -import java.util.StringTokenizer; >>> -import java.util.TreeMap; >>> +import java.util.*; >>> import java.util.logging.Level; >>> >>> import javax.management.Descriptor; >>> @@ -665,7 +659,7 @@ >>> "getFieldNames()", "Field is null"); >>> } >>> } else { >>> - responseFields[i] = currElement.getKey().toString(); >>> + responseFields[i] = >>> Objects.requireNonNull(currElement.getKey()); >>> } >>> } >>> >>> @@ -929,7 +923,7 @@ >>> if (currElement != null) { >>> if (currElement.getValue() != null) { >>> // validate the field valued... >>> - if (validateField((currElement.getKey()).toString(), >>> + if >>> (validateField((Objects.requireNonNull(currElement.getKey())), >>> >>> (currElement.getValue()).toString())) { >>> continue; >>> } else { >>> diff -r e323c74edabd src/share/classes/javax/swing/ >>> text/html/FormView.java >>> --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/javax/swing/text/html/FormView.java Sun Apr 27 >>> 14:33:45 2014 -0300 >>> @@ -478,7 +478,7 @@ >>> base.getPort(), base.getFile()) >>> : new URL(base, action); >>> if (!isPostMethod) { >>> - String query = data.toString(); >>> + String query = Objects.requireNonNull(data); >>> actionURL = new URL(actionURL + "?" + query); >>> } >>> } catch (MalformedURLException e) { >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java >>> --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 >>> 2014 >>> -0700 >>> +++ b/src/share/classes/sun/java2d/loops/Blit.java Sun Apr 27 14:33:45 >>> 2014 >>> -0300 >>> @@ -50,7 +50,7 @@ >>> >>> public class Blit extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = "Blit(...)".toString(); >>> + public static final String methodSignature = "Blit(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java >>> --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sun Apr 27 14:33:45 >>> 2014 -0300 >>> @@ -54,7 +54,7 @@ >>> */ >>> public class BlitBg extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "BlitBg(...)".toString(); >>> + public static final String methodSignature = "BlitBg(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>> loops/DrawGlyphList.java >>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sun Apr 27 >>> 14:33:45 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> */ >>> public class DrawGlyphList extends GraphicsPrimitive { >>> >>> - public final static String methodSignature = >>> "DrawGlyphList(...)".toString(); >>> + public final static String methodSignature = "DrawGlyphList(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>> loops/DrawGlyphListAA.java >>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sun Apr 27 >>> 14:33:45 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> */ >>> public class DrawGlyphListAA extends GraphicsPrimitive { >>> >>> - public final static String methodSignature = >>> "DrawGlyphListAA(...)".toString(); >>> + public final static String methodSignature = "DrawGlyphListAA(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java >>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sun Apr 27 >>> 14:33:45 2014 -0300 >>> @@ -40,7 +40,7 @@ >>> public class DrawGlyphListLCD extends GraphicsPrimitive { >>> >>> public final static String >>> - methodSignature = "DrawGlyphListLCD(...)".toString(); >>> + methodSignature = "DrawGlyphListLCD(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java >>> --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sun Apr 27 >>> 14:33:45 >>> 2014 -0300 >>> @@ -44,7 +44,7 @@ >>> */ >>> public class DrawLine extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "DrawLine(...)".toString(); >>> + public final static String methodSignature = "DrawLine(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/DrawParallelogram.java >>> --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed Apr >>> 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sun Apr >>> 27 >>> 14:33:45 2014 -0300 >>> @@ -43,7 +43,7 @@ >>> public class DrawParallelogram extends GraphicsPrimitive >>> { >>> public final static String methodSignature = >>> - "DrawParallelogram(...)".toString(); >>> + "DrawParallelogram(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java >>> --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sun Apr 27 >>> 14:33:45 >>> 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> public class DrawPath extends GraphicsPrimitive { >>> >>> public final static String methodSignature = >>> - "DrawPath(...)".toString(); >>> + "DrawPath(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPolygons.java >>> --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sun Apr 27 >>> 14:33:45 2014 -0300 >>> @@ -41,7 +41,7 @@ >>> */ >>> public class DrawPolygons extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "DrawPolygons(...)".toString(); >>> + public final static String methodSignature = "DrawPolygons(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java >>> --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sun Apr 27 >>> 14:33:45 >>> 2014 -0300 >>> @@ -44,7 +44,7 @@ >>> */ >>> public class DrawRect extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "DrawRect(...)".toString(); >>> + public final static String methodSignature = "DrawRect(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd >>> src/share/classes/sun/java2d/loops/FillParallelogram.java >>> --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed Apr >>> 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sun Apr >>> 27 >>> 14:33:45 2014 -0300 >>> @@ -41,7 +41,7 @@ >>> public class FillParallelogram extends GraphicsPrimitive >>> { >>> public final static String methodSignature = >>> - "FillParallelogram(...)".toString(); >>> + "FillParallelogram(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java >>> --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sun Apr 27 >>> 14:33:45 >>> 2014 -0300 >>> @@ -39,7 +39,7 @@ >>> public class FillPath extends GraphicsPrimitive { >>> >>> public final static String methodSignature = >>> - "FillPath(...)".toString(); >>> + "FillPath(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java >>> --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sun Apr 27 >>> 14:33:45 >>> 2014 -0300 >>> @@ -44,7 +44,7 @@ >>> */ >>> public class FillRect extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "FillRect(...)".toString(); >>> + public final static String methodSignature = "FillRect(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java >>> --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sun Apr 27 >>> 14:33:45 >>> 2014 -0300 >>> @@ -45,7 +45,7 @@ >>> */ >>> public class FillSpans extends GraphicsPrimitive >>> { >>> - public final static String methodSignature = >>> "FillSpans(...)".toString(); >>> + public final static String methodSignature = "FillSpans(...)"; >>> >>> public final static int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java >>> --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sun Apr 27 >>> 14:33:45 >>> 2014 -0300 >>> @@ -48,7 +48,7 @@ >>> >>> public class MaskBlit extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "MaskBlit(...)".toString(); >>> + public static final String methodSignature = "MaskBlit(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java >>> --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 >>> 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sun Apr 27 >>> 14:33:45 >>> 2014 -0300 >>> @@ -50,11 +50,11 @@ >>> */ >>> public class MaskFill extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "MaskFill(...)".toString(); >>> + public static final String methodSignature = "MaskFill(...)"; >>> public static final String fillPgramSignature = >>> - "FillAAPgram(...)".toString(); >>> + "FillAAPgram(...)"; >>> public static final String drawPgramSignature = >>> - "DrawAAPgram(...)".toString(); >>> + "DrawAAPgram(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java >>> --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sun Apr 27 >>> 14:33:45 2014 -0300 >>> @@ -45,7 +45,7 @@ >>> >>> public class ScaledBlit extends GraphicsPrimitive >>> { >>> - public static final String methodSignature = >>> "ScaledBlit(...)".toString(); >>> + public static final String methodSignature = "ScaledBlit(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>> loops/TransformBlit.java >>> --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sun Apr 27 >>> 14:33:45 2014 -0300 >>> @@ -47,7 +47,7 @@ >>> public class TransformBlit extends GraphicsPrimitive >>> { >>> public static final String methodSignature = >>> - "TransformBlit(...)".toString(); >>> + "TransformBlit(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>> loops/TransformHelper.java >>> --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sun Apr 27 >>> 14:33:45 2014 -0300 >>> @@ -46,7 +46,7 @@ >>> public class TransformHelper extends GraphicsPrimitive >>> { >>> public static final String methodSignature = >>> - "TransformHelper(...)".toString(); >>> + "TransformHelper(...)"; >>> >>> public static final int primTypeID = makePrimTypeID(); >>> >>> diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java >>> --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 >>> 2014 -0700 >>> +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sun Apr 27 14:33:45 >>> 2014 -0300 >>> @@ -25,6 +25,7 @@ >>> >>> package sun.misc; >>> >>> +import java.util.Objects; >>> import java.util.StringTokenizer; >>> import java.util.jar.Attributes; >>> import java.util.jar.Attributes.Name; >>> @@ -260,11 +261,11 @@ >>> >>> // Convert token into meaning number for comparision >>> if (stk.hasMoreTokens()) >>> - n = convertToken(stk.nextToken().toString()); >>> + n = convertToken(Objects.requireNonNull(stk.nextToken())); >>> >>> // Convert token into meaning number for comparision >>> if (ttk.hasMoreTokens()) >>> - m = convertToken(ttk.nextToken().toString()); >>> + m = convertToken(Objects.requireNonNull(ttk.nextToken())); >>> >>> if (n > m) >>> return 1; >>> diff -r e323c74edabd >>> src/share/classes/sun/tools/jconsole/inspector/Utils.java >>> --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr >>> 23 >>> 11:35:40 2014 -0700 >>> +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sun Apr >>> 27 >>> 14:33:45 2014 -0300 >>> @@ -378,7 +378,7 @@ >>> if (userInput instanceof XObject) { >>> result[i] = ((XObject) userInput).getObject(); >>> } else { >>> - result[i] = createObjectFromString(params[i].toString(), >>> + result[i] = >>> createObjectFromString(Objects.requireNonNull(params[i]), >>> (String) userInput); >>> } >>> } >>> >>> >>> >>> >>> On Sun, Apr 27, 2014 at 1:09 PM, Remi Forax wrote: >>> >>> On 04/27/2014 03:15 PM, Ot?vio Gon?alves de Santana wrote: >>>> There is an issue that was opened to remove redundant calls of >>>>> toString() >>>>> on String objects. [1] >>>>> I went deep on all JVM sources and I found all, 32 changes. >>>>> >>>>> >>>>> [1]https://bugs.openjdk.java.net/browse/JDK-8015470 >>>>> >>>>> >>>> Otavio, >>>> calling toString() on a String has the side effect to implicitly check >>>> that the reference is not null. >>>> Do you have checked that for each redundant call, the String can never be >>>> null ? >>>> >>>> regards, >>>> R?mi >>>> >>>> >>>> >>>> >>>>> diff -r e323c74edabd >>>>> src/share/classes/com/sun/tools/example/debug/tty/Commands.java >>>>> --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java >>>>> Wed >>>>> Apr 23 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java >>>>> Sat >>>>> Apr 26 01:40:27 2014 -0300 >>>>> @@ -1653,20 +1653,20 @@ >>>>> String expr = t.nextToken(""); >>>>> Value val = evaluate(expr); >>>>> if (val == null) { >>>>> - MessageOutput.println("expr is null", expr.toString()); >>>>> + MessageOutput.println("expr is null", expr); >>>>> } else if (dumpObject && (val instanceof >>>>> ObjectReference) && >>>>> !(val instanceof StringReference)) { >>>>> ObjectReference obj = (ObjectReference)val; >>>>> ReferenceType refType = obj.referenceType(); >>>>> MessageOutput.println("expr is value", >>>>> - new Object [] {expr.toString(), >>>>> + new Object [] {expr, >>>>> >>>>> MessageOutput.format("grouping begin character")}); >>>>> dump(obj, refType, refType); >>>>> MessageOutput.println("grouping end character"); >>>>> } else { >>>>> String strVal = getStringValue(); >>>>> if (strVal != null) { >>>>> - MessageOutput.println("expr is value", new Object >>>>> [] >>>>> {expr.toString(), >>>>> + MessageOutput.println("expr is value", new Object >>>>> [] >>>>> {expr, >>>>> >>>>> strVal}); >>>>> } >>>>> } >>>>> diff -r e323c74edabd >>>>> src/share/classes/java/lang/annotation/IncompleteAnnotationException. >>>>> java >>>>> --- >>>>> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException. >>>>> java >>>>> Wed >>>>> Apr 23 11:35:40 2014 -0700 >>>>> +++ >>>>> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException. >>>>> java >>>>> Sat >>>>> Apr 26 01:40:27 2014 -0300 >>>>> @@ -56,7 +56,7 @@ >>>>> Class annotationType, >>>>> String elementName) { >>>>> super(annotationType.getName() + " missing element " + >>>>> - elementName.toString()); >>>>> + elementName); >>>>> >>>>> this.annotationType = annotationType; >>>>> this.elementName = elementName; >>>>> diff -r e323c74edabd src/share/classes/java/text/DateFormatSymbols.java >>>>> --- a/src/share/classes/java/text/DateFormatSymbols.java Wed Apr 23 >>>>> 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/java/text/DateFormatSymbols.java Sat Apr 26 >>>>> 01:40:27 >>>>> 2014 -0300 >>>>> @@ -593,8 +593,8 @@ >>>>> * pattern characters. >>>>> */ >>>>> public void setLocalPatternChars(String newLocalPatternChars) { >>>>> - // Call toString() to throw an NPE in case the argument is null >>>>> - localPatternChars = newLocalPatternChars.toString(); >>>>> + >>>>> + localPatternChars = Objects.requireNonNull( >>>>> newLocalPatternChars); >>>>> cachedHashCode = 0; >>>>> } >>>>> >>>>> diff -r e323c74edabd >>>>> src/share/classes/javax/management/modelmbean/DescriptorSupport.java >>>>> --- a/src/share/classes/javax/management/modelmbean/ >>>>> DescriptorSupport.java >>>>> Wed >>>>> Apr 23 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/javax/management/modelmbean/ >>>>> DescriptorSupport.java >>>>> Sat >>>>> Apr 26 01:40:27 2014 -0300 >>>>> @@ -665,7 +665,7 @@ >>>>> "getFieldNames()", "Field is null"); >>>>> } >>>>> } else { >>>>> - responseFields[i] = currElement.getKey().toString(); >>>>> + responseFields[i] = currElement.getKey(); >>>>> } >>>>> } >>>>> >>>>> @@ -929,8 +929,8 @@ >>>>> if (currElement != null) { >>>>> if (currElement.getValue() != null) { >>>>> // validate the field valued... >>>>> - if (validateField((currElement. >>>>> getKey()).toString(), >>>>> - >>>>> (currElement.getValue()).toString())) { >>>>> + if (validateField((currElement.getKey()), >>>>> + (currElement.getValue()))) { >>>>> continue; >>>>> } else { >>>>> if (MODELMBEAN_LOGGER.isLoggable( >>>>> Level.FINEST)) >>>>> { >>>>> diff -r e323c74edabd src/share/classes/javax/swing/ >>>>> text/html/FormView.java >>>>> --- a/src/share/classes/javax/swing/text/html/FormView.java Wed Apr 23 >>>>> 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/javax/swing/text/html/FormView.java Sat Apr 26 >>>>> 01:40:27 2014 -0300 >>>>> @@ -478,7 +478,7 @@ >>>>> base.getPort(), >>>>> base.getFile()) >>>>> : new URL(base, action); >>>>> if (!isPostMethod) { >>>>> - String query = data.toString(); >>>>> + String query = data; >>>>> actionURL = new URL(actionURL + "?" + query); >>>>> } >>>>> } catch (MalformedURLException e) { >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/Blit.java >>>>> --- a/src/share/classes/sun/java2d/loops/Blit.java Wed Apr 23 11:35:40 >>>>> 2014 >>>>> -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/Blit.java Sat Apr 26 01:40:27 >>>>> 2014 >>>>> -0300 >>>>> @@ -50,7 +50,7 @@ >>>>> >>>>> public class Blit extends GraphicsPrimitive >>>>> { >>>>> - public static final String methodSignature = >>>>> "Blit(...)".toString(); >>>>> + public static final String methodSignature = "Blit(...)"; >>>>> >>>>> public static final int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/BlitBg.java >>>>> --- a/src/share/classes/sun/java2d/loops/BlitBg.java Wed Apr 23 >>>>> 11:35:40 >>>>> 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/BlitBg.java Sat Apr 26 >>>>> 01:40:27 >>>>> 2014 -0300 >>>>> @@ -54,7 +54,7 @@ >>>>> */ >>>>> public class BlitBg extends GraphicsPrimitive >>>>> { >>>>> - public static final String methodSignature = >>>>> "BlitBg(...)".toString(); >>>>> + public static final String methodSignature = "BlitBg(...)"; >>>>> >>>>> public static final int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>>>> loops/DrawGlyphList.java >>>>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphList.java Wed Apr 23 >>>>> 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphList.java Sat Apr 26 >>>>> 01:40:27 2014 -0300 >>>>> @@ -39,7 +39,7 @@ >>>>> */ >>>>> public class DrawGlyphList extends GraphicsPrimitive { >>>>> >>>>> - public final static String methodSignature = >>>>> "DrawGlyphList(...)".toString(); >>>>> + public final static String methodSignature = "DrawGlyphList(...)"; >>>>> >>>>> public final static int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>>>> loops/DrawGlyphListAA.java >>>>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Wed Apr >>>>> 23 >>>>> 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListAA.java Sat Apr >>>>> 26 >>>>> 01:40:27 2014 -0300 >>>>> @@ -39,7 +39,7 @@ >>>>> */ >>>>> public class DrawGlyphListAA extends GraphicsPrimitive { >>>>> >>>>> - public final static String methodSignature = >>>>> "DrawGlyphListAA(...)".toString(); >>>>> + public final static String methodSignature = >>>>> "DrawGlyphListAA(...)"; >>>>> >>>>> public final static int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd >>>>> src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java >>>>> --- a/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Wed Apr >>>>> 23 >>>>> 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/DrawGlyphListLCD.java Sat Apr >>>>> 26 >>>>> 01:40:27 2014 -0300 >>>>> @@ -40,7 +40,7 @@ >>>>> public class DrawGlyphListLCD extends GraphicsPrimitive { >>>>> >>>>> public final static String >>>>> - methodSignature = "DrawGlyphListLCD(...)".toString(); >>>>> + methodSignature = "DrawGlyphListLCD(...)"; >>>>> >>>>> public final static int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawLine.java >>>>> --- a/src/share/classes/sun/java2d/loops/DrawLine.java Wed Apr 23 >>>>> 11:35:40 >>>>> 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/DrawLine.java Sat Apr 26 >>>>> 01:40:27 >>>>> 2014 -0300 >>>>> @@ -44,7 +44,7 @@ >>>>> */ >>>>> public class DrawLine extends GraphicsPrimitive >>>>> { >>>>> - public final static String methodSignature = >>>>> "DrawLine(...)".toString(); >>>>> + public final static String methodSignature = "DrawLine(...)"; >>>>> >>>>> public final static int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd >>>>> src/share/classes/sun/java2d/loops/DrawParallelogram.java >>>>> --- a/src/share/classes/sun/java2d/loops/DrawParallelogram.java Wed Apr >>>>> 23 >>>>> 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/DrawParallelogram.java Sat Apr >>>>> 26 >>>>> 01:40:27 2014 -0300 >>>>> @@ -43,7 +43,7 @@ >>>>> public class DrawParallelogram extends GraphicsPrimitive >>>>> { >>>>> public final static String methodSignature = >>>>> - "DrawParallelogram(...)".toString(); >>>>> + "DrawParallelogram(...)"; >>>>> >>>>> public final static int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawPath.java >>>>> --- a/src/share/classes/sun/java2d/loops/DrawPath.java Wed Apr 23 >>>>> 11:35:40 >>>>> 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/DrawPath.java Sat Apr 26 >>>>> 01:40:27 >>>>> 2014 -0300 >>>>> @@ -39,7 +39,7 @@ >>>>> public class DrawPath extends GraphicsPrimitive { >>>>> >>>>> public final static String methodSignature = >>>>> - "DrawPath(...)".toString(); >>>>> + "DrawPath(...)"; >>>>> >>>>> public final static int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>>>> loops/DrawPolygons.java >>>>> --- a/src/share/classes/sun/java2d/loops/DrawPolygons.java Wed Apr 23 >>>>> 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/DrawPolygons.java Sat Apr 26 >>>>> 01:40:27 >>>>> 2014 -0300 >>>>> @@ -41,7 +41,7 @@ >>>>> */ >>>>> public class DrawPolygons extends GraphicsPrimitive >>>>> { >>>>> - public final static String methodSignature = >>>>> "DrawPolygons(...)".toString(); >>>>> + public final static String methodSignature = "DrawPolygons(...)"; >>>>> >>>>> public final static int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/DrawRect.java >>>>> --- a/src/share/classes/sun/java2d/loops/DrawRect.java Wed Apr 23 >>>>> 11:35:40 >>>>> 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/DrawRect.java Sat Apr 26 >>>>> 01:40:27 >>>>> 2014 -0300 >>>>> @@ -44,7 +44,7 @@ >>>>> */ >>>>> public class DrawRect extends GraphicsPrimitive >>>>> { >>>>> - public final static String methodSignature = >>>>> "DrawRect(...)".toString(); >>>>> + public final static String methodSignature = "DrawRect(...)"; >>>>> >>>>> public final static int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd >>>>> src/share/classes/sun/java2d/loops/FillParallelogram.java >>>>> --- a/src/share/classes/sun/java2d/loops/FillParallelogram.java Wed Apr >>>>> 23 >>>>> 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/FillParallelogram.java Sat Apr >>>>> 26 >>>>> 01:40:27 2014 -0300 >>>>> @@ -41,7 +41,7 @@ >>>>> public class FillParallelogram extends GraphicsPrimitive >>>>> { >>>>> public final static String methodSignature = >>>>> - "FillParallelogram(...)".toString(); >>>>> + "FillParallelogram(...)"; >>>>> >>>>> public final static int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillPath.java >>>>> --- a/src/share/classes/sun/java2d/loops/FillPath.java Wed Apr 23 >>>>> 11:35:40 >>>>> 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/FillPath.java Sat Apr 26 >>>>> 01:40:27 >>>>> 2014 -0300 >>>>> @@ -39,7 +39,7 @@ >>>>> public class FillPath extends GraphicsPrimitive { >>>>> >>>>> public final static String methodSignature = >>>>> - "FillPath(...)".toString(); >>>>> + "FillPath(...)"; >>>>> >>>>> public final static int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillRect.java >>>>> --- a/src/share/classes/sun/java2d/loops/FillRect.java Wed Apr 23 >>>>> 11:35:40 >>>>> 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/FillRect.java Sat Apr 26 >>>>> 01:40:27 >>>>> 2014 -0300 >>>>> @@ -44,7 +44,7 @@ >>>>> */ >>>>> public class FillRect extends GraphicsPrimitive >>>>> { >>>>> - public final static String methodSignature = >>>>> "FillRect(...)".toString(); >>>>> + public final static String methodSignature = "FillRect(...)"; >>>>> >>>>> public final static int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/FillSpans.java >>>>> --- a/src/share/classes/sun/java2d/loops/FillSpans.java Wed Apr 23 >>>>> 11:35:40 >>>>> 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/FillSpans.java Sat Apr 26 >>>>> 01:40:27 >>>>> 2014 -0300 >>>>> @@ -45,7 +45,7 @@ >>>>> */ >>>>> public class FillSpans extends GraphicsPrimitive >>>>> { >>>>> - public final static String methodSignature = >>>>> "FillSpans(...)".toString(); >>>>> + public final static String methodSignature = "FillSpans(...)"; >>>>> >>>>> public final static int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskBlit.java >>>>> --- a/src/share/classes/sun/java2d/loops/MaskBlit.java Wed Apr 23 >>>>> 11:35:40 >>>>> 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/MaskBlit.java Sat Apr 26 >>>>> 01:40:27 >>>>> 2014 -0300 >>>>> @@ -48,7 +48,7 @@ >>>>> >>>>> public class MaskBlit extends GraphicsPrimitive >>>>> { >>>>> - public static final String methodSignature = >>>>> "MaskBlit(...)".toString(); >>>>> + public static final String methodSignature = "MaskBlit(...)"; >>>>> >>>>> public static final int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/MaskFill.java >>>>> --- a/src/share/classes/sun/java2d/loops/MaskFill.java Wed Apr 23 >>>>> 11:35:40 >>>>> 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/MaskFill.java Sat Apr 26 >>>>> 01:40:27 >>>>> 2014 -0300 >>>>> @@ -50,11 +50,11 @@ >>>>> */ >>>>> public class MaskFill extends GraphicsPrimitive >>>>> { >>>>> - public static final String methodSignature = >>>>> "MaskFill(...)".toString(); >>>>> + public static final String methodSignature = "MaskFill(...)"; >>>>> public static final String fillPgramSignature = >>>>> - "FillAAPgram(...)".toString(); >>>>> + "FillAAPgram(...)"; >>>>> public static final String drawPgramSignature = >>>>> - "DrawAAPgram(...)".toString(); >>>>> + "DrawAAPgram(...)"; >>>>> >>>>> public static final int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/loops/ScaledBlit.java >>>>> --- a/src/share/classes/sun/java2d/loops/ScaledBlit.java Wed Apr 23 >>>>> 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/ScaledBlit.java Sat Apr 26 >>>>> 01:40:27 >>>>> 2014 -0300 >>>>> @@ -45,7 +45,7 @@ >>>>> >>>>> public class ScaledBlit extends GraphicsPrimitive >>>>> { >>>>> - public static final String methodSignature = >>>>> "ScaledBlit(...)".toString(); >>>>> + public static final String methodSignature = "ScaledBlit(...)"; >>>>> >>>>> public static final int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>>>> loops/TransformBlit.java >>>>> --- a/src/share/classes/sun/java2d/loops/TransformBlit.java Wed Apr 23 >>>>> 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/TransformBlit.java Sat Apr 26 >>>>> 01:40:27 2014 -0300 >>>>> @@ -47,7 +47,7 @@ >>>>> public class TransformBlit extends GraphicsPrimitive >>>>> { >>>>> public static final String methodSignature = >>>>> - "TransformBlit(...)".toString(); >>>>> + "TransformBlit(...)"; >>>>> >>>>> public static final int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/java2d/ >>>>> loops/TransformHelper.java >>>>> --- a/src/share/classes/sun/java2d/loops/TransformHelper.java Wed Apr >>>>> 23 >>>>> 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/sun/java2d/loops/TransformHelper.java Sat Apr >>>>> 26 >>>>> 01:40:27 2014 -0300 >>>>> @@ -46,7 +46,7 @@ >>>>> public class TransformHelper extends GraphicsPrimitive >>>>> { >>>>> public static final String methodSignature = >>>>> - "TransformHelper(...)".toString(); >>>>> + "TransformHelper(...)"; >>>>> >>>>> public static final int primTypeID = makePrimTypeID(); >>>>> >>>>> diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java >>>>> --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 >>>>> 2014 -0700 >>>>> +++ b/src/share/classes/sun/misc/ExtensionInfo.java Sat Apr 26 01:40:27 >>>>> 2014 -0300 >>>>> @@ -260,11 +260,11 @@ >>>>> >>>>> // Convert token into meaning number for comparision >>>>> if (stk.hasMoreTokens()) >>>>> - n = convertToken(stk.nextToken().toString()); >>>>> + n = convertToken(stk.nextToken()); >>>>> >>>>> // Convert token into meaning number for comparision >>>>> if (ttk.hasMoreTokens()) >>>>> - m = convertToken(ttk.nextToken().toString()); >>>>> + m = convertToken(ttk.nextToken()); >>>>> >>>>> if (n > m) >>>>> return 1; >>>>> diff -r e323c74edabd >>>>> src/share/classes/sun/tools/jconsole/inspector/Utils.java >>>>> --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr >>>>> 23 >>>>> 11:35:40 2014 -0700 >>>>> +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Sat Apr >>>>> 26 >>>>> 01:40:27 2014 -0300 >>>>> @@ -378,7 +378,7 @@ >>>>> if (userInput instanceof XObject) { >>>>> result[i] = ((XObject) userInput).getObject(); >>>>> } else { >>>>> - result[i] = createObjectFromString(params[ >>>>> i].toString(), >>>>> + result[i] = createObjectFromString(params[i], >>>>> (String) userInput); >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>> >>> > From kumar.x.srinivasan at oracle.com Wed Apr 30 22:42:24 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 30 Apr 2014 15:42:24 -0700 Subject: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <53616152.9070600@oracle.com> References: <536029F0.9000406@oracle.com> <53616152.9070600@oracle.com> Message-ID: <53617C50.80409@oracle.com> For completeness the bugid line needs the bugid as shown, otherwise SQE will open another bug to have you fix this. -26 * @bug 8001533 8004547 +26 * @bug 8001533 8004547 8035782 other than that it looks good, I can push this with the above change. Anyone else have any concerns with this change before I push ? Thanks Kumar On 4/30/2014 1:47 PM, Neil Toda wrote: > > Please review Launcher change and test. > > I've added to the Launcher test : FXLauncherTest.java > The test will now check that LauncherHelper$FXHelper is not loaded for > non-JavaFX class and jar files. > > webrev.02 contains only review suggestions from webrev.01 and the new > test class. > > http://cr.openjdk.java.net/~ntoda/8035782/webrev.02/ > > for bug: > > https://bugs.openjdk.java.net/browse/JDK-8035782 > > Thanks > > -neil > > From martinrb at google.com Wed Apr 30 23:33:52 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 30 Apr 2014 16:33:52 -0700 Subject: Why does canonicalize call collapse after realpath? Message-ID: canonicalize_md.c does: /* First try realpath() on the entire path */ if (realpath(original, resolved)) { /* That worked, so return it */ collapse(resolved); return 0; } And collapse promises to remove /./ and /../ BUT realpath should have already done that: http://pubs.opengroup.org/onlinepubs/009696899/functions/realpath.html The *realpath*() function shall derive, from the pathname pointed to by *file_name*, an absolute pathname that names the same file, whose resolution does not involve '.', '..', or symbolic links. (although it's true that collapse is not the expensive part of the operation...)